Re: [PATCH] ath10k: Allow setting coverage class

2016-07-29 Thread Sebastian Gottschall 
if these sourcecodes would be just up to date with the binaries provided 
by qca. but qca doesnt seem to care that much about it.
this is mainly also the reason why there are soo many long term 
stability issues with no resolution



Am 29.07.2016 um 17:09 schrieb Ben Greear:

On 07/29/2016 07:52 AM, Benjamin Berg wrote:

On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:

On 07/27/2016 01:33 AM, Benjamin Berg wrote:


Unfortunately ath10k does not generally allow modifying the 
coverage class
with the stock firmware and Qualcomm has so far refused to 
implement this
feature so that it can be properly supported in ath10k. If we 
however know
the registers that need to be modified for proper operation with a 
higher

coverage class, then we can do these modifications from the driver.

This patch implements this hack for first generation cards which 
are based
on a core that is similar to ath9k. The registers are modified in 
place and
need to be re-written every time the firmware sets them. To achieve 
this

the register status is verified after any event from the firmware.

The coverage class may not be modified temporarily right after the 
card
re-initializes the registers. This is for example the case during 
scanning.


A warning will be generated if the hack is not supported on the 
card or

unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).

Thanks to Sebastian Gottschall  for 
initially

working on a userspace support for this. This patch wouldn't have been
possible without this documentation.


I would be concerned about the various resets firmware does to work 
around
hardware hangs as well.  I don't think any events are generated for 
these, unless

you count the dbglog messages?


Yeah, I am aware of the fact that the firmware may do internal resets
from time to time. The interesting question (and one for which I do not
know the answer) is whether we get a wmi or other event under all
conditions where the register may be rewritten due to a reset.

The current code will re-set the register value after any wmi event
including debug messages. If this is not enough, then the only solution
might be to periodically poll the register values instead of relying on
a received event.


You will get a dbglog event at least most of the time, so maybe that
will be good enough.

Someone with src code and that cared could audit the code I guess, but 
then
that person could also just implement the feature properly in the 
firmware

to begin with...

Thanks,
Ben




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

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

Dell Venue 8 Pro "Dell Wireless" (Atheros 6k) chipset with SDIO ID 0271:0418 not recognized/supported

2016-07-29 Thread russianneuromancer 
Hi
 
Please look into commentary 50 from bugreport 
https://bugzilla.kernel.org/show_bug.cgi?id=67921#c50 
There is patch for enabling support of Atheros Wireless adapter in Dell Venue 8 
Pro tablet.
 
Please review if this possible to include this patch into upstream.
--
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

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-29 Thread Ben Greear 

On 07/29/2016 07:52 AM, Benjamin Berg wrote:

On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:

On 07/27/2016 01:33 AM, Benjamin Berg wrote:


Unfortunately ath10k does not generally allow modifying the coverage class
with the stock firmware and Qualcomm has so far refused to implement this
feature so that it can be properly supported in ath10k. If we however know
the registers that need to be modified for proper operation with a higher
coverage class, then we can do these modifications from the driver.

This patch implements this hack for first generation cards which are based
on a core that is similar to ath9k. The registers are modified in place and
need to be re-written every time the firmware sets them. To achieve this
the register status is verified after any event from the firmware.

The coverage class may not be modified temporarily right after the card
re-initializes the registers. This is for example the case during scanning.

A warning will be generated if the hack is not supported on the card or
unexpected values are hit. There is no error reporting for userspace
applications though (this is a limitation in the mac80211 driver
interface).


Thanks to Sebastian Gottschall  for initially

working on a userspace support for this. This patch wouldn't have been
possible without this documentation.


I would be concerned about the various resets firmware does to work around
hardware hangs as well.  I don't think any events are generated for these, 
unless
you count the dbglog messages?


Yeah, I am aware of the fact that the firmware may do internal resets
from time to time. The interesting question (and one for which I do not
know the answer) is whether we get a wmi or other event under all
conditions where the register may be rewritten due to a reset.

The current code will re-set the register value after any wmi event
including debug messages. If this is not enough, then the only solution
might be to periodically poll the register values instead of relying on
a received event.


You will get a dbglog event at least most of the time, so maybe that
will be good enough.

Someone with src code and that cared could audit the code I guess, but then
that person could also just implement the feature properly in the firmware
to begin with...

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: [PATCH] ath10k: Allow setting coverage class

