linux-kernel - Re: [PATCH 4/4] regulator: core: make bulk API support optional supplies

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:   Mon, 6 Feb 2017 16:21:18 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org,
        Bjorn Andersson <bjorn.andersson@...ymobile.com>
Subject: Re: [PATCH 4/4] regulator: core: make bulk API support optional
 supplies

On Fri 03 Feb 15:16 PST 2017, Dmitry Torokhov wrote:

> Make it possible to use the bulk API with optional supplies, by allowing
> the consumer to marking supplies as optional in the regulator_bulk_data.
> 
> Based on earlier patch by Bjorn Andersson <bjorn.andersson@...ymobile.com>
> 

Hi Dmitry,

Rather than fixing my broken patch, I reverted it after talking to Mark.
This as I realized that I got things backwards.

When a given component has an "optional" supply this can mean two
things:
1) The component has a supply pin that is connected, but the kernel has
no information about what it's connected to (in essence a "broken" DT).
In this case regulator_get() will return a dummy regulator.

2) The component has a supply pin that might or not might be connected
and depending on this the component needs to be configured differently.
In this case you use regulator_get_optional() which will return an error
in the event that no supply is specified.

With this in mind, supporting optional supplies in the bulk operations
makes less sense. (And after further review my case was a clear #1)

Regards,
Bjorn