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:	Mon, 15 Feb 2016 10:13:50 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Guenter Roeck <linux@...ck-us.net>
Subject: Re: arm qemu test failures due to 'driver-core: platform: probe
 of-devices only using list of compatibles'

On Mon, Feb 15, 2016 at 11:10:14AM +0100, Uwe Kleine-König wrote:
> Hello Russell,
> 
> On Mon, Feb 15, 2016 at 10:04:15AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 15, 2016 at 10:14:06AM +0100, Uwe Kleine-König wrote:
> > > On Mon, Feb 15, 2016 at 08:58:18AM +0000, Russell King - ARM Linux wrote:
> > > > On Mon, Feb 15, 2016 at 09:17:50AM +0100, Uwe Kleine-König wrote:
> > > > > On Sun, Feb 14, 2016 at 08:07:55PM +0000, Russell King - ARM Linux wrote:
> > > > > > On Sun, Feb 14, 2016 at 08:55:01PM +0100, Uwe Kleine-König wrote:
> > > > > > > So the unexpected abnormality here is that even though this device is
> > > > > > > instantiated by dt, the driver doesn't provide any compatibles.
> > > > > > > Either my expectation is wrong, then 67d02a1bbb33455 should be reverted
> > > > > > 
> > > > > > Your expectation is wrong.  AMBA primecell devices have hardware IDs
> > > > > > and are matched to their drivers by those IDs.  Just like PCI.
> > > > > 
> > > > > pci devices don't appear in dt, do they? I don't see the connection
> > > > > between amba devices and platform devices, see my other mail in this
> > > > > thread for some more details.
> > > > 
> > > > They both have hardware IDs, and they are both matched via those hardware
> > > > IDs.
> > > 
> > > I changed platform_match which is about matching by dt compatible, acpi
> > > and/or device name. I don't see how this can affect an amba device given
> > > they match to a driver by a hardware id.
> > > 
> > > > Your change has introduced a regression and is therefore wrong.
> > > 
> > > I'd like to understand though why and how my commit is wrong to be able
> > > to fix it instead of getting it reverted.
> > 
> > I don't have the commit, and I haven't seen the patch so I can't
> > comment further, sorry.
> 
> It's in -next. For a quick look:
> 
> 	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=67d02a1bbb33455

Well, if that's only touching the platform device matching, it can't have
any effect on AMBA bus matching, which uses completely different code.
The AMBA bus code is entirely separate from platform devices.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