linux-kernel - Re: [PATCH 2/3] hwmon: da9063: HWMON driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 7 Jul 2021 00:20:45 +0000
From:   Vincent Pelletier <plr.vincent@...il.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Jean Delvare <jdelvare@...e.com>, Jonathan Corbet <corbet@....net>,
        Support Opensource <support.opensource@...semi.com>,
        Lee Jones <lee.jones@...aro.org>, linux-hwmon@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Opensource [Steve Twiss]" <stwiss.opensource@...semi.com>
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@...ck-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