linux-kernel - Re: linux-next: build failure after merge of the final tree (pwm tree related)

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]

Message-ID: <20120703111426.GA26468@avionic-0098.mockup.avionic-design.de>
Date:	Tue, 3 Jul 2012 13:14:26 +0200
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Arnd Bergmann <arnd.bergmann@...aro.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Sascha Hauer <s.hauer@...gutronix.de>
Subject: Re: linux-next: build failure after merge of the final tree (pwm
 tree related)

On Tue, Jul 03, 2012 at 11:06:42AM +0000, Arnd Bergmann wrote:
> On Tuesday 03 July 2012, Thierry Reding wrote:
> >   Show Details
> >   On Tue, Jul 03, 2012 at 08:59:11AM +0000, Arnd Bergmann wrote:
> > > On Tuesday 03 July 2012, Thierry Reding wrote:
> > > > I came up with the attached patch. What do you think? It fixes the
> > > > PowerPC allyesconfig issue for me.
> > > 
> > > This one looks correct, but I would still do it the other way around,
> > > putting the depends statements into the locations of the other drivers.
> > > The main difference is that we can then independently convert the
> > > remaining drivers, without having merge conflicts in the same line
> > > every time we remove one of the dependencies.
> > 
> > The downside of that approach, however, is to make PWM override other
> > settings. For instance if you have TWL6030_PWM selected and then decide
> > to also select PWM, then the former will be automatically deselected to
> > satisfy the dependency. I'm not sure if that's desired.
> 
> It's true that this may be confusing, but I think it's the right
> approach for future multiplatform kernels. If we have e.g. a combined
> omap+ux500+imx kernel, we can only have one implementation of the
> PWM interfaces, and that should be the new one.

It will certainly be an incentive to port other PWM implementations to
the new framework.

> It's less clear for the other architectures. Maybe a mixed approach
> is better there, making CONFIG_PWM depend on !MACH_JZ4740 &&
> !PUV3_NB0916 && !BLACKFIN, but letting the remaining ARM versions
> of the PWM code depend on !PWM.

Yes, that would certainly be less confusing if somebody wants to build
with e.g. JZ4740 support because Kconfig will then disable the new PWM
instead of the other way around. Then again, maybe that's exactly the
opposite of what we want.

Also note that I already ported the blackfin PWM driver.

Thierry

Content of type "application/pgp-signature" skipped