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] [day] [month] [year] [list]
Message-ID: <85ec3e9a-e69b-ecd6-3d77-4364064c57a3@gmail.com>
Date:   Fri, 30 Apr 2021 14:37:01 +0200
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Wang Hongcheng <annie.wang@....com>, Ken Xue <Ken.Xue@....com>
Subject: Re: Support for AMDI0022 UART



On 4/24/21 12:25 PM, Andy Shevchenko wrote:
> On Fri, Apr 23, 2021 at 10:58 PM Maximilian Luz <luzmaximilian@...il.com> wrote:
>>
>> Hi all,
>>
>> I received a report from a Surface Laptop 4 which has a UART that is
>> identified as AMDI0022 in ACPI [1] and that does not seem to be
>> supported by the kernel yet.
>>
>>   From what I can tell via ACPI, this is similar to the AMDI0020 [2] UART
>> that's already supported by the kernel (well, both are devices with two
>> MMIO regions and an interrupt as far as I can tell...). So it's possible
>> that all that's needed is adding it to the respective device ID lists
>> [3, 4]. Unfortunately, I a) don't have a device to test this myself, b)
>> haven't found any more details on that online, and c) don't want to tell
>> others to test this without knowing a bit more about that (potentially
>> writing random stuff to some unknown MMIO region that I don't know
>> anything about doesn't sound as safe to me as I'd like).
> 
> To me they look completely the same. Depending on the device which is
> connected to the UART, I would suggest just to add an ID and see if it
> makes it work.

Thanks! We've tried that now and we do have some progress, meaning that
the serial device seems to work as expected (we have some basic
communication working).

The driver that we want to load (drivers/platform/surface/aggregator/)
still doesn't quite load yet, but that now seems to be due to a missing
GPIO driver for an AMDI0031 device. There's again an AMDI0030 in
drivers/pinctrl/pinctrl-amd.c, but this time the definitions do seem a
bit different (compare [5, 6]), specifically there are now two memory
regions (altough the combined size is still the same).

I'll try to have a look around and maybe ping the linux-gpio list if I
don't find anything else. I'll post some patches once we've got the
driver loading properly and can run some more tests.

Regards,
Max

[5]: AMDI0030 on Surface Laptop 3
https://github.com/linux-surface/acpidumps/blob/4da0148744164cea0c924dab92f45842fde03177/surface_laptop_3_amd/dsdt.dsl#L1767-L1802

[6]: AMDI0031 on Surface Laptop 4
https://github.com/linux-surface/acpidumps/blob/4da0148744164cea0c924dab92f45842fde03177/surface_laptop_4_amd/dsdt.dsl#L1404-L1428

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