From: Jeroen Hofstee <[email protected]>
Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
id to common file") did not only move the code for an am3517, it also
added the slave parameter, resulting in an invalid (all zero) mac address
being returned for an am3517, since it only has a single emac and the slave
parameter is pointing to the second. So simply always read the first and
valid mac-address.
Signed-off-by: Jeroen Hofstee <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
---
drivers/net/ethernet/ti/cpsw-common.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw-common.c b/drivers/net/ethernet/ti/cpsw-common.c
index bfa81bbfce3f..465dc15f059d 100644
--- a/drivers/net/ethernet/ti/cpsw-common.c
+++ b/drivers/net/ethernet/ti/cpsw-common.c
@@ -74,8 +74,12 @@ int ti_cm_get_macid(struct device *dev, int slave, u8 *mac_addr)
if (of_machine_is_compatible("ti,am33xx"))
return cpsw_am33xx_cm_get_macid(dev, 0x630, slave, mac_addr);
+ /*
+ * There is only one emac / mac address on an am3517 so ignore the
+ * slave = 1 and always get the macid from slave 0.
+ */
if (of_device_is_compatible(dev->of_node, "ti,am3517-emac"))
- return davinci_emac_3517_get_macid(dev, 0x110, slave, mac_addr);
+ return davinci_emac_3517_get_macid(dev, 0x110, 0, mac_addr);
if (of_device_is_compatible(dev->of_node, "ti,dm816-emac"))
return cpsw_am33xx_cm_get_macid(dev, 0x30, slave, mac_addr);
--
2.41.0
On Sat, Jun 24, 2023 at 01:10:59PM +0100, Mans Rullgard wrote:
> From: Jeroen Hofstee <[email protected]>
>
> Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
> id to common file") did not only move the code for an am3517, it also
> added the slave parameter, resulting in an invalid (all zero) mac address
> being returned for an am3517, since it only has a single emac
Hi Mans
If there is only a single emac, why is the function being called with
slave=1? Given the description, it seems like you are fixing the wrong
problem.
Andrew
Andrew Lunn <[email protected]> writes:
> On Sat, Jun 24, 2023 at 03:24:47PM +0100, M?ns Rullg?rd wrote:
>> Andrew Lunn <[email protected]> writes:
>>
>> > On Sat, Jun 24, 2023 at 01:10:59PM +0100, Mans Rullgard wrote:
>> >> From: Jeroen Hofstee <[email protected]>
>> >>
>> >> Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
>> >> id to common file") did not only move the code for an am3517, it also
>> >> added the slave parameter, resulting in an invalid (all zero) mac address
>> >> being returned for an am3517, since it only has a single emac
>> >
>> > Hi Mans
>> >
>> > If there is only a single emac, why is the function being called with
>> > slave=1? Given the description, it seems like you are fixing the wrong
>> > problem.
>>
>> See previous discussion:
>> https://lore.kernel.org/lkml/[email protected]/
>
> Hi M?ns
>
> O.K. did i mention memory of a goldfish?
>
> This is the sort of detail that should be in the commit
> message. Otherwise reviewers are going to ask for an explanation, even
> if it has been explained once, 6 years ago.
>
> I assume you also want this back ported to stable? Please add a Fixed:
> tag, and a Cc: [email protected] tag. And set the patch subject
> to [PATCH net v3] to indicate this is for the net tree, not net-next.
I give up. It's not worth my time. This is why people hoard patches
rather than sending them upstream.
--
M?ns Rullg?rd
Andrew Lunn <[email protected]> writes:
> On Sat, Jun 24, 2023 at 01:10:59PM +0100, Mans Rullgard wrote:
>> From: Jeroen Hofstee <[email protected]>
>>
>> Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
>> id to common file") did not only move the code for an am3517, it also
>> added the slave parameter, resulting in an invalid (all zero) mac address
>> being returned for an am3517, since it only has a single emac
>
> Hi Mans
>
> If there is only a single emac, why is the function being called with
> slave=1? Given the description, it seems like you are fixing the wrong
> problem.
See previous discussion:
https://lore.kernel.org/lkml/[email protected]/
--
M?ns Rullg?rd
On Sat, Jun 24, 2023 at 03:24:47PM +0100, M?ns Rullg?rd wrote:
> Andrew Lunn <[email protected]> writes:
>
> > On Sat, Jun 24, 2023 at 01:10:59PM +0100, Mans Rullgard wrote:
> >> From: Jeroen Hofstee <[email protected]>
> >>
> >> Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac
> >> id to common file") did not only move the code for an am3517, it also
> >> added the slave parameter, resulting in an invalid (all zero) mac address
> >> being returned for an am3517, since it only has a single emac
> >
> > Hi Mans
> >
> > If there is only a single emac, why is the function being called with
> > slave=1? Given the description, it seems like you are fixing the wrong
> > problem.
>
> See previous discussion:
> https://lore.kernel.org/lkml/[email protected]/
Hi M?ns
O.K. did i mention memory of a goldfish?
This is the sort of detail that should be in the commit
message. Otherwise reviewers are going to ask for an explanation, even
if it has been explained once, 6 years ago.
I assume you also want this back ported to stable? Please add a Fixed:
tag, and a Cc: [email protected] tag. And set the patch subject
to [PATCH net v3] to indicate this is for the net tree, not net-next.
Thanks
Andrew
Hi,
* Måns Rullgård <[email protected]> [230624 14:36]:
> Andrew Lunn <[email protected]> writes:
> > I assume you also want this back ported to stable? Please add a Fixed:
> > tag, and a Cc: [email protected] tag. And set the patch subject
> > to [PATCH net v3] to indicate this is for the net tree, not net-next.
>
> I give up. It's not worth my time. This is why people hoard patches
> rather than sending them upstream.
Maybe just give it one more go filing the proper paperwork :) It would be
nice to have it in stable too so IMO it's worth the few more hoops to
addthe tags for automating picking it to stable kernels.
Regards,
Tony