linux-stable.git/drivers/net/wireless/ath, branch linux-3.2.y Linux kernel stable tree ath9k_htc: Add a sanity check in ath9k_htc_ampdu_action() 2018-05-31T23:30:05+00:00 Dan Carpenter dan.carpenter@oracle.com 2017-12-05T14:35:08+00:00 5d3ecc8aa8eb3dc677d5214464a0b01e7b5e1d26 commit 413fd2f5c0233d3cde391679b967c1f14cd2cb27 upstream. Smatch generates a warning here: drivers/net/wireless/ath/ath9k/htc_drv_main.c:1688 ath9k_htc_ampdu_action() error: buffer overflow 'ista->tid_state' 8 <= 15 I don't know if it's a real bug or not but the other paths through this function all ensure that "tid" is less than ATH9K_HTC_MAX_TID (8) so checking here makes things more consistent. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 413fd2f5c0233d3cde391679b967c1f14cd2cb27 upstream.

Smatch generates a warning here:

    drivers/net/wireless/ath/ath9k/htc_drv_main.c:1688 ath9k_htc_ampdu_action()
    error: buffer overflow 'ista->tid_state' 8 <= 15

I don't know if it's a real bug or not but the other paths through this
function all ensure that "tid" is less than ATH9K_HTC_MAX_TID (8) so
checking here makes things more consistent.

Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath6kl: fix struct hif_scatter_req list handling 2018-03-19T18:58:24+00:00 Kalle Valo kvalo@qca.qualcomm.com 2014-03-11T10:58:00+00:00 ff114714a1ffc8d4824aae0ee8dcd1851d3203d0 commit 31b9cc9a873dcab161999622314f98a75d838975 upstream. Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf command: iperf -c $TARGET_IP -i 5 -t 50 -w 1M The crash was: Unable to handle kernel paging request at virtual address 1a480000 pgd = 80004000 [1a480000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core] CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1 Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio] task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000 PC is at v7_dma_clean_range+0x20/0x38 LR is at dma_cache_maint_page+0x50/0x54 pc : [<8001a6f8>] lr : [<800170fc>] psr: 20000093 sp : dc9afcf8 ip : 8001a748 fp : 00000004 r10: 00000000 r9 : 00000001 r8 : 00000000 r7 : 00000001 r6 : 00000000 r5 : 80cb7000 r4 : 03f9a480 r3 : 0000001f r2 : 00000020 r1 : 1a480000 r0 : 1a480000 Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 6cc5004a DAC: 00000015 Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238) Stack: (0xdc9afcf8 to 0xdc9b0000) fce0: 80c9b29c 00000000 fd00: 00000000 80017134 8001a748 dc302ac0 00000000 00000000 dc454a00 80c12ed8 fd20: dc115410 80017238 00000000 dc454a10 00000001 80017588 00000001 00000000 fd40: 00000000 dc302ac0 dc9afe38 dc9afe68 00000004 80c12ed8 00000000 dc454a00 fd60: 00000004 80436f88 00000000 00000000 00000600 0000ffff 0000000c 80c113c4 fd80: 80c9b29c 00000001 00000004 dc115470 60000013 dc302ac0 dc46e000 dc302800 fda0: dc9afe10 dc302b78 60000013 dc302ac0 dc46e000 00000035 dc46e5b0 80438c90 fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 00000005 dc9afe10 fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00 fe00: 000001b5 7f619d64 dcc7c830 00000000 00000000 dc9afe38 dc9afe68 00000000 fe20: 00000000 00000000 dc9afe28 dc9afe28 80424d80 00000000 00000035 9cac0034 fe40: 00000000 00000000 00000000 00000000 000001b5 00000000 00000000 00000000 fe60: dc9afe68 dc9afe10 3b9aca00 00000000 00000080 00000034 00000000 00000100 fe80: 00000000 00000000 dc9afe10 00000004 dc454a00 00000000 dc46e010 dc46e96c fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 00000600 80c0e770 fec0: dc15a900 dcc7c838 00000000 dc46e954 8042d434 dcc44680 dc46e954 dc004400 fee0: dc454500 00000000 00000000 dc9ae038 dc004400 8003c450 dcc44680 dc004414 ff00: dc46e954 dc454500 00000001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030 ff20: 00000001 dc9ae000 dc004400 8003d158 8003d020 00000000 00000000 80c53941 ff40: dc9aff64 dcb71ea0 00000000 dcc44680 8003d020 00000000 00000000 00000000 ff60: 00000000 80042480 00000000 00000000 000000f8 dcc44680 00000000 00000000 ff80: dc9aff80 dc9aff80 00000000 00000000 dc9aff90 dc9aff90 dc9affac dcb71ea0 ffa0: 800423cc 00000000 00000000 8000e018 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] (dma_cache_maint_page+0x50/0x54) [<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] (arm_dma_map_page+0x64/0x68) [<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] (arm_dma_map_sg+0x7c/0xf4) [<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] (sdhci_send_command+0x894/0xe00) [<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] (sdhci_request+0xc0/0x1ec) [<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] (mmc_start_request+0xb8/0xd4) [<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] (__mmc_start_req+0x60/0x84) [<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] (mmc_wait_for_req+0x10/0x20) [<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from [<8003c450>] (process_one_work+0x10c/0x370) [<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] (worker_thread+0x138/0x3fc) [<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] (kthread+0xb4/0xb8) [<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c) Code: e1a02312 e2423001 e1c00003 f57ff04f (ee070f3a) ---[ end trace 0c038f0b8e0b67a3 ]--- Kernel panic - not syncing: Fatal exception Jason's analysis: "The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead, it only run one round loop. This may be caused by that the GCC 4.8.1 thought that the scat_list only have one item and then no need to do full iteration, but this is simply wrong by looking at the assebly code. This will cause the sg buffer not get set when scat_entries > 1 and thus lead to kernel panic. Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)" Fix this by using the normal [0] style for defining unknown number of list entries following the struct. This also fixes corruption with scat_q_depth, which was mistankely added to the end of struct and overwritten if there were more than item in the scat list. Reported-by: Jason Liu <r64343@freescale.com> Tested-by: Jason Liu <r64343@freescale.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> [bwh: Backported to 3.2: There's no scat_q_depth field] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 31b9cc9a873dcab161999622314f98a75d838975 upstream.

