Netdev List
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@arri.de>
To: "Jörg Sommer" <joerg@jo-so.de>
Cc: Andrew Lunn <andrew@lunn.ch>, <netdev@vger.kernel.org>
Subject: Re: KSZ8795 not detected at start to boot from NFS
Date: Wed, 11 Dec 2024 11:18:58 +0100	[thread overview]
Message-ID: <5708326.ZASKD2KPVS@n9w6sw14> (raw)
In-Reply-To: <njdcvcha6n3chy2ldrf2ghnj5brgqxqujrk4trp5wyo6jvpo6c@b3qdubsvg6ko>

Hi Jörg,

On Tuesday, 10 December 2024, 17:43:01 CET, Jörg Sommer wrote:
> 
> So I think it's a timing problem: the ksz8795 isn't ready after the SPI
> reset, when the chip ID gets read, and this causes the probing to stop.
> 
> Why is SPI_MODE_3 required? At me, the chip works fine with SPI_MODE_0.

I tried to reconstruct why I actually did this change (sorry, I am over 40):

1. I was working on the PTP patches for KSZ956x.
2. It was necessary to convert the devicetree bindings to Yaml.
3. There where objections against keeping "spi-cpha" and "spi-cpol"
   in the example code:
   https://lore.kernel.org/netdev/20201119134801.GB3149565@bogus/

On Thursday, 19 November 2020 07:48:01 -0600, Rob Hering wrote:
> On Wed, Nov 18, 2020 at 09:30:02PM +0100, Christian Eggers wrote:
...
> > +        ksz9477: switch@0 {
> > +            compatible = "microchip,ksz9477";
> > +            reg = <0>;
> > +            reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
> > +
> > +            spi-max-frequency = <44000000>;
> > +            spi-cpha;
> > +            spi-cpol;
> 
> Are these 2 optional or required? Being optional is rare as most
> devices support 1 mode, but not unheard of. In general, you shouldn't
> need them as the driver should know how to configure the mode if the h/w
> is fixed.
...

It seems that I considered the h/w as "fixed". The pre-existing device tree
bindings and the diagrams on page 53 suggested that SPI mode 3 is the only
valid option. Particularly the idle state of the "SCL" signal is high here:

https://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9563R-Data-Sheet-DS00002419D.pdf

But the text description on page 52 says something different:
> SCL is expected to stay low when SPI operation is idle. 

Especially the timing diagrams on page 206 look more like SPI mode 0.

So it is possible that my patch was wrong (due to inconsistent description
on the data sheet / pre existing device tree binding). As I already mentioned,
I did this only due to the DT conversion, I actually don't use SPI on such
devices myself.

N.B. Which KSZ device do you actually use (I didn't find this in you previous
mails)?


On Sunday, 8 December 2024, 17:44:49 CET, Jörg Sommer wrote:
> Or am I missing something in my devicetree to set the SPI to mode 3?

The idea was that for "fixed" hardware the SPI mode should be setup in
the drivers probe() routine rather than in the device tree.

regards,
Christian




  parent reply	other threads:[~2024-12-11 10:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-07  7:53 KSZ8795 not detected at start to boot from NFS Jörg Sommer
2024-12-07 20:47 ` Andrew Lunn
2024-12-07 21:07   ` Jörg Sommer
2024-12-07 22:44     ` Christian Eggers
2024-12-08 16:44       ` Jörg Sommer
2024-12-10 16:43         ` Jörg Sommer
2024-12-10 17:41           ` Andrew Lunn
2024-12-10 21:21             ` Jörg Sommer
2024-12-11 10:18           ` Christian Eggers [this message]
2024-12-11 12:23             ` Jörg Sommer
2024-12-11 13:04               ` Christian Eggers
2024-12-11 14:46                 ` Jörg Sommer
2025-01-05 16:33                   ` Jörg Sommer
2025-01-05 17:08                     ` Andrew Lunn
2025-01-06 13:38                       ` Pieter Van Trappen
2025-01-07 22:14                         ` Jörg Sommer
2025-01-08  0:07                           ` Tristram.Ha
2024-12-11 13:24             ` 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=5708326.ZASKD2KPVS@n9w6sw14 \
    --to=ceggers@arri.de \
    --cc=andrew@lunn.ch \
    --cc=joerg@jo-so.de \
    --cc=netdev@vger.kernel.org \
    /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