linux-kernel - Re: [PATCH net 0/1] phy: microchip

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]

Date: Mon, 27 May 2024 09:48:10 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <andrew@...n.ch>, <ramon.nordin.rodriguez@...roamp.se>
CC: <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>
Subject: Re: [PATCH net 0/1] phy: microchip_t1s: lan865x rev.b1 support

Hi Andrew,

On 24/05/24 8:20 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> Far as I can tell the phy-driver cannot access some of the regs necessary
>> for probing the hardware and performing the init/fixup without going
>> over the spi interface.
>> The MMDCTRL register (used with indirect access) can address
>>
>> * PMA - mms 3
>> * PCS - mms 2
>> * Vendor specific / PLCA - mms 4
>>
>> This driver needs to access mms (memory map seleector)
>> * mac registers - mms 1,
>> * vendor specific / PLCA - mms 4
>> * vencor specific - mms 10
> 
> In general, a MAC should not be touching the PHY, and the PHY should
> not be touching the MAC. This rule is because you should not assume
> you have a specific MAC+PHY pair. However, this is one blob of
> silicon, so we can relax that a bit if needed.
> 
> So it sounds like Microchip have mixed up the register address spaces
> :-(
> 
> I guess this also means there is no discrete version of this PHY,
> because where would these registers be?
> 
> Do any of the registers in the wrong address space need to be poked at
> runtime? By that i mean config_aneg(), read_status(). Or are they only
> needed around the time the PHY is probed?
> 
> How critical is the ordering? Could we have the Microchip MAC driver
> probe. It instantiates the TC6 framework which registers the MDIO bus
> and probes the PHY. Can the MAC driver then complete the PHY setup
> using the registers in the wrong address space? Does it need to access
> any PHY registers in the correct address space? The MAC driver should
> be able to do this before phy_start()
> 
> Does MMS 0 register 1 "PHY Identification Register" give enough
> information to know it is a B1 PHY? The standard suggests it is a
> straight copy of PHY registers 2 and 3. So the MAC driver does not
> need to touch PHY registers, we are not totally violating the
> layering...
I completely agree with all your above points. As I told already, I am 
in talk with our design team about this complications by the time this 
Rev.B1 support has been posted. Will try to get the clarity as soon as 
possible. Sorry for the inconvenience.

So I would recommend to go with Rev.B0 support now as "CD disable if 
PLCA is enabled" fix which gives stable performance until we get the 
clarity on B1. So that we can evaluate the TC6 framework (oa_tc6.c) to 
have a initial/basic version in the mainline first.

Best regards,
Parthiban V
> 
>          Andrew
>