January 2021 - kernelnewbies@kernelnewbies.org

Re: Scheduler benchmarks
by Muni Sekhar April 29, 2021

April 29, 2021

On Tue, Aug 18, 2020 at 11:45 PM peter enderborg <peter.enderborg(a)sony.com> wrote: > > On 8/18/20 7:53 PM, Muni Sekhar wrote: > > On Tue, Aug 18, 2020 at 11:06 PM Greg KH <greg(a)kroah.com> wrote: > >> On Tue, Aug 18, 2020 at 11:01:35PM +0530, Muni Sekhar wrote: > >>> On Tue, Aug 18, 2020 at 10:44 PM Greg KH <greg(a)kroah.com> wrote: > >>>> On Tue, Aug 18, 2020 at 10:24:13PM +0530, Muni Sekhar wrote: > >>>>> On Tue, Aug 18, 2020 at 8:06 PM Greg KH <greg(a)kroah.com> wrote: > >>>>>> On Tue, Aug 18, 2020 at 08:00:11PM +0530, Muni Sekhar wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> I’ve two identical Linux systems with only kernel differences. > >>>>>> What are the differences in the kernels? > >>>> You didn't answer this question, is this the same kernel source being > >>>> compared here? Same version? Same compiler? Everything identical? > >>> Both systems are having exactly the same hardware configuration. > >>> Compiler and kernel versions are different. One system has Ubuntu > >>> 16.04.4 LTS(4.4.0-66-generic kernel with gcc version 5.4.0) kernel and > >>> the other one has Ubuntu 18.04.4 LTS(4.15.0-91-generic kernel with gcc > >>> version 7.5.0). > >> Those are _very_ different kernel versions, with many years and tens of > >> thousands of different changes between them. > >> > >> Hopefully the newer kernel is faster, so just stick with that :) > > But unfortunately the newer kernel is very slow, that is the reason > > for starting this investigation :) > > Any type of help, and guidelines to dive deeper will be highly appreciated. > > On the 4.4 kernel you dont have > > +CONFIG_RETPOLINE=y > +CONFIG_INTEL_RDT=y Thanks! That is helpful. Yes, I see 4.4 kernel don't have the above two config options. What analysis can be done to narrow down the root cause? Any example of reference could be helpful to understand. > > And your base is very different two. > > Try to use mainline on both system and see. > > You can also use the same base kernel version from ubuntu and > > run your test. > > > >> greg k-h > > > > > -- Thanks, Sekhar

6 6

UDP implementation and the MSG_MORE flag
by Oliver Graute Feb. 3, 2021

Feb. 3, 2021

