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

[Paul Barker]

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).

Thanks,

-- 
Paul Barker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x27F4B3459F002257.asc
Type: application/pgp-keys
Size: 3520 bytes
Desc: OpenPGP public key
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241205/a82e7ec6/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241205/a82e7ec6/attachment-0001.sig>