netdev - Re: [PATCH net-next v4 13/12] net: lan865x: optional hardware reset

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: <a3719443-153b-49d5-b039-fa0a7928de28@microchip.com>
Date: Tue, 30 Apr 2024 13:30:44 +0000
From: <Parthiban.Veerasooran@...rochip.com>
To: <andrew@...n.ch>
CC: <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>, <Pier.Beruto@...emi.com>,
	<Selvamani.Rajagopal@...emi.com>, <Nicolas.Ferre@...rochip.com>,
	<benjamin.bigler@...nformulastudent.ch>, <ramon.nordin.rodriguez@...roamp.se>
Subject: Re: [PATCH net-next v4 13/12] net: lan865x: optional hardware reset

On 29/04/24 5:49 pm, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> Additionally I figured out why my setup did not work without the HW
>> reset, I had missed a pull resistor in the schematic that held the IC in
>> reset.
> 
> Having a reset controlled by software is a pretty common
> design. Something needs to ensure the device is out of reset. It could
> be the bootloader, but i don't particularly like that, hiding away
> critical things where they are hard to see. So i think having it in
> the Linux driver is better.
> 
> There is an open question of does the driver need to actually reset
> the device, or is it sufficient to ensure it is out of reset? The
> wording of the standard suggests a hardware reset cycle is probably
> not required, but why did Microchip provide a reset pin?
There are three resets mentioned,

1. Power ON reset - A Power-On Reset occurs when power is initially 
applied to the device. Once the reset completes, the IRQ_N pin will be 
asserted and the RESETC (Reset Completed) bit of the OA_STATUS0 Register 
will be set to 1, as specified by the Open Alliance. This indicates to 
the driver that the device has been reset and ready to configure. For a 
pre configured system this is enough to start the configuration.

2. Software reset - This reset can be done from software. In the driver, 
it is done as part of initialization. Actually it may not be needed if 
we are not going to reload the driver, as the Power ON reset does the 
same job for us. But if we compiled the driver as a loadable module and 
out of tree then it is needed for each time when we reload the driver 
without power reset.

3. Ext pin reset - A hardware reset will occur when the RESET_N pin is 
asserted. Once the RESET_N input is deasserted, the LAN8650/1 will 
restart operation. The device will indicate to the station's controller
that it has been reset and must be configured in the same way as if a 
Power-On Reset had occurred: the IRQ_N pin will be asserted and the 
RESETC (Reset Completed) bit of the OA_STATUS Register will be set to 1.

This is also basically does the same job but it may be useful when the 
chip gets into a situation where it can't perform SPI anymore to do a 
software reset. This may be needed in the initial phase testing. But 
once the development is completed and the chip is ready to use then 
there will not be any possibility to get into the above situation unless 
there is a permanent hardware failure where this reset also will not 
make any sense.

OPEN Alliance spec says the following in the section 8.2 Variables

reset
	This variable reflects the logical-OR of all reset sources of the 
MAC-PHY and is TRUE when any of the reset sources are asserted. Reset 
sources include power-on reset (POR), software reset (see Section 
9.2.4.2), and an external RESET pin (if implemented).

In the spec, external RESET pin is mentioned as "if implemented", in my 
understanding it is MAC-PHY vendors choice of implementing it where 
Microchip is implemented it. Using this reset, can be a application 
requirement/decision. It can be controlled from an external application 
where it is not needed SPI to operate.

Best regards,
Parthiban V
> 
>          Andrew