June 2017 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

./include/linux/err.h:35:16: warning: dereference of noderef expression
by Charlemagne Lasse June 13, 2017

June 13, 2017

Hi, I have following code which generates a warning when compiling with "make C=1". ~~~~~~~ struct task_struct *kthread; kthread = kthread_create(xxxxx, yyyyy, "zzzzz"); if (IS_ERR(kthread)) { ~~~~~~~ The warning is ./include/linux/err.h:35:16: warning: dereference of noderef expression And disappears when I remove the IS_ERR. How do I correctly work around this incorrect warning? Btw. I am using Debian stretch amd64. It seems like this is related to the __force used in the parameter list of IS_ERR. Removing it also removes the warning. If it is fixed in sparse's git then when will there be a new release of it? Greetings, Charlemagne Lasse

2 1

sched_wakeup_granularity_ns in CFS correctly designed or not?
by Rohith R June 12, 2017

June 12, 2017

Hi, I was working on the Linux CFS scheduler and came across this tuneable parameter called `sched_wakeup_granularity_ns`. The use of this goes as follows as described in [this paper](http://rouskas.csc. ncsu.edu/Publications/Conferences/ICC-SPS-2015.pdf) > This parameter controls the wake-up latency of a task, i.e., the amount of time it must lapse before it can preempt the current task. Further looking up on this parameter from [here](https://www. systutorials.com/239998/sched_min_granularity_ns-sched_ latency_ns-cfs-affect-timeslice-processes/) : > If the difference between the virtual run time of current running process and the virtual run time of preempting process is bigger than the virtual run time of sched_wakeup_granularity_ns (here, transfer sched_wakeup_granularity_ns to a virtual run time with preempting process’s weight), the preemption happens. The default value of this in my system is 2.5 milli seconds. My question : If a process with a deadline <= 2.5 ms comes at time another low priority process is executing then, it won't get its chance to execute because of this minimum granularity and will always miss its deadline. Am I right in my claim ? Why is the Linux kernel designed like that ? Of course we can set this parameter to 0 ms and re-compile the kernel, but don't tasks with deadlines of 2.5 ms occur frequently in day to day life ? Video decoders, sound processing apps, and other latency critical workloads ? - RR

2 5

Is there any way to save just the 'Kernel Hacking' subsection instead of entire .config
by Roman Storozhenko June 9, 2017

June 9, 2017

Hello everybody! As you know there is a great script "merge_config.sh". It allows to override a predefined set of .config keys with the values stored in a file. For example: scripts/kconfig/merge_config.sh -m -r .config ~/kernel/conf_mixins/.config_deb Now, I want to turn on all of the options in the "Kernel Hacking" submenu and save only that options to a separate file ".config_deb". But how can I do this? I see three options: 1) Do it manually checking the match between every option title in "Kernel Hacking" submenu and a key in .config. It is a hard way. 2) Turn off all debug options. Save them in one file. Turn on all debug options and save them to other file. Then make diff on these two files, format it and save to .config_deb. It is a better way, but not ideal. Is there any other ways to handle this task? Thanks in advance, Roman Storozhenko

1 0

Unable to wakeup suspended host with USB HID Composite Device
by Abdulhadi Mohamed June 8, 2017

June 8, 2017

Hi This is my first email using this mailing list but I could really use some help. I have connected a composite USB device running the 4.0 Linux kernel to a PC running Ubuntu. One of its functions is to act as a HID device for mouse and keyboard to control the host. However, an issue that I am currently encountering is that if the host (running Ubuntu 14.10) enters suspend mode, the composite USB device cannot wake it up however a normal connected USB mouse or keyboard on the same USB port can wake it up. Detailed lsusb information for my device is provided below. I think this feature is called remote wakeup, if so has it been implemented for the composite USB devices, specifically those emulating HID devices? Bus 003 Device 003: ID 1d6b:0001 Linux Foundation Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 0 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 3.18 iManufacturer 1 Evertz Microsystem Ltd. iProduct 2 Evertz TRXS10G Composite device iSerial 3 ev-53-trxs-10g-sn bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 226 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 4 Conf 1 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 120mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 2 Abstract (modem) bFunctionProtocol 1 AT-commands (v.25ter) iFunction 7 CDC Serial Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 5 CDC Abstract Control Model (ACM) CDC Header: bcdCDC 1.10 CDC Call Management: bmCapabilities 0x00 bDataInterface 1 CDC ACM: bmCapabilities 0x02 line coding and serial state CDC Union: bMasterInterface 0 bSlaveInterface 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 6 CDC ACM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 9 Mass Storage Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 11 HID Interface HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 59 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 13 HID Interface HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 46 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 15 HID Interface HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 106 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 4 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 17 HID Interface HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.01 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 69 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4

1 0

minimum commit id length when fixing a patch
by Kevin Wilson June 8, 2017

June 8, 2017

Hi, I want to send a patch to LKML fixing something wrong which was caused by other patch. Form what I understand, it is a good practice to mention the commit title and the commit ID. A commit ID is very long. My question is: when mentioning in my commit log the patch that caused the problem, what is the minimum commit id length which I should use when presenting the patch that caused the problem ? is such commit length is documented anywhere ? Regards, Kevin

