| Message ID | 20211225161056.682797-1-u.kleine-koenig@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | counter: cleanups and device lifetime fixes | expand |
Hello, some sidestory to this series: While working on fixing the struct dev lifetime thing, I saw a few ugly things that I don't intend to fix myself. Here is just a mail to let you know this with a list of issues. Feel free to address or ignore: - 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. Best regards Uwe
Hello,
I just noticed I had a few dirty changes in my working copy that need to
be squashed into these commits:
diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
index 4315b14f239e..680c7ba943a4 100644
--- a/drivers/counter/104-quad-8.c
+++ b/drivers/counter/104-quad-8.c
@@ -1084,7 +1084,8 @@ static struct counter_count quad8_counts[] = {
static irqreturn_t quad8_irq_handler(int irq, void *private)
{
- struct quad8 *const priv = private;
+ struct counter_device *counter = private;
+ struct quad8 *const priv = counter_priv(counter);
const unsigned long base = priv->base;
unsigned long irq_status;
unsigned long channel;
@@ -1115,7 +1116,7 @@ static irqreturn_t quad8_irq_handler(int irq, void *private)
continue;
}
- counter_push_event(&priv->counter, event, channel);
+ counter_push_event(counter, event, channel);
}
/* Clear pending interrupts on device */
@@ -1192,7 +1193,7 @@ static int quad8_probe(struct device *dev, unsigned int id)
outb(QUAD8_CHAN_OP_ENABLE_INTERRUPT_FUNC, base[id] + QUAD8_REG_CHAN_OP);
err = devm_request_irq(dev, irq[id], quad8_irq_handler, IRQF_SHARED,
- counter->name, priv);
+ counter->name, counter);
if (err)
return err;
diff --git a/drivers/counter/ftm-quaddec.c b/drivers/counter/ftm-quaddec.c
index d73506436e58..c636183b1337 100644
--- a/drivers/counter/ftm-quaddec.c
+++ b/drivers/counter/ftm-quaddec.c
@@ -301,7 +301,7 @@ static int ftm_quaddec_probe(struct platform_device *pdev)
ret = devm_counter_add(&pdev->dev, counter);
if (ret)
- return dev_err_probe(&pdev->dev, "Failed to add counter\n");
+ return dev_err_probe(&pdev->dev, ret, "Failed to add counter\n");
return 0;
}
diff --git a/drivers/counter/interrupt-cnt.c b/drivers/counter/interrupt-cnt.c
index 3f816454220e..9e99702470c2 100644
--- a/drivers/counter/interrupt-cnt.c
+++ b/drivers/counter/interrupt-cnt.c
@@ -215,7 +215,7 @@ static int interrupt_cnt_probe(struct platform_device *pdev)
ret = devm_counter_add(dev, counter);
if (ret < 0)
- return dev_err_probe(dev, err, "Failed to add counter\n");
+ return dev_err_probe(dev, ret, "Failed to add counter\n");
return 0;
}
Will fix these in a v2.
Best regards
Uwe
On 12/25/21 1:20 PM, Uwe Kleine-König wrote: > Hello, > > some sidestory to this series: While working on fixing the struct dev > lifetime thing, I saw a few ugly things that I don't intend to fix > myself. Here is just a mail to let you know this with a list of issues. > Feel free to address or ignore: > > - 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. This last item has been brought up before. The conclusion was yes it should have been a class but it is too late to change it now since it would break userspace. (I think bus was cargo-culted from the iio subsystem.)