All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: "Artur Świgoń" <a.swigon@samsung.com>
Cc: devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-pm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	myungjoo.ham@samsung.com, "Inki Dae" <inki.dae@samsung.com>,
	"Seung Woo Kim" <sw0312.kim@samsung.com>,
	georgi.djakov@linaro.org, leonard.crestez@nxp.com,
	"Marek Szyprowski" <m.szyprowski@samsung.com>,
	"Bartłomiej Żołnierkiewicz" <b.zolnierkie@samsung.com>
Subject: Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
Date: Tue, 31 Dec 2019 11:38:02 +0100	[thread overview]
Message-ID: <CAJKOXPezRMb0OnpcRWrRheKbBjyzqNXG3TDX-MQkjAm2sTSr1w@mail.gmail.com> (raw)
In-Reply-To: <29ed54c7700e35fb95fff4f4f5580eba24ffbb35.camel@samsung.com>

On Tue, 31 Dec 2019 at 11:23, Artur Świgoń <a.swigon@samsung.com> wrote:
> >
> > The order of patches should reflect first of all real dependency.
> > Whether it compiles, works at all and does not break anything.  Logical
> > dependency of "when the feature will start working" is
> > irrelevant to DTS because DTS goes in separate way and driver is
> > independent of it.
>
> The order of patches does indeed reflect real dependency. I can also reorder
> them (preserving the dependencies) so that DTS patches go first in the series
> if this is the more preferred way.

It looks wrong then. Driver should not depend on DTS. I cannot find
the patch changing bindings (should be first in patchset) which could
also point to this problem.

It seems you added requirement for interconnect properties while it
should be rather optional.

> > > I still think the order of these patches is the most logical one for someone
> > > reading this RFC as a whole.
> >
> > I am sorry but it brings only confusion. DTS is orthogonal of the
> > driver code. You could even post the patchset without DTS (although then
> > it would raise questions where is the user of it, but still, you
> > could).
> >
> > Further, DTS describes also hardware so you could send certain DTS
> > patches without driver implementation to describe the hardware.
> >
> > Driver code and DTS are kind of different worlds so mixing them up for
> > logical review does not really make any sense.
> >
> > Not mentioning it is different than most of other patches on mailing
> > lists.
> >
> > BTW, it is the same as bindings which should (almost) always go first as
> > separate patches.
>
> Thanks for elaborating on this, I appreciate it.
> Regarding your original concern, patches 04 & 06 are separate for several
> reasons, one of which is that they are related to two different drivers
> (exynos-bus vs. exynos-mixer).

It's okay then (for them to be split).