2016-07-29 Thread Benjamin Berg 
On Mi, 2016-07-27 at 10:26 -0700, Ben Greear wrote:
> On 07/27/2016 01:33 AM, Benjamin Berg wrote:
> > 
> > Unfortunately ath10k does not generally allow modifying the coverage class
> > with the stock firmware and Qualcomm has so far refused to implement this
> > feature so that it can be properly supported in ath10k. If we however know
> > the registers that need to be modified for proper operation with a higher
> > coverage class, then we can do these modifications from the driver.
> > 
> > This patch implements this hack for first generation cards which are based
> > on a core that is similar to ath9k. The registers are modified in place and
> > need to be re-written every time the firmware sets them. To achieve this
> > the register status is verified after any event from the firmware.
> > 
> > The coverage class may not be modified temporarily right after the card
> > re-initializes the registers. This is for example the case during scanning.
> > 
> > A warning will be generated if the hack is not supported on the card or
> > unexpected values are hit. There is no error reporting for userspace
> > applications though (this is a limitation in the mac80211 driver
> > interface).
> > 
> > > > Thanks to Sebastian Gottschall  for initially
> > working on a userspace support for this. This patch wouldn't have been
> > possible without this documentation.
> 
> I would be concerned about the various resets firmware does to work around
> hardware hangs as well.  I don't think any events are generated for these, 
> unless
> you count the dbglog messages?

Yeah, I am aware of the fact that the firmware may do internal resets
from time to time. The interesting question (and one for which I do not
know the answer) is whether we get a wmi or other event under all
conditions where the register may be rewritten due to a reset.

The current code will re-set the register value after any wmi event
including debug messages. If this is not enough, then the only solution
might be to periodically poll the register values instead of relying on
a received event.

Benjamin

signature.asc
Description: This is a digitally signed message part

[PATCH] mwifiex: PCIe8997 chip specific handling

2016-07-29 Thread Amitkumar Karwar 
The patch corrects the revision id register and uses it along with
magic value and chip version registers to download appropriate firmware
image.

PCIe8997 Z chipset variant code has been removed, as it won't be used in
production.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 35 ++---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 14 +---
 2 files changed, 18 insertions(+), 31 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 81bceef..9aec9a9 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2910,7 +2910,7 @@ static int mwifiex_pcie_request_irq(struct 
mwifiex_adapter *adapter)
 static void mwifiex_pcie_get_fw_name(struct mwifiex_adapter *adapter)
 {
int revision_id = 0;
-   int version;
+   int version, magic;
struct pcie_service_card *card = adapter->card;
 
switch (card->dev->device) {
@@ -2935,30 +2935,19 @@ static void mwifiex_pcie_get_fw_name(struct 
mwifiex_adapter *adapter)
}
break;
case PCIE_DEVICE_ID_MARVELL_88W8997:
-   mwifiex_read_reg(adapter, 0x0c48, _id);
+   mwifiex_read_reg(adapter, 0x8, _id);
mwifiex_read_reg(adapter, 0x0cd0, );
+   mwifiex_read_reg(adapter, 0x0cd4, );
+   revision_id &= 0xff;
version &= 0x7;
-   switch (revision_id) {
-   case PCIE8997_V2:
-   if (version == CHIP_VER_PCIEUART)
-   strcpy(adapter->fw_name,
-  PCIEUART8997_FW_NAME_V2);
-   else
-   strcpy(adapter->fw_name,
-  PCIEUSB8997_FW_NAME_V2);
-   break;
-   case PCIE8997_Z:
-   if (version == CHIP_VER_PCIEUART)
-   strcpy(adapter->fw_name,
-  PCIEUART8997_FW_NAME_Z);
-   else
-   strcpy(adapter->fw_name,
-  PCIEUSB8997_FW_NAME_Z);
-   break;
-   default:
-   strcpy(adapter->fw_name, PCIE8997_DEFAULT_FW_NAME);
-   break;
-   }
+   magic &= 0xff;
+   if (revision_id == PCIE8997_A1 &&
+   magic == CHIP_MAGIC_VALUE &&
+   version == CHIP_VER_PCIEUART)
+   strcpy(adapter->fw_name, PCIEUART8997_FW_NAME_V4);
+   else
+   strcpy(adapter->fw_name, PCIEUSB8997_FW_NAME_V4);
+   break;
default:
break;
}
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index f6992f0..46f99ca 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -32,12 +32,9 @@
 #define PCIE8897_DEFAULT_FW_NAME "mrvl/pcie8897_uapsta.bin"
 #define PCIE8897_A0_FW_NAME "mrvl/pcie8897_uapsta_a0.bin"
 #define PCIE8897_B0_FW_NAME "mrvl/pcie8897_uapsta.bin"
