[RFC v3 0/8] ath10k sdio support

[Erik Stromdahl]

Ok, I'll do another round of checkpatch before I submit anything.
I couldn't find the script you mentioned though (ath10k-check).
Is it some kind of checkpatch wrapper?

Anyway, I have a few warnings related to 'line over 80 chars' that
is really hard to get rid of (without breaking indentation etc.) so
I won't do anything about those for now.

Then there are some other warnings about the BIT macro being preferred
over (1 << x). I have used (1 << x) in some files despite the checkpatch
warning in order to keep the patches consistent with the existing code.
I think the best approach is to have a separate round of cleanup-patches
replacing all (1 << x) with BIT(x).

--
Erik

On 2017-02-19 14:59, Valo, Kalle wrote:
> Kalle Valo <kvalo at qca.qualcomm.com> writes:
>
>> Erik Stromdahl <erik.stromdahl at gmail.com> writes:
>>
>>> I was actually about to email you about this.
>>>
>>> I have made a few more updates to the sdio code so I think it would be
>>> best if I could submit a new series of patches based on this code (v4).
>>>
>>> Then you can tweak it (v5).
>>>
>>> It is only minor updates to the HIF layer (added QCA9377 support) and
>>> a setup of some pll registers.
>>
>> Ok, that sounds good. I'll wait for v4.
>
> Forgot to mention can you run ath10k-check before submitting them, it
> shows few problems:
>
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle#checking_code
>
> But if you wonder what this is about it's checkpatch warning about camel
> case (doesn't like the lower case x character):
>
> drivers/net/wireless/ath/ath10k/sdio.h:68: <ATH10K_SDIO_DRIVE_DTSx_TYPE_C>
>
> I guess I have a bug in the script when it parses checkpatch output.
>