On 11/13/2015 02:02 PM, Rob Groner wrote: > 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. Sort of; what we need to know is if there is a reliable, non-destructive method of h/w probing to id your board(s). For example, are the pci subsystem vendor and device id fields valid and uniquely identify your board? If so, we can use the 8250_pci quirk mechanism to fork into your board-specific init. >From there is how RS485 support would be added. Regards, Peter Hurley -- 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
