> > Well, the _correct_ driver needs to be used for the PHY specific
> > features to be properly controlled. Using the generic driver
> > in this situation will not be guaranteed to work.
I fully agree about the PHY driver. I'm expect this device is
violating c22 when it modifies the advertisement register itself. So
all bets are off for the genphy.
> Well, this hasn't worked, but not for the obvious reason. Register 0x14
> is documented as read/write. Bits 15:6 are reserved, bit 5 is the
> smart speed enable, 4:2 configures the attempts, bit 1 sets the link
> stable condition, bit 0 is reserved.
>
> Writing 0x80c results in the register reading back 0x82c. Writing
> 0x800 results in the same. Writing 0 reads back 0x2c. Writing 0xffff
> seems to prevent packets being passed - and at that point I lost
> control so I couldn't see what the result was.
>
> There is nothing in the data sheet which suggests that there is any
> gating of this register. So it looks like we're stuck with smartspeed
> enabled.
>
> So, I think there's only two remaining ways forward - to revert commit
> 5502b218e001 to restore the old behaviour, read back the advertisement
> from the PHY along with the rest of the status, as I've previously
> stated. It means that phylib will modify phydev->advertising at
> random points, just as it modifies phydev->lp_advertising, so locking
> may become an issue. The revert approach is probably best until we
> have something working along those lines.
We have a couple of other PHYs which support downshift. We should see
if we can follow what they do. What is i think important is that
read_status return the correct speed. So we probably cannot use
genphy_read_status() as is. Maybe we should split genphy_read_status()
into two, so the register reading bit can be done unconditionally by
phy drivers for hardware which don't report link down when they
should?
Andrew
