| Message ID | 20240221233026.2915061-4-saravanak@google.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | Add post-init-providers binding to improve suspend/resume stability | expand |
On Wed, 21 Feb 2024 15:30:23 -0800, Saravana Kannan wrote: > The post-init-providers property can be used to break a dependency cycle by > marking some provider(s) as a post device initialization provider(s). This > allows an OS to do a better job at ordering initialization and > suspend/resume of the devices in a dependency cycle. > > Signed-off-by: Saravana Kannan <saravanak@google.com> > --- > .../bindings/post-init-providers.yaml | 105 ++++++++++++++++++ > MAINTAINERS | 13 ++- > 2 files changed, 112 insertions(+), 6 deletions(-) > create mode 100644 Documentation/devicetree/bindings/post-init-providers.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@1000: failed to match any schema with compatible: ['vendor,soc4-gcc', 'vendor,soc1-gcc'] Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@1000: failed to match any schema with compatible: ['vendor,soc4-gcc', 'vendor,soc1-gcc'] Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@2000: failed to match any schema with compatible: ['vendor,soc4-dispcc', 'vendor,soc1-dispcc'] Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@2000: failed to match any schema with compatible: ['vendor,soc4-dispcc', 'vendor,soc1-dispcc'] doc reference errors (make refcheckdocs): Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/post-init-supplier.yaml MAINTAINERS: Documentation/devicetree/bindings/post-init-supplier.yaml See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240221233026.2915061-4-saravanak@google.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
On Wed, Feb 21, 2024 at 4:23 PM Rob Herring <robh@kernel.org> wrote: > > > On Wed, 21 Feb 2024 15:30:23 -0800, Saravana Kannan wrote: > > The post-init-providers property can be used to break a dependency cycle by > > marking some provider(s) as a post device initialization provider(s). This > > allows an OS to do a better job at ordering initialization and > > suspend/resume of the devices in a dependency cycle. > > > > Signed-off-by: Saravana Kannan <saravanak@google.com> > > --- > > .../bindings/post-init-providers.yaml | 105 ++++++++++++++++++ > > MAINTAINERS | 13 ++- > > 2 files changed, 112 insertions(+), 6 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/post-init-providers.yaml > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@1000: failed to match any schema with compatible: ['vendor,soc4-gcc', 'vendor,soc1-gcc'] > Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@1000: failed to match any schema with compatible: ['vendor,soc4-gcc', 'vendor,soc1-gcc'] > Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@2000: failed to match any schema with compatible: ['vendor,soc4-dispcc', 'vendor,soc1-dispcc'] > Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@2000: failed to match any schema with compatible: ['vendor,soc4-dispcc', 'vendor,soc1-dispcc'] I'm assuming it's okay to ignore these warnings about made up compatible string names. > doc reference errors (make refcheckdocs): > Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/post-init-supplier.yaml > MAINTAINERS: Documentation/devicetree/bindings/post-init-supplier.yaml Will fix this and send out v4. Ignore the v3 series please. -Saravana > > See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240221233026.2915061-4-saravanak@google.com > > The base for the series is generally the latest rc1. A different dependency > should be noted in *this* patch. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit after running the above command yourself. Note > that DT_SCHEMA_FILES can be set to your schema file to speed up checking > your schema. However, it must be unset to test all examples with your schema. >
On 22/02/2024 04:41, Saravana Kannan wrote: > On Wed, Feb 21, 2024 at 4:23 PM Rob Herring <robh@kernel.org> wrote: >> >> >> On Wed, 21 Feb 2024 15:30:23 -0800, Saravana Kannan wrote: >>> The post-init-providers property can be used to break a dependency cycle by >>> marking some provider(s) as a post device initialization provider(s). This >>> allows an OS to do a better job at ordering initialization and >>> suspend/resume of the devices in a dependency cycle. >>> >>> Signed-off-by: Saravana Kannan <saravanak@google.com> >>> --- >>> .../bindings/post-init-providers.yaml | 105 ++++++++++++++++++ >>> MAINTAINERS | 13 ++- >>> 2 files changed, 112 insertions(+), 6 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/post-init-providers.yaml >>> >> >> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' >> on your patch (DT_CHECKER_FLAGS is new in v5.13): >> >> yamllint warnings/errors: >> >> dtschema/dtc warnings/errors: >> Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@1000: failed to match any schema with compatible: ['vendor,soc4-gcc', 'vendor,soc1-gcc'] >> Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@1000: failed to match any schema with compatible: ['vendor,soc4-gcc', 'vendor,soc1-gcc'] >> Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@2000: failed to match any schema with compatible: ['vendor,soc4-dispcc', 'vendor,soc1-dispcc'] >> Documentation/devicetree/bindings/post-init-providers.example.dtb: /example-0/clock-controller@2000: failed to match any schema with compatible: ['vendor,soc4-dispcc', 'vendor,soc1-dispcc'] > > I'm assuming it's okay to ignore these warnings about made up > compatible string names. No, unfortunately not. I think you need to come with a real example or just drop compatibles. BTW, I still don't see any users of this binding. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/post-init-providers.yaml b/Documentation/devicetree/bindings/post-init-providers.yaml new file mode 100644 index 000000000000..92eb9a027443 --- /dev/null +++ b/Documentation/devicetree/bindings/post-init-providers.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020, Google LLC. All rights reserved. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/post-init-providers.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Post device initialization providers + +maintainers: + - Saravana Kannan <saravanak@google.com> + +description: | + This property is used to indicate that the device(s) pointed to by the + property are not needed for the initialization of the device that lists this + property. This property does not make a device (that's previously not a + provider) into a provider. It simply downgrades an existing provider to a + post device initialization provider. + + A device can list its providers in devicetree using one or more of the + standard devicetree bindings. By default, it is assumed that the provider + device can be initialized before the consumer device is initialized. + + However, that assumption cannot be made when there are cyclic dependencies + between devices. Since each device is a provider (directly or indirectly) of + the others in the cycle, there is no guaranteed safe order for initializing + the devices in a cycle. We can try to initialize them in an arbitrary order + and eventually successfully initialize all of them, but that doesn't always + work well. + + For example, say, + * The device tree has the following cyclic dependency X -> Y -> Z -> X (where + -> denotes "depends on"). + * But X is not needed to fully initialize Z (X might be needed only when a + specific functionality is requested post initialization). + + If all the other -> are mandatory initialization dependencies, then trying to + initialize the devices in a loop (or arbitrarily) will always eventually end + up with the devices being initialized in the order Z, Y and X. + + However, if Y is an optional provider for X (where X provides limited + functionality when Y is not initialized and providing its services), then + trying to initialize the devices in a loop (or arbitrarily) could end up with + the devices being initialized in the following order: + + * Z, Y and X - All devices provide full functionality + * Z, X and Y - X provides partial functionality + * X, Z and Y - X provides partial functionality + + However, we always want to initialize the devices in the order Z, Y and X + since that provides the full functionality without interruptions. + + One alternate option that might be suggested is to have the driver for X + notice that Y became available at a later point and adjust the functionality + it provides. However, other userspace applications could have started using X + with the limited functionality before Y was available and it might not be + possible to transparently transition X or the users of X to full + functionality while X is in use. + + Similarly, when it comes to suspend (resume) ordering, it's unclear which + device in a dependency cycle needs to be suspended/resumed first and trying + arbitrary orders can result in system crashes or instability. + + Explicitly calling out which link in a cycle needs to be broken when + determining the order, simplifies things a lot, improves efficiency, makes + the behavior more deterministic and maximizes the functionality that can be + provided without interruption. + + This property is used to provide this additional information between devices + in a cycle by telling which provider(s) is not needed for initializing the + device that lists this property. + + In the example above, Z would list X as a post-init-providers and the + initialization dependency would become X -> Y -> Z -/-> X. So the best order + to initialize them becomes clear: Z, Y and then X. + +select: true + +properties: + post-init-providers: + # One or more providers can be marked as post initialization provider + description: + List of phandles to providers that are not needed for initializing or + resuming this device. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 + +additionalProperties: true + +examples: + - | + gcc: clock-controller@1000 { + compatible = "vendor,soc4-gcc", "vendor,soc1-gcc"; + reg = <0x1000 0x80>; + clocks = <&dispcc 0x1>; + #clock-cells = <1>; + post-init-providers = <&dispcc>; + }; + dispcc: clock-controller@2000 { + compatible = "vendor,soc4-dispcc", "vendor,soc1-dispcc"; + reg = <0x2000 0x80>; + clocks = <&gcc 0xdd>; + #clock-cells = <1>; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 9ed4d3868539..5c97a0b5e9c1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6060,12 +6060,6 @@ S: Maintained F: drivers/base/devcoredump.c F: include/linux/devcoredump.h -DEVICE DEPENDENCY HELPER SCRIPT -M: Saravana Kannan <saravanak@google.com> -L: linux-kernel@vger.kernel.org -S: Maintained -F: scripts/dev-needs.sh - DEVICE DIRECT ACCESS (DAX) M: Dan Williams <dan.j.williams@intel.com> M: Vishal Verma <vishal.l.verma@intel.com> @@ -8300,6 +8294,13 @@ F: include/linux/firewire.h F: include/uapi/linux/firewire*.h F: tools/firewire/ +FIRMWARE DEVICE LINK (fw_devlink) +M: Saravana Kannan <saravanak@google.com> +L: linux-kernel@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/post-init-supplier.yaml +F: scripts/dev-needs.sh + FIRMWARE FRAMEWORK FOR ARMV8-A M: Sudeep Holla <sudeep.holla@arm.com> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
The post-init-providers property can be used to break a dependency cycle by marking some provider(s) as a post device initialization provider(s). This allows an OS to do a better job at ordering initialization and suspend/resume of the devices in a dependency cycle. Signed-off-by: Saravana Kannan <saravanak@google.com> --- .../bindings/post-init-providers.yaml | 105 ++++++++++++++++++ MAINTAINERS | 13 ++- 2 files changed, 112 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/post-init-providers.yaml