Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1253401pxb; Thu, 4 Mar 2021 07:07:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/udKl7lYcun6qyjks7HXSbn+5h9NLxa2BfdsdzdzNmo1YmyWALDJdG3Km9nritjlNdvVe X-Received: by 2002:a17:906:3881:: with SMTP id q1mr4760822ejd.490.1614870473374; Thu, 04 Mar 2021 07:07:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614870473; cv=none; d=google.com; s=arc-20160816; b=tXrOFMeoBl0wIQ+uVDwTq4IyDZx6sgnuCeDLFX1IzdD327z17gG6Qc+GCd1NbkONIe MT9VarqmkcaRLovubCZzN1Bf0A4zdQR6aDoTGseENRt6eELiXwWquc14vXzGOI8xRIpw iSrFlZWA2HVCEqDuvCWYwIYTin8w4B+NaMKsnIpIx5Aig+W2jq/3DD0Dc/7lyDZvH7lj I5IQvBznzQxfOj3m5yyJTvNS3abnwpdUnInTi22iteMjuP4O2RqtUaoS60XQ8JXay97C 4VNwMFiejD/lxz8kTQwBTXs3AyANB19gQsMJNhjHIJVE/bVFy9LMZQwYjSWPGc/I7PHC U2ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=P0f+eYtATsSsjrMI9K7JVfhIQMfZEx2gHGl9xTr7UQQ=; b=eJuSfVGWOeWTSzhIwJ/fZ319DeMHAQOkghwyoMeYxrqDXmDti/4kLTsg2Nrta4Yadh dPe7cD6pnUMlpHdLKDCdTlEHqvvEsbIY3BVKQHlnbN1Op4Zq2QOA1YUE+StX5IC3EQFP YXHKSh4S4aqFuX2438lKK+58WnJpBJ8FKIpWMPGi6RNHokS9pyRSEhfKA/R0CLtpLDJo k+XRSBxTqXZMpTuG+M+bMybfOgdY5kZs9BgQFRojDdNI2zD8MqK/OM+Aj3BlwN3XK8yX XZfarM68daapkOy3HGpSkTw+xW/uyhl3SwMF3NMN2EyDfsrWbakuM1t2nIlfOVlf+P9T bKGw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a23si15862040ejx.146.2021.03.04.07.07.23; Thu, 04 Mar 2021 07:07:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234059AbhCDGI0 (ORCPT + 99 others); Thu, 4 Mar 2021 01:08:26 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:33745 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234042AbhCDGIM (ORCPT ); Thu, 4 Mar 2021 01:08:12 -0500 Received: from mail-lj1-f200.google.com ([209.85.208.200]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1lHh90-0005Hz-HA for linux-wireless@vger.kernel.org; Thu, 04 Mar 2021 06:07:30 +0000 Received: by mail-lj1-f200.google.com with SMTP id 6so3779538ljr.11 for ; Wed, 03 Mar 2021 22:07:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=P0f+eYtATsSsjrMI9K7JVfhIQMfZEx2gHGl9xTr7UQQ=; b=c+5GRDls8ioOSexuH10tJPktFFlNLAnhXAruodv+ePdNTcY//RC65cuw5hbri21nZ2 +mhaUnX8CwH41ay5gfhC+9zo9tym1fZNnHF2BKH9egmWPtjqnRw+29ugT8n5WCGnU4tL RiDQAYGtCSEtvu/AKRSIu+njM5ABCuOx710cwxvmaeE6PdReCMKg0G+3mERsDaWHsoeK 8ZSTo1IPgAqb/c+sZrG06Lr0BZW83FSJz9kePz/oKx2TVVC2t4ZKt3OrFv8yRqzX+nrF 3O3X8v/8k/K0vIhKid0fS/FkDpNlH8/0LNlAjSGxtFZy5ULGtmoAAl4tVruNf42NhnJl sUyg== X-Gm-Message-State: AOAM5314Jo4Z+6/Ph3vS/SN9T4cVDjLAcDtj3Fh1GXwM1iy1Sz/mC3Ss hNGsd69yKk/yRTkgt7lW/mu7H1VktgRJj1XBVjkyaxjR0yh4JnUs9AhBRHFnwSPZaXegeSNrciJ knhbn3CVF2og6R21+2KTmtVkMGkUEl34dXEFEPC5upMqDPAo1PKFkPy6DVQM6 X-Received: by 2002:a19:6d09:: with SMTP id i9mr1290805lfc.425.1614838049992; Wed, 03 Mar 2021 22:07:29 -0800 (PST) X-Received: by 2002:a19:6d09:: with SMTP id i9mr1290788lfc.425.1614838049726; Wed, 03 Mar 2021 22:07:29 -0800 (PST) MIME-Version: 1.0 References: <6db9e75e-52a7-4316-bfd8-cf44b4875f44@gmail.com> <20210226181656.GA143072@bjorn-Precision-5520> In-Reply-To: <20210226181656.GA143072@bjorn-Precision-5520> From: Kai-Heng Feng Date: Thu, 4 Mar 2021 14:07:18 +0800 Message-ID: Subject: Re: [PATCH 3/3] PCI: Convert rtw88 power cycle quirk to shutdown quirk To: Bjorn Helgaas Cc: Heiner Kallweit , Kalle Valo , Bjorn Helgaas , Yan-Hsuan Chuang , "David S. Miller" , Jakub Kicinski , linux-wireless , Linux Netdev List , open list , Linux PCI Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Sat, Feb 27, 2021 at 2:17 AM Bjorn Helgaas wrote: > > On Fri, Feb 26, 2021 at 02:31:31PM +0100, Heiner Kallweit wrote: > > On 26.02.2021 13:18, Kai-Heng Feng wrote: > > > On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit wrote: > > >> > > >> On 26.02.2021 08:12, Kalle Valo wrote: > > >>> Kai-Heng Feng writes: > > >>> > > >>>> Now we have a generic D3 shutdown quirk, so convert the original > > >>>> approach to a PCI quirk. > > >>>> > > >>>> Signed-off-by: Kai-Heng Feng > > >>>> --- > > >>>> 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 > > >> > > >> 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@linux.intel.com/ > > > > > > > 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. > > I haven't looked at these patches carefully, but in general, I agree > that quirks should be used to work around hardware defects in the > device. If the device behaves correctly per spec, we should use a > different mechanism so the code remains generic and all devices get > the benefit. > > If we do add quirks, the commit log should explain what the device > defect is. So maybe it's reasonable to put all PCI devices to D3 at shutdown? Kai-Heng > > Bjorn