[PATCH] firmware: Make firmware drivers generally available

[PATCH] firmware: Make firmware drivers generally available

[Lars-Peter Clausen]

Currently only x86, ia64 and blackfin architectures include
drivers/firmware/Kconfig, as a result firmware drivers are only available on
these platforms. This has not been a problem historically, because all of the
firmware drivers were architecture specific.

But this has changed with the addition of the SigmaStudio firmware loader
(commit e359dc24 "sigma-firmware: loader for Analog Devices' SigmaStudio"),
which is used to parse and load firmware files for Analog Devices' SigmaDSP
processors. These DSPs are usually embedded in for example audio codecs, which
use the I2C or SPI bus for communication and are not architecture specific.
Thus make the firmware drivers generally available, so it can be used on all
architectures.

Note that this moves the Kconfig "Firmware Drivers" entry from the top-level to
the "Device Drivers" submenu for architectures which had it already available.

Reported-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
---
 arch/blackfin/Kconfig |    2 --
 arch/ia64/Kconfig     |    2 --
 arch/x86/Kconfig      |    2 --
 drivers/Kconfig       |    2 ++
 4 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig
index d619b17..a7c1efa 100644
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -1283,8 +1283,6 @@ source "net/Kconfig"
 
 source "drivers/Kconfig"
 
-source "drivers/firmware/Kconfig"
-
 source "fs/Kconfig"
 
 source "arch/blackfin/Kconfig.debug"
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 38280ef..34be81e 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -583,8 +583,6 @@ config CRASH_DUMP
 	  help
 	    Generate crash dump after being started by kexec.
 
-source "drivers/firmware/Kconfig"
-
 source "fs/Kconfig.binfmt"
 
 endmenu
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index da34972..e112693 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2153,8 +2153,6 @@ source "net/Kconfig"
 
 source "drivers/Kconfig"
 
-source "drivers/firmware/Kconfig"
-
 source "fs/Kconfig"
 
 source "arch/x86/Kconfig.debug"
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 3bb154d..6b2c238 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -32,6 +32,8 @@ source "drivers/message/fusion/Kconfig"
 
 source "drivers/firewire/Kconfig"
 
+source "drivers/firmware/Kconfig"
+
 source "drivers/message/i2o/Kconfig"
 
 source "drivers/macintosh/Kconfig"
-- 
1.7.2.5

Re: [PATCH] firmware: Make firmware drivers generally available

[Clemens Ladisch]

Lars-Peter Clausen wrote:
> Currently only x86, ia64 and blackfin architectures include
> drivers/firmware/Kconfig, as a result firmware drivers are only available on
> these platforms. This has not been a problem historically, because all of the
> firmware drivers were architecture specific.
> 
> But this has changed with the addition of the SigmaStudio firmware loader
> (commit e359dc24 "sigma-firmware: loader for Analog Devices' SigmaStudio"),
> which is used to parse and load firmware files for Analog Devices' SigmaDSP
> processors.

It looks as if sigma.c doesn't actually belong into drivers/firmware.
That directory is for code that lets the kernel access the firmware
of the platform that the kernel itself runs on.

The request_firmware() stuff is usually part of the actual driver that
needs it.


Regards,
Clemens

Re: [PATCH] firmware: Make firmware drivers generally available

[Mike Frysinger]

On Fri, Jun 17, 2011 at 09:16, Clemens Ladisch wrote:
> It looks as if sigma.c doesn't actually belong into drivers/firmware.
> That directory is for code that lets the kernel access the firmware
> of the platform that the kernel itself runs on.

-EMISSINGBETTERSUGGESTION

> The request_firmware() stuff is usually part of the actual driver that
> needs it.

except for when the firmware format is the same across many drivers
because it has a unified format (by design)
-mike

Re: [PATCH] firmware: Make firmware drivers generally available

[Mike Frysinger]

