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-next>] [day] [month] [year] [list]
Message-ID: <53BFDF22.1020302@linaro.org>
Date:	Fri, 11 Jul 2014 07:57:06 -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: 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
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