September 2015 - kernelnewbies@kernelnewbies.org

USB error codes and usbmon
by alx741＠riseup.net Sept. 7, 2015

Sept. 7, 2015

Kernel newbies community, I'm writing a simple usb device implementation using PIC microcontroller and using USBMON to debug, i've properly receive the very first GET_DESCRIPTOR request and try to send the device descriptor to the host and it seems not to be working, but the USBMON and dmesg confuses me and don't know if the device isn't sending the descriptor or if it's corrupted or if the descriptor is ok but the device don't accept the address (not programmed yet in the device). The USBMON output for the device (address 0) is: ffff8801c3272480 1145843 S Ci:3:000:0 s 80 06 0100 0000 0040 64 < ffff8801c3272480 2203609 C Ci:3:000:0 -32 0 ffff8801c3272480 2203652 S Ci:3:000:0 s 80 06 0100 0000 0040 64 < ffff8801c3272480 2203728 C Ci:3:000:0 -71 0 ffff8801c3272480 2203827 S Ci:3:000:0 s 80 06 0100 0000 0040 64 < ffff8801c3272480 2203952 C Ci:3:000:0 -71 0 The host request the device descriptor and asks for 64 bytes, from the device i (try to) send the descriptor but don't know what the "-32" and "-71" errors means, descriptor not received? descriptor bad constructed? neither? the DMESG output is: [ 3497.029992] usb 3-1.3: new full-speed USB device number 7 using xhci_hcd [ 3498.154446] usb 3-1.3: device descriptor read/64, error -71 [ 3498.324591] usb 3-1.3: device descriptor read/64, error -71 [ 3498.494831] usb 3-1.3: new full-speed USB device number 8 using xhci_hcd [ 3498.561500] usb 3-1.3: device descriptor read/64, error -71 [ 3498.731740] usb 3-1.3: device descriptor read/64, error -71 [ 3498.901870] usb 3-1.3: new full-speed USB device number 9 using xhci_hcd [ 3498.902080] usb 3-1.3: Device not responding to setup address. [ 3499.105555] usb 3-1.3: Device not responding to setup address. [ 3499.308882] usb 3-1.3: device not accepting address 9, error -71 [ 3499.375759] usb 3-1.3: new full-speed USB device number 10 using xhci_hcd [ 3499.375892] usb 3-1.3: Device not responding to setup address. [ 3499.579423] usb 3-1.3: Device not responding to setup address. [ 3499.782770] usb 3-1.3: device not accepting address 10, error -71 [ 3499.783035] usb 3-1-port3: unable to enumerate USB device Here the "-71" error is used for both device descriptor read error and device not accepting address. Is there a way to see what the host receives even if the data that is sent pretending to be the device descriptor is corrupted (for debugging)? and how can i know for sure what those errors tell me so i can start looking for the errors in my device code? Any pointers are much appreciated. Greetings from Ecuador.

1 0

Re: How to properly unregister LED class devices?
by Pranay Srivastava Sept. 7, 2015

Sept. 7, 2015

