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: <20151217172143.GA20049@kroah.com>
Date:	Thu, 17 Dec 2015 09:21:43 -0800
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Sebastian Frias <sf84@...oste.net>
Cc:	Peter Hurley <peter@...leysoftware.com>,
	linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	mason <slash.tmp@...e.fr>,
	Måns Rullgård <mans@...sr.com>
Subject: Re: [RFC PATCH] always probe UART HW when options are not specified

On Thu, Dec 17, 2015 at 05:48:42PM +0100, Sebastian Frias wrote:
> On 12/17/2015 05:29 PM, Peter Hurley wrote:
> >On 12/17/2015 07:15 AM, Sebastian Frias wrote:
> >>---
> >>
> >>I think there are a few minor bugs on the 8250 UART code.
> >>
> >>Below you can find a patch with a proposed solution.
> >>
> >>In a nutshell:
> >>- probe_baud from 87515772c33ee8a0cc08d984a7d2401eeff074cd was
> >>converted into probe_port so that it reads all the parameters that
> >>uart_set_options require (namely baud, parity, bits, flow).
> >>- reading/writing to UART_DLL/UART_DLM directly are converted to
> >>using the read_dl/write_dl callbacks.
> >>- the port is always probed if there are no options (*).
> >
> >Because I don't want to probe the port at all.
> >
> >But must when using the
> >	earlycon=ttyS0,....
> >
> >command-line (because the original hack expects that behavior).
> 
> Ok, we are using:
> 
> "console=ttyS0 earlyprintk"
> 
> and the 8250 (with CONFIG_SERIAL_8250_RT288X=y) driver.
> 
> The hardware is setup prior to Linux boot.
> We don't want Linux to change the UART settings, just to pick up whatever
> settings the UART has and take over UART.

Don't do that :)
Linux can't "know" what happened before it started to the hardware and
expect to work properly.

> How do you suggest we do that? Right now, since it does not probe, it just
> messes up the UART config setup before booting Linux.

pass in the same settings as you previously set up, that way there is no
change.

thanks,

greg k-h
--
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