4 7

tx path circular buffer
by Tobin C. Harding June 8, 2017

June 8, 2017

Hi, I am attempting to implement a circular buffer for the tx path of a networking driver. From my understanding this is something that is very common, yet I am struggling to find a clear way to do it. I have tried to read the source for ath6kl, brcmfmac without success. I have read Documentation/circular-buffers.txt and this seems like the solution however grep'ing drivers/net hints that this is not that common a way to solve this problem. Also I'm getting in knots with atomic_t types when copying the text document. Before I bore you with all my non-working code, does any one please know, off the top of their heads, a driver with simple-ish / nice clean implementation that I can learn from? thanks, Tobin.

2 2

How to use V4L2 dmafd with sendfile?
by Frank Smith June 7, 2017

June 7, 2017

2 2

Re: ks7010 firmware upload fail
by Tobin C. Harding June 6, 2017

June 6, 2017

On Mon, Jun 05, 2017 at 09:22:12AM +0200, Wolfram Sang wrote: > Tobin, > > > My question is should I be digging further into the MMC code or be doing > > something else with the driver code? > > So, you haven't found any branch that worked? No plain v4.9 or the > gen3-sdio branch from my tree? I have not tried cloning your tree. I am using the Rasperry Pi kernel source https://github.com/raspberrypi/linux which is v4.9.29 I checked out the last commit you made to the mainline then cross compiled the driver from within the Rpi tree, copied the module over to the Pi and insmod'd it. To debug I was making code changes on my desktop, re cross compiling the module and scp'ing it over (then rmmod'ing and insmod'ing the new module). I'll try using a vanilla 4.9 kernel, and if that fails I'll try cloning your tree. Thanks for getting back to me. Will report my progress. thanks, Tobin.

2 2

ks7010 firmware upload fail
by Tobin C. Harding June 5, 2017

June 5, 2017

Hi, I am attempting to test the ks7010 SIDO Wi-Fi driver (drivers/staging/ks7010/). Currently probing the driver fails because of a firmware upload error. I am seeking ideas on where to continue troubleshooting this issue. Test setup: - Spectec SDW-823 WIFI card (micro SD). - Raspberry Pi B 1 (kernel 4.9.29) breakout board connected via GPIO pins. - Driver code from current mainline (commit 453e102db531ac1ffa55f3e03c4907c063125859) (with additional debugging output calls). Debugging thus far: - define DEBUG in ks7010 and mmc makefiles (core, card, host). kernel messages from time of fail: [ 3746.903972] mmc1: starting CMD53 arg 94002004 flags 000001b5 [ 3746.903985] mmc1: blksz 4 blocks 1 flags 00000100 tsac 1000 ms nsac 0 [ 3746.904077] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000 [ 3746.904090] mmc1: 4 bytes transferred: 0 [ 3746.904114] mmc1: starting CMD53 arg 94000804 flags 000001b5 [ 3746.904126] mmc1: blksz 4 blocks 1 flags 00000100 tsac 1000 ms nsac 0 [ 3746.904180] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000 [ 3746.904189] mmc1: 4 bytes transferred: 0 [ 3746.912784] ks7010_upload_firmware: updated index to: 6000000 [ 3746.912816] mmc1: starting CMD53 arg 9e000080 flags 000001b5 [ 3746.912831] mmc1: blksz 512 blocks 128 flags 00000100 tsac 1000 ms nsac 0 [ 3746.916336] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000 [ 3746.916353] mmc1: 65536 bytes transferred: 0 [ 3746.916420] ks7010_upload_firmware: wrote to address 10000 (DATA_WINDOW) 65536 bytes [ 3746.916429] ks7010_sdio_data_compare: read 65536 bytes from address 10000 [ 3746.916436] debug messages from mmc/core are enabled [ 3746.916459] mmc1: starting CMD53 arg 1e000080 flags 000001b5 [ 3746.916472] mmc1: blksz 512 blocks 128 flags 00000200 tsac 1000 ms nsac 0 [ 3746.916575] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000 [ 3746.916588] mmc1: 0 bytes transferred: -84 [ 3746.920029] ks7010_sdio_read: sdio_memcpy_fromio() failed: -84 [ 3746.920100] ks7010: ERROR firmware load failed: 9 Briefly, firmware is uploaded to the card in chunks. Each chunk is read back from the card to verify the transfer. CMD53 can be seen to succeed when writing the first chunk to the card. ks7010_sdio_data_compare() is then called which calls ks7010_sdio_read() to read back the data written to the card. It is this call that fails. (CMD52 appears to be successful as well as CMD53 write). All function calls (including memory addresses on the card, and kernel buffer addresses) appear to be correct. Removing the call to ks7010_sdio_data_compare() leads to an MMC read error for each successive read (via CMD53) by the driver. My question is should I be digging further into the MMC code or be doing something else with the driver code? Any suggestions, no matter how simple, most appreciated. This is my first time digging into MMC and my first time really trying to trouble shoot a kernel issue. thanks, Tobin.

2 1

Fixing warnings
by srishti sharma June 2, 2017

June 2, 2017

Hey, Can we fix two warnings in a single patch ? Regards, Srishti

2 4