We currently only support processing 2 events in the workqueue: phy up and control phy. However we may want to use more in the future, likeWe could create a work_struct for each event, which would be fine.
Yes, that would be the normal way to do it. You initialize the work
structures from the initial probe function to have the right
callbacks, and then you just queue the right one when you need to
defer an event.
How many different events are there?
YesHowever we would sometimes still need some way of passing data to
the event, like the phy control example.
Do you mean the 'int func' argument to hisi_sas_control_phy_work?
It sounds like that would again just be more different work_structs.I'll check on this. We need to consider how to pass the argument for the control phy case.
At some point that might get silly (having 10 or more work structs
per phy), but then you could restructure the code to use something
other that work queues to get from interrupt context to process
context, e.g. a threaded interrupt handler.
Understood. For what it's worth, I was just following other SAS drivers
Note that the current code is not only unusual but also fragile
because you rely on GFP_ATOMIC memory allocations from the interrupt
handler, and they tend to eventually fail.
Thanks, John
Arnd -- To unsubscribe from this list: send the line "unsubscribe
linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
.