diff for duplicates of <20181102092852.000038a2@huawei.com> diff --git a/a/1.txt b/N1/1.txt index ee17748..0a16a74 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,25 +5,29 @@ Rob Herring <robh@kernel.org> wrote: > > > > On Thu, 18 Oct 2018 12:40:10 -0700 > > Matthias Kaehlcke <mka@chromium.org> wrote: -> > -> > > On Fri, Oct 12, 2018 at 10:15:23AM -0700, Matthias Kaehlcke wrote: -> > > > On Fri, Oct 05, 2018 at 03:47:43PM -0500, Rob Herring wrote: -> > > > > On Wed, Oct 03, 2018 at 05:14:31PM -0700, Matthias Kaehlcke wrote: -> > > > > > The node has a reg property, therefore its name should include a unit +> > =20 +> > > On Fri, Oct 12, 2018 at 10:15:23AM -0700, Matthias Kaehlcke wrote: =20 +> > > > On Fri, Oct 05, 2018 at 03:47:43PM -0500, Rob Herring wrote: =20 +> > > > > On Wed, Oct 03, 2018 at 05:14:31PM -0700, Matthias Kaehlcke wrote= +: =20 +> > > > > > The node has a reg property, therefore its name should include = +a unit > > > > > > address. > > > > > > -> > > > > > Also change the name from 'usb_id_nopull' to 'usb-id-nopull' to follow -> > > > > > DT conventions. +> > > > > > Also change the name from 'usb_id_nopull' to 'usb-id-nopull' to= + follow +> > > > > > DT conventions. =20 > > > > > > > > > > This is ADC channels? If so, then DT convention would really be -> > > > > "adc@...". +> > > > > "adc@...". =20 > > > > > > > > Is it really? A grep for 'adc@' in arch/${ARCH}/boot/dts yields > > > > mostly ADC controller not channel nodes. > > > > > > > > I'm totally fine with changing the name to 'adc@...' if that's the -> > > > preference/convention, just want to reconfirm since the actual use is -> > > > a bit ambiguous. +> > > > preference/convention, just want to reconfirm since the actual use = +is +> > > > a bit ambiguous. =20 > > > > > > Could we please reach a conclusion on this? > > > @@ -38,17 +42,17 @@ Rob Herring <robh@kernel.org> wrote: > > > since the unit address doesn't just resolve to an ADC channel number > > > but also includes configuation information. A literal like '57' > > > conveys less information than the define, it's easier to introduce -> > > errors and these errors are harder to spot. +> > > errors and these errors are harder to spot. =20 > > -> > I agree that to my mind this is the most sensible option. -> +> > I agree that to my mind this is the most sensible option. =20 +>=20 > If you really want the defines, then fine. Of course, that only works > if the function is fixed. It won't work if the function is defined per > board. -> +>=20 > Eventually, examples using defines will have to also include the > headers. I plan to make the examples build-able. -> +>=20 > > > If 'adc@...' really was the convention (or should be) I'd be clearly > > > in favor of following it. As mentioned above, in practice the use of > > > the 'adc@...' node name seems to be more prevalent for ADC controllers @@ -58,16 +62,16 @@ Rob Herring <robh@kernel.org> wrote: > > > All that said, these are just my preferences for the reasons outlined > > > above, if DT maintainers really want it to be 'adc@57' or some > > > variation of that, I'm fine with that too. Please let me know and we -> > > can move forward with this trivial series. +> > > can move forward with this trivial series. =20 > > -> > Rob, what's your view on this? -> +> > Rob, what's your view on this? =20 +>=20 > I want node names that reflect the class of the node (not a specific > model) and consistency across bindings. What that looks like for > multi-channel ADCs is really up to you. There was another binding > recently which mapped sub-nodes to inputs rather than channels. Maybe > that's needed too if you have more inputs than simultaneous channels. ->From a DT point of view the simultaneous channels vs inputs isn't meant +=46rom a DT point of view the simultaneous channels vs inputs isn't meant to be currently visible. It's a userspace problem and from IIO point of view a 'channel' is an input (you just might not be able to enable all channels at once!) @@ -76,7 +80,7 @@ channel@ would work for me, though that might then match other types of device where this has a different meaning. Perhaps adc_chan@ ? -> +>=20 > Also, if your goal is to just quiet dtc warnings, then I'd prefer you > not. They often point to bigger issues even if they can be fixed with > trivial changes. Of course, if not fixed someone else will come along @@ -87,5 +91,5 @@ common thing to represent. Jonathan -> +>=20 > Rob diff --git a/a/content_digest b/N1/content_digest index 39b7159..3c27b99 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -19,8 +19,8 @@ Peter Meerwald <pmeerw@pmeerw.net> linux-arm-msm <linux-arm-msm@vger.kernel.org> open list:ARM/QUALCOMM SUPPORT <linux-soc@vger.kernel.org> - devicetree@vger.kernel.org - linux-iio@vger.kernel.org + <devicetree@vger.kernel.org> + <linux-iio@vger.kernel.org> linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> " Doug Anderson <dianders@chromium.org>\0" "\00:1\0" @@ -32,25 +32,29 @@ "> >\n" "> > On Thu, 18 Oct 2018 12:40:10 -0700\n" "> > Matthias Kaehlcke <mka@chromium.org> wrote:\n" - "> > \n" - "> > > On Fri, Oct 12, 2018 at 10:15:23AM -0700, Matthias Kaehlcke wrote: \n" - "> > > > On Fri, Oct 05, 2018 at 03:47:43PM -0500, Rob Herring wrote: \n" - "> > > > > On Wed, Oct 03, 2018 at 05:14:31PM -0700, Matthias Kaehlcke wrote: \n" - "> > > > > > The node has a reg property, therefore its name should include a unit\n" + "> > =20\n" + "> > > On Fri, Oct 12, 2018 at 10:15:23AM -0700, Matthias Kaehlcke wrote: =20\n" + "> > > > On Fri, Oct 05, 2018 at 03:47:43PM -0500, Rob Herring wrote: =20\n" + "> > > > > On Wed, Oct 03, 2018 at 05:14:31PM -0700, Matthias Kaehlcke wrote=\n" + ": =20\n" + "> > > > > > The node has a reg property, therefore its name should include =\n" + "a unit\n" "> > > > > > address.\n" "> > > > > >\n" - "> > > > > > Also change the name from 'usb_id_nopull' to 'usb-id-nopull' to follow\n" - "> > > > > > DT conventions. \n" + "> > > > > > Also change the name from 'usb_id_nopull' to 'usb-id-nopull' to=\n" + " follow\n" + "> > > > > > DT conventions. =20\n" "> > > > >\n" "> > > > > This is ADC channels? If so, then DT convention would really be\n" - "> > > > > \"adc@...\". \n" + "> > > > > \"adc@...\". =20\n" "> > > >\n" "> > > > Is it really? A grep for 'adc@' in arch/${ARCH}/boot/dts yields\n" "> > > > mostly ADC controller not channel nodes.\n" "> > > >\n" "> > > > I'm totally fine with changing the name to 'adc@...' if that's the\n" - "> > > > preference/convention, just want to reconfirm since the actual use is\n" - "> > > > a bit ambiguous. \n" + "> > > > preference/convention, just want to reconfirm since the actual use =\n" + "is\n" + "> > > > a bit ambiguous. =20\n" "> > >\n" "> > > Could we please reach a conclusion on this?\n" "> > >\n" @@ -65,17 +69,17 @@ "> > > since the unit address doesn't just resolve to an ADC channel number\n" "> > > but also includes configuation information. A literal like '57'\n" "> > > conveys less information than the define, it's easier to introduce\n" - "> > > errors and these errors are harder to spot. \n" + "> > > errors and these errors are harder to spot. =20\n" "> >\n" - "> > I agree that to my mind this is the most sensible option. \n" - "> \n" + "> > I agree that to my mind this is the most sensible option. =20\n" + ">=20\n" "> If you really want the defines, then fine. Of course, that only works\n" "> if the function is fixed. It won't work if the function is defined per\n" "> board.\n" - "> \n" + ">=20\n" "> Eventually, examples using defines will have to also include the\n" "> headers. I plan to make the examples build-able.\n" - "> \n" + ">=20\n" "> > > If 'adc@...' really was the convention (or should be) I'd be clearly\n" "> > > in favor of following it. As mentioned above, in practice the use of\n" "> > > the 'adc@...' node name seems to be more prevalent for ADC controllers\n" @@ -85,16 +89,16 @@ "> > > All that said, these are just my preferences for the reasons outlined\n" "> > > above, if DT maintainers really want it to be 'adc@57' or some\n" "> > > variation of that, I'm fine with that too. Please let me know and we\n" - "> > > can move forward with this trivial series. \n" + "> > > can move forward with this trivial series. =20\n" "> >\n" - "> > Rob, what's your view on this? \n" - "> \n" + "> > Rob, what's your view on this? =20\n" + ">=20\n" "> I want node names that reflect the class of the node (not a specific\n" "> model) and consistency across bindings. What that looks like for\n" "> multi-channel ADCs is really up to you. There was another binding\n" "> recently which mapped sub-nodes to inputs rather than channels. Maybe\n" "> that's needed too if you have more inputs than simultaneous channels.\n" - ">From a DT point of view the simultaneous channels vs inputs isn't meant\n" + "=46rom a DT point of view the simultaneous channels vs inputs isn't meant\n" "to be currently visible. It's a userspace problem and from IIO point\n" "of view a 'channel' is an input (you just might not be able to enable\n" "all channels at once!)\n" @@ -103,7 +107,7 @@ "of device where this has a different meaning. Perhaps\n" "adc_chan@ ?\n" "\n" - "> \n" + ">=20\n" "> Also, if your goal is to just quiet dtc warnings, then I'd prefer you\n" "> not. They often point to bigger issues even if they can be fixed with\n" "> trivial changes. Of course, if not fixed someone else will come along\n" @@ -114,7 +118,7 @@ "\n" "Jonathan\n" "\n" - "> \n" + ">=20\n" > Rob -56a00d2c54bdd60b873d9a3ec9a61e8a3ae97bf444f5c74f4070817b4a9009e2 +23a987b7b8b574ffb75779d171fd671332165fbb29cc448df94aa157c5543d28
diff --git a/a/1.txt b/N2/1.txt index ee17748..6f6c13e 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -67,7 +67,7 @@ Rob Herring <robh@kernel.org> wrote: > multi-channel ADCs is really up to you. There was another binding > recently which mapped sub-nodes to inputs rather than channels. Maybe > that's needed too if you have more inputs than simultaneous channels. ->From a DT point of view the simultaneous channels vs inputs isn't meant +From a DT point of view the simultaneous channels vs inputs isn't meant to be currently visible. It's a userspace problem and from IIO point of view a 'channel' is an input (you just might not be able to enable all channels at once!) diff --git a/a/content_digest b/N2/content_digest index 39b7159..b0bcdbf 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -19,8 +19,8 @@ Peter Meerwald <pmeerw@pmeerw.net> linux-arm-msm <linux-arm-msm@vger.kernel.org> open list:ARM/QUALCOMM SUPPORT <linux-soc@vger.kernel.org> - devicetree@vger.kernel.org - linux-iio@vger.kernel.org + <devicetree@vger.kernel.org> + <linux-iio@vger.kernel.org> linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> " Doug Anderson <dianders@chromium.org>\0" "\00:1\0" @@ -94,7 +94,7 @@ "> multi-channel ADCs is really up to you. There was another binding\n" "> recently which mapped sub-nodes to inputs rather than channels. Maybe\n" "> that's needed too if you have more inputs than simultaneous channels.\n" - ">From a DT point of view the simultaneous channels vs inputs isn't meant\n" + "From a DT point of view the simultaneous channels vs inputs isn't meant\n" "to be currently visible. It's a userspace problem and from IIO point\n" "of view a 'channel' is an input (you just might not be able to enable\n" "all channels at once!)\n" @@ -117,4 +117,4 @@ "> \n" > Rob -56a00d2c54bdd60b873d9a3ec9a61e8a3ae97bf444f5c74f4070817b4a9009e2 +7922c25ea71cfe792173bff36d15e6e7bc4bbf863a5785927a675def7733664a
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.