| Message ID | 20181003143824.13059-1-ulf.hansson@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | PM / Domains: Support hierarchical CPU arrangement (PSCI/ARM) (a subset) | expand |
On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > I have digested the review comments so far, including a recent offlist chat > with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I > have a plan for how to move forward. > > However, to avoid re-posting non-changed patches over and over again, I decided > to withhold the more debatable part from this v9, hence this is not the complete > series to make things play. In v9, I have just included the trivial changes, > which are either already acked/reviewed or hopefully can be rather soon/easily. > > My hope is to get this queued for v4.20, to move things forward. I know it's > late, but there are more or less nothing new here since v8. I have no problems with the first three patches in this series, so I can apply them right away. Do you want me to do that? As for the rest, the cpuidle driver patch looks OK to me, but the PSCI-related ones need ACKs. Thanks, Rafael
On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote: > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: >> >> I have digested the review comments so far, including a recent offlist chat >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I >> have a plan for how to move forward. >> >> However, to avoid re-posting non-changed patches over and over again, I decided >> to withhold the more debatable part from this v9, hence this is not the complete >> series to make things play. In v9, I have just included the trivial changes, >> which are either already acked/reviewed or hopefully can be rather soon/easily. >> >> My hope is to get this queued for v4.20, to move things forward. I know it's >> late, but there are more or less nothing new here since v8. > > I have no problems with the first three patches in this series, so I > can apply them right away. Do you want me to do that? Yes, please. > > As for the rest, the cpuidle driver patch looks OK to me, but the > PSCI-related ones need ACKs. For some yes, but I think you can go ahead with a few more. Patch 4, 5 is already acked/reviewed. Patch 6 should be fine (if you are okay with it else wait for an ack from Daniel) Patch 7 and 8 should be fine. They were suggested by Mark. Patch 9 and 10 needs acks. Patch 11 has been acked, but depends on the other PSCI changes. Kind regards Uffe
On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote: > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote: > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > >> > >> I have digested the review comments so far, including a recent offlist chat > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I > >> have a plan for how to move forward. > >> > >> However, to avoid re-posting non-changed patches over and over again, I decided > >> to withhold the more debatable part from this v9, hence this is not the complete > >> series to make things play. In v9, I have just included the trivial changes, > >> which are either already acked/reviewed or hopefully can be rather soon/easily. > >> > >> My hope is to get this queued for v4.20, to move things forward. I know it's > >> late, but there are more or less nothing new here since v8. > > > > I have no problems with the first three patches in this series, so I > > can apply them right away. Do you want me to do that? > > Yes, please. > > > > > As for the rest, the cpuidle driver patch looks OK to me, but the > > PSCI-related ones need ACKs. > > For some yes, but I think you can go ahead with a few more. > > Patch 4, 5 is already acked/reviewed. > > Patch 6 should be fine (if you are okay with it else wait for an ack > from Daniel) OK, thanks. Do the 4-6 depend on the 1-3? > Patch 7 and 8 should be fine. They were suggested by Mark. I'd rather have ACKs on these two as well. > Patch 9 and 10 needs acks. > > Patch 11 has been acked, but depends on the other PSCI changes. OK
On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote: > > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > >> > > >> I have digested the review comments so far, including a recent offlist chat > > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I > > >> have a plan for how to move forward. > > >> > > >> However, to avoid re-posting non-changed patches over and over again, I decided > > >> to withhold the more debatable part from this v9, hence this is not the complete > > >> series to make things play. In v9, I have just included the trivial changes, > > >> which are either already acked/reviewed or hopefully can be rather soon/easily. > > >> > > >> My hope is to get this queued for v4.20, to move things forward. I know it's > > >> late, but there are more or less nothing new here since v8. > > > > > > I have no problems with the first three patches in this series, so I > > > can apply them right away. Do you want me to do that? > > > > Yes, please. > > > > > > > > As for the rest, the cpuidle driver patch looks OK to me, but the > > > PSCI-related ones need ACKs. > > > > For some yes, but I think you can go ahead with a few more. > > > > Patch 4, 5 is already acked/reviewed. > > > > Patch 6 should be fine (if you are okay with it else wait for an ack > > from Daniel) > > OK, thanks. > > Do the 4-6 depend on the 1-3? I don't see any dependency there, so I'll queue up the 1-3 in pm-domains and the 4-6 in pm-cpuidle. Thanks, Rafael
On 4 October 2018 at 11:32, Rafael J. Wysocki <rafael@kernel.org> wrote: > On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote: >> >> On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote: >> > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote: >> > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: >> > >> >> > >> I have digested the review comments so far, including a recent offlist chat >> > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I >> > >> have a plan for how to move forward. >> > >> >> > >> However, to avoid re-posting non-changed patches over and over again, I decided >> > >> to withhold the more debatable part from this v9, hence this is not the complete >> > >> series to make things play. In v9, I have just included the trivial changes, >> > >> which are either already acked/reviewed or hopefully can be rather soon/easily. >> > >> >> > >> My hope is to get this queued for v4.20, to move things forward. I know it's >> > >> late, but there are more or less nothing new here since v8. >> > > >> > > I have no problems with the first three patches in this series, so I >> > > can apply them right away. Do you want me to do that? >> > >> > Yes, please. >> > >> > > >> > > As for the rest, the cpuidle driver patch looks OK to me, but the >> > > PSCI-related ones need ACKs. >> > >> > For some yes, but I think you can go ahead with a few more. >> > >> > Patch 4, 5 is already acked/reviewed. >> > >> > Patch 6 should be fine (if you are okay with it else wait for an ack >> > from Daniel) >> >> OK, thanks. >> >> Do the 4-6 depend on the 1-3? > > I don't see any dependency there, so I'll queue up the 1-3 in > pm-domains and the 4-6 in pm-cpuidle. Great, thanks! Make sure you put the remaining of the PSCI changes on pm-cpuidle (once acked), as there are dependency. Kind regards Uffe
On Thu, Oct 04, 2018 at 11:32:41AM +0200, Rafael J. Wysocki wrote: > On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > > > On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote: > > > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > >> > > > >> I have digested the review comments so far, including a recent offlist chat > > > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I > > > >> have a plan for how to move forward. > > > >> > > > >> However, to avoid re-posting non-changed patches over and over again, I decided > > > >> to withhold the more debatable part from this v9, hence this is not the complete > > > >> series to make things play. In v9, I have just included the trivial changes, > > > >> which are either already acked/reviewed or hopefully can be rather soon/easily. > > > >> > > > >> My hope is to get this queued for v4.20, to move things forward. I know it's > > > >> late, but there are more or less nothing new here since v8. > > > > > > > > I have no problems with the first three patches in this series, so I > > > > can apply them right away. Do you want me to do that? > > > > > > Yes, please. > > > > > > > > > > > As for the rest, the cpuidle driver patch looks OK to me, but the > > > > PSCI-related ones need ACKs. > > > > > > For some yes, but I think you can go ahead with a few more. > > > > > > Patch 4, 5 is already acked/reviewed. > > > > > > Patch 6 should be fine (if you are okay with it else wait for an ack > > > from Daniel) > > > > OK, thanks. > > > > Do the 4-6 depend on the 1-3? > > I don't see any dependency there, so I'll queue up the 1-3 in > pm-domains and the 4-6 in pm-cpuidle. I do not see why we should merge patches 4-6 for v4.20; they add legacy (DT bindings and related parsing code) with no user in the kernel; we may still want to tweak them, in particular PSCI DT bindings. Likewise, it makes no sense to merge patches 7-8 without the rest of the PSCI patches. Why do not we target v4.20-rc1 for the whole series re-posting and we take it from there given that we are at -rc6 tail end ? Thanks, Lorenzo
On Thu, Oct 4, 2018 at 5:58 PM Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > > On Thu, Oct 04, 2018 at 11:32:41AM +0200, Rafael J. Wysocki wrote: > > On Thu, Oct 4, 2018 at 11:04 AM Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > > > > > > On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote: > > > > On 4 October 2018 at 10:39, Rafael J. Wysocki <rafael@kernel.org> wrote: > > > > > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > > >> > > > > >> I have digested the review comments so far, including a recent offlist chat > > > > >> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I > > > > >> have a plan for how to move forward. > > > > >> > > > > >> However, to avoid re-posting non-changed patches over and over again, I decided > > > > >> to withhold the more debatable part from this v9, hence this is not the complete > > > > >> series to make things play. In v9, I have just included the trivial changes, > > > > >> which are either already acked/reviewed or hopefully can be rather soon/easily. > > > > >> > > > > >> My hope is to get this queued for v4.20, to move things forward. I know it's > > > > >> late, but there are more or less nothing new here since v8. > > > > > > > > > > I have no problems with the first three patches in this series, so I > > > > > can apply them right away. Do you want me to do that? > > > > > > > > Yes, please. > > > > > > > > > > > > > > As for the rest, the cpuidle driver patch looks OK to me, but the > > > > > PSCI-related ones need ACKs. > > > > > > > > For some yes, but I think you can go ahead with a few more. > > > > > > > > Patch 4, 5 is already acked/reviewed. > > > > > > > > Patch 6 should be fine (if you are okay with it else wait for an ack > > > > from Daniel) > > > > > > OK, thanks. > > > > > > Do the 4-6 depend on the 1-3? > > > > I don't see any dependency there, so I'll queue up the 1-3 in > > pm-domains and the 4-6 in pm-cpuidle. > > I do not see why we should merge patches 4-6 for v4.20; they add legacy > (DT bindings and related parsing code) with no user in the kernel; we > may still want to tweak them, in particular PSCI DT bindings. My impression was that 4-6 have been agreed on due to the ACKs they carry. I'll drop them if that's not the case. > Likewise, it makes no sense to merge patches 7-8 without the rest of > the PSCI patches. OK I'll let the ARM camp sort out the PSCI material then. Thanks, Rafael
On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote: [...] > > > I don't see any dependency there, so I'll queue up the 1-3 in > > > pm-domains and the 4-6 in pm-cpuidle. > > > > I do not see why we should merge patches 4-6 for v4.20; they add legacy > > (DT bindings and related parsing code) with no user in the kernel; we > > may still want to tweak them, in particular PSCI DT bindings. > > My impression was that 4-6 have been agreed on due to the ACKs they > carry. I'll drop them if that's not the case. I have not expressed myself correctly: they have been agreed (even though as I said they may require some tweaking) but I see no urgency of merging them in v4.20 since they have no user. They contain DT bindings, that create ABI/legacy, I think it is better to have code that uses them in the kernel before merging them and creating a dependency that is not needed. > > Likewise, it makes no sense to merge patches 7-8 without the rest of > > the PSCI patches. > > OK > > I'll let the ARM camp sort out the PSCI material then. We will do. Thanks, Lorenzo
On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote: > > [...] > >> > > I don't see any dependency there, so I'll queue up the 1-3 in >> > > pm-domains and the 4-6 in pm-cpuidle. >> > >> > I do not see why we should merge patches 4-6 for v4.20; they add legacy >> > (DT bindings and related parsing code) with no user in the kernel; we >> > may still want to tweak them, in particular PSCI DT bindings. >> >> My impression was that 4-6 have been agreed on due to the ACKs they >> carry. I'll drop them if that's not the case. > > I have not expressed myself correctly: they have been agreed (even > though as I said they may require some tweaking) but I see no urgency > of merging them in v4.20 since they have no user. They contain DT > bindings, that create ABI/legacy, I think it is better to have code > that uses them in the kernel before merging them and creating a > dependency that is not needed. There is already code using the new bindings, for the idle states. Please have look at patch 5, 6 and 11. Moreover, you have had plenty on time to look at the series, as those patches haven't changed since a very long time. May I suggest you do the review instead, so we can move things forward, please. The changes in the v9 series should be trivial to review. > >> > Likewise, it makes no sense to merge patches 7-8 without the rest of >> > the PSCI patches. Well, those patches are part of this series, because Mark wanted me to move the files. Is really such a big deal? I think it makes sense, no matter what happens afterwards. [...] Kind regards Uffe
On 4 October 2018 at 20:36, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: >> On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote: >> >> [...] >> >>> > > I don't see any dependency there, so I'll queue up the 1-3 in >>> > > pm-domains and the 4-6 in pm-cpuidle. >>> > >>> > I do not see why we should merge patches 4-6 for v4.20; they add legacy >>> > (DT bindings and related parsing code) with no user in the kernel; we >>> > may still want to tweak them, in particular PSCI DT bindings. >>> >>> My impression was that 4-6 have been agreed on due to the ACKs they >>> carry. I'll drop them if that's not the case. >> >> I have not expressed myself correctly: they have been agreed (even >> though as I said they may require some tweaking) but I see no urgency >> of merging them in v4.20 since they have no user. They contain DT >> bindings, that create ABI/legacy, I think it is better to have code >> that uses them in the kernel before merging them and creating a >> dependency that is not needed. > > There is already code using the new bindings, for the idle states. > Please have look at patch 5, 6 and 11. Should be 5, 6 and 10, sorry. > > Moreover, you have had plenty on time to look at the series, as those > patches haven't changed since a very long time. > > May I suggest you do the review instead, so we can move things > forward, please. The changes in the v9 series should be trivial to > review. > >> >>> > Likewise, it makes no sense to merge patches 7-8 without the rest of >>> > the PSCI patches. > > Well, those patches are part of this series, because Mark wanted me to > move the files. Is really such a big deal? I think it makes sense, no > matter what happens afterwards. > > [...] > > Kind regards > Uffe
On Thu, Oct 04, 2018 at 08:36:24PM +0200, Ulf Hansson wrote: > On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > > On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote: > > > > [...] > > > >> > > I don't see any dependency there, so I'll queue up the 1-3 in > >> > > pm-domains and the 4-6 in pm-cpuidle. > >> > > >> > I do not see why we should merge patches 4-6 for v4.20; they add legacy > >> > (DT bindings and related parsing code) with no user in the kernel; we > >> > may still want to tweak them, in particular PSCI DT bindings. > >> > >> My impression was that 4-6 have been agreed on due to the ACKs they > >> carry. I'll drop them if that's not the case. > > > > I have not expressed myself correctly: they have been agreed (even > > though as I said they may require some tweaking) but I see no urgency > > of merging them in v4.20 since they have no user. They contain DT > > bindings, that create ABI/legacy, I think it is better to have code > > that uses them in the kernel before merging them and creating a > > dependency that is not needed. > > There is already code using the new bindings, for the idle states. > Please have look at patch 5, 6 and 11. I had a look before replying and I reiterate the point, there is no reason to merge those patches without the rest of the series, none. There is already a way to describe idle states in the kernel and it works very well, we will add one when we need it not before. > Moreover, you have had plenty on time to look at the series, as those > patches haven't changed since a very long time. So ? > May I suggest you do the review instead, so we can move things > forward, please. The changes in the v9 series should be trivial to > review. There is no reason to merge patches [4, 5, 6, 10] stand-alone, they are not solving any problem and they do not provide any benefit other than adding useless ABI/legacy, they make sense when we look at the whole series. > >> > Likewise, it makes no sense to merge patches 7-8 without the rest of > >> > the PSCI patches. > > Well, those patches are part of this series, because Mark wanted me to > move the files. Is really such a big deal? I think it makes sense, no > matter what happens afterwards. We can merge patches [7-8] even if there is no urgency at all to do so, usually PSCI patches go via arm-soc whose patches queue is now closed and I do not think that's a problem at all. Lorenzo
On 5 October 2018 at 12:47, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: > On Thu, Oct 04, 2018 at 08:36:24PM +0200, Ulf Hansson wrote: >> On 4 October 2018 at 19:21, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote: >> > On Thu, Oct 04, 2018 at 07:07:27PM +0200, Rafael J. Wysocki wrote: >> > >> > [...] >> > >> >> > > I don't see any dependency there, so I'll queue up the 1-3 in >> >> > > pm-domains and the 4-6 in pm-cpuidle. >> >> > >> >> > I do not see why we should merge patches 4-6 for v4.20; they add legacy >> >> > (DT bindings and related parsing code) with no user in the kernel; we >> >> > may still want to tweak them, in particular PSCI DT bindings. >> >> >> >> My impression was that 4-6 have been agreed on due to the ACKs they >> >> carry. I'll drop them if that's not the case. >> > >> > I have not expressed myself correctly: they have been agreed (even >> > though as I said they may require some tweaking) but I see no urgency >> > of merging them in v4.20 since they have no user. They contain DT >> > bindings, that create ABI/legacy, I think it is better to have code >> > that uses them in the kernel before merging them and creating a >> > dependency that is not needed. >> >> There is already code using the new bindings, for the idle states. >> Please have look at patch 5, 6 and 11. > > I had a look before replying and I reiterate the point, there is > no reason to merge those patches without the rest of the series, > none. There is already a way to describe idle states in the kernel > and it works very well, we will add one when we need it not before. Okay, let's defer them. > >> Moreover, you have had plenty on time to look at the series, as those >> patches haven't changed since a very long time. > > So ? > >> May I suggest you do the review instead, so we can move things >> forward, please. The changes in the v9 series should be trivial to >> review. > > There is no reason to merge patches [4, 5, 6, 10] stand-alone, they > are not solving any problem and they do not provide any benefit > other than adding useless ABI/legacy, they make sense when we look > at the whole series. Okay, let's defer them. > >> >> > Likewise, it makes no sense to merge patches 7-8 without the rest of >> >> > the PSCI patches. >> >> Well, those patches are part of this series, because Mark wanted me to >> move the files. Is really such a big deal? I think it makes sense, no >> matter what happens afterwards. > > We can merge patches [7-8] even if there is no urgency at all to do so, > usually PSCI patches go via arm-soc whose patches queue is now closed > and I do not think that's a problem at all. Okay, let's defer them. That said, can please review the patches? Kind regards Uffe
I have digested the review comments so far, including a recent offlist chat with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I have a plan for how to move forward. However, to avoid re-posting non-changed patches over and over again, I decided to withhold the more debatable part from this v9, hence this is not the complete series to make things play. In v9, I have just included the trivial changes, which are either already acked/reviewed or hopefully can be rather soon/easily. My hope is to get this queued for v4.20, to move things forward. I know it's late, but there are more or less nothing new here since v8. Kind regards Ulf Hansson Changes in v9: - Collect only a subset from the changes in v8. - Patch 3 is new, documenting existing genpd flags. Future wise, this means when a new genpd flag is invented, we must also properly document it. - No changes have been made to the patches picked from v8. - Dropped the text from v8 cover-letter[1], to avoid confusion. When posting v10 (or whatever the next version containing the rest becomes), I am going re-write the cover-letter to clarify, more exactly, the problems this series intends to solve. The earlier text was simply too vague. [1] https://lwn.net/Articles/758091/ Changes in v8: - Added some tags for reviews and acks. - Cleanup timer patch (patch6) according to comments from Rafael. - Rebased series on top of v4.18rc1 - it applied cleanly, except for patch 5. - While adopting patch 5 to new genpd changes, I took the opportunity to improve the new function description a bit. - Corrected malformed SPDX-License-Identifier in patch20. Changes in v7: - Addressed comments concerning the PSCI changes from Mark Rutland, which moves the psci firmware driver to a new firmware subdir and change to force PSCI PC mode during boot to cope with kexec'ed booted kernels. - Added some maintainers in cc for the timer/nohz patches. - Minor update to the new genpd governor, taking into account the state's poweroff latency while validating the sleep duration time. - Addressed a problem pointed out by Geert Uytterhoeven, around calling pm_runtime_get|put() for CPUs that has not been attached to a CPU PM domain. - Re-based on Linus' latest master. Lina Iyer (3): dt: psci: Update DT bindings to support hierarchical PSCI states cpuidle: dt: Support hierarchical CPU idle states drivers: firmware: psci: Support hierarchical CPU idle states Ulf Hansson (8): PM / Domains: Don't treat zero found compatible idle states as an error PM / Domains: Deal with multiple states but no governor in genpd PM / Domains: Document flags for genpd of: base: Add of_get_cpu_state_node() to get idle states for a CPU node drivers: firmware: psci: Move psci to separate directory MAINTAINERS: Update files for PSCI drivers: firmware: psci: Split psci_dt_cpu_init_idle() drivers: firmware: psci: Simplify error path of psci_dt_init() .../devicetree/bindings/arm/psci.txt | 156 ++++++++++++++++++ MAINTAINERS | 2 +- drivers/base/power/domain.c | 20 ++- drivers/cpuidle/dt_idle_states.c | 5 +- drivers/firmware/Kconfig | 15 +- drivers/firmware/Makefile | 3 +- drivers/firmware/psci/Kconfig | 13 ++ drivers/firmware/psci/Makefile | 4 + drivers/firmware/{ => psci}/psci.c | 70 ++++---- drivers/firmware/{ => psci}/psci_checker.c | 0 drivers/of/base.c | 35 ++++ include/linux/of.h | 8 + include/linux/pm_domain.h | 35 +++- 13 files changed, 302 insertions(+), 64 deletions(-) create mode 100644 drivers/firmware/psci/Kconfig create mode 100644 drivers/firmware/psci/Makefile rename drivers/firmware/{ => psci}/psci.c (95%) rename drivers/firmware/{ => psci}/psci_checker.c (100%)