From: Vincent Pelletier <plr.vincent@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>,
Jonathan Corbet <corbet@lwn.net>,
Support Opensource <support.opensource@diasemi.com>,
Lee Jones <lee.jones@linaro.org>,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Opensource [Steve Twiss]" <stwiss.opensource@diasemi.com>
Subject: Re: [PATCH 2/3] hwmon: da9063: HWMON driver
Date: Wed, 7 Jul 2021 00:20:45 +0000 [thread overview]
Message-ID: <20210707002045.571694b2@gmail.com> (raw)
In-Reply-To: <20210706174201.GC943349@roeck-us.net>
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
next prev parent reply other threads:[~2021-07-07 0:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-06 14:34 [PATCH 1/3] mfd: da9063: Add HWMON dependencies Vincent Pelletier
2021-07-06 14:34 ` [PATCH 2/3] hwmon: da9063: HWMON driver Vincent Pelletier
2021-07-06 17:42 ` Guenter Roeck
2021-07-07 0:20 ` Vincent Pelletier [this message]
2021-07-07 0:58 ` Guenter Roeck
2021-07-07 23:28 ` Vincent Pelletier
2021-07-06 14:34 ` [PATCH 3/3] Documentation: hwmon: New information for DA9063 Vincent Pelletier
2021-07-06 17:28 ` Guenter Roeck
2021-07-06 17:28 ` [PATCH 1/3] mfd: da9063: Add HWMON dependencies Guenter Roeck
-- strict thread matches above, loose matches on Subject: below --
2021-07-06 0:01 Vincent Pelletier
2021-07-06 0:01 ` [PATCH 2/3] hwmon: da9063: HWMON driver Vincent Pelletier
2021-07-06 0:28 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210707002045.571694b2@gmail.com \
--to=plr.vincent@gmail.com \
--cc=corbet@lwn.net \
--cc=jdelvare@suse.com \
--cc=lee.jones@linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=stwiss.opensource@diasemi.com \
--cc=support.opensource@diasemi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).