[v2,00/23] counter: cleanups and device lifetime fixes

Commit Message

Uwe Kleine-König Dec. 27, 2021, 9:45 a.m. UTC

Hello,

this is v2 of this series, it's goal is to fix struct device lifetime issues as
pointed out in patch #13. The patches up to patch #12 are only prepatory and
cleanup patches. Patch #13 provides the needed functions to fix the issues in
all drivers (patches #15 to #22). The last patch removes the then unused API
calls.

The changes compared to v1 is only build fixes that I missed to include in v1,
they were only in my working copy. Additionally I changed:


The stm32-timer-cnt driver was used to test
this series, the other drivers are only compile tested.


To complete the information from the v1 thread: There are a few more
issues I found while working on this patch set:

 - 104_QUAD_8 depends on X86, but compiles fine on ARCH=arm. Maybe
   adding support for COMPILE_TEST would be a good idea.

 - 104-quad-8.c uses devm_request_irq() and (now) devm_counter_add(). On
   unbind an irq might be pending which results in quad8_irq_handler()
   calling counter_push_event() for a counter that is already
   unregistered. (The issue exists also without my changes.)

 - I think intel-qep.c makes the counter unfunctional in
   intel_qep_remove before the counter is unregistered.

 - I wonder why counter is a bus and not a class device type. There is
   no driver that would ever bind a counter device, is there? So
   /sys/bus/counter/driver is always empty.

Do whatever you want with this list, I won't address these in the near
future.

Uwe Kleine-König (23):
  counter: Use container_of instead of drvdata to track counter_device
  counter: ftm-quaddec: Drop unused platform_set_drvdata()
  counter: microchip-tcb-capture: Drop unused platform_set_drvdata()
  counter: Provide a wrapper to access device private data
  counter: 104-quad-8: Convert to counter_priv() wrapper
  counter: interrupt-cnt: Convert to counter_priv() wrapper
  counter: microchip-tcb-capture: Convert to counter_priv() wrapper
  counter: intel-qep: Convert to counter_priv() wrapper
  counter: ftm-quaddec: Convert to counter_priv() wrapper
  counter: ti-eqep: Convert to counter_priv() wrapper
  counter: stm32-lptimer-cnt: Convert to counter_priv() wrapper
  counter: stm32-timer-cnt: Convert to counter_priv() wrapper
  counter: Provide alternative counter registration functions
  counter: Update documentation for new counter registration functions
  counter: 104-quad-8: Convert to new counter registration
  counter: interrupt-cnt: Convert to new counter registration
  counter: intel-qep: Convert to new counter registration
  counter: ftm-quaddec: Convert to new counter registration
  counter: microchip-tcb-capture: Convert to new counter registration
  counter: stm32-timer-cnt: Convert to new counter registration
  counter: stm32-lptimer-cnt: Convert to new counter registration
  counter: ti-eqep: Convert to new counter registration
  counter: remove old and now unused registration API

 Documentation/driver-api/generic-counter.rst |  10 +-
 drivers/counter/104-quad-8.c                 |  93 +++++-----
 drivers/counter/counter-core.c               | 168 +++++++++++++------
 drivers/counter/ftm-quaddec.c                |  37 ++--
 drivers/counter/intel-qep.c                  |  46 ++---
 drivers/counter/interrupt-cnt.c              |  38 +++--
 drivers/counter/microchip-tcb-capture.c      |  44 ++---
 drivers/counter/stm32-lptimer-cnt.c          |  51 +++---
 drivers/counter/stm32-timer-cnt.c            |  48 +++---
 drivers/counter/ti-eqep.c                    |  47 +++---
 include/linux/counter.h                      |  15 +-
 11 files changed, 348 insertions(+), 249 deletions(-)


base-commit: a7904a538933c525096ca2ccde1e60d0ee62c08e

Comments

Lars-Peter Clausen Dec. 27, 2021, 12:25 p.m. UTC | #1

On 12/27/21 10:45 AM, Uwe Kleine-König wrote:
> [...]
>
>   - I wonder why counter is a bus and not a class device type. There is
>     no driver that would ever bind a counter device, is there? So
>     /sys/bus/counter/driver is always empty.
>
There used to be a time when GKH said that we do not want new driver 
classes. And all new subsystems should use bus since bus is a superset 
of class. This restriction has been eased since then.

But it was around when the IIO subsystem was merged and since the 
counter subsystem originated from the IIO subsystem I assume it just 
copied this.

Jonathan Cameron Dec. 28, 2021, 5:35 p.m. UTC | #2

On Mon, 27 Dec 2021 13:25:25 +0100
Lars-Peter Clausen <[e-mail]> wrote:

> On 12/27/21 10:45 AM, Uwe Kleine-König wrote:
> > [...]
> >
> >   - I wonder why counter is a bus and not a class device type. There is
> >     no driver that would ever bind a counter device, is there? So
> >     /sys/bus/counter/driver is always empty.
> >  
> There used to be a time when GKH said that we do not want new driver 
> classes. And all new subsystems should use bus since bus is a superset 
> of class. This restriction has been eased since then.
> 
> But it was around when the IIO subsystem was merged and since the 
> counter subsystem originated from the IIO subsystem I assume it just 
> copied this.
> 

Yup. Discussion about this back then with one view being there
should never have been class in the first place.

https://lore.kernel.org/lkml/[e-mail]/

For anyone who loves the history of these things...

FWIW I think Greg suggested IIO should be a bus because we were hanging
a bunch of different types of device off a class and it was getting messy.
Kay then gave some history on class vs bus and suggested no new
subsystem should use class.

Ah well, opinions change over time!

Also interesting to see we were discussing a bridge to input all that
time ago and it's still not gone beyond various prototypes (with
exception of touch screens).