On Fri, Jun 17, 2011 at 07:40, Lars-Peter Clausen wrote:
> Currently only x86, ia64 and blackfin architectures include
> drivers/firmware/Kconfig, as a result firmware drivers are only available on
> these platforms. This has not been a problem historically, because all of the
> firmware drivers were architecture specific.
>
> But this has changed with the addition of the SigmaStudio firmware loader
> (commit e359dc24 "sigma-firmware: loader for Analog Devices' SigmaStudio"),
> which is used to parse and load firmware files for Analog Devices' SigmaDSP
> processors. These DSPs are usually embedded in for example audio codecs, which
> use the I2C or SPI bus for communication and are not architecture specific.
> Thus make the firmware drivers generally available, so it can be used on all
> architectures.
>
> Note that this moves the Kconfig "Firmware Drivers" entry from the top-level to
> the "Device Drivers" submenu for architectures which had it already available.

Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike

Re: [PATCH] firmware: Make firmware drivers generally available

[Clemens Ladisch]

Mike Frysinger wrote:
> On Fri, Jun 17, 2011 at 09:16, Clemens Ladisch wrote:
> > It looks as if sigma.c doesn't actually belong into drivers/firmware.
> > That directory is for code that lets the kernel access the firmware
> > of the platform that the kernel itself runs on.
> 
> -EMISSINGBETTERSUGGESTION

I *knew* somebody would ask.  :)

"drivers/firmware" is the obvious name for both, but that makes
it ambiguous.  I'd suggest to split the two subsystems into
"drivers/host-firmware" and "drivers/device-firmware".


Regards,
Clemens

Re: [PATCH] firmware: Make firmware drivers generally available

[Mike Frysinger]

On Fri, Jun 17, 2011 at 14:11, Clemens Ladisch wrote:
> Mike Frysinger wrote:
>> On Fri, Jun 17, 2011 at 09:16, Clemens Ladisch wrote:
>> > It looks as if sigma.c doesn't actually belong into drivers/firmware.
>> > That directory is for code that lets the kernel access the firmware
>> > of the platform that the kernel itself runs on.
>>
>> -EMISSINGBETTERSUGGESTION
>
> I *knew* somebody would ask.  :)
>
> "drivers/firmware" is the obvious name for both, but that makes
> it ambiguous.  I'd suggest to split the two subsystems into
> "drivers/host-firmware" and "drivers/device-firmware".

i honestly dont see how this is better.  the drivers/firmware/ isnt
exactly overflowing, and differentiating between the two modes doesnt
seem to gain us anything.
-mike

Re: [PATCH] firmware: Make firmware drivers generally available

[Mark Brown]

On Fri, Jun 17, 2011 at 02:25:21PM -0400, Mike Frysinger wrote:
> On Fri, Jun 17, 2011 at 14:11, Clemens Ladisch wrote:

> > "drivers/firmware" is the obvious name for both, but that makes
> > it ambiguous.  I'd suggest to split the two subsystems into
> > "drivers/host-firmware" and "drivers/device-firmware".

> i honestly dont see how this is better.  the drivers/firmware/ isnt
> exactly overflowing, and differentiating between the two modes doesnt
> seem to gain us anything.

Do we have anything like an actual subsystem in firmware?  If we do and
it's sensible to do things that affect all firmwares then splitting
seems reasonable but if not then it's less clear.

Re: [uclinux-dist-devel] [PATCH] firmware: Make firmware drivers generally available

[Mike Frysinger]

On Mon, Jun 20, 2011 at 20:35, Mark Brown wrote:
> On Fri, Jun 17, 2011 at 02:25:21PM -0400, Mike Frysinger wrote:
>> On Fri, Jun 17, 2011 at 14:11, Clemens Ladisch wrote:
>> > "drivers/firmware" is the obvious name for both, but that makes
>> > it ambiguous.  I'd suggest to split the two subsystems into
>> > "drivers/host-firmware" and "drivers/device-firmware".
>
>> i honestly dont see how this is better.  the drivers/firmware/ isnt
>> exactly overflowing, and differentiating between the two modes doesnt
>> seem to gain us anything.
>
> Do we have anything like an actual subsystem in firmware?  If we do and
> it's sensible to do things that affect all firmwares then splitting
> seems reasonable but if not then it's less clear.

i dont think there is.  we havent hit enough critical mass yet to warrant it.
-mike