[PATCH 1/4] ath10k: provide firmware crash info via debugfs.

[Michal Kazior]

On 6 June 2014 10:55, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> On 6 June 2014 08:10, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>>> Ben Greear <greearb at candelatech.com> writes:
>> [...]
>>>> I'm a bit leery of adding spin-locks in the dump routine just for
>>>> this, but I can add and use a new spin-lock if you prefer.
>>>
>>> Why a new spinlock? I didn't review the locking requirements, but I
>>> would first check ar->data_lock can be used.
>>>
>>>> If so, any idea if we can do the reads of the target's memory while
>>>> holding a spin-lock, or would I need some temporary buffers and only
>>>> lock while copying that in to the storage in the 'ar'?
>>>
>>> I don't see why you would need special locks for reading target's
>>> memory. If there is something needed, pci.c should handle that. Michal?
>>
>> By definition the diagnostic window access must be serialized. We
>> don't do this with locks now but rely ON driver states/sequences. We
>> might have some problems lurking there already but I'd need to analyze
>> it to tell for sure.
>
> Should that serialisation happen within pci.c?

You can but that's not a requirement I guess. E.g. exchange_bmi_msg
hif callback requires the caller to serialize calls.


Michał