linux-kernel - Re: [PATCH 1/2] remove i.MX SPI driver

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: <20090623155840.c750b70b.akpm@linux-foundation.org>
Date:	Tue, 23 Jun 2009 15:58:40 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Sascha Hauer <s.hauer@...gutronix.de>
Cc:	linux-kernel@...r.kernel.org, david-b@...bell.net,
	s.hauer@...gutronix.de,
	Andrea Paterniani <a.paterniani@...pp-eng.it>
Subject: Re: [PATCH 1/2] remove i.MX SPI driver

On Thu, 18 Jun 2009 08:54:31 +0200
Sascha Hauer <s.hauer@...gutronix.de> wrote:

> This driver is in a non working state at the moment and will
> be replaced by a bitbang driver which can also handle the
> newer i.MX variants

hum.  How did it get into a non-working state?

>From the logs, it looks like it was working OK for Andrea Paterniani
when he patched it in April last year.

Ordinarily I'd be asking whether this replacement of one driver with
another is a 100% seamless change.  But I guess that the audience for
SPI drivers are sufficiently technical to be able to handle the odd
Kconfig changes, module parameter changes, module name changes, etc.

But I do think that if there are any such user-visible changes, they
should be described in the changelog.  And I think there are such
changes - the module name at least?

Is it possible and desirable to retain both drivers for a while?  Would
that ease the transition?  It also gives people a fallback driver to
use, if your new driver doesn't work for them.  Just like eepro100.c,
which lived for five years ;)

But it's really hard to make any decisions about this because the
changelog failed to provide any details about the "non working state".

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/