| Message ID | cover.1733504533.git.u.kleine-koenig@baylibre.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | iio: adc: ad7124: Various fixes | expand |
On Fri, Dec 6, 2024 at 7:29 PM Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote: > > Hello, > > here comes v6 of this series. Compared to v5 > (https://lore.kernel.org/linux-iio/20241203110019.1520071-12-u.kleine-koenig@baylibre.com) > the following things changed: > > - Rebased to v6.13-rc1 + 64612ec9b909. (No changes needed here.) > > - Add Ack from Conor to patch #3 > > - Fixed how R̅D̅Y̅ is written. This was wrong before because the overline > char must be added after the character that should get the overline, > not before. I got that wrong because of > https://bugs.debian.org/1089108. I would expect that now this is > properly shown in most browsers, MUAs and editors. > > I guess Andy still doesn't agree to write it that way. Yeah, I prefer a solid overline which Unicode simply incapable of, but HTML does. In any case the representation in this version is much better than in the previous version. I leave this up to Jonathan, but as I said an electrical engineer in me is not satisfied. > Jonathan, > would you decide here please? If you agree with Andy I suggest to > replace it by #RDY. Andy suggested #RDY_N which I think is too far > away from the original name. If you (also) like R̅D̅Y̅, just keep it as > is. > > - Fix error handling in patch #8 > I just pasted "return ret" to all callers of > ad_sigma_delta_clear_pending_event() before. Now the error handling > matches the actual needs of the context. > > - s/irq controller's capabilities/irq controller capabilities/ > as suggested by Andy for patch #8
On Fri, 6 Dec 2024 18:28:32 +0100 Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote: > Hello, > > here comes v6 of this series. Compared to v5 > (https://lore.kernel.org/linux-iio/20241203110019.1520071-12-u.kleine-koenig@baylibre.com) > the following things changed: > > - Rebased to v6.13-rc1 + 64612ec9b909. (No changes needed here.) > > - Add Ack from Conor to patch #3 > > - Fixed how R̅D̅Y̅ is written. This was wrong before because the overline > char must be added after the character that should get the overline, > not before. I got that wrong because of > https://bugs.debian.org/1089108. I would expect that now this is > properly shown in most browsers, MUAs and editors. > > I guess Andy still doesn't agree to write it that way. Jonathan, > would you decide here please? If you agree with Andy I suggest to > replace it by #RDY. Andy suggested #RDY_N which I think is too far > away from the original name. If you (also) like R̅D̅Y̅, just keep it as > is. > > - Fix error handling in patch #8 > I just pasted "return ret" to all callers of > ad_sigma_delta_clear_pending_event() before. Now the error handling > matches the actual needs of the context. > > - s/irq controller's capabilities/irq controller capabilities/ > as suggested by Andy for patch #8 > > Best regards > Uwe Hi Uwe Given the mix of fixes and other material (kind of fixes, but also kind of new functionality), I've queued this for the next merge window in my togreg branch. If you think there are particular patches that need to go sooner then I can handle them in a split fashion, but that does add risk that the whole lot might no land depending on timings (particularly given it's coming into vacation season). Initially pushed out as testing - I assume we'll see that sparse warning. Thanks, Jonathan > > Uwe Kleine-König (10): > iio: adc: ad7124: Don't create more channels than the driver can handle > iio: adc: ad7124: Refuse invalid input specifiers > dt-bindings: iio: adc: adi,ad7{124,173,192,780}: Allow specifications of a gpio for irq line > iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO > iio: adc: ad_sigma_delta: Handle CS assertion as intended in ad_sd_read_reg_raw() > iio: adc: ad_sigma_delta: Fix a race condition > iio: adc: ad_sigma_delta: Store information about reset sequence length > iio: adc: ad_sigma_delta: Check for previous ready signals > iio: adc: ad7124: Add error reporting during probe > iio: adc: ad7124: Implement temperature measurement > > .../bindings/iio/adc/adi,ad7124.yaml | 13 ++ > .../bindings/iio/adc/adi,ad7173.yaml | 12 + > .../bindings/iio/adc/adi,ad7192.yaml | 15 ++ > .../bindings/iio/adc/adi,ad7780.yaml | 11 + > drivers/iio/adc/ad7124.c | 217 +++++++++++++----- > drivers/iio/adc/ad7173.c | 1 + > drivers/iio/adc/ad7192.c | 4 +- > drivers/iio/adc/ad7791.c | 1 + > drivers/iio/adc/ad7793.c | 3 +- > drivers/iio/adc/ad_sigma_delta.c | 194 +++++++++++++--- > include/linux/iio/adc/ad_sigma_delta.h | 8 +- > 11 files changed, 390 insertions(+), 89 deletions(-) > > base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 > prerequisite-patch-id: 617af17fc377a984762c61893b9f2a92ae62213a
On Sat, 7 Dec 2024 01:12:56 +0200 Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Fri, Dec 6, 2024 at 7:29 PM Uwe Kleine-König > <u.kleine-koenig@baylibre.com> wrote: > > > > Hello, > > > > here comes v6 of this series. Compared to v5 > > (https://lore.kernel.org/linux-iio/20241203110019.1520071-12-u.kleine-koenig@baylibre.com) > > the following things changed: > > > > - Rebased to v6.13-rc1 + 64612ec9b909. (No changes needed here.) > > > > - Add Ack from Conor to patch #3 > > > > - Fixed how R̅D̅Y̅ is written. This was wrong before because the overline > > char must be added after the character that should get the overline, > > not before. I got that wrong because of > > https://bugs.debian.org/1089108. I would expect that now this is > > properly shown in most browsers, MUAs and editors. > > > > I guess Andy still doesn't agree to write it that way. > > Yeah, I prefer a solid overline which Unicode simply incapable of, but > HTML does. > In any case the representation in this version is much better than in > the previous version. > I leave this up to Jonathan, but as I said an electrical engineer in > me is not satisfied. Fully agree it's unsatisfying, but I think it is clear enough what is intended to go ahead as is. Jonathan > > > Jonathan, > > would you decide here please? If you agree with Andy I suggest to > > replace it by #RDY. Andy suggested #RDY_N which I think is too far > > away from the original name. If you (also) like R̅D̅Y̅, just keep it as > > is. > > > > - Fix error handling in patch #8 > > I just pasted "return ret" to all callers of > > ad_sigma_delta_clear_pending_event() before. Now the error handling > > matches the actual needs of the context. > > > > - s/irq controller's capabilities/irq controller capabilities/ > > as suggested by Andy for patch #8 >
Hello Jonathan, On Sun, Dec 08, 2024 at 12:44:27PM +0000, Jonathan Cameron wrote: > Given the mix of fixes and other material (kind of fixes, but also kind > of new functionality), I've queued this for the next merge window in my > togreg branch. If you think there are particular patches that need to > go sooner then I can handle them in a split fashion, but that does add > risk that the whole lot might no land depending on timings (particularly > given it's coming into vacation season). So you tend to not backport the rdy-gpios patches (i.e. dt-bindings: iio: adc: adi,ad7{124,173,192,780}: Allow specifications of a gpio for irq line iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO )? I personally would want to have these backported, too, but I can understand that you might decide that in a different way. Cherry picking iio: adc: ad_sigma_delta: Fix a race condition iio: adc: ad_sigma_delta: Check for previous ready signals isn't trivial without the rdy-gpios, but they could be reworked. Tell me if you want a helping hand (or an eye judging your backport). Best regards Uwe
On Mon, 9 Dec 2024 10:47:29 +0100 Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote: > Hello Jonathan, > > On Sun, Dec 08, 2024 at 12:44:27PM +0000, Jonathan Cameron wrote: > > Given the mix of fixes and other material (kind of fixes, but also kind > > of new functionality), I've queued this for the next merge window in my > > togreg branch. If you think there are particular patches that need to > > go sooner then I can handle them in a split fashion, but that does add > > risk that the whole lot might no land depending on timings (particularly > > given it's coming into vacation season). > > So you tend to not backport the rdy-gpios patches (i.e. > > dt-bindings: iio: adc: adi,ad7{124,173,192,780}: Allow specifications of a gpio for irq line > iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO > > )? I personally would want to have these backported, too, but I can > understand that you might decide that in a different way. Yeah. If it were tiny amount of code I might have gone the other way, but this just got a bit too complex. > > Cherry picking > > iio: adc: ad_sigma_delta: Fix a race condition > iio: adc: ad_sigma_delta: Check for previous ready signals > > isn't trivial without the rdy-gpios, but they could be reworked. Tell me > if you want a helping hand (or an eye judging your backport). > A backport won't go anywhere until these are upstream. At that point if you want them, feel free to suggest backporting these and provide the code ;) Thanks, Jonathan > Best regards > Uwe
On Wed, Dec 11, 2024 at 07:24:59PM +0000, Jonathan Cameron wrote: > On Mon, 9 Dec 2024 10:47:29 +0100 > Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote: > > > Hello Jonathan, > > > > On Sun, Dec 08, 2024 at 12:44:27PM +0000, Jonathan Cameron wrote: > > > Given the mix of fixes and other material (kind of fixes, but also kind > > > of new functionality), I've queued this for the next merge window in my > > > togreg branch. If you think there are particular patches that need to > > > go sooner then I can handle them in a split fashion, but that does add > > > risk that the whole lot might no land depending on timings (particularly > > > given it's coming into vacation season). > > > > So you tend to not backport the rdy-gpios patches (i.e. > > > > dt-bindings: iio: adc: adi,ad7{124,173,192,780}: Allow specifications of a gpio for irq line > > iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO > > > > )? I personally would want to have these backported, too, but I can > > understand that you might decide that in a different way. > > Yeah. If it were tiny amount of code I might have gone the other way, but > this just got a bit too complex. I think it is easy to see that the changes for the rdy-gpios support has zero impact if the device has no rdy-gpio. Then devm_gpiod_get_optional() returns NULL and !sigma_delta->rdy_gpiod is true and so nothing changes. Of course it's subjective if you agree this to be easy to see, and also if that matters for the backport. > > Cherry picking > > > > iio: adc: ad_sigma_delta: Fix a race condition > > iio: adc: ad_sigma_delta: Check for previous ready signals > > > > isn't trivial without the rdy-gpios, but they could be reworked. Tell me > > if you want a helping hand (or an eye judging your backport). > > A backport won't go anywhere until these are upstream. At that point if you > want them, feel free to suggest backporting these and provide the code ;) I've not given up hope that you agree to backport also the rdy-gpio change yet. I won't invest the work without knowing it's used in the end. So I'll wait until the changes are upstream and you made up your mind. Then if the need arises, I will help. Best regards Uwe
On Thu, Dec 12, 2024 at 1:28 PM Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote: > On Wed, Dec 11, 2024 at 07:24:59PM +0000, Jonathan Cameron wrote: > > On Mon, 9 Dec 2024 10:47:29 +0100 > > Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote: ... > > A backport won't go anywhere until these are upstream. At that point if you > > want them, feel free to suggest backporting these and provide the code ;) > > I've not given up hope that you agree to backport also the rdy-gpio > change yet. I won't invest the work without knowing it's used in the > end. So I'll wait until the changes are upstream and you made up your > mind. Then if the need arises, I will help. AFAIK the process, any contributor may suggest a bacport of a few patches if the justification is good enough, I don't understand how Jonathan's view can be an impediment here (he may be a help, of course).
On Thu, 12 Dec 2024 13:44:40 +0200 Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Thu, Dec 12, 2024 at 1:28 PM Uwe Kleine-König > <u.kleine-koenig@baylibre.com> wrote: > > On Wed, Dec 11, 2024 at 07:24:59PM +0000, Jonathan Cameron wrote: > > > On Mon, 9 Dec 2024 10:47:29 +0100 > > > Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote: > > ... > > > > A backport won't go anywhere until these are upstream. At that point if you > > > want them, feel free to suggest backporting these and provide the code ;) > > > > I've not given up hope that you agree to backport also the rdy-gpio > > change yet. I won't invest the work without knowing it's used in the > > end. So I'll wait until the changes are upstream and you made up your > > mind. Then if the need arises, I will help. > > AFAIK the process, any contributor may suggest a bacport of a few > patches if the justification is good enough, I don't understand how > Jonathan's view can be an impediment here (he may be a help, of > course). > I could in theory object (as could any reviewer!) but on this one I won't because I think it is justified, just not something to rush into without some soaking time in upstream. Thanks, Jonathan
Hello, here comes v6 of this series. Compared to v5 (https://lore.kernel.org/linux-iio/20241203110019.1520071-12-u.kleine-koenig@baylibre.com) the following things changed: - Rebased to v6.13-rc1 + 64612ec9b909. (No changes needed here.) - Add Ack from Conor to patch #3 - Fixed how R̅D̅Y̅ is written. This was wrong before because the overline char must be added after the character that should get the overline, not before. I got that wrong because of https://bugs.debian.org/1089108. I would expect that now this is properly shown in most browsers, MUAs and editors. I guess Andy still doesn't agree to write it that way. Jonathan, would you decide here please? If you agree with Andy I suggest to replace it by #RDY. Andy suggested #RDY_N which I think is too far away from the original name. If you (also) like R̅D̅Y̅, just keep it as is. - Fix error handling in patch #8 I just pasted "return ret" to all callers of ad_sigma_delta_clear_pending_event() before. Now the error handling matches the actual needs of the context. - s/irq controller's capabilities/irq controller capabilities/ as suggested by Andy for patch #8 Best regards Uwe Uwe Kleine-König (10): iio: adc: ad7124: Don't create more channels than the driver can handle iio: adc: ad7124: Refuse invalid input specifiers dt-bindings: iio: adc: adi,ad7{124,173,192,780}: Allow specifications of a gpio for irq line iio: adc: ad_sigma_delta: Add support for reading irq status using a GPIO iio: adc: ad_sigma_delta: Handle CS assertion as intended in ad_sd_read_reg_raw() iio: adc: ad_sigma_delta: Fix a race condition iio: adc: ad_sigma_delta: Store information about reset sequence length iio: adc: ad_sigma_delta: Check for previous ready signals iio: adc: ad7124: Add error reporting during probe iio: adc: ad7124: Implement temperature measurement .../bindings/iio/adc/adi,ad7124.yaml | 13 ++ .../bindings/iio/adc/adi,ad7173.yaml | 12 + .../bindings/iio/adc/adi,ad7192.yaml | 15 ++ .../bindings/iio/adc/adi,ad7780.yaml | 11 + drivers/iio/adc/ad7124.c | 217 +++++++++++++----- drivers/iio/adc/ad7173.c | 1 + drivers/iio/adc/ad7192.c | 4 +- drivers/iio/adc/ad7791.c | 1 + drivers/iio/adc/ad7793.c | 3 +- drivers/iio/adc/ad_sigma_delta.c | 194 +++++++++++++--- include/linux/iio/adc/ad_sigma_delta.h | 8 +- 11 files changed, 390 insertions(+), 89 deletions(-) base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 prerequisite-patch-id: 617af17fc377a984762c61893b9f2a92ae62213a