linux-kernel - Re: dw8250_set_termios() questions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Jul 2014 08:34:11 -0500
From:	Alex Elder <elder@...aro.org>
To:	heikki.krogerus@...ux.intel.com
CC:	Greg KH <gregkh@...uxfoundation.org>, david.daney@...ium.com,
	loic.poulain@...el.com, linux-serial@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Subject: Re: dw8250_set_termios() questions

Heikki, ping.

On 07/11/2014 07:57 AM, Alex Elder wrote:
> 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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/