GENET has historically had to create a MDIO platform device for its
controller and pass some auxiliary data to it, like a MDIO completion
callback. Now we also pass the "main" clock to allow for the MDIO bus
controller to manage that clock adequately around I/O accesses.
Signed-off-by: Florian Fainelli <[email protected]>
---
drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index cbbe004621bc..7a21950da77c 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -476,6 +476,10 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv)
ppd.wait_func = bcmgenet_mii_wait;
ppd.wait_func_data = priv;
ppd.bus_name = "bcmgenet MII bus";
+ /* Pass a reference to our "main" clock which is used for MDIO
+ * transfers
+ */
+ ppd.clk = priv->clk;
/* Unimac MDIO bus controller starts at UniMAC offset + MDIO_CMD
* and is 2 * 32-bits word long, 8 bytes total.
--
2.34.1
On 2/16/2024 10:42 AM, Florian Fainelli wrote:
> GENET has historically had to create a MDIO platform device for its
> controller and pass some auxiliary data to it, like a MDIO completion
> callback. Now we also pass the "main" clock to allow for the MDIO bus
> controller to manage that clock adequately around I/O accesses.
>
> Signed-off-by: Florian Fainelli <[email protected]>
> ---
> drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
> index cbbe004621bc..7a21950da77c 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
> @@ -476,6 +476,10 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv)
> ppd.wait_func = bcmgenet_mii_wait;
> ppd.wait_func_data = priv;
> ppd.bus_name = "bcmgenet MII bus";
> + /* Pass a reference to our "main" clock which is used for MDIO
> + * transfers
> + */
> + ppd.clk = priv->clk;
>
> /* Unimac MDIO bus controller starts at UniMAC offset + MDIO_CMD
> * and is 2 * 32-bits word long, 8 bytes total.
Is this missing a modification of the header file to add the clk field
to struct unimac_mdio_pdata? I don't see that field in the
include/linux/platform_data/mdio-bcm-unimac.h header currently...
Oh. you included that in the first patch of the series. I see.
It feels like the series would be more natural of this was 1/3 instead
of 2/3, since the current 1/3 patch depends on this clk value being set, no?
The result of the series makes sense tho:
Reviewed-by: Jacob Keller <[email protected]>
On 2/16/24 14:41, Jacob Keller wrote:
>
>
> On 2/16/2024 10:42 AM, Florian Fainelli wrote:
>> GENET has historically had to create a MDIO platform device for its
>> controller and pass some auxiliary data to it, like a MDIO completion
>> callback. Now we also pass the "main" clock to allow for the MDIO bus
>> controller to manage that clock adequately around I/O accesses.
>>
>> Signed-off-by: Florian Fainelli <[email protected]>
>> ---
>> drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
>> index cbbe004621bc..7a21950da77c 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
>> @@ -476,6 +476,10 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv)
>> ppd.wait_func = bcmgenet_mii_wait;
>> ppd.wait_func_data = priv;
>> ppd.bus_name = "bcmgenet MII bus";
>> + /* Pass a reference to our "main" clock which is used for MDIO
>> + * transfers
>> + */
>> + ppd.clk = priv->clk;
>>
>> /* Unimac MDIO bus controller starts at UniMAC offset + MDIO_CMD
>> * and is 2 * 32-bits word long, 8 bytes total.
>
> Is this missing a modification of the header file to add the clk field
> to struct unimac_mdio_pdata? I don't see that field in the
> include/linux/platform_data/mdio-bcm-unimac.h header currently...
>
> Oh. you included that in the first patch of the series. I see.
I suppose I could have included it in patch #1, and have introduced in
patch #2 the hunk that dealt with fetching pdata->clk, but since I was
re-organizing the mdio-bcm-unimac.c driver's probe function, it felt
more natural to arrange it that way.
>
> It feels like the series would be more natural of this was 1/3 instead
> of 2/3, since the current 1/3 patch depends on this clk value being set, no?
I sort of debated that with myself, and ended up going with: put the
plumbing first, wire it later, rather than the opposite. If someone was
to run a bisection there would not be any difference in behavior until
patch #2 regardless of their ordering.
>
> The result of the series makes sense tho:
>
> Reviewed-by: Jacob Keller <[email protected]>
Thanks Jacob!
--
Florian
On Fri, Feb 16, 2024 at 10:42:36AM -0800, Florian Fainelli wrote:
> GENET has historically had to create a MDIO platform device for its
> controller and pass some auxiliary data to it, like a MDIO completion
> callback. Now we also pass the "main" clock to allow for the MDIO bus
> controller to manage that clock adequately around I/O accesses.
I guess this code comes from before the times of DT? I would normally
expect to see a clock added to the DT node for the MDIO bus. But if
there is no node, because it is not in DT....
Andrew
Hi Andrew,
On 2/17/2024 7:21 AM, Andrew Lunn wrote:
> On Fri, Feb 16, 2024 at 10:42:36AM -0800, Florian Fainelli wrote:
>> GENET has historically had to create a MDIO platform device for its
>> controller and pass some auxiliary data to it, like a MDIO completion
>> callback. Now we also pass the "main" clock to allow for the MDIO bus
>> controller to manage that clock adequately around I/O accesses.
>
> I guess this code comes from before the times of DT? I would normally
> expect to see a clock added to the DT node for the MDIO bus. But if
> there is no node, because it is not in DT....
The driver started being DT-only from the get go, however it was also my
group's first attempt at upstreaming a driver and we did not get
everything right in terms of the DT binding. In particular there was no
"mdio" sub-node initially, but we still wanted to be able to split up
the MDIO controller part since we knew it was going to be re-used in
other designs (bcm_sf2 and later asp2). The platform device was the best
we could come up with at the time.
All of our DTBs deployed out there do not have a "clocks" property
within the "mdio" sub-mode of the GENET Ethernet node, so that is why we
are doing this.
Thanks!
--
Florian