linux-kernel - Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS

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]

Date:	Tue, 7 May 2013 22:06:28 +0300
From:	Aaro Koskinen <aaro.koskinen@....fi>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Eduardo Valentin <eduardo.valentin@...com>, tony@...mide.com,
	linux-omap@...r.kernel.org, Russell King <linux@....linux.org.uk>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Tomi Valkeinen <tomi.valkeinen@...com>
Subject: Re: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP

On Tue, May 07, 2013 at 12:27:11PM -0600, Jason Gunthorpe wrote:
> On Tue, May 07, 2013 at 09:15:00AM -0400, Eduardo Valentin wrote:
> > > But broadly the direction seems that drivers should have minimal
> > > dependencies so, eg, the thermal maintainer compiling for x86 should
> > > be able to compile test/static analyze your driver..
> 
> > Well, I do not see much of this attempt actually. Do you have some link
> > / evidene that shows someone who actually cares about compiling drivers
> > for targets that they are not used for? On this specific driver, I
> > actually have  had exactly the opposite advice [1]. I am not convinced
> > people actually want to do that.
> 
> There was a discussion a bit ago, but I can't find a link.. The
> context was subsystem maintainers are being asked to look after more
> code with the DT transition moving things out of arch/arm and at least
> one complained they couldn't even compile test on x86... But again, I
> can't find a link and you are right, there are lots and lots of
> 'depends ARCH..' style things in kConfig already.
> 
> Lets just call it something to think about.

Tomi started a thread related to this recently:

	http://marc.info/?l=linux-kernel&m=136731558332265&w=2

I think there's some good reasons listed there, but I guess up to the
subsystem maintainers to decide what they prefer.

A.
--
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/