On 13/11/2024 12:36, Daniel Wagner wrote:
@@ -48,6 +48,7 @@ struct fwnode_handle;
* will never get called until they do.
* @remove: Called when a device removed from this bus.
My impression is that this would be better suited to "struct device_driver",
but I assume that there is a good reason to add to "struct bus_type".
I think the main reason to put it here is that most of the drivers are
happy with the getter on bus level and don't need special treatment. We
don't have to touch all the drivers to hookup a common getter, nor do we
have to install a default handler when the driver doesn't specify one.
Having the callback in struct bus_driver avoids this. Though Christoph
suggested it, so I can only guess.
But you bring up a good point, if we had also an irq_get_affinity
callback in struct device_driver it would be possible for the
hisi_sas v2 driver to provide a getter and blk_mq_hctx_map_queues could
do:
for (queue = 0; queue < qmap->nr_queues; queue++) {
if (dev->driver->irq_get_affinity)
mask = dev->driver->irq_get_affinity;
else if (dev->bus->irq_get_affinity)
mask = dev->bus->irq_get_affinity(dev, queue + offset);
if (!mask)
goto fallback;
for_each_cpu(cpu, mask)
qmap->mq_map[cpu] = qmap->queue_offset + queue;
}
and with this in place the open coded version in hisi_sas v2 can also be
replaced.
Yeah, I think that it could be plugged in like:
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index 342d75f12051..5172af77a3f0 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -3636,6 +3636,7 @@ static struct platform_driver hisi_sas_v2_driver = {
.name = DRV_NAME,
.of_match_table = sas_v2_of_match,
.acpi_match_table = ACPI_PTR(sas_v2_acpi_match),
+ .irq_get_affinity_mask = hisi_sas_v2_get_affinity_mask,
},
};
If no one objects, I go ahead and add the callback to struct
device_driver.
I'd wait for Christoph and Greg to both agree. I was just wondering why
we use bus_type.
