> Maybe I'm locked in concepts of iwlwifi but I believe also other
> drivers uses similar concept. I think USB has some URB complete
> handler etc. So iwlwifi get interrupt (asynchronous) when packet is
> transmitted (TX response flow) and driver retrieves the information of
> transmitting. This is NOT done in TX contexts so you have to store
> tx_status between TX flows and TX response flow so you can feed it
> back to ieee80211_tx_status_irqsafe
Ah. But where's the difference between "TX response" and "TX status"
then? Anyway, yes, you do have to store the info between ->tx() and
tx_status().
> Not sure which flow will free this pointer ? Iwlwifi keeps tx_status
> attached to TBD so it have to be sure it won't be overriden somewhere
> in the stack. But it might be a case that I'm not understand here
> something
I'd think that mac80211 would free it. I guess we should then have
something like
static inline struct ieee80211_tx_status *
ieee80211_alloc_tx_status(size_t num_rate_ctrl)
{
struct ieee80211_tx_status *s;
s = kzalloc(... the expression you had earlier...);
if (s)
s->num_rate_control = num_rate_control;
return s;
}
so that we can change that w/o changing all drivers. In fact, you'd
probably already allocate that in the TX flow and keep it around until
TX status.
Mind you, I'm just writing whatever comes to my head ;) Better ideas
welcome, especially since this makes tx_status_irqsafe() and tx_status()
behave completely differently. Incidentally, why does iwlwifi use both
depending on in_interrupt(), or rather, why isn't the content statically
known?
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
