On Wednesday 12 November 2014 01:19:24 Kevin Cernekee wrote: > On Wed, Nov 12, 2014 at 1:04 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Wednesday 12 November 2014 00:46:30 Kevin Cernekee wrote: > >> Remove the platform dependency in Kconfig and add an appropriate > >> compatible string. Note that BCM7401 has one 16550A-compatible UART > >> in the UPG uart_clk domain, and two proprietary UARTs in the 27 MHz > >> clock domain. This driver handles the former one. > >> > >> Signed-off-by: Kevin Cernekee <cernekee@xxxxxxxxx> > > > > Can you explain why you are using the PXA serial driver instead of the > > 8250 driver, if this is 16550A compatible? I don't know the history > > why PXA is using a separate driver. > > I wasn't able to get serial8250 to work in any situation where another > driver tried to claim "ttyS"/4/64. > > serial8250 calls uart_add_one_port() in its module_init function, even > if the system doesn't have any ports. Setting nr_uarts > (CONFIG_SERIAL_8250_RUNTIME_UARTS) to 0 doesn't help because > serial8250_find_match_or_unused() will just return NULL. > > I guess I could try to rework that logic but several cases would need > to be retested, going back to PCs with ISA buses and PCI add-in cards. > And the differences may be visible to userspace. > > The PXA driver seemed like a much cleaner starting point, even if it > was intended for a different SoC. Hmm, I've seen you already posted v2 of the series, but I'm not sure that this is what Greg had in mind when he suggested using /dev/ttyS* for the other driver. TTY naming is a mess today, and you seem to be caught in the middle of it trying to work around the inherent problems. Extending the PXA driver is an interesting approach since as you say it's a very nice clean subset of the 8250 driver, but that doesn't mean that it's a good long-term strategy, as we will likely have more chips with 8250 variants. Some of the ways forward that I can see are: - (your approach) use and extend the pxa serial driver for new SoCs, possibly migrate some of the existing users of 8250 to use that and leave 8250 alone. - fix the problem you see in a different way, and get the 8250 driver to solve your problem. Possibly integrate the pxa driver back into 8250 in eventually, as we did with the omap driver. - Do a fresh start for a general-purpose soc-type 8250 driver, using tty_port instead of uart_port as the abstraction layer. Use that for all new socs instead of extending the 8250 driver more, possibly migrating some of the existing 8250 users. - split out the /dev/ttyS number allocation from the 8250 driver and make it usable by arbitrary drivers. Greg, Jiri, do you have some guidance, or possibly other ideas? Arnd
