On 09/12/2020 19:13, Greg KH wrote:
Hi Greg,
For this HW version, the device is on the system bus, directly addressable
by the CPU.
What do you mean by "system bus"?
Maybe my terminology is wrong, the point is that we have a platform
device driver.
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:)
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 serieshttps://lore.kernel.org/linux-scsi/1606905417-183214-1-git-send-email-john.garry@xxxxxxxxxx/T/#m0df7e7cd6f0819b99aaeb6b7f8939ef1e17b8a83.
Ah, I missed that, I thought that was some high-speed scsi thing, not a
tiny platform driver...
It is actually is a high-speed SCSI thing also, SAS 3.0 :)
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.
irq experts are cc'ed and have been very helpful here
So the API mushroomed a bit over time, as I realized that we need to
support tearing down the irq mapping, make as devm method, use
irq_calc_affinity_vectors(). Not sure how we could factor any of it out
to become less of your problem.
Thanks,
John
