Re: [ath9k-devel] [PATCH v4] ath9k: Switch to using mac80211 intermediate software queues.

2017-01-07 Thread Arend van Spriel 


On 23-08-16 08:59, Kalle Valo wrote:
> Toke Høiland-Jørgensen  writes:
> 
> This is great work but due to the regressions I'm not sure if this
> will be ready for 4.9. To get more testing time I wonder if we should
> wait for 4.10? IMHO applying this in the end of the cycle is too risky
> and we should try to maximise the time linux-next by applying this
> just after -rc1 is released.
>
> Thoughts?

 Well, now that we understand what is causing the throughput regressions,
 fixing them should be fairly straight forward (yeah, famous last words,
 but still...). I already have a patch for the fast path and will go poke
 at the slow path next. It'll probably require another workaround or two,
 so I guess it won't be the architecturally clean ideal solution; but it
 would make it possible to have something that works for 4.9 and then
 iterate for a cleaner design for 4.10.
>>>
>>> But if we try to rush this to 4.9 it won't be in linux-next for long. We
>>> are now in -rc3 and let's say that the patches are ready to apply in two
>>> weeks. That would leave us only two weeks of -next time before the merge
>>> window, which I think is not enough for a controversial patch like this
>>> one. There might be other bugs lurking which haven't been found yet.
>>
>> What, other hidden bugs? Unpossible! :)
> 
> Yeah, right ;)
> 
>> Would it be possible to merge the partial solution (which is ready now,
>> basically) and fix the slow path in a separate patch later?
> 
> What do you mean with partial solution? You mean ath9k users would
> suffer from regressions until they are fixed? We can't do that.
> 
>> (Just spit-balling here; I'm still fairly new to this process. But I am
>> concerned that we'll hit a catch-22 where we can't get wider testing
>> before it's "ready" and we can't prove that it's "ready" until we've had
>> wider testing...)

So could the wider testing be accomplished by working on a branch in the
wireless-testing repo and make its availability known on wireless-list,
ath?k-list, LWN or whatever.

Regards,
Arend

> I understand your point, but I don't want to rush this to 4.9 and then
> start getting lots of bug reports and eventually forced to revert it. If
> we just found a new serious regression the chances are that there are
> more lurking somewhere and this patch is just not ready yet.

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH RFC v2 1/2] Documentation: dt: net: add ath9k wireless device binding

2017-01-07 Thread Arend Van Spriel 


On 23-6-2016 19:45, Martin Blumenstingl wrote:
> Add documentation how devicetree can be used to configure ath9k based
> devices.
> 
> Signed-off-by: Martin Blumenstingl 
> ---
> changes in v1 -> v2:
> - use vendor prefix "qca" instead of "ath"
> - extend the example so it includes the "compatible" property
> 
>  .../devicetree/bindings/net/wireless/qca,ath9k.txt | 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> new file mode 100644
> index 000..bb78f68
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/qca,ath9k.txt
> @@ -0,0 +1,41 @@
> +* Qualcomm Atheros ath9k wireless devices
> +
> +This node provides properties for configuring the ath9k wireless device. The
> +node is expected to be specified as a child node of the PCI controller to
> +which the wireless chip is connected.
> +
> +Required properties:
> +- compatible: Should be "qca,ath9k"
> +
> +Optional properties:
> +- reg: Address and length of the register set for the device.

Is 'reg' property handled. I don't see it in patch 2/2.

> +- qca,gpio-mask: The GPIO mask
> +- qca,gpio-val: The GPIO value
> +- qca,led-pin: The GPIO number to which the LED is connected
> +- qca,led-active-high: The LED is active when the GPIO is HIGH
> +- qca,clk-25mhz: Defines that at 25MHz clock is used

For the above I can somehow see them as variables for different hardware
platforms.

> +- qca,eeprom-name: The name of the file which contains the EEPROM data (which
> + will be loaded via request_firmware)
> +- qca,check-eeprom-endianness: Allow checking the EEPROM endianness and
> + swapping of the EEPROM data if required
> +- qca,disable-2ghz: Disables the 2.4GHz band, even if enabled in the EEPROM
> +- qca,disable-5ghz: Disables the 5GHz band, even if enabled in the EEPROM

These not really. Storing filename information in device tree seems
wrong as it does not describe hardware configuration. The other three
also seem more like driver module parameters. I think what you are
trying here with the last two properties is to use the same eeprom file
for different types of hardware, ie. for dual-band, 2g-only, and 5g-only
devices. From device tree perspective I would use those types, eg.:

qca,2g-capable: Device can operate in 2.4GHz band.
qca,5g-capable: Device can operate in 5GHz band.

The other patch also looks for a MAC address for the device. I suppose
that should be documented as well.

