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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a964442-80ca-f69a-f1ad-9296cc8f6839@linumiz.com>
Date:   Wed, 11 Oct 2023 12:02:44 +0530
From:   Saravanan Sekar <saravanan@...umiz.com>
To:     Guenter Roeck <linux@...ck-us.net>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     sravanhome@...il.com, lgirdwood@...il.com, broonie@...nel.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        conor+dt@...nel.org, jdelvare@...e.com,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-hwmon@...r.kernel.org
Subject: Re: [PATCH v3 2/3] regulator: dt-bindings: Add mps,mpq2286
 power-management IC

On 08/10/23 19:22, Guenter Roeck wrote:
> On Sun, Oct 08, 2023 at 12:40:29PM +0200, Krzysztof Kozlowski wrote:
>> On 08/10/2023 03:20, Guenter Roeck wrote:
>>> On Sat, Oct 07, 2023 at 10:28:02PM +0530, Saravanan Sekar wrote:
>>>> Document mpq2286 power-management IC. Instead of simple 'buck', 'buck0' is
>>>> used to keep the driver common which handles multiple regulators.
>>>
>>> Sorry for the maybe dumb question, but where can I find the driver
>>> depencency on buck naming ?
>>
>> I guess it is because:
>> PMBUS_REGULATOR_STEP("buck", 0, MPQ7932_N_VOLTAGES,
>> creates regulator name as buck+id (so buck0).
>>
> 
> Ah, good point. Problem here is that this is already kind of common,
> even though the use of "buckX" isn't. Look for "vout0", or
> 'PMBUS_REGULATOR("vout", 0)'. Apparently so far no one took offence
> if a regulator was named "vout0" even if "vout1" didn't exist.
> 
> I don't really have a good solution right now, but I guess we'll need
> a second set of macros for the single-regulator case, or maybe generate
> struct regulator_desc arrays using a function. I'll have to explore
> options.
> 
> Please let me know how you want the subsystem to handle existing
> single-channel regulators with numbered regulator name.
> 
> Saravanan - for this driver please just declare a local driver-specific
> variant of the PMBUS_REGULATOR_STEP() macro which doesn't use indexing,
> use it to initialise a second regulators_desc array, and use that second
> array for mpq2286. That is a bit messy, but acceptable for now until
> there is a more generic solution (unless of course you have an idea for
> one and want to implement it, but that is not a requirement).
Hello Guenter,

Thanks for your proposal as intermediate fix local declaration of macro, 
could you please suggest whether below changes is acceptable as workaround?

+++ b/drivers/hwmon/pmbus/mpq7932.c
@@ -118,6 +118,12 @@ static int mpq7932_probe(struct i2c_client *client)
  #if IS_ENABLED(CONFIG_SENSORS_MPQ7932_REGULATOR)
         info->num_regulators = info->pages;
         info->reg_desc = mpq7932_regulators_desc;
+
+       if (info->num_regulators == 1) {
+               mpq7932_regulators_desc->name = "buck";
+               mpq7932_regulators_desc->of_match = of_match_ptr("buck");
+       }
+


> 
> Thanks,
> Guenter

Thanks,
Saravanan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