[PATCH] ath10k: Add the target register access and memory dump debugfs interface

Michal Kazior michal.kazior at tieto.com
Mon Nov 24 06:03:10 PST 2014


On 24 November 2014 at 14:50, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Yanbo Li <yanbol at qti.qualcomm.com> writes:
[...]
>> +     spin_lock_bh(&ar->data_lock);
>> +     reg_addr = ar->debug.reg_addr;
>> +     spin_unlock_bh(&ar->data_lock);
>
> [...]
>
>> +     spin_lock_bh(&ar->data_lock);
>> +     ar->debug.reg_addr = reg_addr;
>> +     spin_unlock_bh(&ar->data_lock);
>
> [...]
>
>> +     spin_lock_bh(&ar->data_lock);
>> +     reg_addr = ar->debug.reg_addr;
>> +     spin_unlock_bh(&ar->data_lock);
>
> [...]
>
>> +     spin_lock_bh(&ar->data_lock);
>> +     reg_addr = ar->debug.reg_addr;
>> +     spin_unlock_bh(&ar->data_lock);
>
> I admit that I'm far from a locking expert, but does that make any
> difference in the functionality?

I imagine reg_addr could end up needing 2 instructions to be set on
some weird architecture+compiler combination in which case locking is
desired. With multiple access to write reg_addr you could end up
reading an address that either isn't the old nor the new one. Should
be harmless though and you could argue that you shouldn't access the
reg_addr debugfs file simultaneously in the first place. Maybe I'm
just over-exaggerating? :-)


Michał



More information about the ath10k mailing list