Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2454691ybt; Tue, 16 Jun 2020 06:38:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYkAs2N3VBca43SAXJTxJbGAyV2SUJ90ioF1dIc+/Ucwaqgy2R16vvnyTseU0QuJa+5mr3 X-Received: by 2002:a17:906:945a:: with SMTP id z26mr2965103ejx.448.1592314686757; Tue, 16 Jun 2020 06:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592314686; cv=none; d=google.com; s=arc-20160816; b=niLFgqV50/4+UGa6E2vZ+C4884V57Av9jz+qW8MqII1qcoHVPoFrXcUY0aGms2q0Rn O6/YOgWusZcUVr+5Hv4Lwl5kryvlgEQc2lLaiO4iQmnYfD3DVNNkwaesfY5GkjDRU0Ot SMuWZm7LvxR+zOnnpD75VVWl8SRdlXX+aepjHjGpYfrZIb/zS6D9HuUFzkFZA81kjXWd BMFAfWGsybjwwiUwdSrPuxxPzGxzEnKfbVlspSfKoXRxT5d+83DyB41jORYUYq2yHCGX DtYlb0nlNnWDIYEsLh9aWqOZSjd7yVv78KhizQTJlzoT4a/n3MhNo1qQcqUdLS4sz1fP u6qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=seP+LZP2QTOajxxdp/NzIIGZaPlQCsYU+L6FVqklaFo=; b=PZCt9Wjpx6sM1Gyp8gBo7AsvyrFJqp3pdzIx4ecQ4PHpP+vDjNnuZMGenK45zjJG8T KgbvwSd2XGjoQU69rEXKsFtokRgIFnpAwoBh3+7HaLGbQuCSbxv9R22cbw0oxFrh+8Sf eEVZMIchfkJKze50nZry1IwADimXqIZanZjkOhy2yHbLoahaVPGQ6CFndNY3ZHn48bwX HcROj/lpcRIJh8jcH7wEEy8kmQWSuSIb9KFL1NqyNXDnbz8I2Oq6GK6XxnCyGGvcILjq zAAGbh03kMYr+B6gBYGcfMDN82GT90N2lm8TnmpOXfRemN5ujPp93gH5S7OH9PnFKXum PWsQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l20si11680938ejr.66.2020.06.16.06.37.42; Tue, 16 Jun 2020 06:38:06 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728549AbgFPNfo (ORCPT + 99 others); Tue, 16 Jun 2020 09:35:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726306AbgFPNfo (ORCPT ); Tue, 16 Jun 2020 09:35:44 -0400 Received: from Galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37483C061573 for ; Tue, 16 Jun 2020 06:35:44 -0700 (PDT) Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1jlBkR-0006Hx-LT; Tue, 16 Jun 2020 15:35:31 +0200 Date: Tue, 16 Jun 2020 15:35:31 +0200 From: Sebastian Andrzej Siewior To: Tony Chuang Cc: "kvalo@codeaurora.org" , "kernel@iuliancostan.com" , "linux-wireless@vger.kernel.org" , "i@outv.im" , "trevor@shartrec.com" Subject: Re: [PATCH v1] rtw88: pci: disable aspm for platform inter-op with module parameter Message-ID: <20200616133531.7eyfu6jniywhak7h@linutronix.de> References: <20200605074703.32726-1-yhchuang@realtek.com> <20200610213720.3sopcuimas375xl2@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On 2020-06-16 11:06:28 [+0000], Tony Chuang wrote: > > On 2020-06-05 15:47:03 [+0800], yhchuang@realtek.com wrote: > > > From: Yan-Hsuan Chuang > > > > > > Some platforms cannot read the DBI register successfully for the > > > ASPM settings. After the read failed, the bus could be unstable, > > > and the device just became unavailable [1]. For those platforms, > > > the ASPM should be disabled. But as the ASPM can help the driver > > > to save the power consumption in power save mode, the ASPM is still > > > needed. So, add a module parameter for them to disable it, then > > > the device can still work, while others can benefit from the less > > > power consumption that brings by ASPM enabled. > > > > Can you set disable_aspm if rtw_dbi_read8() fails? Or make a test if it > > is save to use? > > > > If someone notices the warning they still have to search for the warning > > in order to make the link towards loading the module with the > > disable_aspm=1 paramter. > > Is it known what causes the failure? > > > > I think as long as the rtw_dbi_read() fails, the consequent register > operation will also fail, and still get an error read/write the register. > And this is some sort of PCI issue, and I am not really familiar with it. > Such as the root cause or how it fails. Then it does not sound safe to enable it by default. > If we can default disable it, then we can help those platforms, but > then other platform will suffer from higher power consumption. So for those platform, where the error occurs, you expect that the user manages to read the error message (a backtrace from rtw_dbi_read8()) and connects this the need to set a certain module option. > Yen-Hsuan Sebastian