RE: Multi-touch USB weird response
>> Event: time 1627381396.770902, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), >> value 35023100 >> Event: time 1627381396.770902, -- SYN_REPORT >> Event: time 1627381396.780891, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), >> value 35029400 >> Event: time 1627381396.780891, -- SYN_REPORT >> Event: time 1627381396.789895, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), >> value 35035700 >> Event: time 1627381396.789895, -- SYN_REPORT >> Event: time 1627381396.798896, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), >> value 35041900 >> Event: time 1627381396.798896, -- SYN_REPORT >> Event: time 1627381396.807889, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), >> value 35048200 > >Looks like somebody's got a timer that pops every 0.01 seconds or so. >(looks closer to 0.0098 or so actually) >'git grep SYN_REPORT' tells me that these two files are a good place to start >reading: > >Documentation/input/multi-touch-protocol.rst >Documentation/input/event-codes.rst Thanks for the info! Yes I would like to know who is sending these packages. I'm sniffing the USB and I suspect the device in this edge situation is sending the same touch event every 8ms. Maybe a firmware bug... ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Multi-touch USB weird response
Hi all, I'm using a 5.8.x kernel and an USB multitouch device is reporting a weird response in some situations. I put a coin or some object in the left edge of the touch without entering the working area and then the next taps to the touch are ignored. With the evtest tool to get all the messages from multitouch I'm reading a lot of EV_MSC events with code MSC_TIMESTAMP. Is it correct? Where this events storm could come from? Maybe is it configurable some way? # evtest /dev/input/event4 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x2b7f product 0xd200 version 0x110 Input device name: "Advanced Silicon S.A. CoolTouch® System Interface" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 29660 Min0 Max32767 Resolution 106 Event code 1 (ABS_Y) Value 11404 Min0 Max32767 Resolution 188 Event code 47 (ABS_MT_SLOT) Value 0 Min0 Max9 Event code 53 (ABS_MT_POSITION_X) Value 0 Min0 Max32767 Resolution 106 Event code 54 (ABS_MT_POSITION_Y) Value 0 Min0 Max32767 Resolution 188 Event code 57 (ABS_MT_TRACKING_ID) Value 0 Min0 Max65535 Event type 4 (EV_MSC) Event code 5 (MSC_TIMESTAMP) Properties: Property type 1 (INPUT_PROP_DIRECT) Testing ... (interrupt to exit) Event: time 1627381396.770902, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35023100 Event: time 1627381396.770902, -- SYN_REPORT Event: time 1627381396.780891, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35029400 Event: time 1627381396.780891, -- SYN_REPORT Event: time 1627381396.789895, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35035700 Event: time 1627381396.789895, -- SYN_REPORT Event: time 1627381396.798896, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35041900 Event: time 1627381396.798896, -- SYN_REPORT Event: time 1627381396.807889, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35048200 Event: time 1627381396.807889, -- SYN_REPORT Event: time 1627381396.816893, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35054400 Event: time 1627381396.816893, -- SYN_REPORT Event: time 1627381396.825891, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35060700 Event: time 1627381396.825891, -- SYN_REPORT Event: time 1627381396.834905, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35067000 Event: time 1627381396.834905, -- SYN_REPORT Event: time 1627381396.843914, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35073300 Event: time 1627381396.843914, -- SYN_REPORT Event: time 1627381396.852890, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35079600 Event: time 1627381396.852890, -- SYN_REPORT Event: time 1627381396.861899, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35085900 Event: time 1627381396.861899, -- SYN_REPORT Event: time 1627381396.871900, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35092200 Event: time 1627381396.871900, -- SYN_REPORT Event: time 1627381396.880903, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35098500 Event: time 1627381396.880903, -- SYN_REPORT Event: time 1627381396.889894, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35104800 Event: time 1627381396.889894, -- SYN_REPORT Event: time 1627381396.898894, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 3500 Event: time 1627381396.898894, -- SYN_REPORT Event: time 1627381396.907897, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35117400 Event: time 1627381396.907897, -- SYN_REPORT Event: time 1627381396.916905, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35123700 Event: time 1627381396.916905, -- SYN_REPORT Event: time 1627381396.925887, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 3513 Event: time 1627381396.925887, -- SYN_REPORT Event: time 1627381396.934912, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35136300 Event: time 1627381396.934912, -- SYN_REPORT Event: time 1627381396.943900, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35142500 Event: time 1627381396.943900, -- SYN_REPORT Event: time 1627381396.953893, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35148800 Event: time 1627381396.953893, -- SYN_REPORT Event: time 1627381396.962898, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 35155100 Event: time
RE: USB resets
I've been able to stop the disconnecting loop. First I tried the usbcore.autosuspend=-1 guessing that an inactive period of time will send the device to some low power state, explaining the enumerating and disconnect loop with, but I had no luck. Then I force using the device with an udev rule running evtest --query $DEVNAME EV_KEY 0 and the disconnection disappears. Maybe it's an error in the tobis touchscreen controller code?? I would like to test if the behavior changes in full speed instead of high speed. Is there some way to downgrade the EHCI speed to full speed? Thanks! De: Greg KH Enviado: martes, 20 de abril de 2021 10:52 Para: Jorge Fernandez Monteagudo Cc: kernelnewbies@kernelnewbies.org Asunto: Re: USB resets On Tue, Apr 20, 2021 at 07:41:14AM +, Jorge Fernandez Monteagudo wrote: > >Bad hardware, the kernel can not cause a disconnect :( > > > >Do you have a flaky cable or underpowerd hub here? > > > > How many retries before the kernel decides to send a reset to a USB device? > After a reset, this device is ignored? The hub itself disconnects the device electronically, the kernel does not do that. When the device comes back, then it is initialized by the kernel, as the logs show, but then it is disconnected again. This really looks like broken hardware or electronic noise on the connection, the kernel can not cause electronic disconnects on a USB hub like this. good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: USB resets
>Bad hardware, the kernel can not cause a disconnect :( > >Do you have a flaky cable or underpowerd hub here? > How many retries before the kernel decides to send a reset to a USB device? After a reset, this device is ignored? Thanks! Jorge ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
USB resets
Hi all, I'm using an ancient 4.17.1 kernel and I'm seeing an weird USB behavior. A touchscreen device is been detected and disconnected in a 4 seconds pattern. # dmesg | grep 1.3.2[2.170041] usb 1-1.3.2: new full-speed USB device number 6 using ehci-pci [2.254868] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0001/input/input2 [2.254958] hid-multitouch 0003:29BD:4101.0001: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [6.776320] usb 1-1.3.2: USB disconnect, device number 6 [6.955040] usb 1-1.3.2: new full-speed USB device number 7 using ehci-pci [7.039215] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0002/input/input4 [7.039306] hid-multitouch 0003:29BD:4101.0002: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 11.383830] usb 1-1.3.2: USB disconnect, device number 7 [ 11.642043] usb 1-1.3.2: new full-speed USB device number 8 using ehci-pci [ 11.726858] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0003/input/input6 [ 11.726947] hid-multitouch 0003:29BD:4101.0003: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 16.247185] usb 1-1.3.2: USB disconnect, device number 8 [ 16.426042] usb 1-1.3.2: new full-speed USB device number 9 using ehci-pci [ 16.510970] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0004/input/input8 [ 16.511067] hid-multitouch 0003:29BD:4101.0004: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 20.854572] usb 1-1.3.2: USB disconnect, device number 9 [ 21.112042] usb 1-1.3.2: new full-speed USB device number 10 using ehci-pci [ 21.197973] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0005/input/input10 [ 21.198072] hid-multitouch 0003:29BD:4101.0005: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 25.717651] usb 1-1.3.2: USB disconnect, device number 10 [ 25.895018] usb 1-1.3.2: new full-speed USB device number 11 using ehci-pci [ 25.979810] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0006/input/input12 [ 25.979909] hid-multitouch 0003:29BD:4101.0006: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 30.325789] usb 1-1.3.2: USB disconnect, device number 11 [ 30.588021] usb 1-1.3.2: new full-speed USB device number 12 using ehci-pci [ 30.673335] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0007/input/input14 [ 30.673381] hid-multitouch 0003:29BD:4101.0007: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 35.188772] usb 1-1.3.2: USB disconnect, device number 12 [ 35.366040] usb 1-1.3.2: new full-speed USB device number 13 using ehci-pci [ 35.451447] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0008/input/input16 [ 35.451498] hid-multitouch 0003:29BD:4101.0008: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 39.795933] usb 1-1.3.2: USB disconnect, device number 13 [ 40.055019] usb 1-1.3.2: new full-speed USB device number 14 using ehci-pci [ 40.139578] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.0009/input/input18 [ 40.139626] hid-multitouch 0003:29BD:4101.0009: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 44.659133] usb 1-1.3.2: USB disconnect, device number 14 [ 44.837018] usb 1-1.3.2: new full-speed USB device number 15 using ehci-pci [ 44.920784] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000A/input/input20 [ 44.920828] hid-multitouch 0003:29BD:4101.000A: input: USB HID v1.00 Mouse [Silicon Works Multi-touch SW4101C] on usb-:00:12.0-1.3.2/input0 [ 49.266523] usb 1-1.3.2: USB disconnect, device number 15 [ 49.550012] usb 1-1.3.2: new full-speed USB device number 16 using ehci-pci [ 49.634659] input: Silicon Works Multi-touch SW4101C as /devices/pci:00/:00:12.0/usb1/1-1/1-1.3/1-1.3.2/1-1.3.2:1.0/0003:29BD:4101.000B/input/input22 [ 49.634706] hid-multitouch 0003:29BD:4101.000B: input: USB HID v1.00 Mouse
Enable 9bit-mode in a serial device
Hi all, I'm wondering what's the best way to enable the 9bit-mode for a given tty serial device. I have a motherboard with a NCT6102D Nuvoton super IO with 6 UARTs. This device is supported by the 8250/16550 driver already in kernel and I'm able to communicate two serial port with a NULL modem cable. >From NCT6102D Nuvoton datasheet it seems some bits has to be set in order to >enable this mode to use the parity bit as the 9 bit. Any hint? Any driver from drivers/tty/serial/8250 can be used as a guide? Some user space code can be used to get access to registers? Thanks, Jorge ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: How to replace set_fs(KERNEL_DS) for a kernel 5.10.x module driver version
>Patents have almost nothing to do with licenses, we have many things in >the Linux kernel that are under a GPLv2 license that have patents issued >for (and are actively enforced.) The GPL can, and does, work with the >patent system, so if that's a reason that any company tries to give for >not releasing kernel code, it's very misinformed. Well, I think the only the reason not to publish the code was because it's a driver for a custom hardware with no interest outside our department... > Anyway, off-topic but I figured I would try to clear that up. I was wondering that with the current limitation, there is no way to call functions in a driver as the cdc-acm from other drivers as the dummy I sent. Maybe our driver was designed the way is to avoid latencies from context switching if the code were in userspace... It's only a guess... Thanks, Jorge ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: How to replace set_fs(KERNEL_DS) for a kernel 5.10.x module driver version
>> Well, I don't know if I'm allowed to share the full source code... >> But, is it not enough with the minimal code I attached to grasp the >> problem? > >I'm not allowed to help vendors with closed source kernel modules, >sorry. I understand you... I'll ask for permission because there are no secrets no patents in the code. It's only an old code unmanteined I was trying to update to last kernel version. Thanks Greg! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: How to replace set_fs(KERNEL_DS) for a kernel 5.10.x module driver version
>> Well, I can summarize as technological debt :( >> I have to maintain an old code and I've been succesful until now with >> minimal changes... Is there no way to overcome this? > >There might be, again, do you have a pointer to your full source for the >module? > Well, I don't know if I'm allowed to share the full source code... But, is it not enough with the minimal code I attached to grasp the problem? With the original kernel modules I'll have problems with the read/write functions because they use the set_fs/get_fs functions too but I think it's not an option to rewrite the driver as a userspace library and maybe I should remain using a < 5.10.x kernel... Thanks, Jorge ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: How to replace set_fs(KERNEL_DS) for a kernel 5.10.x module driver version
>> Hi all, this is my first post in this mailing list... I hope to find an >> answer. I've post the question in stackoverflow with the same tittle with no >> answers yet. Since then, I've been able to reduce the demo kernel module to >> minimum in order to show but I see. The minimum kernel module code is >> attached at the end. >> >> My kernel module was working ok up to kernel 5.10.x. My kernel module adds a >> layer above the cdc-acm class driver to use all the infrastructure this >> driver because the hardware it controls has a ttyACMx device. The minimum >> kernel module code attached shows how I open the ttyACMx device and try to >> set the baudrate. Once the device is opened I use the unlocked_ioctl >> function with TCSETS to set the new device properties. >> >> ret = fd->f_op->unlocked_ioctl(fd, TCSETS, (unsigned long >>int) ); >Ick, why do all of this from the kernel and not just do it from >userspace? > >Do you have a pointer to the source of your whole module so we can help >with solving the root problem and not mess with this specific >implementation which is not the correct thing to do at all. Hi Greg! Well, I can summarize as technological debt :( I have to maintain an old code and I've been succesful until now with minimal changes... Is there no way to overcome this? Thanks! Jorge ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
How to replace set_fs(KERNEL_DS) for a kernel 5.10.x module driver version
Hi all, this is my first post in this mailing list... I hope to find an answer.
I've post the question in stackoverflow with the same tittle with no answers
yet. Since then, I've been able to reduce the demo kernel module to minimum in
order to show but I see. The minimum kernel module code is attached at the end.
My kernel module was working ok up to kernel 5.10.x. My kernel module adds a
layer above the cdc-acm class driver to use all the infrastructure this driver
because the hardware it controls has a ttyACMx device. The minimum kernel
module code attached shows how I open the ttyACMx device and try to set the
baudrate. Once the device is opened I use the unlocked_ioctl function with
TCSETS to set the new device properties.
ret = fd->f_op->unlocked_ioctl(fd, TCSETS, (unsigned long int)
);
I get an EFAULT (-14) error from this function. I've track down the error to
drivers/tty/tty_ioctl.c, set_termios function in the next code:
#ifdef TCGETS2
} else if (opt & TERMIOS_OLD) {
if (user_termios_to_kernel_termios_1(_termios,
(struct termios __user *)arg))
return -EFAULT;
} else {
where 'user_termios_to_kernel_termios_1' is a macro to 'copy_from_user' then I
think there is a problem with the parameter 'newtio'. To solve this in the
previous kernel versions ( < 5.10.x) I had the code with get_fs()/set_fs() but
now these functions and the KERNEL_DS definitions are gone...
As a reference when I run this kernel module in a 4.15.0-128-generic I get when
inserted and removed:
# dmesg
...
[431743.226926] cdc_acm 3-5.2:1.0: ttyACM0: USB ACM device
[431749.633030] testdrv:testdrv_init: testdrv_init
[431749.633351] testdrv:testdrv_init: fd : e9327576
[431749.633355] testdrv:testdrv_init: fd->f_op: c761e065
[431749.633357] testdrv:testdrv_init: ioctl : 608ed60c
[431749.633517] testdrv:usbox_serial_baudrate_set: _unlocked_ioctl: 0
[431749.633519] testdrv:usbox_serial_baudrate_set: ret: 0
[431761.532905] testdrv:testdrv_exit: testdrv_exit
and the same driver with 5.10.0-1-amd64:
# dmesg
...
[4.731179] cdc_acm 2-3:1.0: ttyACM0: USB ACM device
...
[ 168.263871] testdrv: loading out-of-tree module taints kernel.
[ 168.264337] testdrv:testdrv_init: testdrv_init
[ 168.266360] testdrv:testdrv_init: fd : bd0e50a3
[ 168.266363] testdrv:testdrv_init: fd->f_op: dc488f77
[ 168.266364] testdrv:testdrv_init: ioctl : c31431c2
[ 168.266370] testdrv:usbox_serial_baudrate_set: _unlocked_ioctl: -14
[ 168.266371] testdrv:usbox_serial_baudrate_set: ret: -14
[ 168.266372] testdrv:testdrv_init: errno: EINVAL
Anybody can help me to make it work the minimum kernel module attached?
Thank you!
Jorge
#define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__
#include
#include
#include
#include
#include
#include
/* ttyACM file descriptor */
static struct file *fd;
static int usbox_serial_baudrate_set(struct file *fd)
{
int ret;
mm_segment_t old_fs;
struct termios newtio;
//struct termios __user newtio;
//void __user *unewtio = (void __user *)
memset(, 0, sizeof(newtio));
newtio.c_cflag = (B115200 | CS8 | CLOCAL | CREAD);
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,0,0)
old_fs = get_fs();
set_fs( get_ds() );
#elif LINUX_VERSION_CODE < KERNEL_VERSION(5,10,0)
old_fs = get_fs();
set_fs( KERNEL_DS );
#else
old_fs = force_uaccess_begin();
#endif
if (fd->f_op->unlocked_ioctl) {
ret = fd->f_op->unlocked_ioctl(fd, TCSETS, (unsigned long int)
);
pr_info("_unlocked_ioctl: %d\n", ret);
} else {
ret = -ENOTTY;
}
#if LINUX_VERSION_CODE < KERNEL_VERSION(5,10,0)
set_fs(old_fs);
#else
force_uaccess_end(old_fs);
#endif
pr_info("ret: %d\n", ret );
return ret;
}
static int __init testdrv_init(void)
{
pr_info("testdrv_init\n");
fd = filp_open( "/dev/ttyACM0", O_RDWR|O_NOCTTY, 0);
if (IS_ERR(fd)) {
pr_info("error from filp_open()\n");
return -ENODEV;
}
pr_info ("fd : %p\n", fd);
pr_info ("fd->f_op: %p\n", fd->f_op);
pr_info ("ioctl : %p\n", fd->f_op->unlocked_ioctl);
if ((fd->f_op == NULL) || (fd->f_op->unlocked_ioctl == NULL)) {
pr_info("errno: ENODEV\n");
return -ENODEV;
}
// Set baudrate.
if (usbox_serial_baudrate_set(fd) != 0 ) {
filp_close(fd, NULL);
pr_info("errno: EINVAL\n");
return -EINVAL;
}
return 0;
}
static void __exit testdrv_exit(void)
{
pr_info("testdrv_exit\n");
if (fd != NULL) {
filp_close(fd, NULL);
fd = NULL;
}
}
module_init(testdrv_init);
module_exit(testdrv_exit);
