[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210731120515.xkr64yvnczchxz4s@pengutronix.de>
Date: Sat, 31 Jul 2021 14:05:15 +0200
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Finn Thain <fthain@...ux-m68k.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org,
kernel@...gutronix.de
Subject: Re: [PATCH 1/5] nubus: Simplify check in remove callback
Hello Finn,
On Sat, Jul 31, 2021 at 08:32:38PM +1000, Finn Thain wrote:
> On Tue, 27 Jul 2021, Uwe Kleine-König wrote:
> > On Tue, Jul 27, 2021 at 07:50:39PM +1000, Finn Thain wrote:
> > > On Tue, 27 Jul 2021, Uwe Kleine-König wrote:
> > >
> > > > The driver core only calls a remove callback when the device was
> > > > successfully bound (aka probed) before. So dev->driver is never
> > > > NULL.
> > >
> > > Are you sure dev->driver is non-NULL for the lifetime of the device? A
> > > quick glance at device_reprobe() makes me wonder about that.
> >
> > Not for the lifetime of the device, but as long as a driver is bound to
> > the device. device_reprobe() calls device_driver_detach() after which
> > the driver is considered unbound and dev->driver is assigned NULL. (via
> > device_driver_detach -> device_release_driver_internal ->
> > __device_release_driver)
>
> Are you saying that this situation does not presently apply to nubus,
> zorro or superhyway? Or are you saying that the remove callback will never
> be called in this situation?
I'm saying that if you call device_reprobe() the remove callback is
called before dev->driver becomes NULL. So in the remove callback it's
safe to assume that dev->driver is non-NULL.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists