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

Message-ID: <145ee4ab-14e9-41c6-bedb-b2af55ae9f43@kernel.org>
Date: Sat, 9 Nov 2024 12:59:54 +0200
From: Roger Quadros <rogerq@...nel.org>
To: Andreas Kemnade <andreas@...nade.info>
Cc: 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



On 08/11/2024 19:41, Andreas Kemnade wrote:
> Am Fri, 8 Nov 2024 14:42:14 +0200
> schrieb Roger Quadros <rogerq@...nel.org>:
> 
>>> diff --git a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> index 3661340009e7a..11f8af34498b1 100644
>>> --- a/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> +++ b/arch/arm/boot/dts/ti/omap/omap3-gta04.dtsi
>>> @@ -612,19 +612,23 @@ &i2c3 {
>>>  };
>>>  
>>>  &mcspi1 {
>>> -	status = "disabled";  
>>
>> But according to commit a622310f7f01 ("ARM: dts: gta04: fix excess dma channel usage"),
>> these mcspi modules are not used. So it doesn't make sense to enable them even if it
>> seems to solve the power management issue?
>>
> 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.
> 
> I can try a ti-sysc based fix in parallel.
> 
>> Does bootloader leave the mcspi modules in a unwanted state?
> 
> Or at least something related to them. 
> As said, for the blamed patch I checked only for CM_IDLEST1_CORE
> and CM_FCLKEN1_CORE.
> 
>> Would it make sense for the bus driver to explicitly turn off all modules?
> 
> Hmm, not very clear what you mean. AFAIK everything below ti-sysc gets
> turned off if a disable is in the child node. Explicitly disabling such
> stuff in the dtsi and enable it in the board dts sound sane
> to me at first glance. I think it is a common pattern. The question is
> whether that causes confusion with not ti-sysc stuff. Well, having
> status=okay everywhere in the dts should not harm.
> But as said for a regression fix some overhaul affecting every device 
> is out of scope.

McSPI modules have Revision, Syconfig and Sysstatus registers.
Is it because we are missing the ti-sysc representation for it
that the module power is not being correctly handled in Linux
if module is kept disabled?

-- 
cheers,
-roger