netdev - Re: [PATCH net-next v2 1/2] net: phy: microchip: update LAN88xx phy ID and phy ID mask.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 27 Apr 2022 19:30:26 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Yuiko.Oshino@...rochip.com
Cc:     Woojung.Huh@...rochip.com, davem@...emloft.net,
        netdev@...r.kernel.org, Ravi.Hegde@...rochip.com,
        UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next v2 1/2] net: phy: microchip: update LAN88xx phy
 ID and phy ID mask.

> >> The current phy IDs on the available hardware.
> >>         LAN8742 0x0007C130, 0x0007C131
> >>         LAN88xx 0x0007C132
> >>
> >> Signed-off-by: Yuiko Oshino <yuiko.oshino@...rochip.com>
> >> ---
> >>  drivers/net/phy/microchip.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
> >> index 9f1f2b6c97d4..131caf659ed2 100644
> >> --- a/drivers/net/phy/microchip.c
> >> +++ b/drivers/net/phy/microchip.c
> >> @@ -344,8 +344,8 @@ static int lan88xx_config_aneg(struct phy_device
> >> *phydev)
> >>
> >>  static struct phy_driver microchip_phy_driver[] = {  {
> >> -     .phy_id         = 0x0007c130,
> >> -     .phy_id_mask    = 0xfffffff0,
> >> +     .phy_id         = 0x0007c132,
> >> +     .phy_id_mask    = 0xfffffff2,
> >
> >Just so my comment on the previous version does not get lost, is this the correct
> >mask, because it is very odd. I think you really want 0xfffffffe?
> >
> >    Andrew
> 
> Hi Andrew,
> 
> thank you for your review.
> Yes, 0xfffffff2 is correct for us.
> We would like to have bits for future revisions of the hardware without updating the driver source code in the future.
> If we use 0xfffffffe, then we need to submit a patch again when we have a new hardware revision.

This has some risks. Do you really have enough control over the
hardware people to say that:

LAN8742 0x0007C130, 0x0007C131, 0x0007C134, 0x0007C135, 0x0007C138, 0x0007C139, ...
LAN88xx 0x0007C132, 0x0007C133, 0x0007C136, 0x0007C137, 0x0007C13a, 0x0007C13b, ...

It seems safer to wait until there is new hardware and then update the
list given whatever they decide on is next.

At minimum, please add a comment in the code, otherwise you are going
to get asked, is this correct, it looks wrong?

     Andrew