netdev - Re: [PATCH v2 1/3] net: mvneta: introduce compatible string "marvell, armada-xp-neta"

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: <20150617213926.GE2917@io.lakedaemon.net>
Date:	Wed, 17 Jun 2015 21:39:26 +0000
From:	Jason Cooper <jason@...edaemon.net>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Simon Guinot <simon.guinot@...uanux.org>,
	Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
	Vincent Donnefort <vdonnefort@...il.com>,
	stable@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH v2 1/3] net: mvneta: introduce compatible string
 "marvell, armada-xp-neta"

Hey Thomas,

On Wed, Jun 17, 2015 at 10:43:12PM +0200, Thomas Petazzoni wrote:
> On Wed, 17 Jun 2015 17:01:12 +0000, Jason Cooper wrote:
> 
> > I disagree with this.  We can't predict what incosistencies we'll discover in
> > the future.  We should only assign new compatible strings based on known IP
> > variations when we discover them.  This seems fraught with demons since we
> > can't predict the scope of affected IP blocks (some steppings of one SoC, three
> > SoCs plus two steppings of a fourth, etc)
> > 
> > imho, the 'future-proofing' lies in being specific as to the naming of the
> > compatible strings against known hardware variations at the time.
> 
> Except that this clearly doesn't work, and the case raised by Simon is
> a perfect illustration of why planning ahead is beneficial. 

Odd, I'd use that as an example of the process working.  ;-)  we have
everyone using 'armada-370-neta' for a given block.  We discovered that
the original IP block (on the 370s) had a limitation (no hw checksum
for greater than 1600 bytes).  A newer version of the IP block (XP)
doesn't have the limitation.

So we change the driver to honor the limit for the 370 compatible
string.  We create a new compatible string for xp where the block
doesn't have the limitation.

How did the process fail?

> We already had the issue several times on mvebu platforms, so it
> should really become the rule to have one compatible string specific
> to the actual SoC in the list of compatible strings.

Sorry, I'm just not a fan of guessing.  But I'll fall back to the DT
maintainers on this one.  if they are ok with it, then I'll drop my
objection.

> Not doing so requires breaking DT backward compatibility more often, so
> wanting DT backward compatibility and not wanting to plan ahead is a
> bit antagonist.

I'm not seeing where backwards compatibility was broken?  A device with
an old dtb booting a newer kernel gets a bugfix.  In the case of an XP
board with an old dtb (armada-370-neta), the hardware still works, but
not optimally.  Upgrading the dtb will enable hw checksumming for jumbo
packets.

thx,

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