linux-kernel - Re: [PATCH v5] arm pl011 serial: support multi-irq request

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 Jul 2021 10:57:09 +0800
From:   Bing Fan <hptsfb@...il.com>
To:     Robin Murphy <robin.murphy@....com>,
        Qian Cai <quic_qiancai@...cinc.com>,
        gregkh@...uxfoundation.org, Bing Fan <tombinfan@...cent.com>
Cc:     linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5] arm pl011 serial: support multi-irq request

hello,

Thanks very much for analysis. And i have get the cause of the problem.

I will add pl011_allocate_multi_irqs/pl011_release_multi_irqs functions 
for amba drivers,

and call them in pl011_startup/pl011_shutdown respectively.


Reserved pl011_allocate_irq/pl011_release_irq functions for platform 
drivers.

Please help to confirm, is this ok?





在 7/27/2021 5:14, Robin Murphy 写道:
> On 2021-07-26 21:56, Qian Cai wrote:
>>
>>
>> On 7/26/2021 4:36 PM, Robin Murphy wrote:
>>> The important point you're missing, but which the KASAN dump does 
>>> hint at, is
>>> that that is a machine with SBSA generic UARTs booting via ACPI - I 
>>> know it
>>> doesn't do DT at all because I have one too. What matters there is 
>>> that pl011
>>> binds as a platform driver, *not* an amba driver.
>>
>> Thanks for pointing out, Robin. I just yet to see an ARM server 
>> booting from DT
>> those days.
>
> Unlikely in production datacentre/cloud environments, indeed, although 
> some of the mid-range kit like LX2160 does start to blur the line of 
> what might be considered "server", and that's one example which *does* 
> have full-featured DT support (even if it also aspires to ACPI...)
>
> What I thought was worth clarifying for the general audience is that 
> the relevant aspects of "server" here should in fact still be possible 
> to reproduce on something like a Raspberry Pi or a tiny QEMU VM, if 
> one can figure out the ACPI runes :)
>
> Thanks,
> Robin.