From: "Neftin, Sasha" <sasha.neftin@intel.com>
To: Aaron Ma <aaron.ma@canonical.com>,
jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com,
davem@davemloft.net, kuba@kernel.org,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, "Edri,
Michael" <michael.edri@intel.com>,
"Ruinskiy, Dima" <dima.ruinskiy@intel.com>,
"Shalev, Avi" <avi.shalev@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH 2/2] igc: wait for the MAC copy when enabled MAC passthrough
Date: Thu, 8 Jul 2021 07:24:35 +0300 [thread overview]
Message-ID: <47117935-10d6-98e0-5894-ba104912ce25@intel.com> (raw)
In-Reply-To: <96106dfe-9844-1d9d-d865-619d78a0d150@canonical.com>
On 7/6/2021 09:46, Aaron Ma wrote:
>
> On 7/5/21 7:54 PM, Neftin, Sasha wrote:
>> Hello Aaron, Thanks to point me on this document. I see... This is
>> recommendation for Windows driver. Anyway, "delay" approach is
>> error-prone. We need rather ask for MNG FW confirmation (message) that
>> MAC address is copied.
>> Can we call (in case we know that MNG FW copied MAC address):
>> igc_rar_set (method from igc_mac.c), update the mac.addr and then
>> perform": memcpy(netdev->dev_addr, hw->mac.addr, netdev->addr_len);?
>
> Without delay, after igc_rar_set, the MAC address is all 0.
> The MAC addr is the from dock instead of MAC passthrough with the
> original driver.
I would to like suggest checking the following direction:
1. principal question: can we update the netdev device address after it
is already set during probe? I meant perform another:
memcpy(netdev->dev_addr, hw->mac.addr, netdev->addr_len) up to demand
2. We need to work with Intel's firmware engineer/group and define the
message/event: MAC addressis changed and should be updated.
As I know MNG FW updates shadow registers. Since shadow registers are
different from RAL/RAH registers - it could be a notification that the
MAC address changed. Let's check it.
>
> Thanks,
> Aaron
WARNING: multiple messages have this Message-ID (diff)
From: Neftin, Sasha <sasha.neftin@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH 2/2] igc: wait for the MAC copy when enabled MAC passthrough
Date: Thu, 8 Jul 2021 07:24:35 +0300 [thread overview]
Message-ID: <47117935-10d6-98e0-5894-ba104912ce25@intel.com> (raw)
In-Reply-To: <96106dfe-9844-1d9d-d865-619d78a0d150@canonical.com>
On 7/6/2021 09:46, Aaron Ma wrote:
>
> On 7/5/21 7:54 PM, Neftin, Sasha wrote:
>> Hello Aaron, Thanks to point me on this document. I see... This is
>> recommendation for Windows driver. Anyway, "delay" approach is
>> error-prone. We need rather ask for MNG FW confirmation (message) that
>> MAC?address?is?copied.
>> Can?we?call?(in?case?we?know?that?MNG?FW?copied?MAC?address):
>> igc_rar_set (method from igc_mac.c), update the mac.addr and then
>> perform":?memcpy(netdev->dev_addr,?hw->mac.addr,?netdev->addr_len);?
>
> Without delay, after igc_rar_set, the MAC address is all 0.
> The MAC addr is the from dock instead of MAC passthrough with the
> original driver.
I would to like suggest checking the following direction:
1. principal question: can we update the netdev device address after it
is already set during probe? I meant perform another:
memcpy(netdev->dev_addr, hw->mac.addr, netdev->addr_len) up to demand
2. We need to work with Intel's firmware engineer/group and define the
message/event: MAC addressis changed and should be updated.
As I know MNG FW updates shadow registers. Since shadow registers are
different from RAL/RAH registers - it could be a notification that the
MAC address changed. Let's check it.
>
> Thanks,
> Aaron
next prev parent reply other threads:[~2021-07-08 4:24 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 4:51 [PATCH 1/2] igc: don't rd/wr iomem when PCI is removed Aaron Ma
2021-07-02 4:51 ` [Intel-wired-lan] " Aaron Ma
2021-07-02 4:51 ` [PATCH 2/2] igc: wait for the MAC copy when enabled MAC passthrough Aaron Ma
2021-07-02 4:51 ` [Intel-wired-lan] " Aaron Ma
2021-07-04 5:36 ` Neftin, Sasha
2021-07-04 5:36 ` Neftin, Sasha
2021-07-05 7:38 ` Aaron Ma
2021-07-05 7:38 ` Aaron Ma
2021-07-05 11:54 ` Neftin, Sasha
2021-07-05 11:54 ` Neftin, Sasha
2021-07-06 6:46 ` Aaron Ma
2021-07-06 6:46 ` Aaron Ma
2021-07-08 4:24 ` Neftin, Sasha [this message]
2021-07-08 4:24 ` Neftin, Sasha
2021-07-13 13:45 ` Aaron Ma
2021-07-13 13:45 ` Aaron Ma
2021-07-14 9:13 ` Ruinskiy, Dima
2021-07-14 9:13 ` Ruinskiy, Dima
2021-07-04 14:28 ` [PATCH 1/2] igc: don't rd/wr iomem when PCI is removed Pali Rohár
2021-07-04 14:28 ` [Intel-wired-lan] " Pali =?unknown-8bit?q?Roh=C3=A1r?=
2021-07-05 7:23 ` Aaron Ma
2021-07-05 7:23 ` [Intel-wired-lan] " Aaron Ma
2021-07-05 23:02 ` Krzysztof Wilczyński
2021-07-05 23:02 ` [Intel-wired-lan] " Krzysztof =?unknown-8bit?q?Wilczy=C5=84ski?=
2021-07-06 14:23 ` Pali Rohár
2021-07-06 14:23 ` [Intel-wired-lan] " Pali =?unknown-8bit?q?Roh=C3=A1r?=
2021-07-05 7:47 ` Dave Airlie
2021-07-05 7:47 ` [Intel-wired-lan] " Dave Airlie
2021-07-06 6:42 ` Aaron Ma
2021-07-06 6:42 ` [Intel-wired-lan] " Aaron Ma
2021-07-06 20:12 ` Bjorn Helgaas
2021-07-06 20:12 ` [Intel-wired-lan] " Bjorn Helgaas
2021-07-07 21:53 ` Pali Rohár
2021-07-07 21:53 ` [Intel-wired-lan] " Pali =?unknown-8bit?q?Roh=C3=A1r?=
2021-07-07 22:10 ` Bjorn Helgaas
2021-07-07 22:10 ` [Intel-wired-lan] " Bjorn Helgaas
2021-07-08 2:04 ` Oliver O'Halloran
2021-07-08 2:04 ` [Intel-wired-lan] " Oliver O'Halloran
2021-07-08 15:45 ` Bjorn Helgaas
2021-07-08 15:45 ` [Intel-wired-lan] " Bjorn Helgaas
2021-07-18 16:31 ` Oliver O'Halloran
2021-07-18 16:31 ` [Intel-wired-lan] " Oliver O'Halloran
2021-07-18 22:50 ` Pali Rohár
2021-07-18 22:50 ` [Intel-wired-lan] " Pali =?unknown-8bit?q?Roh=C3=A1r?=
2021-07-19 2:49 ` Oliver O'Halloran
2021-07-19 2:49 ` [Intel-wired-lan] " Oliver O'Halloran
2021-07-19 8:13 ` Pali Rohár
2021-07-19 8:13 ` [Intel-wired-lan] " Pali =?unknown-8bit?q?Roh=C3=A1r?=
2021-07-20 0:17 ` Bjorn Helgaas
2021-07-20 0:17 ` [Intel-wired-lan] " Bjorn Helgaas
2021-07-13 13:00 ` [PATCH v2] igc: fix page fault when thunderbolt is unplugged Aaron Ma
2021-07-13 13:00 ` [Intel-wired-lan] " Aaron Ma
2021-08-04 12:06 ` Fuxbrumer, Dvora
2021-08-04 12:06 ` Fuxbrumer, Dvora
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=47117935-10d6-98e0-5894-ba104912ce25@intel.com \
--to=sasha.neftin@intel.com \
--cc=aaron.ma@canonical.com \
--cc=anthony.l.nguyen@intel.com \
--cc=avi.shalev@intel.com \
--cc=davem@davemloft.net \
--cc=dima.ruinskiy@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.edri@intel.com \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.