On Mon, Jun 14, 2021 at 1:45 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > 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: ... > > > > >> - 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. As I said this is unflexible. For example, we have quite a few drivers that split in the way of core part (as library) + glue driver(s) How to implement callbacks that will use the same pairs of the callbacks? I don't think it's possible in a good and neat way. On top of that I think using the knowledge of the device nature in the generic callbacks _is_ a layering violation. TL;DR: the simple rule of thumb may be: if the callback uses struct device, that dev_get_drvdata(), otherwise based on what you have got as a parameter. Does it make sense? > Not worth changing it though is my 0.02€ -- With Best Regards, Andy Shevchenko
