From: Kai-Heng Feng <kai.heng.feng@canonical.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Ryankao <ryankao@realtek.com>,
"jrg.otte@gmail.com" <jrg.otte@gmail.com>,
David Miller <davem@davemloft.net>,
Hayes Wang <hayeswang@realtek.com>,
"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
"romieu@fr.zoreil.com" <romieu@fr.zoreil.com>,
Linux Netdev List <netdev@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hau <hau@realtek.com>
Subject: Re: [PATCH] r8169: Reinstate ALDPS and ASPM support
Date: Wed, 6 Jun 2018 14:58:52 +0800 [thread overview]
Message-ID: <C2132983-62FC-4099-892D-DD9E5F6587FC@canonical.com> (raw)
In-Reply-To: <20180605172805.GD30381@bhelgaas-glaptop.roam.corp.google.com>
Hi, Bjorn,
at 01:28, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, Jun 05, 2018 at 06:34:09AM +0000, Ryankao wrote:
>> Add realtek folk Hau
>>
>> -----Original Message-----
>> From: Kai Heng Feng [mailto:kai.heng.feng@canonical.com]
>> Sent: Tuesday, June 05, 2018 1:02 PM
>> To: jrg.otte@gmail.com
>> Cc: David Miller <davem@davemloft.net>; Hayes Wang
>> <hayeswang@realtek.com>; hkallweit1@gmail.com; romieu@fr.zoreil.com;
>> Linux Netdev List <netdev@vger.kernel.org>; Linux Kernel Mailing List
>> <linux-kernel@vger.kernel.org>; Ryankao <ryankao@realtek.com>
>> Subject: Re: [PATCH] r8169: Reinstate ALDPS and ASPM support
>>
>> Hi Jörg Otte,
>>
>> Can you give this patch a try?
>>
>> Since you are the only one that reported ALDPS/ASPM regression,
>>
>> And I think this patch should solve the issue you had [1].
>>
>> Hopefully we don't need to go down the rabbit hole of
>> blacklist/whitelist...
>>
>> Kai-Heng
>>
>> [1] https://lkml.org/lkml/2013/1/5/36
>
> I have no idea what ALDPS is. It's not mentioned in the PCIe spec, so
> presumably it's some Realtek-specific thing. ASPM is a generic PCIe
> thing. Changes to these two things should be in separate patches so
> they don't get tangled up.
Sure, I'll split them in two. I'll also consult with Realtek to explain
what ALDPS actually does.
>
>>> On Jun 5, 2018, at 12:58 PM, Kai-Heng Feng
>>> <kai.heng.feng@canonical.com>
>>> wrote:
>>>
>>> This patch reinstate ALDPS and ASPM support on r8169.
>>>
>>> On some Intel platforms, ASPM support on r8169 is the key factor to
>>> let Package C-State achieve PC8. Without ASPM support, the deepest
>>> Package C-State can hit is PC3. PC8 can save additional ~3W in
>>> comparison with PC3.
>>>
>>> This patch is from Realtek.
>>>
>>> Fixes: e0c075577965 ("r8169: enable ALDPS for power saving")
>>> Fixes: d64ec841517a ("r8169: enable internal ASPM and clock request
>>> settings")
>
>>> +3507,15 @@ static void rtl8168e_1_hw_phy_config(struct
>>> rtl8169_private *tp)
>>> rtl_writephy(tp, 0x0d, 0x4007);
>>> rtl_writephy(tp, 0x0e, 0x0000);
>>> rtl_writephy(tp, 0x0d, 0x0000);
>>> +
>>> + /* Check ALDPS bit, disable it if enabled */
>>> + rtl_writephy(tp, 0x1f, 0x0000);
>>> + if (enable_aldps)
>>> + rtl_w0w1_phy(tp, 0x15, 0x1000, 0x0000);
>>> + else if (rtl_readphy(tp, 0x15) & 0x1000)
>>> + rtl_w0w1_phy(tp, 0x15, 0x0000, 0x1000);
>
> There's a lot of repetition of this code with minor variations. You
> could probably factor it out and make it more concise and more
> readable.
You are right. Will do.
>
>>> +static void rtl8169_check_link_status(struct net_device *dev,
>>> + struct rtl8169_private *tp) {
>>> + struct device *d = tp_to_dev(tp);
>>> +
>>> + if (tp->link_ok(tp)) {
>>> + rtl_link_chg_patch(tp);
>>> + /* This is to cancel a scheduled suspend if there's one. */
>>> + if (pm_request_resume(d))
>>> + _rtl_reset_work(tp);
>>> + netif_carrier_on(dev);
>>> + if (net_ratelimit())
>>> + netif_info(tp, ifup, dev, "link up\n");
>>> + } else {
>>> + netif_carrier_off(dev);
>>> + netif_info(tp, ifdown, dev, "link down\n");
>>> + pm_runtime_idle(d);
>>> + }
>>> +}
>
> This function apparently just got moved around without changing
> anything. That's fine, but the move should be in a separate patch to
> make the real changes easier to review.
It actually added a new condition to check the return value of
pm_request_resume().
It's probably a bogus check though. I'll ask Realtek why they did this.
>
>>> @@ -7649,8 +7757,12 @@ static int rtl_init_one(struct pci_dev *pdev,
>>> const struct pci_device_id *ent)
>>>
>>> /* disable ASPM completely as that cause random device stop working
>>> * problems as well as full system hangs for some PCIe devices users */
>>> - pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S | PCIE_LINK_STATE_L1 |
>>> - PCIE_LINK_STATE_CLKPM);
>>> + if (!enable_aspm) {
>>> + pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S |
>>> + PCIE_LINK_STATE_L1 |
>>> + PCIE_LINK_STATE_CLKPM);
>>> + netif_info(tp, probe, dev, "ASPM disabled\n");
>>> + }
>
> ASPM is a generic PCIe feature that should be configured by the PCI
> core without any help from the device driver.
>
> If code in the driver is needed, that means either the PCI core is
> doing it wrong and we should fix it there, or the device is broken and
> the driver is working around the erratum.
>
> If this is an erratum, you should include details about exactly what's
> broken and (ideally) a URL to the published erratum. Otherwise this
> is just unmaintainable black magic and likely to be broken by future
> ASPM changes in the PCI core.
>
> ASPM configuration is done by the PCI core before drivers are bound to
> the device. If you need device-specific workarounds, they should
> probably be in quirks so they're done before the core does that ASPM
> configuration.
You are right.
I think calling pci_disable_link_state() is unnecessary, I'll also consult
with Realtek about this.
I'll also do some testing and send a separate patch to remove
pci_disable_link_state() for -rc kernel to test if this is something really
needed.
Kai-Heng
>
>>> /* enable device (incl. PCI PM wakeup and hotplug setup) */
>>> rc = pcim_enable_device(pdev);
>>> --
>>> 2.17.0
>>
>> ------Please consider the environment before printing this e-mail.
next prev parent reply other threads:[~2018-06-06 7:00 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-05 4:58 [PATCH] r8169: Reinstate ALDPS and ASPM support Kai-Heng Feng
2018-06-05 5:02 ` Kai Heng Feng
2018-06-05 6:34 ` Ryankao
2018-06-05 17:28 ` Bjorn Helgaas
2018-06-05 19:11 ` Bjorn Helgaas
2018-06-05 19:17 ` Heiner Kallweit
2018-06-05 19:27 ` Florian Fainelli
2018-06-05 19:41 ` Heiner Kallweit
2018-06-05 19:24 ` Heiner Kallweit
2018-06-06 6:58 ` Kai-Heng Feng [this message]
2018-06-05 14:11 ` Andrew Lunn
2018-06-05 14:15 ` David Miller
2018-06-05 16:47 ` Florian Fainelli
2018-06-06 6:47 ` Kai-Heng Feng
2018-06-06 12:34 ` Andrew Lunn
2018-06-07 4:15 ` Kai Heng Feng
2018-06-05 19:13 ` Heiner Kallweit
2018-06-06 6:12 ` Simon Horman
2018-06-06 7:03 ` Kai-Heng Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C2132983-62FC-4099-892D-DD9E5F6587FC@canonical.com \
--to=kai.heng.feng@canonical.com \
--cc=davem@davemloft.net \
--cc=hau@realtek.com \
--cc=hayeswang@realtek.com \
--cc=helgaas@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=jrg.otte@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.com \
--cc=ryankao@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).