On Tue, Feb 04, 2025 at 02:12:33PM GMT, Bartosz Golaszewski wrote: > On Mon, Feb 3, 2025 at 4:12 AM Koichiro Den <koichiro.den@xxxxxxxxxxxxx> wrote: > > > > Expose settings for aggregators created using the sysfs 'new_device' > > interface to configfs. Once written to 'new_device', an "_auto.<N>" path > > I would prefer this to be called "_sysfs.<N>" as it's not really > "automatic" - the user did create this, just with a different > interface. Makes sense, I'll change it in v3. Thanks, Koichiro > > > appears in the configfs regardless of whether the probe succeeds. > > Consequently, users can no longer use that prefix for custom GPIO > > aggregator names. The 'live' attribute changes to 1 when the probe > > succeeds and the GPIO forwarder is instantiated. > > > > Note that the aggregator device created via sysfs is asynchrnous, i.e. > > writing into 'new_device' returns without waiting for probe completion, > > and the probe may succeed, fail, or eventually succeed via deferred > > probe. Thus, the 'live' attribute may change from 0 to 1 asynchronously > > without notice. So, editting key/offset/name while it's waiting for > > deferred probe is prohibited. > > > > The configfs auto-generation relies on create_default_group(), which > > inherently prohibits rmdir(2). To align with the limitation, this commit > > also prohibits mkdir(2) for them. When users want to change the number > > of lines for an aggregator initialized via 'new_device', they need to > > tear down the device using 'delete_device' and reconfigure it from > > scratch. This does not break previous behaviour; users of legacy sysfs > > interface simply gain additional almost read-only configfs exposure. > > > > Still, users can write into 'live' attribute to toggle the device unless > > it's waiting for deferred probe. So once probe succeeds, they can > > deactivate it in the same manner as the devices initialized via > > configfs. > > > > Signed-off-by: Koichiro Den <koichiro.den@xxxxxxxxxxxxx> > > --- > > Bart