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
| ||
|
Date: Wed, 25 May 2011 11:02:26 +0800 From: Shawn Guo <shawn.guo@...escale.com> To: Rob Herring <robherring2@...il.com> CC: Grant Likely <grant.likely@...retlab.ca>, Kevin Hilman <khilman@...com>, Russell King - ARM Linux <linux@....linux.org.uk>, <devicetree-discuss@...ts.ozlabs.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rjw@...k.pl>, Jeremy Kerr <jeremy.kerr@...onical.com>, <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH 2/2] drivers/amba: probe via device tree On Tue, May 24, 2011 at 10:03:35AM -0500, Rob Herring wrote: > Grant, > > On 05/23/2011 10:09 AM, Grant Likely wrote: > >On Mon, May 23, 2011 at 3:58 AM, Russell King - ARM Linux > ><linux@....linux.org.uk> wrote: > >>On Mon, May 23, 2011 at 11:37:04AM +0200, Kristoffer Glembo wrote: > >>>Grant Likely wrote: > >>>>In the case we're talking about the bus really is an AMBA bus, and all > >>>>the devices on it are in some sense real amba devices. The problem is > >>>>that not all of the devices on the bus implement peripheral ID > >>>>registers or other mechanisms that good upstanding AMBA devices are > >>>>expected to have. > >>> > >>>Before we go hardware bashing of non primecell AMBA devices I would just > >>>want to point out that the primecell stuff is not part of the AMBA > >>>specification. > >> > >>And before we go down that route, let me point out that the 'amba bus' > >>stuff in the kernel is there to support primecells, rather than all > >>devices which the AMBA specification covers. > >> > >>The reason it's called 'amba' is because back in 2001 or so when the > >>first primecell drivers were created, there was little information > >>available as to what AMBA, AHB, or APB even covered. All I had to go > >>on were the primecell documents themselves. The higher level documents > >>were not available to me. > >> > >>So, despite it being called 'amba', it really is just for primecells > >>and if we didn't have the exposure to userspace, I'd have renamed it to > >>'apb' or similar instead. > > > >Okay, that clarifies things a lot, and lends weight to the arguement > >that it is perfectly normal and acceptable to have both amba_devices > >and platform_devices on the same bus segment. Are there any cases > >where amba primecells are being driven by platform_drivers? If so, > >should those drivers have an amba_driver registration added? > > I would be surprised if there are any implemented as > platform_drivers that are not duplicates of an amba driver. The STMP > uart is actually a pl011 and it's platform driver was recently It (duart than auart) is a platform driver in Freesccale BSP, and was turned into 'amba' one when being upstreamed. > removed IIRC. So I think we can consider platform drivers something > that should be fixed in this case. > -- Regards, Shawn -- 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