Re: [PATCH v3 net-next 2/2] net: dsa: Add support for Motorcomm YT922x

[Andrew Lunn <andrew@lunn.ch>]

> I would also like to seek your advice on a design question.
> For the yt92xx_series_info table, the maveall reference design invokes
> chip_detect() inside probe() to perform the matching lookup.
> However, in the existing yt921x DSA driver, chip_detect() is called within
> dsa_setup() instead.
> 
> We are considering two possible approaches:
> 1. Keep the code as-is and relocate the initialization of certain
> dsa_switch structure parameters into dsa_setup().
> 2. Refactor by moving chip_detect() into probe() to align with
> the reference design.
> 
> Which of these two approaches would you lean toward,
> and what are your considerations?

There is some advantage in postponing as much as possible to
later. The DSA design when used with MDIO to control the switch has a
chicken/egg problem.

The conduit MAC driver probes, and first creates its MDIO bus. The bus
is walked and the devices on the bus probe. Meaning the switch driver
probes. At this time, if you can detect if the switch exists, cheaply,
do it, so you can return -ENODEV. However, don't do anything
expensive, because... the switch driver registers the switch with the
DSA framework. The DSA core pokes around in the DT description and
looks for the phandle to the conduit interface. It wants to take a
reference on the interface, but finds it does not exist yet. So the
DSA core returns -EPROBE_DEFER. The switch probe unwinds, and returns
-EPROBE_DEFER.

The registration of the MDIO bus completes, without error, because bus
and devices on the bus have different lifetimes. This allows the MAC
driver to continue and it will eventually register the interface.

Sometime later the driver core will reprobe the switch, and this time
it succeeds.

So avoid doing expensive things early in probe, because you will have
to do it again later.

   Andrew