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] [day] [month] [year] [list]
Date:	Tue, 29 Jan 2013 10:51:58 -0800
From:	Olof Johansson <olof@...om.net>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Stephen Warren <swarren@...dia.com>,
	Anmar Oueja <anmar.oueja@...aro.org>, arm@...nel.org
Subject: Re: [PATCH 5/5] ARM: ux500: select the DB8540 pin controller

On Tue, Jan 29, 2013 at 10:16 AM, Linus Walleij
<linus.walleij@...aro.org> wrote:
> On Tue, Jan 29, 2013 at 12:00 AM, Olof Johansson <olof@...om.net> wrote:
>> On Mon, Jan 28, 2013 at 02:52:31PM +0100, Linus Walleij wrote:
>>> From: Linus Walleij <linus.walleij@...aro.org>
>>>
>>> The pin controller is an inherent part of the SoC, without
>>> it the system will not boot, thus it needs to be selected
>>> from Kconfig.
>>>
>>> Cc: arm@...nel.org
>>> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
>>> ---
>>> Requesting ACK from ARM SoC on this patch.
>>
>> Acked-by: Olof Johansson <olof@...om.net>
>
> Thanks!
>
>> ... but I wonder if this is growing out of hand. Since they will always
>> be selected (and required) for UX500_SOC_DB8500, why not just make them
>> silent options that default to y with that as a depend?
>
> So either I do it like this by using select FOO in the
> Kconfig for the affected SoC, or I just turn it around
> and make it depend on the affected SoC and select it
> to "y" default.
>
> It's like eating eggs from the little or big end or something.
>
> This current approach has the upside of not proliferating
> the SoC Kconfig symbol outside of the ARM tree, but
> I have no strong preference...
>
> All this stuff used to live in the arch/arm/mach-foo
> folders in the past, like the clocks you just have to
> default-enable it somehow.

Hm. Damned if we do, damned if we don't.

Well, the slightly awkward part is probably that we split them up in a
bunch of Kconfig options that we need to select, but at the end of the
day, they are all either selected or unselected together. So the
granularity just means more Kconfig select lines.

Still, not a horrible problem, it just started to look at bit
excessive in the arch/arm/mach-* Kconfig.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