| Message ID | 20240221233026.2915061-1-saravanak@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add post-init-providers binding to improve suspend/resume stability | expand |
On Wed, Feb 21, 2024 at 03:30:20PM -0800, Saravana Kannan wrote: > This patch series adds a "post-init-providers" device tree binding that > can be used to break dependency cycles in device tree and enforce a more > determinstic probe/suspend/resume order. This will also improve the > stability of global async probing and async suspend/resume and allow us > to enable them more easily. Yet another step away from playing initcall > chicken with probing and step towards fully async probing and > suspend/resume. Do you know what is the state of affairs in ACPI? Is there any (similar) issue even possible?
On Thu, Feb 22, 2024 at 5:34 AM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Wed, Feb 21, 2024 at 03:30:20PM -0800, Saravana Kannan wrote: > > This patch series adds a "post-init-providers" device tree binding that > > can be used to break dependency cycles in device tree and enforce a more > > determinstic probe/suspend/resume order. This will also improve the > > stability of global async probing and async suspend/resume and allow us > > to enable them more easily. Yet another step away from playing initcall > > chicken with probing and step towards fully async probing and > > suspend/resume. > > Do you know what is the state of affairs in ACPI? Is there any (similar) > issue even possible? I'm not very familiar with ACPI, but I wouldn't be surprised if ACPI devices have cyclic dependencies. But then ACPI on a PC doesn't typically have as many devices/drivers and ACPI might be hiding the dependencies from the kernel. So maybe the possibility of a cycle visible to the kernel might be low. I would really like to see fw_devlink extended to ACPI (it's written in a way to make that possible), but don't have enough knowledge to do it. -Saravana
On Fri, Feb 23, 2024 at 1:03 AM Saravana Kannan <saravanak@google.com> wrote: > > On Thu, Feb 22, 2024 at 5:34 AM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Wed, Feb 21, 2024 at 03:30:20PM -0800, Saravana Kannan wrote: > > > This patch series adds a "post-init-providers" device tree binding that > > > can be used to break dependency cycles in device tree and enforce a more > > > determinstic probe/suspend/resume order. This will also improve the > > > stability of global async probing and async suspend/resume and allow us > > > to enable them more easily. Yet another step away from playing initcall > > > chicken with probing and step towards fully async probing and > > > suspend/resume. > > > > Do you know what is the state of affairs in ACPI? Is there any (similar) > > issue even possible? > > I'm not very familiar with ACPI, but I wouldn't be surprised if ACPI > devices have cyclic dependencies. But then ACPI on a PC doesn't > typically have as many devices/drivers and ACPI might be hiding the > dependencies from the kernel. So maybe the possibility of a cycle > visible to the kernel might be low. > > I would really like to see fw_devlink extended to ACPI (it's written > in a way to make that possible), but don't have enough knowledge to do > it. This might happen one day, for example in the _DEP handling context (for now it is very limited, but I'm not actually sure how much more capable it needs to be). I don't think that ACPI will ever need device links between parents and children, though. On a related note, RISC-V people seem to want to use it on ACPI systems for interrupt controller dependency tracking.
This patch series adds a "post-init-providers" device tree binding that can be used to break dependency cycles in device tree and enforce a more determinstic probe/suspend/resume order. This will also improve the stability of global async probing and async suspend/resume and allow us to enable them more easily. Yet another step away from playing initcall chicken with probing and step towards fully async probing and suspend/resume. Patch 3 (the binding documentation) provides a lot more details and examples. v2->v3: - Changes doc/code from "post-init-supplier" to "post-init-providers" - Fixed some wording that was ambiguous for Conor. - Fixed indentation, additionalProperties and white space issues in the yaml syntax. - Fixed syntax errors in the example. v1->v2: - Addressed Documentation/commit text errors pointed out by Rob - Reordered MAINTAINERS chunk as pointed out by Krzysztof Saravana Kannan (4): driver core: Adds flags param to fwnode_link_add() driver core: Add FWLINK_FLAG_IGNORE to completely ignore a fwnode link dt-bindings: Add post-init-providers property of: property: fw_devlink: Add support for "post-init-providers" property .../bindings/post-init-providers.yaml | 105 ++++++++++++++++++ MAINTAINERS | 13 ++- drivers/base/core.c | 14 ++- drivers/firmware/efi/sysfb_efi.c | 2 +- drivers/of/property.c | 17 ++- include/linux/fwnode.h | 5 +- 6 files changed, 142 insertions(+), 14 deletions(-) create mode 100644 Documentation/devicetree/bindings/post-init-providers.yaml