Hi Andy, > > Nice find! There might one more driver that leverages the vendor-specific > > capabilities that seems to be also open coding pci_find_vsec_capability(), > > as per: > > ... > > Do you think that it would be worthwhile to also update this other driver > > to use pci_find_vsec_capability() at the same time? I might be nice to rid > > of the other open coded implementation too. > > You mean https://lore.kernel.org/linux-fpga/20211109154127.18455-1-andriy.shevchenko@xxxxxxxxxxxxxxx/T/#u? Ohh! Thank you for doing it! Sorry for mentioning it twice then, I wasn't aware of the conversation there on the other mailing list. > It seems a bit hard to explain HW people how the Linux kernel development > process is working. (Yes, shame on me that I haven't compiled that one) I see what you mean... (after reading the linked conversation). > > > Currently the set_pcie_thunderbolt() opens code pci_find_vsec_capability(). > > > > I would write it as "open codes" in the above. > > Hmm... Is anybody among us a native speaker (me — no)? :-) Admittedly, neither am I, so hopefully Bjorn (or other native speaker) can chime in. Albeit, it's probably not worth spending a lot of time over. > But if you think it's better like this I'll definitely change. > (I admit I'm lost in a morphological analysis of the above two > words) Sorry about that! It was simple something I noticed while reading the commit messaged - looked somewhat different than the usual to my unskilled and untrained eyes. Krzysztof
