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 08:21:00 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <ramon.nordin.rodriguez@...roamp.se>, <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>
Subject: Re: [PATCH net 0/1] phy: microchip_t1s: lan865x rev.b1 support

Hi Ramon,

On 24/05/24 7:37 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi,
> Let me first prepend this submission with 4 points:
> 
> * this is not in a merge-ready state
> * some code has been copied from the ongoing oa_tc6 work by Parthiban
> * this has to interop with code not yet merged (oa_tc6)
> * Microchip is looking into if rev.b0 can use the rev.b1 init procedure
I will try to get the info on this as soon as possible. I have asked for 
it to avoid the below complications only. I don't want to proceed with 
these patches until getting a clarity to avoid unnecessary confusions.

Best regards,
Parthiban V
> 
> The ongoing work by Parthiban Veerasooran is probably gonna get at least
> one more revision
> (https://lore.kernel.org/netdev/20240418125648.372526-1-Parthiban.Veerasooran@microchip.com/)
> 
> I'm publishing this early as it could benefit some of the discussions in
> the oa_tc6 threads, as well as giving other devs the possibility
> massaging things to a state where they can use the rev.b1 chip (rev.b0
> is eol).
> And I need feedback on how to wrap this up.
> 
> 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
> 
> Far as I can tell, mms 1 and 10 are only accessible via spi. In the
> oa_tc6 patches this is enabled by the oa_tc6 framework by populating the
> mdiobus->read/write_c45 funcs.
> 
> In order to access any mms I needed I added the following change in the
> oa_tc6.c module
> 
> static int oa_tc6_get_phy_c45_mms(int devnum)
>   {
> +       if(devnum & BIT(31))
> +               return devnum & GENMASK(30, 0);
> 
> Which corresponds to the 'mms | BIT(31)' snippets in this commit, this
> is really not how things should be handled, and I need input on how to
> proceed here.
> 
> Here we get into a weird spot, this driver will need changes in the
> oa_tc6 submission, but it's weird to submit support for yet another phy
> with that patchset (in my opinion).
> 
> This has been tested with a lan8650 rev.b1 chip on one end and a lan8670
> usb eval board on the other end. Performance is rather lacking, the
> rev.b0 reaches close to the 10Mbit/s limit, but b.1 only gets about
> ~4Mbit/s, with the same results when PLCA enabled or disabled.
> 
> I suggest that this patch is left to brew until the oa_tc6 changes are
> accepted, at which time this is fixed up.
> 
> Ramón Nordin Rodriguez (1):
>    net: phy: microchip_t1s: enable lan865x revb1
> 
>   drivers/net/phy/microchip_t1s.c | 189 ++++++++++++++++++++++++++++----
>   1 file changed, 166 insertions(+), 23 deletions(-)
> 
> --
> 2.43.0
>