From: LW@KARO-electronics.de (Lothar Waßmann)
To: linux-arm-kernel@lists.infradead.org
Subject: dev->of_node overwrite can cause device loading with different driver
Date: Wed, 18 Sep 2013 10:49:19 +0200 [thread overview]
Message-ID: <21049.26895.978512.36292@ipc1.ka-ro> (raw)
In-Reply-To: <20130918083155.GB10126@pengutronix.de>
Hi,
Markus Pargmann writes:
> On Sat, Sep 14, 2013 at 01:28:09PM +0100, Russell King - ARM Linux wrote:
> > On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
> > > On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> > > > 3. We could fix up all drivers that change the of_node. But there are
> > > > ARM DT frameworks that require a device struct as parameter instead
> > > > of a device_node parameter (e.g. soc-generic-dmaengine-pcm). So a
> > > > driver core, initialized by a glue driver with DT bindings, has to
> > > > set dev->of_node to use those frameworks. I think it is strange to
> > > > have such DT framework interfaces if a driver is not supposed to
> > > > overwrite dev->of_node permanently.
> > >
> > > How about any driver that does muck with this structure, restore it
> > > properly if their probe() function fails? Yes, you show that this is
> > > going to be tricky in some places (i.e. musb), but it makes sense that
> > > the burden of fixing this issue would rest on them, as they are the ones
> > > causing this problem, right?
> >
> > It's not about overwriting at all.
>
> musb does not overwrite of_node, but other drivers do, e.g. USB chipidea
> core driver which uses its parent of_node. When probe fails in this
> case, we could end up with similar issues.
>
This has already been fixed in commit:
e98b44e9 usb: chipidea: prevent endless loop registering platform_devices when probe fails
in linux-next
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
WARNING: multiple messages have this Message-ID (diff)
From: "Lothar Waßmann" <LW@KARO-electronics.de>
To: Markus Pargmann <mpa@pengutronix.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: Re: dev->of_node overwrite can cause device loading with different driver
Date: Wed, 18 Sep 2013 10:49:19 +0200 [thread overview]
Message-ID: <21049.26895.978512.36292@ipc1.ka-ro> (raw)
In-Reply-To: <20130918083155.GB10126@pengutronix.de>
Hi,
Markus Pargmann writes:
> On Sat, Sep 14, 2013 at 01:28:09PM +0100, Russell King - ARM Linux wrote:
> > On Sat, Sep 14, 2013 at 05:17:29AM -0700, Greg Kroah-Hartman wrote:
> > > On Sat, Sep 14, 2013 at 09:16:53AM +0200, Markus Pargmann wrote:
> > > > 3. We could fix up all drivers that change the of_node. But there are
> > > > ARM DT frameworks that require a device struct as parameter instead
> > > > of a device_node parameter (e.g. soc-generic-dmaengine-pcm). So a
> > > > driver core, initialized by a glue driver with DT bindings, has to
> > > > set dev->of_node to use those frameworks. I think it is strange to
> > > > have such DT framework interfaces if a driver is not supposed to
> > > > overwrite dev->of_node permanently.
> > >
> > > How about any driver that does muck with this structure, restore it
> > > properly if their probe() function fails? Yes, you show that this is
> > > going to be tricky in some places (i.e. musb), but it makes sense that
> > > the burden of fixing this issue would rest on them, as they are the ones
> > > causing this problem, right?
> >
> > It's not about overwriting at all.
>
> musb does not overwrite of_node, but other drivers do, e.g. USB chipidea
> core driver which uses its parent of_node. When probe fails in this
> case, we could end up with similar issues.
>
This has already been fixed in commit:
e98b44e9 usb: chipidea: prevent endless loop registering platform_devices when probe fails
in linux-next
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
next prev parent reply other threads:[~2013-09-18 8:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 15:53 dev->of_node overwrite can cause device loading with different driver Markus Pargmann
2013-09-13 15:53 ` Markus Pargmann
2013-09-13 17:10 ` Greg Kroah-Hartman
2013-09-13 17:10 ` Greg Kroah-Hartman
2013-09-14 7:16 ` Markus Pargmann
2013-09-14 7:16 ` Markus Pargmann
2013-09-14 11:20 ` Russell King - ARM Linux
2013-09-14 11:20 ` Russell King - ARM Linux
2013-09-18 8:43 ` Markus Pargmann
2013-09-18 8:43 ` Markus Pargmann
2013-09-14 12:17 ` Greg Kroah-Hartman
2013-09-14 12:17 ` Greg Kroah-Hartman
2013-09-14 12:28 ` Russell King - ARM Linux
2013-09-14 12:28 ` Russell King - ARM Linux
2013-09-18 8:31 ` Markus Pargmann
2013-09-18 8:31 ` Markus Pargmann
2013-09-18 8:49 ` Lothar Waßmann [this message]
2013-09-18 8:49 ` Lothar Waßmann
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=21049.26895.978512.36292@ipc1.ka-ro \
--to=lw@karo-electronics.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.