On Fri, 2015-11-13 at 17:06 +0100, Soeren Grunewald wrote: > Hi Rob, > > Unless you need the 8250_pci driver in early boot as console e.g for > onboard devices, it might be a solution to build 8250_pci as module. > > Then you can blacklist it e.g. via kernel argument modprobe.blacklist= > 8250_pci or 8250_pci.disable=1. Later in the boot process you load the > Exar driver and afterwards the 8250_pci manually. > > But I guess you already thought about this too. So your solution seems > pretty obvious to solve your issues. I did try making the 8250_pci modular instead of built-in. It ended up having the same problems that trying "unbind" did (I mentioned that in another response), but even if it did work, then it still comes back to having to rebuild the kernel. I'm trying to avoid having that be the workaround. > Anyway, I find Sudip's argument also extremely reasonable and I totally > agree that adding RS485 support for exar chips as for the Fintek chips > is the way to go. Which raises the question how to implement the non > standard functionality mentioned by Sudip? And is this functionality > really needed? I may not be understanding fully, as I don't know about the Fintek chips, but whatever we end up doing won't add RS485 support for the Exar chip. The XR17V35x chips don't have RS232/RS422/RS485 capability, that's all provided by other parts on the board. In our particular case, those parts that are configured to provide RS485/etc are configured using the GPIO lines of the Exar chip. So, we need access to the GPIO of the Exar chip to configure the board. But any other board out there with this same Exar chip will do nothing if you tell it to twiddle the GPIO lines in the same way. Well, it might do SOMETHING if they happen to also be using the GPIO lines...but I doubt they're using them in the same way we are. > So to me question is, especially since the HW you produce is pretty > special. Do your customers use unmodified distributions (e.g. Debian or > RHEL). And don't they build there own customized/modified kernels, which > could contain your patch then. Based on my interaction with them over the past 4 years, my impression is that the vast majority use un-modified distros. Whenever we start a tech support issue, I ask them what distro they have and rarely is a custom kernel mentioned. We design and develop our boards and software to be as universally accessible as possible. As it is now, since kernel 3.8, this is the only board we have that requires kernel-level interaction to get to fully work. Thank you for the questions and help Rob G. -- 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
