Re: [PATCH mvebu-dt 3/6] ARM: dts: turris-omnia: describe ethernet-phy interrupt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Nov 14, 2020 at 06:47:17PM +0100, Marek Behun wrote:
> On Sat, 14 Nov 2020 18:42:21 +0100
> Marek Behún <kabel@xxxxxxxxxx> wrote:
> 
> > Do you think we should just poll for interrupts with the PHY?

Yes.

> 
> Andrew, JFI, there are also SFP GPIOs connected to this expander. So
> interrupt will be generated on changes from those gpios as well. Is an
> interrupt storm seriosly probable here?

As far as i remember on the device i was using, all inputs are
interrupt sources. And all pins default as inputs, so you don't
accidentally drive the output against something else. So you need to
get the device properly configured before enabling its interrupt. And
i'm not too sure how that works with the GPIO framework where you
effectively have a collection of individual GPIOs. How do you know
they have all be configured, and it is safe to enable the interrupt
output? Do you have any pins floating? Those you are going to have to
configure as output. Plus is the interrupt output from the gpio
expander level triggered? If so you need to ensure the upstream
interrupt controller can do level. And Marvell SoCs often cannot.

The device i was working on i had trouble even getting it to boot
without dying. Polling the PHY and SFP was working O.K, so i gave
up. And i suggested the next revision of the board used an sx150x
which has much better interrupt support. That has worked well against
a Vybrid.

	   Andrew



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux