linux-kernel - Re: [PATCH 1/2] serial: samsung: Move uart_register

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: <20140124120309.GU11727@sirena.org.uk>
Date:	Fri, 24 Jan 2014 12:03:09 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Tomasz Figa <t.figa@...sung.com>,
	Tushar Behera <tushar.behera@...aro.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-serial <linux-serial@...r.kernel.org>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	jslaby <jslaby@...e.cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ben Dooks <ben.dooks@...ethink.co.uk>
Subject: Re: [PATCH 1/2] serial: samsung: Move uart_register_driver call to
 device probe

On Thu, Jan 23, 2014 at 09:33:21PM +0000, Alan Cox wrote:
> Mark Brown <broonie@...nel.org> wrote:

> > I don't see how we can meaningfully test this on a platform - the kernel
> > would have to be pretty demented to care, it's userspace that cares and
> > that's not really tied to individual serial drivers but is where we
> > mainly need coverage.

> Which is why I think we want to enable it gradually and platform by
> platform as that platform or arch maintainer judges it appropriate given
> their knowledge of their platform(s).

I don't see how that follows?  For the most part architecture
maintainers aren't going to be able to say too much about which
userspaces are being run on their platforms if the architecture
has any kind of widespread use.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)