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: <4AB1AF91.2080606@windriver.com>
Date:	Wed, 16 Sep 2009 22:40:01 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	gregkh@...e.de, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] usb console,usb-serial: pass initial console baud
 on to first tty open

Alan Stern wrote:
> On Wed, 16 Sep 2009, Jason Wessel wrote:
>
>   
>> The first open of the usb serial HW has the termios initialized to the
>> default of 9600 baud, and this will override what ever was setup via
>> the original console initialization.
>>     
>
> I don't understand.  The first open of the console hardware occurs in 
> console.c as part of usb_console_setup(), and it uses the baud rate 
> passed in via the console options.  Why does anything need to get 
> saved?
>   

The initialization in console.c is done with a dummy tty structure that
is thrown away.  It is thrown away because it was not connected to any
device handle.

Any new tty that is opened defaults to 9600 baud, for the mct_u232
driver as an example, if you boot the system with
console=ttyUSB0,115200, when mingetty starts it will inherit 9600 from
the first tty that is opened, vs reading the value from the HW.  Even if
you have a pl2303 and boot with the 115200 baud, you can run "stty -a <
/dev/ttyUSB0" and you will see it reports it is running at 9600.  The
pl2303 driver just happens to work because it handles the baud differently.

I elected to save the baud because:

1) There was no uniform interface to read the current baud from the usb
hardware

2) There was no documented API for getting tty to attach when you create
the initial console.

If there is a better way to fix this, it would be good to continue the
discussion.

Thanks,
Jason.

--
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