drivers/iio/magnetometer/ak8975.c | 253 +++++++++++++----------------- 1 file changed, 112 insertions(+), 141 deletions(-)
This series is an attempt to make the driver less a rabbit hole. It's a continuation of what Joshua Crofts started doing. Hence it is based on his work and first three "patches" here are supposed to be folded to his series accordingly. I have compile-tested them, but I haven't done full double check of the correctness from functional point of view. Joshua, please do that before incorporating into your series. Yes, my patches are assumed to become the part of Joshua's whatever next version of the series, that's why mine is marked as v0. Should not be taken directly by the maintainers, but any comments, review are highly appreciated. Andy Shevchenko (14): drivers/iio/magnetometer/ak8975.c: fixup for the IWYU change drivers/iio/magnetometer/ak8975.c: fixup for the errno fix drivers/iio/magnetometer/ak8975.c: fixup for the iopoll.h conversion iio: magnetometer: ak8975: Inline timeout constants iio: magnetometer: ak8975: Avoid using temporary variable iio: magnetometer: ak8975: Drop duplicate NULL check iio: magnetometer: ak8975: remove duplicate error message iio: magnetometer: ak8975: Reduce usage of magic lengths of the buffer iio: magnetometer: ak8975: Unify return code variable name iio: magnetometer: ak8975: switch to using managed resources iio: magnetometer: ak8975: Consistently use 'data' parameter iio: magnetometer: ak8975: Unify messages with help of dev_err_probe() iio: magnetometer: ak8975: Use temporary variable for struct device iio: magnetometer: ak8975: Make use of the macros from bits.h drivers/iio/magnetometer/ak8975.c | 253 +++++++++++++----------------- 1 file changed, 112 insertions(+), 141 deletions(-) -- 2.50.1
On Mon, 27 Apr 2026 22:09:45 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > This series is an attempt to make the driver less a rabbit hole. > It's a continuation of what Joshua Crofts started doing. Hence > it is based on his work and first three "patches" here are supposed > to be folded to his series accordingly. > > I have compile-tested them, but I haven't done full double check of > the correctness from functional point of view. Joshua, please do that > before incorporating into your series. Yes, my patches are assumed to > become the part of Joshua's whatever next version of the series, that's > why mine is marked as v0. > > Should not be taken directly by the maintainers, but any comments, review > are highly appreciated. > A few brief comments but mostly looks good in isolation. I'll wait for the fused set with the fixups applied to take a closer look. Thanks Andy J > Andy Shevchenko (14): > drivers/iio/magnetometer/ak8975.c: fixup for the IWYU change > drivers/iio/magnetometer/ak8975.c: fixup for the errno fix > drivers/iio/magnetometer/ak8975.c: fixup for the iopoll.h conversion > iio: magnetometer: ak8975: Inline timeout constants > iio: magnetometer: ak8975: Avoid using temporary variable > iio: magnetometer: ak8975: Drop duplicate NULL check > iio: magnetometer: ak8975: remove duplicate error message > iio: magnetometer: ak8975: Reduce usage of magic lengths of the buffer > iio: magnetometer: ak8975: Unify return code variable name > iio: magnetometer: ak8975: switch to using managed resources > iio: magnetometer: ak8975: Consistently use 'data' parameter > iio: magnetometer: ak8975: Unify messages with help of dev_err_probe() > iio: magnetometer: ak8975: Use temporary variable for struct device > iio: magnetometer: ak8975: Make use of the macros from bits.h > > drivers/iio/magnetometer/ak8975.c | 253 +++++++++++++----------------- > 1 file changed, 112 insertions(+), 141 deletions(-) >
On Tue, 28 Apr 2026 at 18:35, Jonathan Cameron <jic23@kernel.org> wrote: > > On Mon, 27 Apr 2026 22:09:45 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > This series is an attempt to make the driver less a rabbit hole. > > It's a continuation of what Joshua Crofts started doing. Hence > > it is based on his work and first three "patches" here are supposed > > to be folded to his series accordingly. > > > > I have compile-tested them, but I haven't done full double check of > > the correctness from functional point of view. Joshua, please do that > > before incorporating into your series. Yes, my patches are assumed to > > become the part of Joshua's whatever next version of the series, that's > > why mine is marked as v0. > > > > Should not be taken directly by the maintainers, but any comments, review > > are highly appreciated. > > > A few brief comments but mostly looks good in isolation. I'll wait > for the fused set with the fixups applied to take a closer look. > > Thanks Andy > > J > > Andy Shevchenko (14): > > drivers/iio/magnetometer/ak8975.c: fixup for the IWYU change > > drivers/iio/magnetometer/ak8975.c: fixup for the errno fix > > drivers/iio/magnetometer/ak8975.c: fixup for the iopoll.h conversion > > iio: magnetometer: ak8975: Inline timeout constants > > iio: magnetometer: ak8975: Avoid using temporary variable > > iio: magnetometer: ak8975: Drop duplicate NULL check > > iio: magnetometer: ak8975: remove duplicate error message > > iio: magnetometer: ak8975: Reduce usage of magic lengths of the buffer > > iio: magnetometer: ak8975: Unify return code variable name > > iio: magnetometer: ak8975: switch to using managed resources > > iio: magnetometer: ak8975: Consistently use 'data' parameter > > iio: magnetometer: ak8975: Unify messages with help of dev_err_probe() > > iio: magnetometer: ak8975: Use temporary variable for struct device > > iio: magnetometer: ak8975: Make use of the macros from bits.h > > > > drivers/iio/magnetometer/ak8975.c | 253 +++++++++++++----------------- > > 1 file changed, 112 insertions(+), 141 deletions(-) > > Given the relatively big backlog of email in the list, should I wait a bit longer sending the combined series? -- Kind regards CJD
On Mon, May 04, 2026 at 11:13:36AM +0200, Joshua Crofts wrote: > On Tue, 28 Apr 2026 at 18:35, Jonathan Cameron <jic23@kernel.org> wrote: ... > Given the relatively big backlog of email in the list, should I wait a > bit longer sending the combined series? I'm fine if you send it today or this week. -- With Best Regards, Andy Shevchenko
On Mon, 4 May 2026 at 11:18, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, May 04, 2026 at 11:13:36AM +0200, Joshua Crofts wrote: > > On Tue, 28 Apr 2026 at 18:35, Jonathan Cameron <jic23@kernel.org> wrote: > > ... > > > Given the relatively big backlog of email in the list, should I wait a > > bit longer sending the combined series? > > I'm fine if you send it today or this week. Is it fine if I do a RESEND PATCH after rebasing or should I wait? Sashiko reported "failed to apply". -- Kind regards CJD
On Mon, May 04, 2026 at 12:13:45PM +0200, Joshua Crofts wrote: > On Mon, 4 May 2026 at 11:18, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, May 04, 2026 at 11:13:36AM +0200, Joshua Crofts wrote: > > > On Tue, 28 Apr 2026 at 18:35, Jonathan Cameron <jic23@kernel.org> wrote: ... > > > Given the relatively big backlog of email in the list, should I wait a > > > bit longer sending the combined series? > > > > I'm fine if you send it today or this week. > > Is it fine if I do a RESEND PATCH after rebasing or should I wait? Sashiko > reported "failed to apply". Better to wait, have you missed the --base argument? Or is it incorrect? -- With Best Regards, Andy Shevchenko
On Mon, 4 May 2026 at 12:20, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Mon, May 04, 2026 at 12:13:45PM +0200, Joshua Crofts wrote: > > On Mon, 4 May 2026 at 11:18, Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > On Mon, May 04, 2026 at 11:13:36AM +0200, Joshua Crofts wrote: > > > > On Tue, 28 Apr 2026 at 18:35, Jonathan Cameron <jic23@kernel.org> wrote: > > ... > > > > > Given the relatively big backlog of email in the list, should I wait a > > > > bit longer sending the combined series? > > > > > > I'm fine if you send it today or this week. > > > > Is it fine if I do a RESEND PATCH after rebasing or should I wait? Sashiko > > reported "failed to apply". > > Better to wait, have you missed the --base argument? Or is it incorrect? I use b4, so the base-commit was included in the cover letter, but looking at it - it's a commit from a month ago, so not good. -- Kind regards CJD
On Mon, 27 Apr 2026 at 22:14, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > This series is an attempt to make the driver less a rabbit hole. > It's a continuation of what Joshua Crofts started doing. Hence > it is based on his work and first three "patches" here are supposed > to be folded to his series accordingly. > > I have compile-tested them, but I haven't done full double check of > the correctness from functional point of view. Joshua, please do that > before incorporating into your series. Yes, my patches are assumed to > become the part of Joshua's whatever next version of the series, that's > why mine is marked as v0. > > Should not be taken directly by the maintainers, but any comments, review > are highly appreciated. When you said a few changes, I didn't expect an 11-part series :). I'll go over them and am them to my branch. I might check out the guard()() and chip_info changes. -- Kind regards CJD
On Tue, Apr 28, 2026 at 08:37:22AM +0200, Joshua Crofts wrote: > On Mon, 27 Apr 2026 at 22:14, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > This series is an attempt to make the driver less a rabbit hole. > > It's a continuation of what Joshua Crofts started doing. Hence > > it is based on his work and first three "patches" here are supposed > > to be folded to his series accordingly. > > > > I have compile-tested them, but I haven't done full double check of > > the correctness from functional point of view. Joshua, please do that > > before incorporating into your series. Yes, my patches are assumed to > > become the part of Joshua's whatever next version of the series, that's > > why mine is marked as v0. > > > > Should not be taken directly by the maintainers, but any comments, review > > are highly appreciated. > > When you said a few changes, I didn't expect an 11-part series :). I'll go over > them and am them to my branch. I might check out the guard()() and chip_info > changes. On top of that also one may consider to switching to use reset-gpio instead of poking "reset" GPIO directly. But this sounds like too many for one go, let's make this 17 patch series go (6 yours + 11 mine). -- With Best Regards, Andy Shevchenko
On Tue, 28 Apr 2026 at 09:03, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Tue, Apr 28, 2026 at 08:37:22AM +0200, Joshua Crofts wrote: > > On Mon, 27 Apr 2026 at 22:14, Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > This series is an attempt to make the driver less a rabbit hole. > > > It's a continuation of what Joshua Crofts started doing. Hence > > > it is based on his work and first three "patches" here are supposed > > > to be folded to his series accordingly. > > > > > > I have compile-tested them, but I haven't done full double check of > > > the correctness from functional point of view. Joshua, please do that > > > before incorporating into your series. Yes, my patches are assumed to > > > become the part of Joshua's whatever next version of the series, that's > > > why mine is marked as v0. > > > > > > Should not be taken directly by the maintainers, but any comments, review > > > are highly appreciated. > > > > When you said a few changes, I didn't expect an 11-part series :). I'll go over > > them and am them to my branch. I might check out the guard()() and chip_info > > changes. > > On top of that also one may consider to switching to use reset-gpio instead of > poking "reset" GPIO directly. But this sounds like too many for one go, let's > make this 17 patch series go (6 yours + 11 mine). Fair enough, perhaps another time. BTW, if I'm sending your patches to the list, I should also add a Signed-off-by tag to the end, right? -- Kind regards CJD
On Tue, 28 Apr 2026 09:14:55 +0200 Joshua Crofts <joshua.crofts1@gmail.com> wrote: > On Tue, 28 Apr 2026 at 09:03, Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Tue, Apr 28, 2026 at 08:37:22AM +0200, Joshua Crofts wrote: > > > On Mon, 27 Apr 2026 at 22:14, Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > > This series is an attempt to make the driver less a rabbit hole. > > > > It's a continuation of what Joshua Crofts started doing. Hence > > > > it is based on his work and first three "patches" here are supposed > > > > to be folded to his series accordingly. > > > > > > > > I have compile-tested them, but I haven't done full double check of > > > > the correctness from functional point of view. Joshua, please do that > > > > before incorporating into your series. Yes, my patches are assumed to > > > > become the part of Joshua's whatever next version of the series, that's > > > > why mine is marked as v0. > > > > > > > > Should not be taken directly by the maintainers, but any comments, review > > > > are highly appreciated. > > > > > > When you said a few changes, I didn't expect an 11-part series :). I'll go over > > > them and am them to my branch. I might check out the guard()() and chip_info > > > changes. > > > > On top of that also one may consider to switching to use reset-gpio instead of > > poking "reset" GPIO directly. But this sounds like too many for one go, let's > > make this 17 patch series go (6 yours + 11 mine). > > Fair enough, perhaps another time. > > BTW, if I'm sending your patches to the list, I should also add a Signed-off-by > tag to the end, right? > Yes. You are 'handling' the patches, so need to add your sign off.
On Tue, 28 Apr 2026 at 18:16, Jonathan Cameron <jic23@kernel.org> wrote: > Yes. You are 'handling' the patches, so need to add your sign off. Thanks for the clarification. -- Kind regards CJD
On Mon, Apr 27, 2026 at 10:09:45PM +0200, Andy Shevchenko wrote: > This series is an attempt to make the driver less a rabbit hole. FWIW, the more refactoring and cleaning up may be - moving to guard()() - requires preparatory refactoring - splitting chip_info array to individual data, getting rid of .type field When I looked into them, I understood that my time slot for this driver is fully consumed (and even more) already, so I leave it to the motivated people. > It's a continuation of what Joshua Crofts started doing. Hence > it is based on his work and first three "patches" here are supposed > to be folded to his series accordingly. > > I have compile-tested them, but I haven't done full double check of > the correctness from functional point of view. Joshua, please do that > before incorporating into your series. Yes, my patches are assumed to > become the part of Joshua's whatever next version of the series, that's > why mine is marked as v0. > > Should not be taken directly by the maintainers, but any comments, review > are highly appreciated. -- With Best Regards, Andy Shevchenko
© 2016 - 2026 Red Hat, Inc.