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, 28 May 2012 16:03:11 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Roland Stigge <stigge@...com.de>
Cc:	alan@...ux.intel.com, gregkh@...uxfoundation.org,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	kevin.wells@....com, srinivas.bakki@....com,
	linux-arm-kernel@...ts.infradead.org, arnd@...db.de
Subject: Re: [PATCH] serial/of-serial: Add 16654 chip to compatible string
	list

On Mon, May 28, 2012 at 01:20:55PM +0200, Roland Stigge wrote:
> On 28/05/12 12:03, Russell King - ARM Linux wrote:
> > Something which occurs to me.  Normally, the digit at the end indicates
> > how many ports are integrated into the device (0=1port, 2=2port, 4=4port.)
> > Are you sure there isn't a ST16650 which has the same characteristics?
> > 
> > We really should stick with naming these using the single port versions if
> > at all possible.
> 
> Right.
> 
> This indicates to me that maybe this is not the right solution for my
> original problem, anyway. :-)
> 
> Initially, with my RFC patch, there was an #ifdef for bigger FIFO in
> case of LPC32xx where we have a 16550A variant with 64 byte fifos.

What are all the differences?  Is it just a larger FIFO?

> Looking at the 16x50 line:
> 
> 16550A  16 bytes FIFOs
> 16650V2 32 bytes FIFOs
> 16750   64 bytes FIFOs
> 
> (?)
> 
> So maybe 16750 is the better choice for me, anyway. Already supported in
> of-serial. Works for now, but need more testing. Another hint is that
> 16750 is advertised as "IP core for Soc" which matches the case of LPC32xx.

16750 also has automatic hardware flow control support, selectable through
bit 5 in the MCR register.  If your UART has that, then it's probably a
16750 derivative rather than a 16550 or 16650 derivative.

16650s have an EFR register at offset 2, selectable by writing 0xBF into
the LCR register, which the 16750 doesn't have.  16650 also has automatic
hardware flow control, bit this is selected through a couple of bits in
the EFR.

With that information, you should be able to track down which of these
your UART is derived from.
--
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