From: Andrzej Hajda <a.hajda@samsung.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
dri-devel@lists.freedesktop.org, Inki Dae <inki.dae@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Chanwoo Choi <cw00.choi@samsung.com>,
Archit Taneja <architt@codeaurora.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
Date: Mon, 5 Mar 2018 09:18:10 +0100 [thread overview]
Message-ID: <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> (raw)
In-Reply-To: <20180302131315.GA10598@kuha.fi.intel.com>
On 02.03.2018 14:13, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
>> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
>> +
>> +ccic: s2mm005@33 {
>> + ...
>> + usb_con: connector {
>> + compatible = "usb-c-connector";
>> + label = "USB-C";
> Is this child node really necessary? There will never be more then
> one connector per CC line.
But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1].
[1]:
http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery
>
> We should prefer device_graph* functions over of_graph* and
I guess you mean fwnode_graph* functions.
> acpi_graph* functions in the drivers so we don't have to handle the
> same thing multiple times with separate APIs. Is it still possible if
> there is that connector child node?
Bindings proposed here are OF bindings, I suppose the most important is
to follow OF specification and guidelines and these bindings tries to
follow it.
It looks like it should not be a problem for fwnode framework to handle
such bindings, but it is just my guess. I have not seen any fwnode*
specification I am not sure what is the real purpose of this framework,
but it seems to be just in-kernel abstraction for different firmware
standards (OF, ACPI), so even if it lacks at the moment some
functionality it should not be a barrier for OF bindings.
Regards
Andrzej
>
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + usb_con_hs: endpoint {
>> + remote-endpoint = <&max77865_usbc_hs>;
>> + };
>> + };
>> + port@1 {
>> + reg = <1>;
>> + usb_con_ss: endpoint {
>> + remote-endpoint = <&usbdrd_phy_ss>;
>> + };
>> + };
>> + port@2 {
>> + reg = <2>;
>> + usb_con_sbu: endpoint {
>> + remote-endpoint = <&dp_aux>;
>> + };
>> + };
>> + };
>> + };
>> +};
>
> Thanks,
>
WARNING: multiple messages have this Message-ID (diff)
From: Andrzej Hajda <a.hajda@samsung.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
linux-samsung-soc@vger.kernel.org,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Chanwoo Choi <cw00.choi@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
Date: Mon, 5 Mar 2018 09:18:10 +0100 [thread overview]
Message-ID: <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> (raw)
In-Reply-To: <20180302131315.GA10598@kuha.fi.intel.com>
On 02.03.2018 14:13, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
>> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
>> +
>> +ccic: s2mm005@33 {
>> + ...
>> + usb_con: connector {
>> + compatible = "usb-c-connector";
>> + label = "USB-C";
> Is this child node really necessary? There will never be more then
> one connector per CC line.
But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1].
[1]:
http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery
>
> We should prefer device_graph* functions over of_graph* and
I guess you mean fwnode_graph* functions.
> acpi_graph* functions in the drivers so we don't have to handle the
> same thing multiple times with separate APIs. Is it still possible if
> there is that connector child node?
Bindings proposed here are OF bindings, I suppose the most important is
to follow OF specification and guidelines and these bindings tries to
follow it.
It looks like it should not be a problem for fwnode framework to handle
such bindings, but it is just my guess. I have not seen any fwnode*
specification I am not sure what is the real purpose of this framework,
but it seems to be just in-kernel abstraction for different firmware
standards (OF, ACPI), so even if it lacks at the moment some
functionality it should not be a barrier for OF bindings.
Regards
Andrzej
>
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + usb_con_hs: endpoint {
>> + remote-endpoint = <&max77865_usbc_hs>;
>> + };
>> + };
>> + port@1 {
>> + reg = <1>;
>> + usb_con_ss: endpoint {
>> + remote-endpoint = <&usbdrd_phy_ss>;
>> + };
>> + };
>> + port@2 {
>> + reg = <2>;
>> + usb_con_sbu: endpoint {
>> + remote-endpoint = <&dp_aux>;
>> + };
>> + };
>> + };
>> + };
>> +};
>
> Thanks,
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Andrzej Hajda <a.hajda@samsung.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
dri-devel@lists.freedesktop.org, Inki Dae <inki.dae@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Chanwoo Choi <cw00.choi@samsung.com>,
Archit Taneja <architt@codeaurora.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-usb@vger.kernel.org
Subject: [v5,1/6] dt-bindings: add bindings for USB physical connector
Date: Mon, 5 Mar 2018 09:18:10 +0100 [thread overview]
Message-ID: <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> (raw)
On 02.03.2018 14:13, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
>> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
>> +
>> +ccic: s2mm005@33 {
>> + ...
>> + usb_con: connector {
>> + compatible = "usb-c-connector";
>> + label = "USB-C";
> Is this child node really necessary? There will never be more then
> one connector per CC line.
But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1].
[1]:
http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery
>
> We should prefer device_graph* functions over of_graph* and
I guess you mean fwnode_graph* functions.
> acpi_graph* functions in the drivers so we don't have to handle the
> same thing multiple times with separate APIs. Is it still possible if
> there is that connector child node?
Bindings proposed here are OF bindings, I suppose the most important is
to follow OF specification and guidelines and these bindings tries to
follow it.
It looks like it should not be a problem for fwnode framework to handle
such bindings, but it is just my guess. I have not seen any fwnode*
specification I am not sure what is the real purpose of this framework,
but it seems to be just in-kernel abstraction for different firmware
standards (OF, ACPI), so even if it lacks at the moment some
functionality it should not be a barrier for OF bindings.
Regards
Andrzej
>
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> + usb_con_hs: endpoint {
>> + remote-endpoint = <&max77865_usbc_hs>;
>> + };
>> + };
>> + port@1 {
>> + reg = <1>;
>> + usb_con_ss: endpoint {
>> + remote-endpoint = <&usbdrd_phy_ss>;
>> + };
>> + };
>> + port@2 {
>> + reg = <2>;
>> + usb_con_sbu: endpoint {
>> + remote-endpoint = <&dp_aux>;
>> + };
>> + };
>> + };
>> + };
>> +};
>
> Thanks,
>
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: a.hajda@samsung.com (Andrzej Hajda)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector
Date: Mon, 5 Mar 2018 09:18:10 +0100 [thread overview]
Message-ID: <8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com> (raw)
In-Reply-To: <20180302131315.GA10598@kuha.fi.intel.com>
On 02.03.2018 14:13, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
>> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
>> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
>> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
>> +
>> +ccic: s2mm005 at 33 {
>> + ...
>> + usb_con: connector {
>> + compatible = "usb-c-connector";
>> + label = "USB-C";
> Is this child node really necessary? There will never be more then
> one connector per CC line.
But there can be more connectors/cc-lines per IC, for example EZ-PD CCG5[1].
[1]:
http://www.cypress.com/products/ez-pd-ccg5-two-port-usb-type-c-and-power-delivery
>
> We should prefer device_graph* functions over of_graph* and
I guess you mean fwnode_graph* functions.
> acpi_graph* functions in the drivers so we don't have to handle the
> same thing multiple times with separate APIs. Is it still possible if
> there is that connector child node?
Bindings proposed here are OF bindings, I suppose the most important is
to follow OF specification and guidelines and these bindings tries to
follow it.
It looks like it should not be a problem for fwnode framework to handle
such bindings, but it is just my guess. I have not seen any fwnode*
specification I am not sure what is the real purpose of this framework,
but it seems to be just in-kernel abstraction for different firmware
standards (OF, ACPI), so even if it lacks at the moment some
functionality it should not be a barrier for OF bindings.
Regards
Andrzej
>
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port at 0 {
>> + reg = <0>;
>> + usb_con_hs: endpoint {
>> + remote-endpoint = <&max77865_usbc_hs>;
>> + };
>> + };
>> + port at 1 {
>> + reg = <1>;
>> + usb_con_ss: endpoint {
>> + remote-endpoint = <&usbdrd_phy_ss>;
>> + };
>> + };
>> + port at 2 {
>> + reg = <2>;
>> + usb_con_sbu: endpoint {
>> + remote-endpoint = <&dp_aux>;
>> + };
>> + };
>> + };
>> + };
>> +};
>
> Thanks,
>
next prev parent reply other threads:[~2018-03-05 8:18 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180227071137eucas1p104aeeb0fd926fe985e250174d9d65b2e@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
[not found] ` <CGME20180227071138eucas1p17e1e16f13f6d3e3b15a57dc93eb8cf3f@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 1/6] " Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
2018-02-27 7:11 ` [v5,1/6] " Andrzej Hajda
2018-02-27 7:11 ` [PATCH v5 1/6] " Andrzej Hajda
2018-03-02 13:13 ` Heikki Krogerus
2018-03-02 13:13 ` Heikki Krogerus
2018-03-02 13:13 ` [v5,1/6] " Heikki Krogerus
2018-03-05 8:18 ` Andrzej Hajda [this message]
2018-03-05 8:18 ` [PATCH v5 1/6] " Andrzej Hajda
2018-03-05 8:18 ` [v5,1/6] " Andrzej Hajda
2018-03-05 8:18 ` [PATCH v5 1/6] " Andrzej Hajda
2018-03-05 10:27 ` Heikki Krogerus
2018-03-05 10:27 ` Heikki Krogerus
2018-03-05 10:27 ` [v5,1/6] " Heikki Krogerus
2018-03-05 22:14 ` [PATCH v5 1/6] " Rob Herring
2018-03-05 22:14 ` Rob Herring
2018-03-05 22:14 ` [v5,1/6] " Rob Herring
2018-03-05 22:14 ` [PATCH v5 1/6] " Rob Herring
2018-03-09 10:24 ` Roger Quadros
2018-03-09 10:24 ` Roger Quadros
2018-03-09 10:24 ` [v5,1/6] " Roger Quadros
2018-03-09 10:24 ` [PATCH v5 1/6] " Roger Quadros
2018-03-12 7:02 ` Andrzej Hajda
2018-03-12 7:02 ` Andrzej Hajda
2018-03-12 7:02 ` [v5,1/6] " Andrzej Hajda
2018-03-12 7:02 ` [PATCH v5 1/6] " Andrzej Hajda
2018-03-12 7:06 ` Andrzej Hajda
2018-03-12 7:06 ` Andrzej Hajda
2018-03-12 7:06 ` [v5,1/6] " Andrzej Hajda
2018-03-12 7:06 ` [PATCH v5 1/6] " Andrzej Hajda
2018-03-12 10:41 ` Roger Quadros
2018-03-12 10:41 ` Roger Quadros
2018-03-12 10:41 ` [v5,1/6] " Roger Quadros
2018-03-12 10:41 ` [PATCH v5 1/6] " Roger Quadros
2018-03-15 11:02 ` Andrzej Hajda
2018-03-15 11:02 ` Andrzej Hajda
2018-03-15 11:02 ` [v5,1/6] " Andrzej Hajda
2018-03-15 11:02 ` [PATCH v5 1/6] " Andrzej Hajda
2018-03-15 11:46 ` Robin Murphy
2018-03-15 11:46 ` Robin Murphy
2018-03-15 11:46 ` [v5,1/6] " Robin Murphy
2018-03-15 11:46 ` [PATCH v5 1/6] " Robin Murphy
2018-03-15 17:08 ` Roger Quadros
2018-03-15 17:08 ` Roger Quadros
2018-03-15 17:08 ` [v5,1/6] " Roger Quadros
2018-03-15 17:08 ` [PATCH v5 1/6] " Roger Quadros
[not found] ` <CGME20180227071139eucas1p125ee35ada221fbed1dc85b7fc250f9ca@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 2/6] dt-bindings: add bindings for Samsung micro-USB 11-pin connector Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
2018-02-27 7:11 ` [v5,2/6] " Andrzej Hajda
2018-02-27 7:11 ` [PATCH v5 2/6] " Andrzej Hajda
[not found] ` <CGME20180227071139eucas1p1d28b39a6636a7e6625aeb3a16091f81a@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 3/6] arm64: dts: exynos: add micro-USB connector node to TM2 platforms Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
2018-02-27 7:11 ` [v5,3/6] " Andrzej Hajda
2018-02-27 7:11 ` [PATCH v5 3/6] " Andrzej Hajda
2018-03-06 16:49 ` Krzysztof Kozlowski
2018-03-06 16:49 ` Krzysztof Kozlowski
2018-03-06 16:49 ` [v5,3/6] " Krzysztof Kozlowski
[not found] ` <CGME20180227071140eucas1p15a8b8443c6d52c5fab79cc82c37dce09@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 4/6] arm64: dts: exynos: add OF graph between MHL and USB connector Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
2018-02-27 7:11 ` [v5,4/6] " Andrzej Hajda
2018-02-27 7:11 ` [PATCH v5 4/6] " Andrzej Hajda
2018-03-06 16:49 ` Krzysztof Kozlowski
2018-03-06 16:49 ` Krzysztof Kozlowski
2018-03-06 16:49 ` [v5,4/6] " Krzysztof Kozlowski
2018-03-06 16:49 ` [PATCH v5 4/6] " Krzysztof Kozlowski
[not found] ` <CGME20180227071141eucas1p1170216070d70007a07de120a0dc3363a@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 5/6] extcon: add possibility to get extcon device by OF node Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
2018-02-27 7:11 ` [v5,5/6] " Andrzej Hajda
2018-02-27 7:11 ` [PATCH v5 5/6] " Andrzej Hajda
2018-02-27 11:03 ` Chanwoo Choi
2018-02-27 11:03 ` Chanwoo Choi
2018-02-27 11:03 ` [v5,5/6] " Chanwoo Choi
[not found] ` <CGME20180227122215eucas1p11a1a12c26665f032c666d10effaf15fc@eucas1p1.samsung.com>
2018-02-27 12:22 ` [PATCH v6 5/6] " Andrzej Hajda
2018-02-27 12:22 ` Andrzej Hajda
2018-02-27 12:22 ` [v6,5/6] " Andrzej Hajda
2018-02-27 12:22 ` [PATCH v6 5/6] " Andrzej Hajda
[not found] ` <CGME20180227071142eucas1p10203dac2558db034a4a3287220213601@eucas1p1.samsung.com>
2018-02-27 7:11 ` [PATCH v5 6/6] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL Andrzej Hajda
2018-02-27 7:11 ` Andrzej Hajda
2018-02-27 7:11 ` [v5,6/6] " Andrzej Hajda
2018-02-27 7:11 ` [PATCH v5 6/6] " Andrzej Hajda
2018-02-27 11:08 ` Chanwoo Choi
2018-02-27 11:08 ` Chanwoo Choi
2018-02-27 11:08 ` [v5,6/6] " Chanwoo Choi
2018-02-27 12:05 ` [PATCH v5 6/6] " Andrzej Hajda
2018-02-27 12:05 ` Andrzej Hajda
2018-02-27 12:05 ` [v5,6/6] " Andrzej Hajda
2018-02-27 12:05 ` [PATCH v5 6/6] " Andrzej Hajda
2018-02-27 22:26 ` Chanwoo Choi
2018-02-27 22:26 ` Chanwoo Choi
2018-02-27 22:26 ` [v5,6/6] " Chanwoo Choi
2018-02-28 13:44 ` [PATCH v5 6/6] " Andrzej Hajda
2018-02-28 13:44 ` Andrzej Hajda
2018-02-28 13:44 ` [v5,6/6] " Andrzej Hajda
2018-02-28 13:44 ` [PATCH v5 6/6] " Andrzej Hajda
2018-03-02 0:29 ` Chanwoo Choi
2018-03-02 0:29 ` Chanwoo Choi
2018-03-02 0:29 ` [v5,6/6] " Chanwoo Choi
2018-03-06 12:53 ` [PATCH v5 0/6] dt-bindings: add bindings for USB physical connector Andrzej Hajda
2018-03-06 12:53 ` Andrzej Hajda
2018-03-06 13:08 ` Krzysztof Kozlowski
2018-03-06 13:08 ` Krzysztof Kozlowski
2018-03-07 2:12 ` Chanwoo Choi
2018-03-07 2:12 ` Chanwoo Choi
2018-03-07 4:48 ` Chanwoo Choi
2018-03-07 4:48 ` Chanwoo Choi
2018-03-07 11:13 ` Andrzej Hajda
2018-03-07 11:13 ` Andrzej Hajda
2018-03-07 11:22 ` Krzysztof Kozlowski
2018-03-07 11:22 ` Krzysztof Kozlowski
2018-03-07 11:22 ` Krzysztof Kozlowski
2018-03-07 11:40 ` Andrzej Hajda
2018-03-07 11:40 ` Andrzej Hajda
2018-03-07 11:40 ` Andrzej Hajda
2018-03-08 1:52 ` Chanwoo Choi
2018-03-08 1:52 ` Chanwoo Choi
2018-03-09 9:20 ` Andrzej Hajda
2018-03-09 9:20 ` Andrzej Hajda
2018-03-09 9:20 ` Andrzej Hajda
2018-03-12 1:29 ` Chanwoo Choi
2018-03-12 1:29 ` Chanwoo Choi
2018-03-12 1:29 ` [v5,0/6] " 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=8434f820-5016-1e5a-c3cb-5d7789dd69c1@samsung.com \
--to=a.hajda@samsung.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=architt@codeaurora.org \
--cc=b.zolnierkie@samsung.com \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=inki.dae@samsung.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
/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.