linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ruinskiy, Dima" <dima.ruinskiy@intel.com>
To: Aaron Ma <aaron.ma@canonical.com>,
	"Neftin, Sasha" <sasha.neftin@intel.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>,
	"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: Wed, 14 Jul 2021 12:13:25 +0300	[thread overview]
Message-ID: <20daa122-aaec-0c6b-23f5-d2be2fcab1e9@intel.com> (raw)
In-Reply-To: <1a539d4d-10b4-5b9b-31e7-6aec57120356@canonical.com>

Hello, Aaron, Sasha,

On 13/07/2021 16:45, Aaron Ma wrote:
> 
> On 7/8/21 12:24 PM, Neftin, Sasha wrote:
>> 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
> 
> Updating MAC addr may work.
> Even at the end of probe, it still got the wrong MAC address, delay is 
> still needed.
> 
> Aaron
> 
>> 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.

There is an interrupt which the FW can issue to the driver to indicate 
that MAC address has been changed. At that point the driver can update 
the MAC in its internal structures.

The important question is - is there away to update the OS structures at 
that point so that the MAC address change propagates through all the 
network stack. Some network stacks do not support such an update, except 
during device initialization (probe), so in such environments a delay is 
the only workaround, and it is a problematic one as we know.

If we find a mechanism by which the device driver can tell the Linux 
network stack - "My MAC address has changed; please update it", we can 
implement it differently, and not need this delay. Who can help us with 
this inquiry?

Thanks,
--Dima
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

  reply	other threads:[~2021-07-14  9:14 UTC|newest]

Thread overview: 27+ 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 ` [PATCH 2/2] igc: wait for the MAC copy when enabled MAC passthrough Aaron Ma
2021-07-04  5:36   ` [Intel-wired-lan] " Neftin, Sasha
2021-07-05  7:38     ` Aaron Ma
2021-07-05 11:54       ` Neftin, Sasha
2021-07-06  6:46         ` Aaron Ma
2021-07-08  4:24           ` Neftin, Sasha
2021-07-13 13:45             ` Aaron Ma
2021-07-14  9:13               ` Ruinskiy, Dima [this message]
2021-07-04 14:28 ` [PATCH 1/2] igc: don't rd/wr iomem when PCI is removed Pali Rohár
2021-07-05  7:23   ` Aaron Ma
2021-07-05 23:02   ` Krzysztof Wilczyński
2021-07-06 14:23     ` Pali Rohár
2021-07-05  7:47 ` Dave Airlie
2021-07-06  6:42   ` Aaron Ma
2021-07-06 20:12 ` Bjorn Helgaas
2021-07-07 21:53   ` Pali Rohár
2021-07-07 22:10     ` Bjorn Helgaas
2021-07-08  2:04       ` Oliver O'Halloran
2021-07-08 15:45         ` Bjorn Helgaas
2021-07-18 16:31           ` Oliver O'Halloran
2021-07-18 22:50             ` Pali Rohár
2021-07-19  2:49               ` Oliver O'Halloran
2021-07-19  8:13                 ` Pali Rohár
2021-07-20  0:17                 ` Bjorn Helgaas
2021-07-13 13:00 ` [PATCH v2] igc: fix page fault when thunderbolt is unplugged Aaron Ma
2021-08-04 12:06   ` [Intel-wired-lan] " 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=20daa122-aaec-0c6b-23f5-d2be2fcab1e9@intel.com \
    --to=dima.ruinskiy@intel.com \
    --cc=aaron.ma@canonical.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=avi.shalev@intel.com \
    --cc=davem@davemloft.net \
    --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 \
    --cc=sasha.neftin@intel.com \
    --subject='Re: [Intel-wired-lan] [PATCH 2/2] igc: wait for the MAC copy when enabled MAC passthrough' \
    /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

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).