linux-kernel - Re: [PATCH net-next] net: phy: bcm7xxx: Add EPHY entry for 72165

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]

Message-ID: <373865cd-469d-78ab-12ed-d84de63c6295@gmail.com>
Date:   Fri, 17 Sep 2021 11:10:57 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        "open list:BROADCOM ETHERNET PHY DRIVERS" 
        <bcm-kernel-feedback-list@...adcom.com>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] net: phy: bcm7xxx: Add EPHY entry for 72165

On 9/15/21 2:47 PM, Jakub Kicinski wrote:
> On Tue, 14 Sep 2021 15:40:41 -0700 Florian Fainelli wrote:
>> 72165 is a 16nm process SoC with a 10/100 integrated Ethernet PHY,
>> create a new macro and set of functions for this different process type.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
>> ---
>>  drivers/net/phy/bcm7xxx.c | 200 ++++++++++++++++++++++++++++++++++++++
>>  include/linux/brcmphy.h   |   1 +
>>  2 files changed, 201 insertions(+)
>>
>> diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
>> index e79297a4bae8..f6912a77a378 100644
>> --- a/drivers/net/phy/bcm7xxx.c
>> +++ b/drivers/net/phy/bcm7xxx.c
>> @@ -398,6 +398,189 @@ static int bcm7xxx_28nm_ephy_config_init(struct phy_device *phydev)
>>  	return bcm7xxx_28nm_ephy_apd_enable(phydev);
>>  }
>>  
>> +static int bcm7xxx_16nm_ephy_afe_config(struct phy_device *phydev)
>> +{
>> +	int tmp, rcalcode, rcalnewcodelp, rcalnewcode11, rcalnewcode11d2;
>> +
>> +	/* Reset PHY */
>> +	tmp = genphy_soft_reset(phydev);
>> +	if (tmp)
>> +		return tmp;
>> +
>> +	/* Reset AFE and PLL */
>> +	bcm_phy_write_exp_sel(phydev, 0x0003, 0x0006);
>> +	/* Clear reset */
>> +	bcm_phy_write_exp_sel(phydev, 0x0003, 0x0000);
>> +
>> +	/* Write PLL/AFE control register to select 54MHz crystal */
>> +	bcm_phy_write_misc(phydev, 0x0030, 0x0001, 0x0000);
>> +	bcm_phy_write_misc(phydev, 0x0031, 0x0000, 0x044a);
>> +
>> +	/* Change Ka,Kp,Ki to pdiv=1 */
>> +	bcm_phy_write_misc(phydev, 0x0033, 0x0002, 0x71a1);
>> +	/* Configuration override */
>> +	bcm_phy_write_misc(phydev, 0x0033, 0x0001, 0x8000);
>> +
>> +	/* Change PLL_NDIV and PLL_NUDGE */
>> +	bcm_phy_write_misc(phydev, 0x0031, 0x0001, 0x2f68);
>> +	bcm_phy_write_misc(phydev, 0x0031, 0x0002, 0x0000);
>> +
>> +	/* Reference frequency is 54Mhz, config_mode[15:14] = 3 (low
>> +	 * phase) */
> 
> Checkpatch points out:
> 
> WARNING: Block comments use a trailing */ on a separate line
> #55: FILE: drivers/net/phy/bcm7xxx.c:429:
> +	 * phase) */

Yes indeed, sorry about that.

> 
>> +	/* Drop LSB */
>> +	rcalnewcode11d2 = (rcalnewcode11 & 0xfffe) / 2;
>> +	tmp = bcm_phy_read_misc(phydev, 0x003d, 0x0001);
>> +	/* Clear bits [11:5] */
>> +	tmp &= ~0xfe0;
>> +	/* set txcfg_ch0<5>=1 (enable + set local rcal) */
>> +	tmp |= 0x0020 | (rcalnewcode11d2 * 64);
>> +	bcm_phy_write_misc(phydev, 0x003d, 0x0001, tmp);
>> +	bcm_phy_write_misc(phydev, 0x003d, 0x0002, tmp);
>> +
>> +	tmp = bcm_phy_read_misc(phydev, 0x003d, 0x0000);
>> +	/* set txcfg<45:44>=11 (enable Rextra + invert fullscaledetect)
>> +	 */
>> +	tmp &= ~0x3000;
>> +	tmp |= 0x3000;
> 
> Clearing then setting the same bits looks a little strange. Especially
> since from the comment it sounds like these are two separate bits, not
> a bitfield which is cleared and set as a whole. Anyway, up to you, just
> jumped out when I was looking thru to see if the use of signed tmp may
> cause any trouble...

I will keep it for now if you don't mind because there is a good chance
that we will need to change that in the future. For the most part the
programming sequence is automated based on a script provided by the
design team, the less manual updates I have to do the better.
-- 
Florian