On Mon, 14 Jun 2021 11:37:22 +0200 Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > 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 :-) Personally I'm happy with either dev_set_drvdata / dev_get_drvdata or pci_set_drvdata / pci_get_drvdata In this particular case there is a convenient struct device *dev local variable anyway in the probe() (IIRC) so could have done option 1 with no loss of readability and a tiny saving in code. Not worth changing it though is my 0.02€ Jonathan > > Just my 0.02€ > Uwe >