Hello, we observe some unexpected behavior in the UDP implementation of the linux kernel. Some UDP packets send via the loopback interface are dropped in the kernel on the receive side when using sendto with the MSG_MORE flag. Every drop increases the InCsumErrors in /proc/self/net/snmp. Some example code to reproduce it is appended below. In the code we tracked it down to this code section. ( Even a little further but its unclear to me wy the csum() is wrong in the bad case) udpv6_recvmsg() ... if (checksum_valid || udp_skb_csum_unnecessary(skb)) { if (udp_skb_is_linear(skb)) err = copy_linear_skb(skb, copied, off, &msg->msg_iter); else err = skb_copy_datagram_msg(skb, off, msg, copied); } else { err = skb_copy_and_csum_datagram_msg(skb, off, msg); if (err == -EINVAL) { goto csum_copy_err; } } ... Perhaps someone with deeper knowledge can comment on this and can explain us the reason of this behavior. Best regards, Oliver udp-send.c #include <arpa/inet.h> #include <errno.h> #include <fcntl.h> #include <netinet/in.h> #include <poll.h> #include <signal.h> #include <stdbool.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/socket.h> #include <sys/stat.h> #include <sys/types.h> #include <sys/un.h> #include <unistd.h> #define BUFFSIZE 512*1024 int main(int argc, char** argv) { int fd = 0; int port = 0; char *buffer; struct sockaddr_in addr; ssize_t addrlen = 0; if(argc == 2) { port = atoi(argv[1]); } else { port = 4711; } fd = socket(PF_INET, SOCK_DGRAM, 0); addr.sin_family = AF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = inet_addr("127.0.0.1"); addrlen = sizeof(addr); buffer = malloc(BUFFSIZE); if (!buffer) { return 0; } printf("\nsending BROKEN segmented testdata on local port %i \n", port); snprintf(buffer, BUFFSIZE, "start-data {\n"); sendto(fd, buffer, strlen(buffer), MSG_MORE, (struct sockaddr *) &addr, addrlen); snprintf(buffer, BUFFSIZE, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"); sendto(fd, buffer, strlen(buffer), MSG_MORE, (struct sockaddr *) &addr, addrlen); snprintf(buffer, BUFFSIZE, "}\n"); sendto(fd, buffer, strlen(buffer), 0, (struct sockaddr *) &addr, addrlen); printf("\nsending VALID segmented testdata on local port %i \n", port); snprintf(buffer, BUFFSIZE, "start-data {\n"); sendto(fd, buffer, strlen(buffer), MSG_MORE, (struct sockaddr *) &addr, addrlen); snprintf(buffer, BUFFSIZE, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"); sendto(fd, buffer, strlen(buffer), MSG_MORE, (struct sockaddr *) &addr, addrlen); snprintf(buffer, BUFFSIZE, "}\n"); sendto(fd, buffer, strlen(buffer), 0, (struct sockaddr *) &addr, addrlen); printf("\nsending VALID unsegmented testdata on local port %i \n", port); snprintf(buffer, BUFFSIZE, "start-data {\n"); snprintf(buffer + strlen(buffer), BUFFSIZE - strlen(buffer), "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n"); snprintf(buffer+ strlen(buffer), BUFFSIZE - strlen(buffer), "}\n"); sendto(fd, buffer, strlen(buffer), 0, (struct sockaddr *) &addr, addrlen); free(buffer); return 0; } ------- udp-receive.c #include <arpa/inet.h> #include <errno.h> #include <fcntl.h> #include <netinet/in.h> #include <poll.h> #include <signal.h> #include <stdbool.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/socket.h> #include <sys/stat.h> #include <sys/types.h> #include <sys/un.h> #include <unistd.h> int main(int argc, char** argv) { int fd = 0; int arg = 0; int ret = 0; struct sockaddr_in addr; ssize_t addrlen = 0; int port = 0; char *buffer; char *printbuffer; int recvlen = 0; if(argc == 2) { port = atoi(argv[1]); } else { port = 4711; } fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); addr.sin_family = AF_INET; addr.sin_port = htons(port); addr.sin_addr.s_addr = inet_addr("0.0.0.0"); addrlen = sizeof(addr); buffer = malloc(65536); if (!buffer) { return 0; } printbuffer = malloc(65537); if (!printbuffer) { return 0; } if(fd) { printf("\nbinding to local port %i \n", port); //bind ret = bind(fd, (struct sockaddr *)&addr, addrlen); printf("result error %i, errno %i\n", ret, errno); do { recvlen = recvfrom(fd, buffer, 65536, 0, NULL, NULL); if (recvlen >0) { printf("\nreceived %i bytes of data:\n", recvlen); memset(printbuffer, 0, 65537); memcpy(printbuffer, buffer, recvlen); printf("%s\n", printbuffer); } else if(recvlen < 0) { printf("\n receive error %i, errno %i\n", recvlen, errno); } } while(1); close(fd); } else { printf("\nerror creating socket\n"); } free(buffer); free(printbuffer); return 0; }

2 1

'-D' 'KBUILD_MODSYM=main - like KBUILD_MODNAME, without the quotes ?
by jim.cromie＠gmail.com Jan. 29, 2021

Jan. 29, 2021

