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: <D3E40A6A-39B8-4F3F-9ABC-28EAE8D623A6@goldelico.com>
Date:   Tue, 21 Apr 2020 22:40:39 +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 21.04.2020 um 20:20 schrieb Tony Lindgren <tony@...mide.com>:
> 
>> Well, what helps is reverting the patch and using the old driver
>> (which did work for several years). So I would not assume that
>> there is a hardware influence. It seems to be something the new
>> driver is doing differently.
> 
> Well earlier hdq1w.c did not idle, now it does.

Ah, I see!

> If you just want to keep it enabled like earlier, you can just add something like:

Well, I don't want it enabled, it just should work as before.
Ideally including all improvements :)

> 
> &hdqw1w {
> 	ti,no-idle;
> };

I have added that and there might be a slightly different pattern
(unless that is just by luck): the first two or three attempts to
read the bq27xx/uevent did still time out. But then the next ones
worked fine (with a response time of ca. 65 .. 230 ms).

So as if something needs to be shaken into the right position after
boot until it works.

Interestingly, after reinstalling the version without ti,no-idle;
it did work well on the first boot but not afterwards. Like there
is some memory surviving powerdown and battery removal... But again,
it started to work after 6 or 7 failed attempts.

If only it weren't so time-consuming to perform such tests...

>> I need more time to understand and trace this issue on what it
>> depends... It may depend on the sequence some other modules are
>> loaded and what the user-space (udevd) is doing in the meantime.
> 
> Yes would be good to understand what goes wrong here before we
> apply the ti,no-idle as that will block SoC deeper idle states.
> 
> Regards,
> 
> Tony

BR and thanks,
Nikolaus