linux-kernel - Re: [PATCH V3 2/4] drivers/i2c/busses/i2c-at91.c: add new driver

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: <20111108190200.GC24399@legolas.emea.dhcp.ti.com>
Date:	Tue, 8 Nov 2011 21:02:02 +0200
From:	Felipe Balbi <balbi@...com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Felipe Balbi <balbi@...com>,
	Nicolas Ferre <nicolas.ferre@...el.com>, rmallon@...il.com,
	Nikolaus Voss <n.voss@...nmann.de>,
	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	ben-linux@...ff.org, khali@...ux-fr.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V3 2/4] drivers/i2c/busses/i2c-at91.c: add new driver

Hi,

On Tue, Nov 08, 2011 at 06:55:25PM +0000, Russell King - ARM Linux wrote:
> > so ? Instead of saying this to me, you should contact the
> > authors/maintainers of those drivers and ask them to clean that up.
> 
> Oh for god sake, I was just asking you to clarify your statement in
> light of what is currently being done.
> 
> Now, let me set something straight.  I've been saying that machine_is_xxx()
> should not be used in drivers.  That's a platform thing and platform
> specifics should not be in drivers - it should be passed in via DT or
> platform data.  That's enforced by the way DT works (Grant's decision
> not mine) - with DT you don't have any kind of testable machine ID for
> machine_is_xxx() to use.
> 
> I've never said that cpu_is_xxx() should not - that's something *other*
> people are saying (and quite rightly so) because if we're going to start
> sharing drivers between different SoCs (or even architectures - eg, PXA
> IP appearing on x86) then it doesn't make sense for the type of SoC to
> be tested.  It makes more sense for the revision of the IP implementation
> to be checked IFF such information is available.  If not, some other way
> of controlling the 'features' needs to be sought.
> 
> As far as the use of asm/*.h includes, I've NEVER made any statement
> about the use of those in drivers.  In fact, I don't see any reason to
> avoid them _provided_ they're standard cross-arch includes.
> 
> As for mach/*.h includes, I don't think that I've made any statement
> about those either, but at this point - given that we're working towards
> a single zImage on ARM - it is _sensible_ to avoid such includes in
> drivers.
> 
> So, I think your reaction to my statement is way off mark, and you're
> attributing statements (that it seems you personally don't agree with)
> to me.

If I did, then it's really my fault. But I _do_ remember you complaining
about uses of <asm/gpio.h> instead of <linux/gpio.h>, for example.

Now, all the other topics I agree and, in fact, have been pushing for
that as I can. Specially with regards to IP cores being shared among
several architectures (see drivers/usb/dwc3 where I have a core driver
shared between ARM and PCI/x86).

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)