Jonathan

William Breathitt Gray Dec. 29, 2021, 8:49 a.m. UTC | #3

On Tue, Dec 28, 2021 at 05:35:58PM +0000, Jonathan Cameron wrote:
> On Mon, 27 Dec 2021 13:25:25 +0100
> Lars-Peter Clausen <[e-mail]> wrote:
> 
> > On 12/27/21 10:45 AM, Uwe Kleine-König wrote:
> > > [...]
> > >
> > >   - I wonder why counter is a bus and not a class device type. There is
> > >     no driver that would ever bind a counter device, is there? So
> > >     /sys/bus/counter/driver is always empty.
> > >  
> > There used to be a time when GKH said that we do not want new driver 
> > classes. And all new subsystems should use bus since bus is a superset 
> > of class. This restriction has been eased since then.
> > 
> > But it was around when the IIO subsystem was merged and since the 
> > counter subsystem originated from the IIO subsystem I assume it just 
> > copied this.
> > 
> 
> Yup. Discussion about this back then with one view being there
> should never have been class in the first place.
> 
> https://lore.kernel.org/lkml/[e-mail]/
> 
> For anyone who loves the history of these things...
> 
> FWIW I think Greg suggested IIO should be a bus because we were hanging
> a bunch of different types of device off a class and it was getting messy.
> Kay then gave some history on class vs bus and suggested no new
> subsystem should use class.
> 
> Ah well, opinions change over time!
> 
> Also interesting to see we were discussing a bridge to input all that
> time ago and it's still not gone beyond various prototypes (with
> exception of touch screens).
> 
> Jonathan

Yes this is the reason: Counter subsystem just followed the structure of
the IIO subsystem originally which is how it ended up as a bus; changing
it to a class now would break userspace expectations so that is why it
remains a bus still.

William Breathitt Gray

Patch

diff --git a/drivers/counter/counter-core.c b/drivers/counter/counter-core.c
index cdc6004a7e77..3f7dc5718423 100644
--- a/drivers/counter/counter-core.c
+++ b/drivers/counter/counter-core.c
@@ -27,7 +27,7 @@  static DEFINE_IDA(counter_ida);
 
 struct counter_device_allochelper {
 	struct counter_device counter;
-	unsigned long privdata[0];
+	unsigned long privdata[];
 };
 
 static void counter_device_release(struct device *dev)