* [PATCH] iio:frequency:adf4377: Fix duplicated soft reset mask @ 2025-12-30 12:36 SeungJu Cheon 2025-12-30 12:57 ` Andy Shevchenko 2025-12-30 13:21 ` [PATCH v2] " SeungJu Cheon 0 siblings, 2 replies; 8+ messages in thread From: SeungJu Cheon @ 2025-12-30 12:36 UTC (permalink / raw) To: antoniu.miclaus, lars, Michael.Hennerich, jic23 Cc: dlechner, nuno.sa, andy, linux-iio, linux-kernel, SeungJu Cheon The regmap_read_poll_timeout() uses ADF4377_0000_SOFT_RESET_R_MSK twice instead of checking both SOFT_RESET_MSK (bit 0) and SOFT_RESET_R_MSK (bit 7). This causes incomplete reset status check. Fix by using both masks as done in regmap_update_bits() above. Signed-off-by: SeungJu Cheon <suunj1331@gmail.com> --- drivers/iio/frequency/adf4377.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/frequency/adf4377.c b/drivers/iio/frequency/adf4377.c index 08833b7035e4..48aa4b015a14 100644 --- a/drivers/iio/frequency/adf4377.c +++ b/drivers/iio/frequency/adf4377.c @@ -501,7 +501,7 @@ static int adf4377_soft_reset(struct adf4377_state *st) return ret; return regmap_read_poll_timeout(st->regmap, 0x0, read_val, - !(read_val & (ADF4377_0000_SOFT_RESET_R_MSK | + !(read_val & (ADF4377_0000_SOFT_RESET_MSK | ADF4377_0000_SOFT_RESET_R_MSK)), 200, 200 * 100); } -- 2.52.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] iio:frequency:adf4377: Fix duplicated soft reset mask 2025-12-30 12:36 [PATCH] iio:frequency:adf4377: Fix duplicated soft reset mask SeungJu Cheon @ 2025-12-30 12:57 ` Andy Shevchenko 2025-12-30 13:21 ` [PATCH v2] " SeungJu Cheon 1 sibling, 0 replies; 8+ messages in thread From: Andy Shevchenko @ 2025-12-30 12:57 UTC (permalink / raw) To: SeungJu Cheon Cc: antoniu.miclaus, lars, Michael.Hennerich, jic23, dlechner, nuno.sa, andy, linux-iio, linux-kernel On Tue, Dec 30, 2025 at 09:36:09PM +0900, SeungJu Cheon wrote: > The regmap_read_poll_timeout() uses ADF4377_0000_SOFT_RESET_R_MSK > twice instead of checking both SOFT_RESET_MSK (bit 0) and > SOFT_RESET_R_MSK (bit 7). This causes incomplete reset status check. > > Fix by using both masks as done in regmap_update_bits() above. Shouldn't we have a Fixes tag here? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2] iio:frequency:adf4377: Fix duplicated soft reset mask 2025-12-30 12:36 [PATCH] iio:frequency:adf4377: Fix duplicated soft reset mask SeungJu Cheon 2025-12-30 12:57 ` Andy Shevchenko @ 2025-12-30 13:21 ` SeungJu Cheon 2025-12-31 11:19 ` Andy Shevchenko 1 sibling, 1 reply; 8+ messages in thread From: SeungJu Cheon @ 2025-12-30 13:21 UTC (permalink / raw) To: antoniu.miclaus, lars, Michael.Hennerich, jic23 Cc: andriy.shevchenko, dlechner, nuno.sa, andy, linux-iio, linux-kernel, SeungJu Cheon The regmap_read_poll_timeout() uses ADF4377_0000_SOFT_RESET_R_MSK twice instead of checking both SOFT_RESET_MSK (bit 0) and SOFT_RESET_R_MSK (bit 7). This causes incomplete reset status check. Fix by using both masks as done in regmap_update_bits() above. Fixes: eda549e2e524 ("iio:frequency:adf4377: add support for ADF4377") Signed-off-by: SeungJu Cheon <suunj1331@gmail.com> --- drivers/iio/frequency/adf4377.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/frequency/adf4377.c b/drivers/iio/frequency/adf4377.c index 08833b7035e4..48aa4b015a14 100644 --- a/drivers/iio/frequency/adf4377.c +++ b/drivers/iio/frequency/adf4377.c @@ -501,7 +501,7 @@ static int adf4377_soft_reset(struct adf4377_state *st) return ret; return regmap_read_poll_timeout(st->regmap, 0x0, read_val, - !(read_val & (ADF4377_0000_SOFT_RESET_R_MSK | + !(read_val & (ADF4377_0000_SOFT_RESET_MSK | ADF4377_0000_SOFT_RESET_R_MSK)), 200, 200 * 100); } -- 2.52.0 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v2] iio:frequency:adf4377: Fix duplicated soft reset mask 2025-12-30 13:21 ` [PATCH v2] " SeungJu Cheon @ 2025-12-31 11:19 ` Andy Shevchenko 2026-01-11 12:09 ` Jonathan Cameron 0 siblings, 1 reply; 8+ messages in thread From: Andy Shevchenko @ 2025-12-31 11:19 UTC (permalink / raw) To: SeungJu Cheon Cc: antoniu.miclaus, lars, Michael.Hennerich, jic23, andriy.shevchenko, dlechner, nuno.sa, andy, linux-iio, linux-kernel On Tue, Dec 30, 2025 at 3:21 PM SeungJu Cheon <suunj1331@gmail.com> wrote: > > The regmap_read_poll_timeout() uses ADF4377_0000_SOFT_RESET_R_MSK > twice instead of checking both SOFT_RESET_MSK (bit 0) and > SOFT_RESET_R_MSK (bit 7). This causes incomplete reset status check. an incomplete > Fix by using both masks as done in regmap_update_bits() above. ... May I ask how you tested this? Logically from the code it sounds correct, but I haven't read the datasheet yet, so I can't tell if this is the expected value to read or not. > return regmap_read_poll_timeout(st->regmap, 0x0, read_val, > - !(read_val & (ADF4377_0000_SOFT_RESET_R_MSK | > + !(read_val & (ADF4377_0000_SOFT_RESET_MSK | > ADF4377_0000_SOFT_RESET_R_MSK)), 200, 200 * 100); Okay, I opened the datasheet, and the below is what I read there. The code first sets the SOFT_RESET_R and SOFT_RESET bits to "1", and waits for them to be cleared. But the Table 43 does not mention that SOFT_RESET_R is auto cleaned, and actually I don't see with a brief look what the "repeat of" term means. And for normal operation they needs to be 0ed as per: "SOFT_RESET, SOFT_RESET_R, RST_SYS, and ADC_ST_CNV are the only remaining RW bit fields not mentioned yet, and must also be set to their POR state (see Table 34)." With that said, I would wait for AD people to clarify the programming workflow here. -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] iio:frequency:adf4377: Fix duplicated soft reset mask 2025-12-31 11:19 ` Andy Shevchenko @ 2026-01-11 12:09 ` Jonathan Cameron 2026-01-23 9:44 ` Jonathan Cameron 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Cameron @ 2026-01-11 12:09 UTC (permalink / raw) To: Andy Shevchenko Cc: SeungJu Cheon, antoniu.miclaus, lars, Michael.Hennerich, andriy.shevchenko, dlechner, nuno.sa, andy, linux-iio, linux-kernel On Wed, 31 Dec 2025 13:19:46 +0200 Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > On Tue, Dec 30, 2025 at 3:21 PM SeungJu Cheon <suunj1331@gmail.com> wrote: > > > > The regmap_read_poll_timeout() uses ADF4377_0000_SOFT_RESET_R_MSK > > twice instead of checking both SOFT_RESET_MSK (bit 0) and > > SOFT_RESET_R_MSK (bit 7). This causes incomplete reset status check. > > an incomplete > > > Fix by using both masks as done in regmap_update_bits() above. > > ... > > > May I ask how you tested this? Logically from the code it sounds > correct, but I haven't read the datasheet yet, so I can't tell if this > is the expected value to read or not. > > > > return regmap_read_poll_timeout(st->regmap, 0x0, read_val, > > - !(read_val & (ADF4377_0000_SOFT_RESET_R_MSK | > > + !(read_val & (ADF4377_0000_SOFT_RESET_MSK | > > ADF4377_0000_SOFT_RESET_R_MSK)), 200, 200 * 100); > > Okay, I opened the datasheet, and the below is what I read there. The > code first sets the SOFT_RESET_R and SOFT_RESET bits to "1", and waits > for them to be cleared. But the Table 43 does not mention that > SOFT_RESET_R is auto cleaned, and actually I don't see with a brief > look what the "repeat of" term means. > > And for normal operation they needs to be 0ed as per: > "SOFT_RESET, SOFT_RESET_R, RST_SYS, and ADC_ST_CNV are the only > remaining RW bit fields not mentioned yet, and must also be set to > their POR state (see Table 34)." > > With that said, I would wait for AD people to clarify the programming > workflow here. > Small kernel development process thing as well. Please don't send a v2 in reply to a v1. It can become very confusing if we end up with a larger number of versions. Much better to just post a new thread for each version, and include a link back to the lore archive of the previous version in your cover letter. Also from a practical point of view, it ends up pages up in people's inboxes and so is is less likely to get reviewed! Thanks Jonathan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] iio:frequency:adf4377: Fix duplicated soft reset mask 2026-01-11 12:09 ` Jonathan Cameron @ 2026-01-23 9:44 ` Jonathan Cameron 2026-01-23 10:08 ` Miclaus, Antoniu 0 siblings, 1 reply; 8+ messages in thread From: Jonathan Cameron @ 2026-01-23 9:44 UTC (permalink / raw) To: Andy Shevchenko, Michael.Hennerich, nuno.sa Cc: SeungJu Cheon, antoniu.miclaus, lars, andriy.shevchenko, dlechner, andy, linux-iio, linux-kernel On Sun, 11 Jan 2026 12:09:25 +0000 Jonathan Cameron <jic23@kernel.org> wrote: > On Wed, 31 Dec 2025 13:19:46 +0200 > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > On Tue, Dec 30, 2025 at 3:21 PM SeungJu Cheon <suunj1331@gmail.com> wrote: > > > > > > The regmap_read_poll_timeout() uses ADF4377_0000_SOFT_RESET_R_MSK > > > twice instead of checking both SOFT_RESET_MSK (bit 0) and > > > SOFT_RESET_R_MSK (bit 7). This causes incomplete reset status check. > > > > an incomplete > > > > > Fix by using both masks as done in regmap_update_bits() above. > > > > ... > > > > > > May I ask how you tested this? Logically from the code it sounds > > correct, but I haven't read the datasheet yet, so I can't tell if this > > is the expected value to read or not. > > > > > > > return regmap_read_poll_timeout(st->regmap, 0x0, read_val, > > > - !(read_val & (ADF4377_0000_SOFT_RESET_R_MSK | > > > + !(read_val & (ADF4377_0000_SOFT_RESET_MSK | > > > ADF4377_0000_SOFT_RESET_R_MSK)), 200, 200 * 100); > > > > Okay, I opened the datasheet, and the below is what I read there. The > > code first sets the SOFT_RESET_R and SOFT_RESET bits to "1", and waits > > for them to be cleared. But the Table 43 does not mention that > > SOFT_RESET_R is auto cleaned, and actually I don't see with a brief > > look what the "repeat of" term means. > > > > And for normal operation they needs to be 0ed as per: > > "SOFT_RESET, SOFT_RESET_R, RST_SYS, and ADC_ST_CNV are the only > > remaining RW bit fields not mentioned yet, and must also be set to > > their POR state (see Table 34)." > > > > With that said, I would wait for AD people to clarify the programming > > workflow here. > > > > Small kernel development process thing as well. Please don't send a v2 in reply to a v1. > It can become very confusing if we end up with a larger number of versions. > Much better to just post a new thread for each version, and include > a link back to the lore archive of the previous version in your cover letter. > > Also from a practical point of view, it ends up pages up in people's inboxes and > so is is less likely to get reviewed! > > Thanks > > Jonathan > ADI folk. This is waiting for one of you to take a look at the questions Andy raised. Thanks! Jonathan ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH v2] iio:frequency:adf4377: Fix duplicated soft reset mask 2026-01-23 9:44 ` Jonathan Cameron @ 2026-01-23 10:08 ` Miclaus, Antoniu 2026-01-23 11:06 ` andriy.shevchenko 0 siblings, 1 reply; 8+ messages in thread From: Miclaus, Antoniu @ 2026-01-23 10:08 UTC (permalink / raw) To: Jonathan Cameron, Andy Shevchenko Cc: SeungJu Cheon, lars@metafoo.de, andriy.shevchenko@intel.com, David Lechner, andy@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Hennerich, Michael, Sa, Nuno > -----Original Message----- > From: Jonathan Cameron <jic23@kernel.org> > Sent: Friday, January 23, 2026 11:44 AM > To: Andy Shevchenko <andy.shevchenko@gmail.com>; Hennerich, Michael > <Michael.Hennerich@analog.com>; Sa, Nuno <Nuno.Sa@analog.com> > Cc: SeungJu Cheon <suunj1331@gmail.com>; Miclaus, Antoniu > <Antoniu.Miclaus@analog.com>; lars@metafoo.de; > andriy.shevchenko@intel.com; David Lechner <dlechner@baylibre.com>; > andy@kernel.org; linux-iio@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2] iio:frequency:adf4377: Fix duplicated soft reset mask > > [External] > > On Sun, 11 Jan 2026 12:09:25 +0000 > Jonathan Cameron <jic23@kernel.org> wrote: > > > On Wed, 31 Dec 2025 13:19:46 +0200 > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > > On Tue, Dec 30, 2025 at 3:21 PM SeungJu Cheon > <suunj1331@gmail.com> wrote: > > > > > > > > The regmap_read_poll_timeout() uses > ADF4377_0000_SOFT_RESET_R_MSK > > > > twice instead of checking both SOFT_RESET_MSK (bit 0) and > > > > SOFT_RESET_R_MSK (bit 7). This causes incomplete reset status check. > > > > > > an incomplete > > > > > > > Fix by using both masks as done in regmap_update_bits() above. > > > > > > ... > > > > > > > > > May I ask how you tested this? Logically from the code it sounds > > > correct, but I haven't read the datasheet yet, so I can't tell if this > > > is the expected value to read or not. > > > > > > > > > > return regmap_read_poll_timeout(st->regmap, 0x0, read_val, > > > > - !(read_val & (ADF4377_0000_SOFT_RESET_R_MSK > | > > > > + !(read_val & (ADF4377_0000_SOFT_RESET_MSK | > > > > ADF4377_0000_SOFT_RESET_R_MSK)), 200, 200 * > 100); > > > > > > Okay, I opened the datasheet, and the below is what I read there. The > > > code first sets the SOFT_RESET_R and SOFT_RESET bits to "1", and waits > > > for them to be cleared. But the Table 43 does not mention that > > > SOFT_RESET_R is auto cleaned, and actually I don't see with a brief > > > look what the "repeat of" term means. > > > > > > And for normal operation they needs to be 0ed as per: > > > "SOFT_RESET, SOFT_RESET_R, RST_SYS, and ADC_ST_CNV are the only > > > remaining RW bit fields not mentioned yet, and must also be set to > > > their POR state (see Table 34)." > > > > > > With that said, I would wait for AD people to clarify the programming > > > workflow here. > > > > > > > Small kernel development process thing as well. Please don't send a v2 in > reply to a v1. > > It can become very confusing if we end up with a larger number of versions. > > Much better to just post a new thread for each version, and include > > a link back to the lore archive of the previous version in your cover letter. > > > > Also from a practical point of view, it ends up pages up in people's inboxes > and > > so is is less likely to get reviewed! > > > > Thanks > > > > Jonathan > > > ADI folk. This is waiting for one of you to take a look at the questions Andy > raised. Yep, it's a straightforward copy-paste typo - SOFT_RESET_R_MSK is OR'd with itself, so we're only checking BIT(7). Since we set both bits before polling, we should be waiting for both to clear. Regards, Antoniu > Thanks! > > Jonathan ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2] iio:frequency:adf4377: Fix duplicated soft reset mask 2026-01-23 10:08 ` Miclaus, Antoniu @ 2026-01-23 11:06 ` andriy.shevchenko 0 siblings, 0 replies; 8+ messages in thread From: andriy.shevchenko @ 2026-01-23 11:06 UTC (permalink / raw) To: Miclaus, Antoniu Cc: Jonathan Cameron, Andy Shevchenko, SeungJu Cheon, lars@metafoo.de, David Lechner, andy@kernel.org, linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Hennerich, Michael, Sa, Nuno On Fri, Jan 23, 2026 at 10:08:54AM +0000, Miclaus, Antoniu wrote: > > From: Jonathan Cameron <jic23@kernel.org> > > Sent: Friday, January 23, 2026 11:44 AM > > On Sun, 11 Jan 2026 12:09:25 +0000 > > Jonathan Cameron <jic23@kernel.org> wrote: > > > On Wed, 31 Dec 2025 13:19:46 +0200 > > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > On Tue, Dec 30, 2025 at 3:21 PM SeungJu Cheon > > <suunj1331@gmail.com> wrote: ... > > > > May I ask how you tested this? Logically from the code it sounds > > > > correct, but I haven't read the datasheet yet, so I can't tell if this > > > > is the expected value to read or not. > > > > > > > > > > > > > return regmap_read_poll_timeout(st->regmap, 0x0, read_val, > > > > > - !(read_val & (ADF4377_0000_SOFT_RESET_R_MSK > > | > > > > > + !(read_val & (ADF4377_0000_SOFT_RESET_MSK | > > > > > ADF4377_0000_SOFT_RESET_R_MSK)), 200, 200 * > > 100); > > > > > > > > Okay, I opened the datasheet, and the below is what I read there. The > > > > code first sets the SOFT_RESET_R and SOFT_RESET bits to "1", and waits > > > > for them to be cleared. But the Table 43 does not mention that > > > > SOFT_RESET_R is auto cleaned, and actually I don't see with a brief > > > > look what the "repeat of" term means. > > > > > > > > And for normal operation they needs to be 0ed as per: > > > > "SOFT_RESET, SOFT_RESET_R, RST_SYS, and ADC_ST_CNV are the only > > > > remaining RW bit fields not mentioned yet, and must also be set to > > > > their POR state (see Table 34)." > > > > > > > > With that said, I would wait for AD people to clarify the programming > > > > workflow here. > > > > > > Small kernel development process thing as well. Please don't send a v2 in > > reply to a v1. > > > It can become very confusing if we end up with a larger number of versions. > > > Much better to just post a new thread for each version, and include > > > a link back to the lore archive of the previous version in your cover letter. > > > > > > Also from a practical point of view, it ends up pages up in people's inboxes > > and > > > so is is less likely to get reviewed! > > > > > ADI folk. This is waiting for one of you to take a look at the questions Andy > > raised. > > Yep, it's a straightforward copy-paste typo - SOFT_RESET_R_MSK is OR'd with > itself, so we're only checking BIT(7). Since we set both bits before polling, > we should be waiting for both to clear. Can you clarify more on this, please? Datasheet is unclear about the second bit to be self-cleared. And are you going to fix documentation (Datasheet)? -- With Best Regards, Andy Shevchenko ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2026-01-23 11:06 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-12-30 12:36 [PATCH] iio:frequency:adf4377: Fix duplicated soft reset mask SeungJu Cheon 2025-12-30 12:57 ` Andy Shevchenko 2025-12-30 13:21 ` [PATCH v2] " SeungJu Cheon 2025-12-31 11:19 ` Andy Shevchenko 2026-01-11 12:09 ` Jonathan Cameron 2026-01-23 9:44 ` Jonathan Cameron 2026-01-23 10:08 ` Miclaus, Antoniu 2026-01-23 11:06 ` andriy.shevchenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox