netdev - Re: [PATCH v4 05/10] net/fec: add dual fec support for mx28

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: <20110114075223.GC24920@pengutronix.de>
Date:	Fri, 14 Jan 2011 08:52:23 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Shawn Guo <shawn.guo@...escale.com>
Cc:	davem@...emloft.net, gerg@...pgear.com, baruch@...s.co.il,
	eric@...rea.com, bryan.wu@...onical.com, r64343@...escale.com,
	B32542@...escale.com, lw@...o-electronics.de,
	w.sang@...gutronix.de, s.hauer@...gutronix.de, jamie@...ieiles.com,
	jamie@...reable.org, netdev@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v4 05/10] net/fec: add dual fec support for mx28

On Fri, Jan 14, 2011 at 01:48:40PM +0800, Shawn Guo wrote:
> Hi Uwe,
> 
> On Thu, Jan 13, 2011 at 03:48:05PM +0100, Uwe Kleine-König wrote:
> 
> [...]
> 
> > > +/* Controller is ENET-MAC */
> > > +#define FEC_QUIRK_ENET_MAC           (1 << 0)
> > does this really qualify to be a quirk?
> > 
> My understanding is that ENET-MAC is a type of "quirky" FEC
> controller.
> 
> > > +/* Controller needs driver to swap frame */
> > > +#define FEC_QUIRK_SWAP_FRAME         (1 << 1)
> > IMHO this is a bit misnamed.  FEC_QUIRK_NEEDS_BE_DATA or similar would
> > be more accurate.
> > 
> When your make this change, you may want to pick a better name for
> function swap_buffer too.
> 
> [...]
> 
> > > +static void *swap_buffer(void *bufaddr, int len)
> > > +{
> > > +     int i;
> > > +     unsigned int *buf = bufaddr;
> > > +
> > > +     for (i = 0; i < (len + 3) / 4; i++, buf++)
> > > +             *buf = cpu_to_be32(*buf);
> > if len isn't a multiple of 4 this accesses bytes behind len.  Is this
> > generally OK here?  (E.g. because skbs always have a length that is a
> > multiple of 4?)
> The len may not be a multiple of 4.  But I believe bufaddr is always
> a buffer allocated in a length that is a multiple of 4, and the 1~3
> bytes exceeding the len very likely has no data that matters.  But
> yes, it deserves a safer implementation.
Did you test what happens if bufaddr isn't aligned?  Does it work at all
then?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html