linux-kernel - Re: [PATCH v5 4/5] Driver core: platform: Add devm_platform_get_irqs

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:   Wed, 09 Dec 2020 19:39:03 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     John Garry <john.garry@...wei.com>, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, lenb@...nel.org, rjw@...ysocki.net,
        tglx@...utronix.de, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org, linuxarm@...wei.com,
        linux-acpi@...r.kernel.org, dwagner@...e.de
Subject: Re: [PATCH v5 4/5] Driver core: platform: Add
 devm_platform_get_irqs_affinity()

On 2020-12-09 19:13, Greg KH wrote:
> On Wed, Dec 09, 2020 at 07:04:02PM +0000, John Garry wrote:
>> On 09/12/2020 18:32, Greg KH wrote:
>> > On Wed, Dec 02, 2020 at 06:36:56PM +0800, John Garry wrote:
>> > > Drivers for multi-queue platform devices may also want managed interrupts
>> > > for handling HW queue completion interrupts, so add support.
>> >
>> 
>> Hi Greg,
>> 
>> > Why would a platform device want all of this?  Shouldn't such a device
>> > be on a "real" bus instead?
>> 
>> For this HW version, the device is on the system bus, directly 
>> addressable
>> by the CPU.
> 
> What do you mean by "system bus"?
> 
>> Motivation is that I wanted to switch the HW completion queues to use
>> managed interrupts.
> 
> Fair enough, seems like overkill for a "platform" bus though :)

You should see the box, really... ;-)

> 
>> > What in-kernel driver needs this complexity?  I can't take new apis
>> > without a real user in the tree, sorry.
>> 
>> It's in the final patch in the series 
>> https://lore.kernel.org/linux-scsi/1606905417-183214-1-git-send-email-john.garry@huawei.com/T/#m0df7e7cd6f0819b99aaeb6b7f8939ef1e17b8a83.
> 
> Ah, I missed that, I thought that was some high-speed scsi thing, not a
> tiny platform driver...
> 
>> I don't anticipate a huge number of users of this API in future, as 
>> most
>> multi-queue devices are PCI devices; so we could do the work of this 
>> API in
>> the driver itself, but the preference was not to export genirq 
>> functions
>> like irq_update_affinity_desc() or irq_create_affinity_masks(), and 
>> rather
>> have a common helper in the core platform code.
> 
> Ok, I'd like to have the irq maintainers/developers ack this before
> taking it in the driver core, as someone is going to have to maintain
> this crazy thing for forever if it gets merged.

I'm actually quite happy with this, and as it turns out, the crazy
system that has this SAS thing keeps my backside warm all year long.
As long as this machine keeps ticking, I'm happy to help with this.

So if that helps:

Acked-by: Marc Zyngier <maz@...nel.org>

We need to work out the merge strategy for the whole lot though, given
that it crosses 3 subsystems over two series...

         M.
-- 
Jazz is not dead. It just smells funny...