netdev - Re: [PATCH net-next v2 09/21] net: ravb: Split GTI computation and set operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 17 Dec 2023 14:40:39 +0200
From: claudiu beznea <claudiu.beznea@...on.dev>
To: Sergey Shtylyov <s.shtylyov@....ru>, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
 richardcochran@...il.com, p.zabel@...gutronix.de,
 yoshihiro.shimoda.uh@...esas.com, wsa+renesas@...g-engineering.com,
 geert+renesas@...der.be
Cc: netdev@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH net-next v2 09/21] net: ravb: Split GTI computation and
 set operations



On 16.12.2023 18:38, Sergey Shtylyov wrote:
> On 12/14/23 2:45 PM, Claudiu wrote:
> 
>> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>
>> ravb_set_gti() was computing the value of GTI based on the reference clock
>> rate and then applied it to register. This was done on the driver's probe
>> function. In order to implement runtime PM for all IP variants (as some IP
>> variants switches to reset operation mode (and thus the register's content
> 
>    Again, operating mode...
> 
>> is lost) when module standby is configured through clock APIs) the GTI was
> 
>    The GTI what? Setup?
> 
>> split in 2 parts: one computing the value of the GTI register (done in the
>> driver's probe function) and one applying the computed value to register
>> (done in the driver's ndo_open API).
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> [...]
> 
>> diff --git a/drivers/net/ethernet/renesas/ravb.h b/drivers/net/ethernet/renesas/ravb.h
>> index e0f8276cffed..76202395b68d 100644
>> --- a/drivers/net/ethernet/renesas/ravb.h
>> +++ b/drivers/net/ethernet/renesas/ravb.h
>> @@ -1106,6 +1106,8 @@ struct ravb_private {
>>  
>>  	const struct ravb_hw_info *info;
>>  	struct reset_control *rstc;
>> +
>> +	uint64_t gti_tiv;
> 
>    Please use the kernel type, u64; uint64_t is for userland, IIRC.

I just kept the initial type here. Anyway, uint64_t should translate to u64
AFAICT.

Looking at it again the field here is enough to be 32 bit as the register
field is no longer than that. It is needed on 64 bits when checking the
ranges in compute function.

> 
> [...]
>> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
>> index d7f6e8ea8e79..5e01e03e1b43 100644
>> --- a/drivers/net/ethernet/renesas/ravb_main.c
>> +++ b/drivers/net/ethernet/renesas/ravb_main.c
>> @@ -1750,6 +1750,51 @@ static int ravb_set_reset_mode(struct net_device *ndev)
>>  	return error;
>>  }
>>  
>> +static int ravb_set_gti(struct net_device *ndev)
>> +{
> [...]
>> +	/* Request GTI loading */
>> +	ravb_modify(ndev, GCCR, GCCR_LTI, GCCR_LTI);
>> +
>> +	/* Check completion status. */
>> +	return ravb_wait(ndev, GCCR, GCCR_LTI, 0);
> 
>    Is this really necessary?

I've just updated it to respect the manual specifications. Please let me
know if you want me to drop it. For this series it should be harmless
keeping it as it was previously (I will double check it).

> 
> [...]
>> @@ -1767,6 +1812,10 @@ static int ravb_open(struct net_device *ndev)
>>  		goto out_napi_off;
>>  	ravb_emac_init(ndev);
>>  
>> +	error = ravb_set_gti(ndev);
>> +	if (error)
>> +		goto out_dma_stop;
>> +
> 
>    Hm... belongs in ravb_dmac_init() now, as it seems... 

Isn't it PTP specific?

> 
> [...]
> 
> MBR, Sergey