>
> > >
> > > > In certain cases dependency on DTS changes is ok:
> > > > 1. Cleaning up deprecated properties,
> > > > 2. Ignoring the backward compatibility for e.g. new platforms.
> > > >
> > > > None of these are applicable here.
> > > >
> > > > You need to rework it, put DTS changes at the end. This clearly shows
> > > > that there is no wrong dependency.
> > > >
> > > > >
> > > > > > Adjust the title to match the contents - you are not adding bindings but
> > > > > > properties to bus nodes. Also the prefix is ARM: (look at recent
> > > > > > commits).
> > > > >
> > > > > OK.
> > > > >
> > > > > > >
> > > > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > > > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > @@ -90,6 +90,7 @@
> > > > > > >  &bus_dmc {
> > > > > > >     exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > > > > >     vdd-supply = <&buck1_reg>;
> > > > > > > +   #interconnect-cells = <0>;
> > > > > >
> > > > > > This does not look like property of Odroid but Exynos4412 or Exynos4.
> > > > >
> > > > > Strangely enough, this file is where the 'exynos,parent-bus' (aka. 'devfreq')
> > > > > properties are located (and everything in this RFC concerns devfreq).
> > > >
> > > > I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
> > > > you elaborate?
> > >
> > > Currently a name change is being made: 'devfreq' -> 'exynos,parent-bus'
> > > https://patchwork.kernel.org/patch/11304549/
> > > (a dependency of this RFC; also available in devfreq-testing branch)
> >
> > I see. That property also does not look like board (Odroid) specific so
> > it should be moved to Exynos4412 DTSI.
>
> Makes sense to me. Just from looking at the patch I referenced above, there is
> a significant level of code duplication between
> * arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> * arch/arm/boot/dts/exynos4412-midas.dtsi
> * arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> with relation to the devfreq*/exynos,* properties.

If you have in mind all the nodes with "status=okay", it's fine to
duplicate them.

Best regards,
Krzysztof

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzk@kernel.org>
To: "Artur Świgoń" <a.swigon@samsung.com>
Cc: devicetree@vger.kernel.org,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	linux-pm@vger.kernel.org,
	"Bartłomiej Żołnierkiewicz" <b.zolnierkie@samsung.com>,
	"Seung Woo Kim" <sw0312.kim@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	"Inki Dae" <inki.dae@samsung.com>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	myungjoo.ham@samsung.com, leonard.crestez@nxp.com,
	georgi.djakov@linaro.org, linux-arm-kernel@lists.infradead.org,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
Date: Tue, 31 Dec 2019 11:38:02 +0100	[thread overview]
Message-ID: <CAJKOXPezRMb0OnpcRWrRheKbBjyzqNXG3TDX-MQkjAm2sTSr1w@mail.gmail.com> (raw)
In-Reply-To: <29ed54c7700e35fb95fff4f4f5580eba24ffbb35.camel@samsung.com>

On Tue, 31 Dec 2019 at 11:23, Artur Świgoń <a.swigon@samsung.com> wrote:
> >
> > The order of patches should reflect first of all real dependency.
> > Whether it compiles, works at all and does not break anything.  Logical
> > dependency of "when the feature will start working" is
> > irrelevant to DTS because DTS goes in separate way and driver is
> > independent of it.
>
> The order of patches does indeed reflect real dependency. I can also reorder
> them (preserving the dependencies) so that DTS patches go first in the series
> if this is the more preferred way.

It looks wrong then. Driver should not depend on DTS. I cannot find
the patch changing bindings (should be first in patchset) which could
also point to this problem.

It seems you added requirement for interconnect properties while it
should be rather optional.

> > > I still think the order of these patches is the most logical one for someone
> > > reading this RFC as a whole.
> >
> > I am sorry but it brings only confusion. DTS is orthogonal of the
> > driver code. You could even post the patchset without DTS (although then
> > it would raise questions where is the user of it, but still, you
> > could).
> >
> > Further, DTS describes also hardware so you could send certain DTS
> > patches without driver implementation to describe the hardware.
> >
> > Driver code and DTS are kind of different worlds so mixing them up for
> > logical review does not really make any sense.
> >
> > Not mentioning it is different than most of other patches on mailing
> > lists.
> >
> > BTW, it is the same as bindings which should (almost) always go first as
> > separate patches.
>
> Thanks for elaborating on this, I appreciate it.
> Regarding your original concern, patches 04 & 06 are separate for several
> reasons, one of which is that they are related to two different drivers
> (exynos-bus vs. exynos-mixer).

It's okay then (for them to be split).

>
> > >
> > > > In certain cases dependency on DTS changes is ok:
> > > > 1. Cleaning up deprecated properties,
> > > > 2. Ignoring the backward compatibility for e.g. new platforms.
> > > >
> > > > None of these are applicable here.
> > > >
> > > > You need to rework it, put DTS changes at the end. This clearly shows
> > > > that there is no wrong dependency.
> > > >
> > > > >
> > > > > > Adjust the title to match the contents - you are not adding bindings but
> > > > > > properties to bus nodes. Also the prefix is ARM: (look at recent
> > > > > > commits).
> > > > >
> > > > > OK.
> > > > >
> > > > > > >
> > > > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > > > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > @@ -90,6 +90,7 @@
> > > > > > >  &bus_dmc {
> > > > > > >     exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > > > > >     vdd-supply = <&buck1_reg>;
> > > > > > > +   #interconnect-cells = <0>;
> > > > > >
> > > > > > This does not look like property of Odroid but Exynos4412 or Exynos4.
> > > > >
> > > > > Strangely enough, this file is where the 'exynos,parent-bus' (aka. 'devfreq')
> > > > > properties are located (and everything in this RFC concerns devfreq).
> > > >
> > > > I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
> > > > you elaborate?
> > >
> > > Currently a name change is being made: 'devfreq' -> 'exynos,parent-bus'
> > > https://patchwork.kernel.org/patch/11304549/
> > > (a dependency of this RFC; also available in devfreq-testing branch)
> >
> > I see. That property also does not look like board (Odroid) specific so
> > it should be moved to Exynos4412 DTSI.
>
> Makes sense to me. Just from looking at the patch I referenced above, there is
> a significant level of code duplication between
> * arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> * arch/arm/boot/dts/exynos4412-midas.dtsi
> * arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> with relation to the devfreq*/exynos,* properties.

If you have in mind all the nodes with "status=okay", it's fine to
duplicate them.

Best regards,
Krzysztof

_______________________________________________
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: Krzysztof Kozlowski <krzk@kernel.org>
To: "Artur Świgoń" <a.swigon@samsung.com>
Cc: devicetree@vger.kernel.org,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	linux-pm@vger.kernel.org,
	"Bartłomiej Żołnierkiewicz" <b.zolnierkie@samsung.com>,
	"Seung Woo Kim" <sw0312.kim@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	dri-devel@lists.freedesktop.org,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	myungjoo.ham@samsung.com, leonard.crestez@nxp.com,
	georgi.djakov@linaro.org, linux-arm-kernel@lists.infradead.org,
	"Marek Szyprowski" <m.szyprowski@samsung.com>
Subject: Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
Date: Tue, 31 Dec 2019 11:38:02 +0100	[thread overview]
Message-ID: <CAJKOXPezRMb0OnpcRWrRheKbBjyzqNXG3TDX-MQkjAm2sTSr1w@mail.gmail.com> (raw)
In-Reply-To: <29ed54c7700e35fb95fff4f4f5580eba24ffbb35.camel@samsung.com>

On Tue, 31 Dec 2019 at 11:23, Artur Świgoń <a.swigon@samsung.com> wrote:
> >
> > The order of patches should reflect first of all real dependency.
> > Whether it compiles, works at all and does not break anything.  Logical
> > dependency of "when the feature will start working" is
> > irrelevant to DTS because DTS goes in separate way and driver is
> > independent of it.
>
> The order of patches does indeed reflect real dependency. I can also reorder
> them (preserving the dependencies) so that DTS patches go first in the series
> if this is the more preferred way.

It looks wrong then. Driver should not depend on DTS. I cannot find
the patch changing bindings (should be first in patchset) which could
also point to this problem.

It seems you added requirement for interconnect properties while it
should be rather optional.

> > > I still think the order of these patches is the most logical one for someone
> > > reading this RFC as a whole.
> >
> > I am sorry but it brings only confusion. DTS is orthogonal of the
> > driver code. You could even post the patchset without DTS (although then
> > it would raise questions where is the user of it, but still, you
> > could).
> >
> > Further, DTS describes also hardware so you could send certain DTS
> > patches without driver implementation to describe the hardware.
> >
> > Driver code and DTS are kind of different worlds so mixing them up for
> > logical review does not really make any sense.
> >
> > Not mentioning it is different than most of other patches on mailing
> > lists.
> >
> > BTW, it is the same as bindings which should (almost) always go first as
> > separate patches.
>
> Thanks for elaborating on this, I appreciate it.
> Regarding your original concern, patches 04 & 06 are separate for several
> reasons, one of which is that they are related to two different drivers
> (exynos-bus vs. exynos-mixer).

It's okay then (for them to be split).

>
> > >
> > > > In certain cases dependency on DTS changes is ok:
> > > > 1. Cleaning up deprecated properties,
> > > > 2. Ignoring the backward compatibility for e.g. new platforms.
> > > >
> > > > None of these are applicable here.
> > > >
> > > > You need to rework it, put DTS changes at the end. This clearly shows
> > > > that there is no wrong dependency.
> > > >
> > > > >
> > > > > > Adjust the title to match the contents - you are not adding bindings but
> > > > > > properties to bus nodes. Also the prefix is ARM: (look at recent
> > > > > > commits).
> > > > >
> > > > > OK.
> > > > >
> > > > > > >
> > > > > > > diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > index 4ce3d77a6704..d9d70eacfcaf 100644
> > > > > > > --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> > > > > > > @@ -90,6 +90,7 @@
> > > > > > >  &bus_dmc {
> > > > > > >     exynos,ppmu-device = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> > > > > > >     vdd-supply = <&buck1_reg>;
> > > > > > > +   #interconnect-cells = <0>;
> > > > > >
> > > > > > This does not look like property of Odroid but Exynos4412 or Exynos4.
> > > > >
> > > > > Strangely enough, this file is where the 'exynos,parent-bus' (aka. 'devfreq')
> > > > > properties are located (and everything in this RFC concerns devfreq).
> > > >
> > > > I cannot find exynos,parent-bus in exynos4412-odroid-common.dtsi. Can
> > > > you elaborate?
> > >
> > > Currently a name change is being made: 'devfreq' -> 'exynos,parent-bus'
> > > https://patchwork.kernel.org/patch/11304549/
> > > (a dependency of this RFC; also available in devfreq-testing branch)
> >
> > I see. That property also does not look like board (Odroid) specific so
> > it should be moved to Exynos4412 DTSI.
>
> Makes sense to me. Just from looking at the patch I referenced above, there is
> a significant level of code duplication between
> * arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> * arch/arm/boot/dts/exynos4412-midas.dtsi
> * arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> with relation to the devfreq*/exynos,* properties.

If you have in mind all the nodes with "status=okay", it's fine to
duplicate them.

Best regards,
Krzysztof
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-12-31 10:38 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20191220120140eucas1p14ad33c20882f8f48e02337ea16754d91@eucas1p1.samsung.com>
2019-12-20 11:56 ` [RFC PATCH v3 0/7] PM / devfreq: Simple QoS for exynos-bus using interconnect Artur Świgoń
2019-12-20 11:56   ` Artur Świgoń
2019-12-20 11:56   ` Artur Świgoń
     [not found]   ` <CGME20191220120141eucas1p11f5fa9d76d17e80e06199cb7a911c482@eucas1p1.samsung.com>
2019-12-20 11:56     ` [RFC PATCH v3 1/7] interconnect: Export of_icc_get_from_provider() Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
     [not found]   ` <CGME20191220120142eucas1p1f43c7a862d9c0faa72e14b21d7d697e9@eucas1p1.samsung.com>
2019-12-20 11:56     ` [RFC PATCH v3 2/7] interconnect: Relax requirement in of_icc_get_from_provider() Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-21 17:20       ` Chanwoo Choi
2019-12-21 17:20         ` Chanwoo Choi
2019-12-21 17:20         ` Chanwoo Choi
     [not found]   ` <CGME20191220120143eucas1p1c9b01ae8c2e4ecd70423ef9d8001536f@eucas1p1.samsung.com>
2019-12-20 11:56     ` [RFC PATCH v3 3/7] interconnect: Allow inter-provider pairs to be configured Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-22 17:08       ` Chanwoo Choi
2019-12-22 17:08         ` Chanwoo Choi
2019-12-22 17:08         ` Chanwoo Choi
     [not found]   ` <CGME20191220120144eucas1p119ececf161a6d45a6a194e432bbbd1f9@eucas1p1.samsung.com>
2019-12-20 11:56     ` [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412 Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-21 20:00       ` Chanwoo Choi
2019-12-21 20:00         ` Chanwoo Choi
2019-12-21 20:00         ` Chanwoo Choi
2019-12-30 15:44       ` Krzysztof Kozlowski
2019-12-30 15:44         ` Krzysztof Kozlowski
2019-12-30 15:44         ` Krzysztof Kozlowski
2019-12-31  7:18         ` Artur Świgoń
2019-12-31  7:18           ` Artur Świgoń
2019-12-31  7:18           ` Artur Świgoń
2019-12-31  9:22           ` Krzysztof Kozlowski
2019-12-31  9:22             ` Krzysztof Kozlowski
2019-12-31  9:22             ` Krzysztof Kozlowski
2019-12-31  9:41             ` Artur Świgoń
2019-12-31  9:41               ` Artur Świgoń
2019-12-31  9:41               ` Artur Świgoń
2019-12-31 10:02               ` Krzysztof Kozlowski
2019-12-31 10:02                 ` Krzysztof Kozlowski
2019-12-31 10:02                 ` Krzysztof Kozlowski
2019-12-31 10:23                 ` Artur Świgoń
2019-12-31 10:23                   ` Artur Świgoń
2019-12-31 10:23                   ` Artur Świgoń
2019-12-31 10:38                   ` Krzysztof Kozlowski [this message]
2019-12-31 10:38                     ` Krzysztof Kozlowski
2019-12-31 10:38                     ` Krzysztof Kozlowski
2019-12-31 11:03                     ` Artur Świgoń
2019-12-31 11:03                       ` Artur Świgoń
2019-12-31 11:03                       ` Artur Świgoń
2020-01-22 16:54       ` Georgi Djakov
2020-01-22 16:54         ` Georgi Djakov
2020-01-22 16:54         ` Georgi Djakov
2020-01-24 11:22         ` Artur Świgoń
2020-01-24 11:22           ` Artur Świgoń
2020-01-24 11:22           ` Artur Świgoń
     [not found]   ` <CGME20191220120145eucas1p295af63eed7b23982d8c49fcf875cec8c@eucas1p2.samsung.com>
2019-12-20 11:56     ` [RFC PATCH v3 5/7] devfreq: exynos-bus: Add interconnect functionality to exynos-bus Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-21 19:53       ` Chanwoo Choi
2019-12-21 19:53         ` Chanwoo Choi
2019-12-21 19:53         ` Chanwoo Choi
2019-12-21 19:55         ` Chanwoo Choi
2019-12-21 19:55           ` Chanwoo Choi
2019-12-21 19:55           ` Chanwoo Choi
2020-01-22 17:02       ` Georgi Djakov
2020-01-22 17:02         ` Georgi Djakov
2020-01-22 17:02         ` Georgi Djakov
2020-01-24 11:22         ` Artur Świgoń
2020-01-24 11:22           ` Artur Świgoń
2020-01-24 11:22           ` Artur Świgoń
2020-01-24 12:32           ` Georgi Djakov
2020-01-24 12:32             ` Georgi Djakov
2020-01-24 12:32             ` Georgi Djakov
     [not found]   ` <CGME20191220120146eucas1p25dada01c315215d18bb8a15e3173b52c@eucas1p2.samsung.com>
2019-12-20 11:56     ` [RFC PATCH v3 6/7] arm: dts: exynos: Add interconnects to Exynos4412 mixer Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-21 20:08       ` Chanwoo Choi
2019-12-21 20:08         ` Chanwoo Choi
2019-12-21 20:08         ` Chanwoo Choi
     [not found]   ` <CGME20191220120146eucas1p22a7b0457be4f378b113f67dc25f2eba7@eucas1p2.samsung.com>
2019-12-20 11:56     ` [RFC PATCH v3 7/7] drm: exynos: mixer: Add interconnect support Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-20 11:56       ` Artur Świgoń
2019-12-21 20:15       ` Chanwoo Choi
2019-12-21 20:15         ` Chanwoo Choi
2019-12-21 20:15         ` Chanwoo Choi
2019-12-24  4:56       ` Inki Dae
2019-12-24  4:56         ` Inki Dae
2019-12-24  4:56         ` Inki Dae
2019-12-30  9:35         ` Artur Świgoń
2019-12-30  9:35           ` Artur Świgoń
2019-12-30  9:35           ` Artur Świgoń
2019-12-21 19:58   ` [RFC PATCH v3 0/7] PM / devfreq: Simple QoS for exynos-bus using interconnect Chanwoo Choi
2019-12-21 19:58     ` Chanwoo Choi
2019-12-21 19:58     ` Chanwoo Choi

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=CAJKOXPezRMb0OnpcRWrRheKbBjyzqNXG3TDX-MQkjAm2sTSr1w@mail.gmail.com \
    --to=krzk@kernel.org \
    --cc=a.swigon@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=cw00.choi@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=georgi.djakov@linaro.org \
    --cc=inki.dae@samsung.com \
    --cc=leonard.crestez@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=sw0312.kim@samsung.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.