On 11/30/18 11:34 AM, Andrew Lunn wrote:

quoted

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.

quoted

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.