Use the DEVICE_ATTR_RW macro to reduce boiler plate and move the
attribute declaration to get rid of function signatures.
Signed-off-by: Vivien Didelot
---
drivers/hid/hid-lg4ff.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers
There is no reason to set the range attribute executable to the user and
group, and writable to the group. Fix the permission to 0644.
Signed-off-by: Vivien Didelot
---
drivers/hid/hid-lg4ff.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lg4ff.c b
what is useful to switch on and off the LED.
This feature is still easily accessible through hidraw.
Signed-off-by: Vivien Didelot
---
Documentation/ABI/testing/sysfs-driver-hid-thingm | 7 -
drivers/hid/hid-thingm.c | 33 ---
2 files change
As for the "play" sysfs attribute, remove this other non-standard
attribute, so the driver only implements what is required to switch the
LED on and off. Thus, a fade time won't be ideal for some fast-changing
triggers.
Signed-off-by: Vivien Didelot
---
Documentation/ABI/testi
This patchset introduces the support of the blink(1) mk2 device, after a
refactoring of the thingm driver. It removes non-standard sysfs attributes and
uses work queues to fix the usage of triggers with this device.
Vivien Didelot (4):
HID: (thingm) remove the "play" sysfs attri
h the driver name.
Signed-off-by: Vivien Didelot
---
Documentation/ABI/testing/sysfs-driver-hid-thingm | 8 -
drivers/hid/hid-thingm.c | 304 +++---
drivers/leds/Kconfig | 2 +
3 files changed, 209 insertions(+), 105 de
t) command does not support setting a color for a
single RGB chip, so it was changed to 'c' (fade) with a timeout of 0.
Signed-off-by: Vivien Didelot
---
drivers/hid/hid-thingm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-thingm.c b/driv
version 3. It updates the name of the source file, the
driver and the led sysfs entry, according to comments from Jiri Kosina
and Simon Wood.
Signed-off-by: Vivien Didelot
---
Documentation/ABI/testing/sysfs-driver-hid-thingm | 23 ++
MAINTAINERS | 5 +
drivers
> > The vendor's name is "ThingM" and the product's name is "blink(1)",
> > not "blink".
> > Given that, would you prefer to keep "blink(1)::1234", or would it
> > rather be
> > "thingm-blink1::1234" (avoiding parenthesis)?
> >
> > I ask the same question for the driver name, which is actually
>
Hi,
> > > Shouldn't the name presented in the sys/class/leds directories
> > > change
> > > appropriately too?
> >
> > The directory name for the device under /sys/class/leds is
> > "blink(1)::",
> > where is the last 4 digits of the device serial number
> > (the first 4
> > digits are always th
Hi Simon,
> > +++ b/Documentation/ABI/testing/sysfs-driver-hid-blink1
> > @@ -0,0 +1,23 @@
> > +What: /sys/class/leds/blink(1)::/rgb
> > +Date: January 2013
> > +Contact: Vivien Didelot
> > +Description: The ThingM b
Hi,
I wrote:
> Should I keep the Kconfig macro CONFIG_BLINK1 or CONFIG_THINGM_BLINK1
> sounds better?
CONFIG_HID_THINGM_BLINK1 is definitely more explicit. Here's a link to the v2:
https://lkml.org/lkml/2013/1/21/435
Thanks,
Vivien
--
To unsubscribe from this list: send the line "unsubscribe lin
: Vivien Didelot
---
Documentation/ABI/testing/sysfs-driver-hid-blink1 | 23 ++
MAINTAINERS | 5 +
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c
Hi Jiri,
> hid-blink sounds too generic to me, taking into account that this is
> not
> 'generic HID blinking' framework, but rather a specific device driver
> for
> a particular device.
>
> So something like hid-thingm-blink sounds more reasonable to me.
Ok, I'll name the file hid-thingm-blink1
: Vivien Didelot
---
Documentation/ABI/testing/sysfs-driver-hid-blink1 | 25 ++
MAINTAINERS | 5 +
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-blink1.c
15 matches
Mail list logo
