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: <20140127000426.6027cdd5@www.etchedpixels.co.uk>
Date:	Mon, 27 Jan 2014 00:04:26 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Pavel Machek <pavel@....cz>
Cc:	Mark Brown <broonie@...nel.org>, 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 Sun, 26 Jan 2014 22:09:07 +0100
Pavel Machek <pavel@....cz> wrote:

> On Thu 2014-01-23 19:36:33, Mark Brown wrote:
> > On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote:
> > > On 23.01.2014 19:40, Mark Brown wrote:
> > 
> > > >We'd need to leave it user selectable rather than enabling it for ARM,
> > > >the whole reason this got noticed is that people are trying to build
> > > >kernels that support a wider range of devices for ARM.
> > 
> > > What about making it depend on !MULTIPLATFORM and enabled by default?
> > 
> > That'd work, but if we're doing that then substituting in the dynamic
> > assignment only when we hit a collision seems smoother and more general.
> 
> That seems like a mess. I had enough fun debugging "WTF is
> going on with my serials" as is...
> 
> Plus... collision can happen at runtime when you insert
> BT CF card... at that point it is too late to reassign.

Agreed entirely - you want predictability here, plus making it happen by
magic is going to do the nut of anyone trying to figure out why kernel A
works on their platform and kernel B doesn't.

It needs to be something you choose to turn on as compatibility, like old
sysfs files and so forth.
--
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/