Re: [PATCH] docs: driver-model: Update the documentation for device class

2021-04-03 Thread Manivannan Sadhasivam
On Sat, Apr 03, 2021 at 03:04:42PM +0200, Greg KH wrote:
> On Sat, Apr 03, 2021 at 05:30:50PM +0530, Manivannan Sadhasivam wrote:
> > The current documentation about the device class is out of date such
> > that it refers to non-existent APIs and structures. This commit updates
> > them to the current device class APIs and structures, removes wordings
> > that no longer valid while trying to keep the original content intact.
> 
> Thanks for working on this!
> 
> One thing that instantly jumped out at me:
> 
> > -Class drivers can export attributes using the DEVCLASS_ATTR macro that 
> > works
> > -similarly to the DEVICE_ATTR macro for devices. For example, a definition
> > +Class drivers can export attributes using the CLASS_ATTR_* macros that 
> > works
> > +similarly to the DEVICE_ATTR_* macros for devices. For example, a 
> > definition
> >  like this::
> >  
> > -  static DEVCLASS_ATTR(debug,0644,show_debug,store_debug);
> > +  static CLASS_ATTR_RW(debug, 0644, show_debug, store_debug);
> 
> CLASS_ATTR_RW(debug);
> is the correct way to write the above, what you added there will not
> build.
> 

Oops... I just did a blind replace there, thanks for spotting.

> But a meta-comment, should stuff like this go directly into the .c files
> itself so that the documentation is created automatically?  the fact
> that this lives so "far away" from the source ensures that it will
> always be out of date.  I know other subsystems (graphics, v4l2) have
> tied the documentation into their code files much better so I think the
> build and markup infrastructure is there today to do this.
> 

Well you're right that this documentation is far from its implementation but
that applies to most of the stuffs inside kernel, right? Also, I think if we
move these into .c file, then it will flood the whole file IMO.

We already have the kernel doc for most of the APIs/structures and that should
be enough for the .c/.h code in my perspective. If a developer wants to obtain
more information other than the API/struct definitions, then they should land
in documentation.

It should be responsibility of the maintainer to keep the doc up-to date :)

Thanks,
Mani

> thanks,
> 
> greg k-h


Re: [PATCH] docs: driver-model: Update the documentation for device class

2021-04-03 Thread Greg KH
On Sat, Apr 03, 2021 at 05:30:50PM +0530, Manivannan Sadhasivam wrote:
> The current documentation about the device class is out of date such
> that it refers to non-existent APIs and structures. This commit updates
> them to the current device class APIs and structures, removes wordings
> that no longer valid while trying to keep the original content intact.

Thanks for working on this!

One thing that instantly jumped out at me:

> -Class drivers can export attributes using the DEVCLASS_ATTR macro that works
> -similarly to the DEVICE_ATTR macro for devices. For example, a definition
> +Class drivers can export attributes using the CLASS_ATTR_* macros that works
> +similarly to the DEVICE_ATTR_* macros for devices. For example, a definition
>  like this::
>  
> -  static DEVCLASS_ATTR(debug,0644,show_debug,store_debug);
> +  static CLASS_ATTR_RW(debug, 0644, show_debug, store_debug);

CLASS_ATTR_RW(debug);
is the correct way to write the above, what you added there will not
build.

But a meta-comment, should stuff like this go directly into the .c files
itself so that the documentation is created automatically?  the fact
that this lives so "far away" from the source ensures that it will
always be out of date.  I know other subsystems (graphics, v4l2) have
tied the documentation into their code files much better so I think the
build and markup infrastructure is there today to do this.

thanks,

greg k-h


[PATCH] docs: driver-model: Update the documentation for device class

2021-04-03 Thread Manivannan Sadhasivam
The current documentation about the device class is out of date such
that it refers to non-existent APIs and structures. This commit updates
them to the current device class APIs and structures, removes wordings
that no longer valid while trying to keep the original content intact.

