linux-kernel - Re: [PATCH] hwmon: da9052: Synchronize access with mfd

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200512113128.yfg2vihkbbg3f762@earth.universe>
Date:   Tue, 12 May 2020 13:31:28 +0200
From:   Sebastian Reichel <sebastian.reichel@...labora.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Support Opensource <support.opensource@...semi.com>,
        Jean Delvare <jdelvare@...e.com>,
        Lee Jones <lee.jones@...aro.org>, linux-hwmon@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel@...labora.com,
        Samu Nuutamo <samu.nuutamo@...cit.fi>
Subject: Re: [PATCH] hwmon: da9052: Synchronize access with mfd

Hi Guenter,

On Mon, May 11, 2020 at 09:51:25AM -0700, Guenter Roeck wrote:
> On 5/11/20 4:02 AM, Sebastian Reichel wrote:
> > From: Samu Nuutamo <samu.nuutamo@...cit.fi>
> > 
> > When tsi-as-adc is configured it is possible for in7[0123]_input read to
> > return an incorrect value if a concurrent read to in[456]_input is
> > performed. This is caused by a concurrent manipulation of the mux
> > channel without proper locking as hwmon and mfd use different locks for
> > synchronization.
> > 
> > Switch hwmon to use the same lock as mfd when accessing the TSI channel.
> > 
> > Fixes: 4f16cab19a3d5 ("hwmon: da9052: Add support for TSI channel")
> > Signed-off-by: Samu Nuutamo <samu.nuutamo@...cit.fi>
> > [rebase to current master, reword commit message slightly]
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> 
> Have you explored calling da9052_adc_manual_read() instead ?
> At the very least we should have a comment explaining why that
> isn't feasible.

da9052_adc_manual_read() writes to DA9052_ADC_MAN_REG, waits for an
IRQ and then reads DA9052_ADC_RES_H_REG/DA9052_ADC_RES_L_REG. The
function called here works with the TSI registers instead. So
calling da9052_adc_manual_read() is not an option.

The reason for the locking problem is, that the same ADC is used
internally by the devices and muxed to different pins in the
background. In continuous touchscreen mode, the device is supposed
to schedule the ADC slots automatically and I assumed this would
also work here when I wrote the original support. Turns out the
device is not smart enough for that :(

-- Sebastian

> Thanks,
> Guenter
> 
> > ---
> >  drivers/hwmon/da9052-hwmon.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/hwmon/da9052-hwmon.c b/drivers/hwmon/da9052-hwmon.c
> > index 53b517dbe7e6..4af2fc309c28 100644
> > --- a/drivers/hwmon/da9052-hwmon.c
> > +++ b/drivers/hwmon/da9052-hwmon.c
> > @@ -244,9 +244,9 @@ static ssize_t da9052_tsi_show(struct device *dev,
> >  	int channel = to_sensor_dev_attr(devattr)->index;
> >  	int ret;
> >  
> > -	mutex_lock(&hwmon->hwmon_lock);
> > +	mutex_lock(&hwmon->da9052->auxadc_lock);
> >  	ret = __da9052_read_tsi(dev, channel);
> > -	mutex_unlock(&hwmon->hwmon_lock);
> > +	mutex_unlock(&hwmon->da9052->auxadc_lock);
> >  
> >  	if (ret < 0)
> >  		return ret;
> > 
> 

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)