linux-kernel - Re: [PATCH 1/2] regmap: add regmap_might

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]

Date:   Sat, 01 May 2021 00:10:16 +0200
From:   Michael Walle <michael@...le.cc>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>
Subject: Re: [PATCH 1/2] regmap: add regmap_might_sleep()

Am 2021-04-30 19:26, schrieb Mark Brown:
> On Fri, Apr 30, 2021 at 06:01:49PM +0200, Michael Walle wrote:
>> Am 2021-04-30 17:19, schrieb Mark Brown:
> 
>> > Whatever is creating the regmap really ought to know what device it's
>> > dealing with...
> 
>> But creating and using the regmap are two seperate things, no? 
>> Consider
>> the gpio-sl28cpld. It will just use whatever regmap the parent has 
>> created.
>> How would it know what type of regmap it is?
> 
> But that's a driver for a specific device AFAICT which looks like it's
> only got an I2C binding on the MFD so the driver knows that it's for a
> device that's on a bus that's going to sleep and doesn't need to infer
> anything?  This looks like the common case I'd expect where there's no
> variation.

You are right, at the moment this driver only has an I2C binding. But
the idea was that this IP block and driver can be reused behind any
kind of bridge; I2C, SPI or MMIO. Actually, I had the impression
that all you need to do to convert it to MMIO is to replace the
"kontron,sl28cpld" compatible with a "syscon" compatible. But it isn't
that easy. Anyway, the idea is that you don't need to change anything
in the gpio-sl28cpld driver, just change the parent. But if we can't
ask the regmap what type it is, then we'll have to modify the
gpio-sl28cpld driver and we will have to figure it out by some other
means.

>> > > It might be possible to pass this information via the
>> > > gpio_regmap_config, but this has the following drawbacks. First, that
>> > > property is redundant and both places might contratict each other. And
>> > > secondly, the driver might not even know the type of the regmap
>> > > because
>> > > it just gets an opaque pointer by querying the device tree.
> 
>> > If it's a generic GPIO driver from a code correctness point of view it's
>> > always got a risk of sleeping...
> 
>> I can't follow you here.
> 
> If users happen to end up with a map flagged as fast they can work on
> the whatever driver uses this stuff and not realise they're breaking
> other users of the same driver that end up with slow I/O.  The whole
> point of the flag in GPIO is AIUI warnings to help with that case.

Hm, but as of now, the only thing which makes the gpio-regmap driver
slow i/o is the regmap itself.

-michael