Gpio key driver rmmod error

1,HardWare:Jetson Xavier NX moules; SoftWareVersion:R35.4.1;
2,Change the pinmux of GPIO PN.01《xxx_pin_configure template v1.06.xlsm》 as below:

Customer Usage | Pin Direction  | Req. Initial State | Wake Pin
GPIO3_PN.01    | Input	        | Int PD	          | Yes

3,add dts node in tegra194-p3668-0001-p3509-0000.dts

mykey2_node {
		compatible = "mykey2,key2";
		key2-gpio = <&tegra_main_gpio TEGRA194_MAIN_GPIO(N, 1) GPIO_ACTIVE_LOW>;
		interrupt-parent = <&tegra_main_gpio>;
		interrupts = <TEGRA194_MAIN_GPIO(N, 1) IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING>;
	};

4,my driver code is below.
fs4412key2.txt (2.3 KB)
5,It can only works when insmod for the first time. the “dmesg” info is below.
key_rmmod_error_msg.txt (3.5 KB)
6,I located it to the “input_free_device(pgmydev->pdev);”, but this process alloc->register->unregister->free is reasonable.
So what’s the wrong?
And additional,I used GPIO PN.01 is because the topicbelow, Is the statement that only the pins which tagged with “wake” can be used for input interrupt gpio right?
Orin Nano/NX: GPIO as Interrupt source - Jetson & Embedded Systems / Jetson Orin NX - NVIDIA Developer Forums

Your error log looks like the ref count is already 0 before you ran that input_free_device.

Is it relate to that I have not exec any app program?I tried run the app and exit, the dmesg info is the same.
And What about this question?

And additional,I used GPIO PN.01 is because the topicbelow, Is the statement that only the pins which tagged with “wake” can be used for input interrupt gpio right?

Yes, only the pin with “wake” in the spreadsheet could be used to wake the device.

Is it relate to that I have not exec any app program?I tried run the app and exit, the dmesg info is the same.

I don’t know what does that mean any app program. You are writing a kernel driver. This thing got run when you insert the module… not related to any app program.
It is more like just a bug in your code.

Oh,the app program means a exec which open and read the data from /dev/input/event which created by the driver.when one or more of them run, the ref count of the driver will be changed… that’s what I was thinking.

Didn’t you say the issue is happened when you rmmod the driver?

Then I think it is not related to anything you are doing in userspace.

Now I located that it is because I missed the IRQF_TRIGGER_RISING when calling request_irq().
It can be normal insmod and rmmod, but still report the message below when rmmod for the first time. no matter whether I add the flag “IRQF_SHARED” or not.

------------[ cut here ]------------
refcount_t: underflow; use-after-free
....
---[ end trace 476cfe54f147d4e6 ]---

As I said previously, the reason of “refcount_t: underflow; use-after-free” is because the ref count is already 0 before you call input_free_device.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.