Re: [RFC v3 0/8] ath10k sdio support

[Valo, Kalle]

Erik Stromdahl  writes:

> Ok, I'll do another round of checkpatch before I submit anything.
> I couldn't find the script you mentioned though (ath10k-check).

Did you check the link I gave you:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle#checking_code

> Is it some kind of checkpatch wrapper?

It runs various tests (gcc, sparse, checkpatch), sets some checkpatch
settings (like line length) and filters out warnings we don't care
about.

> 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).

These are all disabled by ath10k-check. I think it's easiest that you
forget ath10k-check for now and let me fix those in the next round.

-- 
Kalle Valo

Re: [RFC v3 0/8] ath10k sdio support

[Erik Stromdahl]

On 2017-02-19 15:05, Valo, Kalle wrote:

Erik Stromdahl  writes:


I just noticed that Ryan Hsu submitted two patches containing similar
functionality to what I have in my tree on github. They have not been
integrated in the ath master yet, but they have been added to master-pending.

Below are the commits I am talking about

bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware
download time for QCA9377
db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware
download time for QCA6174

Since some of my patches overlap with these I think it would be best if
I add these to my tree and rewrite my patches.

If they haven't made it into master before I submit my updated patch series
I will include them in my set.

Is this OK?

If they will be added to master soon there is no issue since I will of course
rebase to the latest ath-MMDDHHmm before I submit anything.


That's ok, just mention this in the cover letter.

Even better is that if you can use master-pending from ath.git as the
baseline (compared to the master branch normally recommended), Ryan's
patches are there now. That way you don't need to apply anything extra
to your tree. But I'm hoping to apply Ryan's patches soon anyway.



Ok, I'll make it so.

