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: <20200422120418.49a40c75@aktux>
Date:   Wed, 22 Apr 2020 12:04:18 +0200
From:   Andreas Kemnade <andreas@...nade.info>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Tony Lindgren <tony@...mide.com>,
        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

On Tue, 21 Apr 2020 22:40:39 +0200
"H. Nikolaus Schaller" <hns@...delico.com> wrote:

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

What about reading battery with just omap_hdq loaded and then continue
booting as usual, e.g. something like:

have script init-bat.sh
#!/bin/sh
modprobe omap_hdq
cat /sys/class/power_supply/bq27000_battery/uevent
exec /sbin/init "$@"

and then append to kernel parameters init=/init-bat.sh

Regards,
Andreas