Hi Greg, thanks for your reply. I spent some free time this week trying to compile and use the modified driver, but I'm unable to compile it, I'm not an expert in compiling linux drivers, I may reinstall a fresh linux version this weekend as I think I messed up something. BTW; I'm quite sure that the clock is 12MHz, because the baudrate divisor is calculated as 12M/div - see line 363: http://lxr.free-electrons.com/source/drivers/usb/serial/pl2303.c#L363 The code I'm using to set odd baudrates is this one with Termios2 library: http://mail.python.org/pipermail/python-list/2012-October/633871.html this code, when run, tells me that the actual set baudrate is 230.4K, because obviously this is forced by the lines that I would like to remove (332->348). IMHO, this is the possible scenario when these lines will be removed: - All linux programs using Termios original library will still not be able to set custom baudrates as standard baudrates are forced by that library. Nothing will change. - All linux programs using any other methods of setting baudrates, will still be able to do so, but will also be able to set non-standard baudrates - Only problem: if a user mistypes the baudrate, he will have communication problems, because the driver will not correct it, but this is his problem only, and it's not something that the driver should handle. Also, the driver's way of forcing a different baudrate will also result in comm errors too, because if the user writes "1152000" instead of "115200", for example, the driver will set "1228800" and the communication will fail anyway. This "nanny" function, IMHO, is contrary to linux philosophy, where everything must be precise, case sensitive, and the user must write everything correctly, in exchange for great flexibility; obviously, if a user wants to set a custom baudrate, he will take all the risks associated with doing so, and he must know what he is doing, but the driver shouldn't be forcing a baudrate on the user. PS: this device (at least mine) WILL support 250K baudrate, as in windows I can set it in any software I use, and the output is spot on, measured with a digital oscilloscope. Regards Mastro Gippo 2013/6/9 Greg KH <greg@xxxxxxxxx>: > On Sun, Jun 09, 2013 at 10:38:01AM +0200, Mastro Gippo wrote: >> Hello, I'm working with a PL2303 device and I had an issue with the >> driver. Basically, I can't set the baudrate to 250kbps, but everything >> is better explained here: >> http://stackoverflow.com/questions/17000078/prolific-pl2303-serial-port-to-250000bps >> I think that removing lines from 332 to 348 of the driver the device >> will work even with non-standard (but common in embedded devices) >> baudrates. > > > What exact kernel version are you using? Have you tried removing those > lines and see what happens in the driver? > > How exactly are you trying to set "odd" baud rates in the device? Can > you provide a code example to test with? And what happens when you do > it? > >> Baudrates standards were set a long time ago to use the >> same clock to generate human-compatible timing, for example with >> 32.768kHz crystals. Nowadays, crystals come mostly in round numbers, >> and the Prolific device makes no exception, having a 12MHz clock. In >> all my embedded project I'm running these non-standard baudrates for >> that same reason. > > How do you know the speed of the crystal for this device? We don't have > a data sheet for it, and have no idea how this chip works. > >> I don't see any negative effects that may derive from this >> modification, but please let me know if there are any. > > Given that the driver has been working properly with this table for over > 10 years, and we don't have data sheets on how exactly this driver > works, and we don't know if this chip will even support different baud > rates than what is in it, it's a big risk to just rip it out now. > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
