On 19.12.2023 20:40, Sergey Shtylyov wrote: > On 12/17/23 3:49 PM, claudiu beznea wrote: > > [...] >>>> From: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> >>>> >>>> Delay parse and set were done in the driver's probe API. As some IP >>> >>> Parsing and setting? >>> >>>> variants switch to reset mode (and thus registers' content is lost) when >>> >>> Register. >>> >>>> setting clocks (due to module standby functionality) to be able to >>>> implement runtime PM keep the delay parsing in the driver's probe function >>>> and move the delay apply function to the driver's ndo_open API. >>> >>> Applying? >>> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> >>> [...] >>> >>>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c >>>> index 5e01e03e1b43..04eaa1967651 100644 >>>> --- a/drivers/net/ethernet/renesas/ravb_main.c >>>> +++ b/drivers/net/ethernet/renesas/ravb_main.c >>> [...] >>>> @@ -1806,6 +1821,8 @@ static int ravb_open(struct net_device *ndev) >>>> if (info->nc_queues) >>>> napi_enable(&priv->napi[RAVB_NC]); >>>> >>>> + ravb_set_delay_mode(ndev); >>>> + >>> >>> I suspect this belongs in ravb_dmac_init() now... >> >> I'm confused... Why? To me this seems more like MAC-PHY interface related. > > APSR's full name is AVB-DMAC product specific register. :-) As ravb_dmac_init() is called in multiple places I don't think it worth configuring delays more than once in ravb_open(). Moreover TX/RX delay is something specific to the MAC-PHY interface (and could be influenced also by the wiring length b/w MAC and PHY). Just because it is in the DMAC address space I don't think it worth having it in ravb_dmac_init() (for the above mentioned reasons). > >> Though I'm not sure what ravb_dmac_init() purpose is. > > To configure and start the AVB-DMAC, apparently. :-) > > [...] > > MRB, Sergey
