netdev - Re: [PATCH net-next v2 2/2] amd-xgbe: add support for rx-adaptation

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 02 Feb 2023 15:16:50 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Simon Horman <simon.horman@...igine.com>,
        Raju Rangoju <Raju.Rangoju@....com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuba@...nel.org,
        edumazet@...gle.com, Shyam-sundar.S-k@....com
Subject: Re: [PATCH net-next v2 2/2] amd-xgbe: add support for rx-adaptation

On Wed, 2023-02-01 at 18:11 +0100, Simon Horman wrote:
> On Wed, Feb 01, 2023 at 11:19:32AM +0530, Raju Rangoju wrote:
> > The existing implementation for non-Autonegotiation 10G speed modes does
> > not enable RX adaptation in the Driver and FW. The RX Equalization
> > settings (AFE settings alone) are manually configured and the existing
> > link-up sequence in the driver does not perform rx adaptation process as
> > mentioned in the Synopsys databook. There's a customer request for 10G
> > backplane mode without Auto-negotiation and for the DAC cables of more
> > significant length that follow the non-Autonegotiation mode. These modes
> > require PHY to perform RX Adaptation.
> > 
> > The proposed logic adds the necessary changes to Yellow Carp devices to
> > ensure seamless RX Adaptation for 10G-SFI (LONG DAC) and 10G-KR without
> > AN (CL72 not present). The RX adaptation core algorithm is executed by
> > firmware, however, to achieve that a new mailbox sub-command is required
> > to be sent by the driver.
> > 
> > Co-developed-by: Shyam Sundar S K <Shyam-sundar.S-k@....com>
> > Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@....com>
> > Signed-off-by: Raju Rangoju <Raju.Rangoju@....com>
> 
> ...
> 
> > diff --git a/drivers/net/ethernet/amd/xgbe/xgbe.h b/drivers/net/ethernet/amd/xgbe/xgbe.h
> > index 16e73df3e9b9..ad136ed493ed 100644
> > --- a/drivers/net/ethernet/amd/xgbe/xgbe.h
> > +++ b/drivers/net/ethernet/amd/xgbe/xgbe.h
> > @@ -625,6 +625,7 @@ enum xgbe_mb_cmd {
> >  
> >  enum xgbe_mb_subcmd {
> >  	XGBE_MB_SUBCMD_NONE = 0,
> > +	XGBE_MB_SUBCMD_RX_ADAP,
> >  
> >  	/* 10GbE SFP subcommands */
> >  	XGBE_MB_SUBCMD_ACTIVE = 0,
> > @@ -1316,6 +1317,10 @@ struct xgbe_prv_data {
> >  
> >  	bool debugfs_an_cdr_workaround;
> >  	bool debugfs_an_cdr_track_early;
> > +	bool en_rx_adap;
> 
> nit: there is a 1 byte hole here (on x86_64)

I think even in the current form is ok. The total size of the struct is
not going to change, due to alignment, and the fields will sit in the
same cacheline in both cases.

I guess the layout could be changed later if needed.

Thanks,

Paolo