On Sat, Apr 27, 2024 at 10:58:07PM +0200, Andrew Lunn wrote: > On Sat, Apr 27, 2024 at 09:35:06PM +0200, Ramón Nordin Rodriguez wrote: > > I'm running a dual lan8650 setup, neither IC passed the sw reset in the > > oa_tc.c module, I need to pull the reset pin low to reset the pin before > > the rest of the init stuff happens. > > > > The datasheet recommends not doing a sw reset, excerpt from section > > 4.1.1.3 Software Reset > > "Note: The SW_RESET bit of the Clause 22 Basic Control register will reset only the internal PHY, not > > the entire device. This PHY only reset is not recommended for use. If such a reset is detected, by > > reading the RESETC bit of the STS2 register, reset the entire device." > > That is not so good. The PHY driver does not know the PHY is embedded > within another device. It has no idea of RESETC bit in STS2. Looking > at the phy driver, i don't actually seeing it using > genphy_soft_reset(). Do you see a code path where this could actually > be an issue? > I agree with your assesment, the phy won't reset itself, but maybe we could add some comment doc about not adding it for the lan8670, so no one trips over that in the future. Though the phy does not have to be baked with the lan8650 mac, so that might be tricky to cover all future bases there. But for now I don't think it matters. Then regarding doing the soft reset in the oa_tc6 module, I'm not sure that it matters, since it seems to work fine for me for as long as I do the hw reset first. But I can submit a suggestion for how to deal with reset-quirks if we want to have the soft reset optional. I'll run a test with and without the soft reset and see if I can spot any change in behaviour. Let me know if I missed any nuance in your question. > Supporting a hardware reset does however make sense. It would be best > if you submitted a proper clean patch. It can be added to the end of > this series, keeping you as author. > I'd be happy to. Getting late in scandinavia so I'll clean it up and submit tomorrow. R
