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
