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

Message-ID: <20090624092443.GW31396@pengutronix.de>
Date:	Wed, 24 Jun 2009 11:24:43 +0200
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, david-b@...bell.net,
	Andrea Paterniani <a.paterniani@...pp-eng.it>
Subject: Re: [PATCH 1/2] remove i.MX SPI driver

On Tue, Jun 23, 2009 at 03:58:40PM -0700, Andrew Morton wrote:
> 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.

The driver was written for arch-imx which is superseeded by arch-mxc
now. It depends on the i.MX DMA API which changed while moving from
arch-imx to arch-mxc.
A reason to keep the old driver is that it has DMA support, but Andrea
agrees that it's better to add DMA support to the new driver than to fix
it in the old driver.

> 
> 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 ;)

I rather try to avoid that. Note that this is a platform driver which
had zero inkernel users till now.

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

I'll add notes about this to the patch which removes the driver.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/