diff for duplicates of <20230720192428.2faaaf68@jic23-huawei> diff --git a/a/1.txt b/N1/1.txt index 63a7664..28537d6 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,52 +1,73 @@ -On Sun, 16 Jul 2023 14:42:23 +0100 -Jonathan Cameron <jic23@kernel.org> wrote: - -> On Tue, 11 Jul 2023 12:08:04 +0300 -> Andy Shevchenko <andy.shevchenko@gmail.com> wrote: +> On Sun, 16 Jul 2023 14:42:23 +0100 +> Jonathan Cameron <jic23@kernel.org> wrote: > -> > On Tue, Jul 11, 2023 at 9:55 AM Paller, Kim Seer -> > <KimSeer.Paller@analog.com> wrote: -> > > > From: Andy Shevchenko <andy.shevchenko@gmail.com> -> > > > On Mon, Jul 10, 2023 at 11:17 AM Paller, Kim Seer -> > > > <KimSeer.Paller@analog.com> wrote: -> > -> > ... -> > -> > > > Hence instead of v10, reply with a draft of the comment in the code (I -> > > > have asked before) that explains these bit twiddlers. -> > > -> > > In patch v9, regarding with my bit arrangement comments, is it somewhat correct -> > > or do I need to totally replace it? -> > > -> > > I am not yet familiar with the terminologies, so I hope you can provide some -> > > suggestions and I'll definitely send the draft first. +> > On Tue, 11 Jul 2023 12:08:04 +0300 +> > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > -> > I'm not sure I understand what comments you are referring to. -> > The v9 does not explain the algorithm clearly. +> > > On Tue, Jul 11, 2023 at 9:55 AM Paller, Kim Seer +> > > <KimSeer.Paller@analog.com> wrote: +> > > > > From: Andy Shevchenko <andy.shevchenko@gmail.com> +> > > > > On Mon, Jul 10, 2023 at 11:17 AM Paller, Kim Seer +> > > > > <KimSeer.Paller@analog.com> wrote: +> > > +> > > ... +> > > +> > > > > Hence instead of v10, reply with a draft of the comment in the code (I +> > > > > have asked before) that explains these bit twiddlers. +> > > > +> > > > In patch v9, regarding with my bit arrangement comments, is it somewhat correct +> > > > or do I need to totally replace it? +> > > > +> > > > I am not yet familiar with the terminologies, so I hope you can provide some +> > > > suggestions and I'll definitely send the draft first. +> > > +> > > I'm not sure I understand what comments you are referring to. +> > > The v9 does not explain the algorithm clearly. +> > > +> > > What you need is to cite or retell what the datasheet explains about +> > > bit ordering along with the proposed algo (in AN as far as I +> > > understood). Because I haven't got, why do you need to use be16 + +> > > bitrev if your data is le16 (and that's my understanding of the +> > > datasheet). Is it because of the answer from the device? I don't +> > > remember if it keep the bit order the same (i.e. D0...D9) as on the +> > > wire. +> > > +> > > For the terminology, use what the datasheet and AN provide you. Also +> > > good to put those URLs to the code and datasheet as Datasheet: tag in +> > > the commit message. +> > > > > -> > What you need is to cite or retell what the datasheet explains about -> > bit ordering along with the proposed algo (in AN as far as I -> > understood). Because I haven't got, why do you need to use be16 + -> > bitrev if your data is le16 (and that's my understanding of the -> > datasheet). Is it because of the answer from the device? I don't -> > remember if it keep the bit order the same (i.e. D0...D9) as on the -> > wire. +> > Absolutely agree. The data format is weird enough we need the +> > info to be available for anyone who tries to work out what is going +> > on in the future. This is a case where I'd rather see too much detail +> > in the comments than too little! > > -> > For the terminology, use what the datasheet and AN provide you. Also -> > good to put those URLs to the code and datasheet as Datasheet: tag in -> > the commit message. -> > +> > Jonathan > -> Absolutely agree. The data format is weird enough we need the -> info to be available for anyone who tries to work out what is going -> on in the future. This is a case where I'd rather see too much detail -> in the comments than too little! -> -> Jonathan +> Note that I had applied (and forgotten I'd done so) this driver. +> Given the outstanding questions and a build issue with clang, I'm dropping +> it for now. Hopefully that doesn't cause anyone too many problems (those +> based on my togreg branch which rarely rebases) + +It feels like in a cartoon, when there's banana peel on the floor and somebody +comes and steps right into it. Oh my, hope at least the title of most +spectacular patch set fail of the year can be ours. + +Jokes apart, what would be the best way to collaborate towards +providing/improving support for max14001? I suppose the only option left was to +apply something on top of Kim's patch set, but maybe Kim's work can be improved +with a few things from Marilene's set. Her device tree documentation is more +complete and follows datasheet nomenclature for voltage supplies. Her set also +uses newer regulator APIs and adds support for max14002. + +Kim, would you mind if Marilene generates a v10 of your set with the suggested +improvements? + +Besides that, I think Marilene has the evaluation board set up to do any +additional tests if needed. + +Let me know your thoughts. -Note that I had applied (and forgotten I'd done so) this driver. -Given the outstanding questions and a build issue with clang, I'm dropping -it for now. Hopefully that doesn't cause anyone too many problems (those -based on my togreg branch which rarely rebases) -Jonathan +Thanks, +Marcelo diff --git a/a/content_digest b/N1/content_digest index f76dd3f..0a20b74 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -6,69 +6,93 @@ "ref\0fe0cd5348f864a6392a7e0e5ca93bec5@analog.com\0" "ref\0CAHp75VcpguSN9DkuCtpaB+_=sY7+Ot1MGPWToe-2pYjFXC9=4Q@mail.gmail.com\0" "ref\020230716144223.0d9260d3@jic23-huawei\0" - "From\0Jonathan Cameron <jic23@kernel.org>\0" + "From\0Marcelo Schmitt <marcelo.schmitt1@gmail.com>\0" "Subject\0Re: [PATCH v9 2/2] iio: adc: max14001: New driver\0" - "Date\0Thu, 20 Jul 2023 19:24:28 +0100\0" - "To\0Andy Shevchenko <andy.shevchenko@gmail.com>\0" + "Date\0Fri, 22 Aug 2025 22:50:12 -0300\0" + "To\0Jonathan Cameron <jic23@kernel.org>\0" "Cc\0Paller" Kim Seer <KimSeer.Paller@analog.com> + Andy Shevchenko <andy.shevchenko@gmail.com> Hennerich Michael <Michael.Hennerich@analog.com> linux-iio <linux-iio@vger.kernel.org> - " Lars-Peter Clausen <lars@metafoo.de>\0" + Lars-Peter Clausen <lars@metafoo.de> + marilene.agarcia@gmail.com + " marcelo.schmitt1@gmail.com\0" "\00:1\0" "b\0" - "On Sun, 16 Jul 2023 14:42:23 +0100\n" - "Jonathan Cameron <jic23@kernel.org> wrote:\n" - "\n" - "> On Tue, 11 Jul 2023 12:08:04 +0300\n" - "> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:\n" + "> On Sun, 16 Jul 2023 14:42:23 +0100\n" + "> Jonathan Cameron <jic23@kernel.org> wrote:\n" "> \n" - "> > On Tue, Jul 11, 2023 at 9:55\342\200\257AM Paller, Kim Seer\n" - "> > <KimSeer.Paller@analog.com> wrote: \n" - "> > > > From: Andy Shevchenko <andy.shevchenko@gmail.com>\n" - "> > > > On Mon, Jul 10, 2023 at 11:17\342\200\257AM Paller, Kim Seer\n" - "> > > > <KimSeer.Paller@analog.com> wrote: \n" - "> > \n" - "> > ...\n" - "> > \n" - "> > > > Hence instead of v10, reply with a draft of the comment in the code (I\n" - "> > > > have asked before) that explains these bit twiddlers. \n" - "> > >\n" - "> > > In patch v9, regarding with my bit arrangement comments, is it somewhat correct\n" - "> > > or do I need to totally replace it?\n" - "> > >\n" - "> > > I am not yet familiar with the terminologies, so I hope you can provide some\n" - "> > > suggestions and I'll definitely send the draft first. \n" + "> > On Tue, 11 Jul 2023 12:08:04 +0300\n" + "> > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:\n" "> > \n" - "> > I'm not sure I understand what comments you are referring to.\n" - "> > The v9 does not explain the algorithm clearly.\n" + "> > > On Tue, Jul 11, 2023 at 9:55\342\200\257AM Paller, Kim Seer\n" + "> > > <KimSeer.Paller@analog.com> wrote: \n" + "> > > > > From: Andy Shevchenko <andy.shevchenko@gmail.com>\n" + "> > > > > On Mon, Jul 10, 2023 at 11:17\342\200\257AM Paller, Kim Seer\n" + "> > > > > <KimSeer.Paller@analog.com> wrote: \n" + "> > > \n" + "> > > ...\n" + "> > > \n" + "> > > > > Hence instead of v10, reply with a draft of the comment in the code (I\n" + "> > > > > have asked before) that explains these bit twiddlers. \n" + "> > > >\n" + "> > > > In patch v9, regarding with my bit arrangement comments, is it somewhat correct\n" + "> > > > or do I need to totally replace it?\n" + "> > > >\n" + "> > > > I am not yet familiar with the terminologies, so I hope you can provide some\n" + "> > > > suggestions and I'll definitely send the draft first. \n" + "> > > \n" + "> > > I'm not sure I understand what comments you are referring to.\n" + "> > > The v9 does not explain the algorithm clearly.\n" + "> > > \n" + "> > > What you need is to cite or retell what the datasheet explains about\n" + "> > > bit ordering along with the proposed algo (in AN as far as I\n" + "> > > understood). Because I haven't got, why do you need to use be16 +\n" + "> > > bitrev if your data is le16 (and that's my understanding of the\n" + "> > > datasheet). Is it because of the answer from the device? I don't\n" + "> > > remember if it keep the bit order the same (i.e. D0...D9) as on the\n" + "> > > wire.\n" + "> > > \n" + "> > > For the terminology, use what the datasheet and AN provide you. Also\n" + "> > > good to put those URLs to the code and datasheet as Datasheet: tag in\n" + "> > > the commit message.\n" + "> > > \n" "> > \n" - "> > What you need is to cite or retell what the datasheet explains about\n" - "> > bit ordering along with the proposed algo (in AN as far as I\n" - "> > understood). Because I haven't got, why do you need to use be16 +\n" - "> > bitrev if your data is le16 (and that's my understanding of the\n" - "> > datasheet). Is it because of the answer from the device? I don't\n" - "> > remember if it keep the bit order the same (i.e. D0...D9) as on the\n" - "> > wire.\n" + "> > Absolutely agree. The data format is weird enough we need the\n" + "> > info to be available for anyone who tries to work out what is going\n" + "> > on in the future. This is a case where I'd rather see too much detail\n" + "> > in the comments than too little!\n" "> > \n" - "> > For the terminology, use what the datasheet and AN provide you. Also\n" - "> > good to put those URLs to the code and datasheet as Datasheet: tag in\n" - "> > the commit message.\n" - "> > \n" + "> > Jonathan\n" "> \n" - "> Absolutely agree. The data format is weird enough we need the\n" - "> info to be available for anyone who tries to work out what is going\n" - "> on in the future. This is a case where I'd rather see too much detail\n" - "> in the comments than too little!\n" - "> \n" - "> Jonathan\n" + "> Note that I had applied (and forgotten I'd done so) this driver.\n" + "> Given the outstanding questions and a build issue with clang, I'm dropping\n" + "> it for now. Hopefully that doesn't cause anyone too many problems (those\n" + "> based on my togreg branch which rarely rebases)\n" + "\n" + "It feels like in a cartoon, when there's banana peel on the floor and somebody\n" + "comes and steps right into it. Oh my, hope at least the title of most\n" + "spectacular patch set fail of the year can be ours.\n" + "\n" + "Jokes apart, what would be the best way to collaborate towards\n" + "providing/improving support for max14001? I suppose the only option left was to\n" + "apply something on top of Kim's patch set, but maybe Kim's work can be improved\n" + "with a few things from Marilene's set. Her device tree documentation is more\n" + "complete and follows datasheet nomenclature for voltage supplies. Her set also\n" + "uses newer regulator APIs and adds support for max14002.\n" + "\n" + "Kim, would you mind if Marilene generates a v10 of your set with the suggested\n" + "improvements?\n" + "\n" + "Besides that, I think Marilene has the evaluation board set up to do any\n" + "additional tests if needed. \n" + "\n" + "Let me know your thoughts.\n" "\n" - "Note that I had applied (and forgotten I'd done so) this driver.\n" - "Given the outstanding questions and a build issue with clang, I'm dropping\n" - "it for now. Hopefully that doesn't cause anyone too many problems (those\n" - "based on my togreg branch which rarely rebases)\n" "\n" - Jonathan + "Thanks,\n" + Marcelo -7c8c57d67fd28b48d4a2436b811e77df858b0d0d174c7258bfd15a4bcec3dca4 +3221139186a1cacce23e03e04d1fd03b63344e82f6d74cf2eb92e9b583f6acab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox