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, 20 Jan 2014 23:21:41 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Mark Brown <broonie@...nel.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Tushar Behera <tushar.behera@...aro.org>,
	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 Mon, Jan 20, 2014 at 11:14:57PM +0000, Mark Brown wrote:
> On Mon, Jan 20, 2014 at 09:43:05PM +0000, Alan Cox wrote:
> > If the hardware isn't present then the driver shouldn't even register
> > with the tty layer in the first place so it doesn't make any resource
> > differeneces either for properly written code.
> 
> Right, that's not the idiom that has been followed by any of serial
> drivers though so needs fixing too.

It's not followed by serial drivers because it gets f*scking complicated
to do it that way.

In order to do it that way, what we need to do is:

1. On the first device probe, register the UART driver.
2. On subsequent device probes, don't register the UART driver because
   it's already registered.
3. When devices are removed, do nothing until the last device.
4. When the last device is removed, unregister the UART driver.

The first bit is easy... but we need to add locks to every serial
driver to prevent two probes operating concurrently...

-- 
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up.  Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