hi folks, In my hacking, Im finding this useful. it adds a version of KBUILD_MODNAME without the quotes --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -119,7 +119,7 @@ target-stem = $(basename $(patsubst $(obj)/%,%,$@)) # end up in (or would, if it gets compiled in) name-fix = $(call stringify,$(subst $(comma),_,$(subst -,_,$1))) basename_flags = -DKBUILD_BASENAME=$(call name-fix,$(basetarget)) -modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) +modname_flags = -DKBUILD_MODNAME=$(call name-fix,$(modname)) -DKBUILD_MODSYM=$(modname) Im suspicious however, KBUILD_MODNAME has the quotes for a reason; probably robustness at some level. Afterall, __stringify() could add the quotes for cases where it was needed. If there was an __unstringify_token( ) I could remove this Makefile hack, is such a construct possible ?

2 5

Doubt on show() function of sysfs attribute
by Mohana Datta Yelugoti Jan. 27, 2021

Jan. 27, 2021

Hello everyone, I am going through Documentation/filesystems/sysfs.rst. It says that sysfs allocates a buffer of size PAGE_SIZE and passes it to the show/store functions of the attribute. On read(), the show() method should fill the entire buffer[0]. The document also says that sysfs_emit() and sysfs_emit_at() are the preferred function calls in show() function when formatting the value to be returned to the user space [1]. I checked the sysfs_emit() function definition. sysfs_emit() -> vscnprintf() -> vsnprintf() is the function series. (-> = calls) In the vsnprintf() function, i found that only in the case of (start + size > end) the buffer is completely filled, in the other case, that's not the case [2]. Isn't this contradictory to what the sysfs.rst says? (that entire buffer should be filled) Can you please help me understand what i am missing here? Thank you for your time. Cheers, ymdatta. [0]: https://elixir.bootlin.com/linux/latest/source/Documentation/filesystems/sy… [1]: https://elixir.bootlin.com/linux/latest/source/Documentation/filesystems/sy… [2]: https://elixir.bootlin.com/linux/latest/source/lib/vsprintf.c#L2689

4 4

new module is not compiled
by Dario Pagani Jan. 26, 2021

Jan. 26, 2021

