On Wednesday 22 May 2013, Arnd Bergmann wrote: > > Also all of the custom_divisor functionality is basically commented as "old" > > or has a kernel warning saying it is deprecated (see uart_set_info), so as > > far as I can see for our (and I suspect most) hardware it is completely > > irrelevant functionality. > > What may have happened here is that custom_divisor was used in a different > way when I added that code than it is today, and the change was not propagated > into the of_serial driver. However, going back to 2.6.20 shows no different > code than what we have today in this regard. It may simply have been > a mistake on my side. Thanks for looking into this and digging around in the history. At least I didn't miss something really obvious. > I looked it up in the original serial port binding at > http://www.openfirmware.org/1275/bindings/devices/html/serial.ht > ml, which does > not specify the property, and in ePAPR, which does have it in the > section about > "serial class devices": > > 18 6.2.1.2 current-speed > 19 Property: current-speed > 20 Value type: <u32> > 21 Description: > 22 Specifies the current speed of a serial device in bits per second. A > boot program should set > 23 this property if it has initialized the serial device. > 24 Example: > 25 current - speed = <115200>; # 115200 baud > > The reason you want this is so that the driver can initialize the hardware from > scratch more easily and get back to the same settings. Why they only specified > the baud rate but not also start/stop bits and flow control I don't understand > though. Yes, I had been made aware of the ePAPR definition by Srini after I sent the post. In fact I had exactly the same question in my head about the other settings as well. > > I guess you can ignore my original comment. > OK. Thanks again for your time. Regards, -stephen -- 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
