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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 Jun 2019 10:42:28 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Ioana Ciornei <ioana.ciornei@....com>
Cc:     hkallweit1@...il.com, f.fainelli@...il.com, andrew@...n.ch,
        davem@...emloft.net, netdev@...r.kernel.org,
        alexandru.marginean@....com, ruxandra.radulescu@....com
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?

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?

Or is the SFP cage entirely handled by firmware?

> This poses somewhat of a problem, as
> dpaa2-eth lacks any handle to the phy so it will probably need further
> modification to the API that the firmware exposes (same applies to 'ethtool
> --phy-statistics').

This again sounds like the eth driver forwards the request to firmware
which then forwards it to the mac driver for it to process.

Is that correct?

> 
> The documentation patch provides a more complete view of the software
> architecture and the current implementation.
> 
> Ioana Ciornei (4):
>   net: phy: update the autoneg state in phylink_phy_change
>   dpaa2-mac: add MC API for the DPMAC object
>   dpaa2-mac: add initial driver
>   net: documentation: add MAC/PHY proxy driver documentation
> 
> Ioana Radulescu (2):
>   dpaa2-eth: add support for new link state APIs
>   dpaa2-eth: add autoneg support
> 
>  .../freescale/dpaa2/dpmac-driver.rst               | 159 ++++++
>  .../device_drivers/freescale/dpaa2/index.rst       |   1 +
>  MAINTAINERS                                        |   8 +
>  drivers/net/ethernet/freescale/dpaa2/Kconfig       |  13 +
>  drivers/net/ethernet/freescale/dpaa2/Makefile      |   2 +
>  .../net/ethernet/freescale/dpaa2/dpaa2-ethtool.c   |  83 +++-
>  drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c   | 541 +++++++++++++++++++++
>  drivers/net/ethernet/freescale/dpaa2/dpmac-cmd.h   | 107 ++++
>  drivers/net/ethernet/freescale/dpaa2/dpmac.c       | 369 ++++++++++++++
>  drivers/net/ethernet/freescale/dpaa2/dpmac.h       | 210 ++++++++
>  drivers/net/ethernet/freescale/dpaa2/dpni-cmd.h    |  35 ++
>  drivers/net/ethernet/freescale/dpaa2/dpni.c        |  70 +++
>  drivers/net/ethernet/freescale/dpaa2/dpni.h        |  27 +
>  drivers/net/phy/phylink.c                          |   1 +
>  14 files changed, 1612 insertions(+), 14 deletions(-)
>  create mode 100644 Documentation/networking/device_drivers/freescale/dpaa2/dpmac-driver.rst
>  create mode 100644 drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
>  create mode 100644 drivers/net/ethernet/freescale/dpaa2/dpmac-cmd.h
>  create mode 100644 drivers/net/ethernet/freescale/dpaa2/dpmac.c
>  create mode 100644 drivers/net/ethernet/freescale/dpaa2/dpmac.h
> 
> -- 
> 1.9.1
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up