From: Andre Edich <hidden> Date: 2021-03-29 09:46:45
The function lan87xx_config_aneg_ext was introduced to configure
LAN95xxA but as well writes to undocumented register of LAN87xx.
This fix prevents that access.
The function lan87xx_config_aneg_ext gets more suitable for the new
behavior name.
Reported-by: Måns Rullgård <redacted>
Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
Signed-off-by: Andre Edich <redacted>
---
drivers/net/phy/smsc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
The function lan87xx_config_aneg_ext was introduced to configure
LAN95xxA but as well writes to undocumented register of LAN87xx.
This fix prevents that access.
The function lan87xx_config_aneg_ext gets more suitable for the new
behavior name.
Reported-by: Måns Rullgård <redacted>
Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
Signed-off-by: Andre Edich <redacted>
---
drivers/net/phy/smsc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
This seems to differentiate based on the "revision" field of the ID
register. Can we be certain that a future update of chip won't break
this assumption?
--
Måns Rullgård
On Mon, 2021-03-29 at 12:19 +0100, Måns Rullgård wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know
the content is safe
Andre Edich [off-list ref] writes:
quoted
The function lan87xx_config_aneg_ext was introduced to configure
LAN95xxA but as well writes to undocumented register of LAN87xx.
This fix prevents that access.
The function lan87xx_config_aneg_ext gets more suitable for the new
behavior name.
Reported-by: Måns Rullgård <redacted>
Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
Signed-off-by: Andre Edich <redacted>
---
drivers/net/phy/smsc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
This seems to differentiate based on the "revision" field of the ID
register. Can we be certain that a future update of chip won't break
this assumption?
The way to fail would be to "fix" and release any of LAN95xxA in the
way that the register map will is changed or feature is disabled but
the Phy ID remains the same. This is very unlikely and obviously
wrong. I don't believe this may happen.
If a new chip with the different Phy ID but the same feature will be
released, then it must be explicitly added into the table.
Is there a third case I don't see?
--
Regards,
Andre
On Mon, 2021-03-29 at 12:19 +0100, Måns Rullgård wrote:
quoted
EXTERNAL EMAIL: Do not click links or open attachments unless you know
the content is safe
Andre Edich [off-list ref] writes:
quoted
The function lan87xx_config_aneg_ext was introduced to configure
LAN95xxA but as well writes to undocumented register of LAN87xx.
This fix prevents that access.
The function lan87xx_config_aneg_ext gets more suitable for the new
behavior name.
Reported-by: Måns Rullgård <redacted>
Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
Signed-off-by: Andre Edich <redacted>
---
drivers/net/phy/smsc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
This seems to differentiate based on the "revision" field of the ID
register. Can we be certain that a future update of chip won't break
this assumption?
The way to fail would be to "fix" and release any of LAN95xxA in the
way that the register map will is changed or feature is disabled but
the Phy ID remains the same. This is very unlikely and obviously
wrong. I don't believe this may happen.
If a new chip with the different Phy ID but the same feature will be
released, then it must be explicitly added into the table.
Is there a third case I don't see?
I was thinking that an updated LAN9500A might get the revision field set
to 1, making it indistinguishable from a LAN8710A. That wouldn't break
anything as such, but that bit wouldn't get set either. It seems
unlikely that this will ever happen, though, and it if it does, it can
be dealt with then.
Some rummaging in my boxes of old boards turned up both A and B
revisions of the LAN8720A, and they both have the same ID register value
(0xc0f1). I had wondered if the A version might have had the revision
field set to 0, but apparently not.
--
Måns Rullgård
The function lan87xx_config_aneg_ext was introduced to configure
LAN95xxA but as well writes to undocumented register of LAN87xx.
This fix prevents that access.
The function lan87xx_config_aneg_ext gets more suitable for the new
behavior name.
Reported-by: Måns Rullgård <redacted>
Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support")
Signed-off-by: Andre Edich <redacted>
---
drivers/net/phy/smsc.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
I can confirm that this fixes the problem I was seeing.
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Mon, 29 Mar 2021 11:45:36 +0200 you wrote:
The function lan87xx_config_aneg_ext was introduced to configure
LAN95xxA but as well writes to undocumented register of LAN87xx.
This fix prevents that access.
The function lan87xx_config_aneg_ext gets more suitable for the new
behavior name.
[...]