[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH3L5QoF1pyexq-QNJAy4j-X_0EFhAvzpt7tD-Tg+JFjymQg1A@mail.gmail.com>
Date: Mon, 7 Aug 2023 21:57:18 +0300
From: Alexandru Ardelean <alex@...uggie.ro>
To: Mark Brown <broonie@...nel.org>
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 7, 2023 at 9:18 PM Mark Brown <broonie@...nel.org> wrote:
>
> 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.
Ah. Right.
I hadn't thought of checking "dev->driver_data" access.
> 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
Agree. I see that happening with PM routines.
It doesn't look like it's the case in this driver.
> 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.
If I'm looking more closely, I am seeing that the
"platform_set_drvdata(pdev, spifi);" has no equivalent access to
"pdev->dev.driver_data"
Nor by open-coding, nor by "dev_get_drvdata(&pdev->dev)"
But I do see that "spi_controller_get_devdata()" is calling
"dev_get_drvdata()" on a device object allocated here via
"devm_spi_alloc_master()"
So, I agree. That a more thorough check is needed here.
>
> That said the looking at the parent's driver data is definitely a thing
> that happens with MFDs.
Yep. MFDs is one case I was thinking of too (with respect to
parent/child lookup of driver data).
Powered by blists - more mailing lists