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

On Mon, 2020-03-02 at 12:42 +0800, 王文虎 wrote:

发件人：Scott Wood [off-list ref]
发送日期：2020-03-01 07:12:58
收件人："王文虎" [off-list ref]
抄送人：wangwenhu [off-list ref],Kumar Gala [off-list ref],B
enjamin Herrenschmidt [off-list ref],Paul Mackerras <
paulus@samba.org>,Michael Ellerman [off-list ref],
linuxppc-dev@lists.ozlabs.org,linux-kernel@vger.kernel.org,
trivial@kernel.org,Rai Harninder [off-list ref]
主题：Re: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
Tue, 2020-01-21 at 14:38 +0800, 王文虎 wrote:

quoted

quoted

发件人：Scott Wood [off-list ref]
发送日期：2020-01-21 13:49:59
收件人："王文虎" [off-list ref]
抄送人：wangwenhu [off-list ref],Kumar Gala <
galak@kernel.crashing.org>,B
enjamin Herrenschmidt [off-list ref],Paul Mackerras <
paulus@samba.org>,Michael Ellerman [off-list ref],
linuxppc-dev@lists.ozlabs.org,linux-kernel@vger.kernel.org,
trivial@kernel.org,Rai Harninder [off-list ref]
主题：Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM configurable>On
Tue, 2020-01-21 at 13:20 +0800, 王文虎 wrote:

quoted

quoted

From: Scott Wood <oss@buserror.net>
Date: 2020-01-21 11:25:25
To:  wangwenhu <redacted>,Kumar Gala <
galak@kernel.crashing.org>,
Benjamin Herrenschmidt [off-list ref],Paul Mackerras <
paulus@samba.org>,Michael Ellerman [off-list ref],
linuxppc-dev@lists.ozlabs.org,linux-kernel@vger.kernel.org
Cc:  trivial@kernel.org,wenhu.wang@vivo.com,Rai Harninder <
harninder.rai@nxp.com>
Subject: Re: [PATCH] powerpc/Kconfig: Make FSL_85XX_CACHE_SRAM
configurable>On Mon, 2020-01-20 at 06:43 -0800, wangwenhu wrote:

quoted

quoted

From: wangwenhu <redacted>

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 <redacted>

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