EBBR platforms are unlikely to ever use the MP Start protocol used in
some AArch64 server systems. It was only used to support platforms
without EL3. No more EL2-only platforms are expected, and MP Start is
being removed from the next release of SBBR. Devicetree platforms in the
same scenario use the Linux spin table protocol instead.
MP Start was only included for completeness to align the SBBR and EBBR
specifications. Therefore remove it entirely, leaving PSCI and spin
table as the only acceptable implementations.
Also revert to PSCI v1.0 as that is the minimum level of functionality
required. PSCI v1.1 adds new capabilities, but is not required for
interoperability.
Suggested-by: Dong Wei <dong.wei(a)arm.com>
Signed-off-by: Grant Likely <grant.likely(a)arm.com>
---
source/ebbr.rst | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/source/ebbr.rst b/source/ebbr.rst
index 40f03f1..4100b2f 100644
--- a/source/ebbr.rst
+++ b/source/ebbr.rst
@@ -329,10 +329,9 @@ Power State Coordination Interface specification[PSCI_].
Platforms without EL3 must implement one of:
- PSCI at EL2 (leaving only EL1 available to an operating system)
-- MP Startup for Arm[MPSTART_] (ACPI Parking Protocol) on an ACPI platform
-- Linux AArch64 spin tables[LINUXA64BOOT_] on a Devicetree platform
+- Linux AArch64 spin tables[LINUXA64BOOT_] (Devicetree only)
-However, the MP Startup and Spintable protocols are strongly discouraged.
+However, the spin table protocol is strongly discouraged.
Future versions of this specification will only allow PSCI, and PSCI should
be implemented in all new designs.
@@ -575,13 +574,9 @@ EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2
<https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tre…>`_,
Linux kernel
-.. [MPSTART] `MP Startup for Arm
- <https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.…>`_,
- 20 December 2012, `Microsoft <http://microsoft.com>`_
-
-.. [PSCI] `Power State Coordination Interface Issue D (PSCI v1.1)
- <http://infocenter.arm.com/help//topic/com.arm.doc.den0022d/Power_State_Coor…>`_,
- 21 April 2017, `Arm Limited <http://arm.com>`_
+.. [PSCI] `Power State Coordination Interface Issue C (PSCI v1.0)
+ <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_
+ 30 January 2015, `Arm Limited <http://arm.com>`_
.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0)
<https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_
--
2.13.0
On 18/05/2018 18:08, Mark Brown wrote:
> On Fri, May 18, 2018 at 06:04:11PM +0100, Grant Likely wrote:
>
>> My bikeshed now has a sign that reads:
>
>> +As stated above, EBBR systems must not provide both ACPI
>> +and Devicetree tables at the same time.
>> +Systems that support both interfaces must provide a configuration
>> +mechanism to select either ACPI or Devicetree,
>> +and must ensure only the selected interface is provided
>> +to the OS loader.
>
> I think that's a very pleasing shade, thanks! :)
>
> (Sorry, I spent far too long working on interoperability of some
> particularly poorly specified networking standards so now have
> difficulty reading any spec without assuming the worst.)
>
Thanks! I'll take that as you're Acked-by then. :-)
g.
On 18/05/2018 17:45, Mark Brown wrote:
> On Fri, May 18, 2018 at 05:28:10PM +0100, Grant Likely wrote:
>
>> +Devicetree tables at the same time. Platforms that want to offer
>> +both ACPI and Devicetree solutions must implement a boot time
>> +mechanism to select one or the other, before the OS Loader is
>> +executed.
>
> How about "...must configure this using a mechanism that ensures that
> one or the other is chosen and provided to the OS loader when it is
> executed"? It doesn't really matter for sensible systems but I can see
> someone misreading the above and thinking there must be a prompt on boot
> or something, I do think this is me being paranoid about perverse
> implementors though.
>
My bikeshed now has a sign that reads:
+As stated above, EBBR systems must not provide both ACPI
+and Devicetree tables at the same time.
+Systems that support both interfaces must provide a configuration
+mechanism to select either ACPI or Devicetree,
+and must ensure only the selected interface is provided
+to the OS loader.
g.
On 18/05/2018 14:18, Tom Rini wrote:
> On Fri, May 18, 2018 at 02:06:08PM +0100, Grant Likely wrote:
>
>> Use reStructuredText citation markup to capture all referenced
>> documents. Sphinx will take care of creating a table of references at
>> the end of the document.
>>
>> Fixes #6
>> Signed-off-by: Grant Likely <grant.likely(a)arm.com>
> [snip]
>> @@ -132,22 +115,11 @@ This document defines the boot and runtime services that are expected by an
>> Operating System or hypervisor, for an ARM embedded device, which follows the
>> UEFI specification.
>>
>> -This document references the following specification and versions:
>> -
>> - UEFI 2.7
>> - Published June 2017, includes the AArch64 bindings.
>> -
>
> Is it clear enough when rendering the final document that here we don't
> need a link down to the UEFI reference?
Not sure what you mean. Can you elaborate?
I do think the introduction chapter needs to be reworked anyway to talk
about standardizing the firmware interface. It too quickly jumps to
"when UEFI is chosen", when what I'd rather it present is "here is a
standardized platform taylored to embedded systems"... and then get to
UEFI is part of that standard.
(it isn't about chosing UEFI; it is about choosing a standard platform)
>
>> This specification defines the boot and runtime services for a physical system,
>> including services that are required for virtualization.
>> It does not define a standardized abstract virtual machine view for a Guest
>> Operating System.
>>
>> -When present with in a system, this document makes additional references to the
>> -Power State Coordination Interface:
>> -
>> - PSCI 1.1
>> - Published April 2017.
>> -
> [snip]
>> @@ -306,9 +278,10 @@ command:
>>
>> - EfiWarmReset()
>>
>> -.. note:: When Runtime Services and PSCI co-exist, it is anticipated that
>> - Operating System calls to reset the system will go via Runtime Services and
>> - not directly to PSCI.
>> +.. note:: On platforms implementing the Power State Coordination Interface
>> + specification[PSCI_], it is still required that EBBR compliant
>> + Operating Systems calls to reset the system will go via Runtime Services
>> + and not directly to PSCI.
>>
>> Set Variable
>> ------------
>
> Is all of the above equivalent in terms of talking about PSCI? Thanks!
Ummm, yes? But I'm not sure that I understand what you're asking.
Thanks for the reviews on all the other patches.
g.
I'm adding some EBBR text around the CPU state at boot and I've lost
track of what is being done for multicore bringup. What is the current
state-of-the-art for multicore boot protocol when PSCI isn't available?
SBBR allows for the MP Boot Protocol; with the intend of phasing it out:
https://acpica.org/sites/acpica/files/MP%20Startup%20for%20ARM%20platforms.…
The kernel documents the spin table method:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tre…
What are the cool kids currently doing here?
g.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On the weekly call today I suggested for people to assign issues to
themselves if they wanted to take it on. Turns out GitHub doesn't allow
that unless you've got write access to the project. So, if you want to
take on an issue, add a comment saying so and I'll send you an invite to
join the project.
Once you've accepted the invite I can assign issues to you.
g.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Deferred probe will currently wait forever on dependent devices to probe,
but sometimes a driver will never exist. It's also not always critical for
a driver to exist. Platforms can rely on default configuration from the
bootloader or reset defaults for things such as pinctrl and power domains.
This is often the case with initial platform support until various drivers
get enabled. There's at least 2 scenarios where deferred probe can render
a platform broken. Both involve using a DT which has more devices and
dependencies than the kernel supports. The 1st case is a driver may be
disabled in the kernel config. The 2nd case is the kernel version may
simply not have the dependent driver. This can happen if using a newer DT
(provided by firmware perhaps) with a stable kernel version.
Unfortunately, this change breaks with modules as we have no way of
knowing when modules are done loading. One possibility is to make this
opt in or out based on compatible strings rather than at a subsystem level.
Ideally this information could be extracted automatically somehow. OTOH,
maybe the lists are pretty small. There's only a handful of subsystems
that can be optional, and then only so many drivers in those that can be
modules (at least for pinctrl, many drivers are built-in only).
Cc: Alexander Graf <agraf(a)suse.de>
Signed-off-by: Rob Herring <robh(a)kernel.org>
---
This patch came out of a discussion on the ARM boot-architecture
list[1] about DT forwards and backwards compatibility issues. There are
issues with newer DTs breaking on older, stable kernels. Some of these
are difficult to solve, but cases of optional devices not having
kernel support should be solvable.
I tested this on a RPi3 B with the pinctrl driver forced off. With this
change, the MMC/SD and UART drivers can function without the pinctrl
driver.
Rob
[1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html
drivers/base/dd.c | 16 ++++++++++++++++
drivers/pinctrl/devicetree.c | 2 +-
include/linux/device.h | 2 ++
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index c9f54089429b..5848808b9d7a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -226,6 +226,15 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+
+int driver_deferred_probe_optional(void)
+{
+ if (initcalls_done)
+ return -ENODEV;
+
+ return -EPROBE_DEFER;
+}
+
/**
* deferred_probe_initcall() - Enable probing of deferred devices
*
@@ -240,6 +249,13 @@ static int deferred_probe_initcall(void)
/* Sort as many dependencies as possible before exiting initcalls */
flush_work(&deferred_probe_work);
initcalls_done = true;
+
+ /*
+ * Trigger deferred probe again, this time we won't defer anything
+ * that is optional
+ */
+ driver_deferred_probe_trigger();
+ flush_work(&deferred_probe_work);
return 0;
}
late_initcall(deferred_probe_initcall);
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index b601039d6c69..096e52a5c506 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -120,7 +120,7 @@ static int dt_to_map_one_config(struct pinctrl *p,
np_config);
of_node_put(np_pctldev);
/* OK let's just assume this will appear later then */
- return -EPROBE_DEFER;
+ return driver_deferred_probe_optional();
}
/* If we're creating a hog we can use the passed pctldev */
if (pctldev && (np_pctldev == p->dev->of_node))
diff --git a/include/linux/device.h b/include/linux/device.h
index 0059b99e1f25..8de920442bc1 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -332,6 +332,8 @@ struct device *driver_find_device(struct device_driver *drv,
struct device *start, void *data,
int (*match)(struct device *dev, void *data));
+int driver_deferred_probe_optional(void);
+
/**
* struct subsys_interface - interfaces to device functions
* @name: name of the device function
--
2.17.0