Re: [PATCH 1/2] net: enc28j60: support getting irq number from gpiophandle in the device tree
From: Andrew Lunn
Date: Mon Mar 10 2025 - 08:10:03 EST
On Mon, Mar 10, 2025 at 10:20:01AM +0800, hanyuan-z wrote:
> Hi Andrew, <br/><br/>> My understanding is that you should not need most of this. The IRQ<br/>> core will handle converting a GPIO to an interrupt, if you just list<br/>> is as an interrupt source in the normal way.<br/><br/>> You say:<br/>><br/>> > Additionally, it is necessary for platforms that do not support pin<br/>> > configuration and properties via the device tree.<br/>><br/>> Are you talking about ACPI?<br/><br/>Thanks for your review. Let me explain them.<br/><br/>I understand that specifying the interrupt as:<br/><br/> interrupts = <&gpio2 23 IRQ_TYPE_LEVEL_LOW>;<br/><br/>would also work, and the IRQ subsystem will properly handle the<br/>conversion during the SPI probe. However, my problem is that the<br/>GPIO pin itself needs to be explicitly requested and configured a<br/>an input before it can be used as an IRQ pin.<br/><br/>My embedded platform has limited support, it only provides a<br/>hard-coded pin control driver and does not support configuring<br/>pinctrl properties in the device tree. So, there is no generic<br/>way to request the pin and set its direction via device tree bindings.<br/><br/>I noticed that some existing NIC drivers solve this issue by specifying<br/>`irq-gpios` in the device tree, which ensures that the GPIO is properly<br/>initialized before being converted to an IRQ.<br/><br/>That was my motivation for these patches.<br/><br/>And my changes are not related to ACPI in any way—they are mainly<br/>focused on device tree handling.<br/><br/>Thanks, <br/>Hanyuan Zhao <br/>
Please use plain text for emails.
Andrew