linux-kernel - Re: [PATCH] SPI: SSP SPI Controller driver v3

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]

Date:	Mon, 7 Jan 2013 11:21:04 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	channing <chao.bi@...el.com>
Cc:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	grant.likely@...retlab.ca, linux-kernel@...r.kernel.org,
	sylvain.centelles@...el.com, ken.k.mills@...el.com,
	jun.d.chen@...el.com, alan@...ux.intel.com
Subject: Re: [PATCH] SPI: SSP SPI Controller driver v3

On Mon, Jan 7, 2013 at 9:05 AM, channing <chao.bi@...el.com> wrote:

> Frankly I'm currently not sure whether they share same IP.. per your reminds, I tried to find but get
> limited info about PXA SSP's IP, from the code, looks like they have part of registers the same.
>
> As far as I know, spi-pxa2xx.c is specific for SSP controller of PXA2XX/PXA3XX core, right?

As pointed out by Mika it may very well be the same IP anyway. People copy/paste
share and fork VHDL/Verilog/SystemC code just as much as they do with
kernel code.

> While Medfield
> platform is embedded with ATOM core, the SSP driver we upload is validated on SSP controller of ATOM. In my
> view, they're specific for different AP & Platforms, if compare the 2 files, there are still many difference
> in how they works, if to choose a driver for Intel Medfild/Moorestown platform, I believe spi-intel-mid-ssp.c
> driver could be a more mature solution.

>From the kernel community point of view the driver that is being
maintained in-tree
is the more mature solution.

For your productization maybe the other driver is more mature.

These are two different definitions of maturity.

In the kernel we worry that we do not needlessly need to fix bugs in two places
or leave a bug in one place while fixing it in another place, which is
potentially the
problem we run into here.

There may be an initial time/testing cost for you to adopt to the PXA driver,
but on the other hand the PXA developers will review your code and fix
bugs for you also, so it's what we call a win-win situation if you can share
the driver.

Yours,
Linus Walleij
--
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/