linux-kernel - Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend

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: <313BDBD2-DBF1-44A7-B021-92F1CAC0BC67@goldelico.com>
Date:   Sat, 9 May 2020 13:47:12 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Andreas Kemnade <andreas@...nade.info>,
        Evgeniy Polyakov <zbr@...emap.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-omap <linux-omap@...r.kernel.org>,
        Adam Ford <aford173@...il.com>,
        "Andrew F . Davis" <afd@...com>, Vignesh R <vigneshr@...com>
Subject: Re: [PATCHv3] w1: omap-hdq: Simplify driver with PM runtime autosuspend

Hi Tony,

> Am 29.04.2020 um 23:38 schrieb Tony Lindgren <tony@...mide.com>:
> 
> * H. Nikolaus Schaller <hns@...delico.com> [200429 21:35]:
>> I have reworked the way the spinlocks, setting and resetting
>> of the hdq_irqstatus bits are done and now it works right from
>> start of boot. Without any timeouts or delays.
>> 
>> I am not exactly sure what went wrong, but it seems as if
>> the read is already done when the write interrupt status
>> bit is processed. Then, the old logic did wipe out both
>> bits by hdq_reset_irqstatus() and the read code did timeout
>> because it did not notice that the data had already been
>> available. This may depend on other system activities so
>> that it can explain why other tests didn't reveal it.
>> 
>> omap_hdq_runtime_resume() and omap_hdq_runtime_suspend()
>> also behave fine.
>> 
>> Before I can post something I need to clean up my hacks
>> and add similar fixes to omap_hdq_break() and omap_w1_triplet()
>> where I hope that I don't break those...
> 
> OK good to hear you were able to figure out what is
> going on here.

I have found another small bug and a dev_dbg format weakness
and now it seems to work well even if I remove or reinsert the
battery while read operations are ongoing.

Still I need more time to fix up the patch(es).

BR and thanks,
Nikolaus