Re: [PATCH 0/4] Driver for talking to PLX PEX8xxx PCIe switch over I2C

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]


> ===========================================================
> ...<snip>...
> 
> +0. Why have an I2C interface to a PCIe switch?
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +Other than the regular PCI express interface, most modern PCIe switches (e.g.
> +from IDT and PLX) have an I2C based secondary interface. This interface allows
> +access to all the registers of the switch. Some of these registers may not even
> +be accessible over the regular PCI interface. Also, there are certain registers
> +that can be written to, using only the I2C interface and may only be read-only
> +using the PCI interface.
> +
> +This I2C interface is often used in designs involving these switches, and can
> +be used for a variety of use cases where the switch needs to be configured
> +independent of the PCI subsystem (and likely before PCI enumeration). Some
> +examples:
> +
> +* Dividing a PCIe switch into multiple "virtual" switches. Using this feature,
> +  a switch could be connected to 2 root ports for instance, each managing its
> +  own PCI hierarchy, and the traffic from one virtual switch does not leak into
> +  another.
> +
> +* Managing Transparent / Non-transparent bridging, and changing them
> on-the-fly.
> +  There are ports that can be converted into "Non-transparent" bridge ports.
> +  Essentially this is used to create different domains (not visible to
> +  software). In a dynamic distributed system, it may be desirable to change a
> +  transparent bridge to non-transparent or vice versa, for example, to handle a
> +  failover situation.
> +
> +* Buggy hardware / Bad EEPROM configuration. There may be cases where an errata
> +  involving register writes need to be applied before enumerating over PCI.
> +  Also these switches are typically attached to an EEPROM that is supposed to
> +  initialize the switch. If that EEPROM is not present, or contains bad
> +  initialization data, this I2C interface can be used to fix that.
> +
> +* Changing switch configuration on the fly. In a multi-homed or complex
> +  distributed systemsystem, there may be a need to change the switch
> +  configuration (eg. change the upstream port, or the port or lane
> +  configuration etc) to address run time scenarios (CPU plug out etc).
> +
> 
> ...<snip>...
> ===========================================================
> 
> I am myself leaning towards drivers/pci/switch/. And am wanting to
> hear what other think.

I had a closer look and my first question is now if we really need a
kernel driver for this?

The sysfs interface is basically to PEEK/POKE registers of the switch.
How registers get accessed is part of userspace. Well, then it might
even be easier to construct the proper i2c messages in userspace, too,
and send them via i2c-dev (instead of writing to various files in
sysfs).

The Kernel API is also PEEK/POKE register. I am not an PCI expert, but I
can't see a user in this form. What I'd expect would be more like

pci_switch_set_mode(some_device, PCI_BRIDGE_MODE_TRANSPARENT);

and then a shim layer would make sure the proper driver for the switch
sends the proper commands. Again, I don't know if the decision of
setting a mode/creating virtual switches... is even desirable in kernel
space. If so, then this is probably a sub-subsystem
drivers/pci/switches, but needs way more abstraction. Otherwise,
userspace will currently do IMO.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]