netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hau <hau@realtek.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	nic_swsd <nic_swsd@realtek.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"grundler@chromium.org" <grundler@chromium.org>
Subject: RE: [PATCH net] r8169: fix rtl8125b dmar pte write access not set error
Date: Thu, 20 Oct 2022 18:01:48 +0000	[thread overview]
Message-ID: <e7b7241fdb7c4cde80811ca5b588e17e@realtek.com> (raw)
In-Reply-To: <465b96bf-0eff-8e5c-433d-3571114058e6@gmail.com>

> On 17.10.2022 19:23, Hau wrote:
> >> On 13.10.2022 08:04, Hau wrote:
> >>>> On 12.10.2022 09:59, Hau wrote:
> >>>>>>
> >>>>>> On 04.10.2022 10:10, Chunhao Lin wrote:
> >>>>>>> When close device, rx will be enabled if wol is enabeld. When
> >>>>>>> open device it will cause rx to dma to wrong address after
> pci_set_master().
> >>>>>>>
> >>>>>>> In this patch, driver will disable tx/rx when close device. If
> >>>>>>> wol is eanbled only enable rx filter and disable rxdv_gate to
> >>>>>>> let hardware can receive packet to fifo but not to dma it.
> >>>>>>>
> >>>>>>> Fixes: 120068481405 ("r8169: fix failing WoL")
> >>>>>>> Signed-off-by: Chunhao Lin <hau@realtek.com>
> >>>>>>> ---
> >>>>>>>  drivers/net/ethernet/realtek/r8169_main.c | 14 +++++++-------
> >>>>>>>  1 file changed, 7 insertions(+), 7 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/net/ethernet/realtek/r8169_main.c
> >>>>>>> b/drivers/net/ethernet/realtek/r8169_main.c
> >>>>>>> index 1b7fdb4f056b..c09cfbe1d3f0 100644
> >>>>>>> --- a/drivers/net/ethernet/realtek/r8169_main.c
> >>>>>>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> >>>>>>> @@ -2239,6 +2239,9 @@ static void rtl_wol_enable_rx(struct
> >>>>>> rtl8169_private *tp)
> >>>>>>>  	if (tp->mac_version >= RTL_GIGA_MAC_VER_25)
> >>>>>>>  		RTL_W32(tp, RxConfig, RTL_R32(tp, RxConfig) |
> >>>>>>>  			AcceptBroadcast | AcceptMulticast |
> AcceptMyPhys);
> >>>>>>> +
> >>>>>>> +	if (tp->mac_version >= RTL_GIGA_MAC_VER_40)
> >>>>>>> +		RTL_W32(tp, MISC, RTL_R32(tp, MISC) &
> >> ~RXDV_GATED_EN);
> >>>>>>
> >>>>>> Is this correct anyway? Supposedly you want to set this bit to
> >>>>>> disable
> >> DMA.
> >>>>>>
> >>>>> If wol is enabled, driver need to disable hardware rxdv_gate for
> >>>>> receiving
> >>>> packets.
> >>>>>
> >>>> OK, I see. But why disable it here? I see no scenario where
> >>>> rxdv_gate would be enabled when we get here.
> >>>>
> >>> rxdv_gate will be enabled in rtl8169_cleanup(). When suspend or
> >>> close and wol is enabled driver will call rtl8169_down() ->
> >>> rtl8169_cleanup()->
> >> rtl_prepare_power_down()-> rtl_wol_enable_rx().
> >>> So disabled rxdv_gate in rtl_wol_enable_rx() for receiving packets.
> >>>
> >> rtl8169_cleanup() skips the call to rtl_enable_rxdvgate() when being
> >> called from
> >> rtl8169_down() and wol is enabled. This means rxdv gate is still disabled.
> >>
> > Yes, it will keep rxdv_gate disable. But it will also keep tx/rx on.
> > If OS have an  unexpected reboot hardware  may dma to invalid memory
> > address. If possible I prefer to keep tx/rx off when exit driver control.
> >
> 
> When you say "keep tx/rx off", do you refer to the rxconfig bits in register
> RxConfig, or to CmdTxEnb and CmdRxEnb in ChipCmd?
> 
> If we talk about the first option, then my guess would be:
> According to rtl_wol_enable_rx() the rx config bits are required for WoL to
> work on certain chip versions. With the introduction of rxdvgate this changed
> and setting these bits isn't needed any longer.
> I tested on RTL8168h and WoL worked w/o the Accept bits set in RxConfig.
> Please confirm or correct my understanding.
> 
> static void rtl_wol_enable_rx(struct rtl8169_private *tp) {
> 	if (tp->mac_version >= RTL_GIGA_MAC_VER_25)
> 		RTL_W32(tp, RxConfig, RTL_R32(tp, RxConfig) |
> 			AcceptBroadcast | AcceptMulticast |
> AcceptMyPhys); }
> 
> 
We expect wol  packet should be filtered by Accept bits set in RxConfig. 
But for magic packet wakeup it seems it does not perform as expected. 
We need some time to figure this out. Once we have any update we will let you know.

 ------Please consider the environment before printing this e-mail.

  reply	other threads:[~2022-10-20 18:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04  8:10 [PATCH net] r8169: fix rtl8125b dmar pte write access not set error Chunhao Lin
2022-10-04 20:14 ` Heiner Kallweit
2022-10-05  5:44   ` Hau
2022-10-05 16:29 ` Heiner Kallweit
2022-10-06 14:23   ` Hau
2022-10-08 21:53 ` Heiner Kallweit
2022-10-09  7:45 ` Heiner Kallweit
2022-10-12  7:59   ` Hau
2022-10-12 19:33     ` Heiner Kallweit
2022-10-13  6:04       ` Hau
2022-10-15  8:18         ` Heiner Kallweit
2022-10-17 17:23           ` Hau
2022-10-17 19:38             ` Heiner Kallweit
2022-10-20 18:01               ` Hau [this message]
2022-10-24 18:02               ` Hau

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=e7b7241fdb7c4cde80811ca5b588e17e@realtek.com \
    --to=hau@realtek.com \
    --cc=grundler@chromium.org \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nic_swsd@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).