netdev - Re: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error interrupts unmasking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6e4207cd-2bd5-4f5b-821f-bc87c1296367@microchip.com>
Date: Tue, 14 May 2024 04:46:58 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <ramon.nordin.rodriguez@...roamp.se>, <andrew@...n.ch>
CC: <Pier.Beruto@...emi.com>, <davem@...emloft.net>, <edumazet@...gle.com>,
	<kuba@...nel.org>, <pabeni@...hat.com>, <horms@...nel.org>,
	<saeedm@...dia.com>, <anthony.l.nguyen@...el.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <corbet@....net>,
	<linux-doc@...r.kernel.org>, <robh+dt@...nel.org>,
	<krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
	<devicetree@...r.kernel.org>, <Horatiu.Vultur@...rochip.com>,
	<ruanjinjie@...wei.com>, <Steen.Hegelund@...rochip.com>,
	<vladimir.oltean@....com>, <UNGLinuxDriver@...rochip.com>,
	<Thorsten.Kummermehr@...rochip.com>, <Selvamani.Rajagopal@...emi.com>,
	<Nicolas.Ferre@...rochip.com>, <benjamin.bigler@...nformulastudent.ch>
Subject: Re: [PATCH net-next v4 05/12] net: ethernet: oa_tc6: implement error
 interrupts unmasking

Hi Ramon,

On 13/05/24 7:20 pm, Ramón Nordin Rodriguez wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Mon, May 13, 2024 at 03:00:48PM +0200, Andrew Lunn wrote:
>>> I've enabled some debugging options but so far nothing seems to hit.
>>> What I've been able to conclude is that there still is SPI
>>> communication, the macphy interrupt is still pulled low, and the cpu
>>> does the ack so that it's reset to inactive.
>>
>> Is it doing this in an endless cycle?
> 
> Exactly, so what I'm seeing is when the driver livelocks the macphy is
> periodically pulling the irq pin low, the driver clears the interrupt
> and repeat.
If I understand correctly, you are keep on getting interrupt without 
indicating anything in the footer?. Are you using LAN8650 Rev.B0 or B1?. 
If it is B0 then can you try with Rev.B1 once?

Best regards,
Parthiban V
> 
>>
>> Probably the debug tools are not showing anything because it is not
>> looping in just one location. It is a complex loop, interrupts
>> triggering a thread which runs to completion etc. So it looks like
>> normal behaviour.
> 
> Gotcha. The 'do work' func called in the worker threads loop does run
> and return, so I guess there is not much to trigger on.
> 
>>
>> If it is an endless cycle, it sounds like an interrupt storm. Some
>> interrupt bit is not getting cleared, so it immediately fires again as
>> soon as interrupts are enabled.
> 
> Good input. I'll add some instrumentation/stats for how many jiffies
> have elapsed between releases of the worker thread and for the irq
> handler. I can probably find a gpio to toggle as well if it's really
> tight timings.
> 
> The irq pin is inactive/high for 100s of us to ms in the measurments
> I've done. But I've been using multiple channels and not the fanciest
> equipment so samplerates might be playing tricks, I'll rerun some tests
> while only measuring the irq pin.
> 
>>
>> Is this your dual device board? Do you have both devices on the same
>> SPI bus? Do they share interrupt lines?
>>
> 
> It's on the dual device board, the macphys are using separate spi buses,
> one chip shares the bus with another spi device, but the other is the
> only tenant on the bus.
> 
> No device shares an irq line.
> 
> Pretty sure I can replicate the result for both devices, but need to
> double check, been to much testing of random things for me to keep track.
> 
> I'll do some more digging, I think we're getting pretty close to
> understading the behaviour now.
> 
> R