linux-kernel - Re: [PATCH linux-next] arm64: PCI: Introduce pcibios_free

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <01d7cf96c63c05097ef28789e2e27d6f@linux.dev>
Date:   Wed, 25 Aug 2021 10:49:14 +0000
From:   yajun.deng@...ux.dev
To:     "Will Deacon" <will@...nel.org>
Cc:     catalin.marinas@....com, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, lorenzo.pieralisi@....com
Subject: Re: [PATCH linux-next] arm64: PCI: Introduce pcibios_free_irq()
 helper function

August 25, 2021 6:05 PM, "Will Deacon" <will@...nel.org> wrote:

> [+Lorenzo]
> 
> On Wed, Aug 25, 2021 at 03:16:12PM +0800, Yajun Deng wrote:
> 
>> Introduce pcibios_free_irq() to free irq in pci_device_probe() and
>> pci_device_remove() that in drivers/pci/pci-driver.c.
> 
> Please can you describe the problem you're solving?
> 

pcibios_alloc_irq() will be called in pci_device_probe(), but there hasn't pcibios_free_irq()
in arm64 architecture correspond it. pcibios_free_irq() is an empty function in 
drivers/pci/pci-driver.c.So pcibios_alloc_irq() and pcibios_free_irq() don't correspond.

>> Signed-off-by: Yajun Deng <yajun.deng@...ux.dev>
>> ---
>> arch/arm64/kernel/pci.c | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index 1006ed2d7c60..40da5aff4548 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -25,10 +25,18 @@
>> int pcibios_alloc_irq(struct pci_dev *dev)
>> {
>> if (!acpi_disabled)
>> - acpi_pci_irq_enable(dev);
>> + return acpi_pci_irq_enable(dev);
> 
> This means we'll now fail device probe if we can't enable the GSI. Is that a
> problem?
> 
Oh, It would be better that hasn't return.
> Will