linux-kernel - RE: [PATCH RESEND 0/2] Solve data access delay of ST sensors

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

Message-ID: <AM6PR06MB5158D9EF6708A89D48AE6D43A0309@AM6PR06MB5158.eurprd06.prod.outlook.com>
Date:   Fri, 11 Feb 2022 15:14:24 +0000
From:   TOSCANELLI Massimo <massimo.toscanelli@...ca-geosystems.com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jic23@...nel.org" <jic23@...nel.org>,
        "lars@...afoo.de" <lars@...afoo.de>,
        "caihuoqing@...du.com" <caihuoqing@...du.com>,
        "aardelean@...iqon.com" <aardelean@...iqon.com>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "hdegoede@...hat.com" <hdegoede@...hat.com>,
        LI Qingwu <qing-wu.li@...ca-geosystems.com.cn>,
        "stephan@...hold.net" <stephan@...hold.net>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        GEO-CHHER-bsp-development 
        <bsp-development.geo@...ca-geosystems.com>
Subject: RE: [PATCH RESEND 0/2] Solve data access delay of ST sensors

Hello Linus and Jonathan

> -----Original Message-----
> From: Linus Walleij <linus.walleij@...aro.org>
> Sent: 11 February 2022 02:12
> To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> Cc: TOSCANELLI Massimo <massimo.toscanelli@...ca-geosystems.com>;
> linux-kernel@...r.kernel.org; jic23@...nel.org; lars@...afoo.de;
> caihuoqing@...du.com; aardelean@...iqon.com;
> andy.shevchenko@...il.com; hdegoede@...hat.com; LI Qingwu <qing-
> wu.li@...ca-geosystems.com.cn>; stephan@...hold.net; linux-
> iio@...r.kernel.org; GEO-CHHER-bsp-development <bsp-
> development.geo@...ca-geosystems.com>
> Subject: Re: [PATCH RESEND 0/2] Solve data access delay of ST sensors
> 
> 
> On Mon, Feb 7, 2022 at 2:59 PM Jonathan Cameron
> <Jonathan.Cameron@...wei.com> wrote:
> > On Mon,  7 Feb 2022 09:04:41 +0000
> > Massimo Toscanelli <massimo.toscanelli@...ca-geosystems.com> wrote:
> 
> > The standard approach to avoiding rapid power up and power down cycles
> > is to use runtime_pm with autosuspend and a period set at a period of
> > perhaps 1 second.  Would that work for you?  You'll pay the costs of
> > power up only on the first read after a period of not reading.
> >
> > Exposing the control to userspace for this sort of thing is normally a
> > bad idea because userspace generally has no idea if it should use it
> > as there is no clean way of telling userspace the costs of not using
> > it (as those will be device specific).
> >
> > If you have a usecase that requires regular reading you should also
> > think about whether using the buffered interface is more appropriate.
> > IIRC that will keep these devices powered up continuously whilst the
> > buffer is enabled and will provide a lower overhead way of reading
> > data than sysfs reads.
> 
> I see that I have repeted similar comments.
> 
Thanks a lot for your suggestions, I decided to go for the second solution proposed by Jonathan.
Using the buffered interface should be enough, you can discard the patches.

Massimo