From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ang, Chee Hong Date: Wed, 13 Mar 2019 08:10:31 +0000 Subject: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI In-Reply-To: <20190311194811.GB4690@bill-the-cat> References: <1549960023-124134-1-git-send-email-chee.hong.ang@intel.com> <20190308180953.GH5026@bill-the-cat> <1552318071.25078.20.camel@intel.com> <20190311194811.GB4690@bill-the-cat> Message-ID: <1552464631.25816.0.camel@intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote: > On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote: > > > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote: > > > > > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel.com > > > wrote: > > > > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > Currently u-boot only support standard PSCI functions for power > > > > management > > > > and lack of convenient method to allow the users to extend the > > > > PSCI > > > > functions > > > > to support platform specific services. Most of the u-boot users > > > > still rely > > > > on ATF (ARM Trusted Firmware) to handle the standard power > > > > management and > > > > platform specific PSCI services. > > > > The purpose of this patchsets is to allow u-boot users to > > > > support > > > > their > > > > own platform specific secure SMC/PSCI services without making > > > > any > > > > SMC calls to ATF. This will benefit the users who need to use > > > > u- > > > > boot as the > > > > only bootloader and secure service provider without relying on > > > > ATF. > > > > > > > > Below is a simple code example for adding your own PSCI > > > > functions: > > > > > > > > #include > > > > #include > > > > #include > > > > #include > > > > #include > > > > > > > > #define PSCI_SMC64_FUNC_ID1 0xC2000001 > > > > #define PSCI_SMC64_FUNC_ID2 0xC2000002 > > > > > > > > static void __secure psci_plat_specific_func1(unsigned long > > > > function_id) > > > > { > > > > /* Your code for handling the SMC/PSCI platform > > > > specific > > > > service 1 */ > > > > } > > > > > > > > static void __secure psci_plat_specific_func2(unsigned long > > > > function_id) > > > > { > > > > /* Your code for handling the SMC/PSCI platform > > > > specific > > > > service 2 */ > > > > } > > > > > > > > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, > > > >    psci_plat_specific_func1); > > > > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, > > > >    psci_plat_specific_func2); > > > > > > > > Ang, Chee Hong (1): > > > >   ARMv8: Disable fwcall when PSCI is enabled > > > > > > > > Chee Hong Ang (1): > > > >   ARMv8: Allow SiP service extensions on top of PSCI code > > > Conceptually, I suppose this is a logical step.  In specifics, > > > would > > > we > > > want to make this functionality opt-in, or no, that doesn't make > > > sense? > > > > > Allowing user to add platform specific service is part of SMC/PSCI > > specification as specifed in ARM document (Table 2-1): > > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN00 > > 28B_ > > SMC_Calling_Convention.pdf > > > > So I think this functionality should be part of the standard > > PSCI/SMC > > implementation. Currently u-boot only support standard PSCI call > > which > > is: > > ---------------------------------------------- > > > > > > 0x84000000-0x8400001F  | PSCI 32-bit calls | > > > 0xC4000000-0xC400001F  | PSCI 64-bit calls | > > ---------------------------------------------- > > > > My implementation do not affect or alter the behavior of any > > existing > > standard PSCI calls. > > > > Users can simply add their own platform specific services by using > > the > > service call range as below: > > ---------------------------------------------------- > > > > > > 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls | > > > 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls | > > ---------------------------------------------------- > > > > For complete service call ranges please refer to Table 6-2 in the > > ARM > > document. > OK, thanks! > Any chance this enhancement get accepted ? Thanks.