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: <cxe42bethnzs7f46xxyvj6ok6ve7itssdxyh2vuftnfws4aa3z@2o4njdkw3r5i>
Date: Wed, 11 Dec 2024 13:23:38 +0100
From: Jörg Sommer <joerg@...so.de>
To: Christian Eggers <ceggers@...i.de>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: KSZ8795 not detected at start to boot from NFS

Christian Eggers schrieb am Mi 11. Dez, 11:18 (+0100):
> 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):

Don't worry. Me, too. :)

> 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/

I think for 8795 these are optional. At me, it works with 0 and 3.

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

> 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.


Jörg.

-- 
>> Kann man da auch ausrutschen?
> Das ist ja das fatale: Im Bett passieren sogar Unfälle, *ohne* daß man
> ausrutscht.
Du meinst, Safer Sex ist, wenn man die Freundin an der Wand festkettet?
   <news:072bda371fa28679a7c0818a1157fd7e@...ug.de>

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)