On 11/30/18 11:34 AM, Andrew Lunn wrote: >> Yep, registering multiple interfaces is wrong. The first board I tested >> against only had a single MAC enabled (they can be disabled/hidden via >> straps) so it just happened to work. > > Hi Steve > > Can you hide any/all via straps, or is 00.0 always guaranteed to > exist?
You can hide all the devices, but if function 1 is enabled then function 0 must also be enabled, so not all combinations are valid. >> The Intel C3xxx family of SoCs have up to four ixgbe MACs. These are >> structured as two devices of two functions each on fixed internal root >> ports. >> >> from lspci: >> <snip> >> +-16.0-[05]--+-00.0 >> | \-00.1 >> +-17.0-[06]--+-00.0 >> | \-00.1 >> <snip> > > Is there any other hardware resource which is shared between the MAC > interfaces? I'm just wondering if the driver has already solved this > once. Is there an EEPROM per interface for the MAC address, or one > shared EEPROM? NVM is shared, it's actually the same SPI flash that holds the BIOS for this SoC. Access is serialized by the swfw_sync semaphore. I think the device firmware is automagically handling offset translation. I don't think that helps for this case. There might be a better match for shared resources, but nothing springs to mind. > Ah, how about using the 'cards_found' found variable. It is not > perfect, in that it is not decremented in ixgb_remove(), and i wonder > about race conditions since there does not appear to be any lock when > it is incremented. But if cards_found == 0, register the MDIO bus. 'cards_found' doesn't exist for the ixgbe driver. I could add it and fix the race/decrement issues you mention, but it'd have to be a device type specific count. It's still possible there are other non-x550em_a ixgbe devices in external PCIe slots that have different resource sharing setups. It's still a lighter weight solution than poking around the parent bus so I'll add a 'x550em_a_devs_found' counter to v2.
