netdev - RE: [RFC/PATCH 06/18] ravb: Add multi_tsrq to struct ravb_hw

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]

Message-ID: <OS0PR01MB5922135B7F17FDE3F4C6091A86A49@OS0PR01MB5922.jpnprd01.prod.outlook.com>
Date:   Fri, 24 Sep 2021 06:19:26 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Sergey Shtylyov <s.shtylyov@....ru>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
CC:     Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
        Andrew Lunn <andrew@...n.ch>,
        Sergei Shtylyov <sergei.shtylyov@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Adam Ford <aford173@...il.com>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Biju Das <biju.das@...renesas.com>
Subject: RE: [RFC/PATCH 06/18] ravb: Add multi_tsrq to struct ravb_hw_info

Hi Sergei,

Thanks for the feedback.

> Subject: Re: [RFC/PATCH 06/18] ravb: Add multi_tsrq to struct ravb_hw_info
> 
> On 9/23/21 5:08 PM, Biju Das wrote:
> 
> > R-Car AVB-DMAC has 4 Transmit start Request queues, whereas RZ/G2L has
> > only 1 Transmit start Request queue(Best Effort)
> >
> > Add a multi_tsrq hw feature bit to struct ravb_hw_info to enable this
> > only for R-Car. This will allow us to add single TSRQ support for
> > RZ/G2L.
> >
> > Signed-off-by: Biju Das <biju.das.jz@...renesas.com>
> > ---
> >  drivers/net/ethernet/renesas/ravb.h      |  1 +
> >  drivers/net/ethernet/renesas/ravb_main.c | 12 ++++++++++--
> >  2 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/renesas/ravb.h
> > b/drivers/net/ethernet/renesas/ravb.h
> > index bb92469d770e..c043ee555be4 100644
> > --- a/drivers/net/ethernet/renesas/ravb.h
> > +++ b/drivers/net/ethernet/renesas/ravb.h
> > @@ -1006,6 +1006,7 @@ struct ravb_hw_info {
> >  	unsigned multi_irqs:1;		/* AVB-DMAC and E-MAC has multiple
> irqs */
> >  	unsigned no_gptp:1;		/* AVB-DMAC does not support gPTP
> feature */
> >  	unsigned ccc_gac:1;		/* AVB-DMAC has gPTP support active in
> config mode */
> > +	unsigned multi_tsrq:1;		/* AVB-DMAC has MULTI TSRQ */
> 
>    Maybe 'single_tx_q' instead? 

Since it is called transmit start request queue, it is better to be named as single_tsrq
to match with hardware manual and I will update the comment with "GbEthernet DMAC has single TSRQ"
Please let me know are you ok with it. Other wise I would like to use existing name.

> 
> >  };
> >
> >  struct ravb_private {
> > diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> > b/drivers/net/ethernet/renesas/ravb_main.c
> > index 8663d83507a0..d37d73f6d984 100644
> > --- a/drivers/net/ethernet/renesas/ravb_main.c
> > +++ b/drivers/net/ethernet/renesas/ravb_main.c
> > @@ -776,11 +776,17 @@ static void ravb_rcv_snd_enable(struct
> > net_device *ndev)
> >  /* function for waiting dma process finished */  static int
> > ravb_stop_dma(struct net_device *ndev)  {
> > +	struct ravb_private *priv = netdev_priv(ndev);
> > +	const struct ravb_hw_info *info = priv->info;
> >  	int error;
> >
> >  	/* Wait for stopping the hardware TX process */
> > -	error = ravb_wait(ndev, TCCR,
> > -			  TCCR_TSRQ0 | TCCR_TSRQ1 | TCCR_TSRQ2 | TCCR_TSRQ3, 0);
> > +	if (info->multi_tsrq)
> > +		error = ravb_wait(ndev, TCCR,
> > +				  TCCR_TSRQ0 | TCCR_TSRQ1 | TCCR_TSRQ2 |
> TCCR_TSRQ3, 0);
> > +	else
> > +		error = ravb_wait(ndev, TCCR, TCCR_TSRQ0, 0);
> 
>    Aren't the TSRQ1/2/3 bits reserved on RZ/G2L? If so, this new flag adds
> a little value, I think... unless you plan to use this flag further in the
> series?

It will be confusing for RZ/G2L users. HW manual does not describes TSRQ1/2/3
and we are writing undocumented registers which is reserved.

Tomorrow it can happen that this reserved bits(90% it will not happen) will be used for describing something else.

It is unsafe to use reserved bits. Are you agreeing with this?

Regards,
Biju

> 
> MBR, Sergei