I think that it would be better to explicitly error out if
irq_active_high and open_drain are both set. When I sent my
attempt at this, I did it like this:
Which is something I want to do. As I've got a inverter in between :)
For the mcp the open-drain config bit takes precedence over active-high.
Really needs to be fixed by fixing up the irq request, but I
still haven't got a good
fix for the irq request polarity based on active-high in this driver.
I can't see how to fix it without breaking existing dt interface.
I was told that the appropriate way forward are device drivers which do not
specify the IRQ polarity. Apparently, people are supposed to do that in
their DT.
So, in this context:
- pinctrl-mcp23s08.c should only specify IRQF_ONESHOT | IRQF_SHARED
- the DT should use an appropriate IRQ_TYPE_LEVEL_LOW or
IRQ_TYPE_LEVEL_HIGH based on what the CPU expects to see on its IRQ pins
- the DT must also set a property to configure the MCP23xxx device to
*generate* an IRQ by the active-high flag, or another flag for an
open-drain active-low IRQ output suitable for connecting directly to an
interrupt line which gets shared by several open-drain IRQ producers
- whoever supplies the DT must now check that their settings "make sense"
Yes, this means that people might have to update their DTs. To me, that
makes sense. If you ask me, the DT is already sort-of broken because it's
using IRQF_SHARED with a push-pull IRQ output. Yes, one can fix that with
extra transistors, but that sounds quite ugly, doesn't it. The current
heuristics only work for some users, and they don't work for you and me.
I dug a bit and found some reasoning [1] for why it was done like that back
in 2014. Adding Alexander Stein to Cc as he wrote that code.
Phil, is that approach something that you agree with? Are you going to
submit a patch for this? Or should I do that?
With kind regards,
Jan
[1] https://www.spinics.net/lists/devicetree/msg60203.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
