Re: [PATCH/RFC 5/8] serial: pxa: Make the driver buildable for BCM7xxx set-top platforms

[Arnd Bergmann <arnd@arndb.de>]

On Thursday 13 November 2014 11:08:08 Kevin Cernekee wrote:
> On Thu, Nov 13, 2014 at 1:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 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 you think it might make sense to come up with a set of guidelines
> that ensure that SoCs using a non-serial8250 driver (like pxa) on
> 16550-compatible hardware can be easily moved back to serial8250
> someday?
> 
> e.g. maybe I should be adding a reg-shift property to my pxa DT entry.
> It isn't necessary for pxa.c, but if we ever move to serial8250 it
> will be necessary.

I'm not sure how many others exist that are 8250-like with different
drivers. I think it would be a good idea to have the properties in
there, but I'm not sure if I can come up with an exhaustive list
of requirements.

> > - Do a fresh start for a general-purpose soc-type 8250 driver, using
> >   tty_port instead of uart_port as the abstraction layer.
> 
> Hmm, does that mean we can't use the serial_core.c helpers?

Correct. IIRC the consensus among the tty maintainers has been
for some time that serial_core.c and uart_port doesn't actually do
that much good compared to the complexity it adds in other places.
I may misremember the exact argument.

> >   Use that for
> >   all new socs instead of extending the 8250 driver more, possibly
> >   migrating some of the existing 8250 users.
> 
> One nice thing about a brand new driver is that we can use dynamic
> major/minor numbers unconditionally without breaking existing users.
> If either pxa.c or bcm63xx_uart.c had used dynamic numbers, I could
> drop Tushar's original workaround.
> 
> Another advantage is that we can assume all users have DT, simplifying
> the probe function.
> 
> Would it be helpful to split parts of pxa.c and/or serial8250 into a
> "lib8250", similar to libahci, that can be called by many different
> implementations (some of which have special features like DMA
> support)?

That sounds like a very good idea, yes. I had actually worked on something
in this area years ago, but haven't followed up in some time. In particular,
I think it makes sense to split the specific I/O register access method into
a separate library from the code that knows about the 8250 register set,
and from the code that performs the probing.

	Arnd