On Fri, 2015-11-13 at 14:26 -0500, Peter Hurley wrote: > 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 > > 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 Oh, I see. Yes, the subvendor and subdevice IDs can be used to reliably determine that it is our card. The vendor and device IDs will be Exar's. 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
