On Fri, 2015-11-13 at 13:43 -0500, Peter Hurley wrote: > On 11/13/2015 11:39 AM, Rob Groner wrote: > > 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 how does your userspace discover that it is actually talking to > your board and not some other Exar board using those GPIO lines? > When executing the example, you're supposed to pass it the first serial device of the board (there are 8 total). The configuration example we provide with the board naturally assumes you're using it with our board. As such, it checks for the presence of some values stored in the EEPROM (revision, user-defined message, etc), mainly as a check that everything is working as it should be. If the user wanted to, they could remove those checks and execute the reconfiguration calls anyway (ex. to change from RS232 to RS485). If they did that with a non-RTD board that had the Exar XR17V35x chipset on it, and had the Exar driver inserted, then (as far as I know) it would end up toggling the GPIO lines of the Exar chip. The final result of doing that depends on what the non-RTD board does with those GPIO lines. So far as I know, we're the only ones that use them to configure the recv/trans on the board. Other manufacturers might use the GPIO for other things, or nothing. Configuring the board in this manner was solely a design decision on our part...it's not a requirement for the Exar chip. In fact, the Exar chip knows nothing about it. It was a means for us to get away from relying on jumpers for configuration. I hope I answered your question. 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
