linux-kernel - Re: [PATCH] dw_mmc: Add Synopsys DesignWare mmc host 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: <AANLkTi=BXxfNcnhNb6Bd_N3gVpDUMWBCQtZ0d=m9p_sa@mail.gmail.com>
Date:	Thu, 9 Dec 2010 17:46:20 +0000
From:	Will Newton <will.newton@...il.com>
To:	Chris Ball <cjb@...top.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Matt Fleming <matt@...sole-pimps.org>,
	linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] dw_mmc: Add Synopsys DesignWare mmc host driver.

On Thu, Dec 9, 2010 at 5:35 PM, Chris Ball <cjb@...top.org> wrote:
> Hi Andrew,
>
> On Thu, Dec 09, 2010 at 04:01:57PM +0000, Chris Ball wrote:
>> > > Is there something we could depend on that would stop this driver being
>> > > presented to everyone, without being far too specific?  At the moment
>> > > we'd be making x86 desktop users say whether they have this IP, which
>> > > isn't good.  Are the architectures that use this IP already upstream?
>> > > Are they all ARM architectures, for instance?
>> >
>> > I don't know of any architectures upstream that use this IP block. There is an
>> > SoC from NXP that uses this it but it is not upstream:
>> >
>> > http://ics.nxp.com/support/software/lpc313x.bsp.linux/
>> >
>> > The architecture we tested and debugged this driver on is not upstream either
>> > unfortunately. :-/
>>
>> Okay.  I think "depends on ARM" is appropriate for now, and we could
>> expand that later if the block appears in a MIPS SoC or something.
>> Does that work for you?
>
> Oh, hey, rmk says that he seems to recall that akpm says that if the
> driver builds on x86 (it does), we should just allow it to be built
> there too so that it gets build coverage.  Andrew, does this still
> represent your stance?
>
> I've heard the distro maintainers complain about having to investigate
> Kconfig entries for drivers that their users would never possibly use,
> though, and this certainly falls into that case.  Is there something
> better we can do here, to correctly hide this driver from non-ARM users
> but also make it clear that it can be built if somebody wants to do a
> mass driver build?

The driver does build on x86{_64} and it has been useful for me to do
that in the past to test cosmetic changes. It might also be good to
have it building on x86 to get more compile testing, as I suspect a
lot more people doing randconfig builds are doing it on x86 rather
than arm.

But I'm fine with it either way.
--
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/