> +In this example, the node is defined as child node of the PCI controller.
> +
> +pci {
> + pcie@0 {
> + reg = <0 0 0 0 0>;
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + device_type = "pci";
> +
> + ath9k@0,0 {
> + compatible = "qca,ath9k";
> + reg = <0 0 0 0 0>;
> + device_type = "pci";

Is this just a copy-paste or should device_type be specified?

Regards,
Arend
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [RFC] ath9k: advertise p2p dev support when chanctx

2015-06-15 Thread Arend van Spriel 
+ Jouni

On 06/15/15 17:47, Sujith Manoharan wrote:
 Janusz Dziedzic wrote:
 At least the callbacks for adding/removing interfaces need
 to be handled ?

 Strange, but I didn't hit any problem yet with my simple patch.

 Ok. But I am not very familiar with how p2p-device is supposed
 to be used...

The p2p-device is designed to be used for p2p discovery and p2p action 
frame exchange. It make it easier for driver and/or firmware to 
determine if user-space request is p2p related or not. However, in 
discussions with Jouni I got the impression that ath (or qca) firmware 
and/or drivers did not need this design. Not sure if that claim is 
unaffected by the use_chanctx=1 parameter.

Regards,
Arend

 Sujith
 --
 To unsubscribe from this list: send the line unsubscribe linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k-devel Digest, Vol 79, Issue 6

2015-01-10 Thread Arend van Spriel 
On 01/10/15 03:00, 杨铁军 wrote:
 Hi Arend
 My development environment is LINUX 2.26.31 Kernel, and I could not use
 new version kernel (The whole project work in Kernel 2.26.31, and the
 2.26.31 is provided by my device manufactuer, I had no power to update
 to new kernel). Could you give a suggestion how to test your patch in
 LINUX 2.26.31? I am new to LINUX.

I see. Well, you could grab this backports package [1] and apply the 
patch there. There is a twiki [2] containing info how to build, etc.

Regards,
Arend

[1] 
http://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.19-rc1/backports-3.19-rc1-1.tar.xz
[2] https://backports.wiki.kernel.org/

 Thanks,
 David
 -- Original --
 *From: * Arend van Sprielar...@broadcom.com;
 *Date: * Fri, Jan 9, 2015 06:01 PM
 *To: * 杨铁军y...@nethdv.com;
 *Cc: * ath9k-develath9k-devel@lists.ath9k.org;
 *Subject: * Re: ath9k-devel Digest, Vol 79, Issue 6
 On 01/09/15 02:54, 杨铁军 wrote:
   Hi Arend,
   I had ATH9k hardware, my wireless device is WLE350NX, it is AR9580 chip.
   Please send me your code to test!
   I am new to LINUX.

 Ok. The patch can be found on patchwork [1]. That page contains download
 links to get the patch. _mbox_ link can be used with 'git am' command.
 _patch_ link can be used with 'patch' command.

 Regards,
 Arend

 [1] https://patchwork.kernel.org/patch/5544621/

   Regards,
   David Yang
   -- Original --
   *From: * ath9k-devel-requestath9k-devel-requ...@lists.ath9k.org;
   *Date: * Thu, Jan 8, 2015 07:00 PM
   *To: * ath9k-develath9k-devel@lists.ath9k.org;
   *Subject: * ath9k-devel Digest, Vol 79, Issue 6
   Send ath9k-devel mailing list submissions to
   ath9k-devel@lists.ath9k.org
  
   To subscribe or unsubscribe via the World Wide Web, visit
   https://lists.ath9k.org/mailman/listinfo/ath9k-devel
   or, via email, send a message with subject or body 'help' to
   ath9k-devel-requ...@lists.ath9k.org
  
   You can reach the person managing the list at
   ath9k-devel-ow...@lists.ath9k.org
  
   When replying, please edit your Subject line so it is more specific
   than Re: Contents of ath9k-devel digest...
  
  
   Today's Topics:
  
   1. Re: [PATCH] ath: ath9k: use debugfs_create_devm_seqfile()
   helper for seq_file entries (Kalle Valo)
   2. Re: [PATCH] ath: ath9k: use debugfs_create_devm_seqfile()
   helper for seq_file entries (Sujith Manoharan)
  
  
   --
  
   Message: 1
   Date: Wed, 07 Jan 2015 20:05:00 +0200
   From: Kalle Valo kv...@codeaurora.org
   Subject: Re: [ath9k-devel] [PATCH] ath: ath9k: use
   debugfs_create_devm_seqfile() helper for seq_file entries
   To: Arend van Spriel ar...@broadcom.com
   Cc: ath9k-devel@lists.ath9k.org, linux-wireless
   linux-wirel...@vger.kernel.org
   Message-ID: 87bnmapiur@kamboji.qca.qualcomm.com
   Content-Type: text/plain; charset=us-ascii
  
   Arend van Spriel ar...@broadcom.com writes:
  
Use the helper to get rid of the file operations per debugfs file. The
device driver data contains struct ieee80211_hw pointer and the
struct ath9k_softc pointer is assigned to ieee80211_hw::priv so it can
be accessed in the seq_file read operation.
   
Cc: ath9k-devel@lists.ath9k.org
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
Hi Kalle,
   
This patch was reverted in the driver-core repository as I overlooked
the use of driver data and caused ath9k driver to crash. I believe this
revised patch properly uses it now although I have no ath9k hardware to
test this. So I hope some ath9k developers out there can give this
 patch
a run for its money. It compiles and no checkpatch or sparse warnings.
   
The patch applies to the master branch of the wireless-drivers-next
repository.
  
   Can someone with ath9k hardware test this, please? I'm hesitant to apply
   this without testing.
  
   --
   Kalle Valo
  
  
   --
  
   Message: 2
   Date: Thu, 8 Jan 2015 08:49:00 +0530
   From: Sujith Manoharan suj...@msujith.org
   Subject: Re: [ath9k-devel] [PATCH] ath: ath9k: use
   debugfs_create_devm_seqfile() helper for seq_file entries
   To: Kalle Valo kv...@codeaurora.org
   Cc: Arend van Spriel ar...@broadcom.com,
   ath9k-devel@lists.ath9k.org, linux-wireless
   linux-wirel...@vger.kernel.org
   Message-ID: 21677.63268.657151.679...@gargle.gargle.howl
   Content-Type: text/plain; charset=us-ascii
  
Arend van Spriel ar...@broadcom.com writes:
   
 Use the helper to get rid of the file operations per debugfs
 file. The
 device driver data contains struct ieee80211_hw pointer and the
 struct ath9k_softc pointer is assigned to ieee80211_hw::priv so
 it can
 be accessed in the seq_file read operation.

 Cc: ath9k-devel@lists.ath9k.org
 Signed-off-by: Arend van Spriel ar...@broadcom.com
  
   Thanks for the patch.
  
Can someone

Re: [ath9k-devel] [PATCH] ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries

2015-01-09 Thread Arend van Spriel 
On 01/09/15 01:34, Sujith Manoharan wrote:
 Arend van Spriel wrote:
 So the content of the modified debugfs files looks sane?

 Yep, as sane as the code populating the debug data. :-)

:-D

Thanks,
Arend

 Sujith

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k-devel Digest, Vol 79, Issue 6

2015-01-09 Thread Arend van Spriel 
On 01/09/15 02:54, 杨铁军 wrote:
 Hi Arend,
 I had ATH9k hardware, my wireless device is WLE350NX, it is AR9580 chip.
 Please send me your code to test!
 I am new to LINUX.

Ok. The patch can be found on patchwork [1]. That page contains download 
links to get the patch. _mbox_ link can be used with 'git am' command. 
_patch_ link can be used with 'patch' command.

Regards,
Arend

[1] https://patchwork.kernel.org/patch/5544621/

 Regards,
 David Yang
 -- Original --
 *From: * ath9k-devel-requestath9k-devel-requ...@lists.ath9k.org;
 *Date: * Thu, Jan 8, 2015 07:00 PM
 *To: * ath9k-develath9k-devel@lists.ath9k.org;
 *Subject: * ath9k-devel Digest, Vol 79, Issue 6
 Send ath9k-devel mailing list submissions to
 ath9k-devel@lists.ath9k.org

 To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel
 or, via email, send a message with subject or body 'help' to
 ath9k-devel-requ...@lists.ath9k.org

 You can reach the person managing the list at
 ath9k-devel-ow...@lists.ath9k.org

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of ath9k-devel digest...


 Today's Topics:

 1. Re: [PATCH] ath: ath9k: use debugfs_create_devm_seqfile()
 helper for seq_file entries (Kalle Valo)
 2. Re: [PATCH] ath: ath9k: use debugfs_create_devm_seqfile()
 helper for seq_file entries (Sujith Manoharan)


 --

 Message: 1
 Date: Wed, 07 Jan 2015 20:05:00 +0200
 From: Kalle Valo kv...@codeaurora.org
 Subject: Re: [ath9k-devel] [PATCH] ath: ath9k: use
 debugfs_create_devm_seqfile() helper for seq_file entries
 To: Arend van Spriel ar...@broadcom.com
 Cc: ath9k-devel@lists.ath9k.org, linux-wireless
 linux-wirel...@vger.kernel.org
 Message-ID: 87bnmapiur@kamboji.qca.qualcomm.com
 Content-Type: text/plain; charset=us-ascii

 Arend van Spriel ar...@broadcom.com writes:

   Use the helper to get rid of the file operations per debugfs file. The
   device driver data contains struct ieee80211_hw pointer and the
   struct ath9k_softc pointer is assigned to ieee80211_hw::priv so it can
   be accessed in the seq_file read operation.
  
   Cc: ath9k-devel@lists.ath9k.org
   Signed-off-by: Arend van Spriel ar...@broadcom.com
   ---
   Hi Kalle,
  
   This patch was reverted in the driver-core repository as I overlooked
   the use of driver data and caused ath9k driver to crash. I believe this
   revised patch properly uses it now although I have no ath9k hardware to
   test this. So I hope some ath9k developers out there can give this patch
   a run for its money. It compiles and no checkpatch or sparse warnings.
  
   The patch applies to the master branch of the wireless-drivers-next
   repository.

 Can someone with ath9k hardware test this, please? I'm hesitant to apply
 this without testing.

 --
 Kalle Valo


 --

 Message: 2
 Date: Thu, 8 Jan 2015 08:49:00 +0530
 From: Sujith Manoharan suj...@msujith.org
 Subject: Re: [ath9k-devel] [PATCH] ath: ath9k: use
 debugfs_create_devm_seqfile() helper for seq_file entries
 To: Kalle Valo kv...@codeaurora.org
 Cc: Arend van Spriel ar...@broadcom.com,
 ath9k-devel@lists.ath9k.org, linux-wireless
 linux-wirel...@vger.kernel.org
 Message-ID: 21677.63268.657151.679...@gargle.gargle.howl
 Content-Type: text/plain; charset=us-ascii

   Arend van Spriel ar...@broadcom.com writes:
  
Use the helper to get rid of the file operations per debugfs file. The
device driver data contains struct ieee80211_hw pointer and the
struct ath9k_softc pointer is assigned to ieee80211_hw::priv so it can
be accessed in the seq_file read operation.
   
Cc: ath9k-devel@lists.ath9k.org
Signed-off-by: Arend van Spriel ar...@broadcom.com

 Thanks for the patch.

   Can someone with ath9k hardware test this, please? I'm hesitant to apply
   this without testing.

 I tested it and there were no crashes.

 Sujith


 --

 ___
 ath9k-devel mailing list
 ath9k-devel@lists.ath9k.org
 https://lists.ath9k.org/mailman/listinfo/ath9k-devel


 End of ath9k-devel Digest, Vol 79, Issue 6
 **

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath9k: ignore radar PHY errors when DFS is not enabled

2015-01-09 Thread Arend van Spriel 
On 01/09/15 17:54, Simon Wunderlich wrote:
 Performing spectral scans on 5 GHz channels may result in PHY errors
 sent by the hardware, even if DFS support is not enabled in the driver
 (e.g. channel scanning or passive monitoring). In that case channels may
 falsely get marked as 'unusable'. To fix that, only process radar PHY
 errors when radar is explicitly enabled in the driver.

Hi Simon,

Not an ath9k expert, but I would think those channels would already be 
marked as unusable, because DFS is disabled in the driver. Or does this 
also affect 5G channels that do not require DFS.

Regards,
Arend

 Cc: Stablesta...@vger.kernel.org  [v3.10+]
 Reported-by: Mathias Kretschmermathias.kretsch...@fokus.fraunhofer.de
 Signed-off-by: Simon Wunderlichs...@simonwunderlich.de
 ---
   drivers/net/wireless/ath/ath9k/dfs.c | 6 ++
   1 file changed, 6 insertions(+)

 diff --git a/drivers/net/wireless/ath/ath9k/dfs.c 
 b/drivers/net/wireless/ath/ath9k/dfs.c
 index 726271c..3d04905 100644
 --- a/drivers/net/wireless/ath/ath9k/dfs.c
 +++ b/drivers/net/wireless/ath/ath9k/dfs.c
 @@ -152,6 +152,12 @@ void ath9k_dfs_process_phyerr(struct ath_softc *sc, void 
 *data,
   return;
   }

 + if (!sc-hw-conf.radar_enabled) {
 + ath_dbg(common, DFS,
 + Error: received radar phyerr while radar was 
 disabled\n);
 + return;
 + }
 +
   datalen = rs-rs_datalen;
   if (datalen == 0) {
   DFS_STAT_INC(sc, datalen_discards);

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries

2015-01-08 Thread Arend van Spriel 
On 01/08/15 04:19, Sujith Manoharan wrote:
 Arend van Sprielar...@broadcom.com  writes:

 Use the helper to get rid of the file operations per debugfs file. The
 device driver data contains struct ieee80211_hw pointer and the
 struct ath9k_softc pointer is assigned to ieee80211_hw::priv so it can
 be accessed in the seq_file read operation.

 Cc: ath9k-devel@lists.ath9k.org
 Signed-off-by: Arend van Sprielar...@broadcom.com

 Thanks for the patch.

 Can someone with ath9k hardware test this, please? I'm hesitant to apply
 this without testing.

 I tested it and there were no crashes.

Thanks, Sujith

So the content of the modified debugfs files looks sane?

Regards,
Arend

 Sujith

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH] ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries

2014-12-27 Thread Arend van Spriel 
Use the helper to get rid of the file operations per debugfs file. The
device driver data contains struct ieee80211_hw pointer and the
struct ath9k_softc pointer is assigned to ieee80211_hw::priv so it can
be accessed in the seq_file read operation.

Cc: ath9k-devel@lists.ath9k.org
Signed-off-by: Arend van Spriel ar...@broadcom.com
---
Hi Kalle,

This patch was reverted in the driver-core repository as I overlooked
the use of driver data and caused ath9k driver to crash. I believe this
revised patch properly uses it now although I have no ath9k hardware to
test this. So I hope some ath9k developers out there can give this patch
a run for its money. It compiles and no checkpatch or sparse warnings.

The patch applies to the master branch of the wireless-drivers-next
repository.

Regards,
Arend
---
 drivers/net/wireless/ath/ath9k/debug.c | 129 -
 1 file changed, 29 insertions(+), 100 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index c43e2ad..1bed9d7 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -403,7 +403,8 @@ static const struct file_operations fops_antenna_diversity 
= {
 
 static int read_file_dma(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ieee80211_hw *hw = dev_get_drvdata(file-private);
+   struct ath_softc *sc = hw-priv;
struct ath_hw *ah = sc-sc_ah;
u32 val[ATH9K_NUM_DMA_DEBUG_REGS];
int i, qcuOffset = 0, dcuOffset = 0;
@@ -470,20 +471,6 @@ static int read_file_dma(struct seq_file *file, void *data)
return 0;
 }
 
-static int open_file_dma(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_dma, inode-i_private);
-}
-
-static const struct file_operations fops_dma = {
-   .open = open_file_dma,
-   .read = seq_read,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
-
 void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status)
 {
if (status)
@@ -539,7 +526,8 @@ void ath_debug_stat_interrupt(struct ath_softc *sc, enum 
ath9k_int status)
 
 static int read_file_interrupt(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ieee80211_hw *hw = dev_get_drvdata(file-private);
+   struct ath_softc *sc = hw-priv;
 
 #define PR_IS(a, s)\
do {\
@@ -600,22 +588,10 @@ static int read_file_interrupt(struct seq_file *file, 
void *data)
return 0;
 }
 
-static int open_file_interrupt(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_interrupt, inode-i_private);
-}
-
-static const struct file_operations fops_interrupt = {
-   .read = seq_read,
-   .open = open_file_interrupt,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
 static int read_file_xmit(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ieee80211_hw *hw = dev_get_drvdata(file-private);
+   struct ath_softc *sc = hw-priv;
 
seq_printf(file, %30s %10s%10s%10s\n\n, BE, BK, VI, VO);
 
@@ -661,7 +637,8 @@ static void print_queue(struct ath_softc *sc, struct 
ath_txq *txq,
 
 static int read_file_queues(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ieee80211_hw *hw = dev_get_drvdata(file-private);
+   struct ath_softc *sc = hw-priv;
struct ath_txq *txq;
int i;
static const char *qname[4] = {
@@ -682,7 +659,8 @@ static int read_file_queues(struct seq_file *file, void 
*data)
 
 static int read_file_misc(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ieee80211_hw *hw = dev_get_drvdata(file-private);
+   struct ath_softc *sc = hw-priv;
struct ath_common *common = ath9k_hw_common(sc-sc_ah);
struct ath9k_vif_iter_data iter_data;
struct ath_chanctx *ctx;
@@ -773,7 +751,8 @@ static int read_file_misc(struct seq_file *file, void *data)
 
 static int read_file_reset(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ieee80211_hw *hw = dev_get_drvdata(file-private);
+   struct ath_softc *sc = hw-priv;
static const char * const reset_cause[__RESET_TYPE_MAX] = {
[RESET_TYPE_BB_HANG] = Baseband Hang,
[RESET_TYPE_BB_WATCHDOG] = Baseband Watchdog,
@@ -837,58 +816,6 @@ void ath_debug_stat_tx(struct ath_softc *sc, struct 
ath_buf *bf,
TX_STAT_INC(qnum, delim_underrun);
 }
 
-static int open_file_xmit(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_xmit, inode-i_private);
-}
-
-static const struct file_operations fops_xmit

Re: [ath9k-devel] [PATCH V2 0/3] debugfs: adding helper for single seq_file

2014-11-21 Thread Arend van Spriel 
On 11/09/14 11:31, Arend van Spriel wrote:
 This series replaces the initial series posted:

 Message-ID:1414498752-9746-1-git-send-email-ar...@broadcom.com

 This series include changes in driver code to investigate potential
 code savings. As example used the ath9k driver as it has a fair
 amount of debugfs files. In this series it changes 7 debugfs entries
 to use seq_file and the helper function. Below the output of the
 size utility:

 text data bss dec hex filename
   115968 1225  28  117221   1c9e5 original/ath9k.o
   113224 1225  28  114477   1bf2d seq_file/ath9k.o
   111024 1225  28  112277   1b695 helper/ath9k.o

 This series is for 3.19 kernel and applies to the driver-core-next
 branch of the driver-core repository.

 The second patch has a number of CamelCase checks, but those were
 already present in code. So fixing that would be a separate effort.

Hi Greg,

These patches did not show up in driver-core repo so did you miss them. 
If I need to rebase again, let me know.

Regards,
Arend

 Changelog:
 --
 V2:
   - fixed whitespace failures.
   - use seq_puts where applicable.
   - rebased on driver-core-next branch.

 Arend van Spriel (3):
debugfs: add helper function to create device related seq_file
ath: use seq_file api for ath9k debugfs files
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
  entries

   drivers/net/wireless/ath/ath9k/ahb.c   |   1 +
   drivers/net/wireless/ath/ath9k/debug.c | 459 
 +++--
   drivers/net/wireless/ath/ath9k/debug.h |  11 +-
   drivers/net/wireless/ath/ath9k/pci.c   |   1 +
   fs/debugfs/file.c  |  54 
   include/linux/debugfs.h|  16 +-
   6 files changed, 226 insertions(+), 316 deletions(-)


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH V2 3/3] ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries

2014-11-09 Thread Arend van Spriel 
Use the helper to get rid of the file operations per debugfs file. The
struct ath9k_softc pointer is set as device driver data to be obtained
in the seq_file read operation.

Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 drivers/net/wireless/ath/ath9k/ahb.c   |   1 +
 drivers/net/wireless/ath/ath9k/debug.c | 122 ++---
 drivers/net/wireless/ath/ath9k/pci.c   |   1 +
 3 files changed, 24 insertions(+), 100 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ahb.c 
b/drivers/net/wireless/ath/ath9k/ahb.c
index e000c4c..750a130 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -126,6 +126,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
sc = hw-priv;
sc-hw = hw;
sc-dev = pdev-dev;
+   dev_set_drvdata(sc-dev, sc);
sc-mem = mem;
sc-irq = irq;
 
diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index e7b709f..a1f1614 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -403,7 +403,7 @@ static const struct file_operations fops_antenna_diversity 
= {
 
 static int read_file_dma(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
struct ath_hw *ah = sc-sc_ah;
u32 val[ATH9K_NUM_DMA_DEBUG_REGS];
int i, qcuOffset = 0, dcuOffset = 0;
@@ -470,20 +470,6 @@ static int read_file_dma(struct seq_file *file, void *data)
return 0;
 }
 
-static int open_file_dma(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_dma, inode-i_private);
-}
-
-static const struct file_operations fops_dma = {
-   .open = open_file_dma,
-   .read = seq_read,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
-
 void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status)
 {
if (status)
@@ -539,7 +525,7 @@ void ath_debug_stat_interrupt(struct ath_softc *sc, enum 
ath9k_int status)
 
 static int read_file_interrupt(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
 
 #define PR_IS(a, s)\
do {\
@@ -600,22 +586,9 @@ static int read_file_interrupt(struct seq_file *file, void 
*data)
return 0;
 }
 
-static int open_file_interrupt(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_interrupt, inode-i_private);
-}
-
-static const struct file_operations fops_interrupt = {
-   .read = seq_read,
-   .open = open_file_interrupt,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
 static int read_file_xmit(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
 
seq_printf(file, %30s %10s%10s%10s\n\n, BE, BK, VI, VO);
 
@@ -661,7 +634,7 @@ static void print_queue(struct ath_softc *sc, struct 
ath_txq *txq,
 
 static int read_file_queues(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
struct ath_txq *txq;
int i;
static const char *qname[4] = {
@@ -682,7 +655,7 @@ static int read_file_queues(struct seq_file *file, void 
*data)
 
 static int read_file_misc(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
struct ath_common *common = ath9k_hw_common(sc-sc_ah);
struct ath9k_vif_iter_data iter_data;
struct ath_chanctx *ctx;
@@ -772,7 +745,7 @@ static int read_file_misc(struct seq_file *file, void *data)
 
 static int read_file_reset(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
 
seq_printf(file, %17s: %2d\n, Baseband Hang,
   sc-debug.stats.reset[RESET_TYPE_BB_HANG]);
@@ -833,58 +806,6 @@ void ath_debug_stat_tx(struct ath_softc *sc, struct 
ath_buf *bf,
TX_STAT_INC(qnum, delim_underrun);
 }
 
-static int open_file_xmit(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_xmit, inode-i_private);
-}
-
-static const struct file_operations fops_xmit = {
-   .read = seq_read,
-   .open = open_file_xmit,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
-static int open_file_queues(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_queues, inode-i_private);
-}
-
-static const struct file_operations fops_queues = {
-   .read = seq_read

[ath9k-devel] [PATCH V2 0/3] debugfs: adding helper for single seq_file

2014-11-09 Thread Arend van Spriel 
This series replaces the initial series posted:

Message-ID: 1414498752-9746-1-git-send-email-ar...@broadcom.com

This series include changes in driver code to investigate potential
code savings. As example used the ath9k driver as it has a fair
amount of debugfs files. In this series it changes 7 debugfs entries
to use seq_file and the helper function. Below the output of the
size utility:

   textdata bss dec hex filename
 1159681225  28  117221   1c9e5 original/ath9k.o
 1132241225  28  114477   1bf2d seq_file/ath9k.o
 1110241225  28  112277   1b695 helper/ath9k.o

This series is for 3.19 kernel and applies to the driver-core-next
branch of the driver-core repository.

The second patch has a number of CamelCase checks, but those were
already present in code. So fixing that would be a separate effort.

Changelog:
--
V2:
 - fixed whitespace failures.
 - use seq_puts where applicable.
 - rebased on driver-core-next branch.

Arend van Spriel (3):
  debugfs: add helper function to create device related seq_file
  ath: use seq_file api for ath9k debugfs files
  ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
entries

 drivers/net/wireless/ath/ath9k/ahb.c   |   1 +
 drivers/net/wireless/ath/ath9k/debug.c | 459 +++--
 drivers/net/wireless/ath/ath9k/debug.h |  11 +-
 drivers/net/wireless/ath/ath9k/pci.c   |   1 +
 fs/debugfs/file.c  |  54 
 include/linux/debugfs.h|  16 +-
 6 files changed, 226 insertions(+), 316 deletions(-)

-- 
1.9.1

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH V2 1/3] debugfs: add helper function to create device related seq_file

2014-11-09 Thread Arend van Spriel 
This patch adds a helper function that simplifies adding a
so-called single_open sequence file for device drivers. The
calling device driver needs to provide a read function and
a device pointer. The field struct seq_file::private will
reference the device pointer upon call to the read function
so the driver can obtain his data from it and do its task
of providing the file content using seq_printf() calls and
alike. Using this helper function also gets rid of the need
to specify file operations per debugfs file.

Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 fs/debugfs/file.c   | 54 +
 include/linux/debugfs.h | 16 ++-
 2 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 76c08c2..a2f8ec7 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -22,6 +22,7 @@
 #include linux/io.h
 #include linux/slab.h
 #include linux/atomic.h
+#include linux/device.h
 
 static ssize_t default_read_file(struct file *file, char __user *buf,
 size_t count, loff_t *ppos)
@@ -761,3 +762,56 @@ struct dentry *debugfs_create_regset32(const char *name, 
umode_t mode,
 EXPORT_SYMBOL_GPL(debugfs_create_regset32);
 
 #endif /* CONFIG_HAS_IOMEM */
+
+struct debugfs_devm_entry {
+   int (*read)(struct seq_file *seq, void *data);
+   struct device *dev;
+};
+
+static int debugfs_devm_entry_open(struct inode *inode, struct file *f)
+{
+   struct debugfs_devm_entry *entry = inode-i_private;
+
+   return single_open(f, entry-read, entry-dev);
+}
+
+static const struct file_operations debugfs_devm_entry_ops = {
+   .owner = THIS_MODULE,
+   .open = debugfs_devm_entry_open,
+   .release = single_release,
+   .read = seq_read,
+   .llseek = seq_lseek
+};
+
+/**
+ * debugfs_create_devm_seqfile - create a debugfs file that is bound to device.
+ *
+ * @dev: device related to this debugfs file.
+ * @name: name of the debugfs file.
+ * @parent: a pointer to the parent dentry for this file.  This should be a
+ * directory dentry if set.  If this parameter is %NULL, then the
+ * file will be created in the root of the debugfs filesystem.
+ * @read_fn: function pointer called to print the seq_file content.
+ */
+struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char 
*name,
+  struct dentry *parent,
+  int (*read_fn)(struct seq_file *s,
+ void *data))
+{
+   struct debugfs_devm_entry *entry;
+
+   if (IS_ERR(parent))
+   return ERR_PTR(-ENOENT);
+
+   entry = devm_kzalloc(dev, sizeof(*entry), GFP_KERNEL);
+   if (!entry)
+   return ERR_PTR(-ENOMEM);
+
+   entry-read = read_fn;
+   entry-dev = dev;
+
+   return debugfs_create_file(name, S_IRUGO, parent, entry,
+  debugfs_devm_entry_ops);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_devm_seqfile);
+
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 4d0b4d1..4bbe2ac 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -99,13 +99,18 @@ struct dentry *debugfs_create_u32_array(const char *name, 
umode_t mode,
struct dentry *parent,
u32 *array, u32 elements);
 
+struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char 
*name,
+  struct dentry *parent,
+  int (*read_fn)(struct seq_file *s,
+ void *data));
+
 bool debugfs_initialized(void);
 
 #else
 
 #include linux/err.h
 
-/* 
+/*
  * We do not return NULL from these functions if CONFIG_DEBUG_FS is not enabled
  * so users have a chance to detect if there was a real error or not.  We don't
  * want to duplicate the design decision mistakes of procfs and devfs again.
@@ -251,6 +256,15 @@ static inline struct dentry 
*debugfs_create_u32_array(const char *name, umode_t
return ERR_PTR(-ENODEV);
 }
 
+static inline struct dentry *debugfs_create_devm_seqfile(struct device *dev,
+const char *name,
+struct dentry *parent,
+  int (*read_fn)(struct seq_file *s,
+ void *data))
+{
+   return ERR_PTR(-ENODEV);
+}
+
 #endif
 
 #endif
-- 
1.9.1

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH V2 2/3] ath: use seq_file api for ath9k debugfs files

2014-11-09 Thread Arend van Spriel 
The debugfs files that are defined in debug.c which are read-only
and using a simple_open as .open file operation have been modified
to use the single_open seq_file API. This simplifies the read
functions defining the file contents.

Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 drivers/net/wireless/ath/ath9k/debug.c | 455 ++---
 drivers/net/wireless/ath/ath9k/debug.h |  11 +-
 2 files changed, 192 insertions(+), 274 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 5c45e78..e7b709f 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -401,22 +401,14 @@ static const struct file_operations 
fops_antenna_diversity = {
.llseek = default_llseek,
 };
 
-static ssize_t read_file_dma(struct file *file, char __user *user_buf,
-size_t count, loff_t *ppos)
+static int read_file_dma(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private_data;
+   struct ath_softc *sc = file-private;
struct ath_hw *ah = sc-sc_ah;
-   char *buf;
-   int retval;
-   unsigned int len = 0;
u32 val[ATH9K_NUM_DMA_DEBUG_REGS];
int i, qcuOffset = 0, dcuOffset = 0;
u32 *qcuBase = val[0], *dcuBase = val[4];
 
-   buf = kmalloc(DMA_BUF_LEN, GFP_KERNEL);
-   if (!buf)
-   return -ENOMEM;
-
ath9k_ps_wakeup(sc);
 
REG_WRITE_D(ah, AR_MACMISC,
@@ -424,21 +416,18 @@ static ssize_t read_file_dma(struct file *file, char 
__user *user_buf,
   (AR_MACMISC_MISC_OBS_BUS_1 
AR_MACMISC_MISC_OBS_BUS_MSB_S)));
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-Raw DMA Debug values:\n);
+   seq_puts(file, Raw DMA Debug values:\n);
 
for (i = 0; i  ATH9K_NUM_DMA_DEBUG_REGS; i++) {
if (i % 4 == 0)
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, \n);
+   seq_puts(file, \n);
 
val[i] = REG_READ_D(ah, AR_DMADBG_0 + (i * sizeof(u32)));
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, %d: %08x ,
-i, val[i]);
+   seq_printf(file, %d: %08x , i, val[i]);
}
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, \n\n);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-Num QCU: chain_st fsp_ok fsp_st DCU: chain_st\n);
+   seq_puts(file, \n\n);
+   seq_puts(file, Num QCU: chain_st fsp_ok fsp_st DCU: chain_st\n);
 
for (i = 0; i  ATH9K_NUM_QUEUES; i++, qcuOffset += 4, dcuOffset += 5) {
if (i == 8) {
@@ -451,55 +440,47 @@ static ssize_t read_file_dma(struct file *file, char 
__user *user_buf,
dcuBase++;
}
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-%2d  %2x  %1x %2x   %2x\n,
-i, (*qcuBase  (0x7  qcuOffset))  qcuOffset,
-(*qcuBase  (0x8  qcuOffset))  (qcuOffset + 3),
-(val[2]  (0x7  (i * 3)))  (i * 3),
-(*dcuBase  (0x1f  dcuOffset))  dcuOffset);
+   seq_printf(file, %2d  %2x  %1x %2x   
%2x\n,
+  i, (*qcuBase  (0x7  qcuOffset))  qcuOffset,
+  (*qcuBase  (0x8  qcuOffset))  (qcuOffset + 3),
+  (val[2]  (0x7  (i * 3)))  (i * 3),
+  (*dcuBase  (0x1f  dcuOffset))  dcuOffset);
}
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, \n);
-
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   qcu_stitch state:   %2xqcu_fetch state:%2x\n,
-   (val[3]  0x003c)  18, (val[3]  0x03c0)  22);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   qcu_complete state: %2xdcu_complete state: %2x\n,
-   (val[3]  0x1c00)  26, (val[6]  0x3));
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   dcu_arb state:  %2xdcu_fp state:   %2x\n,
-   (val[5]  0x0600)  25, (val[5]  0x3800)  27);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   chan_idle_dur: %3dchan_idle_dur_valid: %1d\n,
-   (val[6]  0x03fc)  2, (val[6]  0x0400)  10);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   txfifo_valid_0:  %1dtxfifo_valid_1:  %1d\n,
-   (val[6]  0x0800)  11, (val[6]  0x1000)  12);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   txfifo_dcu_num_0:   %2dtxfifo_dcu_num_1:   %2d\n,
-   (val[6]  0x0001e000)  13, (val[6]  0x001e)  17);
-
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, pcu observe: 0x%x\n

Re: [ath9k-devel] [PATCH 2/3] ath: use seq_file api for ath9k debugfs files

2014-11-08 Thread Arend van Spriel 
On 11/07/14 20:05, Greg Kroah-Hartman wrote:
 On Tue, Oct 28, 2014 at 01:19:11PM +0100, Arend van Spriel wrote:
 The debugfs files that are defined in debug.c which are read-only
 and using a simple_open as .open file operation have been modified
 to use the single_open seq_file API. This simplifies the read
 functions defining the file contents.

 Signed-off-by: Arend van Sprielar...@broadcom.com
 Acked-by: John W. Linvillelinvi...@tuxdriver.com
 ---
   drivers/net/wireless/ath/ath9k/debug.c | 425 
 +
   drivers/net/wireless/ath/ath9k/debug.h |   3 +-
   2 files changed, 173 insertions(+), 255 deletions(-)

 I can't take patch 1/3 right now, but even if I could, this one doesn't
 apply to 3.18-rc3 :(

Yep, I noticed some patches going in hitting the same area. As patch 1 
needs rework I will rebase all.

Thanks,
Arend
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 2/3] ath: use seq_file api for ath9k debugfs files

2014-11-08 Thread Arend van Spriel 
On 11/08/14 14:44, Arend van Spriel wrote:
 On 11/07/14 20:05, Greg Kroah-Hartman wrote:
 On Tue, Oct 28, 2014 at 01:19:11PM +0100, Arend van Spriel wrote:
 The debugfs files that are defined in debug.c which are read-only
 and using a simple_open as .open file operation have been modified
 to use the single_open seq_file API. This simplifies the read
 functions defining the file contents.

 Signed-off-by: Arend van Sprielar...@broadcom.com
 Acked-by: John W. Linvillelinvi...@tuxdriver.com
 ---
 drivers/net/wireless/ath/ath9k/debug.c | 425
 +
 drivers/net/wireless/ath/ath9k/debug.h | 3 +-
 2 files changed, 173 insertions(+), 255 deletions(-)

 I can't take patch 1/3 right now, but even if I could, this one doesn't
 apply to 3.18-rc3 :(

driver-core/driver-core-next branch is not on 3.18-rc3. Should I rebase 
the series on driver-core/master? As this is for 3.19 I figured it 
needed to go on some -next branch.

Regards,
Arend

 Yep, I noticed some patches going in hitting the same area. As patch 1
 needs rework I will rebase all.

 Thanks,
 Arend
 --
 To unsubscribe from this list: send the line unsubscribe
 linux-wireless in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at http://vger.kernel.org/majordomo-info.html

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 0/3] debugfs: adding helper for single seq_file

2014-10-30 Thread Arend van Spriel 
On 10/30/14 20:39, Greg Kroah-Hartman wrote:
 On Thu, Oct 30, 2014 at 03:19:22PM -0400, John W. Linville wrote:
 On Tue, Oct 28, 2014 at 01:19:09PM +0100, Arend van Spriel wrote:
 The first patch was already posted earlier:

 Message-ID:1413043315-22332-1-git-send-email-ar...@broadcom.com

 This series include changes in driver code to investigate potential
 code savings. As example used the ath9k driver as it has a fair
 amount of debugfs files. In this series it changes 7 debugfs entries
 to use seq_file and the helper function. Below the output of the
 size utility:

 text   data bss dec hex filename
   115968   1225  28  117221   1c9e5 original/ath9k.o
   113224   1225  28  114477   1bf2d seq_file/ath9k.o
   111024   1225  28  112277   1b695 helper/ath9k.o

 This series is for 3.19 kernel and applies to the driver-core-next
 branch of the driver-core repository. If needed the ath9k patches
 may be dropped for now and I will resubmit them to wireless-next
 once the debugfs patch has made it into linux-next.

 Arend van Spriel (3):
debugfs: add helper function to create device related seq_file
ath: use seq_file api for ath9k debugfs files
ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
  entries

 Greg,

 If you are happy with the debugfs change then feel free to merge the
 wireless patches along with it.

 Ok, will do, can I get your Ack for them?

I saw a patch from Dan Carpenter on one of the functions I converted so 
if John has taken that one [1] it may give merge conflict in linux-next.

Regards,
Arend

[1] http://mid.gmane.org/20141029154805.GC5290@mwanda
 thanks,

 greg k-h

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH 2/3] ath: use seq_file api for ath9k debugfs files

2014-10-28 Thread Arend van Spriel 
The debugfs files that are defined in debug.c which are read-only
and using a simple_open as .open file operation have been modified
to use the single_open seq_file API. This simplifies the read
functions defining the file contents.

Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 drivers/net/wireless/ath/ath9k/debug.c | 425 +
 drivers/net/wireless/ath/ath9k/debug.h |   3 +-
 2 files changed, 173 insertions(+), 255 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 46f20a3..1d6bfda 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -401,22 +401,14 @@ static const struct file_operations 
fops_antenna_diversity = {
.llseek = default_llseek,
 };
 
-static ssize_t read_file_dma(struct file *file, char __user *user_buf,
-size_t count, loff_t *ppos)
+static int read_file_dma(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private_data;
+   struct ath_softc *sc = file-private;
struct ath_hw *ah = sc-sc_ah;
-   char *buf;
-   int retval;
-   unsigned int len = 0;
u32 val[ATH9K_NUM_DMA_DEBUG_REGS];
int i, qcuOffset = 0, dcuOffset = 0;
u32 *qcuBase = val[0], *dcuBase = val[4];
 
-   buf = kmalloc(DMA_BUF_LEN, GFP_KERNEL);
-   if (!buf)
-   return -ENOMEM;
-
ath9k_ps_wakeup(sc);
 
REG_WRITE_D(ah, AR_MACMISC,
@@ -424,21 +416,18 @@ static ssize_t read_file_dma(struct file *file, char 
__user *user_buf,
   (AR_MACMISC_MISC_OBS_BUS_1 
AR_MACMISC_MISC_OBS_BUS_MSB_S)));
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-Raw DMA Debug values:\n);
+   seq_printf(file, Raw DMA Debug values:\n);
 
for (i = 0; i  ATH9K_NUM_DMA_DEBUG_REGS; i++) {
if (i % 4 == 0)
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, \n);
+   seq_printf(file, \n);
 
val[i] = REG_READ_D(ah, AR_DMADBG_0 + (i * sizeof(u32)));
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, %d: %08x ,
-i, val[i]);
+   seq_printf(file, %d: %08x , i, val[i]);
}
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, \n\n);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-Num QCU: chain_st fsp_ok fsp_st DCU: chain_st\n);
+   seq_printf(file, \n\n);
+   seq_printf(file, Num QCU: chain_st fsp_ok fsp_st DCU: chain_st\n);
 
for (i = 0; i  ATH9K_NUM_QUEUES; i++, qcuOffset += 4, dcuOffset += 5) {
if (i == 8) {
@@ -451,55 +440,47 @@ static ssize_t read_file_dma(struct file *file, char 
__user *user_buf,
dcuBase++;
}
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-%2d  %2x  %1x %2x   %2x\n,
+   seq_printf(file, %2d  %2x  %1x %2x   
%2x\n,
 i, (*qcuBase  (0x7  qcuOffset))  qcuOffset,
 (*qcuBase  (0x8  qcuOffset))  (qcuOffset + 3),
 val[2]  (0x7  (i * 3))  (i * 3),
 (*dcuBase  (0x1f  dcuOffset))  dcuOffset);
}
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len, \n);
+   seq_printf(file, \n);
 
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   qcu_stitch state:   %2xqcu_fetch state:%2x\n,
+   seq_printf(file, qcu_stitch state:   %2xqcu_fetch state:
%2x\n,
(val[3]  0x003c)  18, (val[3]  0x03c0)  22);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   qcu_complete state: %2xdcu_complete state: %2x\n,
+   seq_printf(file, qcu_complete state: %2xdcu_complete state: 
%2x\n,
(val[3]  0x1c00)  26, (val[6]  0x3));
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   dcu_arb state:  %2xdcu_fp state:   %2x\n,
+   seq_printf(file, dcu_arb state:  %2xdcu_fp state:   
%2x\n,
(val[5]  0x0600)  25, (val[5]  0x3800)  27);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   chan_idle_dur: %3dchan_idle_dur_valid: %1d\n,
+   seq_printf(file, chan_idle_dur: %3dchan_idle_dur_valid: 
%1d\n,
(val[6]  0x03fc)  2, (val[6]  0x0400)  10);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   txfifo_valid_0:  %1dtxfifo_valid_1:  %1d\n,
+   seq_printf(file, txfifo_valid_0:  %1dtxfifo_valid_1:  
%1d\n,
(val[6]  0x0800)  11, (val[6]  0x1000)  12);
-   len += scnprintf(buf + len, DMA_BUF_LEN - len,
-   txfifo_dcu_num_0:   %2d

[ath9k-devel] [PATCH 3/3] ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file entries

2014-10-28 Thread Arend van Spriel 
Use the helper to get rid of the file operations per debugfs file. The
struct ath9k_softc pointer is set as device driver data to be obtained
in the seq_file read operation.

Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 drivers/net/wireless/ath/ath9k/ahb.c   |   1 +
 drivers/net/wireless/ath/ath9k/debug.c | 122 ++---
 drivers/net/wireless/ath/ath9k/pci.c   |   1 +
 3 files changed, 24 insertions(+), 100 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ahb.c 
b/drivers/net/wireless/ath/ath9k/ahb.c
index 4173838..74b009b 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -126,6 +126,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
sc = hw-priv;
sc-hw = hw;
sc-dev = pdev-dev;
+   dev_set_drvdata(sc-dev, sc);
sc-mem = mem;
sc-irq = irq;
 
diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 1d6bfda..62d8a09 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -403,7 +403,7 @@ static const struct file_operations fops_antenna_diversity 
= {
 
 static int read_file_dma(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
struct ath_hw *ah = sc-sc_ah;
u32 val[ATH9K_NUM_DMA_DEBUG_REGS];
int i, qcuOffset = 0, dcuOffset = 0;
@@ -470,20 +470,6 @@ static int read_file_dma(struct seq_file *file, void *data)
return 0;
 }
 
-static int open_file_dma(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_dma, inode-i_private);
-}
-
-static const struct file_operations fops_dma = {
-   .open = open_file_dma,
-   .read = seq_read,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
-
 void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status)
 {
if (status)
@@ -539,7 +525,7 @@ void ath_debug_stat_interrupt(struct ath_softc *sc, enum 
ath9k_int status)
 
 static int read_file_interrupt(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
 
 #define PR_IS(a, s)\
do {\
@@ -600,22 +586,9 @@ static int read_file_interrupt(struct seq_file *file, void 
*data)
return 0;
 }
 
-static int open_file_interrupt(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_interrupt, inode-i_private);
-}
-
-static const struct file_operations fops_interrupt = {
-   .read = seq_read,
-   .open = open_file_interrupt,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
 static int read_file_xmit(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
 
seq_printf(file, %30s %10s%10s%10s\n\n, BE, BK, VI, VO);
 
@@ -661,7 +634,7 @@ static void print_queue(struct ath_softc *sc, struct 
ath_txq *txq,
 
 static int read_file_queues(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
struct ath_txq *txq;
int i;
static const char *qname[4] = {
@@ -682,7 +655,7 @@ static int read_file_queues(struct seq_file *file, void 
*data)
 
 static int read_file_misc(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
struct ath_common *common = ath9k_hw_common(sc-sc_ah);
struct ath9k_vif_iter_data iter_data;
struct ath_chanctx *ctx;
@@ -772,7 +745,7 @@ static int read_file_misc(struct seq_file *file, void *data)
 
 static int read_file_reset(struct seq_file *file, void *data)
 {
-   struct ath_softc *sc = file-private;
+   struct ath_softc *sc = dev_get_drvdata(file-private);
 
seq_printf(file, %17s: %2d\n, Baseband Hang,
   sc-debug.stats.reset[RESET_TYPE_BB_HANG]);
@@ -833,58 +806,6 @@ void ath_debug_stat_tx(struct ath_softc *sc, struct 
ath_buf *bf,
TX_STAT_INC(qnum, delim_underrun);
 }
 
-static int open_file_xmit(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_xmit, inode-i_private);
-}
-
-static const struct file_operations fops_xmit = {
-   .read = seq_read,
-   .open = open_file_xmit,
-   .owner = THIS_MODULE,
-   .llseek = seq_lseek,
-   .release = single_release,
-};
-
-static int open_file_queues(struct inode *inode, struct file *f)
-{
-   return single_open(f, read_file_queues, inode-i_private);
-}
-
-static const struct file_operations fops_queues = {
-   .read = seq_read

[ath9k-devel] [PATCH 0/3] debugfs: adding helper for single seq_file

2014-10-28 Thread Arend van Spriel 
The first patch was already posted earlier:

Message-ID: 1413043315-22332-1-git-send-email-ar...@broadcom.com

This series include changes in driver code to investigate potential
code savings. As example used the ath9k driver as it has a fair
amount of debugfs files. In this series it changes 7 debugfs entries
to use seq_file and the helper function. Below the output of the
size utility:

   textdata bss dec hex filename
 1159681225  28  117221   1c9e5 original/ath9k.o
 1132241225  28  114477   1bf2d seq_file/ath9k.o
 1110241225  28  112277   1b695 helper/ath9k.o

This series is for 3.19 kernel and applies to the driver-core-next
branch of the driver-core repository. If needed the ath9k patches
may be dropped for now and I will resubmit them to wireless-next
once the debugfs patch has made it into linux-next.

Arend van Spriel (3):
  debugfs: add helper function to create device related seq_file
  ath: use seq_file api for ath9k debugfs files
  ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
entries

 drivers/net/wireless/ath/ath9k/ahb.c   |   1 +
 drivers/net/wireless/ath/ath9k/debug.c | 429 +++--
 drivers/net/wireless/ath/ath9k/debug.h |   3 +-
 drivers/net/wireless/ath/ath9k/pci.c   |   1 +
 fs/debugfs/file.c  |  54 +
 include/linux/debugfs.h|  16 +-
 6 files changed, 207 insertions(+), 297 deletions(-)

-- 
1.9.1

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [PATCH 1/3] debugfs: add helper function to create device related seq_file

2014-10-28 Thread Arend van Spriel 
This patch adds a helper function that simplifies adding a
so-called single_open sequence file for device drivers. The
calling device driver needs to provide a read function and
a device pointer. The field struct seq_file::private will
reference the device pointer upon call to the read function
so the driver can obtain his data from it and do its task
of providing the file content using seq_printf() calls and
alike. Using this helper function also gets rid of the need
to specify file operations per debugfs file.

Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 fs/debugfs/file.c   | 54 +
 include/linux/debugfs.h | 16 ++-
 2 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 76c08c2..088b3fc 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -22,6 +22,7 @@
 #include linux/io.h
 #include linux/slab.h
 #include linux/atomic.h
+#include linux/device.h
 
 static ssize_t default_read_file(struct file *file, char __user *buf,
 size_t count, loff_t *ppos)
@@ -761,3 +762,56 @@ struct dentry *debugfs_create_regset32(const char *name, 
umode_t mode,
 EXPORT_SYMBOL_GPL(debugfs_create_regset32);
 
 #endif /* CONFIG_HAS_IOMEM */
+
+struct debugfs_devm_entry {
+   int (*read)(struct seq_file *seq, void *data);
+   struct device *dev;
+};
+
+static int debugfs_devm_entry_open(struct inode *inode, struct file *f)
+{
+   struct debugfs_devm_entry *entry = inode-i_private;
+
+   return single_open(f, entry-read, entry-dev);
+}
+
+static const struct file_operations debugfs_devm_entry_ops = {
+   .owner = THIS_MODULE,
+   .open = debugfs_devm_entry_open,
+   .release = single_release,
+   .read = seq_read,
+   .llseek = seq_lseek
+};
+
+/**
+ * debugfs_create_devm_seqfile - create a debugfs file that is bound to device.
+ *
+ * @dev: device related to this debugfs file.
+ * @name: name of the debugfs file.
+ * @parent: a pointer to the parent dentry for this file.  This should be a
+ * directory dentry if set.  If this parameter is %NULL, then the
+ * file will be created in the root of the debugfs filesystem.
+ * @read_fn: function pointer called to print the seq_file content.
+ */
+struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char 
*name,
+  struct dentry *parent,
+  int (*read_fn)(struct seq_file *s,
+ void *data))
+{
+   struct debugfs_devm_entry *entry;
+
+   if (IS_ERR(parent))
+   return ERR_PTR(-ENOENT);
+
+   entry = devm_kzalloc(dev, sizeof(*entry), GFP_KERNEL);
+   if (!entry)
+   return ERR_PTR(-ENOMEM);
+
+   entry-read = read_fn;
+   entry-dev = dev;
+
+   return debugfs_create_file(name, S_IRUGO, parent, entry,
+  debugfs_devm_entry_ops);
+}
+EXPORT_SYMBOL_GPL(debugfs_create_devm_seqfile);
+
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 4d0b4d1..f8c0db4 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -99,13 +99,18 @@ struct dentry *debugfs_create_u32_array(const char *name, 
umode_t mode,
struct dentry *parent,
u32 *array, u32 elements);
 
+struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char 
*name,
+  struct dentry *parent,
+  int (*read_fn)(struct seq_file *s,
+ void *data));
+
 bool debugfs_initialized(void);
 
 #else
 
 #include linux/err.h
 
-/* 
+/*
  * We do not return NULL from these functions if CONFIG_DEBUG_FS is not enabled
  * so users have a chance to detect if there was a real error or not.  We don't
  * want to duplicate the design decision mistakes of procfs and devfs again.
@@ -251,6 +256,15 @@ static inline struct dentry 
*debugfs_create_u32_array(const char *name, umode_t
return ERR_PTR(-ENODEV);
 }
 
+static inline struct dentry *debugfs_create_devm_seqfile(struct device *dev,
+const char *name,
+struct dentry *parent,
+  int (*read_fn)(struct seq_file *s,
+ void *data))
+{
+   return ERR_PTR(-ENODEV);
+}
+
 #endif
 
 #endif
-- 
1.9.1

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] ath9k Driver crash

2013-10-23 Thread Arend van Spriel 
+ ath9k-devel@lists.ath9k.org
+ backpo...@vger.kernel.org

On 10/23/2013 02:22 PM, Singh, Gaurav wrote:
 Hi,

 Setup info:

 Linux: mips le, 2.6.29 on ViXS XC4200 SoC
 Ath9k from compat-wireless-3.6.8-1-snpc
 wpa_supplicant 2.0

 Only using wpa_supplicant, no network-manager etc.

 I see a system reboot after following (or similar) (formatted) logs:

 [Tue Oct 22 19:03:39.828 2013] Debug: Monitor Message :  
 3CTRL-EVENT-BSS-ADDED 89 08:cc:68:5e:d7:41
 [Tue Oct 22 19:03:39.829 2013] Debug: Monitor Message :  
 3CTRL-EVENT-SCAN-RESULTS
 [Tue Oct 22 19:03:39.865 2013] Debug: Monitor Message :  
 3WPS-AP-AVAILABLE-PBC
 [Tue Oct 22 19:03:39.871 2013] Debug: Monitor Message :  3SME: Trying to 
 authenticate with 00:23:69:3b:77:9a (SSID='STB Lease Line 1' freq=2422 MHz)
 [Tue Oct 22 19:03:39.872 2013] Debug: Monitor Message :  3Trying to 
 associate with 00:23:69:3b:77:9a (SSID='STB Lease Line 1' freq=2422 MHz)
 [Tue Oct 22 19:03:40.740 2013] irq 7: nobody cared (try booting with the 
 irqpoll option)
 [Tue Oct 22 19:03:40.746 2013] MIPS5_INTERRUPT 0x
 [Tue Oct 22 19:03:40.756 2013] MIPS5_INTERRUPT1 0x0004
 [Tue Oct 22 19:03:40.764 2013] PPC_INT_STATUS 0x0100 MASK 0x063000c2
 [Tue Oct 22 19:03:40.764 2013]
 [Tue Oct 22 19:03:40.764 2013] Call Trace:
 [Tue Oct 22 19:03:40.764 2013] [900484e4] dump_stack+0x8/0x34
 [Tue Oct 22 19:03:40.772 2013] [9009af9c] __report_bad_irq+0xb4/0x158
 [Tue Oct 22 19:03:40.773 2013] [9009b1b4] note_interrupt+0x174/0x23c
 [Tue Oct 22 19:03:40.773 2013] [9009b934] handle_percpu_irq+0xa8/0xcc
 [Tue Oct 22 19:03:40.800 2013] [9004b488] xcode_ic_dispatch_pci+0x30/0x40
 [Tue Oct 22 19:03:40.801 2013] [9004002c] ret_from_irq+0x0/0x4
 [Tue Oct 22 19:03:40.832 2013] [90072ec0] __do_softirq+0x60/0x130
 [Tue Oct 22 19:03:40.832 2013] [90072ffc] do_softirq+0x6c/0x74
 [Tue Oct 22 19:03:40.832 2013] [9004002c] ret_from_irq+0x0/0x4
 [Tue Oct 22 19:03:40.832 2013] [90069de8] finish_task_switch+0xc0/0x178
 [Tue Oct 22 19:03:40.833 2013] [90048dcc] schedule+0x300/0x440
 [Tue Oct 22 19:03:40.833 2013] [9009125c] futex_wait+0x43c/0x4a4
 [Tue Oct 22 19:03:40.833 2013] [9009284c] do_futex+0x120/0x9c8
 [Tue Oct 22 19:03:40.833 2013] [90093180] sys_futex+0x8c/0x17c
 [Tue Oct 22 19:03:40.833 2013] [90041d04] stack_done+0x20/0x3c
 [Tue Oct 22 19:03:40.861 2013]
 [Tue Oct 22 19:03:40.861 2013] handlers:
 [Tue Oct 22 19:03:40.861 2013] [c6b8ff74] (ath_isr+0x0/0x2d0 [ath9k])
 [Tue Oct 22 19:03:40.861 2013] Disabling IRQ #7
 [Tue Oct 22 19:03:43.278 2013]

 Sometimes, a bunch of similar blocks of logs print together.

 I am not sure what's causing this. *Any* pointers would be helpful.

 I am no expert in wireless tech, but am tasked with implementing basic wifi 
 feature-set  for the product.

I suspect the ath_isr is not returning a good value to the kernel 
interrupt framework, but it might be a backports/compat issue.

 Thanks and Regards
 -Gaurav

 ___
 HostAP mailing list
 hos...@lists.shmoo.com
 http://lists.shmoo.com/mailman/listinfo/hostap



___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Supported Wi-Fi direct of Android?

2013-06-20 Thread Arend van Spriel 
On 06/20/2013 02:44 PM, Check Zhao wrote:
 Hi list,

 I want to enable concurrently the wlan0 and p2p0 interface with the usb
 wifi dongle on PCs,
 It is similar to the Wi-Fi direct of Android-4.2.2(Samsung Galaxy Nexus).

 I found out Galaxy Nexus Wi-Fi chip is Broadcom BCM4330, but I can't buy
 a usb dongle used this chip, however I can buy TP-LINK TL-WN722N with
 using ar9271( ath9k_htc driver).

 Now I want to know if ath9k_htc driver support to enable concurrently
 the wlan0 and p2p0 interface, and how to support this functionality with
 coding.

 Please help!

 From the code:

static const struct ieee80211_iface_limit if_limits[] = {
{ .max = 2, .types = BIT(NL80211_IFTYPE_STATION) |
 BIT(NL80211_IFTYPE_P2P_CLIENT) },
{ .max = 2, .types = BIT(NL80211_IFTYPE_AP) |
 BIT(NL80211_IFTYPE_P2P_GO) },
};

static const struct ieee80211_iface_combination if_comb = {
.limits = if_limits,
.n_limits = ARRAY_SIZE(if_limits),
.max_interfaces = 2,
.num_different_channels = 1,
};

It has P2P support, but it is a mac80211 driver and it may need 
P2P_DEVICE support as well. Johannes?

Regards,
Arend

 Some reference information:

 /http://readlist.com/lists/shmoo.com/hostap/3/15004.html/

 --
 / To me it seem YanBo is working with a mac80211 driver and asking how to
 tell mac80211 it can support multiple (concurrent) interfaces.

 Same like for cfg80211, advertise interface combinations? And if you
 advertise a combination with P2P_DEVICE then wpa_s (with these patches)
 will pick it up and create one.

 johannes/
 ---

 Best Regards,

 Chengyi



___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes

2013-02-13 Thread Arend van Spriel 
On 02/13/2013 06:04 PM, Seth Forshee wrote:
 Is all this really worth it? It seems a quick fix for brcmsmac might be
  to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is
  enabled in the config, and then go implement a real solution like I
  described earlier with powersave being separated out of the core
  mac80211 routines, and actually made possible for multiple interfaces?
 Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable
 PS is sent the flag won't be set, as we're still on the operating
 channel. When we're actually off-channel the value of PM doesn't matter
 for the types of frames which are being sent. The only quick fix I've
 found is to watch out for frames with PM set and set the powersave bit
 while they're being transmitted.

I actually don't see that one fly. The frames are posted on a DMA fifo
towards the hardware so in the driver we have no clue when that frame is
being processes/transmitted hence no way of knowing when to write the
register(s).

Gr. AvS

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 1/4] mac80211: Convert PS configuration from a binary flag to a set of modes

2013-02-13 Thread Arend van Spriel 
On 02/13/2013 08:25 PM, Seth Forshee wrote:
 On Wed, Feb 13, 2013 at 07:54:19PM +0100, Arend van Spriel wrote:
 On 02/13/2013 06:04 PM, Seth Forshee wrote:
 Is all this really worth it? It seems a quick fix for brcmsmac might be
 to always set the powersave bit when IEEE80211_CONF_OFFCHANNEL is
 enabled in the config, and then go implement a real solution like I
 described earlier with powersave being separated out of the core
 mac80211 routines, and actually made possible for multiple interfaces?
 Using IEEE80211_CONF_OFFCHANNEL won't work. When the nullfunc to enable
 PS is sent the flag won't be set, as we're still on the operating
 channel. When we're actually off-channel the value of PM doesn't matter
 for the types of frames which are being sent. The only quick fix I've
 found is to watch out for frames with PM set and set the powersave bit
 while they're being transmitted.

 I actually don't see that one fly. The frames are posted on a DMA fifo
 towards the hardware so in the driver we have no clue when that frame is
 being processes/transmitted hence no way of knowing when to write the
 register(s).
 
 There's a couple of ways of doing it. I had a working patch at one point
 but can't seem to find it now, so I'm not sure which way I used. You're
 right though that we can't tell when the hardware is actually processing
 or transmitting the frame, so in either case MCTL_HPS has to be set
 before you put the frame in the tx fifo.
 
 The first option is that for any frame with PM set, set MCTL_HPS when
 mac80211 hands off the frame and clear it once it has finished
 transmitting.
 
 The second option is to look specifically for nullfunc frames and set or
 clear MCTL_HPS based on the value of PM.
 
 Either of these should work fine with the current mac80211 code, but
 overall the second one is probably a little safer.

So you have verified that the last packet mac80211 sends before going
off-channel is the nullfunc frame with PM bit set. I have seen packets
coming in our driver during the .flush() callback, but never checked
whether the last of those packets is indeed the nullfunc.

Gr. AvS


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Wifi basics documents

2013-02-08 Thread Arend van Spriel 
On 02/08/2013 07:55 AM, Onteddu Slreddy wrote:
 Hello All,
 
 
 I recently joined this group the group.
 
 Can anybody suggest me places where I can get Documents which will explain
 wifi  Architecture in brief i would like to know details like
 
 In Linux for embedded systems:
 What is the software architecture for wifi
 What are each folders in kernel/net and kernel/drivers/net refer to
 What is wpa_supplicant how to know which version I have to use
 How to get  familiar with words like nl802.11, mac802.11, wext,
 copat-wireless, compatwireless-openmac
 If I have to add a new chip driver what are the checklist points i
 have to see
 
 My Quesitions may be basic kindly bare with me
 If any body have self prepared documents that will be great help for me

802.11 is a IEEE standard that is freely available for download.
Regarding Linux architecture and infrastructure there is a lot of
information to be found on wireless.kernel.org.

Regards,
Arend



___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Wifi basics documents

2013-02-08 Thread Arend van Spriel 
On 02/08/2013 10:53 AM, sl reddy wrote:
 any successions will be helpful for me

My *suggestion* would be:

http://wireless.kernel.org/en/developers/Documentation

For what it is worth, below is some terrible ascii art.

Gr. AvS

Fullmac model:

 user-space (libnl)
  |
+--+  v
| cfg80211 |--o nl80211 api
+--+
 ^
 |
 v
+--+
| fullmac  |--o netdev
| driver   |
+--+

Softmac model:

 user-space (libnl)
  |
+--+  v
| cfg80211 |--o nl80211 api
+--+
 ^
 |
 v
+--+
| mac80211 |--o netdev
+--+
 ^
 |
 v
+--+
| softmac  |
| driver   |
+--+


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH] drivers: net: Remove remaining alloc/OOM messages

2013-02-07 Thread Arend van Spriel 
On 02/07/2013 10:46 PM, Joe Perches wrote:
 alloc failures already get standardized OOM
 messages and a dump_stack.
 
 For the affected mallocs around these OOM messages:
 
 Converted kmallocs with multiplies to kmalloc_array.
 Converted a kmalloc/memcpy to kmemdup.
 Removed now unused stack variables.
 Removed unnecessary parentheses.
 Neatened alignment.

for brcm80211 driver files listed below:

Acked-by: Arend van Spriel ar...@broadcom.com
 Signed-off-by: Joe Perches j...@perches.com
 ---
 Let me know if you want multiple small patches instead.
 
  drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c |  5 +--
  drivers/net/wireless/brcm80211/brcmfmac/usb.c  |  7 ++--


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 2/2] mac80211: Remove control.sta from struct ieee80211_tx_info and restructure tx-path

2012-07-14 Thread Arend van Spriel 
On 07/13/2012 08:52 PM, Thomas Huehn wrote:
 The pointer control.sta is removed from ieee80211_tx_info to free up 
 sufficient
 memory in SKB_CB on the tx-path to enable new annotations per data packet e.g.
 support of upcoming Transmit Power Control (TPC).
 Now the control.sta pointer is put on the stack where it is passed as function
 parameter to the .tx equivalent (ieee80211_ops) of each affected wireless
 driver. Therefore a new structure ieee80211_tx_control is added to mac80211.h
 which holds the sta structure instead.
 
 ---
  .../net/wireless/brcm80211/brcmsmac/mac80211_if.c  |  6 +++--
 
 diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c 
 b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
 index 9e79d47..a7be68d 100644
 --- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
 +++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
 @@ -264,7 +264,9 @@ static void brcms_set_basic_rate(struct brcm_rateset *rs, 
 u16 rate, bool is_br)
   }
  }
  
 -static void brcms_ops_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
 +static void brcms_ops_tx(struct ieee80211_hw *hw,
 +  struct ieee80211_tx_control *control,
 +  struct sk_buff *skb)

Fix indent here (if it is not a mailer issue).

  {
   struct brcms_info *wl = hw-priv;
   struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
 @@ -276,7 +278,7 @@ static void brcms_ops_tx(struct ieee80211_hw *hw, struct 
 sk_buff *skb)
   goto done;
   }
   brcms_c_sendpkt_mac80211(wl-wlc, skb, hw);
 - tx_info-rate_driver_data[0] = tx_info-control.sta;
 + tx_info-rate_driver_data[0] = control-sta;
   done:
   spin_unlock_bh(wl-lock);
  }

Gr. AvS

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] [PATCH 2/2] mac80211: Remove control.sta from struct ieee80211_tx_info and restructure tx-path

2012-07-14 Thread Arend van Spriel 
On 07/14/2012 01:44 PM, Felix Fietkau wrote:
 On 2012-07-14 12:10 PM, Arend van Spriel wrote:
 On 07/13/2012 08:52 PM, Thomas Huehn wrote:
 The pointer control.sta is removed from ieee80211_tx_info to free up 
 sufficient
 memory in SKB_CB on the tx-path to enable new annotations per data packet 
 e.g.
 support of upcoming Transmit Power Control (TPC).
 Now the control.sta pointer is put on the stack where it is passed as 
 function
 parameter to the .tx equivalent (ieee80211_ops) of each affected wireless
 driver. Therefore a new structure ieee80211_tx_control is added to 
 mac80211.h
 which holds the sta structure instead.

 ---
  .../net/wireless/brcm80211/brcmsmac/mac80211_if.c  |  6 +++--

 diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c 
 b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
 index 9e79d47..a7be68d 100644
 --- a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
 +++ b/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
 @@ -264,7 +264,9 @@ static void brcms_set_basic_rate(struct brcm_rateset 
 *rs, u16 rate, bool is_br)
 }
  }
  
 -static void brcms_ops_tx(struct ieee80211_hw *hw, struct sk_buff *skb)
 +static void brcms_ops_tx(struct ieee80211_hw *hw,
 +struct ieee80211_tx_control *control,
 +struct sk_buff *skb)

 Fix indent here (if it is not a mailer issue).
 Indentation looks correct to me. The + in front of the 'static' moves
 the rest of the line one character further to the right, whereas in the
 other lines it's compensated by the tabstop.
 
 - Felix
 

I see. I did not apply the patch to be sure.

Gr. AvS


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-11-19 Thread Arend van Spriel 
On 11/19/2011 03:20 PM, Haohui Liao wrote:
 Dear Linux wifi developers,
 
 I didn't encounter core dump problem with kernel 3.1. However, after
 connecting for a few seconds or minutes, the connection with stall and
 I can't assess Internet. I check my dmesg, it gave the following info:
 
 [ 45.966602] wlan0: direct probe to f4:3f:61:06:22:21 (try 1/3)
 [ 45.969213] wlan0: direct probe responded
 [ 45.998789] wlan0: authenticate with f4:3f:61:06:22:21 (try 1)
 [ 46.001234] wlan0: authenticated
 [ 46.001270] wlan0: associate with f4:3f:61:06:22:21 (try 1)
 [ 46.004102] wlan0: RX AssocResp from f4:3f:61:06:22:21 (capab=0x411
 status=0 aid=1)
 [ 46.004107] wlan0: associated
 [ 93.007527] usb 1-1.3: USB disconnect, device number 3
 [ 95.654157] NET: Registered protocol family 10
 [ 106.263062] wlan0: no IPv6 routers present

Actually, this trace looks fine. The last message means that no IPv6
capable network equipment has been detected. Did you do unplug a USB device?

 Does this mean that the IPv6 in kernel 3.1 is affecting the wifi
 connection?  Please advice.

Provide hardware info.

Gr. AvS

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Arend Van Spriel 
Hi Dan,

Why not use min() function?
index = min(COMP_HDR_LEN + osize, 2046);
mchecksum = word[index] |
(word[index + 1]  8);

Or would smatch miss this in its analysis?

Gr. AvS

From: linux-wireless-ow...@vger.kernel.org 
[linux-wireless-ow...@vger.kernel.org] On Behalf Of Dan Carpenter 
[erro...@gmail.com]
Sent: Monday, December 20, 2010 9:30 AM
To: Vasanthakumar Thiagarajan
Cc: linux-wirel...@vger.kernel.org; ath9k-devel@lists.ath9k.org
Subject: smatch stuff: potential read past the end of the buffer

Hello Vasanthakumar,

Smatch complains that in linux-next 60e0c3a7 ath9k_hw: Eeeprom changes
for AR9485 means there is a potential read past the end of the buffer
int ar9300_eeprom_restore_internal().

drivers/net/wireless/ath/ath9k/ar9003_eeprom.c +3381
ar9300_eeprom_restore_internal(81)
error: buffer overflow 'word' 2048 = 4099

word is allocated with 2048 bytes:
word = kzalloc(2048, GFP_KERNEL);

length can be up to 4099:
if ((!AR_SREV_9485(ah)  length = 1024) ||
(AR_SREV_9485(ah)  length = (4 * 1024))) {
 ^

so osize can be up to 4099 as well:
osize = length;

We're reading way past the end of the word array here:
mchecksum = word[COMP_HDR_LEN + osize] |
^^
(word[COMP_HDR_LEN + osize + 1]  8);

I don't know how to fix this.  Can you take a look?

regards,
dan carpenter

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Re: [ath9k-devel] smatch stuff: potential read past the end of the buffer

2010-12-20 Thread Arend Van Spriel 
Hi Dan,

Agreed. But maybe there is no usage scenario in which the boundary is actually 
crossed. Have to wait for ath9k developers to answer that.

Gr. AvS

From: Dan Carpenter [erro...@gmail.com]
Sent: Monday, December 20, 2010 1:42 PM
To: Arend Van Spriel
Cc: Vasanthakumar Thiagarajan; linux-wirel...@vger.kernel.org; 
ath9k-devel@lists.ath9k.org
Subject: Re: smatch stuff: potential read past the end of the buffer

On Mon, Dec 20, 2010 at 02:16:56AM -0800, Arend Van Spriel wrote:
 Hi Dan,

 Why not use min() function?
 index = min(COMP_HDR_LEN + osize, 2046);
 mchecksum = word[index] |
 (word[index + 1]  8);

 Or would smatch miss this in its analysis?

That would silence the warning, but is it the right fix?  I thought
maybe we should make word a larger buffer?

regards,
dan carpenter




___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel