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  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]
Date:   Tue, 5 May 2020 16:04:21 +0100
From:   Sudeep Holla <>
To:     Arnd Bergmann <>
Cc:     Peng Fan <>, Marc Zyngier <>,
        Steven Price <>,
        Will Deacon <>,
        Catalin Marinas <>,
        Sudeep Holla <>,
        Mark Rutland <>,
Subject: Re: [PATCH] firmware: arm_scmi: fix psci dependency

Hi Arnd,

On Tue, May 05, 2020 at 04:08:08PM +0200, Arnd Bergmann wrote:
> When CONFIG_ARM_PSCI_FW is disabled but CONFIG_HAVE_ARM_SMCCC is enabled,
> arm-scmi runs into a link failure:
> arm-linux-gnueabi-ld: drivers/firmware/arm_scmi/smc.o: in function `smc_send_message':
> smc.c:(.text+0x200): undefined reference to `arm_smccc_1_1_get_conduit'
> Use an inline helper to default to version v1.0 in the absence of psci.

Thanks for fixing this. I was thinking if we can separate PSCI and SMCCC
quickly as a fix for this but I think he needs to be discussed in detail.

I am fine with this fix as is and happy to apply to my tree if no one

Sorry but taking this patch as opportunity to discuss how to carry the
dependency in future. Just a proposal,

1. Introduce a DT node for SMCCC v1.2+
2. The new SMCCC driver(strictly speaking library/few APIs) can probe 
   independent of PSCI if DT node is present
3. Else we fallback on PSCI and detect the SMCCC version for v1.1 and
4. Assume v1.0 if
	b. CONFIG_ARM_PSCI{,_FW} is not defined


Any other use-case config missed above ?


Powered by blists - more mailing lists