linux-kernel - Re: [PATCH] net: fec: limit register access on i.MX6UL

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] [day] [month] [year] [list]

Message-ID: <caaf147aeb71d69d767cc8509809a2770d297cb9.camel@pengutronix.de>
Date:   Mon, 24 Oct 2022 09:42:44 +0200
From:   Juergen Borleis <jbe@...gutronix.de>
To:     Marco Felsch <m.felsch@...gutronix.de>,
        Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...gutronix.de
Subject: Re: [PATCH] net: fec: limit register access on i.MX6UL

Am Dienstag, dem 20.09.2022 um 14:50 +0200 schrieb Marco Felsch:
> On 22-09-20, Andrew Lunn wrote:
> > > +/* for i.MX6ul */
> > > +static u32 fec_enet_register_offset_6ul[] = {
> > > +       FEC_IEVENT, FEC_IMASK, FEC_R_DES_ACTIVE_0, FEC_X_DES_ACTIVE_0,
> > > +       FEC_ECNTRL, FEC_MII_DATA, FEC_MII_SPEED, FEC_MIB_CTRLSTAT,
> > > FEC_R_CNTRL,
> > > +       FEC_X_CNTRL, FEC_ADDR_LOW, FEC_ADDR_HIGH, FEC_OPD, FEC_TXIC0,
> > > FEC_RXIC0,
> > > +       FEC_HASH_TABLE_HIGH, FEC_HASH_TABLE_LOW, FEC_GRP_HASH_TABLE_HIGH,
> > > +       FEC_GRP_HASH_TABLE_LOW, FEC_X_WMRK, FEC_R_DES_START_0,
> > > +       FEC_X_DES_START_0, FEC_R_BUFF_SIZE_0, FEC_R_FIFO_RSFL,
> > > FEC_R_FIFO_RSEM,
> > > +       FEC_R_FIFO_RAEM, FEC_R_FIFO_RAFL, FEC_RACC,
> > > +       RMON_T_DROP, RMON_T_PACKETS, RMON_T_BC_PKT, RMON_T_MC_PKT,
> > > +       RMON_T_CRC_ALIGN, RMON_T_UNDERSIZE, RMON_T_OVERSIZE, RMON_T_FRAG,
> > > +       RMON_T_JAB, RMON_T_COL, RMON_T_P64, RMON_T_P65TO127,
> > > RMON_T_P128TO255,
> > > +       RMON_T_P256TO511, RMON_T_P512TO1023, RMON_T_P1024TO2047,
> > > +       RMON_T_P_GTE2048, RMON_T_OCTETS,
> > > +       IEEE_T_DROP, IEEE_T_FRAME_OK, IEEE_T_1COL, IEEE_T_MCOL,
> > > IEEE_T_DEF,
> > > +       IEEE_T_LCOL, IEEE_T_EXCOL, IEEE_T_MACERR, IEEE_T_CSERR,
> > > IEEE_T_SQE,
> > > +       IEEE_T_FDXFC, IEEE_T_OCTETS_OK,
> > > +       RMON_R_PACKETS, RMON_R_BC_PKT, RMON_R_MC_PKT, RMON_R_CRC_ALIGN,
> > > +       RMON_R_UNDERSIZE, RMON_R_OVERSIZE, RMON_R_FRAG, RMON_R_JAB,
> > > +       RMON_R_RESVD_O, RMON_R_P64, RMON_R_P65TO127, RMON_R_P128TO255,
> > > +       RMON_R_P256TO511, RMON_R_P512TO1023, RMON_R_P1024TO2047,
> > > +       RMON_R_P_GTE2048, RMON_R_OCTETS,
> > > +       IEEE_R_DROP, IEEE_R_FRAME_OK, IEEE_R_CRC, IEEE_R_ALIGN,
> > > IEEE_R_MACERR,
> > > +       IEEE_R_FDXFC, IEEE_R_OCTETS_OK
> > > +};
> > >  #else
> > >  static __u32 fec_enet_register_version = 1;
> > 
> > Seeing this, i wonder if the i.MX6ul needs its own register version,
> > so that ethtool(1) knows what registers are valid?
> 
> Regarding the uAPI (uapi/linux/ethtool.h):
> 8<-------------------------------------------------
>  * @version: Dump format version.  This is driver-specific and may
>  *      distinguish different chips/revisions.  Drivers must use new
>  *      version numbers whenever the dump format changes in an
>  *      incompatible way.
> 8<-------------------------------------------------
> I would say yes.

But there is no format change. Only a value change. Where the i.MX6 may report a
value, the i.MX6UL just reports a zero.

jb

-- 
Pengutronix e.K.                       | Juergen Borleis             |
Steuerwalder Str. 21                   | https://www.pengutronix.de/ |
31137 Hildesheim, Germany              | Phone: +49-5121-206917-128  |
Amtsgericht Hildesheim, HRA 2686       | Fax:   +49-5121-206917-9    |