2016.03.24. 4:17 keltezéssel, Peter Hurley írta: > On 03/23/2016 07:09 PM, Matthias Schiffer wrote: >>>> autoconfig_16550a() is doing all kinds of weird checks to detect different >>>> hardware by writing a lot of register values which are documented as >>>> reserved in the AR7242 datasheet (there's a leaked version going around >>>> that can be easily googled...), no idea if any of those are problematic. >>>> Just setting UPF_FIXED_TYPE as suggested by Peter would avoid that code >>>> altogether. >>> >>> That's just a debugging patch and not appropriate for permanent use, >>> the reason being that this uart is _not_ 16550 compatible (or even 16450 >>> compatible). >>> >>> The three options for 8250 driver support for this part are: >>> 1. Similar to the debugging patch, set UPF_FIXED_TYPE but set port type >>> to PORT_8250 instead. This will lose FIFO support so 115K won't be >>> possible and likely neither will 38400. >>> >>> 2. Set UPF_FIXED_TYPE but define a new PORT_* value and add support for >>> this PORT_* value to uart_config array, uapi headers, and anywhere >>> the scratch register is used. >>> >>> 3. As with 2. above but don't set UPF_FIXED_TYPE and add a probe function >>> that detects ports of this type to autoconfig(). I don't recommend this >>> method. >>> >>> This requirement is independent of fixing prom_putchar_ar71xx(). >>> >> >> I can send patches for all of this, and I think that 2. would be the nicest >> solution. I've noticed though that include/uapi/linux/serial_core.h is >> experiencing a little "overflow": PORT_MAX_8250 has grown just below the >> first non-8250 entry. > > Ugh. Thanks for noting this. > >> Should I just add the new entry at the bottom (and >> thus grow the uart_config array by ~85 unused entries)? What about >> PORT_MAX_8250 (used at least in drivers/tty/serial/8250/8250_of.c)? > > None of the above, unfortunately. Ok, plan B. > > I need to clean off a dusty series that adds probe steering and > bugs pass-thru for 8250 sub-drivers and platform data. Then add a > UART_BUG_NOSCR to indicate a uart does not have a scratch register > (like this one). Then for this uart, set UPF_FIXED_TYPE and type to > PORT_16550A, with UART_BUG_NOSCR flag. Introducing the UART_BUG_NOSCR flag for this UART is pointless in my opinion, because it does have a scratch register in fact. Even if it is not listed in the datasheet of the SoCs, it exists. I have tested that from the bootloader on the Netgear WNDR3700 board which uses the AR7161 SoC: ar7100> md.l 0xb802001c 1 b802001c: 00000000 .... ar7100> mw.l 0xb802001c a5 ar7100> md.l 0xb802001c 1 b802001c: 000000a5 .... ar7100> mw.l 0xb802001c 5a ar7100> md.l 0xb802001c 1 b802001c: 0000005a ...Z ar7100> The same test is on the TL-WR842ND v1 board (AR7241 SoC): ar7240> md.l b802001c 1 b802001c: 00000000 .... ar7240> mw.l b802001c a5 ar7240> md.l b802001c 1 b802001c: 000000a5 .... ar7240> mw.l b802001c 5a ar7240> md.l b802001c 1 b802001c: 0000005a ...Z ar7240> And on the TL-WR841N v8 board (AR9341 Soc): wasp> md.l b802001c 1 b802001c: 00000000 .... wasp> mw.l b802001c a5 wasp> md.l b802001c 1 b802001c: 000000a5 .... wasp> mw.l b802001c 5a wasp> md.l b802001c 1 b802001c: 0000005a ...Z wasp> Although i did not test it on other SoCs, but i assume that the behaviour is the same on those. -Gabor -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
