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

Message-ID: <20101209173525.GA29879@void.printf.net>
Date:	Thu, 9 Dec 2010 17:35:25 +0000
From:	Chris Ball <cjb@...top.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Will Newton <will.newton@...il.com>,
	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.

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?

Thanks,

-- 
Chris Ball   <cjb@...top.org>   <http://printf.net/>
One Laptop Per Child
--
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/