Re: [PATCH RFC 0/6] DPAA2 MAC Driver

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Jun 14, 2019 at 03:26:50PM +0000, Ioana Ciornei wrote:
> > Subject: Re: [PATCH RFC 0/6] DPAA2 MAC Driver
> > 
> > On Fri, Jun 14, 2019 at 02:55:47AM +0300, Ioana Ciornei wrote:
> > > After today's discussion with Russell King about what phylink exposes
> > > in
> > > .mac_config(): https://marc.info/?l=linux-netdev&m=156043794316709&w=2
> > > I am submitting for initial review the dpaa2-mac driver model.
> > >
> > > At the moment, pause frame support is missing so inherently all the
> > > USXGMII modes that rely on backpressure applied by the PHY in rate
> > > adaptation between network side and system side don't work properly.
> > >
> > > As next steps, the driver will have to be integrated with the SFP bus
> > > so commands such as 'ethtool --dump-module-eeprom' will have to work
> > > through the current callpath through firmware.
> > 
> > From what I understand having read the doc patch, would it be fair to say
> > that every operation that is related to the link state has to be passed from
> > the ETH driver to the firmware, and then from the firmware back to the
> > kernel to the MAC driver?
> 
> That is correct.
> 
> > 
> > Does this mean that "ethtool --dump-module-eeprom" goes through this
> > process as well - eth driver into firmware, which then gets forwarded out of
> > the formware on the MAC side, via phylink to the SFP cage?
> > 
> > If that is true, what is the proposal - to forward a copy of the EEPROM on
> > module insertion into the firmware, so that it is stored there when anyone
> > requests it?  What about the diagnostic monitoring that is real-time?
> > 
> 
> At the moment, we do not have a proposal that could solve all these issues.
> We thought about a solution where the eth driver issues a command to the firmware that then issues an IRQ to the mac driver which could retrieve and then pass back the information.
> This doesn't seem too feasible since the ethernet driver should be waiting for the data to arrive back from the firmware while in an ethtool callback.
> 
> 
> > Or is the SFP cage entirely handled by firmware?
> 
> No, the SFP cage is not handled by firmware.

Hi Ioana

At the moment, you seem to be in a bad middle ground. The firmware
cannot do everything, so you want Linux and PHYLINK to do some
bits. But Linux expects to do everything, have full control of the
hardware. And it is not fitting together.

Maybe you need to step back and look at the overall architecture. And
then decide which way you want to go to get out of the middle
ground. There are good examples of the firmware controlling
everything, and the driver just using the high level ethtool API calls
to report state. And there are good examples of low levels of the
hardware, the MDIO bus so Linux can control the PHYs, the i2c bus and
GPIOs for the SFP cage, etc being exposed so PHYLINK can control
everything.

To have a sensible architecture and driver implementation you need to
go one way or the other. All or nothing.

   Andrew