On Mon, Sep 7, 2015 at 4:58 PM, Jacek Anaszewski <j.anaszewski(a)samsung.com> wrote: > Hi Clément, > > > On 09/07/2015 11:05 AM, Clément Vuchener wrote: >> >> On Mon, Sep 07, 2015 at 12:08:17PM +0530, Pranay Srivastava wrote: >>> >>> On Sun, Sep 6, 2015 at 11:18 PM, Clément Vuchener >>> <clement.vuchener(a)gmail.com> wrote: >>>> >>>> Hello, >>>> >>>> I am trying to write a driver that uses LED class devices using works >>>> for setting the LED brightness but I am not sure of how to unregister the >>>> devices. >>>> >>>> I have been using code like this: >>>> led_classdev_unregister(&drvdata->backlight.cdev); >>>> cancel_work_sync(&drvdata->backlight.work); >>>> trying with both flush_work or cancel_work_sync as I have seen it in >>>> other drivers. >>>> >>>> Using flush_work, the kernel oops in my work function when I unplug the >>>> device. cancel_work_sync seems to fix that, but I am not sure it will work >>>> every time. I would like to understand what happens and if I am doing >>>> something wrong, to be sure it will not break in some different setup. >>> >>> >>> Can you post the backtrace? >>> >> >> I could not get it with my patched kernel (I must be missing some config >> option) so I used the code as a module on my fedora 22 (4.1.6) kernel. >> >> general protection fault: 0000 [#1] SMP >> Modules linked in: hid_corsair_k90(OE) bnep bluetooth nf_nat_h323 >> nf_conntrack_h323 nf_nat_pptp nf_nat_proto_gre nf_conntrack_pptp >> nf_conntrack_proto_g >> snd_hda_codec_hdmi coretemp arc4 kvm_intel snd_hda_codec_realtek iwldvm >> kvm snd_hda_codec_generic mac80211 snd_hda_intel snd_hda_controller >> snd_hda_co >> CPU: 2 PID: 491 Comm: kworker/2:3 Tainted: G OE >> 4.1.6-200.fc22.x86_64 #1 >> Hardware name: CLEVO CO. W350ET/W350ET, BIOS >> 1.02.21PM v3 07/01/2013 >> Workqueue: events k90_record_led_work [hid_corsair_k90] >> task: ffff880223bd4f00 ti: ffff8800c92a0000 task.ti: ffff8800c92a0000 >> RIP: 0010:[<ffffffff814e8816>] [<ffffffff814e8816>] >> __dev_printk+0x26/0x90 >> RSP: 0018:ffff8800c92a3d48 EFLAGS: 00010202 >> RAX: 657079740000009d RBX: ffff8801fcee7800 RCX: 000000000001a2e1 >> RDX: ffff8800c92a3d58 RSI: ffff8801fcee7800 RDI: ffffffff81a2673f >> RBP: ffff8800c92a3d48 R08: 0000001400730102 R09: ffff8800c92a3d58 >> R10: ffffffff81578c4b R11: 0000000000000000 R12: ffff88022f317000 >> R13: ffff88022f31b900 R14: 0000000000000080 R15: ffff8801fcc7d320 >> FS: 0000000000000000(0000) GS:ffff88022f300000(0000) >> knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 0000000002eee850 CR3: 0000000002c0b000 CR4: 00000000001406e0 >> Stack: >> ffff8800c92a3db8 ffffffff814e8bd2 ffffffffa09701f8 ffff8800c92a3d68 >> ffff880100000010 ffff8800c92a3dc8 ffff8800c92a3d88 000000002440e468 >> 0000000000000000 ffff8801fcee7800 00000000ffffffed 000000000001a2e1 >> Call Trace: >> [<ffffffff814e8bd2>] dev_warn+0x62/0x80 >> [<ffffffffa096f44c>] k90_record_led_work+0x8c/0xa0 [hid_corsair_k90] >> [<ffffffff8179da31>] ? __schedule+0x241/0x720 >> [<ffffffff810baadb>] process_one_work+0x1bb/0x410 >> [<ffffffff810baeec>] worker_thread+0x1bc/0x480 >> [<ffffffff810bad30>] ? process_one_work+0x410/0x410 >> [<ffffffff810bad30>] ? process_one_work+0x410/0x410 >> [<ffffffff810c0bf8>] kthread+0xd8/0xf0 >> [<ffffffff810c0b20>] ? kthread_worker_fn+0x180/0x180 >> [<ffffffff817a2322>] ret_from_fork+0x42/0x70 >> [<ffffffff810c0b20>] ? kthread_worker_fn+0x180/0x180 >> Code: 00 00 00 00 00 0f 1f 44 00 00 55 48 85 f6 49 89 d1 48 89 e5 74 60 4c >> 8b 46 50 4d 85 c0 74 26 48 8b 86 90 00 00 00 48 85 c0 74 2a <48> 8b 08 0f be >> RIP [<ffffffff814e8816>] __dev_printk+0x26/0x90 > > > As your backtrace shows, the problem originates from dev_warn call from > k90_record_led_work. dev_warn takes dev in its first argument, which > is already released at the time when it is called as a result of the > call to flush_work. In order to work this around you could set some > flag on remove to indicate that LED class device has been released > and return from k90_record_led_work immediately. You can also try doing get_device to have > 1 ref count so it won't go away. But I still feel you shouldn't have to if you re-order your work_fn and unregister calls. That is flush/cancel work before unregistering and then at the end remove sysfs group. > The same applies to your question regarding retaining the LED state > on remove. Hope this helps. > > Is the backtrace always the same? It could likely happen also earlier, > during dereference of dev in the following line: > > > struct device *dev = led->cdev.dev->parent; > > -- > Best Regards, > Jacek Anaszewski -- ---P.K.S

2 2

How to properly unregister LED class devices?
by Clément Vuchener Sept. 7, 2015

Sept. 7, 2015

Hello, I am trying to write a driver that uses LED class devices using works for setting the LED brightness but I am not sure of how to unregister the devices. I have been using code like this: led_classdev_unregister(&drvdata->backlight.cdev); cancel_work_sync(&drvdata->backlight.work); trying with both flush_work or cancel_work_sync as I have seen it in other drivers. Using flush_work, the kernel oops in my work function when I unplug the device. cancel_work_sync seems to fix that, but I am not sure it will work every time. I would like to understand what happens and if I am doing something wrong, to be sure it will not break in some different setup. Another problem I have with this unregistering is that the LED brightness is set to zero when unregistering when the hardware is supposed to remember the last settings. Thus the LED state is reset when detaching and reattaching the driver. Below is the full code from my driver, if you need it: /* * HID driver for Corsair devices * * Supported devices: * - Vengeance K90 Keyboard * * Copyright (c) 2015 Clement Vuchener */ /* * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free * Software Foundation; either version 2 of the License, or (at your option) * any later version. */ #include <linux/hid.h> #include <linux/module.h> #include <linux/usb.h> #include <linux/leds.h> #include "hid-ids.h" struct k90_led { struct led_classdev cdev; int brightness; struct work_struct work; }; struct k90_drvdata { int current_profile; int macro_mode; int meta_locked; struct k90_led backlight; struct k90_led record_led; }; #define K90_GKEY_COUNT 18 static int k90_usage_to_gkey(unsigned int usage) { /* G1 (0xd0) to G16 (0xdf) */ if (usage >= 0xd0 && usage <= 0xdf) return usage - 0xd0 + 1; /* G17 (0xe8) to G18 (0xe9) */ if (usage >= 0xe8 && usage <= 0xe9) return usage - 0xe8 + 17; return 0; } static unsigned short k90_gkey_map[K90_GKEY_COUNT] = { BTN_TRIGGER_HAPPY1, BTN_TRIGGER_HAPPY2, BTN_TRIGGER_HAPPY3, BTN_TRIGGER_HAPPY4, BTN_TRIGGER_HAPPY5, BTN_TRIGGER_HAPPY6, BTN_TRIGGER_HAPPY7, BTN_TRIGGER_HAPPY8, BTN_TRIGGER_HAPPY9, BTN_TRIGGER_HAPPY10, BTN_TRIGGER_HAPPY11, BTN_TRIGGER_HAPPY12, BTN_TRIGGER_HAPPY13, BTN_TRIGGER_HAPPY14, BTN_TRIGGER_HAPPY15, BTN_TRIGGER_HAPPY16, BTN_TRIGGER_HAPPY17, BTN_TRIGGER_HAPPY18, }; module_param_array_named(gkey_codes, k90_gkey_map, ushort, NULL, S_IRUGO); #define K90_USAGE_SPECIAL_MIN 0xf0 #define K90_USAGE_SPECIAL_MAX 0xff #define K90_USAGE_MACRO_RECORD_START 0xf6 #define K90_USAGE_MACRO_RECORD_STOP 0xf7 #define K90_USAGE_PROFILE 0xf1 #define K90_USAGE_M1 0xf1 #define K90_USAGE_M2 0xf2 #define K90_USAGE_M3 0xf3 #define K90_USAGE_PROFILE_MAX 0xf3 #define K90_USAGE_META_OFF 0xf4 #define K90_USAGE_META_ON 0xf5 #define K90_USAGE_LIGHT 0xfa #define K90_USAGE_LIGHT_OFF 0xfa #define K90_USAGE_LIGHT_DIM 0xfb #define K90_USAGE_LIGHT_MEDIUM 0xfc #define K90_USAGE_LIGHT_BRIGHT 0xfd #define K90_USAGE_LIGHT_MAX 0xfd /* USB control protocol */ #define K90_REQUEST_BRIGHTNESS 49 #define K90_REQUEST_MACRO_MODE 2 #define K90_REQUEST_STATUS 4 #define K90_REQUEST_GET_MODE 5 #define K90_REQUEST_PROFILE 20 #define K90_MACRO_MODE_SW 0x0030 #define K90_MACRO_MODE_HW 0x0001 #define K90_MACRO_LED_ON 0x0020 #define K90_MACRO_LED_OFF 0x0040 /* * LED class devices */ #define K90_BACKLIGHT_LED_SUFFIX ":blue:backlight" #define K90_RECORD_LED_SUFFIX ":red:record" static enum led_brightness k90_brightness_get(struct led_classdev *led_cdev) { struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); return led->brightness; } static void k90_brightness_set(struct led_classdev *led_cdev, enum led_brightness brightness) { struct k90_led *led = container_of(led_cdev, struct k90_led, cdev); led->brightness = brightness; schedule_work(&led->work); } static void k90_backlight_work(struct work_struct *work) { int ret; struct k90_led *led = container_of(work, struct k90_led, work); struct device *dev = led->cdev.dev->parent; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_BRIGHTNESS, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, led->brightness, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) dev_warn(dev, "Failed to set backlight brightness (error: %d).\n", ret); } static void k90_record_led_work(struct work_struct *work) { int ret; struct k90_led *led = container_of(work, struct k90_led, work); struct device *dev = led->cdev.dev->parent; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); int value; if (led->brightness > 0) value = K90_MACRO_LED_ON; else value = K90_MACRO_LED_OFF; ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_MACRO_MODE, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, value, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) dev_warn(dev, "Failed to set record LED state (error: %d).\n", ret); } /* * Keyboard attributes */ static ssize_t k90_show_macro_mode(struct device *dev, struct device_attribute *attr, char *buf) { struct k90_drvdata *drvdata = dev_get_drvdata(dev); return snprintf(buf, PAGE_SIZE, "%s\n", (drvdata->macro_mode ? "HW" : "SW")); } static ssize_t k90_store_macro_mode(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { int ret; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); struct k90_drvdata *drvdata = dev_get_drvdata(dev); __u16 value; if (strncmp(buf, "SW", 2) == 0) value = K90_MACRO_MODE_SW; else if (strncmp(buf, "HW", 2) == 0) value = K90_MACRO_MODE_HW; else return -EINVAL; ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_MACRO_MODE, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, value, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) return ret; drvdata->macro_mode = (value == K90_MACRO_MODE_HW); return count; } static ssize_t k90_show_current_profile(struct device *dev, struct device_attribute *attr, char *buf) { struct k90_drvdata *drvdata = dev_get_drvdata(dev); return snprintf(buf, PAGE_SIZE, "%d\n", drvdata->current_profile); } static ssize_t k90_store_current_profile(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { int ret; struct usb_interface *usbif = to_usb_interface(dev->parent); struct usb_device *usbdev = interface_to_usbdev(usbif); struct k90_drvdata *drvdata = dev_get_drvdata(dev); int profile; if (kstrtoint(buf, 10, &profile)) return -EINVAL; if (profile < 1 || profile > 3) return -EINVAL; ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), K90_REQUEST_PROFILE, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, profile, 0, NULL, 0, USB_CTRL_SET_TIMEOUT); if (ret != 0) return ret; drvdata->current_profile = profile; return count; } static DEVICE_ATTR(macro_mode, 0644, k90_show_macro_mode, k90_store_macro_mode); static DEVICE_ATTR(current_profile, 0644, k90_show_current_profile, k90_store_current_profile); static struct attribute *k90_attrs[] = { &dev_attr_macro_mode.attr, &dev_attr_current_profile.attr, NULL }; static const struct attribute_group k90_attr_group = { .attrs = k90_attrs, }; /* * Driver functions */ static int k90_init_special_functions(struct hid_device *dev) { int ret; struct usb_interface *usbif = to_usb_interface(dev->dev.parent); struct usb_device *usbdev = interface_to_usbdev(usbif); char data[8]; struct k90_drvdata *drvdata = kzalloc(sizeof(struct k90_drvdata), GFP_KERNEL); size_t name_sz; char *name; struct k90_led *led; if (!drvdata) { ret = -ENOMEM; goto fail_drvdata; } hid_set_drvdata(dev, drvdata); /* Get current status */ ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), K90_REQUEST_STATUS, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, 0, data, 8, USB_CTRL_SET_TIMEOUT); if (ret < 0) { hid_warn(dev, "Failed to get K90 initial state (error %d).\n", ret); drvdata->backlight.brightness = 0; drvdata->current_profile = 1; } else { drvdata->backlight.brightness = data[4]; drvdata->current_profile = data[7]; } /* Get current mode */ ret = usb_control_msg(usbdev, usb_rcvctrlpipe(usbdev, 0), K90_REQUEST_GET_MODE, USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE, 0, 0, data, 2, USB_CTRL_SET_TIMEOUT); if (ret < 0) hid_warn(dev, "Failed to get K90 initial mode (error %d).\n", ret); else { switch (data[0]) { case K90_MACRO_MODE_HW: drvdata->macro_mode = 1; break; case K90_MACRO_MODE_SW: drvdata->macro_mode = 0; break; default: hid_warn(dev, "K90 in unknown mode: %02x.\n", data[0]); } } /* Init LED device for backlight */ name_sz = strlen(dev_name(&dev->dev)) + sizeof(K90_BACKLIGHT_LED_SUFFIX); name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); if (!name) { ret = -ENOMEM; goto fail_backlight; } snprintf(name, name_sz, "%s" K90_BACKLIGHT_LED_SUFFIX, dev_name(&dev->dev)); led = &drvdata->backlight; led->cdev.name = name; led->cdev.max_brightness = 3; led->cdev.brightness_set = k90_brightness_set; led->cdev.brightness_get = k90_brightness_get; INIT_WORK(&led->work, k90_backlight_work); ret = led_classdev_register(&dev->dev, &led->cdev); if (ret != 0) goto fail_backlight; /* Init LED device for record LED */ name_sz = strlen(dev_name(&dev->dev)) + sizeof(K90_RECORD_LED_SUFFIX); name = devm_kzalloc(&dev->dev, name_sz, GFP_KERNEL); if (!name) { ret = -ENOMEM; goto fail_record_led; } snprintf(name, name_sz, "%s" K90_RECORD_LED_SUFFIX, dev_name(&dev->dev)); led = &drvdata->record_led; led->cdev.name = name; led->cdev.max_brightness = 1; led->cdev.brightness_set = k90_brightness_set; led->cdev.brightness_get = k90_brightness_get; INIT_WORK(&led->work, k90_record_led_work); ret = led_classdev_register(&dev->dev, &led->cdev); if (ret != 0) goto fail_record_led; /* Init attributes */ ret = sysfs_create_group(&dev->dev.kobj, &k90_attr_group); if (ret != 0) goto fail_sysfs; return 0; fail_sysfs: led_classdev_unregister(&drvdata->record_led.cdev); cancel_work_sync(&drvdata->record_led.work); fail_record_led: led_classdev_unregister(&drvdata->backlight.cdev); cancel_work_sync(&drvdata->backlight.work); fail_backlight: kfree(drvdata); fail_drvdata: hid_set_drvdata(dev, NULL); return ret; } static void k90_cleanup_special_functions(struct hid_device *dev) { struct k90_drvdata *drvdata = hid_get_drvdata(dev); if (drvdata) { sysfs_remove_group(&dev->dev.kobj, &k90_attr_group); led_classdev_unregister(&drvdata->record_led.cdev); led_classdev_unregister(&drvdata->backlight.cdev); cancel_work_sync(&drvdata->record_led.work); cancel_work_sync(&drvdata->backlight.work); kfree(drvdata); } } static int k90_probe(struct hid_device *dev, const struct hid_device_id *id) { int ret; struct usb_interface *usbif = to_usb_interface(dev->dev.parent); ret = hid_parse(dev); if (ret != 0) { hid_err(dev, "parse failed\n"); return ret; } ret = hid_hw_start(dev, HID_CONNECT_DEFAULT); if (ret != 0) { hid_err(dev, "hw start failed\n"); return ret; } if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) { ret = k90_init_special_functions(dev); if (ret != 0) hid_warn(dev, "Failed to initialize K90 special functions.\n"); } else hid_set_drvdata(dev, NULL); return 0; } static void k90_remove(struct hid_device *dev) { struct usb_interface *usbif = to_usb_interface(dev->dev.parent); if (usbif->cur_altsetting->desc.bInterfaceNumber == 0) k90_cleanup_special_functions(dev); hid_hw_stop(dev); } static int k90_event(struct hid_device *dev, struct hid_field *field, struct hid_usage *usage, __s32 value) { struct k90_drvdata *drvdata = hid_get_drvdata(dev); if (!drvdata) return 0; switch (usage->hid & HID_USAGE) { case K90_USAGE_MACRO_RECORD_START: drvdata->record_led.brightness = 1; break; case K90_USAGE_MACRO_RECORD_STOP: drvdata->record_led.brightness = 0; break; case K90_USAGE_M1: case K90_USAGE_M2: case K90_USAGE_M3: drvdata->current_profile = (usage->hid & HID_USAGE) - K90_USAGE_PROFILE + 1; break; case K90_USAGE_META_OFF: drvdata->meta_locked = 0; break; case K90_USAGE_META_ON: drvdata->meta_locked = 1; break; case K90_USAGE_LIGHT_OFF: case K90_USAGE_LIGHT_DIM: case K90_USAGE_LIGHT_MEDIUM: case K90_USAGE_LIGHT_BRIGHT: drvdata->backlight.brightness = (usage->hid & HID_USAGE) - K90_USAGE_LIGHT; break; default: break; } return 0; } static int k90_input_mapping(struct hid_device *dev, struct hid_input *input, struct hid_field *field, struct hid_usage *usage, unsigned long **bit, int *max) { int gkey; gkey = k90_usage_to_gkey(usage->hid & HID_USAGE); if (gkey != 0) { hid_map_usage_clear(input, usage, bit, max, EV_KEY, k90_gkey_map[gkey - 1]); return 1; } if ((usage->hid & HID_USAGE) >= K90_USAGE_SPECIAL_MIN && (usage->hid & HID_USAGE) <= K90_USAGE_SPECIAL_MAX) return -1; return 0; } static const struct hid_device_id k90_devices[] = { { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, USB_DEVICE_ID_CORSAIR_K90) }, {} }; MODULE_DEVICE_TABLE(hid, k90_devices); static struct hid_driver k90_driver = { .name = "k90", .id_table = k90_devices, .probe = k90_probe, .event = k90_event, .remove = k90_remove, .input_mapping = k90_input_mapping, }; static int __init k90_init(void) { return hid_register_driver(&k90_driver); } static void k90_exit(void) { hid_unregister_driver(&k90_driver); } module_init(k90_init); module_exit(k90_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Clement Vuchener"); MODULE_DESCRIPTION("HID driver for Corsair Vengeance K90 Keyboard");

3 3

What is the proper Linux suspend / resume kernel reentry point when the processor is powered down and back up
by John McCaskill Sept. 3, 2015

Sept. 3, 2015

I am working on expanding the suspend and resume capability for Linux running on a Xilinx Zynq Soc that has dual ARM A9s using the Xilinx 2014.4 PetaLinux distribution that uses the 3.17 kernel. The distribution currently supports suspend and resume without removing power to the processors. I am working on expanding the support to include removing power to the processors while the DDR memory is in self refresh mode, then performing a warm boot and having the first stage boot loader (FSBL) hand control back to the Linux kernel in the correct spot to continue with the resume process. I am looking for what routine to have the first stage boot loader call. I think it might be cpu_resume in arch/arm/kernel/sleep.S, but I am not sure and would like to verify that it is the correct routine to be calling. I am jumping to this from the FSBL after a suspend and warm boot, and single stepping through the code in a debugger. It gets to the end of this routine, but the debugger looses connection near the end of that routine shortly after this instruction is executed: ARM( ldmia r0!, {r1, sp, pc} ) In an effort to see if this is the correct entry point, I have modified pm.c in arch/arm/mach-zynq.c to call soft_restart(virt_to_phys(cpu_resume)) just after the resume has happened in the case where the processors are not powered off, but are woken back up with an interrupt. The soft_restart routine turns off the MMUs and clears the caches, and I am using it to get the processors into a similar state as to what they would be in if they had been power cycled. The cpu_resume routine expects to be called with cache and MMU off. This test mostly works, and gets much further than calling cpu_resume from the FSBL. It gets out of assembly code, and back into C, and is printing messages. The cpu_resume routine expects to be called with cache and MMU off. I have read the Documentation/power/devices.txt file, and anything else I could find. I have already done a version of this that uses the no OS flow to put the DDR into self refresh and power cycle the processors, and tested it on hardware. That flow does not use virtual memory. I have looked for other code that does this, but since the code performing the warm boot is device firmware and not kenel code I have not found an example yet. Is cpu_resume the correct renentry point for resuming after a suspend? Can anyone point me to an example I can look at? Thank you in advance, John McCaskill

2 1

EditorsGroup
by Kris Borer Sept. 2, 2015

Sept. 2, 2015

Hello, I would like to make some edits to the wiki. Would someone add KrisBorer to the EditorsGroup? Thanks, Kris

1 0

MADV_ZERO
by Robert Nagy Sept. 1, 2015

Sept. 1, 2015

I have recently switched over to Linux after encountering an issue that seems unsolvable in Windows with the hope of finding a solution in Linux. Basically what I need to achieve is IPC persisted to a huge file. I’m doing this currently by memory-mapping a huge backing file and always sequentially writing to the file in a circular fashion 24/7. However, this has some major throughput issues since overwriting pages will always cause a page-faults, even if entire pages are overwritten, which totally trashes disk performance. Basically I would need a flag for madvice (e.g. MADV_ZERO) with similar functionality to FALLOC_FL_ZERO_RANGE so that I would get much faster zero fill page faults instead. The closest I’ve come is to use MADV_REMOVE before overwriting the range, however, that is a suboptimal as it will from my understanding fragment the backing file and potentially degrade performance over time. What I’d like to be able to do is something like: int mm_fast_write(void* dst, void* src, size_t length) { if (dst & ~PAGE_MASK) return -EINVAL; if (src & ~PAGE_MASK) return -EINVAL; if (length & ~PAGE_MASK) return -EINVAL; madvice(ptr, len, MADV_ZERO); memcpy(ptr, src, len); madvice(ptr, len, MADV_DONTNEED); // Might not do anything without msync? return 0; } Is it possible to implement or emulate something like MADV_ZERO in user mode? Or should I look into modifying the kernel? I believe it could be implemented based on madvice_remove by simply replacing the FALLOC_FL_PUNCH_HOLE flag with FALLOC_FL_ZERO_RANGE?

1 0

Re: [PATCH v2 0/3] SysFS driver for QEMU fw_cfg device
by Gabriel L. Somlo Sept. 1, 2015

Sept. 1, 2015

Hi Christopher, On Wed, Aug 26, 2015 at 02:15:03PM -0400, Christopher Covington wrote: > On 08/19/2015 04:49 PM, Gabriel L. Somlo wrote: > > On Wed, Aug 19, 2015 at 11:42:02AM +0200, Ard Biesheuvel wrote: > >> On 19 August 2015 at 11:38, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> wrote: > >>> From: "Gabriel L. Somlo" <somlo(a)cmu.edu> > >>>> Several different architectures supported by QEMU are set up with a > >>>> "firmware configuration" (fw_cfg) device, used to pass configuration > >>>> "blobs" into the guest by the host running QEMU. > >>>> > >>>> Historically, these config blobs were mostly of interest to the guest > >>>> BIOS, but since QEMU v2.4 it is possible to insert arbitrary blobs via > >>>> the command line, which makes them potentially interesting to userspace > >>>> (e.g. for passing early boot environment variables, etc.). > >>>> > >>> > >>> Does 'potentially interesting' mean you have a use case? Could you elaborate? > > > > My personal one would be something like: > > > > cat > guestinfo.txt << EOT > > KEY1="val1" > > KEY2="val2" > > ... > > EOT > > > > qemu-system-x86_64 ... -fw-cfg name="opt/guestinfo",file=./guestinfo.txt ... > > > > Then, from inside the guest: > > > > . /sys/firmware/qemu_fw_cfg/by_name/opt/guestinfo/raw > > > > do_something_with $KEY1 $KEY2 > > ... > > > > But I'm thinking this is only one of the many positive things one > > could do with the ability to access random host-supplied blobs from > > guest userspace :) > > I do this with kernel parameters: > > host: > qemu-system-aarch64 -append="KEY1=val1 KEY2=val2" > > guest: > KEY1=`sed -nr s/.*KEY1=([^ ]+).*/\1/ /proc/cmdline` > KEY2=`sed -nr s/.*KEY2=([^ ]+).*/\1/ /proc/cmdline` > > do_something_with $KEY1 $KEY2 > > In practice it's just script=hostfile, where hostfile is available to the > guest via a 9P passthrough filesystem mount. > > While quite architecture specific, I've also previously used an > "angel-cmdline" tool for similar purposes. Peter's recent semihosting patches > support such a tool for AArch64. (On AArch32 upstream QEMU disallows > semihosting from userspace.) > > Before I had 9P on all the simulators I regularly ran, I used a semihosting > based "angel-load" tool. Someone (maybe it was you) did suggest this during an early thread on the QEMU dev list. I had considered this, then thought about piggybacking on smbios (e.g. the type 40 "additional information" table), but then realized "wait, smbios is currently being inserted into the guest via fw_cfg, so maybe direct fw_cfg blob transfer *is* the most asynchronous and out-of-band way I can do this... :) True, writing a fw_cfg driver is still Linux-specific (leaves out Windows, which is something I still care about), but dumping a fw_cfg blob using 'cat' or 'cp' on linux has a certain appeal :) Yeah, the immediate use case I have personally can be worked around with kernel command line args, in a slightly less out-of-band, but still quite serviceable way. I'm thinking a fw_cfg driver is just a flexible way to make other use cases possible in a (IMHO) neat and clean way... Plus, it got me to learn about kobjects, now studying DTs on ARM, so it's fun ;) Thanks, --Gabriel

1 0

line wrap error
by punit vara Sept. 1, 2015

Sept. 1, 2015

Hi I am new to kernel development .I want to submit patch but I checked my patch it showed ERROR: patch seems to be corrupt (line wrapped?) how to remove this error ? can any one help.

2 1