linux-kernel - Re: [PATCH v2 1/3] gpio: regmap: Support few IC specific operations

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:   Fri, 21 May 2021 11:41:41 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "michael@...le.cc" <michael@...le.cc>
CC:     linux-power <linux-power@...rohmeurope.com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>
Subject: Re: [PATCH v2 1/3] gpio: regmap: Support few IC specific operations


On Fri, 2021-05-21 at 14:19 +0300, Andy Shevchenko wrote:
> On Fri, May 21, 2021 at 1:19 PM Michael Walle <michael@...le.cc>
> wrote:
> > Am 2021-05-21 12:09, schrieb Andy Shevchenko:
> > > On Fri, May 21, 2021 at 12:53 PM Matti Vaittinen
> > > <matti.vaittinen@...rohmeurope.com> wrote:
> > > > Changelog v2: (based on suggestions by Michael Walle)
> > > >   - drop gpio_regmap_set_drvdata()
> > > 
> > > But why do we have gpio_regmap_get_drvdata() and why is it
> > > different
> > > now to the new member handling?
> > 
> > Eg. the reg_mask_xlate() callback is just passed a "struct
> > gpio_regmap*".
> > If someone needs to access private data there,
> > gpio_regmap_get_drvdata()
> > is used. At least that was its intention.
> > 
> > Thus I was also suggesting to use "struct gpio_regmap*" in the
> > newer
> > callbacks.
> > 
> > I don't get what you mean by "different to the new member
> > handling"?
> 
> Currently we have a symmetrical API that is getter and setter against
> a certain field.
> Now this change drops the setter and introduces some other field
> somewhere else.
> Sounds to me:
>  - either this has to be split into two changes with explanation of
> what's going on
>  - or something odd is happening here which I do not understand.
> 
The rationale beind placing the drvdata pointer / setting in the config
struct is avoiding races in case the drvdata is needed by operations
called during the gpio_chip registration. (If the drvdata is needed for
example at the set_config() or init_valid_mask()). Providing the
drvdata only after we get the gpio_regmap from registration is too
late.

It's actually hard to see am use-case for drvdata where providing it
after gpio registration would not be racy.

Getting the drvdata does not have similar race condition as setting it.
Thus the API for getting it is Ok.

Best Regards
	Matti Vaittinen