linux-kernel - Re: [PATCH v2 2/8] cpuidle: psci: Transition to the faux device interface

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: <c63d7864-2a1a-40f7-acb7-ba0bc3311fba@nvidia.com>
Date: Fri, 2 May 2025 11:20:57 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: linux-kernel@...r.kernel.org,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 Daniel Lezcano <daniel.lezcano@...aro.org>, linux-pm@...r.kernel.org,
 "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH v2 2/8] cpuidle: psci: Transition to the faux device
 interface


On 01/05/2025 17:07, Sudeep Holla wrote:

...

>> I have noticed the following error messages on some of our Tegra devices ...
>>
>>   ERR KERN faux psci-cpuidle: probe did not succeed, tearing down the device
>>   ERR KERN CPUidle PSCI: Failed to create psci-cpuidle device
>>
>> I had a quick look at this and this occurs because of the following code in
>> the probe cpuidle-psci driver ...
>>
>>          /*
>>           * If no DT idle states are detected (ret == 0) let the driver
>>           * initialization fail accordingly since there is no reason to
>>           * initialize the idle driver if only wfi is supported, the
>>           * default archictectural back-end already executes wfi
>>           * on idle entry.
>>           */
>>          ret = dt_init_idle_driver(drv, psci_idle_state_match, 1);
>>          if (ret <= 0)
>>                  return ret ? : -ENODEV;
>>
>>
>> So although it could be argued that the error message is valid, I am not
>> sure if there is anything that mandates that we need to have the idle-states
>> present.
>>
>> We are always checking for new kernel errors and so if something new occurs,
>> I am trying to figure out what is the correct way to fix. For this case I am
>> not sure what is best.
>>
> 
> This is another case where probe was failing before too just that faux
> device probe throws the error. I will take a look and see what can be done.
> But yes, we shouldn't throw error if no idle-states are present in the DT.


Yes exactly this was already failing. Thanks for taking a look!

Cheers
Jon

-- 
nvpublic