linux-kernel - Re: [PATCH net-next v3 2/6] net: phy: microchip_t1s: replace read-modify-write code with phy_modify

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f81c80cb-fbe8-0c7e-f0f9-14509f47c653@microchip.com>
Date:   Fri, 26 May 2023 05:48:25 +0000
From:   <Parthiban.Veerasooran@...rochip.com>
To:     <ramon.nordin.rodriguez@...roamp.se>
CC:     <andrew@...n.ch>, <hkallweit1@...il.com>, <linux@...linux.org.uk>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <Horatiu.Vultur@...rochip.com>,
        <Woojung.Huh@...rochip.com>, <Nicolas.Ferre@...rochip.com>,
        <Thorsten.Kummermehr@...rochip.com>
Subject: Re: [PATCH net-next v3 2/6] net: phy: microchip_t1s: replace
 read-modify-write code with phy_modify_mmd

Hi Ramon,

On 25/05/23 8:38 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Wed, May 24, 2023 at 08:15:35PM +0530, Parthiban Veerasooran wrote:
>> Replace read-modify-write code in the lan867x_config_init function to
>> avoid handling data type mismatch and to simplify the code.
>>
>> Signed-off-by: Parthiban Veerasooran <Parthiban.Veerasooran@...rochip.com>
>> ---
>>   drivers/net/phy/microchip_t1s.c | 23 +++++++++++------------
>>   1 file changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/net/phy/microchip_t1s.c b/drivers/net/phy/microchip_t1s.c
>> index a42a6bb6e3bd..b5b5a95fa6e7 100644
>> --- a/drivers/net/phy/microchip_t1s.c
>> +++ b/drivers/net/phy/microchip_t1s.c
>> @@ -31,19 +31,19 @@
>>    * W   0x1F 0x0099 0x7F80 ------
>>    */
>>
>> -static const int lan867x_fixup_registers[12] = {
>> +static const u32 lan867x_fixup_registers[12] = {
>>        0x00D0, 0x00D1, 0x0084, 0x0085,
>>        0x008A, 0x0087, 0x0088, 0x008B,
>>        0x0080, 0x00F1, 0x0096, 0x0099,
>>   };
>>
>> -static const int lan867x_fixup_values[12] = {
>> +static const u16 lan867x_fixup_values[12] = {
>>        0x0002, 0x0000, 0x3380, 0x0006,
>>        0xC000, 0x801C, 0x033F, 0x0404,
>>        0x0600, 0x2400, 0x2000, 0x7F80,
>>   };
>>
>> -static const int lan867x_fixup_masks[12] = {
>> +static const u16 lan867x_fixup_masks[12] = {
>>        0x0E03, 0x0300, 0xFFC0, 0x000F,
>>        0xF800, 0x801C, 0x1FFF, 0xFFFF,
>>        0x0600, 0x7F00, 0x2000, 0xFFFF,
>> @@ -63,23 +63,22 @@ static int lan867x_config_init(struct phy_device *phydev)
>>         * used, which might then write the same value back as read + modified.
>>         */
>>
>> -     int reg_value;
>>        int err;
>> -     int reg;
>>
>>        /* Read-Modified Write Pseudocode (from AN1699)
>>         * current_val = read_register(mmd, addr) // Read current register value
>>         * new_val = current_val AND (NOT mask) // Clear bit fields to be written
>>         * new_val = new_val OR value // Set bits
>> -      * write_register(mmd, addr, new_val) // Write back updated register value
>> +      * write_register(mmd, addr, new_val) // Write back updated register value.
>> +      * Although AN1699 says Read, Modify, Write, the write is not required if
>> +      * the register already has the required value.
>>         */
> 
> Nitpick, I think this block comment can be reduced to:
> /* The following block deviates from AN1699 which states that a values
>   * should be written back, even if unmodified.
>   * Which is not necessary, so it's safe to use phy_modify_mmd here.*/
> 
>   The comment I added was intended to describe why I was doing weird
>   things, but now I think it's more interesting to describe why we're
>   deviating from the AN.
> 
>   Or the block comment could be dropped all togheter, I'm guessing no one
>   is going to consult the AN if things 'just work'
> 
By consolidating all your comments in the other emails as well on this 
2nd patch, do you agree for my below proposal?

We will remove all block comments and simply put AN1699 reference as we 
did for lan865x_revb0_config_init with a small addition on top of 
phy_modify_mmd for loop? so the comment will look like below,

/* Reference to AN1699
  * 
https://ww1.microchip.com/downloads/aemDocuments/documents/AIS/ProductDocuments/SupportingCollateral/AN-LAN8670-1-2-config-60001699.pdf
  * AN1699 says Read, Modify, Write, but the Write is not required if 
the  register already has the required value. So it is safe to use 
phy_modify_mmd here.
  */

So in future, if someone wants to know about this configuration they can 
simply refer the AN1699.

What do you think?

Best Regards,
Parthiban V
>>        for (int i = 0; i < ARRAY_SIZE(lan867x_fixup_registers); i++) {
>> -             reg = lan867x_fixup_registers[i];
>> -             reg_value = phy_read_mmd(phydev, MDIO_MMD_VEND2, reg);
>> -             reg_value &= ~lan867x_fixup_masks[i];
>> -             reg_value |= lan867x_fixup_values[i];
>> -             err = phy_write_mmd(phydev, MDIO_MMD_VEND2, reg, reg_value);
>> -             if (err != 0)
>> +             err = phy_modify_mmd(phydev, MDIO_MMD_VEND2,
>> +                                  lan867x_fixup_registers[i],
>> +                                  lan867x_fixup_masks[i],
>> +                                  lan867x_fixup_values[i]);
>> +             if (err)
>>                        return err;
>>        }
>>
>> --
>> 2.34.1
>>