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: <20200417150721.GL37466@atomide.com>
Date:   Fri, 17 Apr 2020 08:07:21 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     "H. Nikolaus Schaller" <hns@...delico.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

* H. Nikolaus Schaller <hns@...delico.com> [200417 14:53]:
> 
> > Am 17.04.2020 um 16:43 schrieb Andreas Kemnade <andreas@...nade.info>:
> > 
> > On Fri, 17 Apr 2020 16:22:47 +0200
> > "H. Nikolaus Schaller" <hns@...delico.com> wrote:
> > 
> >>> Am 16.04.2020 um 20:46 schrieb Tony Lindgren <tony@...mide.com>:
> >>> Care to check if changing pm_runtime_set_autosuspend_delay value
> >>> to -1 in probe makes the issue go away? Or change it manually
> >>> to -1 via sysfs.
> >>> 
> >>> If that helps, likely we have a missing pm_runtime_get_sync()
> >>> somewhere in the driver.  
> >> 
> >> Yes, it does! It suffices to set it to -1 for one readout.
> >> Aything else I can test?

You could sprinkle dev_info(dev, "%s\n", __func__) to the
omap_hdq_runtime_suspend() and omap_hdq_runtime_resume()
functions.

> > How does it depend on loaded drivers?
> > Is it really mainline kernel + config + devicetree or something else?
> 
> Well, I can revert the patch on the same
> kernel (5.6 or 5.7-rc1) + config + devicetree + user-space
> and the problem is gone.
> 
> This means that something is different between the old and the new
> version which makes the hdq access delayed and failing. Of course I
> don't know the reason for it and what does influence it.
> 
> > 
> > Can you reproduce the problem with init=/bin/bash
> > and then mount sysfs and modprobe omap_hdq?
> 
> I am not sure how quickly I can test such a setup.
> 
> > Regarding pm_runtime stuff I thought I have the worst case scenario.
> 
> What may make a difference is the sequence in which drivers are loaded.

Well to me it seems that we have PM runtime handling properly
implemented for all the functions in w1_bus_master omap_w1_master,
so we should not have any consumers calling into the driver
bypassing PM runtime.

Maybe the PM runtime usecounts get unbalanced somewhere in the
driver where we end up with driver permanently in disabled state?

Regards,

Tony