GPIO changes with Linux v5.15

[fpoussin]

I've upgraded from 5.10 to 5.15 and can't make GPIO work anymore

I've tried this

gpio_keys {
		compatible = "gpio-keys";
		input-name = "gpio-keys";
		status = "okay";
 
		halt {
			label = "Halt";
			linux,code = <KEY_POWER>; // Key event to match with poweroff daemon
			gpios = <&gpioa 2 GPIO_ACTIVE_LOW>; // WKUP2 on falling edge
			status = "okay";
		};
 
		wakeup {
			label = "Wakeup";
			linux,code = <BTN_1>;
			gpios = <&gpioa 2 GPIO_ACTIVE_HIGH>;
			status = "okay";
			wakeup-source;
		};
 }

but am getting

[ 1.950701] gpio-keys gpio_keys: failed to get gpio: -16
[ 1.950728] gpio-keys: probe of gpio_keys failed with error -16
[ 2.205292] hci_uart_qca serial0-0: failed to acquire enable gpio

I've also tried, according to the kernel documentation:

wakeup {
	label = "Wakeup";
	linux,code = <BTN_1>; // Can be anything, not used
	interrupt-parent = <&pwr_irq>;
	
	//cell 1: wake-up pin id from 0 to 5
	//cell 2: IRQ_TYPE_EDGE_FALLING or IRQ_TYPE_EDGE_RISING
	//cell 3: Pull config: 0 = No Pull, 1=Pull Up, 2=Pull Down
	interrupts = <1 IRQ_TYPE_EDGE_RISING 0>; // WKUP2 - PA2 = ID 1
	wakeup-source;
};

Still not working...

[ 1.940288] stm32_pwr 50001020.pwr: Failed to request wake-up pin
[ 1.940381] genirq: Failed to request resources for Wakeup (irq 64) on irqchip stm32-pwr-irq

My working DT for 5.10 was:

gpio_keys {
	compatible = "gpio-keys";
	input-name = "gpio-keys";
	status = "okay";
		halt {
			label = "Halt";
			linux,code = <KEY_POWER>;
			gpios = <&gpioa 2 GPIO_ACTIVE_LOW>;
			status = "okay";
		};
		wakeup {
			label = "Wakeup";
			linux,code = <BTN_1>;
			interrupts-extended = <&exti_pwr 56 IRQ_TYPE_EDGE_RISING>;
			wakeup-source;
			status = "okay";
		};
	};

 Also, documentation is blocked: https://wiki.st.com/stm32mpu/wiki/How_to_configure_PWR_Wake-up_pins

Any ideas?

[Olivier GALLIEN]

Hi @fpoussin​ ,

No evidence from what you provided .. but issue may come from a little syntax or policy error elsewhere.

Typical pitfall moving from one release to another is around your DTS "user section" which may contains some old version policy/syntax.

How did you manage this upgrade ?

The procedure we recommend :

1.Backup your project

�? Copy all the project into a backup folder to avoid losing codes or configurations if you make an error.

2.Migrate

�? Migrate your project with the newest version of CUBEMX (6.5.0) and generate the DTS

3.Project Reference

�? Create a new project with the newest version of CubeMX (6.5.0) by selecting the ST Board which is the most similar to your custom project.

This project will be used as a reference to see the difference brought by the ecosystem update into the User Section areas.

Merge

• Use a diff tool like “meld�? to merge the reference DTS from CubeMX 6.5.0 with the migrated one from CubeMX 6.1.0.

EDIT :  

the page  https://wiki.st.com/stm32mpu/wiki/How_to_configure_PWR_Wake-up_pins is under construction / not published yet. Since it only concern solution with OPTEE I think it's not relevant in your case.

Hope it help

Olivier

[fpoussin]

Hi,

For the upgrade since I use buildroot I just backported all my changes to the latest ST releases. (TF-A, Kernel)

CubeMX 6.6.1 (or any version) doesn't export anything in the DTS for wake-up or even gpio pins.

Everything works fine with a 5.10 kernel using TF-A 2.6.

Could it be related to the fact that I use sp_min?

I'll give op-tee a try...

[Erwan SZYMANSKI]

Hello @fpoussin​ ,

Are you still blocked with this issue ? Did you make a try with OP-TEE ?

Kind regards,

Erwan.

[Erwan SZYMANSKI]

Hi @fpoussin​ ,

As information, the article that you mention is under review and will soon be available.

Just one remark, I see that your gpio-keys probe error say that your gpio seems busy (-16 error). Considering the difference with your 5.10 device tree, I see that you use the same gpio on halt node and wakeup node. Did you already try to change the second one just to check if the error is still present ? I am not a professional in wake up pin management but it can help us to understand what happens in the drivers' probe fail.

I would also recommend you to put traces in gpio-keys.c driver to print which step exactly fail with which parameter etc..

Let me know if you get more information.

Kind regards,

Erwan.