On Fri, Jul 06, 2018 at 01:28:20PM -0400, William Mills wrote:
> Grant,
>
> Excellent. Some suggestions in-line:
>
> On 07/06/2018 12:26 PM, Grant Likely wrote:
> > Give some rationale behind EBBR so the reader understands what problem
> > the specification is intended to solve.
> >
> > Signed-o
On 06/07/2018 18:28, William Mills wrote:
Grant,
Excellent. Some suggestions in-line:
On 07/06/2018 12:26 PM, Grant Likely wrote:
Give some rationale behind EBBR so the reader understands what problem
the specification is intended to solve.
Signed-off-by: Bill Mills
[glikely: made it more ve
On Mon, Jul 09, 2018 at 12:07:18PM +0100, Grant Likely wrote:
> On 06/07/2018 18:28, William Mills wrote:
> > Grant,
> >
> > Excellent. Some suggestions in-line:
> >
> > On 07/06/2018 12:26 PM, Grant Likely wrote:
> > > Give some rationale behind EBBR so the reader understands what problem
> > >
On 08/07/2018 22:42, Alexander Graf wrote:
On 06.07.18 18:26, Grant Likely wrote:
Give some rationale behind EBBR so the reader understands what problem
the specification is intended to solve.
Signed-off-by: Bill Mills
[glikely: made it more verbose to make the intent clear]
Signed-off-by: G
Editing in response to comments from Bill Mills, Daniel Thompson, and
Alex Graf. Mostly trivial editorial, but did flush out the discussion of
how future updates to the specification would be handled, and added a
note about DT platform compatibility rules.
Signed-off-by: Grant Likely
Cc: Bill Mil
On 09/07/2018 12:18, Daniel Thompson wrote:
On Mon, Jul 09, 2018 at 12:07:18PM +0100, Grant Likely wrote:
On 06/07/2018 18:28, William Mills wrote:
+- Plan to evolve over time
+
+ The first release of EBBR is firmly targeting current embedded hardware.
+ Future versions will add capabilities
On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote:
> Editing in response to comments from Bill Mills, Daniel Thompson, and
> Alex Graf. Mostly trivial editorial, but did flush out the discussion of
> how future updates to the specification would be handled, and added a
> note about DT pl
On 07/09/2018 08:17 AM, Grant Likely wrote:
> Editing in response to comments from Bill Mills, Daniel Thompson, and
> Alex Graf. Mostly trivial editorial, but did flush out the discussion of
> how future updates to the specification would be handled, and added a
> note about DT platform compatibi
This series 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
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.
Thi
Pin setup may be optional in some cases such as the reset default works
or the pin setup is done by the bootloader. In these cases, it is optional
for the OS to support managing the pin controller and pin setup. In order
to support this scenario, add a property 'pinctrl-use-default' to indicate
tha
Pinctrl drivers are a common dependency which can prevent a system
booting even if the default or bootloader configured settings can work.
If a pinctrl node in DT indicates that the default pin setup can be used
with the 'pinctrl-use-default' property, then only defer probe until
initcalls are done
The IOMMU subsystem has its own mechanism to not defer probe if driver
support is missing. Now that the driver core supports stopping deferring
probe if drivers aren't built-in (and probed), use the driver core
support so the IOMMU specific support can be removed.
Acked-by: Joerg Roedel
Cc: io...
Now that we use the driver core to stop deferred probe for missing
drivers, IOMMU_OF_DECLARE can be removed.
This is slightly less optimal than having a list of built-in drivers in
that we'll now defer probe twice before giving up. This shouldn't have a
significant impact on boot times as past dis
All PM domain drivers must be built-in (at least those using DT), so
there is no point deferring probe after initcalls are done. Continuing
to defer probe may prevent booting successfully even if managing PM
domains is not required. This can happen if the user failed to enable
the driver or if powe
On Mon, Jul 09, 2018 at 09:41:48AM -0600, Rob Herring wrote:
> 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
> bootloade
On Mon, Jul 9, 2018 at 9:52 AM Russell King - ARM Linux
wrote:
>
> On Mon, Jul 09, 2018 at 09:41:48AM -0600, Rob Herring wrote:
> > 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
Grant,
In section 4.2, the /Firmware directory is mentioned. What are the reasons why
this new hierarchy of directories are created? Can we not use the existing /EFI
hierarchy as shown at http://www.uefi.org/registry? I may have missed the
rational when discussed.
If we do need to create a new
On 09/07/2018 18:54, Dong Wei wrote:
Grant,
In section 4.2, the /Firmware directory is mentioned. What are the reasons why
this new hierarchy of directories are created? Can we not use the existing /EFI
hierarchy as shown at http://www.uefi.org/registry? I may have missed the
rational when di
Grant,
We don't need to change anything in the UEFI Spec. All we need to do is to
request the addition of /Firmware directory in the registry. You can send the
request to the USWG chair. There is a link on that page to send the request.
Vendors do have the freedom to choose a name, but the name
20 matches
Mail list logo
