linux-kernel - Re: [PATCH 1/3] regulator: Add uapi header

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]

Message-ID: <CABqG17hrfLMynD0OKurfR2694ak0LN0pnpK82DOPqDAW-rhO0A@mail.gmail.com>
Date:   Fri, 1 Sep 2023 00:04:13 +0530
From:   Naresh Solanki <naresh.solanki@...ements.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     zev@...ilderbeest.net, Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] regulator: Add uapi header

Hi


On Thu, 31 Aug 2023 at 18:05, Mark Brown <broonie@...nel.org> wrote:
>
> On Thu, Aug 31, 2023 at 02:14:08PM +0200, Naresh Solanki wrote:
>
> > +#define REGULATOR_EVENT_UNDER_VOLTAGE                0x01
> > +#define REGULATOR_EVENT_OVER_CURRENT         0x02
> > +#define REGULATOR_EVENT_REGULATION_OUT               0x04
> > +#define REGULATOR_EVENT_FAIL                 0x08
> > +#define REGULATOR_EVENT_OVER_TEMP            0x10
> > +#define REGULATOR_EVENT_FORCE_DISABLE                0x20
> > +#define REGULATOR_EVENT_VOLTAGE_CHANGE               0x40
> > +#define REGULATOR_EVENT_DISABLE                      0x80
> > +#define REGULATOR_EVENT_PRE_VOLTAGE_CHANGE   0x100
> > +#define REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE 0x200
> > +#define REGULATOR_EVENT_PRE_DISABLE          0x400
> > +#define REGULATOR_EVENT_ABORT_DISABLE                0x800
> > +#define REGULATOR_EVENT_ENABLE                       0x1000
>
> I'm not sure embedded the raw numbers in the UAPI like this for just one
> driver is ideal - it might be better to do something string based,
> though that would result in us ending up with a file per event which is
> a bit noisy.
I guess this is the standard approach & can be a starting point for
future use cases.

If you still insist on string based then can you please elaborate on it.
Is the events attribute is expected to print string of space separated
events like
for REGULATOR_EVENT_ENABLE -> ENABLE
And even multiple events like: 'UNDER_VOLTAGE REGULATION_OUT'

Let me know your thoughts.

Regards,
Naresh