[PATCH 09/14] net: ravb: Support up to two instances

[Marek Vasut]

On 12/5/24 8:12 PM, Paul Barker wrote:
> Hi Marek,
> 
> On 28/10/2024 09:50, Paul Barker wrote:
>> On 27/10/2024 16:25, Marek Vasut wrote:
>>> On 10/24/24 5:24 PM, Paul Barker wrote:
>>>>    int ravb_of_to_plat(struct udevice *dev)
>>>>    {
>>>>    	struct eth_pdata *pdata = dev_get_plat(dev);
>>>> -	const fdt32_t *cell;
>>>> +
>>>> +	if (bb_miiphy_index >= bb_miiphy_buses_num) {
>>>> +		dev_err(dev, "ravb driver supports only 1 or 2 devices!\n");
>>> Hmmmm, I really do not like this, can we make this dynamic ?
>>>
>>> Unless you want to take a look at this yourself, I can add it into my todo ?
>>
>> I think the real solution here would be to separate the bb_miiphy
>> operations from the bus instance, so we would have something like:
>>
>>      struct bb_miiphy_bus {
>>          struct bb_miiphy_ops *ops;
>>          void *priv;
>>      };
>>
>>      struct bb_miiphy_ops {
>>          int (*init)(struct bb_miiphy_bus *bus);
>>          int (*mdio_active)(struct bb_miiphy_bus *bus);
>>          int (*mdio_tristate)(struct bb_miiphy_bus *bus);
>>          int (*set_mdio)(struct bb_miiphy_bus *bus, int v);
>>          int (*get_mdio)(struct bb_miiphy_bus *bus, int *v);
>>          int (*set_mdc)(struct bb_miiphy_bus *bus, int v);
>>          int (*delay)(struct bb_miiphy_bus *bus);
>>      };
>>
>>      int bb_miiphy_bus_register(const char *name,
>>                                 struct bb_miiphy_ops *ops,
>> 			       void *priv);
>>
>> Where drivers will call `bb_miiphy_bus_register()` from the probe
>> function, it will create a `struct bb_miiphy_bus` instance and a
>> `struct mii_dev` instance then call `mdio_register()`. The driver can
>> then support an arbitrary number of MDIO busses from a single constant
>> `struct bb_miiphy_ops` instance.
>>
>> The bb_miiphy_getbus() function should be dropped from miiphy.c.
>> Instead, the priv pointer in the `struct mii_dev` instance can point to
>> the appropriate `struct bb_miiphy_bus` instance.
>>
>> It looks like all users of CONFIG_BITBANGMII also set
>> CONFIG_BITBANGMII_MULTI, and there don't seem to be any targets that
>> define the macros documented in README.bitbangMII (lines 15-22). So, we
>> can drop the non-BITBANGMII_MULTI code from miiphybb.c and simplify
>> things a lot.
>>
>> That's non-trivial but it's not a huge set of changes, maybe something
>> we could target for v2024.04?
> 
> We've got several of the other patches from this series merged now after
> v2 so I'm coming back to this one. I think we should take this patch
> as-is and then follow up with general improvements to the bb_miiphy
> support. Are you happy with that? If so I will re-send it along with a
> re-worked version of patch 11 from this series (net: ravb: Add RZ/G2L
> Support).
I apologize for the horrible delay.

I just posted the bb_miiphy patches so maybe we can do it properly right 
from the start ?