[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <196642e7-4136-4ba6-a918-8c759f27f818@sirena.org.uk>
Date: Mon, 7 Aug 2023 19:17:58 +0100
From: Mark Brown <broonie@...nel.org>
To: Alexandru Ardelean <alex@...uggie.ro>
Cc: Andrei Coardos <aboutphysycs@...il.com>,
linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
nick.hawkins@....com, verdun@....com
Subject: Re: [PATCH] spi: gxp: removed unneeded call to platform_set_drvdata()
On Mon, Aug 07, 2023 at 08:38:27PM +0300, Alexandru Ardelean wrote:
> On Mon, Aug 7, 2023 at 4:27 PM Mark Brown <broonie@...nel.org> wrote:
> > On Mon, Aug 07, 2023 at 04:02:17PM +0300, Andrei Coardos wrote:
> > > This function call was found to be unnecessary as there is no equivalent
> > > platform_get_drvdata() call to access the private data of the driver. Also,
> > > the private data is defined in this driver, so there is no risk of it being
> > > accessed outside of this driver file.
> > That isn't enough of a check here - people can still reference the
> > driver data without going through the accessor function.
> So, is that like calling `platform_get_drvdata()` in a parent/chid
> device, to check if the driver-data is set?
That wasn't what I was thinking of, waht I was thinking of was just open
coding platform_get_drvdata() and looking directly at struct device.
Another common case is where drivers that support multiple bus types
will pass around the struct device and use dev_get_drvdata() to read the
data rather than using platform_get_drvdata(). The driver data can be
allocated and initialised with bus specific bits before being passed off
to the generic code.
That said the looking at the parent's driver data is definitely a thing
that happens with MFDs.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists