mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: <Parthiban.Veerasooran@microchip.com>
To: <ramon.nordin.rodriguez@ferroamp.se>, <andrew@lunn.ch>,
	<hkallweit1@gmail.com>, <linux@armlinux.org.uk>,
	<davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
	<pabeni@redhat.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net 0/1] phy: microchip_t1s: lan865x rev.b1 support
Date: Mon, 27 May 2024 08:21:00 +0000	[thread overview]
Message-ID: <bd854003-2b8b-41a8-923a-1b87d6213180@microchip.com> (raw)
In-Reply-To: <20240524140706.359537-1-ramon.nordin.rodriguez@ferroamp.se>

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
> 


      parent reply	other threads:[~2024-05-27  8:21 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-24 14:07 Ramón Nordin Rodriguez
2024-05-24 14:07 ` [PATCH 1/1] net: phy: microchip_t1s: enable lan865x revb1 Ramón Nordin Rodriguez
2024-05-24 15:11   ` Russell King (Oracle)
2024-05-27  5:37   ` [EXTERNAL] " Sai Krishna Gajula
2024-05-24 14:50 ` [PATCH net 0/1] phy: microchip_t1s: lan865x rev.b1 support Andrew Lunn
2024-05-27  9:48   ` Parthiban.Veerasooran
2024-05-24 15:30 ` Russell King (Oracle)
2024-05-27  9:54   ` Parthiban.Veerasooran
2024-05-27  8:21 ` Parthiban.Veerasooran [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd854003-2b8b-41a8-923a-1b87d6213180@microchip.com \
    --to=parthiban.veerasooran@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ramon.nordin.rodriguez@ferroamp.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®