[PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable

[Scott Wood]

On Mon, 2020-03-02 at 12:42 +0800, 王文虎 wrote:
> 发件人：Scott Wood <oss at buserror.net>
> 发送日期：2020-03-01 07:12:58
> 收件人："王文虎" <wenhu.wang at vivo.com>
> 抄送人：wangwenhu <wenhu.pku at gmail.com>,Kumar Gala <galak at kernel.crashing.org>,B
> enjamin Herrenschmidt <benh at kernel.crashing.org>,Paul Mackerras <
> paulus at samba.org>,Michael Ellerman <mpe at ellerman.id.au>,
> linuxppc-dev at lists.ozlabs.org,linux-kernel at vger.kernel.org,
> trivial at kernel.org,Rai Harninder <harninder.rai at nxp.com>
> 主题：Re: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
> Tue, 2020-01-21 at 14:38 +0800, 王文虎 wrote:
> > > 发件人：Scott Wood <oss at buserror.net>
> > > 发送日期：2020-01-21 13:49:59
> > > 收件人："王文虎" <wenhu.wang at vivo.com>
> > > 抄送人：wangwenhu <wenhu.pku at gmail.com>,Kumar Gala <
> > > galak at kernel.crashing.org>,B
> > > enjamin Herrenschmidt <benh at kernel.crashing.org>,Paul Mackerras <
> > > paulus at samba.org>,Michael Ellerman <mpe at ellerman.id.au>,
> > > linuxppc-dev at lists.ozlabs.org,linux-kernel at vger.kernel.org,
> > > trivial at kernel.org,Rai Harninder <harninder.rai at nxp.com>
> > > 主题：Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
> > > Tue, 2020-01-21 at 13:20 +0800, 王文虎 wrote:
> > > > > From: Scott Wood <oss at buserror.net>
> > > > > Date: 2020-01-21 11:25:25
> > > > > To:  wangwenhu <wenhu.pku at gmail.com>,Kumar Gala <
> > > > > galak at kernel.crashing.org>,
> > > > > Benjamin Herrenschmidt <benh at kernel.crashing.org>,Paul Mackerras <
> > > > > paulus at samba.org>,Michael Ellerman <mpe at ellerman.id.au>,
> > > > > linuxppc-dev at lists.ozlabs.org,linux-kernel at vger.kernel.org
> > > > > Cc:  trivial at kernel.org,wenhu.wang at vivo.com,Rai Harninder <
> > > > > harninder.rai at nxp.com>
> > > > > 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 at vivo.com>
> > > > > > > 
> > > > > > > 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 at vivo.com>
> > > > > > 
> > > > > > 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