Re: [PATCH v12 14/17] counter: Implement *_component_id sysfs attributes

[Jonathan Cameron]

On Sun, 11 Jul 2021 09:08:29 -0500
David Lechner <david@xxxxxxxxxxxxxx> wrote:

> On 7/11/21 8:28 AM, Jonathan Cameron wrote:
> > On Sat, 10 Jul 2021 12:06:53 -0500
> > David Lechner <david@xxxxxxxxxxxxxx> wrote:
> >   
> >> On 7/5/21 3:19 AM, William Breathitt Gray wrote:  
> >>> The Generic Counter chrdev interface expects users to supply component
> >>> IDs in order to select extensions for requests. In order for users to
> >>> know what component ID belongs to which extension this information must
> >>> be exposed. The *_component_id attribute provides a way for users to
> >>> discover what component ID belongs to which respective extension.
> >>>
> >>> Cc: David Lechner <david@xxxxxxxxxxxxxx>
> >>> Cc: Gwendal Grignou <gwendal@xxxxxxxxxxxx>
> >>> Cc: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
> >>> Signed-off-by: William Breathitt Gray <vilhelm.gray@xxxxxxxxx>
> >>> ---
> >>>    Documentation/ABI/testing/sysfs-bus-counter | 16 ++++++++++-
> >>>    drivers/counter/counter-sysfs.c             | 30 ++++++++++++++++-----
> >>>    2 files changed, 39 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter
> >>> index 9809d8a47431..e0e99adb0ecc 100644
> >>> --- a/Documentation/ABI/testing/sysfs-bus-counter
> >>> +++ b/Documentation/ABI/testing/sysfs-bus-counter
> >>> @@ -203,12 +203,26 @@ Description:
> >>>    		both edges:
> >>>    			Any state transition.
> >>>    
> >>> +What:		/sys/bus/counter/devices/counterX/countY/ceiling_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/floor_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/count_mode_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/direction_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/enable_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/error_noise_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/prescaler_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/preset_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/countY/preset_enable_component_id
> >>>    What:		/sys/bus/counter/devices/counterX/countY/signalZ_action_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/signalY/cable_fault_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/signalY/cable_fault_enable_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/signalY/index_polarity_component_id
> >>> +What:		/sys/bus/counter/devices/counterX/signalY/synchronous_mode_component_id  
> >>
> >> Could we just write a single line?
> >>
> >> What:		/sys/bus/counter/devices/counterX/signalY/<component>_component_id  
> > 
> > Not nice for grepping so I think it's better to call them out explicitly.
> > 
> > There has been a proposal to check this ABI doc against running kernels, and if we have
> > too many wild cards that becomes very difficult to do.
> > 
> > Jonathan
> >   
> >>  
> >>>    KernelVersion:	5.15  
> 
> Makes sense. Do we start a new group of similar names with the same
> description for each kernel release that includes new attributes then?

You've spotted one of the short comings of current format.  The scripts that
produce the html docs don't cope with multiple version numbers.

Mostly for IIO we've just been cynical and not had the correct kernel version for
new ABI when it's added. It's not ideal though.

The alternative, as you mention is to have a new block.  Perhaps we can have
that refer back to the existing one if the docs cover the new entries as well.

@Mauro:  Any suggestions for this?

Thanks

Jonathan


> 
> >>>    Contact:	linux-iio@xxxxxxxxxxxxxxx
> >>>    Description:
> >>>    		Read-only attribute that indicates the component ID of the
> >>> -		respective Synapse of Count Y for Signal Z.
> >>> +		respective extension or Synapse.
> >>>