-#define PCIE8997_DEFAULT_FW_NAME "mrvl/pcieusb8997_combo_v2.bin"
-#define PCIEUART8997_FW_NAME_Z "mrvl/pcieuart8997_combo.bin"
-#define PCIEUART8997_FW_NAME_V2 "mrvl/pcieuart8997_combo_v2.bin"
-#define PCIEUSB8997_FW_NAME_Z "mrvl/pcieusb8997_combo.bin"
-#define PCIEUSB8997_FW_NAME_V2 "mrvl/pcieusb8997_combo_v2.bin"
-#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan.bin"
+#define PCIEUART8997_FW_NAME_V4 "mrvl/pcieuart8997_combo_v4.bin"
+#define PCIEUSB8997_FW_NAME_V4 "mrvl/pcieusb8997_combo_v4.bin"
+#define PCIE8997_DEFAULT_WIFIFW_NAME "mrvl/pcie8997_wlan_v4.bin"
 
 #define PCIE_VENDOR_ID_MARVELL  (0x11ab)
 #define PCIE_VENDOR_ID_V2_MARVELL   (0x1b4b)
@@ -47,9 +44,10 @@
 
 #define PCIE8897_A00x1100
 #define PCIE8897_B00x1200
-#define PCIE8997_Z 0x0
-#define PCIE8997_V20x471
+#define PCIE8997_A00x10
+#define PCIE8997_A10x11
 #define CHIP_VER_PCIEUART  0x3
+#define CHIP_MAGIC_VALUE   0x24
 
 /* Constants for Buffer Descriptor (BD) rings */
 #define MWIFIEX_MAX_TXRX_BD0x20
-- 
1.9.1

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

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

2016-07-29 Thread Daniel Wagner 

On 07/28/2016 09:01 PM, Bjorn Andersson wrote:

On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote:


On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:

From: Daniel Wagner 


[..]


Do not quite like it... I'd rather asynchronous request give out a
firmware status pointer that could be used later on.

pcu->fw_st = request_firmware_async(IMS_PCU_FIRMWARE_NAME,
pcu,
ims_pcu_process_async_firmware);
if (IS_ERR(pcu->fw_st))
return PTR_ERR(pcu->fw_st);



fw_loading_wait(pcu->fw_st);



In the remoteproc case (patch 6) this would clean up the code, rather
than replacing the completion API 1 to 1. I like it!


IIRC most drivers do it the same way. So request_firmware_async() indeed 
would be good thing to have. Let me try that.


Thanks for the excellent feedback.

cheers,
daniel
--
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

Re: [RFC v0 3/8] firmware: Factor out firmware load helpers

2016-07-29 Thread Daniel Wagner 

On 07/28/2016 07:57 PM, Dmitry Torokhov wrote:

On Thu, Jul 28, 2016 at 09:55:07AM +0200, Daniel Wagner wrote:

+int __firmware_stat_wait(struct firmware_stat *fwst,
+   long timeout)
+{
+   int err;
+   err = swait_event_interruptible_timeout(fwst->wq,
+   is_fw_sync_done(READ_ONCE(fwst->status)),
+   timeout);
+   if (err == 0 && fwst->status == FW_STATUS_ABORT)
+   return -ENOENT;
+
+   return err;
+}
+EXPORT_SYMBOL(__firmware_stat_wait);
+
+void __firmware_stat_set(struct firmware_stat *fwst, unsigned long status)
+{
+   WRITE_ONCE(fwst->status, status);
+   swake_up(>wq);


Do we need to notify everyone for FW_STATUS_LOADING status?


Hmm, I don't think so. In the end drivers are probably only interested 
in the final result which is either success or fail.


cheers,
daniel
--
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

Re: [RFC v0 3/8] firmware: Factor out firmware load helpers

2016-07-29 Thread Daniel Wagner 

It's somewhat odd to me that the structure is "firmware_stat" but most
of the functions are "fw_loading_*".  That seems inconsistent for a
structure that is (currently) only used by these functions.


I agree, my proposal is odd.


I would personally do either:

a) "struct fw_load_status" and "fw_load_*()"

or

b) "struct firmware_load_stat" and "firmware_load_*()"

I'd also change the function names from "loading" -> "load", similar to
how userland has read(2), not reading(2).


a) sounds good to me, because fw_load_ should be long enough prefix.

cheers,
daniel
--
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