Kernel 6.6 changes how GPIO numbering works, and manually configuring GPIO numbers is unreliable

[mdeneen]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

The Linux 6.6 kernel changes how GPIO numbering functions, and you can no longer rely on hard-coded GPIO numbers. As such, module parameters settings such as "resetpin" and the hardcoded definitions such as HANDSHAKE_PIN and SPI_DATA_READY_PIN are unreliable. Adding a component, such as an SPI GPIO expander, can cause the GPIO numbering to be different from what it was before it was added.

Additionally, if I'm reading things correctly, the numbering may change non-deterministically on each boot. In short, specifying the GPIO number is not a viable option for the future.

I know that it's a pain in the butt when you're trying to support so many platforms, but the right course of action here is to move these things up to the device tree.

[mantriyogesh]

You are absolutely correct. We will try to take action on this asap.

Although, our approach would be flexible enough for users. We should cater device tree, also hard coding. if users use latest kernel, they can stick with device tree, which makes more sense. If they are very sure, they can also use module param and hardcoded way.

We will update on this, once we fix this. But consider possible delay in addition of this.

[mdeneen]

You've probably seen this as well, but the 6.6 kernel also spits out a warning when the spi driver is removed. It says something along the lines of "WARNING: Flushing system-wide workqueues will be prohibited in near future."

flush_scheduled_work is the offending line.

[mantriyogesh]

Yes. Noted. Will change the driver asap, which is in acceptable way for latest Linux.

Anymore inputs If you have, so that will accommodate in single change.