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: <20130731194332.GA900@radagast>
Date:	Wed, 31 Jul 2013 22:43:32 +0300
From:	Felipe Balbi <balbi@...com>
To:	Richard Cochran <richardcochran@...il.com>
CC:	Felipe Balbi <balbi@...com>, Mugunthan V N <mugunthanvnm@...com>,
	<netdev@...r.kernel.org>, <davem@...emloft.net>,
	<linux-omap@...r.kernel.org>
Subject: Re: [net-next PATCH 1/1] drivers: net: cpsw: Add support for new
 CPSW IP version

Hi,

On Wed, Jul 31, 2013 at 09:22:29PM +0200, Richard Cochran wrote:
> On Wed, Jul 31, 2013 at 09:45:25PM +0300, Felipe Balbi wrote:
> > On Wed, Jul 31, 2013 at 06:38:46PM +0200, Richard Cochran wrote:
> > > On Wed, Jul 31, 2013 at 06:28:27PM +0300, Felipe Balbi wrote:
> > > > On Wed, Jul 31, 2013 at 04:49:59PM +0200, Richard Cochran wrote:
> > > > > On Wed, Jul 31, 2013 at 05:42:26PM +0530, Mugunthan V N wrote:
> > > > > > The new IP version has a minor changes and the offsets are same as the previous
> > > > > > version, so instead of adding CPSW version number in the driver, make the driver
> > > > > > to fall through to the latest versions so that the new version of CPSW which has
> > > > > > the same register offsets will work directly without patching the driver.
> > > > > 
> > > > > This doesn't make any sense to me. Why not just add the new version
> > > > > number?
> > > > > 
> > > > > None of the hunks in your patch are on performance sensitive paths, so
> > > > > I really can't see any point in removing the error checking.
> > > > 
> > > > well, if a new revision of the IP comes, the driver at least has some
> > > > chance to work without having to be modified. If it turns out that there
> > > > are really different features, then we patch a new version, otherwise we
> > > > should just assume highest known version and try it out.
> > > 
> > > And if the driver reads junk from some random address due to
> > > bootloader/DT/multikernel madness, it will happily peek and poke
> > > around instead of rejecting the wrong version number.
> > 
> > that'd be a bug in the DT anyway, why should the driver have to cope
> > with broken data ?
> 
> Um, it is called error checking?

right, now go check on the archives what Linus (and many others, for
that matter) have said about version checking. If it's not the version
you expect, you assume the latest.

Imagine the situation where new IP version has new features, but all the
others still work and we don't use that new feature. We'd have to patch
the kernel just to get the driver to probe() even though the entire
driver is still 'compliant' with the new IP.

> Besides, by not checking the version number, you are pre-programming a
> disaster that will occur when an older kernel is booted on the first
> new IP version with important changes. Can you really be sure that all
> users will have the new, patched kernel?

why will there be a disaster ?

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