Hello, I'm trying to add my hid driver, `hid-tminit.c', to Linux Kernel. I've added the C file in the folder `drivers/hid/` and then I added `config HID_TMINIT' to `Kconfig' and `obj-$(CONIFG_HID_TMINIT) += hid-tminit.o' to the Makefile. Finally I've used `make menuconfig' to enable my driver, which added `CONFIG_HID_TMINIT=m' to my `.config'. But when running `make' or `make M=drivers/hid' all C files are built but mine! Running `make drivers/hid/hid-tminit.o' gives the no rule error, localizated in my system language: `Nessuna regola per generare l'obiettivo «drivers/hid/hid-tminit.o». Arresto.'. What am I doing wrong? --- drivers/hid/Kconfig | 14 ++ drivers/hid/Makefile | 1 + drivers/hid/hid-quirks.c | 3 + drivers/hid/hid-tminit.c | 368 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 386 insertions(+) create mode 100644 drivers/hid/hid-tminit.c diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 09fa75a2b289..2afc63b8d37e 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -1037,6 +1037,20 @@ config THRUSTMASTER_FF a THRUSTMASTER Dual Trigger 3-in-1 or a THRUSTMASTER Ferrari GT Rumble Force or Force Feedback Wheel. +config HID_TMINIT + tristate "Thrustmaster FFB Wheel initialization" + depends on USB_HID + help + Say Y here if you want to enable support for properly initialize some + Thrustmaster wheels that appear like a "Thrustmaster FFB Wheel" + (0x044f:0xb65d) to the host. + + Currently supporting: + - T150RS + - T300RS + - T300 Ferrari Alcantara Edition + - T500RS + config HID_UDRAW_PS3 tristate "THQ PS3 uDraw tablet" depends on HID diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 014d21fe7dac..51cd91040081 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -112,6 +112,7 @@ obj-$(CONFIG_HID_STEELSERIES) += hid-steelseries.o obj-$(CONFIG_HID_SUNPLUS) += hid-sunplus.o obj-$(CONFIG_HID_GREENASIA) += hid-gaff.o obj-$(CONFIG_HID_THRUSTMASTER) += hid-tmff.o +obj-$(CONIFG_HID_TMINIT) += hid-tminit.o obj-$(CONFIG_HID_TIVO) += hid-tivo.o obj-$(CONFIG_HID_TOPSEED) += hid-topseed.o obj-$(CONFIG_HID_TWINHAN) += hid-twinhan.o diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c index d9ca874dffac..5b97fa2ebb9e 100644 --- a/drivers/hid/hid-quirks.c +++ b/drivers/hid/hid-quirks.c @@ -662,6 +662,9 @@ static const struct hid_device_id hid_have_special_driver[] = { { HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb654) }, { HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb65a) }, #endif +#if IS_ENABLED(CONFIG_HID_TMINIT) + { HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb65d) }, +#endif #if IS_ENABLED(CONFIG_HID_TIVO) { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_TIVO, USB_DEVICE_ID_TIVO_SLIDE_BT) }, { HID_USB_DEVICE(USB_VENDOR_ID_TIVO, USB_DEVICE_ID_TIVO_SLIDE) }, diff --git a/drivers/hid/hid-tminit.c b/drivers/hid/hid-tminit.c new file mode 100644 index 000000000000..0ce327a23a45 --- /dev/null +++ b/drivers/hid/hid-tminit.c @@ -0,0 +1,368 @@ +// SPDX-License-Identifier: GPL-2.0 +/** + * When connected to the machine, the Thrustmaster wheels appear as + * a «generic» hid gamepad called "Thrustmaster FFB Wheel". + * + * When in this mode not every functionality of the wheel, like the force feedback, + * are available. To enable all functionalities of a Thrustmaster wheel we have to send + * to it a specific USB CONTROL request with a code different for each wheel. + * + * This driver tries to understand which model of Thrustmaster wheel the generic + * "Thrustmaster FFB Wheel" really is and then sends the appropriate control code. + * + * Copyright (c) 2020-2021 Dario Pagani <dario.pagani.146%2Blinuxk(a)gmail.com> + * Copyright (c) 2020-2021 Kim Kuparinen <kimi.h.kuparinen(a)gmail.com> + */ +#include <linux/hid.h> +#include <linux/usb.h> +#include <linux/input.h> +#include <linux/slab.h> +#include <linux/module.h> + +/** + * These interrupts are used to prevent a nasty crash when initializing the + * T300RS. Used in tminit_interrupts(). + */ +static const u8 setup_0[] = { 0x42, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; +static const u8 setup_1[] = { 0x0a, 0x04, 0x90, 0x03, 0x00, 0x00, 0x00, 0x00 }; +static const u8 setup_2[] = { 0x0a, 0x04, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x00 }; +static const u8 setup_3[] = { 0x0a, 0x04, 0x12, 0x10, 0x00, 0x00, 0x00, 0x00 }; +static const u8 setup_4[] = { 0x0a, 0x04, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00 }; +static const u8 *const setup_arr[] = { setup_0, setup_1, setup_2, setup_3, setup_4 }; +static const unsigned int setup_arr_sizes[] = { + ARRAY_SIZE(setup_0), + ARRAY_SIZE(setup_1), + ARRAY_SIZE(setup_2), + ARRAY_SIZE(setup_3), + ARRAY_SIZE(setup_4) +}; +/** + * This struct contains for each type of + * Thrustmaster wheel + * + * Note: The values are stored in the CPU + * endianess, the USB protocols always use + * little endian; the macro cpu_to_le[BIT]() + * must be used when preparing USB packets + * and vice-versa + */ +struct th_wheel_info { + uint16_t wheel_type; + + /** See when the USB control out packet is prepared... + * @TODO The TMX seems to require multiple control codes to switch. + */ + uint16_t switch_value; + + char const *const wheel_name; +}; + +/** + * All wheel I know. TO BE TESTED + */ +static const struct th_wheel_info th_wheels_infos[] = { + {0x0306, 0x0006, "Thrustmaster T150RS"}, + {0x0206, 0x0005, "Thrustmaster T300RS"}, + {0x0204, 0x0005, "Thrustmaster T300 Ferrari Alcantara Edition"}, + {0x0002, 0x0002, "Thrustmaster T500RS"}, + {0x0407, 0x0001, "Thrustmaster TMX"} +}; + +static const uint8_t th_wheels_infos_length = 5; + +/** + * This structs contains (in little endian) the response data + * of the wheel to the request 73 + * + * A sufficient research to understand what each field does is not + * beign conducted yet. The position and meaning of fields are a + * just a very optimistic guess based on instinct.... + */ +struct __packed tm_wheel_response +{ + /** + * Seems to be the type of packet + * - 0x0049 if is data.a (15 bytes) + * - 0x0047 if is data.b (7 bytes) + */ + uint16_t type; + + union { + struct __packed { + uint16_t field0; + uint16_t field1; + /** + * Seems to be the model code of the wheel + * Read table thrustmaster_wheels to values + */ + uint16_t model; + + uint16_t field2; + uint16_t field3; + uint16_t field4; + uint16_t field5; + } a; + struct __packed { + uint16_t field0; + uint16_t field1; + uint16_t model; + } b; + } data; +}; + +struct tm_wheel { + struct usb_device *usb_dev; + struct urb *urb; + + struct usb_ctrlrequest *model_request; + struct tm_wheel_response *response; + + struct usb_ctrlrequest *change_request; +}; + +/** The control packet to send to wheel */ +static const struct usb_ctrlrequest model_request = { + .bRequestType = 0xc1, + .bRequest = 73, + .wValue = 0, + .wIndex = 0, + .wLength = cpu_to_le16(0x0010) +}; + +static const struct usb_ctrlrequest change_request = { + .bRequestType = 0x41, + .bRequest = 83, + .wValue = 0, // Will be filled by the driver + .wIndex = 0, + .wLength = 0 +}; + +/** + * On some setups initializing the T300RS crashes the kernel, + * these interrupts fix that particular issue. So far they haven't caused any + * adverse effects in other wheels. + */ +static void tminit_interrupts(struct hid_device *hdev) +{ + int ret, trans, i, b_ep; + u8 *send_buf = kmalloc(256, GFP_KERNEL); + struct usb_host_endpoint *ep; + struct device *dev = &hdev->dev; + struct usb_interface *usbif = to_usb_interface(dev->parent); + struct usb_device *usbdev = interface_to_usbdev(usbif); + + if (!send_buf) { + hid_err(hdev, "failed allocating send buffer\n"); + return; + } + + ep = &usbif->cur_altsetting->endpoint[1]; + b_ep = ep->desc.bEndpointAddress; + + for (i = 0; i < ARRAY_SIZE(setup_arr); ++i) { + memcpy(send_buf, setup_arr[i], setup_arr_sizes[i]); + + ret = usb_interrupt_msg(usbdev, + usb_sndintpipe(usbdev, b_ep), + send_buf, + setup_arr_sizes[i], + &trans, + USB_CTRL_SET_TIMEOUT); + + if (ret) { + hid_err(hdev, "setup data couldn't be sent\n"); + return; + } + } + + kfree(send_buf); +} + +static void tminit_change_handler(struct urb *urb) +{ + struct hid_device *hdev = urb->context; + + // The wheel seems to kill himself before answering the host and therefore is violating the USB protocol... + if (urb->status == 0 || urb->status == -EPROTO || urb->status == -EPIPE) + hid_info(hdev, "Success?! The wheel should have been initialized!\n"); + else + hid_warn(hdev, "URB to change wheel mode seems to have failed with error %d\n", urb->status); +} + +/** + * Called by the USB subsystem when the wheel respons to our request + * to get [what it seems to be] the wheel's model. + * + * If the model id is recognized then we send an opportune USB CONTROL REQUEST + * to switch the wheel to its full capabilities + */ +static void tminit_model_handler(struct urb *urb) +{ + struct hid_device *hdev = urb->context; + struct tm_wheel *tm_wheel = hid_get_drvdata(hdev); + uint16_t model = 0; + int i, ret; + const struct th_wheel_info *twi = 0; + + if (urb->status) { + hid_err(hdev, "URB to get model id failed with error %d\n", urb->status); + return; + } + + if (tm_wheel->response->type == cpu_to_le16(0x49)) + model = le16_to_cpu(tm_wheel->response->data.a.model); + else if (tm_wheel->response->type == cpu_to_le16(0x47)) + model = le16_to_cpu(tm_wheel->response->data.b.model); + else { + hid_err(hdev, "Unknow packet type 0x%x, unable to proceed further with wheel init\n", tm_wheel->response->type); + return; + } + + for (i = 0; i < th_wheels_infos_length && !twi; i++) + if (th_wheels_infos[i].wheel_type == model) + twi = th_wheels_infos + i; + + if (twi) + hid_info(hdev, "Wheel with model id 0x%x is a %s\n", model, twi->wheel_name); + else { + hid_err(hdev, "Unknown wheel's model id 0x%x, unable to proceed further with wheel init\n", model); + return; + } + + tm_wheel->change_request->wValue = cpu_to_le16(twi->switch_value); + usb_fill_control_urb( + tm_wheel->urb, + tm_wheel->usb_dev, + usb_sndctrlpipe(tm_wheel->usb_dev, 0), + (char *)tm_wheel->change_request, + 0, 0, // We do not expect any response from the wheel + tminit_change_handler, + hdev + ); + + ret = usb_submit_urb(tm_wheel->urb, GFP_ATOMIC); + if (ret) + hid_err(hdev, "Error %d while submitting the change URB. I am unable to initialize this wheel...\n", ret); +} + +static void tminit_remove(struct hid_device *hdev) +{ + struct tm_wheel *tm_wheel = hid_get_drvdata(hdev); + + usb_kill_urb(tm_wheel->urb); + + kfree(tm_wheel->response); + kfree(tm_wheel->model_request); + usb_free_urb(tm_wheel->urb); + kfree(tm_wheel); + + hid_hw_stop(hdev); +} + +/** + * Function called by HID when a hid Thrustmaster FFB wheel is connected to the host. + * This function starts the hid dev, tries to allocate the tm_wheel data structure and + * finally send an USB CONTROL REQUEST to the wheel to get [what it seems to be] its + * model type. + */ +static int tminit_probe(struct hid_device *hdev, const struct hid_device_id *id) +{ + int ret = 0; + struct tm_wheel *tm_wheel = 0; + + ret = hid_parse(hdev); + if (ret) { + hid_err(hdev, "parse failed with error %d\n", ret); + goto error0; + } + + ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT & ~HID_CONNECT_FF); + if (ret) { + hid_err(hdev, "hw start failed with error %d\n", ret); + goto error0; + } + + // Now we allocate the tm_wheel + tm_wheel = kzalloc(sizeof(struct tm_wheel), GFP_KERNEL); + if (!tm_wheel) { + ret = -ENOMEM; + goto error1; + } + + tm_wheel->urb = usb_alloc_urb(0, GFP_ATOMIC); + if (!tm_wheel->urb) { + ret = -ENOMEM; + goto error2; + } + + tm_wheel->model_request = kzalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL); + if (!tm_wheel->model_request) { + ret = -ENOMEM; + goto error3; + } + memcpy(tm_wheel->model_request, &model_request, sizeof(struct usb_ctrlrequest)); + + tm_wheel->response = kzalloc(sizeof(struct tm_wheel_response), GFP_KERNEL); + if (!tm_wheel->response) { + ret = -ENOMEM; + goto error4; + } + + tm_wheel->change_request = kzalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL); + if (!tm_wheel->model_request) { + ret = -ENOMEM; + goto error5; + } + memcpy(tm_wheel->change_request, &change_request, sizeof(struct usb_ctrlrequest)); + + tm_wheel->usb_dev = interface_to_usbdev(to_usb_interface(hdev->dev.parent)); + hid_set_drvdata(hdev, tm_wheel); + + tminit_interrupts(hdev); + + usb_fill_control_urb( + tm_wheel->urb, + tm_wheel->usb_dev, + usb_rcvctrlpipe(tm_wheel->usb_dev, 0), + (char *)tm_wheel->model_request, + tm_wheel->response, + sizeof(struct tm_wheel_response), + tminit_model_handler, + hdev + ); + + ret = usb_submit_urb(tm_wheel->urb, GFP_ATOMIC); + if (ret) + hid_err(hdev, "Error %d while submitting the URB. I am unable to initialize this wheel...\n", ret); + + return ret; + +error5: kfree(tm_wheel->response); +error4: kfree(tm_wheel->model_request); +error3: usb_free_urb(tm_wheel->urb); +error2: kfree(tm_wheel); +error1: hid_hw_stop(hdev); +error0: + return ret; +} + +static const struct hid_device_id tminit_devices[] = { + { HID_USB_DEVICE(0x044f, 0xb65d)}, + {} +}; + +MODULE_DEVICE_TABLE(hid, tminit_devices); + +static struct hid_driver tminit_driver = { + .name = "hid-tminit", + .id_table = tminit_devices, + .probe = tminit_probe, + .remove = tminit_remove, +}; + +module_hid_driver(tminit_driver); + +MODULE_AUTHOR("Dario Pagani <dario.pagani.146%2Blinuxk(a)gmail.com>"); +MODULE_LICENSE("GPL"); +MODULE_DESCRIPTION("Driver to initialize some steering wheel joysticks from Thrustmaster"); + -- 2.25.1

2 2

/proc/cpuinfo not showing all info
by Pankaj Vinodrao Joshi Jan. 19, 2021

Jan. 19, 2021

Hi, i am using sifive's u540, RISCV64 with custom kernel 5.10.2 and i am trying to get all hardware information with the help of /proc/cpuinfo but i am not able get all information i need. i am attaching current /proc/cpuinfo rocessor : 0 hart : 2 isa : rv64imafdc mmu : sv39 uarch : sifive,u54-mc but i am expecting following kind of output processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 142 model name : Intel(R) Core(TM) i3-7020U CPU @ 2.30GHz stepping : 9 microcode : 0xde cpu MHz : 700.027 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes Can someone suggest me how i can print all info with /proc/cpuinfo ?? Thanks!

3 6

device tree or ACPI table? and x0 register in arm64 kernel start
by ckim＠etri.re.kr Jan. 16, 2021

Jan. 16, 2021

Hello, I saw the head.S file for arm64 assumes the x0 register contains the address of the device tree (dtb). But some systems use ACPI table for handing hardware configuration to the kernel. If the system firmware and bootloader uses UEFI and ACPI, (and bootloader like grub), does the bootloader set x0 with dtb too? In this case x0 is not use? Chan Kim

1 0

How to join other mailing lists
by bigbird2444＠163.com Jan. 15, 2021

Jan. 15, 2021

5 5

linker script hack - can it be made to work ?
by jim.cromie＠gmail.com Jan. 14, 2021

Jan. 14, 2021

Im attempting to conditionally link an input section. if the just linked similarly named section wasnt empty. __start___dyndbg = .; \ _ = .; \ \ KEEP(*(__dyndbg (.-_)? gnu.linkonce.d.__dyndbg)) \ __stop___dyndbg = .; it gives me an unspecified linker syntax error ld:./arch/x86/kernel/vmlinux.lds:46: syntax error its pretty clear that this experiment is failing, is there another way to do this ?

1 0

None
by ‪bigbird2444＠163.com‬ Jan. 14, 2021

Jan. 14, 2021

2 1