netdev - Re: KSZ8795 not detected at start to boot from NFS

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

Message-ID: <2675613.fDdHjke4Dd@n9w6sw14>
Date: Wed, 11 Dec 2024 14:04:37 +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 Wednesday, 11 December 2024, 13:23:38 CET, Jörg Sommer wrote:
> Christian Eggers schrieb am Mi 11. Dez, 11:18 (+0100):

> I think for 8795 these are optional. At me, it works with 0 and 3.
Hmm, I understood that setting SPI mode to 3 (by my patch) is the
root of your problem? If you revert my patch and set spi-cpol + spi-cpha
in you device tree, the result should be more or less the same.

If you think that your problem is related to the reset timing, feel
free to increase the sleep time after asserting/deasserting the reset
line. Beside the hardware reset there's usually also a software reset.
But this type of reset normally doesn't affect consecutive register
accesses.

> I'm not an expert. So, please, double check this: the spec [1] says on
> page 53, table 4-3, register 11, bit 0 “Trigger on the rising edge of SPI
> clock (for higher speed SPI)”. According to [2] the rising edge is cpol=0
> and mode 0. So, “higher speed SPI” (I think this is the 25MHz) should use
> mode 0.
>
> [1] https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/KSZ8795CLX-Data-Sheet-DS00002112.pdf
> [2] https://electronics.stackexchange.com/a/455564

I hate SPI because of its poorly written specifications! When I read the
corresponding sections of the KSZ9563 DS [3], I come to the conclusion that
the register bit you mentioned above affects the SPI *output* signal 
(SPIQ a.k.a MISO). This would also make more sense, as you usually
cannot change the behavior of the SPI input lines.

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

Page 68, on the bottom:
> *SPI Data Out Edge Select*
> 0 = SDO data is clocked by the falling edge of SCL
> 1 = SDO data is clocked by the rising edge of SCL

So the bit 0 is intended to adjust the phase of the SPIQ/SDO/MOSI output
signal, in order to avoid that this signal is switched at the same clock edge
where your uC samples the MISO input.

Also for the KSZ8795CLX there seems to be a mismatch regarding the SPI clock
polarity in the datasheet. Page 28 (functional description) implies CPOL=1
whilst page 123 (timing diagram) shows CPOL=0. I would trust the latter
in this case.

> 
> 
> > 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)?
> 
> I'm using KSZ8795.

I should better read the subject line ...

Summary:
- The timing diagrams of KSZ8795CLX and KSZ9563 implies that SPI mode 0 is correct
- The functional descriptions in the datasheets look more like SPI mode 3, but this
  is not authoritative.
- Maybe that the KSZ devices can work with both modes.


regards,
Christian