lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 1 Jul 2014 22:16:27 +0200
From:	Johan Hovold <johan@...nel.org>
To:	Janne Kanniainen <janne.kanniainen@...il.com>
Cc:	johan@...nel.org, cooloney@...il.com, jkosina@...e.cz,
	greg@...ah.com, bjorn@...k.no, linux-kernel@...r.kernel.org,
	linux-leds@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: Re: [PATCH 2/2 v4] HID: leds: move led_mode attribute to led-class
 devices in MSI GT683R driver

On Tue, Jul 01, 2014 at 08:50:54PM +0300, Janne Kanniainen wrote:
  
> -static DEVICE_ATTR_RW(leds_mode);
> +static DEVICE_ATTR_RW(mode);
> +
> +static struct attribute *gt683r_led_attrs[] = {
> +	&dev_attr_mode.attr,
> +	NULL
> +};
> +
> +ATTRIBUTE_GROUPS(gt683r_led);

I was referring to the name field of struct attribute_group (and not of
struct hid_driver). Specifically, that means that you cannot use the
ATTRIBUTE_GROUPS macro (which leaves the name field unset), but rather
should define the two corresponding structs directly as follows:

	static const struct attribute_group gt683r_led_group = {
	       .name = "gt683r",
	       .attrs = gt683r_led_attrs,
	};
	
	static const struct attribute_group *gt683r_led_groups[] = {
	       &gt683r_led_group,
	       NULL
	};

That way the mode attribute will be created in a subdirectory (named
gt683r) of the led class device.

>  static int gt683r_led_probe(struct hid_device *hdev,
>  			const struct hid_device_id *id)
> @@ -261,6 +270,8 @@ static int gt683r_led_probe(struct hid_device *hdev,
>  		led->led_devs[i].name = name;
>  		led->led_devs[i].max_brightness = 1;
>  		led->led_devs[i].brightness_set = gt683r_brightness_set;
> +		led->led_devs[i].groups = gt683r_led_groups;
> +
>  		ret = led_classdev_register(&hdev->dev, &led->led_devs[i]);
>  		if (ret) {
>  			hid_err(hdev, "could not register led device\n");
> @@ -268,12 +279,6 @@ static int gt683r_led_probe(struct hid_device *hdev,
>  		}
>  	}

<snip>

> @@ -298,7 +302,7 @@ static void gt683r_led_remove(struct hid_device *hdev)
>  static struct hid_driver gt683r_led_driver = {
>  	.probe = gt683r_led_probe,
>  	.remove = gt683r_led_remove,
> -	.name = "gt683r_led",
> +	.name = "gt683r",

So you should skip this bit.

>  	.id_table = gt683r_led_id,
>  };

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