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]
Message-ID: <CAPw-ZTnu+YvBN8PAZfMEKuY_3xTPDgr4qmNqi0JOCPXH_k0SDg@mail.gmail.com>
Date:   Mon, 8 May 2017 12:57:43 -0700
From:   Loc Ho <lho@....com>
To:     Jon Masters <jcm@...hat.com>
Cc:     Jon Mason <jon.mason@...adcom.com>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Robert Moore <robert.moore@...el.com>,
        Lv Zheng <lv.zheng@...el.com>, linux-acpi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devel@...ica.org, bcm-kernel-feedback-list@...adcom.com
Subject: Re: [PATCH] ACPI: SPCR: Use access width to determine mmio usage

Hi Jon,

>>
>>>> The current SPCR code does not check the access width of the mmio, and
>>>> uses a default of 8bit register accesses.  This prevents devices that
>>>> only do 16 or 32bit register accesses from working.  By simply checking
>>>> this field and setting the mmio string appropriately, this issue can be
>>>> corrected.  To prevent any legacy issues, the code will default to 8bit
>>>> accesses if the value is anything but 16 or 32.
>>>
>>> Thanks for this. Just as an FYI I've a running discussion with Microsoft
>>> about defining additional UART subtypes in the DBG2 for special case
>>> UARTs. Specifically, I want to address AppliedMicro's special 8250 dw IP
>>> that also has a non-standard clock. At this time, there is general
>>> agreement to use the access width for some cases rather than defining
>>> yet more subtypes - so your patch is good.
>>>
>>> Loc/Applied: please track this thread, incorporate feedback, and also
>>> track the other general recent discussions of 8250 dw from this week.
>>
>> Thanks for forward me this patch. This patch does not work with X-Gene
>> v1 and v2 SoC's. As BIOS SPCR encodes these info as:
>>
>> Bit Width: 32
>> Bit Offset: 0
>> Encoded Access Width: 01 (Byte Access)
>>
>> With this patch, it would use the "mmio" instead the "mmio32" as with
>> this patch - https://patchwork.kernel.org/patch/9460959
>
> I think this is why we need the DBG2 subtype for Applied X-Gene1. I'm
> hoping the update to the SPCR/DBG2 spec is done soon.

We can't rely on the BIOS change to support this new subtype as we
have system that is already in production deployment. When these
system upgrade to new version of the OS (stock, RHELSA, or whatever),
they will break. We need the patch from
https://patchwork.kernel.org/patch/9460959/ rolled upstream.

-Loc

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