On Thursday, November 19, 2009, Arnd Bergmann wrote:
> I'd still add support for the compatible="ns16550a" property
> so that we do the right thing for future systems.
>
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv
diff --git a/driv
Hi,
On Thursday, November 19, 2009, Arnd wrote:
> In that case, add another entry for the device encoded in the firmware
> itself. The ns16550 entry should be the second one after a more
specific
> one telling which device it is exactly.
>
Is the following better?
---
[PATCH] Xilinx 16550 UART
Hi,
On Monday, November 16, 2009, Stephen wrote:
> There are at least two other ways that you might be able to reset a
> board:
> 1) Internally through the ICAP device.
> 2) Through a GPIO connected externally to the reset logic.
>
Unfortunately none of these is relevant for the specific board i
Hi,
On Monday, November 16, 2009, Arnd wrote:
> > - { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550, },
> > + { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550A, },
>
> Does not seem logical. If the device claims compatibility with
ns165
I am using locally the attached (hackish) patch; could someone propose a
way to make it acceptable to mainline (or should I just keep this
quiet)?
diff --git a/arch/powerpc/platforms/44x/virtex.c
b/arch/powerpc/platforms/44x/virtex.c
index cf96cca..749a330 100644
--- a/arch/powerpc/platforms/44x/v
As of commit eedacbf0, drivers/serial/of_serial.c forces the serial core
to recognize the xps-uart16550-2.00.b as an NS16550 (which had no FIFO).
Prior to this commit, the kernel's auto-configuration logic would
correctly recognize the UART as NS16550A (with 16-byte FIFO).
The following patch corr
