linux-kernel - Re: SPARC and OF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121107065258.GA22325@avionic-0098.mockup.avionic-design.de>
Date:	Wed, 7 Nov 2012 07:52:58 +0100
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	David Miller <davem@...emloft.net>
Cc:	sparclinux@...r.kernel.org, linus.walleij@...aro.org,
	grant.likely@...retlab.ca, linux-kernel@...r.kernel.org
Subject: Re: SPARC and OF_GPIO

On Tue, Nov 06, 2012 at 06:40:58PM -0500, David Miller wrote:
> From: Thierry Reding <thierry.reding@...onic-design.de>
> Date: Mon, 5 Nov 2012 10:53:15 +0100
> 
> > Are you aware of any reasons why this conflict would still be necessary?
> 
> No reason that I can see, I'll push something like the patch below
> via the sparc tree.

Thanks for doing this.

> > This is not only the case for OF_GPIO but likely also for OF_SPI,
> > OF_I2C, OF_IRQ and OF_ADDRESS. Shouldn't those all work even on SPARC
> > nowadays?
> 
> Those also would need to be tested on an individual basis, but
> there are no fundamental problems that I am aware of.

It seems like OF_ADDRESS would be trickier. A comment around line 60 in
drivers/of/platform.c says that SPARC doesn't need functions defined in
the enclosing #ifdef CONFIG_OF_ADDRESS block. I'm not sure it would be
acceptable to remove the conflict nonetheless, even if the functions
aren't used. One benefit would be that the code could receive some extra
compile coverage.

Oddly I'm no longer able to find any reference to OF_SPI, so maybe I
just made that up...

The code conditionalized on OF_I2C looks very generic, so I think there
shouldn't be a problem to remove that conflict either.

Finally, OF_IRQ is again just generic code to map device tree data to
IRQ domains. While I didn't see the IRQ_DOMAIN symbol selected anywhere
in SPARC it should still be possible to run drivers that properly
implement IRQ domains on SPARC, right? Or is there any reason why they
wouldn't work?

So this seems like all conflicts except the one for OF_ADDRESS can
easily be removed. And even for OF_ADDRESS there may be some value in
removing the conflict.

Thierry

> 
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index b6b442b..f0a5391 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -14,6 +14,7 @@ config SPARC
>  	default y
>  	select OF
>  	select OF_PROMTREE
> +	select OF_GPIO
>  	select HAVE_IDE
>  	select HAVE_OPROFILE
>  	select HAVE_ARCH_KGDB if !SMP || SPARC64
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index d055cee..f11d8e3 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -47,7 +47,7 @@ if GPIOLIB
>  
>  config OF_GPIO
>  	def_bool y
> -	depends on OF && !SPARC
> +	depends on OF
>  
>  config DEBUG_GPIO
>  	bool "Debug GPIO calls"
> 

Content of type "application/pgp-signature" skipped