From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 020D2CE79C2 for ; Wed, 20 Sep 2023 10:53:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234267AbjITKxf (ORCPT ); Wed, 20 Sep 2023 06:53:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234036AbjITKxc (ORCPT ); Wed, 20 Sep 2023 06:53:32 -0400 Received: from thorn.bewilderbeest.net (thorn.bewilderbeest.net [IPv6:2605:2700:0:5::4713:9cab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 35E2FB4 for ; Wed, 20 Sep 2023 03:53:27 -0700 (PDT) Received: from hatter.bewilderbeest.net (unknown [IPv6:2602:61:7e5d:5300::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: zev) by thorn.bewilderbeest.net (Postfix) with ESMTPSA id E453F2A7; Wed, 20 Sep 2023 03:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bewilderbeest.net; s=thorn; t=1695207207; bh=9el9Pcz/ONWOavO3ghWssH92pAeXdvb0MjC2aQTSwcg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WTRxXAetgfANTRD18QLW9GT6NenzctP9kqxKtgvBAWvrIMWgcYFv5Ws0wzbvKsaJk SnaJocY/XuK/Za39P3r9CRNTMXPue1whP9Xuq0GbtYl9XjO6VdjKYDt4+DckPJs6Xe 2+s6BfOZ618r1iLPGnuZSffNtUFmJr7pPhcgf0T8= Date: Wed, 20 Sep 2023 03:53:25 -0700 From: Zev Weiss To: Greg Kroah-Hartman Cc: Mark Brown , Naresh Solanki , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] Documentation: ABI: sysfs-driver-regulator-output Message-ID: References: <90b1af83-cb03-476f-9147-eb06247bf09c@hatter.bewilderbeest.net> <2023090330-bling-mammary-3177@gregkh> <6eb78818-7838-4616-bf44-05c215bfa8b3@hatter.bewilderbeest.net> <763bd845-d8d6-489c-bd31-305ed14bc40f@sirena.org.uk> <1518370c-e0cd-4d78-af54-3e2cf4dd6e3c@hatter.bewilderbeest.net> <5282acd1-3c7a-4948-83f2-2829910ab841@sirena.org.uk> <25844d80-fadb-44c3-a0e6-334aa6e4afd7@hatter.bewilderbeest.net> <2023092037-denote-enslave-0a3f@gregkh> <63fe0803-8120-41a8-8998-a4e6aa32308e@hatter.bewilderbeest.net> <2023092027-epileptic-jolly-84ef@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <2023092027-epileptic-jolly-84ef@gregkh> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 20, 2023 at 03:48:00AM PDT, Greg Kroah-Hartman wrote: >On Wed, Sep 20, 2023 at 03:44:29AM -0700, Zev Weiss wrote: >> 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", > >Yes, that value. > >> 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.) > >I don't know, what does userspace do with this value today? If you >change it, what will break? > Unless there's something I'm not aware of, this is an entirely new interface being added, not a change to an existing one, so I don't think there's any existing userspace beyond draft/experimental code. My patch was a relative one on top of Naresh's patch 2/3 in this series as a proposed amendment to it; the userspace-consumer driver as it presently exists in the mainline kernel doesn't have a uevent interface at all. Zev