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: <20241117222237.01a9b0b5@akair>
Date: Sun, 17 Nov 2024 22:22:37 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Tony Lindgren <tony@...mide.com>
Cc: Roger Quadros <rogerq@...nel.org>, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, hns@...delico.com, linux-omap@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 aaro.koskinen@....fi, khilman@...libre.com, stable@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: ti/omap: gta04: fix pm issues caused by spi
 module

Hi Tony,

Am Sun, 17 Nov 2024 13:19:03 +0200
schrieb Tony Lindgren <tony@...mide.com>:

> * Andreas Kemnade <andreas@...nade.info> [241116 20:27]:
> > mcspi is per default in slave mode, setting it to master solves issues.
> > And that happens when the driver is probed because its default is
> > master.  
> 
> OK interesting. Maybe set up a quirk function for it in ti-sysc.c.
> That way the mcspi will get idled also when set to status disabled
> and no mcspi driver is loaded.
> 
First of all I think if status = "disabled" then no pins should be
muxed to mcspi. That prevents all mess.

So the only case left is spi enabled but no driver and CS input is
active. If we configure things as master via a quirk if the setup is
slave then switch something to output which should not be. We would have
some output againt output situation at least for a moment.

Maybe pinmuxing stuff in ti-sysc? Hmm, I am really unsure if it is
worth it.

Regarding the GTA04 case:

mcspi1,2 and 4 are not muxed, so that issue occurs only with mcspi3,
and therefore the most simple solution is to mux it to mode7 as sent
in the v2 which should also be suitable for -stable.

Regards,
Andreas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