[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63fe0803-8120-41a8-8998-a4e6aa32308e@hatter.bewilderbeest.net>
Date: Wed, 20 Sep 2023 03:44:29 -0700
From: Zev Weiss <zev@...ilderbeest.net>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Mark Brown <broonie@...nel.org>,
Naresh Solanki <naresh.solanki@...ements.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output
On Wed, Sep 20, 2023 at 02:29:15AM PDT, Greg Kroah-Hartman wrote:
>On Wed, Sep 20, 2023 at 02:02:49AM -0700, Zev Weiss wrote:
>> static int regulator_userspace_notify(struct notifier_block *nb,
>> unsigned long event,
>> void *ignored)
>> {
>> struct userspace_consumer_data *data =
>> container_of(nb, struct userspace_consumer_data, nb);
>> - static const char * const *envp[] = { "NAME=events", NULL };
>
>You removed this user/kernel api value, what will break if you do that?
>
Sorry, I don't follow -- what removal are you referring to? The envp
array still has a NAME entry -- I changed its value from "events" to
"event", but I wrote that part before I realized that the 'event'
parameter of the function was actually a bitmask that might convey
multiple events and just forgot to change it back, so keeping it
pluralized is probably more appropriate.
And FWIW, I didn't intend for the exact format of the EVENT parameter
that I sketched there to be something that had to be kept; given that
there might be multiple entries perhaps it'd be better to use separate
parameters more like NUMEVENTS, EVENT0, EVENT1, etc? (Or omit NUMEVENTS
and just let the consumer count upward until it doesn't find a match.)
Zev
Powered by blists - more mailing lists