linux-kernel - Re: inverse mapping from a struct console to device

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:	Tue, 27 Jan 2015 15:42:09 -0500
From:	Jon Masters <jcm@...hat.com>
To:	Mark Rutland <mark.rutland@....com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"leif.lindholm@...aro.org" <leif.lindholm@...aro.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Andre Przywara <Andre.Przywara@....com>,
	Torez Smith <torez@...hat.com>
Subject: Re: inverse mapping from a struct console to device

On 01/27/2015 07:30 AM, Mark Rutland wrote:
> On Tue, Jan 27, 2015 at 11:54:18AM +0000, Jon Masters wrote:

>> Here's an example of the data we get in the SPCR for reference:
>>
>> [0012]               Serial Port Register : [Generic Address Structure]
>> [0001]                           Space ID : 00 [SystemMemory]
>> [0001]                          Bit Width : 08
>> [0001]                         Bit Offset : 00
>> [0001]               Encoded Access Width : 01 [Byte Access:8]
>> [0008]                            Address : 000000001c020000
>>
>> [0001]                     Interrupt Type : 08
>> [0001]                PCAT-compatible IRQ : 00
>> [0004]                          Interrupt : 0000006C
>> [0001]                          Baud Rate : 07
>> [0001]                             Parity : 00
>> [0001]                          Stop Bits : 01
>> [0001]                       Flow Control : 00
>> [0001]                      Terminal Type : 00
>> [0001]                           Reserved : 00
>>
>> The actual structure is longer, but you get the idea. I first map this
>> to the correct Device in the DSDT with a device_initcall that will find
>> the table then walk the ACPI namespace to find the corresponding device.
>> This is stashed so that later we can perform the same kind of comparison
>> that you do with DT today. I also populate options, though so far have
>> only bothered to implement baud rate.
> 
> I would recommend that you set up as many of these ASAP. Otherwise
> someone's certain to mess up a table and we can never add them later.

So this is why I'm doing this (and other annoying things) right now - to
make sure that vendors shipping platforms have valid data we can also
use. If we wait until later, we'll have systems that potentially do the
wrong thing. The table above is an example of one for the Mustang. I had
the revision bumped to 2 and the IRQ information added to the reference
one, and I've also verified the tables for Seattle, as well as "other"
hardware that is in the pipeline from other vendors.

> Otherwise, sounds good!

So I'm handing this to Torez Smith to followup on (please keep her
copied on replies to this thread). I'm attaching a *hack* patch I put
together to proof of concept and then Torez will make this into
something actually useable/upstreamable (without hard coded static baud
strings and the like that I used to hack it up).

Jon.


View attachment "spcr_wip2.patch" of type "text/x-patch" (5762 bytes)