[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CH0PR11MB5561E9C01C5500D6301E43728EFA9@CH0PR11MB5561.namprd11.prod.outlook.com>
Date: Wed, 27 Apr 2022 16:02:56 +0000
From: <Yuiko.Oshino@...rochip.com>
To: <andrew@...n.ch>
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.
>-----Original Message-----
>From: Andrew Lunn <andrew@...n.ch>
>Sent: Wednesday, April 27, 2022 11:37 AM
>To: Yuiko Oshino - C18177 <Yuiko.Oshino@...rochip.com>
>Cc: Woojung Huh - C21699 <Woojung.Huh@...rochip.com>;
>davem@...emloft.net; netdev@...r.kernel.org; Ravi Hegde - C21689
><Ravi.Hegde@...rochip.com>; UNGLinuxDriver
><UNGLinuxDriver@...rochip.com>
>Subject: Re: [PATCH net-next v2 1/2] net: phy: microchip: update LAN88xx phy ID
>and phy ID mask.
>
>EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>content is safe
>
>On Wed, Apr 27, 2022 at 05:19:56AM -0700, Yuiko Oshino wrote:
>> update LAN88xx phy ID and phy ID mask because the existing code conflicts
>with the LAN8742 phy.
>>
>> 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.
Yuiko
Powered by blists - more mailing lists