Jason noticed that with Yocto GCC 4.8.1 ath6kl crashes with this iperf command:

iperf -c $TARGET_IP -i 5 -t 50 -w 1M

The crash was:

Unable to handle kernel paging request at virtual address 1a480000
pgd = 80004000
[1a480000] *pgd=00000000
Internal error: Oops: 805 [#1] SMP ARM
Modules linked in: ath6kl_sdio ath6kl_core [last unloaded: ath6kl_core]
CPU: 0 PID: 1953 Comm: kworker/u4:0 Not tainted 3.10.9-1.0.0_alpha+dbf364b #1
Workqueue: ath6kl ath6kl_sdio_write_async_work [ath6kl_sdio]
task: dcc9a680 ti: dc9ae000 task.ti: dc9ae000
PC is at v7_dma_clean_range+0x20/0x38
LR is at dma_cache_maint_page+0x50/0x54
pc : [<8001a6f8>]    lr : [<800170fc>]    psr: 20000093
sp : dc9afcf8  ip : 8001a748  fp : 00000004
r10: 00000000  r9 : 00000001  r8 : 00000000
r7 : 00000001  r6 : 00000000  r5 : 80cb7000  r4 : 03f9a480
r3 : 0000001f  r2 : 00000020  r1 : 1a480000  r0 : 1a480000
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 6cc5004a  DAC: 00000015
Process kworker/u4:0 (pid: 1953, stack limit = 0xdc9ae238)
Stack: (0xdc9afcf8 to 0xdc9b0000)
fce0:                                                       80c9b29c 00000000
fd00: 00000000 80017134 8001a748 dc302ac0 00000000 00000000 dc454a00 80c12ed8
fd20: dc115410 80017238 00000000 dc454a10 00000001 80017588 00000001 00000000
fd40: 00000000 dc302ac0 dc9afe38 dc9afe68 00000004 80c12ed8 00000000 dc454a00
fd60: 00000004 80436f88 00000000 00000000 00000600 0000ffff 0000000c 80c113c4
fd80: 80c9b29c 00000001 00000004 dc115470 60000013 dc302ac0 dc46e000 dc302800
fda0: dc9afe10 dc302b78 60000013 dc302ac0 dc46e000 00000035 dc46e5b0 80438c90
fdc0: dc9afe10 dc302800 dc302800 dc9afe68 dc9afe38 80424cb4 00000005 dc9afe10
fde0: dc9afe20 80424de8 dc9afe10 dc302800 dc46e910 80424e90 dc473c00 dc454f00
fe00: 000001b5 7f619d64 dcc7c830 00000000 00000000 dc9afe38 dc9afe68 00000000
fe20: 00000000 00000000 dc9afe28 dc9afe28 80424d80 00000000 00000035 9cac0034
fe40: 00000000 00000000 00000000 00000000 000001b5 00000000 00000000 00000000
fe60: dc9afe68 dc9afe10 3b9aca00 00000000 00000080 00000034 00000000 00000100
fe80: 00000000 00000000 dc9afe10 00000004 dc454a00 00000000 dc46e010 dc46e96c
fea0: dc46e000 dc46e964 00200200 00100100 dc46e910 7f619ec0 00000600 80c0e770
fec0: dc15a900 dcc7c838 00000000 dc46e954 8042d434 dcc44680 dc46e954 dc004400
fee0: dc454500 00000000 00000000 dc9ae038 dc004400 8003c450 dcc44680 dc004414
ff00: dc46e954 dc454500 00000001 dcc44680 dc004414 dcc44698 dc9ae000 dc9ae030
ff20: 00000001 dc9ae000 dc004400 8003d158 8003d020 00000000 00000000 80c53941
ff40: dc9aff64 dcb71ea0 00000000 dcc44680 8003d020 00000000 00000000 00000000
ff60: 00000000 80042480 00000000 00000000 000000f8 dcc44680 00000000 00000000
ff80: dc9aff80 dc9aff80 00000000 00000000 dc9aff90 dc9aff90 dc9affac dcb71ea0
ffa0: 800423cc 00000000 00000000 8000e018 00000000 00000000 00000000 00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<8001a6f8>] (v7_dma_clean_range+0x20/0x38) from [<800170fc>] (dma_cache_maint_page+0x50/0x54)
[<800170fc>] (dma_cache_maint_page+0x50/0x54) from [<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c)
[<80017134>] (__dma_page_cpu_to_dev+0x34/0x9c) from [<80017238>] (arm_dma_map_page+0x64/0x68)
[<80017238>] (arm_dma_map_page+0x64/0x68) from [<80017588>] (arm_dma_map_sg+0x7c/0xf4)
[<80017588>] (arm_dma_map_sg+0x7c/0xf4) from [<80436f88>] (sdhci_send_command+0x894/0xe00)
[<80436f88>] (sdhci_send_command+0x894/0xe00) from [<80438c90>] (sdhci_request+0xc0/0x1ec)
[<80438c90>] (sdhci_request+0xc0/0x1ec) from [<80424cb4>] (mmc_start_request+0xb8/0xd4)
[<80424cb4>] (mmc_start_request+0xb8/0xd4) from [<80424de8>] (__mmc_start_req+0x60/0x84)
[<80424de8>] (__mmc_start_req+0x60/0x84) from [<80424e90>] (mmc_wait_for_req+0x10/0x20)
[<80424e90>] (mmc_wait_for_req+0x10/0x20) from [<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio])
[<7f619d64>] (ath6kl_sdio_scat_rw.isra.10+0x1dc/0x240 [ath6kl_sdio]) from [<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio])
[<7f619ec0>] (ath6kl_sdio_write_async_work+0x5c/0x104 [ath6kl_sdio]) from [<8003c450>] (process_one_work+0x10c/0x370)
[<8003c450>] (process_one_work+0x10c/0x370) from [<8003d158>] (worker_thread+0x138/0x3fc)
[<8003d158>] (worker_thread+0x138/0x3fc) from [<80042480>] (kthread+0xb4/0xb8)
[<80042480>] (kthread+0xb4/0xb8) from [<8000e018>] (ret_from_fork+0x14/0x3c)
Code: e1a02312 e2423001 e1c00003 f57ff04f (ee070f3a)
---[ end trace 0c038f0b8e0b67a3 ]---
Kernel panic - not syncing: Fatal exception

