<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/counter, branch linux-5.10.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>counter: microchip-tcb-capture: Fix undefined counter channel state on probe</title>
<updated>2025-04-10T12:30:54+00:00</updated>
<author>
<name>William Breathitt Gray</name>
<email>wbg@kernel.org</email>
</author>
<published>2025-03-05T10:01:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3b9b1cc8958edfca834fc4e32932cf7b8fe15ba2'/>
<id>3b9b1cc8958edfca834fc4e32932cf7b8fe15ba2</id>
<content type='text'>
commit c0c9c73434666dc99ee156b25e7e722150bee001 upstream.

Hardware initialize of the timer counter channel does not occur on probe
thus leaving the Count in an undefined state until the first
function_write() callback is executed. Fix this by performing the proper
hardware initialization during probe.

Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Reported-by: Csókás Bence &lt;csokas.bence@prolan.hu&gt;
Closes: https://lore.kernel.org/all/bfa70e78-3cc3-4295-820b-3925c26135cb@prolan.hu/
Link: https://lore.kernel.org/r/20250305-preset-capture-mode-microchip-tcb-capture-v1-1-632c95c6421e@kernel.org
Signed-off-by: William Breathitt Gray &lt;wbg@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c0c9c73434666dc99ee156b25e7e722150bee001 upstream.

Hardware initialize of the timer counter channel does not occur on probe
thus leaving the Count in an undefined state until the first
function_write() callback is executed. Fix this by performing the proper
hardware initialization during probe.

Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Reported-by: Csókás Bence &lt;csokas.bence@prolan.hu&gt;
Closes: https://lore.kernel.org/all/bfa70e78-3cc3-4295-820b-3925c26135cb@prolan.hu/
Link: https://lore.kernel.org/r/20250305-preset-capture-mode-microchip-tcb-capture-v1-1-632c95c6421e@kernel.org
Signed-off-by: William Breathitt Gray &lt;wbg@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: stm32-lptimer-cnt: fix error handling when enabling</title>
<updated>2025-04-10T12:30:54+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@foss.st.com</email>
</author>
<published>2025-02-24T17:06:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6555a92688e4092019bc7d73774ac18ce8e72c0c'/>
<id>6555a92688e4092019bc7d73774ac18ce8e72c0c</id>
<content type='text'>
commit 8744dcd4fc7800de2eb9369410470bb2930d4c14 upstream.

In case the stm32_lptim_set_enable_state() fails to update CMP and ARR,
a timeout error is raised, by regmap_read_poll_timeout. It may happen,
when the lptimer runs on a slow clock, and the clock is gated only
few times during the polling.

Badly, when this happen, STM32_LPTIM_ENABLE in CR register has been set.
So the 'enable' state in sysfs wrongly lies on the counter being
correctly enabled, due to CR is read as one in stm32_lptim_is_enabled().

To fix both issues:
- enable the clock before writing CMP, ARR and polling ISR bits. It will
avoid the possible timeout error.
- clear the ENABLE bit in CR and disable the clock in the error path.

Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer")
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Link: https://lore.kernel.org/r/20250224170657.3368236-1-fabrice.gasnier@foss.st.com
Signed-off-by: William Breathitt Gray &lt;wbg@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8744dcd4fc7800de2eb9369410470bb2930d4c14 upstream.

In case the stm32_lptim_set_enable_state() fails to update CMP and ARR,
a timeout error is raised, by regmap_read_poll_timeout. It may happen,
when the lptimer runs on a slow clock, and the clock is gated only
few times during the polling.

Badly, when this happen, STM32_LPTIM_ENABLE in CR register has been set.
So the 'enable' state in sysfs wrongly lies on the counter being
correctly enabled, due to CR is read as one in stm32_lptim_is_enabled().

To fix both issues:
- enable the clock before writing CMP, ARR and polling ISR bits. It will
avoid the possible timeout error.
- clear the ENABLE bit in CR and disable the clock in the error path.

Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer")
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Link: https://lore.kernel.org/r/20250224170657.3368236-1-fabrice.gasnier@foss.st.com
Signed-off-by: William Breathitt Gray &lt;wbg@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: ti-eqep: enable clock at probe</title>
<updated>2024-07-05T07:12:51+00:00</updated>
<author>
<name>David Lechner</name>
<email>dlechner@baylibre.com</email>
</author>
<published>2024-06-21T22:22:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=78ece307f82397629be958bc46d7573b4fe3cc86'/>
<id>78ece307f82397629be958bc46d7573b4fe3cc86</id>
<content type='text'>
[ Upstream commit 0cf81c73e4c6a4861128a8f27861176ec312af4e ]

