linux-kernel - Re: [RFC 10/10] net: sfp: add support for fwnode

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]

Message-ID: <YhYpLJPXxAm0FEtm@lunn.ch>
Date:   Wed, 23 Feb 2022 13:31:40 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Clément Léger <clement.leger@...tlin.com>,
        Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        Wolfram Sang <wsa@...nel.org>, Peter Rosin <peda@...ntia.se>,
        Russell King <linux@...linux.org.uk>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, linux-i2c@...r.kernel.org,
        netdev@...r.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>
Subject: Re: [RFC 10/10] net: sfp: add support for fwnode

> If I understand this series correctly then this is about a PCI-E card
> which has an I2C controller on the card and behind that I2C-controller
> there are a couple if I2C muxes + I2C clients.

They are not i2c clients in the normal sense. The i2c bus connects to
an SFP cage. You can hot plug different sort of network modules into
the cage. So for example fibre optic modules or copper modules. The
modules have an 'at24' like block of memory, which is a mix of EEPROM
and status values. For copper modules, there is an MDIO over I2C
protocol which allows access to the Copper Ethernet PHY inside the
module.

The current device tree binding is that you have a node for the SFP
cage, which includes a phandle to the i2c bus, plus a list of GPIOs
connected to pins on the SFP cage. The SFP driver will then directly
access the memory, maybe instantiate an mdio-over-i2c device if
needed, and control the GPIOs. The Ethernet driver then has an OF node
with a phandle pointing to the SFP device.

The whole design of this is based around the hardware being a
collection of standard parts, i2c bus, i2c mux, gpio controller,
ethernet controller, each with their own driver as part of a linux
subsystem, and then having some glue to put all the parts
together. And at the moment, that glue is DT.

> Note the above all relies on my interpretation of this patch set,
> which may be wrong, since as said the patch-set does seem to be
> lacking when it comes to documentation / motivation of the patches.

I think some examples from DT will help with this.

  Andrew