From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, "Andrew Davis" <afd@ti.com>,
"Andrew Lunn" <andrew@lunn.ch>, "Arnd Bergmann" <arnd@arndb.de>,
"Bjorn Andersson" <andersson@kernel.org>,
"Chen-Yu Tsai" <wens@kernel.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Michal Simek" <michal.simek@amd.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Nishanth Menon" <nm@ti.com>, "Olof Johansson" <olof@lixom.net>,
"Rafał Miłecki" <zajec5@gmail.com>,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org,
workflows@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
Date: Wed, 29 Nov 2023 09:47:42 +0100 [thread overview]
Message-ID: <CAMuHMdVSAgihFAuPecyrR+Wvzqr58z_fkWkShOSu+HnHzZnW2g@mail.gmail.com> (raw)
In-Reply-To: <ZWboWqELHbIrblnz@francesco-nb.int.toradex.com>
Hi Francesco,
On Wed, Nov 29, 2023 at 8:29 AM Francesco Dolcini <francesco@dolcini.it> wrote:
> On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> > Document preferred coding style for Devicetree sources (DTS and DTSI),
> > to bring consistency among all (sub)architectures and ease in reviews.
>
> Thank Krzysztof, we had most of this collected as BKM in some internal
> documents and it's great to see the effort to consolidate this and add
> it to the kernel documentation.
>
> > ---
> > +Following order of properties in device nodes is preferred:
> > +
> > +1. compatible
> > +2. reg
> > +3. ranges
> > +4. Standard/common properties (defined by common bindings, e.g. without
> > + vendor-prefixes)
> > +5. Vendor-specific properties
> > +6. status (if applicable)
> > +7. Child nodes, where each node is preceded with a blank line
>
> On point 4, do you have a more explicit way to define what is an actual
> standard/common property? You mention the vendor-prefixes as an example,
> is this just an example or this is the whole definition?
I think there are three classes of standard properties:
1. Device Tree Specification (from devicetree.org)
2. dt-schema
3. Common subsystem bindings (Documentation/devicetree/bindings/)
(may be moved to 2).
> What would be the order for this for example (from an existing DTS file)?
>
> reg_sdhc1_vmmc: regulator-sdhci1 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_sd1_pwr_en>;
> enable-active-high;
> gpio = <&main_gpio0 29 GPIO_ACTIVE_HIGH>;
> off-on-delay-us = <100000>;
> regulator-max-microvolt = <3300000>;
> regulator-min-microvolt = <3300000>;
> regulator-name = "+V3.3_SD";
> startup-delay-us = <2000>;
> };
>
> I guess the point that is not obvious to me here is where do we want
> pinctrl. I like it at position between 3 and 4, the rationale is that is
> a very frequent property and this way it will be in a similar place for
> every node.
The pinctrl properties are only present in board DTS files, not in
SoC DTSi files. There are two classes of them:
1. Extension of on-SoC devices, where they are added to already
existing nodes, defined in the SoC DTSi files, e.g. (from the same
existing DTS file):
&cpsw3g {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rgmii1>;
status = "disabled";
};
2. Pure board devices, in new nodes (e.g. your regulator example).
These are less common, so I don't even know from the top of my
mind when I last added one, and where ;-)
I'd guess after all standard properties?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, "Andrew Davis" <afd@ti.com>,
"Andrew Lunn" <andrew@lunn.ch>, "Arnd Bergmann" <arnd@arndb.de>,
"Bjorn Andersson" <andersson@kernel.org>,
"Chen-Yu Tsai" <wens@kernel.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Michal Simek" <michal.simek@amd.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Nishanth Menon" <nm@ti.com>, "Olof Johansson" <olof@lixom.net>,
"Rafał Miłecki" <zajec5@gmail.com>,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org,
workflows@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
Date: Wed, 29 Nov 2023 09:47:42 +0100 [thread overview]
Message-ID: <CAMuHMdVSAgihFAuPecyrR+Wvzqr58z_fkWkShOSu+HnHzZnW2g@mail.gmail.com> (raw)
In-Reply-To: <ZWboWqELHbIrblnz@francesco-nb.int.toradex.com>
Hi Francesco,
On Wed, Nov 29, 2023 at 8:29 AM Francesco Dolcini <francesco@dolcini.it> wrote:
> On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> > Document preferred coding style for Devicetree sources (DTS and DTSI),
> > to bring consistency among all (sub)architectures and ease in reviews.
>
> Thank Krzysztof, we had most of this collected as BKM in some internal
> documents and it's great to see the effort to consolidate this and add
> it to the kernel documentation.
>
> > ---
> > +Following order of properties in device nodes is preferred:
> > +
> > +1. compatible
> > +2. reg
> > +3. ranges
> > +4. Standard/common properties (defined by common bindings, e.g. without
> > + vendor-prefixes)
> > +5. Vendor-specific properties
> > +6. status (if applicable)
> > +7. Child nodes, where each node is preceded with a blank line
>
> On point 4, do you have a more explicit way to define what is an actual
> standard/common property? You mention the vendor-prefixes as an example,
> is this just an example or this is the whole definition?
I think there are three classes of standard properties:
1. Device Tree Specification (from devicetree.org)
2. dt-schema
3. Common subsystem bindings (Documentation/devicetree/bindings/)
(may be moved to 2).
> What would be the order for this for example (from an existing DTS file)?
>
> reg_sdhc1_vmmc: regulator-sdhci1 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_sd1_pwr_en>;
> enable-active-high;
> gpio = <&main_gpio0 29 GPIO_ACTIVE_HIGH>;
> off-on-delay-us = <100000>;
> regulator-max-microvolt = <3300000>;
> regulator-min-microvolt = <3300000>;
> regulator-name = "+V3.3_SD";
> startup-delay-us = <2000>;
> };
>
> I guess the point that is not obvious to me here is where do we want
> pinctrl. I like it at position between 3 and 4, the rationale is that is
> a very frequent property and this way it will be in a similar place for
> every node.
The pinctrl properties are only present in board DTS files, not in
SoC DTSi files. There are two classes of them:
1. Extension of on-SoC devices, where they are added to already
existing nodes, defined in the SoC DTSi files, e.g. (from the same
existing DTS file):
&cpsw3g {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rgmii1>;
status = "disabled";
};
2. Pure board devices, in new nodes (e.g. your regulator example).
These are less common, so I don't even know from the top of my
mind when I last added one, and where ;-)
I'd guess after all standard properties?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, "Andrew Davis" <afd@ti.com>,
"Andrew Lunn" <andrew@lunn.ch>, "Arnd Bergmann" <arnd@arndb.de>,
"Bjorn Andersson" <andersson@kernel.org>,
"Chen-Yu Tsai" <wens@kernel.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Michal Simek" <michal.simek@amd.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Nishanth Menon" <nm@ti.com>, "Olof Johansson" <olof@lixom.net>,
"Rafał Miłecki" <zajec5@gmail.com>,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org,
workflows@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
Date: Wed, 29 Nov 2023 09:47:42 +0100 [thread overview]
Message-ID: <CAMuHMdVSAgihFAuPecyrR+Wvzqr58z_fkWkShOSu+HnHzZnW2g@mail.gmail.com> (raw)
In-Reply-To: <ZWboWqELHbIrblnz@francesco-nb.int.toradex.com>
Hi Francesco,
On Wed, Nov 29, 2023 at 8:29 AM Francesco Dolcini <francesco@dolcini.it> wrote:
> On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> > Document preferred coding style for Devicetree sources (DTS and DTSI),
> > to bring consistency among all (sub)architectures and ease in reviews.
>
> Thank Krzysztof, we had most of this collected as BKM in some internal
> documents and it's great to see the effort to consolidate this and add
> it to the kernel documentation.
>
> > ---
> > +Following order of properties in device nodes is preferred:
> > +
> > +1. compatible
> > +2. reg
> > +3. ranges
> > +4. Standard/common properties (defined by common bindings, e.g. without
> > + vendor-prefixes)
> > +5. Vendor-specific properties
> > +6. status (if applicable)
> > +7. Child nodes, where each node is preceded with a blank line
>
> On point 4, do you have a more explicit way to define what is an actual
> standard/common property? You mention the vendor-prefixes as an example,
> is this just an example or this is the whole definition?
I think there are three classes of standard properties:
1. Device Tree Specification (from devicetree.org)
2. dt-schema
3. Common subsystem bindings (Documentation/devicetree/bindings/)
(may be moved to 2).
> What would be the order for this for example (from an existing DTS file)?
>
> reg_sdhc1_vmmc: regulator-sdhci1 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_sd1_pwr_en>;
> enable-active-high;
> gpio = <&main_gpio0 29 GPIO_ACTIVE_HIGH>;
> off-on-delay-us = <100000>;
> regulator-max-microvolt = <3300000>;
> regulator-min-microvolt = <3300000>;
> regulator-name = "+V3.3_SD";
> startup-delay-us = <2000>;
> };
>
> I guess the point that is not obvious to me here is where do we want
> pinctrl. I like it at position between 3 and 4, the rationale is that is
> a very frequent property and this way it will be in a similar place for
> every node.
The pinctrl properties are only present in board DTS files, not in
SoC DTSi files. There are two classes of them:
1. Extension of on-SoC devices, where they are added to already
existing nodes, defined in the SoC DTSi files, e.g. (from the same
existing DTS file):
&cpsw3g {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rgmii1>;
status = "disabled";
};
2. Pure board devices, in new nodes (e.g. your regulator example).
These are less common, so I don't even know from the top of my
mind when I last added one, and where ;-)
I'd guess after all standard properties?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Francesco Dolcini <francesco@dolcini.it>
Cc: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>,
"AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, "Andrew Davis" <afd@ti.com>,
"Andrew Lunn" <andrew@lunn.ch>, "Arnd Bergmann" <arnd@arndb.de>,
"Bjorn Andersson" <andersson@kernel.org>,
"Chen-Yu Tsai" <wens@kernel.org>,
"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
"Michal Simek" <michal.simek@amd.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Nishanth Menon" <nm@ti.com>, "Olof Johansson" <olof@lixom.net>,
"Rafał Miłecki" <zajec5@gmail.com>,
linux-rockchip@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
linux-amlogic@lists.infradead.org, linux-arm-msm@vger.kernel.org,
workflows@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v3] docs: dt-bindings: add DTS Coding Style document
Date: Wed, 29 Nov 2023 09:47:42 +0100 [thread overview]
Message-ID: <CAMuHMdVSAgihFAuPecyrR+Wvzqr58z_fkWkShOSu+HnHzZnW2g@mail.gmail.com> (raw)
In-Reply-To: <ZWboWqELHbIrblnz@francesco-nb.int.toradex.com>
Hi Francesco,
On Wed, Nov 29, 2023 at 8:29 AM Francesco Dolcini <francesco@dolcini.it> wrote:
> On Sat, Nov 25, 2023 at 07:44:22PM +0100, Krzysztof Kozlowski wrote:
> > Document preferred coding style for Devicetree sources (DTS and DTSI),
> > to bring consistency among all (sub)architectures and ease in reviews.
>
> Thank Krzysztof, we had most of this collected as BKM in some internal
> documents and it's great to see the effort to consolidate this and add
> it to the kernel documentation.
>
> > ---
> > +Following order of properties in device nodes is preferred:
> > +
> > +1. compatible
> > +2. reg
> > +3. ranges
> > +4. Standard/common properties (defined by common bindings, e.g. without
> > + vendor-prefixes)
> > +5. Vendor-specific properties
> > +6. status (if applicable)
> > +7. Child nodes, where each node is preceded with a blank line
>
> On point 4, do you have a more explicit way to define what is an actual
> standard/common property? You mention the vendor-prefixes as an example,
> is this just an example or this is the whole definition?
I think there are three classes of standard properties:
1. Device Tree Specification (from devicetree.org)
2. dt-schema
3. Common subsystem bindings (Documentation/devicetree/bindings/)
(may be moved to 2).
> What would be the order for this for example (from an existing DTS file)?
>
> reg_sdhc1_vmmc: regulator-sdhci1 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_sd1_pwr_en>;
> enable-active-high;
> gpio = <&main_gpio0 29 GPIO_ACTIVE_HIGH>;
> off-on-delay-us = <100000>;
> regulator-max-microvolt = <3300000>;
> regulator-min-microvolt = <3300000>;
> regulator-name = "+V3.3_SD";
> startup-delay-us = <2000>;
> };
>
> I guess the point that is not obvious to me here is where do we want
> pinctrl. I like it at position between 3 and 4, the rationale is that is
> a very frequent property and this way it will be in a similar place for
> every node.
The pinctrl properties are only present in board DTS files, not in
SoC DTSi files. There are two classes of them:
1. Extension of on-SoC devices, where they are added to already
existing nodes, defined in the SoC DTSi files, e.g. (from the same
existing DTS file):
&cpsw3g {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rgmii1>;
status = "disabled";
};
2. Pure board devices, in new nodes (e.g. your regulator example).
These are less common, so I don't even know from the top of my
mind when I last added one, and where ;-)
I'd guess after all standard properties?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next prev parent reply other threads:[~2023-11-29 8:47 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-25 18:44 [PATCH v3] docs: dt-bindings: add DTS Coding Style document Krzysztof Kozlowski
2023-11-25 18:44 ` Krzysztof Kozlowski
2023-11-25 18:44 ` Krzysztof Kozlowski
2023-11-25 18:44 ` Krzysztof Kozlowski
2023-11-25 19:33 ` Jonathan Corbet
2023-11-25 19:33 ` Jonathan Corbet
2023-11-25 19:33 ` Jonathan Corbet
2023-11-25 19:33 ` Jonathan Corbet
2023-11-26 10:28 ` Krzysztof Kozlowski
2023-11-26 10:28 ` Krzysztof Kozlowski
2023-11-26 10:28 ` Krzysztof Kozlowski
2023-11-26 10:28 ` Krzysztof Kozlowski
2023-11-25 19:37 ` Laurent Pinchart
2023-11-25 19:37 ` Laurent Pinchart
2023-11-25 19:37 ` Laurent Pinchart
2023-11-25 19:37 ` Laurent Pinchart
2023-11-25 22:24 ` Konrad Dybcio
2023-11-25 22:24 ` Konrad Dybcio
2023-11-25 22:24 ` Konrad Dybcio
2023-11-25 22:24 ` Konrad Dybcio
2023-11-26 10:32 ` Krzysztof Kozlowski
2023-11-26 10:32 ` Krzysztof Kozlowski
2023-11-26 10:32 ` Krzysztof Kozlowski
2023-11-26 10:32 ` Krzysztof Kozlowski
2023-11-26 14:53 ` Laurent Pinchart
2023-11-26 14:53 ` Laurent Pinchart
2023-11-26 14:53 ` Laurent Pinchart
2023-11-26 14:53 ` Laurent Pinchart
2023-11-27 21:55 ` Rob Herring
2023-11-27 21:55 ` Rob Herring
2023-11-27 21:55 ` Rob Herring
2023-11-27 21:55 ` Rob Herring
2023-11-25 19:47 ` Andrew Lunn
2023-11-25 19:47 ` Andrew Lunn
2023-11-25 19:47 ` Andrew Lunn
2023-11-25 19:47 ` Andrew Lunn
2023-11-26 10:38 ` Krzysztof Kozlowski
2023-11-26 10:38 ` Krzysztof Kozlowski
2023-11-26 10:38 ` Krzysztof Kozlowski
2023-11-26 10:38 ` Krzysztof Kozlowski
2023-11-26 17:48 ` Andrew Lunn
2023-11-26 17:48 ` Andrew Lunn
2023-11-26 17:48 ` Andrew Lunn
2023-11-26 17:48 ` Andrew Lunn
2023-11-29 10:06 ` Krzysztof Kozlowski
2023-11-29 10:06 ` Krzysztof Kozlowski
2023-11-29 10:06 ` Krzysztof Kozlowski
2023-11-29 10:06 ` Krzysztof Kozlowski
2023-11-25 22:26 ` Konrad Dybcio
2023-11-25 22:26 ` Konrad Dybcio
2023-11-25 22:26 ` Konrad Dybcio
2023-11-25 22:26 ` Konrad Dybcio
2023-11-27 14:19 ` Geert Uytterhoeven
2023-11-27 14:19 ` Geert Uytterhoeven
2023-11-27 14:19 ` Geert Uytterhoeven
2023-11-27 14:19 ` Geert Uytterhoeven
2023-11-29 10:16 ` Krzysztof Kozlowski
2023-11-29 10:16 ` Krzysztof Kozlowski
2023-11-29 10:16 ` Krzysztof Kozlowski
2023-11-29 10:16 ` Krzysztof Kozlowski
2023-11-28 20:00 ` Dragan Simic
2023-11-28 20:00 ` Dragan Simic
2023-11-28 20:00 ` Dragan Simic
2023-11-28 20:00 ` Dragan Simic
2023-11-29 10:43 ` Krzysztof Kozlowski
2023-11-29 10:43 ` Krzysztof Kozlowski
2023-11-29 10:43 ` Krzysztof Kozlowski
2023-11-29 10:43 ` Krzysztof Kozlowski
2023-11-29 11:37 ` Dragan Simic
2023-11-29 11:37 ` Dragan Simic
2023-11-29 11:37 ` Dragan Simic
2023-11-29 11:37 ` Dragan Simic
2023-12-03 20:12 ` Dragan Simic
2023-12-03 20:12 ` Dragan Simic
2023-12-03 20:12 ` Dragan Simic
2023-12-03 20:12 ` Dragan Simic
2023-12-04 15:11 ` Krzysztof Kozlowski
2023-12-04 15:11 ` Krzysztof Kozlowski
2023-12-04 15:11 ` Krzysztof Kozlowski
2023-12-04 15:11 ` Krzysztof Kozlowski
2023-12-04 16:19 ` Dragan Simic
2023-12-04 16:19 ` Dragan Simic
2023-12-04 16:19 ` Dragan Simic
2023-12-04 16:19 ` Dragan Simic
2023-11-29 7:29 ` Francesco Dolcini
2023-11-29 7:29 ` Francesco Dolcini
2023-11-29 7:29 ` Francesco Dolcini
2023-11-29 7:29 ` Francesco Dolcini
2023-11-29 8:47 ` Geert Uytterhoeven [this message]
2023-11-29 8:47 ` Geert Uytterhoeven
2023-11-29 8:47 ` Geert Uytterhoeven
2023-11-29 8:47 ` Geert Uytterhoeven
2023-11-29 10:19 ` Krzysztof Kozlowski
2023-11-29 10:19 ` Krzysztof Kozlowski
2023-11-29 10:19 ` Krzysztof Kozlowski
2023-11-29 10:19 ` Krzysztof Kozlowski
2023-11-29 11:16 ` Francesco Dolcini
2023-11-29 11:16 ` Francesco Dolcini
2023-11-29 11:16 ` Francesco Dolcini
2023-11-29 11:16 ` Francesco Dolcini
2023-12-01 16:46 ` Conor Dooley
2023-12-01 16:46 ` Conor Dooley
2023-12-01 16:46 ` Conor Dooley
2023-12-01 16:46 ` Conor Dooley
2023-12-02 13:04 ` Krzysztof Kozlowski
2023-12-02 13:04 ` Krzysztof Kozlowski
2023-12-02 13:04 ` Krzysztof Kozlowski
2023-12-02 13:04 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMuHMdVSAgihFAuPecyrR+Wvzqr58z_fkWkShOSu+HnHzZnW2g@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=afd@ti.com \
--cc=andersson@kernel.org \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=arnd@arndb.de \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=francesco@dolcini.it \
--cc=heiko@sntech.de \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=michal.simek@amd.com \
--cc=neil.armstrong@linaro.org \
--cc=nm@ti.com \
--cc=olof@lixom.net \
--cc=robh+dt@kernel.org \
--cc=wens@kernel.org \
--cc=workflows@vger.kernel.org \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.