Messages in this thread | | | Date | Wed, 7 Jul 2021 00:20:45 +0000 | From | Vincent Pelletier <> | Subject | Re: [PATCH 2/3] hwmon: da9063: HWMON driver |
| |
Hello,
Thanks a lot for your reviews.
On Tue, 6 Jul 2021 10:42:01 -0700, Guenter Roeck <linux@roeck-us.net> wrote: > -EINVAL seems wrong. Maybe -EIO or -ETIMEDOUT.
On this topic, I've been hesitating to change this code to the following. Would it be acceptable ?
ret = wait_for_completion_timeout(...) if (ret == 0) warn[_once](...) ... if (adc_man & DA9063_ADC_MAN) { ret = -ETIMEDOUT; goto err_mread; }
The warn is to make it easier to debug in case of IRQ issue. The reason I'm caring is that I happen to have triggered such issue while testing this driver, as the GPIO and PLIC on the hifive-unmatched seem to disagree with each other. I debugged this and reported to linux-riscv, and I believe the issue is not in da9063-hwmon: it also affects da9063-onkey, and my GPIO-level workaround fixes both.
On a tangential topic: this chip is supposed to complete an ADC cycle in 10ms, so 1s timeout seems a lot to me. On the one hand it made the IRQ issue obvious, but on the other hand a safety factor of 100 seems enormous to me. What would be a usual/reasonable safety factor ? 10 ? 2 ?
> > + ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, > > + da9063_hwmon_irq_handler, > > + IRQF_TRIGGER_LOW | IRQF_ONESHOT, > > Is that correct ? The trigger condition is normally provided by > devicetree.
At least it is consistent with the existing and related da9063-onkey:
irq = platform_get_irq_byname(pdev, "ONKEY"); if (irq < 0) return irq;
error = devm_request_threaded_irq(&pdev->dev, irq, NULL, da9063_onkey_irq_handler, IRQF_TRIGGER_LOW | IRQF_ONESHOT, "ONKEY", onkey);
I am not familiar enough with IRQ handling to tell if IRQF_TRIGGER_LOW has an actual meaning here: in my understanding the regmap handler decides how to clear an interrupt based on regmap_irq_chip content, and this is coming from mfd/da9063-irq.c .
Are both devm_request_threaded_irq() equally wrong ?
> > + /* set trim temperature offset to value read at startup */ > > + hwmon->tjunc_offset = (signed char)hwmon->da9063->t_offset; > > Can you explain why this is read in and passed from the mfd driver > and not here ?
I cannot, at least not with something other than "this is how I found the code", which I realise is not satisfactory. I've been holding back on changes as I felt constrained by preserving the original author's name on the changes (both Author and Signed-off-by), but this split was indeed bothering me.
Regards, -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1
| |