On Wed, Jun 11, 2014 at 04:05:42PM +0200, Johan Hovold wrote:
> On Wed, Jun 11, 2014 at 12:21:39AM +0300, Janne Kanniainen wrote:
> > +static const char gt683r_led_select_leds[GT683R_BUFFER_SIZE] = { 0x01, 0x02, 0x30, 0x00,
> > + 0x00, 0x00, 0x00, 0x00 };
> > +static const char gt683r_led_select_type[GT683R_BUFFER_SIZE] = { 0x01, 0x02, 0x20, 0x00,
> > + 0x01, 0x00, 0x00, 0x00 };
>
> 80 char limit.
>
> Perhaps move these to gt683r_led_set, which is the only place where they
> are used?
Or, as I hinted earlier, just allocate the 8-byte buffer using kzalloc
and only initialise the non-zero bytes directly. The first byte should
be the report id (0x01). I noticed that some hid-drivers use this fact
when sending the raw request (see below).
> > +
> > +static void gt683r_brightness_set(struct led_classdev *led_cdev,
> > + enum led_brightness brightness)
> > +{
> > + struct gt683r_led *led =
> > + container_of(led_cdev, struct gt683r_led, led_dev);
> > +
> > + led->brightness = brightness;
> > +
> > + schedule_work(&led->work);
> > +}
> > +
> > +static int gt683r_led_snd_msg(struct gt683r_led *led, char *msg)
> > +{
> > + int ret;
> > +
> > + ret = hid_hw_raw_request(led->hdev, 0x01, msg, GT683R_BUFFER_SIZE,
> > + HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
That is, you could use msg[0] here instead of 0x01.
> > + if (ret < 0) {
> > + hid_err(led->hdev,
> > + "failed to send set report request: %i\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
