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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID:
 <DM3PR11MB873636331EF099AD422FEABBEC122@DM3PR11MB8736.namprd11.prod.outlook.com>
Date: Wed, 8 Jan 2025 00:07:20 +0000
From: <Tristram.Ha@...rochip.com>
To: <joerg@...so.de>
CC: <ceggers@...i.de>, <kuba@...nel.org>, <Woojung.Huh@...rochip.com>,
	<netdev@...r.kernel.org>, <linux-spi@...r.kernel.org>, <andrew@...n.ch>,
	<pieter.van.trappen@...n.ch>
Subject: RE: KSZ8795 not detected at start to boot from NFS

> From: Jörg Sommer <joerg@...so.de>
> Sent: Tuesday, January 7, 2025 2:14 PM
> To: Pieter Van Trappen <pieter.van.trappen@...n.ch>
> Cc: Christian Eggers <ceggers@...i.de>; Jakub Kicinski <kuba@...nel.org>; Tristram
> Ha - C24268 <Tristram.Ha@...rochip.com>; Woojung Huh - C21699
> <Woojung.Huh@...rochip.com>; netdev@...r.kernel.org; linux-spi@...r.kernel.org;
> Andrew Lunn <andrew@...n.ch>
> Subject: Re: KSZ8795 not detected at start to boot from NFS
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content
> is safe

It is perfectly okay to remove the code as KSZ switches are not limited
to SPI mode 3.  Generally they work for SPI modes 0, 2, and 3.
This SPI access problem is caused by the SPI bus driver.  In certain
kernel versions the Atmel SPI bus driver has this problem.  There is a
workaround for that but the fix occurs in the main SPI bus driver, not
the Atmel sub-driver.  This problem does not occur in latest kernels and
I do not know which part of SPI driver fixed the behavior.

The problem is the very first SPI access after kernel boots is not
recognized by the chip and so it does not return any value.  This is
probably caused by the SPI chip select signal not setting properly
because of polarity.  A workaround is to read the chip again or just use
SPI mode 0, which starts with low level instead of high level.