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:	Fri, 17 Feb 2012 09:46:54 -0800
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	"lkml, " <linux-kernel@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>, Alan Cox <alan@...ux.intel.com>,
	linux-serial@...r.kernel.org
Subject: Re: pch_uart and pch_phub clock selection



On 02/16/2012 05:30 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 16, 2012 at 04:57:59PM -0800, Darren Hart wrote:
>> I'm working on a tunnel creek (atom e6xx + topcliff PCH) development platform
>> that uses a 48MHz or 64MHz clock to drive the pch_uart. I've found that if I
>> force the uart_clock to 48MHz (or 64MHz on the latest rev) I can get the kernel
>> messages and getty on the serial port.
>>
>> I see that the the CM-iTC board is special-cased to set a 192MHz uart_clock.
>> This is done in pch_uart.c code, but there is some register manipulation done in
>> the pch_phub.c driver and I don't understand the connection. How are the two
>> related?
>>
>> Is the pch_phub.c register manipulation required for proper related? It seems to
>> work without touching those registers if I just force the clock.
>>
>> The device I'm working with is EFI, and the dmi_get_system_info(DMI_BOARD_NAME)
>> returns "(null)", so I can't use the same test to identify this board. Is there
>> another common mechanism I might be able to use?
> 
> There's no relevant DMI information for the board at all?  What does:
> 	grep . /sys/class/dmi/id/*
> show?

Duh.

# cat /sys/class/dmi/id/product_name
Fish River Island II


> 
>>
>> The following patch (by way of example, not meant for inclusion) gets things
>> working for this particular board with this command line:
>>
>> console=ttyPCH1,115200 pch_uart.clock_param=48000000
>>
>> I believe the right thing to do here is to discover a way to identify the board
>> and special case the clock as is done for the CM-iTC, but I would like to
>> understand the purpose of the pch_phub register manipulation code. Does this
>> make sense?
>>
>> Thanks,
>>
>> Darren
>>
>>
>> >From f83fa6cb575844d8e37f136890fe32258eb88dd2 Mon Sep 17 00:00:00 2001
>> Message-Id: <f83fa6cb575844d8e37f136890fe32258eb88dd2.1329439822.git.dvhart@...ux.intel.com>
>> From: Darren Hart <dvhart@...ux.intel.com>
>> Date: Wed, 15 Feb 2012 15:44:18 -0800
>> Subject: [PATCH] pch_uart: Add clock parameter
>>
>> Allow for the specification of the clock as a module parameter. This is useful
>> when a board uses a non-standard clock, or when different versions of a board
>> use different clocks, and that board name or the version are not available to
>> the kernel.
> 
> You also rename base_baud to uart_clock here, so you might want to
> mention it in the changelog entry :)
> 

Right, thanks. I suspect I'll end up breaking that change out as a
semantic patch :-)

> greg k-h

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
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