sff: Add SFP driver (fdt-based draft)

[dsl]

Summary

This basic version of the driver obtains properties of the "sff,sfp"
compatible devices and implements a simple inteface to provide an I2C
bus device for the rest of the drivers (e.g. to implement SIOCGI2C).

Both of the interface and driver are subjects for a further
generalization to be used in case of non-FDT and non-arm64 platforms.

Test Plan

This simple driver is a part of a bigger work to support SFP transceivers connected to DPAA2 MACs. Connection between DPMAC and SFP can be described in FDT as:

/* XG1 - Upper SFP */
&dpmac1 {
        sfp = <&sfp_xg1>;
        pcs-handle = <&pcs1>;
        phy-connection-type = "10gbase-r";
        managed = "in-band-status";
};
...
sfp_xg1: dpmac1-sfp {
        compatible = "sff,sfp";
        i2c-bus = <&sfpupper_i2c>;
        tx-fault-gpios = <&sfpgpio 4 GPIO_ACTIVE_HIGH>;
        tx-disable-gpios = <&sfpgpio 5 GPIO_ACTIVE_HIGH>;
        mod-def0-gpios = <&sfpgpio 6 GPIO_ACTIVE_LOW>;
        los-gpios = <&sfpgpio 7 GPIO_ACTIVE_HIGH>;
        maximum-power-milliwatt = <2000>;
};

As soon as "sff,sfp" are real devices and not a part of the DPAA2, I've decided to support them in a separate driver. Note that there are "sff,sff" compatible FDT nodes which describe soldered-down SFF modules which aren't supported by the driver.

from Traverse Ten64:

root@guardian:~ # dmesg | grep sfp
FreeBSD 14.0-CURRENT aarch64 1400093 #26 sfp-n264498-bfc96387de9e: Sat Aug 12 21:20:14 CEST 2023
sfp_fdt0: <Small Form-factor Pluggable Transceiver> on ofwbus0
sfp_fdt1: <Small Form-factor Pluggable Transceiver> on ofwbus0
dpaa2_mac_fdt0: node 0x4674 'ethernet@1': reg 0x1 sfp 0x5170 pcs-handle 0x3c70 phy-handle 0 managed 'in-band-status' phy-conn-type '10gbase-r'
dpaa2_mac_fdt1: node 0x470c 'ethernet@2': reg 0x2 sfp 0x50b8 pcs-handle 0x3d3c phy-handle 0 managed 'in-band-status' phy-conn-type '10gbase-r'
dpaa2_mac_fdt2: node 0x47a4 'ethernet@3': reg 0x3 sfp 0 pcs-handle 0x3e08 phy-handle 0x3a64 managed 'in-band-status' phy-conn-type 'qsgmii'
dpaa2_mac_fdt3: node 0x4838 'ethernet@4': reg 0x4 sfp 0 pcs-handle 0x3e40 phy-handle 0x3a9c managed 'in-band-status' phy-conn-type 'qsgmii'
dpaa2_mac_fdt4: node 0x48cc 'ethernet@5': reg 0x5 sfp 0 pcs-handle 0x3e78 phy-handle 0x3ad4 managed 'in-band-status' phy-conn-type 'qsgmii'
dpaa2_mac_fdt5: node 0x4960 'ethernet@6': reg 0x6 sfp 0 pcs-handle 0x3eb0 phy-handle 0x3b0c managed 'in-band-status' phy-conn-type 'qsgmii'
dpaa2_mac_fdt6: node 0x49f4 'ethernet@7': reg 0x7 sfp 0 pcs-handle 0x3f7c phy-handle 0x3984 managed 'in-band-status' phy-conn-type 'qsgmii'
dpaa2_mac_fdt7: node 0x4a88 'ethernet@8': reg 0x8 sfp 0 pcs-handle 0x3fb4 phy-handle 0x39bc managed 'in-band-status' phy-conn-type 'qsgmii'
dpaa2_mac_fdt8: node 0x4b1c 'ethernet@9': reg 0x9 sfp 0 pcs-handle 0x3fec phy-handle 0x39f4 managed 'in-band-status' phy-conn-type 'qsgmii'
dpaa2_mac_fdt9: node 0x4bb0 'ethernet@a': reg 0xa sfp 0 pcs-handle 0x4024 phy-handle 0x3a2c managed 'in-band-status' phy-conn-type 'qsgmii'

[manu]

What's your plan for the interface for this ?
I see that you use DEFINE_CLASS_0 so this can be subclassed and also that you use OF_device_register_xref so that drivers can talk to this driver but I don't see any interface done for now.

[dsl]

@manu, I'll need the only method in sff_if.m for now to implement SIOCGI2C in dpaa2_ni.c. I haven't ever worked with SFF/SFP modules and not sure what registers in their EEPROM or GPIO pins have to be tinkered with in order to let them start properly. This is the reason for such a draft instead of a fully fledged driver.

[manu]

In D41440#943825, @dsl wrote:

@manu, I'll need the only method in sff_if.m for now to implement SIOCGI2C in dpaa2_ni.c. I haven't ever worked with SFF/SFP modules and not sure what registers in their EEPROM or GPIO pins have to be tinkered with in order to let them start properly. This is the reason for such a draft instead of a fully fledged driver.

I somehow missed this interface sorry ...
LGTM then, we can always expand the interface later.

[dsl]

I somehow missed this interface sorry ...

It's because I forgot to extract it from my SFP pieces and add in the original revision :)

LGTM then, we can always expand the interface later.

Thanks!

[bz]

Can you please adjust the description of the review as well to have a proper (and wrapped) suggested commit messages?

sys/dev/sff/sfp_fdt.c

66

No { } block needed for a single statement.

117

No { } block needed for a single statement

128

In general we don't do assignments in declarations. sfp_fdt_attach() looks better that way.

131

In general I'd do the logic the other way round:

if (xdev == NULL)

return (ENXIO);

*i2c_bus = xdev;
return (0);

Do we need to make sure that i2c_bus is != NULL? Probably and early catch in the function or a KASSERT?

sys/modules/Makefile

680

If we do expand this wisely than a lot of NIC drivers can make use of it (in the non-fdt cases) and it'll be used on non-arm64 as well then. But I assume we'll leave that for another day.

[bz]

Approved by: bz (mentor)

[dsl]

$FreeBSD$ removed