Signed-off-by: Manivannan Sadhasivam 
---
 .../driver-api/driver-model/class.rst | 144 --
 1 file changed, 66 insertions(+), 78 deletions(-)

diff --git a/Documentation/driver-api/driver-model/class.rst 
b/Documentation/driver-api/driver-model/class.rst
index fff55b80e86a..4e1779a37939 100644
--- a/Documentation/driver-api/driver-model/class.rst
+++ b/Documentation/driver-api/driver-model/class.rst
@@ -5,12 +5,7 @@ Device Classes
 Introduction
 
 A device class describes a type of device, like an audio or network
-device. The following device classes have been identified:
-
-
-
-
-Each device class defines a set of semantics and a programming interface
+device. It defines a set of semantics and a programming interface
 that devices of that class adhere to. Device drivers are the
 implementation of that programming interface for a particular device on
 a particular bus.
@@ -18,23 +13,27 @@ a particular bus.
 Device classes are agnostic with respect to what bus a device resides
 on.
 
-
 Programming Interface
 ~
 The device class structure looks like::
 
+  struct class {
+const char  *name;
+struct module   *owner;
 
-  typedef int (*devclass_add)(struct device *);
-  typedef void (*devclass_remove)(struct device *);
+const struct attribute_group**class_groups;
+const struct attribute_group**dev_groups;
+struct kobject  *dev_kobj;
+...
+  };
 
 See the kerneldoc for the struct class.
 
 A typical device class definition would look like::
 
-  struct device_class input_devclass = {
-.name  = "input",
-.add_device= input_add_device,
-   .remove_device  = input_remove_device,
+  struct class input_class = {
+.name   = "input",
+.dev_release= input_dev_release,
   };
 
 Each device class structure should be exported in a header file so it
@@ -42,101 +41,84 @@ can be used by drivers, extensions and interfaces.
 
 Device classes are registered and unregistered with the core using::
 
-  int devclass_register(struct device_class * cls);
-  void devclass_unregister(struct device_class * cls);
-
+  int class_register(struct class *class);
+  void class_unregister(struct class *class);
 
 Devices
 ~~~
-As devices are bound to drivers, they are added to the device class
-that the driver belongs to. Before the driver model core, this would
-typically happen during the driver's probe() callback, once the device
-has been initialized. It now happens after the probe() callback
-finishes from the core.
-
-The device is enumerated in the class. Each time a device is added to
-the class, the class's devnum field is incremented and assigned to the
-device. The field is never decremented, so if the device is removed
-from the class and re-added, it will receive a different enumerated
-value.
-
-The class is allowed to create a class-specific structure for the
-device and store it in the device's class_data pointer.
-
-There is no list of devices in the device class. Each driver has a
-list of devices that it supports. The device class has a list of
-drivers of that particular class. To access all of the devices in the
-class, iterate over the device lists of each driver in the class.
+When a device is added, it is also added to the 'klist_devices' inside
+the 'subsys_private' struct of the class. Later, the devices belonging
+to the class are accessed using::
 
+  class_dev_iter_next()
+  class_find_device()
+  class_find_device_by_name()
 
-Device Drivers
-~~
-Device drivers are added to device classes when they are registered
-with the core. A driver specifies the class it belongs to by setting
-the struct device_driver::devclass field.
+It is also possible to access the devices of a class in a platform
+dependent way using::
 
+  class_find_device_by_of_node()
+  class_find_device_by_acpi_dev()
 
 sysfs directory structure
 
 There is a top-level sysfs directory named 'class'.
 
-Each class gets a directory in the class directory, along with two
-default subdirectories::
+Each class gets a directory in the top-level class directory::
 
-class/
-`-- input
-|-- devices
-`-- drivers
+  class/
+  |-- input
+  |-- block
+  |-- drm
+  |-- nvme
 
-
-Drivers registered with the class get a symlink in the drivers/ directory
-that points to the driver's directory (under its bus directory)::
-
-   class/
-   `-- input
-   |-- devices
-   `-- drivers
-   `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/
-
-
-Each device gets a symlink