Re: [PATCH 3/3] PCI: Convert rtw88 power cycle quirk to shutdown quirk

From: Heiner Kallweit
Date: Fri Feb 26 2021 - 08:32:52 EST


On 26.02.2021 13:18, Kai-Heng Feng wrote:
> On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit <hkallweit1@xxxxxxxxx> wrote:
>>
>> On 26.02.2021 08:12, Kalle Valo wrote:
>>> Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx> writes:
>>>
>>>> Now we have a generic D3 shutdown quirk, so convert the original
>>>> approach to a PCI quirk.
>>>>
>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@xxxxxxxxxxxxx>
>>>> ---
>>>> drivers/net/wireless/realtek/rtw88/pci.c | 2 --
>>>> drivers/pci/quirks.c | 6 ++++++
>>>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>>
>>> It would have been nice to CC linux-wireless also on patches 1-2. I only
>>> saw patch 3 and had to search the rest of patches from lkml.
>>>
>>> I assume this goes via the PCI tree so:
>>>
>>> Acked-by: Kalle Valo <kvalo@xxxxxxxxxxxxxx>
>>>
>>
>> To me it looks odd to (mis-)use the quirk mechanism to set a device
>> to D3cold on shutdown. As I see it the quirk mechanism is used to work
>> around certain device misbehavior. And setting a device to a D3
>> state on shutdown is a normal activity, and the shutdown() callback
>> seems to be a good place for it.
>> I miss an explanation what the actual benefit of the change is.
>
> To make putting device to D3 more generic, as there are more than one
> device need the quirk.
>
> Here's the discussion:
> https://lore.kernel.org/linux-usb/00de6927-3fa6-a9a3-2d65-2b4d4e8f0012@xxxxxxxxxxxxxxx/
>

Thanks for the link. For the AMD USB use case I don't have a strong opinion,
what's considered the better option may be a question of personal taste.
For rtw88 however I'd still consider it over-engineering to replace a simple
call to pci_set_power_state() with a PCI quirk.
I may be biased here because I find it sometimes bothering if I want to
look up how a device is handled and in addition to checking the respective
driver I also have to grep through quirks.c whether there's any special
handling.

> Kai-Heng
>
Heiner