linux-kernel - Re: [PATCH] ARM: dts: ti/omap: gta04: fix pm issues caused by spi module

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

Message-ID: <20241127235858.44e1ce01@akair>
Date: Wed, 27 Nov 2024 23:58:58 +0100
From: Andreas Kemnade <andreas@...nade.info>
To: Roger Quadros <rogerq@...nel.org>
Cc: Tony Lindgren <tony@...mide.com>, 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

Am Mon, 18 Nov 2024 15:08:48 +0200
schrieb Roger Quadros <rogerq@...nel.org>:

> On 16/11/2024 22:27, Andreas Kemnade wrote:
> > Am Mon, 11 Nov 2024 23:46:04 +0100
> > schrieb Andreas Kemnade <andreas@...nade.info>:
> >   
> >> Am Mon, 11 Nov 2024 19:31:17 +0100
> >> schrieb Andreas Kemnade <andreas@...nade.info>:
> >>  
> >>> Am Mon, 11 Nov 2024 17:09:53 +0200
> >>> schrieb Tony Lindgren <tony@...mide.com>:
> >>>     
> >>>> * Andreas Kemnade <andreas@...nade.info> [241108 17:41]:      
> >>>>> They are not used, if they are just disabled, kernel does not touch
> >>>>> them, so if it is there, the kernel can handle
> >>>>> pm. At least as long as it is not under ti,sysc.
> >>>>>
> >>>>> There are probably cleaner solutions for this, but for a CC: stable I
> >>>>> would prefer something less invasive.        
> >>>>
> >>>> For unused devices, it's best to configure things to use ti-sysc, and
> >>>> then set status disabled (or reserved) for the child devices only. This
> >>>> way the parent interconnect target module is PM runtime managed by
> >>>> Linux, and it's power domain gets properly idled for the unused devices
> >>>> too.
> >>>>       
> >>> Hmm, we also have omap_hwmod_setup_all() which is still called if
> >>> without device nodes being available.
> >>>
> >>> Converting mcspi to ti-sysc is more than 100 lines. So it does not
> >>> qualify for stable.
> >>>     
> >>>>> I can try a ti-sysc based fix in parallel.        
> >>>>
> >>>> Yeah that should be trivial hopefully :)
> >>>>       
> >>> I played around, got pm issues too, tried to force-enable things (via
> >>> power/control),
> >>> watched CM_IDLEST1_CORE and CM_FCLKEN1_CORE, they behave. Bits are set
> >>> or reset.
> >>>
> >>> but not CM_IDLEST_CKGEN, it is 0x209 instead of 0x1.
> >>>
> >>> I test from initramfs, so no mmc activity involved
> >>>
> >>> removing status = "disabled" from mcspi3 solves things.
> >>> With and without ti-sysc conversion. removing status = "disabled" from
> >>> mcspi4 seems not to help.
> >>>
> >>> That all cannot be... I will retry tomorrow.
> >>>     
> >> well, I tried a bit further:
> >> I build the omap spi driver as module.
> >> and booted With mcspi3 not disabled and no module autoload.
> >>
> >> without module loaded: pm bad, same as with mcspi3 disabled
> >> with module loaded: core pm ok
> >> with module loaded and unloaded: core pm ok.
> >>
> >> so at least a trace.
> >>  
> > ok, I am a bit further.
> > 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.
> > Having the pins muxed as mode 7 also helps or selecting a pulldown for
> > cs. (cs is active high per default!)
> > switching to pullup does not harm once the spi module is off, but having
> > active cs seems to prevent idling despite CM_IDLEST1_CORE
> > not showing it.
> > 
> > History: u-boot muxes McSPI3, because it can be available on an
> > optionally fitted pin header. But there is no user known (would need
> > a dtb overlay anyways). So I will rather mux to mode 7.  
> 
> I'm sorry I didn't fully understand the problem.
> 
> So, u-boot configures pinmux for McSPI3 and enables McSPI3 as well
> but fails to disable it properly?

At least it sets Pinmux.
 
> And because McSPI3 is in slave mode and CS is active it fails to
> transition to idle in Linux?

yes, slave mode is default.
> 
> So isn't this a u-boot issue?
> 
Just telling u-boot to not mux McSPI3 helps. So, yes u-boot should not
set it. But. I have no clear idea how bitrot the u-boot update process
is. I would prefer setting the pinmux also in kernel back to the
default.

Regards,
Andreas