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 <kv...@qca.qualcomm.com> writes:
Erik Stromdahl <erik.stromd...@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.