The TI eQEP clock is both a functional and interface clock. Since it is
required for the device to function, we should be enabling it at probe.

Up to now, we've just been lucky that the clock was enabled by something
else on the system already.

Fixes: f213729f6796 ("counter: new TI eQEP driver")
Reviewed-by: Judith Mendez &lt;jm@ti.com&gt;
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20240621-ti-eqep-enable-clock-v2-1-edd3421b54d4@baylibre.com
Signed-off-by: William Breathitt Gray &lt;wbg@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0cf81c73e4c6a4861128a8f27861176ec312af4e ]

The TI eQEP clock is both a functional and interface clock. Since it is
required for the device to function, we should be enabling it at probe.

Up to now, we've just been lucky that the clock was enabled by something
else on the system already.

Fixes: f213729f6796 ("counter: new TI eQEP driver")
Reviewed-by: Judith Mendez &lt;jm@ti.com&gt;
Signed-off-by: David Lechner &lt;dlechner@baylibre.com&gt;
Link: https://lore.kernel.org/r/20240621-ti-eqep-enable-clock-v2-1-edd3421b54d4@baylibre.com
Signed-off-by: William Breathitt Gray &lt;wbg@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: microchip-tcb-capture: Fix the use of internal GCLK logic</title>
<updated>2023-10-25T09:54:16+00:00</updated>
<author>
<name>Dharma Balasubiramani</name>
<email>dharma.b@microchip.com</email>
</author>
<published>2023-09-05T10:08:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7decb6515138f74840b31715111d8de025edeb93'/>
<id>7decb6515138f74840b31715111d8de025edeb93</id>
<content type='text'>
commit df8fdd01c98b99d04915c04f3a5ce73f55456b7c upstream.

As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should
be set to 0 while using the internal GCLK (TIMER_CLOCK1).

Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Signed-off-by: Dharma Balasubiramani &lt;dharma.b@microchip.com&gt;
Link: https://lore.kernel.org/r/20230905100835.315024-1-dharma.b@microchip.com
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit df8fdd01c98b99d04915c04f3a5ce73f55456b7c upstream.

As per the datasheet, the clock selection Bits 2:0 – TCCLKS[2:0] should
be set to 0 while using the internal GCLK (TIMER_CLOCK1).

Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Signed-off-by: Dharma Balasubiramani &lt;dharma.b@microchip.com&gt;
Link: https://lore.kernel.org/r/20230905100835.315024-1-dharma.b@microchip.com
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: 104-quad-8: Fix race condition between FLAG and CNTR reads</title>
<updated>2023-05-17T09:47:28+00:00</updated>
<author>
<name>William Breathitt Gray</name>
<email>william.gray@linaro.org</email>
</author>
<published>2023-03-12T23:15:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0f29d0e8fc77db0cbf08df3aafb6206b66714277'/>
<id>0f29d0e8fc77db0cbf08df3aafb6206b66714277</id>
<content type='text'>
commit 4aa3b75c74603c3374877d5fd18ad9cc3a9a62ed upstream.

The Counter (CNTR) register is 24 bits wide, but we can have an
effective 25-bit count value by setting bit 24 to the XOR of the Borrow
flag and Carry flag. The flags can be read from the FLAG register, but a
race condition exists: the Borrow flag and Carry flag are instantaneous
and could change by the time the count value is read from the CNTR
register.

Since the race condition could result in an incorrect 25-bit count
value, remove support for 25-bit count values from this driver;
hard-coded maximum count values are replaced by a LS7267_CNTR_MAX define
for consistency and clarity.

Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8")
Cc: &lt;stable@vger.kernel.org&gt; # 6.1.x
Cc: &lt;stable@vger.kernel.org&gt; # 6.2.x
Link: https://lore.kernel.org/r/20230312231554.134858-1-william.gray@linaro.org/
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4aa3b75c74603c3374877d5fd18ad9cc3a9a62ed upstream.

The Counter (CNTR) register is 24 bits wide, but we can have an
effective 25-bit count value by setting bit 24 to the XOR of the Borrow
flag and Carry flag. The flags can be read from the FLAG register, but a
race condition exists: the Borrow flag and Carry flag are instantaneous
and could change by the time the count value is read from the CNTR
register.

Since the race condition could result in an incorrect 25-bit count
value, remove support for 25-bit count values from this driver;
hard-coded maximum count values are replaced by a LS7267_CNTR_MAX define
for consistency and clarity.