Re: [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  writes:


Erik Stromdahl  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: 

I guess I have a bug in the script when it parses checkpatch output.

Re: [RFC v3 0/8] ath10k sdio support

[Valo, Kalle]

Erik Stromdahl  writes:

> I just noticed that Ryan Hsu submitted two patches containing similar
> functionality to what I have in my tree on github. They have not been
> integrated in the ath master yet, but they have been added to master-pending.
>
> Below are the commits I am talking about
>
> bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware
> download time for QCA9377
> db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware
> download time for QCA6174
>
> Since some of my patches overlap with these I think it would be best if
> I add these to my tree and rewrite my patches.
>
> If they haven't made it into master before I submit my updated patch series
> I will include them in my set.
>
> Is this OK?
>
> If they will be added to master soon there is no issue since I will of course
> rebase to the latest ath-MMDDHHmm before I submit anything.

That's ok, just mention this in the cover letter.

Even better is that if you can use master-pending from ath.git as the
baseline (compared to the master branch normally recommended), Ryan's
patches are there now. That way you don't need to apply anything extra
to your tree. But I'm hoping to apply Ryan's patches soon anyway.

-- 
Kalle Valo

Re: [RFC v3 0/8] ath10k sdio support

[Erik Stromdahl]

Hej,

I just noticed that Ryan Hsu submitted two patches containing similar
functionality to what I have in my tree on github. They have not been
integrated in the ath master yet, but they have been added to master-pending.

Below are the commits I am talking about

bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware download 
time for QCA9377
db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware download 
time for QCA6174

Since some of my patches overlap with these I think it would be best if
I add these to my tree and rewrite my patches.

If they haven't made it into master before I submit my updated patch series
I will include them in my set.

Is this OK?

If they will be added to master soon there is no issue since I will of course
rebase to the latest ath-MMDDHHmm before I submit anything.

/Erik

On 2017-02-19 00:57, Valo, Kalle wrote:

Erik Stromdahl  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.


btw, should I still mark them as RFC or should it be PATCH this time?

If I go for PATCH, should the version be v4 or should I start from v1?


v4 would be fine. Thanks.

Re: [RFC v3 0/8] ath10k sdio support

[Valo, Kalle]

Kalle Valo  writes:

> Erik Stromdahl  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: 

I guess I have a bug in the script when it parses checkpatch output.

-- 
Kalle Valo

Re: [RFC v3 0/8] ath10k sdio support

[Erik Stromdahl]

Hej,

I just noticed that Ryan Hsu submitted two patches containing similar
functionality to what I have in my tree on github. They have not been
integrated in the ath master yet, but they have been added to master-pending.

Below are the commits I am talking about

bc1054a15be3c962c83aa22476a3e9c1266da792 ath10k: improve the firmware download 
time for QCA9377
db5af2a25bd8c1410ec4456d1d4f4e6ded2649ca ath10k: improve the firmware download 
time for QCA6174

Since some of my patches overlap with these I think it would be best if
I add these to my tree and rewrite my patches.

If they haven't made it into master before I submit my updated patch series
I will include them in my set.

Is this OK?

If they will be added to master soon there is no issue since I will of course
rebase to the latest ath-MMDDHHmm before I submit anything.

/Erik

On 2017-02-19 00:57, Valo, Kalle wrote:

Erik Stromdahl  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.


btw, should I still mark them as RFC or should it be PATCH this time?

If I go for PATCH, should the version be v4 or should I start from v1?


v4 would be fine. Thanks.

Re: [RFC v3 0/8] ath10k sdio support

[Valo, Kalle]

Erik Stromdahl  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.

> btw, should I still mark them as RFC or should it be PATCH this time?
>
> If I go for PATCH, should the version be v4 or should I start from v1?

v4 would be fine. Thanks.

-- 
Kalle Valo

Re: [RFC v3 0/8] ath10k sdio support

[Erik Stromdahl]

Hej Kalle,

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.

I will get back to you shortly.

btw, should I still mark them as RFC or should it be PATCH this time?

If I go for PATCH, should the version be v4 or should I start from v1?

/Erik

On 2017-02-18 14:40, Valo, Kalle wrote:

Hej,

Erik Stromdahl  writes:


This is the third version of the sdio RFC patch series.
The actual sdio code (patch 6) has been subject to a massive overhaul,
mainly as a result of Kalle's review comments.
It no longer has any strong resemblance of the original ath6kl code from
which it was originally based upon.

Previous pathes 6 to 10 have been merged into one single patch.

The previous series had a rework of the "HTC fake service" connect
(ep 0 connect) that introduced a race between the actual endpoint
connect and the HTC ready message. This issue has been addressed,
and the current patches (3 and 4) has been rewritten accordingly.

* overview of patches *

Patches 1 to 4 are more or less identical to the previous RFC, with an
exception for patch 3 that changes the "HTC fake service" connect
(mentioned above).

Patch 5 is a squashed version of previous patches 6 to 10.

Patch 6 is the actual sdio patch

Patches 7 to 8 are new and adds special sdio versions of BMI get
target info and HTC ready.

The new version was built and tested against:
tag: ath-201701121109

Erik Stromdahl (8):
  ath10k: htc: made static function public
  ath10k: htc: rx trailer lookahead support
  ath10k: htc: move htc ctrl ep connect to htc_init
  ath10k: htc: refactorization
  ath10k: various sdio related definitions
  ath10k: sdio support
  ath10k: sdio get target info
  ath10k: htc: ready_ext msg support


Sorry for not getting back to you earlier, haven't found time to look
this in detail during the last few weeks.

This is looking quite good now. I have some nitpicks (build warnings,
maybe reorder some patches etc) still but I think it's faster if I fix
those and send v4 as a proper patch (no RFC anymore), naturally
attributing you as the author. Is that ok for you?

Re: [RFC v3 0/8] ath10k sdio support

[Valo, Kalle]

Hej,

Erik Stromdahl  writes:

> This is the third version of the sdio RFC patch series.
> The actual sdio code (patch 6) has been subject to a massive overhaul,
> mainly as a result of Kalle's review comments.
> It no longer has any strong resemblance of the original ath6kl code from
> which it was originally based upon.
>
> Previous pathes 6 to 10 have been merged into one single patch.
>
> The previous series had a rework of the "HTC fake service" connect
> (ep 0 connect) that introduced a race between the actual endpoint
> connect and the HTC ready message. This issue has been addressed,
> and the current patches (3 and 4) has been rewritten accordingly.
>
> * overview of patches *
>
> Patches 1 to 4 are more or less identical to the previous RFC, with an
> exception for patch 3 that changes the "HTC fake service" connect
> (mentioned above).
>
> Patch 5 is a squashed version of previous patches 6 to 10.
>
> Patch 6 is the actual sdio patch
>
> Patches 7 to 8 are new and adds special sdio versions of BMI get
> target info and HTC ready.
>
> The new version was built and tested against:
> tag: ath-201701121109
>
> Erik Stromdahl (8):
>   ath10k: htc: made static function public
>   ath10k: htc: rx trailer lookahead support
>   ath10k: htc: move htc ctrl ep connect to htc_init
>   ath10k: htc: refactorization
>   ath10k: various sdio related definitions
>   ath10k: sdio support
>   ath10k: sdio get target info
>   ath10k: htc: ready_ext msg support

Sorry for not getting back to you earlier, haven't found time to look
this in detail during the last few weeks.

This is looking quite good now. I have some nitpicks (build warnings,
maybe reorder some patches etc) still but I think it's faster if I fix
those and send v4 as a proper patch (no RFC anymore), naturally
attributing you as the author. Is that ok for you?

-- 
Kalle Valo

Re: [RFC v3 0/8] ath10k sdio support

[Valo, Kalle]

Erik Stromdahl  writes:

> This is the third version of the sdio RFC patch series.
> The actual sdio code (patch 6) has been subject to a massive overhaul,
> mainly as a result of Kalle's review comments.
> It no longer has any strong resemblance of the original ath6kl code from
> which it was originally based upon.
>
> Previous pathes 6 to 10 have been merged into one single patch.
>
> The previous series had a rework of the "HTC fake service" connect
> (ep 0 connect) that introduced a race between the actual endpoint
> connect and the HTC ready message. This issue has been addressed,
> and the current patches (3 and 4) has been rewritten accordingly.
>
> * overview of patches *
>
> Patches 1 to 4 are more or less identical to the previous RFC, with an
> exception for patch 3 that changes the "HTC fake service" connect
> (mentioned above).
>
> Patch 5 is a squashed version of previous patches 6 to 10.
>
> Patch 6 is the actual sdio patch
>
> Patches 7 to 8 are new and adds special sdio versions of BMI get
> target info and HTC ready.
>
> The new version was built and tested against:
> tag: ath-201701121109
>
> Erik Stromdahl (8):
>   ath10k: htc: made static function public
>   ath10k: htc: rx trailer lookahead support
>   ath10k: htc: move htc ctrl ep connect to htc_init
>   ath10k: htc: refactorization
>   ath10k: various sdio related definitions
>   ath10k: sdio support
>   ath10k: sdio get target info
>   ath10k: htc: ready_ext msg support

I pushed now this, and your usb series as well, to ath.git
master-pending branch. Let's see if kbuild bot finds any problems.

-- 
Kalle Valo

[RFC v3 0/8] ath10k sdio support

[Erik Stromdahl]

This is the third version of the sdio RFC patch series.
The actual sdio code (patch 6) has been subject to a massive overhaul,
mainly as a result of Kalle's review comments.
It no longer has any strong resemblance of the original ath6kl code from
which it was originally based upon.

Previous pathes 6 to 10 have been merged into one single patch.

The previous series had a rework of the "HTC fake service" connect
(ep 0 connect) that introduced a race between the actual endpoint
connect and the HTC ready message. This issue has been addressed,
and the current patches (3 and 4) has been rewritten accordingly.

* overview of patches *

Patches 1 to 4 are more or less identical to the previous RFC, with an
exception for patch 3 that changes the "HTC fake service" connect
(mentioned above).

Patch 5 is a squashed version of previous patches 6 to 10.

Patch 6 is the actual sdio patch

Patches 7 to 8 are new and adds special sdio versions of BMI get
target info and HTC ready.

The new version was built and tested against:
tag: ath-201701121109

Erik Stromdahl (8):
  ath10k: htc: made static function public
  ath10k: htc: rx trailer lookahead support
  ath10k: htc: move htc ctrl ep connect to htc_init
  ath10k: htc: refactorization
  ath10k: various sdio related definitions
  ath10k: sdio support
  ath10k: sdio get target info
  ath10k: htc: ready_ext msg support

 drivers/net/wireless/ath/ath10k/Kconfig |6 +
 drivers/net/wireless/ath/ath10k/Makefile|3 +
 drivers/net/wireless/ath/ath10k/bmi.c   |   70 +
 drivers/net/wireless/ath/ath10k/bmi.h   |2 +
 drivers/net/wireless/ath/ath10k/core.c  |5 +-
 drivers/net/wireless/ath/ath10k/core.h  |3 +
 drivers/net/wireless/ath/ath10k/debug.h |2 +
 drivers/net/wireless/ath/ath10k/htc.c   |  241 ++-
 drivers/net/wireless/ath/ath10k/htc.h   |   39 +-
 drivers/net/wireless/ath/ath10k/hw.h|   53 +
 drivers/net/wireless/ath/ath10k/sdio.c  | 2105 +++
 drivers/net/wireless/ath/ath10k/sdio.h  |  259 
 drivers/net/wireless/ath/ath10k/targaddrs.h |   24 +
 13 files changed, 2737 insertions(+), 75 deletions(-)
 create mode 100644 drivers/net/wireless/ath/ath10k/sdio.c
 create mode 100644 drivers/net/wireless/ath/ath10k/sdio.h

-- 
2.7.4