On Thu, Nov 13, 2014 at 1:42 AM, Arnd Bergmann <arnd@xxxxxxxx> 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. > - 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? > 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)? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
