Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Guenter Roeck <groeck7@gmail.com>
Date:   Tue, 6 Jul 2021 17:58:00 -0700
From:   Guenter Roeck <linux@roeck-us.net>
To:     Vincent Pelletier <plr.vincent@gmail.com>
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
Message-ID: <20210707005800.GA2221519@roeck-us.net>
References: <850a353432cd676f96889cede291232abf58918d.1625581991.git.plr.vincent@gmail.com>
 <dff04323fc1b0177c1c08d3670333a839af4c268.1625581991.git.plr.vincent@gmail.com>
 <20210706174201.GC943349@roeck-us.net>
 <20210707002045.571694b2@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210707002045.571694b2@gmail.com>
Precedence: bulk

On Wed, Jul 07, 2021 at 12:20:45AM +0000, Vincent Pelletier wrote:
> 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

"to debug". Then make it a debug message.

> 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 ?

Your call, really.

Guenter

> 
> > > +	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 ?
> 
No idea. My understanding is that devicetree data is used unless
an explicit method is specified. That is why I was asking _if_ this
is correct, and did not claim that it is 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.
> 
Sorry, that is not a good argument. On the contrary, if I have to assume
that the code has non-technical constraints, I am inclined to just reject
it for that very reason.

Guenter