Re: [PATCH net-next v3 2/4] dt-bindings: net: phy: add MaxLinear GPY2xx bindings

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

 



Am 2023-01-13 17:38, schrieb Rob Herring:
On Wed, Jan 11, 2023 at 4:30 PM Michael Walle <michael@xxxxxxxx> wrote:

Am 2023-01-11 21:26, schrieb Rob Herring:
> On Mon, Jan 09, 2023 at 01:30:11PM +0100, Michael Walle wrote:
>> Add the device tree bindings for the MaxLinear GPY2xx PHYs, which
>> essentially adds just one flag: maxlinear,use-broken-interrupts.
>>
>> One might argue, that if interrupts are broken, just don't use
>> the interrupt property in the first place. But it needs to be more
>> nuanced. First, this interrupt line is also used to wake up systems by
>> WoL, which has nothing to do with the (broken) PHY interrupt handling.
>
> I don't understand how this is useful. If the interrupt line is
> asserted
> after the 1st interrupt, how is it ever deasserted later on to be
> useful.

Nobody said, that the interrupt line will stay asserted. The broken
behavior is that of the PHY doesn't respond *immediately* with a
deassertion of the interrupt line after the its internal status
register is cleared. Instead there is a random delay of up to 2ms.

With only "keep the interrupt line asserted even after the interrupt
status register is cleared", I assume that means forever, not some
delay.

Fair enough. I'll send a doc patch.

There is already a workaround to avoid an interrupt storm by delaying
the ISR until the line is actually cleared. *But* if this line is
a shared one. The line is blocked by these 2ms and important
interrupts (like PTP timestaming) of other devices on this line
will get delayed. Therefore, the only viabale option is to disable
the interrupts handling in the broken PHY altogether. I.e. the line
will never be asserted by the broken PHY.

Okay, that makes more sense.

So really, this is just an 'is shared interrupt' flag. If not shared,
then there's no reason to not use the interrupt?

Correct.

Assuming all
interrupts are described in DT, we already have that information. It's
just hard and inefficient to get it. You have to parse all interrupts
with the same parent and check for the same cells. If we're going to
add something more explicit, we should consider something common. It's
not the first time shared interrupts have come up, and we probably
have some properties already. For something common, I'd probably make
this a flag in interrupt cells rather than a property. That would
handle cases with multiple interrupts better.

What kind of flag do you have in mind? Could you give an example?

-michael



[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