Fixes: 28e5d3bb0325 ("iio: 104-quad-8: Add IIO support for the ACCES 104-QUAD-8")
Cc: &lt;stable@vger.kernel.org&gt; # 6.1.x
Cc: &lt;stable@vger.kernel.org&gt; # 6.2.x
Link: https://lore.kernel.org/r/20230312231554.134858-1-william.gray@linaro.org/
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: stm32-lptimer-cnt: fix the check on arr and cmp registers update</title>
<updated>2023-01-14T09:15:58+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@foss.st.com</email>
</author>
<published>2022-11-23T13:36:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07905a92497ca95cc419db7759d4264bfd89efcf'/>
<id>07905a92497ca95cc419db7759d4264bfd89efcf</id>
<content type='text'>
[ Upstream commit fd5ac974fc25feed084c2d1599d0dddb4e0556bc ]

The ARR (auto reload register) and CMP (compare) registers are
successively written. The status bits to check the update of these
registers are polled together with regmap_read_poll_timeout().
The condition to end the loop may become true, even if one of the register
isn't correctly updated.
So ensure both status bits are set before clearing them.

Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer")
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Link: https://lore.kernel.org/r/20221123133609.465614-1-fabrice.gasnier@foss.st.com/
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit fd5ac974fc25feed084c2d1599d0dddb4e0556bc ]

The ARR (auto reload register) and CMP (compare) registers are
successively written. The status bits to check the update of these
registers are polled together with regmap_read_poll_timeout().
The condition to end the loop may become true, even if one of the register
isn't correctly updated.
So ensure both status bits are set before clearing them.

Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer")
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Link: https://lore.kernel.org/r/20221123133609.465614-1-fabrice.gasnier@foss.st.com/
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: microchip-tcb-capture: Handle Signal1 read and Synapse</title>
<updated>2022-11-03T14:57:50+00:00</updated>
<author>
<name>William Breathitt Gray</name>
<email>william.gray@linaro.org</email>
</author>
<published>2022-10-18T12:10:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0bcd1ab3e8b3e897141e6e757a3ca00040bd49b8'/>
<id>0bcd1ab3e8b3e897141e6e757a3ca00040bd49b8</id>
<content type='text'>
commit d917a62af81b133f35f627e7936e193c842a7947 upstream.

The signal_read(), action_read(), and action_write() callbacks have been
assuming Signal0 is requested without checking. This results in requests
for Signal1 returning data for Signal0. This patch fixes these
oversights by properly checking for the Signal's id in the respective
callbacks and handling accordingly based on the particular Signal
requested. The trig_inverted member of the mchp_tc_data is removed as
superfluous.

Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Cc: stable@vger.kernel.org
Reviewed-by: Kamel Bouhara &lt;kamel.bouhara@bootlin.com&gt;
Link: https://lore.kernel.org/r/20221018121014.7368-1-william.gray@linaro.org/
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d917a62af81b133f35f627e7936e193c842a7947 upstream.

The signal_read(), action_read(), and action_write() callbacks have been
assuming Signal0 is requested without checking. This results in requests
for Signal1 returning data for Signal0. This patch fixes these
oversights by properly checking for the Signal's id in the respective
callbacks and handling accordingly based on the particular Signal
requested. The trig_inverted member of the mchp_tc_data is removed as
superfluous.

Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
Cc: stable@vger.kernel.org
Reviewed-by: Kamel Bouhara &lt;kamel.bouhara@bootlin.com&gt;
Link: https://lore.kernel.org/r/20221018121014.7368-1-william.gray@linaro.org/
Signed-off-by: William Breathitt Gray &lt;william.gray@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: stm32-lptimer-cnt: remove iio counter abi</title>
<updated>2022-01-27T09:54:08+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@foss.st.com</email>
</author>
<published>2021-01-29T13:22:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=24b047d72c77fdb73821f3dfcf43352663a02546'/>
<id>24b047d72c77fdb73821f3dfcf43352663a02546</id>
<content type='text'>
[ Upstream commit 01f68f067dc39df9c9d95d759ee61517eb4b0fcf ]

Currently, the STM32 LP Timer counter driver registers into both IIO and
counter subsystems, which is redundant.

Remove the IIO counter ABI and IIO registration from the STM32 LP Timer
counter driver since it's been superseded by the Counter subsystem
as discussed in [1].

Keep only the counter subsystem related part.
Move a part of the ABI documentation into a driver comment.

This also removes a duplicate ABI warning
$ scripts/get_abi.pl validate
...
/sys/bus/iio/devices/iio:deviceX/in_count0_preset is defined 2 times:
  ./Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:100
  ./Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:0

[1] https://lkml.org/lkml/2021/1/19/347

Acked-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Link: https://lore.kernel.org/r/1611926542-2490-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 01f68f067dc39df9c9d95d759ee61517eb4b0fcf ]

Currently, the STM32 LP Timer counter driver registers into both IIO and
counter subsystems, which is redundant.

Remove the IIO counter ABI and IIO registration from the STM32 LP Timer
counter driver since it's been superseded by the Counter subsystem
as discussed in [1].

Keep only the counter subsystem related part.
Move a part of the ABI documentation into a driver comment.

This also removes a duplicate ABI warning
$ scripts/get_abi.pl validate
...
/sys/bus/iio/devices/iio:deviceX/in_count0_preset is defined 2 times:
  ./Documentation/ABI/testing/sysfs-bus-iio-timer-stm32:100
  ./Documentation/ABI/testing/sysfs-bus-iio-lptimer-stm32:0

[1] https://lkml.org/lkml/2021/1/19/347

Acked-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Link: https://lore.kernel.org/r/1611926542-2490-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: 104-quad-8: Return error when invalid mode during ceiling_write</title>
<updated>2021-09-15T07:50:38+00:00</updated>
<author>
<name>William Breathitt Gray</name>
<email>vilhelm.gray@gmail.com</email>
</author>
<published>2021-08-03T12:06:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=974ab0a04fe6d2757a4a0b027deca28f263f51bb'/>
<id>974ab0a04fe6d2757a4a0b027deca28f263f51bb</id>
<content type='text'>
[ Upstream commit 728246e8f7269ecd35a2c6e6795323e6d8f48db7 ]

The 104-QUAD-8 only has two count modes where a ceiling value makes
sense: Range Limit and Modulo-N. Outside of these two modes, setting a
ceiling value is an invalid operation -- so let's report it as such by
returning -EINVAL.

Fixes: fc069262261c ("counter: 104-quad-8: Add lock guards - generic interface")
Acked-by: Syed Nayyar Waris &lt;syednwaris@gmail.com&gt;
Signed-off-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Link: https://lore.kernel.org/r/a2147f022829b66839a1db5530a7fada47856847.1627990337.git.vilhelm.gray@gmail.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 728246e8f7269ecd35a2c6e6795323e6d8f48db7 ]

The 104-QUAD-8 only has two count modes where a ceiling value makes
sense: Range Limit and Modulo-N. Outside of these two modes, setting a
ceiling value is an invalid operation -- so let's report it as such by
returning -EINVAL.

Fixes: fc069262261c ("counter: 104-quad-8: Add lock guards - generic interface")
Acked-by: Syed Nayyar Waris &lt;syednwaris@gmail.com&gt;
Signed-off-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Link: https://lore.kernel.org/r/a2147f022829b66839a1db5530a7fada47856847.1627990337.git.vilhelm.gray@gmail.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register</title>
<updated>2021-03-25T08:04:16+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@foss.st.com</email>
</author>
<published>2021-03-03T17:49:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6d4e1fed18d04663f5f8981d4500183888e8d8f0'/>
<id>6d4e1fed18d04663f5f8981d4500183888e8d8f0</id>
<content type='text'>
commit b14d72ac731753708a7c1a6b3657b9312b6f0042 upstream.

Ceiling value may be miss-aligned with what's actually configured into the
ARR register. This is seen after probe as currently the ARR value is zero,
whereas ceiling value is set to the maximum. So:
- reading ceiling reports zero
- in case the counter gets enabled without any prior configuration,
  it won't count.
- in case the function gets set by the user 1st, (priv-&gt;ceiling) is used.

Fix it by getting rid of the cached "priv-&gt;ceiling" variable. Rather use
the ARR register value directly by using regmap read or write when needed.
There should be no drawback on performance as priv-&gt;ceiling isn't used in
performance critical path.
There's also no point in writing ARR while setting function (sms), so
it can be safely removed.

Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder")
Suggested-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Acked-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/1614793789-10346-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b14d72ac731753708a7c1a6b3657b9312b6f0042 upstream.

Ceiling value may be miss-aligned with what's actually configured into the
ARR register. This is seen after probe as currently the ARR value is zero,
whereas ceiling value is set to the maximum. So:
- reading ceiling reports zero
- in case the counter gets enabled without any prior configuration,
  it won't count.
- in case the function gets set by the user 1st, (priv-&gt;ceiling) is used.

Fix it by getting rid of the cached "priv-&gt;ceiling" variable. Rather use
the ARR register value directly by using regmap read or write when needed.
There should be no drawback on performance as priv-&gt;ceiling isn't used in
performance critical path.
There's also no point in writing ARR while setting function (sms), so
it can be safely removed.

Fixes: ad29937e206f ("counter: Add STM32 Timer quadrature encoder")
Suggested-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Acked-by: William Breathitt Gray &lt;vilhelm.gray@gmail.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/1614793789-10346-1-git-send-email-fabrice.gasnier@foss.st.com
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
