Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable

[Scott Wood]

On Mon, 2020-03-02 at 12:42 +0800, çæè wrote:
> åääïScott Wood <oss@xxxxxxxxxxxx>
> åéææï2020-03-01 07:12:58
> æääï"çæè" <wenhu.wang@xxxxxxxx>
> æéäïwangwenhu <wenhu.pku@xxxxxxxxx>,Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>,B
> enjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>,Paul Mackerras <
> paulus@xxxxxxxxx>,Michael Ellerman <mpe@xxxxxxxxxxxxxx>,
> linuxppc-dev@xxxxxxxxxxxxxxxx,linux-kernel@xxxxxxxxxxxxxxx,
> trivial@xxxxxxxxxx,Rai Harninder <harninder.rai@xxxxxxx>
> äéïRe: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
> Tue, 2020-01-21 at 14:38 +0800, çæè wrote:
> > > åääïScott Wood <oss@xxxxxxxxxxxx>
> > > åéææï2020-01-21 13:49:59
> > > æääï"çæè" <wenhu.wang@xxxxxxxx>
> > > æéäïwangwenhu <wenhu.pku@xxxxxxxxx>,Kumar Gala <
> > > galak@xxxxxxxxxxxxxxxxxxx>,B
> > > enjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>,Paul Mackerras <
> > > paulus@xxxxxxxxx>,Michael Ellerman <mpe@xxxxxxxxxxxxxx>,
> > > linuxppc-dev@xxxxxxxxxxxxxxxx,linux-kernel@xxxxxxxxxxxxxxx,
> > > trivial@xxxxxxxxxx,Rai Harninder <harninder.rai@xxxxxxx>
> > > äéïRe: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
> > > Tue, 2020-01-21 at 13:20 +0800, çæè wrote:
> > > > > From: Scott Wood <oss@xxxxxxxxxxxx>
> > > > > Date: 2020-01-21 11:25:25
> > > > > To:  wangwenhu <wenhu.pku@xxxxxxxxx>,Kumar Gala <
> > > > > galak@xxxxxxxxxxxxxxxxxxx>,
> > > > > Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>,Paul Mackerras <
> > > > > paulus@xxxxxxxxx>,Michael Ellerman <mpe@xxxxxxxxxxxxxx>,
> > > > > linuxppc-dev@xxxxxxxxxxxxxxxx,linux-kernel@xxxxxxxxxxxxxxx
> > > > > Cc:  trivial@xxxxxxxxxx,wenhu.wang@xxxxxxxx,Rai Harninder <
> > > > > harninder.rai@xxxxxxx>
> > > > > Subject: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM
> > > > > configurable>On Mon, 2020-01-20 at 06:43 -0800, wangwenhu wrote:
> > > > > > > From: wangwenhu <wenhu.wang@xxxxxxxx>
> > > > > > > 
> > > > > > > When generating .config file with menuconfig on Freescale BOOKE
> > > > > > > SOC, FSL_85XX_CACHE_SRAM is not configurable for the lack of
> > > > > > > description in the Kconfig field, which makes it impossible
> > > > > > > to support L2Cache-Sram driver. Add a description to make it
> > > > > > > configurable.
> > > > > > > 
> > > > > > > Signed-off-by: wangwenhu <wenhu.wang@xxxxxxxx>
> > > > > > 
> > > > > > The intent was that drivers using the SRAM API would select the
> > > > > > symbol.  What
> > > > > > is the use case for selecting it manually?
> > > > > > 
> > > > > 
> > > > > With a repository of multiple products(meaning different defconfigs)
> > > > > and
> > > > > multiple
> > > > > developers, the Kconfigs of the Kernel Source Tree change
> > > > > frequently. So
> > > > > the
> > > > > "make menuconfig"
> > > > > process is needed for defconfigs' re-generating or updating for the
> > > > > complexity of dependencies
> > > > > between different features defined in the Kconfigs.
> > > > 
> > > > That doesn't answer my question of how the SRAM code would be useful
> > > > other
> > > > than to some other driver that uses the API (which would use
> > > > "select").  There
> > > > is no userspace API.  You could use the kernel command line to
> > > > configure
> > > > the
> > > > SRAM but you need to get the address of it for it to be useful.
> > > > 
> > > 
> > > Like you've asked below, via /dev/mem or direct calling within the
> > > Kernel.
> > > And they are not submitted yes, under development.
> > 
> > If they are calling within the kernel, then whatever driver that is should
> > select FSL_85XX_CACHE_SRAM.  Directly accessing /dev/mem without any way
> > for
> > the kernel to advertise where it is or which parts of SRAM are available
> > for
> > use sounds like a bad idea.
> > 
> 
> Yes, definitely. So like we enable the moulde which should selet 
> FSL_85XX_CACHE_SRAM to build vmlinux, FSL_85XX_CACHE_SRAM 
> could not be seleted because of the Kconfig definition problem 
> which I am trying to fix now.  So would you please merge the patch 
> for the convenience of later works depending on the driver.

Sorry, I don't think it's something that should be enabled by itself with
nothing using the allocators.  Suppose we took this patch, and people enabled
it and accessed it via /dev/mem.  Then suppose a driver is patched to allocate
some sram and use it.  They'd be stepping on each others' toes undetected.

If you want to expose it to userspace, add code that allocates some or all of
the sram and make it something userspace can mmap.  Or, if nothing's going to
use them, remove the allocators and export the entire thing to userspace
(again via an sram-specific mappable rather than /dev/mem).

-Scott