Looks ok, but I think the changelog could be more accurate.

On Fri, Feb 22, 2019 at 3:59 PM Vishal Verma <[email protected]> wrote:
>
> Add a 'modalias' attribute to devices under the DAX bus so that userspace
> is able to dynamically load modules as needed.

The modalias is already published in the uevent which is how udev
identifies the module. This patch would allow "modalias to module
lookups" *outside* of the typical uevent used for dynamically loading
modules.

Care to fix up the changelog with that detail and why userspace needs
to do these lookups in addition to the typical uevent lookups?

> The modalias already
> exists, it was only the sysfs attribute that was missing.
>
> Cc: Dan Williams <[email protected]>
> Cc: Dave Hansen <[email protected]>
> Signed-off-by: Vishal Verma <[email protected]>
> ---
>  drivers/dax/bus.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index 28c3324271ac..2109cfe80219 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -295,6 +295,17 @@ static ssize_t target_node_show(struct device *dev,
>  }
>  static DEVICE_ATTR_RO(target_node);
>
> +static ssize_t modalias_show(struct device *dev, struct device_attribute 
> *attr,
> +               char *buf)
> +{
> +       /*
> +        * We only ever expect to handle device-dax instances, i.e. the
> +        * @type argument to MODULE_ALIAS_DAX_DEVICE() is always zero
> +        */
> +       return sprintf(buf, DAX_DEVICE_MODALIAS_FMT "\n", 0);
> +}
> +static DEVICE_ATTR_RO(modalias);
> +
>  static umode_t dev_dax_visible(struct kobject *kobj, struct attribute *a, 
> int n)
>  {
>         struct device *dev = container_of(kobj, struct device, kobj);
> @@ -306,6 +317,7 @@ static umode_t dev_dax_visible(struct kobject *kobj, 
> struct attribute *a, int n)
>  }
>
>  static struct attribute *dev_dax_attributes[] = {
> +       &dev_attr_modalias.attr,
>         &dev_attr_size.attr,
>         &dev_attr_target_node.attr,
>         NULL,
> --
> 2.20.1
>
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to