From: Greg Kroah-Hartman <gregkh@linuxfoundation•org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix•de>
Cc: Russell King - ARM Linux <linux@arm•linux.org.uk>,
Robin Murphy <robin.murphy@arm•com>,
Guenter Roeck <linux@roeck-us•net>,
linux-next@vger•kernel.org, linux-kernel@vger•kernel.org,
linux-arm-kernel@lists•infradead.org
Subject: Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'
Date: Mon, 15 Feb 2016 08:49:37 -0800 [thread overview]
Message-ID: <20160215164937.GC25556@kroah.com> (raw)
In-Reply-To: <20160215162753.GI12289@pengutronix.de>
On Mon, Feb 15, 2016 at 05:27:53PM +0100, Uwe Kleine-König wrote:
> Hello Russell,
>
> On Mon, Feb 15, 2016 at 02:43:44PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 15, 2016 at 01:11:49PM +0000, Robin Murphy wrote:
> > > FWIW the PL180 on my Juno still works fine with this patch picked on top of
> > > -rc3, so the issue would seem to be something else - From a quick comparison
> > > between the DTs I see a slight difference in compatible strings for the
> > > clocks, but the more likely-looking suspect is that the VExpress DT
> > > references some GPIOs where the Juno DT doesn't.
> >
> > Maybe it would be a good idea that Uwe creates a patch which initially
> > warns when a DT platform device falls back to matching via the platform
> > strings?
> >
> > It's likely that the "basic subsystem" platform drivers are silent when
> > they probe, so having notification of a fallback would at least put
> > something into the kernel log when that happens - and then later change
> > that to be a hard failure (as Uwe is trying to do with his patch.)
> >
> > However, I have to bring up another point: is what Uwe is trying to do
> > actually the right thing? The DT platform device code has the ability
> > to create standard platform devices from DT, with an of_node, but with
> > standard names, and platform data. It's there for compatibility with
> > older systems, and is there to allow systems to be transitioned over.
> >
> > This patch breaks all that: despite the DT code changing the platform
> > device bus_id from the address.nodename format to the standard format
> > (thus allowing unconverted platform drivers to match), this patch
> > means that because the platform device has a of_node attached, this
> > will now fail.
> >
> > Therefore, I think Uwe's patch is just wrong - or, if it's something we
> > want, the auxdata table support code needs to _also_ be ripped out of
> > the drivers/of/platform.c code, but that then means anyone who wants to
> > go through the conversion has a big flag-day change to go through.
>
> That's a valid concern I wasn't aware of when I created the patch.
>
> So maybe just emitting a warning as you suggested is a good idea. And
> additionally only emit it when the driver is dt aware, too.
>
> Greg, can you drop this patch, or do you need a proper changelog for a
> revert? On top of that I'd then create a new patch which is more
> conservative.
A hint as to what the git commit id was would be helpful, I can just
revert it based on that.
thanks,
greg k-h
next prev parent reply other threads:[~2016-02-15 16:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-14 16:50 arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles' Guenter Roeck
2016-02-14 19:55 ` Uwe Kleine-König
2016-02-14 20:07 ` Russell King - ARM Linux
2016-02-15 8:17 ` Uwe Kleine-König
2016-02-15 8:58 ` Russell King - ARM Linux
2016-02-15 9:14 ` Uwe Kleine-König
2016-02-15 10:04 ` Russell King - ARM Linux
2016-02-15 10:10 ` Uwe Kleine-König
2016-02-15 10:13 ` Russell King - ARM Linux
2016-02-14 21:08 ` Guenter Roeck
2016-02-15 7:48 ` Uwe Kleine-König
2016-02-15 10:59 ` Uwe Kleine-König
2016-02-15 13:11 ` Robin Murphy
2016-02-15 14:43 ` Russell King - ARM Linux
2016-02-15 16:27 ` Uwe Kleine-König
2016-02-15 16:49 ` Greg Kroah-Hartman [this message]
2016-02-15 17:12 ` Uwe Kleine-König
2016-02-15 21:03 ` Greg Kroah-Hartman
2016-02-15 15:41 ` Guenter Roeck
2016-02-15 16:12 ` Russell King - ARM Linux
2016-02-15 17:00 ` Uwe Kleine-König
2016-02-15 18:12 ` Guenter Roeck
2016-02-15 18:39 ` Sudeep Holla
2016-02-15 17:41 ` Sudeep Holla
2016-02-15 18:03 ` Russell King - ARM Linux
2016-02-15 18:15 ` Sudeep Holla
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160215164937.GC25556@kroah.com \
--to=gregkh@linuxfoundation$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=linux@arm$(echo .)linux.org.uk \
--cc=linux@roeck-us$(echo .)net \
--cc=robin.murphy@arm$(echo .)com \
--cc=u.kleine-koenig@pengutronix$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox