All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ramón Nordin Rodriguez" <ramon.nordin.rodriguez@ferroamp.se>
To: Parthiban.Veerasooran@microchip.com
Cc: 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 3/3] net: microchip_t1s: conditional collision detection
Date: Mon, 27 Nov 2023 17:32:41 +0100	[thread overview]
Message-ID: <ZWTEqXAwxIK1pSHo@debian> (raw)
In-Reply-To: <142ce54c-108c-45b4-b886-ce3ca45df9fe@microchip.com>

On Mon, Nov 27, 2023 at 04:00:18PM +0000, Parthiban.Veerasooran@microchip.com wrote:
> Hi,
> 
> This implementation was introduced in the below patch itself.
> 
> https://lore.kernel.org/netdev/20230426205049.xlfqluzwcvlm6ihh@soft-dev3-1/T/#m9a52b6c03b7fa637f70aed306b50b442590e24a3
> 

But the change was dropped in that patchset right? It's not present in
netdev-next.

> As it is recommended to do it in a separate patch and also the 
> datasheets of LAN867X Rev.B1 and LAN865X Rev.B0 internal PHY have these 
> register is reserved, we were working for a feasible solution to 
> describe this for customer and mainline. By the time many other things 
> messed up and couldn't reach the mainline on time.
> 

Far as I can tell 'collision detect' is described in the following
sections of respective datasheet:

* 11.5.51 - LAN8650
* 5.4.48  - LAN8670

The rest of the bits are reserved though. The change I propose only
manipulate the documented (bit 15) collision bit.

Is your point that the lan8670 datasheet is only valid for rev.c and not
rev.b?

Andrew suggested on the cover letter that it be interesting to look at
completly disabling collision detect, any strings you can pull at
Microchip to investigate that?
Also any input on my suggested testing methodology is more than welcome.

> We also implemented LAN867X Rev.C1 support already in the driver and 
> published in our product site and in the process of preparing mainline 
> patches. But unfortunately it took little more time to make it.
> 
> https://ww1.microchip.com/downloads/aemDocuments/documents/AIS/ProductDocuments/CodeExamples/EVB-LAN8670-USB_Linux_Driver_1v0.zip

I'm aware, we've been using a derivative of that work at ferroamp for
development. But it's been driving me nuts, being the 't1s guy' at work,
and maintaining out of tree drivers for weird dev boxes.

It's not my intention to beat you to the punch, I just want a mainlined
driver so that I can spend less of my time on plumbing.

> 
> Anyway, thank you for the support. Good luck!

Likewise!
R

  reply	other threads:[~2023-11-27 16:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27 10:40 [PATCH 0/3] net: microchip_t1s: additional phy support and collision detect handling Ramón N.Rodriguez
2023-11-27 10:40 ` [PATCH 1/3] net: microchip_t1s: refactor reset functionality Ramón N.Rodriguez
2023-11-27 13:27   ` Andrew Lunn
2023-11-27 10:40 ` [PATCH 2/3] net: microchip_t1s: add support for LAN867x Rev.C1 Ramón N.Rodriguez
2023-11-27 13:37   ` Andrew Lunn
2023-11-27 14:02     ` Ramón Nordin Rodriguez
2023-12-05 10:20     ` Félix Piédallu
2023-12-06 20:58       ` Ramón Nordin Rodriguez
2023-11-27 10:40 ` [PATCH 3/3] net: microchip_t1s: conditional collision detection Ramón N.Rodriguez
2023-11-27 16:00   ` Parthiban.Veerasooran
2023-11-27 16:32     ` Ramón Nordin Rodriguez [this message]
2023-11-28  6:52       ` Parthiban.Veerasooran
2023-11-28  9:18         ` Ramón Nordin Rodriguez
2023-11-27 13:58 ` [PATCH 0/3] net: microchip_t1s: additional phy support and collision detect handling Andrew Lunn
2023-11-27 15:30   ` Ramón Nordin Rodriguez
2023-11-27 16:03     ` Andrew Lunn
2023-11-28  8:57       ` Ramón Nordin Rodriguez
2023-12-10 12:10       ` Ramón Nordin Rodriguez
2023-12-11 13:54         ` Andrew Lunn

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=ZWTEqXAwxIK1pSHo@debian \
    --to=ramon.nordin.rodriguez@ferroamp.se \
    --cc=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 \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.