On Fri, 2015-11-13 at 13:07 +0530, Sudip Mukherjee wrote: > On Thu, Nov 12, 2015 at 02:49:29PM -0500, Rob Groner wrote: > > On Thu, 2015-11-12 at 11:36 -0800, Greg KH wrote: > > > On Thu, Nov 12, 2015 at 02:26:12PM -0500, Rob Groner wrote: > > > > On Thu, 2015-11-12 at 09:52 -0800, Greg KH wrote: > > > > > On Thu, Nov 12, 2015 at 03:16:00PM +0000, Rob Groner wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Greg KH [mailto:greg@xxxxxxxxx] > > > > > > > Sent: Thursday, November 12, 2015 9:51 AM > > > > > > > To: Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx> > > > > > > > Cc: Rob Groner <rgroner@xxxxxxx> > > > > > > > Subject: Re: [PATCH] 8250_pci: Prevent Exar/RTD Boards from binding. > > > > > > > > > > > > > > On Thu, Nov 12, 2015 at 07:24:06PM +0530, Sudip Mukherjee wrote: > > > > > > > > Anyways, I had a glance at the driver today. I think we just need to > > > > > > > > modify the quirks in 8250 code a little bit, and need to see how to > > > > > > > > add your custom ioctl commands. And hopefully, that should be sufficient. > > > > > > > > > > > > > > Drop the "custom" ioctl commands please, those should not be needed. > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > greg k-h > > > > > > > > > > > > We use the following ioctls for configuring the board (RS232/RS422, etc): > > > > > > > > > > > > #define FIOQSIZE 0x5460 > > > > > > #define IOCTL_EXAR_READ_REG (FIOQSIZE + 1) > > > > > > #define IOCTL_EXAR_WRITE_REG (FIOQSIZE + 2) > > > > > > > > > > What's wrong with the "standard" way of doing this instead? > > > > > > > > > > > We use the following ioctls to configure the board for non-standard baud rates: > > > > > > > > > > > > #define EXAR_SET_MULTIDROP_MODE_NORMAL (FIOQSIZE + 3) > > > > > > #define EXAR_SET_MULTIDROP_MODE_AUTO (FIOQSIZE + 4) > > > > > > #define EXAR_SET_REMOVE_MULTIDROP_MODE (FIOQSIZE + 5) > > > > > > > > > > Again, what's wrong with using the standard way of setting non-standard > > > > > baud rates? Why does this device need something "special"? > > > > > > > > > > thanks, > > > > > > > > > > greg k-h > > > > > > > > I have no answer for that. > > > > > > > > So if the IOCTL's change to the "standard" way of doing it, then I'd > > > > just have to change the IOCTL values wherever I use them (libraries, > > > > mainly). And I'd have to either be able to detect when I'm using Exar's > > > > driver vs. this modified kernel driver, or put out two different > > > > packages for the board based on kernel version number. That's right? > > > > > > yes, but then your software works with any serial hardware and isn't > > > tied to one odd serial board :) > > > > > > thanks, > > > > > > greg k-h > > > > Hehe...that would normally be true, but it wouldn't actually make sense > > using it with any other board. That odd serial board is the only one I > > have to care about. > > > > The "software package" is basically the driver, a library, and example > > programs so the user can reconfigure the board. The reconfiguring > > method is specific to our board, so not much portability there. Perhaps > > the non-standard baud rate example would be more portable, however. > > Adding linux-serial@xxxxxxxxxxxxxxx as CC to this thread of discussion. > > Looks like they are using these custom ioctl to read and write to the > hardware registers to reconfigure the board and also to use the GPIO as > mentioned by Rob in his mail. So if we just include the hardware in the > standard way then these functionalities will not be available. And > besides, i think the hardware is already working in the standard way > using upstream driver. They want the extra functionalities for some > users who will have the need to reconfigure the board. > > So basically their requirement is to either include these extra > functionalities (extra custom ioctl) or remove the hardware id from > 8250_pci so the upstream driver doesnot bind with their hardware. > Rob - please correct me if i am wrong in understanding your reqiurement. Correct. Our board works great with the built-in 8250_pci as a result of Soeren's work. That's not the problem. The problem is that in order to reconfigure the serial port for RS232/RS422/RS485, you need to use the Exar GPIO. We wired in our port configuration functionality into the output of their GPIO so that we could have a jumperless board. > And Rob, your initial patch (not binding to these devices) will force > all users to use the out of tree driver. Your device was added to 8250 > by Soeren Grunewald and I guess he wants to use an upsteam driver for > his device. My patch (unless I did it wrong) would only force users of RTD-produced boards from using the out of tree driver. Soeren included support for all boards that had the Exar chipset as the device ID (which includes ours). I tried to exclude only those boards that have an Exar Device ID, but an RTD sub-vendor device ID. > And your driver does not say anything about how you are reconfiguing the > board to RS485. There is another pci card Fintek who are also doing a > reconfiguration. Maybe you can have a look at pci_fintek_rs485_config() > in 8250_pci.c file. If you can post the code to reconfigure the board, > then i think these custom ioctl to reconfigure the board will not be > needed. The utility for reconfiguring the board is quite lengthy. Here is a link to the package if that helps, or I can post it if you want. http://www.rtd.com/software/UM/SERX5330/SER25330_Linux_v01.00.00.tar.gz Rob -- 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
