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@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
