linux-kernel - Re: [PATCH 3/4] w1: omap-hdq: fix interrupt handling which did show spurious timeouts

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200527164633.GJ37466@atomide.com>
Date:   Wed, 27 May 2020 09:46:33 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Evgeniy Polyakov <zbr@...emap.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        YueHaibing <yuehaibing@...wei.com>, linux-kernel@...r.kernel.org,
        kernel@...a-handheld.com, letux-kernel@...nphoenux.org,
        linux-omap@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 3/4] w1: omap-hdq: fix interrupt handling which did show
 spurious timeouts

* H. Nikolaus Schaller <hns@...delico.com> [200523 17:34]:
> Since
> 
> commit 27d13da8782a ("w1: omap-hdq: Simplify driver with PM runtime autosuspend")
> 
> was applied,
> 
> I did see timeouts and wrong values when reading a bq27000 connected
> to hdq of the omap3. This occurred mainly after boot but remained and
> only sometimes settled down after several reads.
> 
> root@...ux:~# time cat /sys/class/power_supply/bq27000-battery/uevent
> POWER_SUPPLY_NAME=bq27000-battery
> POWER_SUPPLY_STATUS=Discharging
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_VOLTAGE_NOW=0
> POWER_SUPPLY_CURRENT_NOW=0
> POWER_SUPPLY_CAPACITY=0
> POWER_SUPPLY_CAPACITY_LEVEL=Normal
> POWER_SUPPLY_TEMP=-2731
> POWER_SUPPLY_TIME_TO_EMPTY_NOW=0
> POWER_SUPPLY_TIME_TO_EMPTY_AVG=0
> POWER_SUPPLY_TIME_TO_FULL_NOW=0
> POWER_SUPPLY_TECHNOLOGY=Li-ion
> POWER_SUPPLY_CHARGE_FULL=0
> POWER_SUPPLY_CHARGE_NOW=0
> POWER_SUPPLY_CHARGE_FULL_DESIGN=0
> POWER_SUPPLY_CYCLE_COUNT=0
> POWER_SUPPLY_ENERGY_NOW=0
> POWER_SUPPLY_POWER_AVG=0
> POWER_SUPPLY_HEALTH=Good
> POWER_SUPPLY_MANUFACTURER=Texas Instruments
> 
> real    0m15.761s
> user    0m0.001s
> sys     0m0.025s
> root@...ux:~#
> 
> Sometimes the effect did disappear after accessing
> the device multiple times, speed went up and results
> became correct.
> 
> All this indicates that some interrupts from the hdq
> controller are lost by the driver.
> 
> Enabling debugging revealed that there were spurious tx
> and rx timeouts, i.e. the driver does not always recognise
> interrupts. The main problem is that rx and tx interrupts
> share a single variable which was sometimes reset to
> 0 wiping out other interrupts. And it was overwritten
> by a second interrupt, independent of whether the
> previous interrupt was already processed or not.
> 
> This patch improves interrupt handling to avoid such
> races and loss of interrupt flags.

Good to hear you got it figured out :) Looks OK to me:

Acked-by: Tony Lindgren <tony@...mide.com>