Re: [RFC net-next v2 5/5] net: phy: nxp-c45-tja11xx: implement mdo_insert_tx_tag

[Russell King (Oracle)]

On Fri, Sep 01, 2023 at 02:31:32PM +0300, Radu Pirea (OSS) wrote:
> On 01.09.2023 12:27, Russell King (Oracle) wrote:
> > On Fri, Sep 01, 2023 at 09:09:06AM +0000, Radu Pirea wrote:
> > > On Wed, 2023-08-30 at 13:35 +0200, Sabrina Dubroca wrote:
> > > ...
> > > 
> > > > And it's not restored when the link goes back up? That's inconvenient
> > > > :/
> > > > Do we end up with inconsistent state? ie driver and core believe
> > > > everything is still offloaded, but HW lost all state? do we leak
> > > > some resources allocated by the driver?
> > > 
> > > Yes. We end up with inconsistent state. The HW will lost all state when
> > > the phy is reseted. No resource is leaked, everything is there, but the
> > > configuration needs to be reapplied.
> > 
> > If it's happening because the PHY is being re-attached from the network
> > driver, then wouldn't it be a good idea to synchronise the hardware > state with the software configuration in the ->config_init function?
> 
> .config_init might be an option, but keeping the keys in the driver might
> not be a good idea.
> 
> > 
> > Presumably the hardware state is also lost when resuming from suspend
> > as well? If so, that'll also fix that issue as well.
> soft_reset is called when resuming from suspend, so, in this case, the
> MACsec configuration will be lost.

Depending on what loses power at suspend time, it could be that the PHY
is powered down, and thus would lose all configuration. This is
something that the MACSEC core _has_ to expect may happen, and there
has to be some way to restore the configuration, including the
keys!

One can't "write configuration to hardware and then forget" when the
hardware may lose state, no matter what the configuration is.

Take for example hibernation... where the system may be effectively
powered off - maybe even if it's a piece of mains powered equipment,
it may be unplugged from the mains. When the system resumes, shouldn't
the configuration be completely restored, keys and all, so that it
continues to function as it was before hibernation?

The only possible alternative would be to have some kind of way for
the driver to tell the core that state was lost, so the core can
invalidate that state and inform userspace of that event, so userspace
gets the opportunity itself to restore the lost state.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!