On Mon, Jun 14, 2021 at 11:57:46AM +0300, Andy Shevchenko wrote: > +Uwe Kleine-König > > On Mon, Jun 14, 2021 at 11:24 AM Jarkko Nikula > <jarkko.nikula@xxxxxxxxxxxxxxx> wrote: > > On 6/13/21 1:36 PM, Andy Shevchenko wrote: > > > On Fri, Jun 11, 2021 at 2:57 PM Jarkko Nikula > > > <jarkko.nikula@xxxxxxxxxxxxxxx> wrote: > > >> > > >> Use to_pci_dev() helper instead of container_of(d, struct pci_dev, dev); > > > > > > ... > > > > > >> - struct pci_dev *pdev = container_of(dev, struct pci_dev, dev); > > >> + struct pci_dev *pdev = to_pci_dev(dev); > > >> struct intel_qep *qep = pci_get_drvdata(pdev); > > > > > > Why not change both lines to dev_get_drvdata()? > > > > > I thought it before and Uwe had a good point why it isn't necessarily a > > good idea: > > > > https://www.spinics.net/lists/linux-pwm/msg15325.html > > I understand this point, but the problem is that we often use > different callbacks for different layers. For example, the PM > callbacks are operating with generic 'struct device' and using the PCI > device there is non-flexible layering violation, so in my opinion it's > the opposite to what Uwe says. I.o.w. we need to use corresponding API > to what we have in the callbacks. If the callback comes from generic > level ==> generic APIs more appropriate. Without having looked at the driver in question: I (think I) understand both sides here and both variants have their own downside. - Using dev_get_drvdata() makes use of the fact that pci_set_drvdata() is a wrapper around dev_set_drvdata for the pcidev's struct device. - Using pci_get_drvdata() adds overhead (for humans only though, the compiler doesn't care and creates the same code) and having the pci device in the callback isn't necessary. My personal opinion is: The first is the graver layer violation because it relies on an implementation detail in the PCI framework. The latter is relying on a fact that is local to the driver only: All devices this driver is bound to are pci devices. The main benefit of explicitly using pci_get_drvdata ∘ to_pci_dev I see is that someone having only shallow knowledge of the PCI stuff can easier match a pci_get_drvdata() to the pci_set_drvdata() called in .probe() than a dev_get_drvdata() and so while it uses a function call/code line more, it is more explicit and more obviously correct. And regarding your argument about the matching API: I think the above code uses the matching API, that is make a pci_dev from a device using to_pci_dev(). So this is about weighting up- and downsides. How you judge them is subjective. (Though my judgement is naturally the better one :-) Just my 0.02€ Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
