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: <OS0PR01MB592237144A680FEC1E7C013586A69@OS0PR01MB5922.jpnprd01.prod.outlook.com>
Date:   Sun, 26 Sep 2021 13:54:56 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Biju Das <biju.das.jz@...renesas.com>,
        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,

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

On the next revision as you proposed for [1],
I will use a u32 tsrq, instead of bit, there by we can avoid a check.

https://patchwork.kernel.org/project/linux-renesas-soc/patch/20210923140813.13541-12-biju.das.jz@bp.renesas.com/
> 
> >
> > >  };
> > >
> > >  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?

As per the above discussion, we can replace the above check as you proposed for [1]

error = ravb_wait(ndev, TCCR, info->tsrq, 0);

[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20210923140813.13541-12-biju.das.jz@bp.renesas.com/

regards,
Biju