Jason's analysis:

  "The GCC 4.8.1 compiler will not do the for-loop till scat_entries, instead,
   it only run one round loop. This may be caused by that the GCC 4.8.1 thought
   that the scat_list only have one item and then no need to do full iteration,
   but this is simply wrong by looking at the assebly code. This will cause the sg
   buffer not get set when scat_entries > 1 and thus lead to kernel panic.

   Note: This issue not observed with GCC 4.7.2, only found on the GCC 4.8.1)"

Fix this by using the normal [0] style for defining unknown number of list
entries following the struct. This also fixes corruption with scat_q_depth, which
was mistankely added to the end of struct and overwritten if there were more
than item in the scat list.

Reported-by: Jason Liu <r64343@freescale.com>
Tested-by: Jason Liu <r64343@freescale.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
[bwh: Backported to 3.2: There's no scat_q_depth field]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath6kl: fix uninitialized variable in ath6kl_sdio_enable_scatter() 2018-03-19T18:58:21+00:00 Andi Kleen andi@firstfloor.org 2012-09-03T20:15:36+00:00 a2d4436a69c3570419680ee75b431d2d9af26254 commit 527f6570300980251e818e80865b437eefb4e5d3 upstream. gcc 4.8 warns /backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c: In function 'ath6kl_sdio_enable_scatter': /backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c:748:16: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized] if (virt_scat || ret) { ^ The variable can indeed be uninitialized when the previous if branch is skipped. I just set it to zero for now. I'm not fully sure the fix is correct, maybe the || should be an && ? Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 527f6570300980251e818e80865b437eefb4e5d3 upstream.

gcc 4.8 warns

/backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c:
In function 'ath6kl_sdio_enable_scatter':
/backup/lsrc/git/linux-lto-2.6/drivers/net/wireless/ath/ath6kl/sdio.c:748:16:
warning: 'ret' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  if (virt_scat || ret) {
                ^

The variable can indeed be uninitialized when the previous if branch is
skipped. I just set it to zero for now. I'm not fully sure the fix is
correct, maybe the || should be an && ?

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k_htc: fix NULL-deref at probe 2017-08-26T01:13:58+00:00 Johan Hovold johan@kernel.org 2017-03-13T12:44:20+00:00 af4b41c56261592cd90c3ea196f6077c466fdd7a commit ebeb36670ecac36c179b5fb5d5c88ff03ba191ec upstream. Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit ebeb36670ecac36c179b5fb5d5c88ff03ba191ec upstream.

Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.

Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device 2017-08-26T01:13:57+00:00 Dmitry Tunin hanipouspilot@gmail.com 2017-03-08T11:52:07+00:00 4b8798065015ed68f2eafc68d32f12dc3cac55f0 commit 16ff1fb0e32f76a5d285a6f23b82d21aa52813c6 upstream. T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=1eda ProdID=2315 Rev=01.08 S: Manufacturer=ATHEROS S: Product=USB2.0 WLAN S: SerialNumber=12345 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 16ff1fb0e32f76a5d285a6f23b82d21aa52813c6 upstream.

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=1eda ProdID=2315 Rev=01.08
S:  Manufacturer=ATHEROS
S:  Product=USB2.0 WLAN
S:  SerialNumber=12345
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)

Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k_htc: add device ID for Toshiba WLM-20U2/GN-1080 2017-08-26T01:13:57+00:00 Alexander Tsoy alexander@tsoy.me 2016-01-07T22:26:03+00:00 7edc5a6b8782374b4653754d452a5c100b8884f6 commit aea57edf80c6e96d6dc24757599396af99c02b19 upstream. This device is available under different marketing names: WLM-20U2 - Wireless USB Dongle for Toshiba TVs GN-1080 - Wireless LAN Module for Toshiba MFPs. Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit aea57edf80c6e96d6dc24757599396af99c02b19 upstream.

This device is available under different marketing names:
WLM-20U2 - Wireless USB Dongle for Toshiba TVs
GN-1080 - Wireless LAN Module for Toshiba MFPs.

Signed-off-by: Alexander Tsoy <alexander@tsoy.me>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k_htc: Add new USB ID 2017-08-26T01:13:56+00:00 Leon Nardella leon.nardella@gmail.com 2015-02-07T19:10:07+00:00 1706ece4ae1be90a70e740595245e2b78bf6fa38 commit 0088d27b78f2c0118aee82923269518616481ea0 upstream. This device is a dongle made by Philips to enhance their TVs with wireless capabilities, but works flawlessly on any upstream kernel, provided that the ath9k_htc module is attached to it. It's correctly recognized by lsusb as "0471:209e Philips (or NXP) PTA01 Wireless Adapter" and the patch has been tested on real hardware. Signed-off-by: Leon Nardella <leon.nardella@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 0088d27b78f2c0118aee82923269518616481ea0 upstream.

This device is a dongle made by Philips to enhance their TVs with wireless capabilities,
but works flawlessly on any upstream kernel, provided that the ath9k_htc module is attached to it.
It's correctly recognized by lsusb as "0471:209e Philips (or NXP) PTA01 Wireless Adapter" and the
patch has been tested on real hardware.

Signed-off-by: Leon Nardella <leon.nardella@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k_htc: Add device ID for Buffalo WLI-UV-AG300P 2017-08-26T01:13:56+00:00 Masaki TAGAWA masaki@club.kyutech.ac.jp 2014-02-06T05:06:24+00:00 4b28469a16d14907dc8d51759e876d43c52a7e2d commit 98f99eeae98047bc195bcc7510eae4f0cf3658a0 upstream. Buffalo WLI-UV-AG300P is almost the same as Sony UWA-BR100. Signed-off-by: Masaki TAGAWA <masaki@club.kyutech.ac.jp> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 98f99eeae98047bc195bcc7510eae4f0cf3658a0 upstream.

Buffalo WLI-UV-AG300P is almost the same as Sony UWA-BR100.

Signed-off-by: Masaki TAGAWA <masaki@club.kyutech.ac.jp>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k_htc: Add PID/VID for a Ubiquiti WiFiStation 2017-08-26T01:13:56+00:00 Mohammed Shafi Shajakhan mohammed@qca.qualcomm.com 2012-10-16T16:01:49+00:00 9abce5c9c114e641281055326271fa490e779633 commit 763cbac07674a648f1377b21ca66f577c103fa9a upstream. Roger says, Ubiquiti produce 2 versions of their WiFiStation USB adapter. One has an internal antenna, the other has an external antenna and name suffix EXT. They have separate USB ids and in distribution openSUSE 12.2 (kernel 3.4.6), file /usr/share/usb.ids shows: 0cf3 Atheros Communications, Inc. ... b002 Ubiquiti WiFiStation 802.11n [Atheros AR9271] b003 Ubiquiti WiFiStationEXT 802.11n [Atheros AR9271] Add b002 Ubiquiti WiFiStation in the PID/VID list. Reported-by: Roger Price <ath9k@rogerprice.org> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 763cbac07674a648f1377b21ca66f577c103fa9a upstream.

Roger says, Ubiquiti produce 2 versions of their WiFiStation USB adapter.  One
has an internal antenna, the other has an external antenna and
name suffix EXT.  They have separate USB ids and in distribution
openSUSE 12.2 (kernel 3.4.6), file /usr/share/usb.ids shows:

  0cf3  Atheros Communications, Inc.
       ...
       b002  Ubiquiti WiFiStation 802.11n [Atheros AR9271]
       b003  Ubiquiti WiFiStationEXT 802.11n [Atheros AR9271]

Add b002 Ubiquiti WiFiStation in the PID/VID list.

Reported-by: Roger Price <ath9k@rogerprice.org>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
ath9k_htc: Add Panasonic N5HBZ0000055 device id 2017-08-26T01:13:56+00:00 Sujith Manoharan c_manoha@qca.qualcomm.com 2012-04-11T08:28:15+00:00 551cbdd10cddb2d2317f0b06d1cfeaf420a4780e commit d90b570898f7cc3dd0b26d4e646f464408b04022 upstream. Reported-by: Ryan Roper <ryan.roper@gmail.com> Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit d90b570898f7cc3dd0b26d4e646f464408b04022 upstream.

Reported-by: Ryan Roper <ryan.roper@gmail.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>