Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1719085 > unrolled thread

[PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic

Back to article view | Back to linux.kernel

Contents

  [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-24 11:50 +0200
    Re: [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval  logic David Miller <davem@davemloft.net> - 2017-08-25 06:50 +0200
      Re: [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval  logic Antoine Tenart <antoine.tenart@free-electrons.com> - 2017-08-25 16:00 +0200

#1719085 — [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic

Hi all,

The MAC address retrieval logic was broken and when using the PPv2
driver on PPv2.2 engines I ended up using the same mac address on all
ports. This series of patches fixes this, and also tackle a possible bug
when defining the mac address in the device tree.

To fix this in a nice way I ended up using a dedicated function to
handle the mac retrieval logic. This can be hard to backport into stable
kernels. This is why I also made a quick fix which is easy to backport
(patch 1/14), to tackle down the PPv2.2 mac retrieval bug. Let me know
if this approach is the proper way to handle this or if I should do
something else.

Thanks!
Antoine

Fixes: 2697582144dd ("net: mvpp2: handle misc PPv2.1/PPv2.2 differences")

Antoine Tenart (4):
  net: mvpp2: fix the mac address used when using PPv2.2
  net: mvpp2: move the mac retrieval/copy logic into its own function
  net: mvpp2: fix use of the random mac address for PPv2.2
  net: mvpp2: fallback using h/w and random mac if the dt one isn't
    valid

 drivers/net/ethernet/marvell/mvpp2.c | 48 ++++++++++++++++++++++--------------
 1 file changed, 30 insertions(+), 18 deletions(-)

-- 
2.13.5

[toc] | [next] | [standalone]

#1719745 — Re: [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic

From: Antoine Tenart <antoine.tenart@free-electrons.com>
Date: Thu, 24 Aug 2017 11:46:54 +0200

> The MAC address retrieval logic was broken and when using the PPv2
> driver on PPv2.2 engines I ended up using the same mac address on all
> ports. This series of patches fixes this, and also tackle a possible bug
> when defining the mac address in the device tree.
> 
> To fix this in a nice way I ended up using a dedicated function to
> handle the mac retrieval logic. This can be hard to backport into stable
> kernels. This is why I also made a quick fix which is easy to backport
> (patch 1/14), to tackle down the PPv2.2 mac retrieval bug. Let me know
> if this approach is the proper way to handle this or if I should do
> something else.

This patch series doesn't apply to any of my trees, that is the first
thing.

Secondly, this is a bug fix, and the bug exists in the 'net' tree.
Therefore this patch series should target the 'net' tree.

Please always target legitimate bug fixes at the 'net' tree, rather
than 'net-next'.

Thank you.

[toc] | [prev] | [next] | [standalone]

#1720085 — Re: [PATCH net-next 0/4] net: mvpp2: fix the mac address retrieval logic

[Multipart message — attachments visible in raw view] — view raw

Hi Dave,

On Thu, Aug 24, 2017 at 09:46:24PM -0700, David Miller wrote:
> From: Antoine Tenart <antoine.tenart@free-electrons.com>
> Date: Thu, 24 Aug 2017 11:46:54 +0200
> 
> > The MAC address retrieval logic was broken and when using the PPv2
> > driver on PPv2.2 engines I ended up using the same mac address on all
> > ports. This series of patches fixes this, and also tackle a possible bug
> > when defining the mac address in the device tree.
> > 
> > To fix this in a nice way I ended up using a dedicated function to
> > handle the mac retrieval logic. This can be hard to backport into stable
> > kernels. This is why I also made a quick fix which is easy to backport
> > (patch 1/14), to tackle down the PPv2.2 mac retrieval bug. Let me know
> > if this approach is the proper way to handle this or if I should do
> > something else.
> 
> This patch series doesn't apply to any of my trees, that is the first
> thing.

That is very strange, my patches were based on top of net-next. I'll
double check if they apply correctly before sending the v2.

> Secondly, this is a bug fix, and the bug exists in the 'net' tree.
> Therefore this patch series should target the 'net' tree.

OK, that's the question I was asking. I'll resent everything to net
then.

> Please always target legitimate bug fixes at the 'net' tree, rather
> than 'net-next'.

Sure, will do.

Thanks!
Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web