netdev - [PATCH net 0/1] phy: microchip_t1s: lan865x rev.b1 support

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

Message-ID: <20240524140706.359537-1-ramon.nordin.rodriguez@ferroamp.se>
Date: Fri, 24 May 2024 16:07:05 +0200
From: Ramón Nordin Rodriguez <ramon.nordin.rodriguez@...roamp.se>
To: 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
Cc: parthiban.veerasooran@...rochip.com,
	Ramón Nordin Rodriguez <ramon.nordin.rodriguez@...roamp.se>
Subject: [PATCH net 0/1] phy: microchip_t1s: lan865x rev.b1 support

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

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