[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5708326.ZASKD2KPVS@n9w6sw14>
Date: Wed, 11 Dec 2024 11:18:58 +0100
From: Christian Eggers <ceggers@...i.de>
To: Jörg Sommer <joerg@...so.de>
CC: Andrew Lunn <andrew@...n.ch>, <netdev@...r.kernel.org>
Subject: Re: KSZ8795 not detected at start to boot from NFS
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
Powered by blists - more mailing lists