From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfram Sang <wsa@the-dreams.de>,
Linux I2C <linux-i2c@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Przemyslaw Sroka <psroka@cadence.com>,
Arkadiusz Golec <agolec@cadence.com>,
Alan Douglas <adouglas@cadence.com>,
Bartosz Folta <bfolta@cadence.com>, Damian Kos <dkos@cadence.com>,
Alicja Jurasik-Urbaniak <alicja@cadence.com>,
Cyprian Wronka <cwronka@cadence.com>,
Suresh Punnoose <sureshp@cadence.com>,
Rafal Ciepiela <rafalc@cadence.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Vitor Soares <Vitor.Soares@synopsys.com>,
Linus Walleij <linus.walleij@linaro.org>,
Xiang Lin <Xiang.Lin@synaptics.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Boris Brezillon <boris.brezillon@free-electrons.com>
Subject: Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
Date: Mon, 26 Mar 2018 13:19:46 +0200 [thread overview]
Message-ID: <20180326131946.5513c6e2@bbrezillon> (raw)
In-Reply-To: <CAMuHMdV9xW8o6zuOmOxB+=h1XTdi-VFq2mp897SUjZKtRMOWOw@mail.gmail.com>
Hi Geert,
On Mon, 26 Mar 2018 12:22:24 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Boris,
>
> On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > From: Boris Brezillon <boris.brezillon@free-electrons.com>
> >
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> >
> > Document this generic representation.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> > @@ -0,0 +1,140 @@
>
> > +I3C devices
> > +===========
> > +
> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> > +are thus discoverable. So, by default, I3C devices do not have to be described
> > +in the device tree.
>
> But if they're described, they should have a compatible value, no?
What's the point of having a compatible here? I mean, I3C devices are
already attached to the relevant drivers using the Provisional ID, why
would we need a compatible if we don't parse it?
>
> > +This being said, one might want to attach extra resources to these devices,
> > +and those resources may have to be described in the device tree, which in turn
> > +means we have to describe I3C devices.
> > +
> > +Another use case for describing an I3C device in the device tree is when this
> > +I3C device has a static address and we want to assign it a specific dynamic
> > +address before the DAA takes place (so that other devices on the bus can't
> > +take this dynamic address).
> > +
> > +The I3C device should be names <device-type>@<static-address>,<i3c-pid>,
>
> named
Oops. Will fix the typo.
>
> So the i3c-pid in the unit address is represented as a 64-bit number, not as two
> comma-separated 32-bit numbers?
Right. I've changed my mind so many times that I ended up mixing the 2
representations I have considered.
Here are the choices we have:
1/ expose the raw ProvisionalID which is a 48-bit integer formed by the
concatenation of the vendor ID, part ID and instance ID:
ProvisionalID = VendorID << 33 | PartID << 16 | InstanceID << 12 |
ExtraInfo
The I3C dev node name should in this case be something like
<device-type>@<static-address>,<i3c-pid>
2/ split the fields we are really interested in in different cells:
2nd cell: vendorID
3rd cell: partID
4th cell: instanceID
In this case, the node name should be
<device-type>@<static-address>,<i3c-vendor>,<i3c-partid>,<i3c-instanceid>
Note that we can still change for the second representation if Rob is
okay.
>
> > +Example:
> > +
> > + i3c-master@d040000 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d040000 0x1000>;
> > + #address-cells = <3>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <100000>;
> > +
> > + /* I2C device. */
> > + nunchuk: nunchuk@52 {
>
> @52,8000001000000000?
Well, I2C devs is a special case, and I'm not sure we want to add the
extra LVR information + the IS_I2C_DEV bit in the node name.
>
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52 0x80000010 0x0>;
One more detail: people are unlikely to define reg using raw values: I
provide macros to do that in patch 6.
> > + };
> > +
> > + /* I3C device with a static address. */
> > + thermal_sensor: sensor@68,39200144004 {
>
> No compatible value?
No, as said above, it's not needed.
>
> > + reg = <0x68 0x392 0x144004>;
> > + assigned-address = <0xa>;
> > + };
> > +
> > + /*
> > + * I3C device without a static address but requiring resources
> > + * described in the DT.
> > + */
> > + sensor@0,39200154004 {
>
> No compatible value?
Ditto.
Thanks for your review.
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" 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: Boris Brezillon <boris.brezillon@bootlin.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfram Sang <wsa@the-dreams.de>,
Linux I2C <linux-i2c@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Przemyslaw Sroka <psroka@cadence.com>,
Arkadiusz Golec <agolec@cadence.com>,
Alan Douglas <adouglas@cadence.com>,
Bartosz Folta <bfolta@cadence.com>, Damian Kos <dkos@cadence.com>,
Alicja Jurasik-Urbaniak <alicja@cadence.com>,
Cyprian Wronka <cwronka@cadence.com>,
Suresh Punnoose <sureshp@cadence.com>,
Rafal Ciepiela <rafalc@cadence.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian
Subject: Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
Date: Mon, 26 Mar 2018 13:19:46 +0200 [thread overview]
Message-ID: <20180326131946.5513c6e2@bbrezillon> (raw)
In-Reply-To: <CAMuHMdV9xW8o6zuOmOxB+=h1XTdi-VFq2mp897SUjZKtRMOWOw@mail.gmail.com>
Hi Geert,
On Mon, 26 Mar 2018 12:22:24 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Boris,
>
> On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > From: Boris Brezillon <boris.brezillon@free-electrons.com>
> >
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> >
> > Document this generic representation.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> > @@ -0,0 +1,140 @@
>
> > +I3C devices
> > +===========
> > +
> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> > +are thus discoverable. So, by default, I3C devices do not have to be described
> > +in the device tree.
>
> But if they're described, they should have a compatible value, no?
What's the point of having a compatible here? I mean, I3C devices are
already attached to the relevant drivers using the Provisional ID, why
would we need a compatible if we don't parse it?
>
> > +This being said, one might want to attach extra resources to these devices,
> > +and those resources may have to be described in the device tree, which in turn
> > +means we have to describe I3C devices.
> > +
> > +Another use case for describing an I3C device in the device tree is when this
> > +I3C device has a static address and we want to assign it a specific dynamic
> > +address before the DAA takes place (so that other devices on the bus can't
> > +take this dynamic address).
> > +
> > +The I3C device should be names <device-type>@<static-address>,<i3c-pid>,
>
> named
Oops. Will fix the typo.
>
> So the i3c-pid in the unit address is represented as a 64-bit number, not as two
> comma-separated 32-bit numbers?
Right. I've changed my mind so many times that I ended up mixing the 2
representations I have considered.
Here are the choices we have:
1/ expose the raw ProvisionalID which is a 48-bit integer formed by the
concatenation of the vendor ID, part ID and instance ID:
ProvisionalID = VendorID << 33 | PartID << 16 | InstanceID << 12 |
ExtraInfo
The I3C dev node name should in this case be something like
<device-type>@<static-address>,<i3c-pid>
2/ split the fields we are really interested in in different cells:
2nd cell: vendorID
3rd cell: partID
4th cell: instanceID
In this case, the node name should be
<device-type>@<static-address>,<i3c-vendor>,<i3c-partid>,<i3c-instanceid>
Note that we can still change for the second representation if Rob is
okay.
>
> > +Example:
> > +
> > + i3c-master@d040000 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d040000 0x1000>;
> > + #address-cells = <3>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <100000>;
> > +
> > + /* I2C device. */
> > + nunchuk: nunchuk@52 {
>
> @52,8000001000000000?
Well, I2C devs is a special case, and I'm not sure we want to add the
extra LVR information + the IS_I2C_DEV bit in the node name.
>
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52 0x80000010 0x0>;
One more detail: people are unlikely to define reg using raw values: I
provide macros to do that in patch 6.
> > + };
> > +
> > + /* I3C device with a static address. */
> > + thermal_sensor: sensor@68,39200144004 {
>
> No compatible value?
No, as said above, it's not needed.
>
> > + reg = <0x68 0x392 0x144004>;
> > + assigned-address = <0xa>;
> > + };
> > +
> > + /*
> > + * I3C device without a static address but requiring resources
> > + * described in the DT.
> > + */
> > + sensor@0,39200154004 {
>
> No compatible value?
Ditto.
Thanks for your review.
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfram Sang <wsa@the-dreams.de>,
Linux I2C <linux-i2c@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Przemyslaw Sroka <psroka@cadence.com>,
Arkadiusz Golec <agolec@cadence.com>,
Alan Douglas <adouglas@cadence.com>,
Bartosz Folta <bfolta@cadence.com>, Damian Kos <dkos@cadence.com>,
Alicja Jurasik-Urbaniak <alicja@cadence.com>,
Cyprian Wronka <cwronka@cadence.com>,
Suresh Punnoose <sureshp@cadence.com>,
Rafal Ciepiela <rafalc@cadence.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Nishanth Menon <nm@ti.com>, Rob Herring <robh+dt@kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Vitor Soares <Vitor.Soares@synopsys.com>,
Linus Walleij <linus.walleij@linaro.org>,
Xiang Lin <Xiang.Lin@synaptics.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Boris Brezillon <boris.brezillon@free-electrons.com>
Subject: Re: [PATCH v3 05/11] dt-bindings: i3c: Document core bindings
Date: Mon, 26 Mar 2018 13:19:46 +0200 [thread overview]
Message-ID: <20180326131946.5513c6e2@bbrezillon> (raw)
In-Reply-To: <CAMuHMdV9xW8o6zuOmOxB+=h1XTdi-VFq2mp897SUjZKtRMOWOw@mail.gmail.com>
Hi Geert,
On Mon, 26 Mar 2018 12:22:24 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Boris,
>
> On Fri, Mar 23, 2018 at 12:00 PM, Boris Brezillon
> <boris.brezillon@bootlin.com> wrote:
> > From: Boris Brezillon <boris.brezillon@free-electrons.com>
> >
> > A new I3C subsystem has been added and a generic description has been
> > created to represent the I3C bus and the devices connected on it.
> >
> > Document this generic representation.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> Thanks for your patch!
>
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> > @@ -0,0 +1,140 @@
>
> > +I3C devices
> > +===========
> > +
> > +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> > +are thus discoverable. So, by default, I3C devices do not have to be described
> > +in the device tree.
>
> But if they're described, they should have a compatible value, no?
What's the point of having a compatible here? I mean, I3C devices are
already attached to the relevant drivers using the Provisional ID, why
would we need a compatible if we don't parse it?
>
> > +This being said, one might want to attach extra resources to these devices,
> > +and those resources may have to be described in the device tree, which in turn
> > +means we have to describe I3C devices.
> > +
> > +Another use case for describing an I3C device in the device tree is when this
> > +I3C device has a static address and we want to assign it a specific dynamic
> > +address before the DAA takes place (so that other devices on the bus can't
> > +take this dynamic address).
> > +
> > +The I3C device should be names <device-type>@<static-address>,<i3c-pid>,
>
> named
Oops. Will fix the typo.
>
> So the i3c-pid in the unit address is represented as a 64-bit number, not as two
> comma-separated 32-bit numbers?
Right. I've changed my mind so many times that I ended up mixing the 2
representations I have considered.
Here are the choices we have:
1/ expose the raw ProvisionalID which is a 48-bit integer formed by the
concatenation of the vendor ID, part ID and instance ID:
ProvisionalID = VendorID << 33 | PartID << 16 | InstanceID << 12 |
ExtraInfo
The I3C dev node name should in this case be something like
<device-type>@<static-address>,<i3c-pid>
2/ split the fields we are really interested in in different cells:
2nd cell: vendorID
3rd cell: partID
4th cell: instanceID
In this case, the node name should be
<device-type>@<static-address>,<i3c-vendor>,<i3c-partid>,<i3c-instanceid>
Note that we can still change for the second representation if Rob is
okay.
>
> > +Example:
> > +
> > + i3c-master@d040000 {
> > + compatible = "cdns,i3c-master";
> > + clocks = <&coreclock>, <&i3csysclock>;
> > + clock-names = "pclk", "sysclk";
> > + interrupts = <3 0>;
> > + reg = <0x0d040000 0x1000>;
> > + #address-cells = <3>;
> > + #size-cells = <0>;
> > +
> > + status = "okay";
> > + i2c-scl-frequency = <100000>;
> > +
> > + /* I2C device. */
> > + nunchuk: nunchuk@52 {
>
> @52,8000001000000000?
Well, I2C devs is a special case, and I'm not sure we want to add the
extra LVR information + the IS_I2C_DEV bit in the node name.
>
> > + compatible = "nintendo,nunchuk";
> > + reg = <0x52 0x80000010 0x0>;
One more detail: people are unlikely to define reg using raw values: I
provide macros to do that in patch 6.
> > + };
> > +
> > + /* I3C device with a static address. */
> > + thermal_sensor: sensor@68,39200144004 {
>
> No compatible value?
No, as said above, it's not needed.
>
> > + reg = <0x68 0x392 0x144004>;
> > + assigned-address = <0xa>;
> > + };
> > +
> > + /*
> > + * I3C device without a static address but requiring resources
> > + * described in the DT.
> > + */
> > + sensor@0,39200154004 {
>
> No compatible value?
Ditto.
Thanks for your review.
Boris
--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-03-26 11:20 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-23 11:00 [PATCH v3 00/11] Add the I3C subsystem Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 01/11] i2c: Export of_i2c_get_board_info() Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-24 22:35 ` Wolfram Sang
2018-03-24 22:35 ` Wolfram Sang
2018-03-24 22:38 ` Wolfram Sang
2018-03-24 22:38 ` Wolfram Sang
2018-03-25 10:21 ` Boris Brezillon
2018-03-25 10:21 ` Boris Brezillon
2018-03-25 10:21 ` Boris Brezillon
2018-03-25 10:19 ` Boris Brezillon
2018-03-25 10:19 ` Boris Brezillon
2018-03-25 10:19 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 02/11] i3c: Add core I3C infrastructure Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 03/11] docs: driver-api: Add I3C documentation Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 04/11] i3c: Add sysfs ABI spec Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 05/11] dt-bindings: i3c: Document core bindings Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 12:47 ` Peter Rosin
2018-03-23 12:47 ` Peter Rosin
2018-03-23 12:47 ` Peter Rosin
2018-03-23 13:58 ` Boris Brezillon
2018-03-23 13:58 ` Boris Brezillon
2018-03-23 13:58 ` Boris Brezillon
2018-03-26 10:22 ` Geert Uytterhoeven
2018-03-26 10:22 ` Geert Uytterhoeven
2018-03-26 10:22 ` Geert Uytterhoeven
2018-03-26 11:19 ` Boris Brezillon [this message]
2018-03-26 11:19 ` Boris Brezillon
2018-03-26 11:19 ` Boris Brezillon
2018-03-26 22:24 ` Rob Herring
2018-03-26 22:24 ` Rob Herring
2018-03-26 22:24 ` Rob Herring
2018-03-28 8:19 ` Boris Brezillon
2018-03-28 8:19 ` Boris Brezillon
2018-03-28 8:19 ` Boris Brezillon
2018-03-28 16:42 ` Rob Herring
2018-03-28 16:42 ` Rob Herring
2018-03-28 16:42 ` Rob Herring
2018-03-28 17:28 ` Boris Brezillon
2018-03-28 17:28 ` Boris Brezillon
2018-03-28 17:28 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 06/11] dt-bindings: i3c: Add macros to help fill I3C/I2C device's reg property Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-26 22:25 ` Rob Herring
2018-03-26 22:25 ` Rob Herring
2018-03-26 22:25 ` Rob Herring
2018-03-23 11:00 ` [PATCH v3 07/11] MAINTAINERS: Add myself as the I3C subsystem maintainer Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 08/11] i3c: master: Add driver for Cadence IP Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 09/11] dt-bindings: i3c: Document Cadence I3C master bindings Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:10 ` Thomas Petazzoni
2018-03-23 11:10 ` Thomas Petazzoni
2018-03-23 11:10 ` Thomas Petazzoni
2018-03-23 13:59 ` Boris Brezillon
2018-03-23 13:59 ` Boris Brezillon
2018-03-23 13:59 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 10/11] gpio: Add a driver for Cadence I3C GPIO expander Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` [PATCH v3 11/11] dt-bindings: gpio: Add bindings for Cadence I3C gpio expander Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-23 11:00 ` Boris Brezillon
2018-03-26 10:12 ` Geert Uytterhoeven
2018-03-26 10:12 ` Geert Uytterhoeven
2018-03-26 10:12 ` Geert Uytterhoeven
2018-03-26 11:25 ` Boris Brezillon
2018-03-26 11:25 ` Boris Brezillon
2018-03-26 11:25 ` Boris Brezillon
2018-03-26 11:35 ` Geert Uytterhoeven
2018-03-26 11:35 ` Geert Uytterhoeven
2018-03-26 11:35 ` Geert Uytterhoeven
2018-03-26 10:17 ` Geert Uytterhoeven
2018-03-26 10:17 ` Geert Uytterhoeven
2018-03-26 10:17 ` Geert Uytterhoeven
2018-03-26 11:21 ` Boris Brezillon
2018-03-26 11:21 ` Boris Brezillon
2018-03-26 11:21 ` Boris Brezillon
2018-03-26 22:25 ` Rob Herring
2018-03-26 22:25 ` Rob Herring
2018-03-26 22:25 ` Rob Herring
2018-03-23 11:03 ` [PATCH v3 00/11] Add the I3C subsystem Boris Brezillon
2018-03-23 11:03 ` Boris Brezillon
2018-03-23 11:03 ` Boris Brezillon
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=20180326131946.5513c6e2@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=Vitor.Soares@synopsys.com \
--cc=Xiang.Lin@synaptics.com \
--cc=adouglas@cadence.com \
--cc=agolec@cadence.com \
--cc=alicja@cadence.com \
--cc=arnd@arndb.de \
--cc=bfolta@cadence.com \
--cc=boris.brezillon@free-electrons.com \
--cc=corbet@lwn.net \
--cc=cwronka@cadence.com \
--cc=devicetree@vger.kernel.org \
--cc=dkos@cadence.com \
--cc=galak@codeaurora.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linus.walleij@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=nm@ti.com \
--cc=pawel.moll@arm.com \
--cc=psroka@cadence.com \
--cc=rafalc@cadence.com \
--cc=robh+dt@kernel.org \
--cc=sureshp@cadence.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=wsa@the-dreams.de \
/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.