[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c7821270385ff8e0ff62b3089937c66b0cddb61.camel@suse.de>
Date: Fri, 16 Oct 2020 17:39:08 +0200
From: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>, f.fainelli@...il.com,
linux-rpi-kernel@...ts.infradead.org,
u.kleine-koenig@...gutronix.de,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] of/platform: Create device link between simple-mfd and
its children
Hi Saravana, thanks for your comments.
On Thu, 2020-10-15 at 09:52 -0700, Saravana Kannan wrote:
> On Thu, Oct 15, 2020 at 4:43 AM Nicolas Saenz Julienne
> <nsaenzjulienne@...e.de> wrote:
> > 'simple-mfd' usage implies there might be some kind of resource sharing
> > between the parent device and its children. By creating a device link
> > with DL_FLAG_AUTOREMOVE_CONSUMER we make sure that at no point in time
> > the parent device is unbound while leaving its children unaware that
> > some of their resources disappeared.
>
> Doesn't the parent child relationship already ensure that? If not,
> maybe that's what needs fixing?
Well as Rob puts it, we're not using simple-mfd as it was intended. So that
pretty much settles it for generic solutions.
>
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
[...]
>
> > - If applying this to all simple-mfd devices is a bit too much, would
> > this be acceptable for a specific device setup. For example RPi4's
> > firmware interface (simple-mfd user) is passed to consumer drivers
> > trough a custom API (see rpi_firmware_get()). So, when unbound,
> > consumers are left with a firmware handle that points to nothing.
>
> You can always create device link between the real suppliers and consumers.
RPi's firmware consumers use a custom API to get a handle to the firmware
interface itself, rpi_firmware_get(). So no trace of the relationship is
expressed in DT. If the firmware interface device, the supplier, is unbinded,
that firmware handle now points nowhere and consumers will end up triggering
kernel panics. Would it make sense to make a device link between the two in
that case? Or I'd be, again, abusing the concept?
Regards,
Nicolas
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists