dw8250_set_termios() questions

Heikki, I have not been a subscriber of the linux-serial mailing list and didn't see this patch go by:
serial: 8250_dw: clock rate handling for all ACPI platforms
http://www.spinics.net/lists/linux-serial/msg12861.html

I had been working on doing something very similar for some Broadcom device tree based devices and it might have been helpful for me to have seen it. What I ended up with was *very* similar to what you did. Here is the last version of the patch I posted:

    https://lkml.org/lkml/2014/7/1/323

There *are* some differences, and I'd like to inquire about them before I simply use the code you have for my purpose.

These first two relate to whether I can use your code as-is:
- Why do you skip setting the clock if a null "old" pointer is supplied?
- I don't believe it's necessary to surround the clock rate change with clk_disable_unprepare() and clk_prepare_enable(). Do you believe otherwise?

This one is addressed to how your code is used now:
- Alan Cox had this question about my patch, and it seems to apply to your code as well:
"This assumes an arbitarily configurable clock, which is not I think the usual case."
https://lkml.org/lkml/2014/6/28/91
His point is that the clock, if adjustable, may not support a rate that produces an acceptable signal rate. Put another way, there may be a better frequency than what the clock framework selects that (in combination with the UART divisor latch registers) produces the best--or even a good--signal. Is there any chance any ACPI platforms will suffer this problem?

Thanks.

-Alex

Heikki, ping.

Quoted 12 lines

Heikki, I have not been a subscriber of the linux-serial mailing list and didn't see this patch go by:
serial: 8250_dw: clock rate handling for all ACPI platforms
http://www.spinics.net/lists/linux-serial/msg12861.html

I had been working on doing something very similar for some Broadcom device tree based devices and it might have been helpful for me to have seen it. What I ended up with was *very* similar to what you did. Here is the last version of the patch I posted:

    https://lkml.org/lkml/2014/7/1/323

Quoted 7 lines

There *are* some differences, and I'd like to inquire about them before I simply use the code you have for my purpose.

These first two relate to whether I can use your code as-is:
- Why do you skip setting the clock if a null "old" pointer is supplied?

Quoted 3 lines

- I don't believe it's necessary to surround the clock rate change with clk_disable_unprepare() and clk_prepare_enable(). Do you believe otherwise?

Quoted 6 lines

This one is addressed to how your code is used now:
- Alan Cox had this question about my patch, and it seems to apply to your code as well:
"This assumes an arbitarily configurable clock, which is not I think the usual case."
https://lkml.org/lkml/2014/6/28/91

Quoted 8 lines

His point is that the clock, if adjustable, may not support a rate that produces an acceptable signal rate. Put another way, there may be a better frequency than what the clock framework selects that (in combination with the UART divisor latch registers) produces the best--or even a good--signal. Is there any chance any ACPI platforms will suffer this problem?