* nl80211 scanning from userspace
From: Christopher Piggott @ 2010-08-16 19:06 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm trying to figure out how to use nl80211 to scan. The "iw" example
has been somewhat helpful, though the userspace header file nl80211
and /usr/include/netlink/*.h have been helpful. I'm on an ubuntu
system, and I'm sorry to say that the libnl1-doc package has some
doxygen files in it that don't agree with the actual headers (function
prototypes differ, etc.) but it's enough to get at least some picture
of what's going on.
Here's what I have put together so far, in snippets:
Register callbacks for all messages:
callbacks = nl_cb_alloc(NL_CB_DEFAULT);
nl_cb_set_all(callbacks, NL_CB_CUSTOM, rx, NULL);
Create a socket, allocate a cache. I do error checking on each of
these calls to make sure they succeed, but I'm eliminating that here
for brevity:
genl_connect(sock);
cache = genl_ctrl_alloc_cache(sock);
nl80211 = genl_ctrl_search_by_name(cache, cacheName); /*
cacheName is "nl80211" */
Start building the message. First build an SSID list with one entry
in it (empty string)
struct nl_msg *ssids = nlmsg_alloc();
nla_put_string(ssids, 0, "");
Next build the scan request message:
struct nl_msg *msg = nlmsg_alloc();
int flags = 0;
int cmd = NL80211_CMD_TRIGGER_SCAN;
genlmsg_put(msg, 0, 0, genl_family_get_id(nl80211), 0, flags, cmd, 0);
/* append our ssid list to this message as a nested message */
nla_put_nested(msg, NL80211_ATTR_SCAN_SSIDS, ssids)
Finally I send the request:
int rc = nl_send_auto_complete(sock, msg);
>From this I found out that 32 bytes were sent (seems reasonable).
Unfortunately, what I get back is this:
[HEADER] 16 octets
.nlmsg_len = 52
.nlmsg_type = 2 <ERROR>
.nlmsg_flags = 0 <>
.nlmsg_seq = 1282012377
.nlmsg_pid = 30415
[ERRORMSG] 20 octets
.error = -22 "Invalid argument"
[ORIGINAL MESSAGE] 16 octets
.nlmsg_len = 16
.nlmsg_type = 23 <0x17>
.nlmsg_flags = 5 <REQUEST,ACK>
.nlmsg_seq = 1282012377
.nlmsg_pid = 30415
so, even following what iw's "scan.c" does I have somehow pieced the
request together incorrectly.
Questions:
1. Am I doing something obviously wrong?
2. Is this even the interface I should be using to do this? (I need
to scan for all access points on a specific "hidden" SSID to retrieve
some information about their SNR. It's a type of "site survey"
application for building contour maps of coverage).
I'm not sure what I'm doing next makes sense, either. After I send
the scan request I wait 3 seconds then start reading like this:
while(nl_recvmsgs(sock, callbacks) != 0)
{
printf("processed a result\n");
}
I have registered my callback earlier; this seems to work because I
get the message (above) plus later an "Operation Not Supported"
message. The operation is indeed supported, as it works with the
iwlist and iw command line tools.
--Chris
^ permalink raw reply
* Re: iwlwifi connection problems
From: Johannes Berg @ 2010-08-16 19:06 UTC (permalink / raw)
To: Alex Romosan; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <877hjqpl2e.fsf@sycorax.lbl.gov>
On Mon, 2010-08-16 at 09:40 -0700, Alex Romosan wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
> > Also, have you tried the released 2.6.35.2?
>
> just tried it with 2.6.36-rc1 (after applying a reiserfs patch) and i
> still need to comment out the call to iwlcore_commit_rxon(priv); on line
> 1361 of iwl-core.c. i'll file the bug, but if nobody steps forward,
> wouldn't it make sense just to remove that call? thanks.
You're right, I got completely confused and mixed up different bug
reports. I'd prefer to have the call there for AGN hardware, but I'll
make a patch to split it up properly. Sorry about that.
johannes
^ permalink raw reply
* Re: nl80211 scanning from userspace
From: Johannes Berg @ 2010-08-16 19:13 UTC (permalink / raw)
To: Christopher Piggott; +Cc: linux-wireless
In-Reply-To: <AANLkTi=ZGn0Rt7zYxBJB0jJ-EY=gPpxtBN2bA9svkq99@mail.gmail.com>
On Mon, 2010-08-16 at 15:06 -0400, Christopher Piggott wrote:
> Start building the message. First build an SSID list with one entry
> in it (empty string)
> struct nl_msg *ssids = nlmsg_alloc();
> nla_put_string(ssids, 0, "");
I think that has to be a 1 instead of 0, but I'm not entirely sure.
> Next build the scan request message:
> struct nl_msg *msg = nlmsg_alloc();
> int flags = 0;
> int cmd = NL80211_CMD_TRIGGER_SCAN;
> genlmsg_put(msg, 0, 0, genl_family_get_id(nl80211), 0, flags, cmd, 0);
> /* append our ssid list to this message as a nested message */
> nla_put_nested(msg, NL80211_ATTR_SCAN_SSIDS, ssids)
You're not telling it which interface should scan, this is handled
generically in iw.c, look for
NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, devidx);
> Finally I send the request:
> int rc = nl_send_auto_complete(sock, msg);
>
> From this I found out that 32 bytes were sent (seems reasonable).
> Unfortunately, what I get back is this:
> [HEADER] 16 octets
> .nlmsg_len = 52
> .nlmsg_type = 2 <ERROR>
> .nlmsg_flags = 0 <>
> .nlmsg_seq = 1282012377
> .nlmsg_pid = 30415
> [ERRORMSG] 20 octets
> .error = -22 "Invalid argument"
> [ORIGINAL MESSAGE] 16 octets
> .nlmsg_len = 16
> .nlmsg_type = 23 <0x17>
> .nlmsg_flags = 5 <REQUEST,ACK>
> .nlmsg_seq = 1282012377
> .nlmsg_pid = 30415
>
> so, even following what iw's "scan.c" does I have somehow pieced the
> request together incorrectly.
>
> Questions:
> 1. Am I doing something obviously wrong?
You're also missing the interface as above.
> 2. Is this even the interface I should be using to do this? (I need
> to scan for all access points on a specific "hidden" SSID to retrieve
> some information about their SNR. It's a type of "site survey"
> application for building contour maps of coverage).
Yes, it does make sense.
> I'm not sure what I'm doing next makes sense, either. After I send
> the scan request I wait 3 seconds then start reading like this:
> while(nl_recvmsgs(sock, callbacks) != 0)
> {
> printf("processed a result\n");
> }
>
> I have registered my callback earlier; this seems to work because I
> get the message (above) plus later an "Operation Not Supported"
> message. The operation is indeed supported, as it works with the
> iwlist and iw command line tools.
Maybe you should look at wpa_supplicant either for doing your thing, or
for the driver_nl80211.c code in it, which is more explicit than iw.
johannes
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Gábor Stefanik @ 2010-08-16 19:16 UTC (permalink / raw)
To: Larry Finger; +Cc: b43-dev, linux-wireless
In-Reply-To: <4C698C19.5010902@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]
2010/8/16 Larry Finger <Larry.Finger@lwfinger.net>:
> On 08/16/2010 12:59 PM, Gábor Stefanik wrote:
>> Hello Everyone!
>>
>> If you are experiencing DMA errors on a BCM4312, please test the
>> attached patch. It implements the PCI-E SERDES workaround, which the
>> hybrid driver is applying during early init to LP-PHY cards, and which
>> is a good candidate for the cause of the DMA error.
>> Note that this is not a final patch & it may cause collateral damage
>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>> cleaned-up version.
>
> The patch that you distributed had a couple of errors in compiling, namely:
>
> CC [M] drivers/ssb/driver_pcicore.o
> drivers/ssb/driver_pcicore.c: In function ‘ssb_pcie_mdio_set_block’:
> drivers/ssb/driver_pcicore.c:457:7: error: ‘i’ undeclared (first use in this
> function)
> drivers/ssb/driver_pcicore.c:457:7: note: each undeclared identifier is reported
> only once for each function it appears in
> drivers/ssb/driver_pcicore.c: In function ‘ssb_pcie_mdio_read’:
> drivers/ssb/driver_pcicore.c:503:2: error: expected ‘;’ before ‘pcicore_write32’
> make[2]: *** [drivers/ssb/driver_pcicore.o] Error 1
> make[1]: *** [drivers/ssb] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> Did you forget a quilt refresh?
>
> My machine does not have the DMA error, but I will be testing.
>
> Larry
>
Oops... yes, two nasty typos. I have no idea why it compiled for me...
Schrödinbug?
With that said, here is the corrected version.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
[-- Attachment #2: pcie_serdes_workaround.diff --]
[-- Type: application/octet-stream, Size: 3429 bytes --]
diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 0e8d352..9f5c5e2 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -446,13 +446,71 @@ static void ssb_pcie_write(struct ssb_pcicore *pc, u32 address, u32 data)
pcicore_write32(pc, 0x134, data);
}
+static bool ssb_pcie_mdio_set_block(struct ssb_pcicore *pc, u8 device)
+{
+ const u16 mdio_control = 0x128;
+ const u16 mdio_data = 0x12C;
+
+ pcicore_write32(pc, mdio_data, 0x57C20000 | (device << 4));
+ udelay(10);
+ int i;
+ for (i = 0; i < 200; i++) {
+ if (pcicore_read32(pc, mdio_control) & 0x100)
+ return true;
+ msleep(1);
+ }
+
+ return false;
+}
+
+static u16 ssb_pcie_mdio_read(struct ssb_pcicore *pc, u8 device,
+ u8 address)
+{
+ const u16 mdio_control = 0x128;
+ const u16 mdio_data = 0x12C;
+ u32 v;
+ int i, imax;
+ u16 data;
+
+ v = 0x80; /* Enable Preamble Sequence */
+ v |= 0x2; /* MDIO Clock Divisor */
+ pcicore_write32(pc, mdio_control, v);
+
+ v = (1 << 30); /* Start of Transaction */
+ v |= (1 << 29); /* Read Transaction */
+ v |= (1 << 17); /* Turnaround */
+
+ if (pc->dev->id.revision >= 10) {
+ if (!ssb_pcie_mdio_set_block(pc, device))
+ return 0;
+ imax = 200;
+ } else {
+ v |= (u32)device << 22;
+ imax = 10;
+ }
+ v |= (u32)address << 18;
+ pcicore_write32(pc, mdio_data, v);
+ /* Wait for the device to complete the transaction */
+ udelay(10);
+ for (i = 0; i < imax; i++) {
+ v = pcicore_read32(pc, mdio_control);
+ if (v & 0x100 /* Trans complete */)
+ break;
+ msleep(1);
+ }
+ udelay(10);
+ data = pcicore_read32(pc, mdio_data) & 0xFFFF;
+ pcicore_write32(pc, mdio_control, 0);
+ return data;
+}
+
static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
u8 address, u16 data)
{
const u16 mdio_control = 0x128;
const u16 mdio_data = 0x12C;
u32 v;
- int i;
+ int i, imax;
v = 0x80; /* Enable Preamble Sequence */
v |= 0x2; /* MDIO Clock Divisor */
@@ -461,13 +519,21 @@ static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
v = (1 << 30); /* Start of Transaction */
v |= (1 << 28); /* Write Transaction */
v |= (1 << 17); /* Turnaround */
- v |= (u32)device << 22;
+
+ if (pc->dev->id.revision >= 10) {
+ if (!ssb_pcie_mdio_set_block(pc, device))
+ return;
+ imax = 200;
+ } else {
+ v |= (u32)device << 22;
+ imax = 10;
+ }
v |= (u32)address << 18;
v |= data;
pcicore_write32(pc, mdio_data, v);
/* Wait for the device to complete the transaction */
udelay(10);
- for (i = 0; i < 10; i++) {
+ for (i = 0; i < imax; i++) {
v = pcicore_read32(pc, mdio_control);
if (v & 0x100 /* Trans complete */)
break;
@@ -591,6 +657,20 @@ int ssb_pcicore_dev_irqvecs_enable(struct ssb_pcicore *pc,
tmp = ssb_pcie_read(pc, 0x100);
tmp |= 0x40;
ssb_pcie_write(pc, 0x100, tmp);
+ } else {
+ const u8 serdes_pll_device = 0x1D;
+ const u8 serdes_rx_device = 0x1F;
+
+ /* PCI-E PHY Status register */
+ if (ssb_pcie_read(pc, 0x204) & 0x10)
+ ssb_pcie_mdio_write(pc, serdes_rx_device,
+ 1 /* Control */, 0xC0);
+ else
+ ssb_pcie_mdio_write(pc, serdes_rx_device,
+ 1 /* Control */, 0x80);
+ ssb_pcie_mdio_write(pc, serdes_pll_device, 1,
+ ssb_pcie_mdio_read(pc, serdes_pll_device, 1) &
+ ~0x4000);
}
}
pc->setup_done = 1;
^ permalink raw reply related
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Larry Finger @ 2010-08-16 19:30 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: b43-dev, linux-wireless
In-Reply-To: <AANLkTi=eFz5fabN74xbndCvD-XBS-KA9EBiOKAZvcbRb@mail.gmail.com>
On 08/16/2010 02:16 PM, Gábor Stefanik wrote:
>
> Oops... yes, two nasty typos. I have no idea why it compiled for me...
> Schrödinbug?
>
> With that said, here is the corrected version.
Hmmm, a new application of the "Uncertainty Principle".
The patch did not break my 14e4:4315 device, which already worked.
Larry
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Gábor Stefanik @ 2010-08-16 19:32 UTC (permalink / raw)
To: Larry Finger; +Cc: b43-dev, linux-wireless
In-Reply-To: <4C6991D9.7070902@lwfinger.net>
2010/8/16 Larry Finger <Larry.Finger@lwfinger.net>:
> On 08/16/2010 02:16 PM, Gábor Stefanik wrote:
>>
>> Oops... yes, two nasty typos. I have no idea why it compiled for me...
>> Schrödinbug?
>>
>> With that said, here is the corrected version.
>
> Hmmm, a new application of the "Uncertainty Principle".
>
> The patch did not break my 14e4:4315 device, which already worked.
>
> Larry
>
That's expected, given that the hybrid driver also does this. :-) The
question is whether it fixes the DMA error.
^ permalink raw reply
* Re: nl80211 scanning from userspace
From: Johannes Berg @ 2010-08-16 19:41 UTC (permalink / raw)
To: Christopher Piggott; +Cc: linux-wireless
In-Reply-To: <AANLkTiniqFJzrWFzNJTxsF31EZfSTei89dbS2Ak4YDjH@mail.gmail.com>
[adding mailing list back]
On Mon, 2010-08-16 at 15:37 -0400, Christopher Piggott wrote:
> Thanks, I had missed that. I assume I also have to specify the
> interface number for NL80211_CMD_GET_SCAN as well as
> NL80211_CMD_TRIGGER_SCAN, right?
>
> What I get now is a "Success" on the TRIGGER but an "Operation not
> supported" on the GET.
Yes, but if that was the only thing missing you'd also get -EINVAL.
However, GET only supports dumping, you have to see how to do that,
which explains the -EOPNOTSUPP.
johannes
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Chris Vine @ 2010-08-16 19:41 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: b43-dev, linux-wireless
In-Reply-To: <AANLkTimMhW7OX3DT7A3EDNaOnr577KmTv5w9C_mz19TG@mail.gmail.com>
On Mon, 16 Aug 2010 19:59:36 +0200
Gábor Stefanik <netrolller.3d@gmail.com> wrote:
> Hello Everyone!
>
> If you are experiencing DMA errors on a BCM4312, please test the
> attached patch. It implements the PCI-E SERDES workaround, which the
> hybrid driver is applying during early init to LP-PHY cards, and which
> is a good candidate for the cause of the DMA error.
> Note that this is not a final patch & it may cause collateral damage
> for non-4312 cards; if it helps the 4312 problem, I will submit a
> cleaned-up version.
This applies to 2.6.35.2, but does not compile:
drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_set_block':
drivers/ssb/driver_pcicore.c:457: error: 'i' undeclared (first use in
this function) drivers/ssb/driver_pcicore.c:457: error: (Each
undeclared identifier is reported only once
drivers/ssb/driver_pcicore.c:457: error: for each function it appears
in.) drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_read':
drivers/ssb/driver_pcicore.c:503: error: expected ';' before
'pcicore_write32'
With the obvious fixes (providing a variable 'i' of int type as the
count variable and terminating the line which had no terminating
semi-colon), it compiled OK and the first time I booted up, booted up
OK but didn't fix the DMA error. Subsequent attempts to boot up gave me
a slew of errors on boot up so I am not sure what is going on there.
You might want to check that the obvious fixes to the patch are
complete.
Chris
^ permalink raw reply
* [PATCH 1/4] b43: N-PHY: Implement Host Flags write during device init
From: Gábor Stefanik @ 2010-08-16 20:39 UTC (permalink / raw)
To: John Linville, Michael Büsch
Cc: linux-wireless, b43-dev, Larry Finger, Rafał Miłecki,
Gábor Stefanik
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
drivers/net/wireless/b43/phy_n.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 5a72570..cb815cc 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -1098,7 +1098,8 @@ static void b43_nphy_workarounds(struct b43_wldev *dev)
if (dev->phy.rev < 2) {
if (b43_phy_read(dev, B43_NPHY_RXCTL) & 0x2)
- ; /*TODO: b43_mhf(dev, 2, 0x0010, 0x0010, 3);*/
+ b43_hf_write(dev, b43_hf_read(dev) |
+ B43_HF_MLADVW);
} else if (dev->phy.rev == 2) {
b43_phy_write(dev, B43_NPHY_CRSCHECK2, 0);
b43_phy_write(dev, B43_NPHY_CRSCHECK3, 0);
--
1.6.4.2
^ permalink raw reply related
* [PATCH 2/4] b43: N-PHY: Fix typo in function name (gain_crtl -> gain_ctrl)
From: Gábor Stefanik @ 2010-08-16 20:39 UTC (permalink / raw)
To: John Linville, Michael Büsch
Cc: linux-wireless, b43-dev, Larry Finger, Rafał Miłecki,
Gábor Stefanik
In-Reply-To: <1281991157-1557-1-git-send-email-netrolller.3d@gmail.com>
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
drivers/net/wireless/b43/phy_n.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index cb815cc..f1b5707 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -893,7 +893,7 @@ static void b43_nphy_adjust_lna_gain_table(struct b43_wldev *dev)
}
/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/WorkaroundsGainCtrl */
-static void b43_nphy_gain_crtl_workarounds(struct b43_wldev *dev)
+static void b43_nphy_gain_ctrl_workarounds(struct b43_wldev *dev)
{
struct b43_phy_n *nphy = dev->phy.n;
u8 i, j;
@@ -1094,7 +1094,7 @@ static void b43_nphy_workarounds(struct b43_wldev *dev)
b43_nphy_set_rf_sequence(dev, 0, events1, delays1, 7);
b43_nphy_set_rf_sequence(dev, 1, events2, delays2, 7);
- b43_nphy_gain_crtl_workarounds(dev);
+ b43_nphy_gain_ctrl_workarounds(dev);
if (dev->phy.rev < 2) {
if (b43_phy_read(dev, B43_NPHY_RXCTL) & 0x2)
--
1.6.4.2
^ permalink raw reply related
* [PATCH 3/4] b43: N-PHY: Implement MAC PHY clock set
From: Gábor Stefanik @ 2010-08-16 20:39 UTC (permalink / raw)
To: John Linville, Michael Büsch
Cc: linux-wireless, b43-dev, Larry Finger, Rafał Miłecki,
Gábor Stefanik
In-Reply-To: <1281991157-1557-2-git-send-email-netrolller.3d@gmail.com>
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
drivers/net/wireless/b43/phy_n.c | 13 ++++++++++++-
include/linux/ssb/ssb_regs.h | 1 +
2 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index f1b5707..d2dab55 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -3074,6 +3074,17 @@ static int b43_nphy_cal_rx_iq(struct b43_wldev *dev,
return b43_nphy_rev2_cal_rx_iq(dev, target, type, debug);
}
+/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/MacPhyClkSet */
+static void b43_nphy_mac_phy_clock_set(struct b43_wldev *dev, bool on)
+{
+ u32 tmslow = ssb_read32(dev->dev, SSB_TMSLOW);
+ if (on)
+ tmslow |= SSB_TMSLOW_PHYCLK;
+ else
+ tmslow &= ~SSB_TMSLOW_PHYCLK;
+ ssb_write32(dev->dev, SSB_TMSLOW, tmslow);
+}
+
/*
* Init N-PHY
* http://bcm-v4.sipsolutions.net/802.11/PHY/Init/N
@@ -3174,7 +3185,7 @@ int b43_phy_initn(struct b43_wldev *dev)
b43_phy_write(dev, B43_NPHY_BBCFG, tmp & ~B43_NPHY_BBCFG_RSTCCA);
b43_nphy_bmac_clock_fgc(dev, 0);
- /* TODO N PHY MAC PHY Clock Set with argument 1 */
+ b43_nphy_mac_phy_clock_set(dev, true);
b43_nphy_pa_override(dev, false);
b43_nphy_force_rf_sequence(dev, B43_RFSEQ_RX2TX);
diff --git a/include/linux/ssb/ssb_regs.h b/include/linux/ssb/ssb_regs.h
index a6d5225..b2d4bed 100644
--- a/include/linux/ssb/ssb_regs.h
+++ b/include/linux/ssb/ssb_regs.h
@@ -97,6 +97,7 @@
#define SSB_TMSLOW_RESET 0x00000001 /* Reset */
#define SSB_TMSLOW_REJECT_22 0x00000002 /* Reject (Backplane rev 2.2) */
#define SSB_TMSLOW_REJECT_23 0x00000004 /* Reject (Backplane rev 2.3) */
+#define SSB_TMSLOW_PHYCLK 0x00000010 /* MAC PHY Clock Control Enable */
#define SSB_TMSLOW_CLOCK 0x00010000 /* Clock Enable */
#define SSB_TMSLOW_FGC 0x00020000 /* Force Gated Clocks On */
#define SSB_TMSLOW_PE 0x40000000 /* Power Management Enable */
--
1.6.4.2
^ permalink raw reply related
* [PATCH 4/4] b43: N-PHY: Implement RX core state setting for rev.2 and earlier PHYs
From: Gábor Stefanik @ 2010-08-16 20:39 UTC (permalink / raw)
To: John Linville, Michael Büsch
Cc: linux-wireless, b43-dev, Larry Finger, Rafał Miłecki,
Gábor Stefanik
In-Reply-To: <1281991157-1557-3-git-send-email-netrolller.3d@gmail.com>
Rev.3+ support coming in a later patch.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
drivers/net/wireless/b43/phy_n.c | 40 +++++++++++++++++++++++++++++++++++++-
1 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index d2dab55..92cf8b8 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -3085,6 +3085,44 @@ static void b43_nphy_mac_phy_clock_set(struct b43_wldev *dev, bool on)
ssb_write32(dev->dev, SSB_TMSLOW, tmslow);
}
+/* http://bcm-v4.sipsolutions.net/802.11/PHY/N/RxCoreSetState */
+static void b43_nphy_set_rx_core_state(struct b43_wldev *dev, u8 mask)
+{
+ struct b43_phy *phy = &dev->phy;
+ struct b43_phy_n *nphy = phy->n;
+ u16 buf[16];
+
+ if (0 /* FIXME clk */)
+ return;
+
+ b43_mac_suspend(dev);
+
+ if (nphy->hang_avoid)
+ b43_nphy_stay_in_carrier_search(dev, true);
+
+ b43_phy_maskset(dev, B43_NPHY_RFSEQCA, ~B43_NPHY_RFSEQCA_RXEN,
+ (mask & 0x3) << B43_NPHY_RFSEQCA_RXEN_SHIFT);
+
+ if (maskbits & 0x3 != 0x3) {
+ b43_phy_write(dev, B43_NPHY_HPANT_SWTHRES, 1);
+ if (dev->phy.rev >= 3) {
+ /* TODO */
+ }
+ } else {
+ b43_phy_write(dev, B43_NPHY_HPANT_SWTHRES, 0x1E);
+ if (dev->phy.rev >= 3) {
+ /* TODO */
+ }
+ }
+
+ b43_nphy_force_rf_sequence(dev, B43_RFSEQ_RESET2RX);
+
+ if (nphy->hang_avoid)
+ b43_nphy_stay_in_carrier_search(dev, false);
+
+ b43_mac_enable(dev);
+}
+
/*
* Init N-PHY
* http://bcm-v4.sipsolutions.net/802.11/PHY/Init/N
@@ -3211,7 +3249,7 @@ int b43_phy_initn(struct b43_wldev *dev)
}
if (nphy->phyrxchain != 3)
- ;/* TODO N PHY RX Core Set State with phyrxchain as argument */
+ b43_nphy_set_rx_core_state(dev, nphy->phyrxchain);
if (nphy->mphase_cal_phase_id > 0)
;/* TODO PHY Periodic Calibration Multi-Phase Restart */
--
1.6.4.2
^ permalink raw reply related
* pull request: wireless-2.6 2010-08-16
From: John W. Linville @ 2010-08-16 20:34 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
This group of fixes is intended for 2.6.36. This includes a fix for a
warning backtrace related to pm_qos in ipw2100, a packet injection oops
for ath9k_htc, a connectivity regression for ath9k_htc related to HT
capabilities handling, a scanning regression in wl1251,
a firmware loading error in ath9k_htc, and a patch to disable L0s for
all ath5k cards (causes misc wierdness).
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 3c09e2647b5e1f1f9fd383971468823c2505e1b0:
ctcm: rename READ/WRITE defines to avoid redefinitions (2010-08-12 16:04:23 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
John W. Linville (1):
ipw2100: register pm_qos request before registering pci driver
Maxim Levitsky (1):
ath5k: disable ASPM L0s for all cards
Rajkumar Manoharan (2):
ath9k_htc: fix panic on packet injection using airbase-ng tool.
ath9k_htc: load proper firmware for device ID 7015
Vivek Natarajan (1):
ath9k_htc: Fix disconnect issue in HT40 mode.
Yuri Kululin (1):
wl1251: fix trigger scan timeout usage
drivers/net/wireless/ath/ath5k/base.c | 21 +++++++++++++++++++++
drivers/net/wireless/ath/ath9k/eeprom.h | 1 +
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 7 ++++++-
drivers/net/wireless/ath/ath9k/hif_usb.c | 8 ++------
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 3 ++-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 15 ++++++++++-----
drivers/net/wireless/ath/ath9k/reg.h | 1 +
drivers/net/wireless/ipw2x00/ipw2100.c | 5 +++--
drivers/net/wireless/wl12xx/wl1251_cmd.c | 2 +-
10 files changed, 48 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 0d5de25..373dcfe 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -48,6 +48,7 @@
#include <linux/netdevice.h>
#include <linux/cache.h>
#include <linux/pci.h>
+#include <linux/pci-aspm.h>
#include <linux/ethtool.h>
#include <linux/uaccess.h>
#include <linux/slab.h>
@@ -476,6 +477,26 @@ ath5k_pci_probe(struct pci_dev *pdev,
int ret;
u8 csz;
+ /*
+ * L0s needs to be disabled on all ath5k cards.
+ *
+ * For distributions shipping with CONFIG_PCIEASPM (this will be enabled
+ * by default in the future in 2.6.36) this will also mean both L1 and
+ * L0s will be disabled when a pre 1.1 PCIe device is detected. We do
+ * know L1 works correctly even for all ath5k pre 1.1 PCIe devices
+ * though but cannot currently undue the effect of a blacklist, for
+ * details you can read pcie_aspm_sanity_check() and see how it adjusts
+ * the device link capability.
+ *
+ * It may be possible in the future to implement some PCI API to allow
+ * drivers to override blacklists for pre 1.1 PCIe but for now it is
+ * best to accept that both L0s and L1 will be disabled completely for
+ * distributions shipping with CONFIG_PCIEASPM rather than having this
+ * issue present. Motivation for adding this new API will be to help
+ * with power consumption for some of these devices.
+ */
+ pci_disable_link_state(pdev, PCIE_LINK_STATE_L0S);
+
ret = pci_enable_device(pdev);
if (ret) {
dev_err(&pdev->dev, "can't enable device\n");
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index 8750c55..7f48df1 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -191,6 +191,7 @@
#define AR9287_EEP_NO_BACK_VER AR9287_EEP_MINOR_VER_1
#define AR9287_EEP_START_LOC 128
+#define AR9287_HTC_EEP_START_LOC 256
#define AR9287_NUM_2G_CAL_PIERS 3
#define AR9287_NUM_2G_CCK_TARGET_POWERS 3
#define AR9287_NUM_2G_20_TARGET_POWERS 3
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_9287.c b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
index 4a52cf0..dff2da7 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_9287.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_9287.c
@@ -34,9 +34,14 @@ static bool ath9k_hw_ar9287_fill_eeprom(struct ath_hw *ah)
struct ar9287_eeprom *eep = &ah->eeprom.map9287;
struct ath_common *common = ath9k_hw_common(ah);
u16 *eep_data;
- int addr, eep_start_loc = AR9287_EEP_START_LOC;
+ int addr, eep_start_loc;
eep_data = (u16 *)eep;
+ if (ah->hw_version.devid == 0x7015)
+ eep_start_loc = AR9287_HTC_EEP_START_LOC;
+ else
+ eep_start_loc = AR9287_EEP_START_LOC;
+
if (!ath9k_hw_use_flash(ah)) {
ath_print(common, ATH_DBG_EEPROM,
"Reading from EEPROM, not flash\n");
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 61c1bee..17e7a9a 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -799,7 +799,7 @@ static int ath9k_hif_usb_download_fw(struct hif_device_usb *hif_dev)
}
kfree(buf);
- if (hif_dev->device_id == 0x7010)
+ if ((hif_dev->device_id == 0x7010) || (hif_dev->device_id == 0x7015))
firm_offset = AR7010_FIRMWARE_TEXT;
else
firm_offset = AR9271_FIRMWARE_TEXT;
@@ -901,6 +901,7 @@ static int ath9k_hif_usb_probe(struct usb_interface *interface,
switch(hif_dev->device_id) {
case 0x7010:
+ case 0x7015:
case 0x9018:
if (le16_to_cpu(udev->descriptor.bcdDevice) == 0x0202)
hif_dev->fw_name = FIRMWARE_AR7010_1_1;
@@ -912,11 +913,6 @@ static int ath9k_hif_usb_probe(struct usb_interface *interface,
break;
}
- if (!hif_dev->fw_name) {
- dev_err(&udev->dev, "Can't determine firmware !\n");
- goto err_htc_hw_alloc;
- }
-
ret = ath9k_hif_usb_dev_init(hif_dev);
if (ret) {
ret = -EINVAL;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 148b433..2d42791 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -245,6 +245,7 @@ static int ath9k_init_htc_services(struct ath9k_htc_priv *priv, u16 devid)
switch(devid) {
case 0x7010:
+ case 0x7015:
case 0x9018:
priv->htc->credits = 45;
break;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index ebed9d1..7d09b4b 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -366,7 +366,8 @@ static void ath9k_htc_setup_rate(struct ath9k_htc_priv *priv,
caps = WLAN_RC_HT_FLAG;
if (sta->ht_cap.mcs.rx_mask[1])
caps |= WLAN_RC_DS_FLAG;
- if (sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40)
+ if ((sta->ht_cap.cap & IEEE80211_HT_CAP_SUP_WIDTH_20_40) &&
+ (conf_is_ht40(&priv->hw->conf)))
caps |= WLAN_RC_40_FLAG;
if (conf_is_ht40(&priv->hw->conf) &&
(sta->ht_cap.cap & IEEE80211_HT_CAP_SGI_40))
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index bd0b4ac..2a6e45a 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -78,18 +78,23 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ieee80211_sta *sta = tx_info->control.sta;
struct ath9k_htc_sta *ista;
- struct ath9k_htc_vif *avp;
struct ath9k_htc_tx_ctl tx_ctl;
enum htc_endpoint_id epid;
u16 qnum;
__le16 fc;
u8 *tx_fhdr;
- u8 sta_idx;
+ u8 sta_idx, vif_idx;
hdr = (struct ieee80211_hdr *) skb->data;
fc = hdr->frame_control;
- avp = (struct ath9k_htc_vif *) tx_info->control.vif->drv_priv;
+ if (tx_info->control.vif &&
+ (struct ath9k_htc_vif *) tx_info->control.vif->drv_priv)
+ vif_idx = ((struct ath9k_htc_vif *)
+ tx_info->control.vif->drv_priv)->index;
+ else
+ vif_idx = priv->nvifs;
+
if (sta) {
ista = (struct ath9k_htc_sta *) sta->drv_priv;
sta_idx = ista->index;
@@ -106,7 +111,7 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
memset(&tx_hdr, 0, sizeof(struct tx_frame_hdr));
tx_hdr.node_idx = sta_idx;
- tx_hdr.vif_idx = avp->index;
+ tx_hdr.vif_idx = vif_idx;
if (tx_info->flags & IEEE80211_TX_CTL_AMPDU) {
tx_ctl.type = ATH9K_HTC_AMPDU;
@@ -169,7 +174,7 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
tx_ctl.type = ATH9K_HTC_NORMAL;
mgmt_hdr.node_idx = sta_idx;
- mgmt_hdr.vif_idx = avp->index;
+ mgmt_hdr.vif_idx = vif_idx;
mgmt_hdr.tidno = 0;
mgmt_hdr.flags = 0;
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index 633e3d9..d01c4ad 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -899,6 +899,7 @@
#define AR_DEVID_7010(_ah) \
(((_ah)->hw_version.devid == 0x7010) || \
+ ((_ah)->hw_version.devid == 0x7015) || \
((_ah)->hw_version.devid == 0x9018))
#define AR_RADIO_SREV_MAJOR 0xf0
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
index 16bbfa3..1189dbb 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -6665,12 +6665,13 @@ static int __init ipw2100_init(void)
printk(KERN_INFO DRV_NAME ": %s, %s\n", DRV_DESCRIPTION, DRV_VERSION);
printk(KERN_INFO DRV_NAME ": %s\n", DRV_COPYRIGHT);
+ pm_qos_add_request(&ipw2100_pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
+ PM_QOS_DEFAULT_VALUE);
+
ret = pci_register_driver(&ipw2100_pci_driver);
if (ret)
goto out;
- pm_qos_add_request(&ipw2100_pm_qos_req, PM_QOS_CPU_DMA_LATENCY,
- PM_QOS_DEFAULT_VALUE);
#ifdef CONFIG_IPW2100_DEBUG
ipw2100_debug_level = debug;
ret = driver_create_file(&ipw2100_pci_driver.driver,
diff --git a/drivers/net/wireless/wl12xx/wl1251_cmd.c b/drivers/net/wireless/wl12xx/wl1251_cmd.c
index a37b30c..ce3722f 100644
--- a/drivers/net/wireless/wl12xx/wl1251_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1251_cmd.c
@@ -484,7 +484,7 @@ int wl1251_cmd_trigger_scan_to(struct wl1251 *wl, u32 timeout)
cmd->timeout = timeout;
- ret = wl1251_cmd_send(wl, CMD_SCAN, cmd, sizeof(*cmd));
+ ret = wl1251_cmd_send(wl, CMD_TRIGGER_SCAN_TO, cmd, sizeof(*cmd));
if (ret < 0) {
wl1251_error("cmd trigger scan to failed: %d", ret);
goto out;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 4/4] b43: N-PHY: Implement RX core state setting for rev.2 and earlier PHYs
From: Michael Büsch @ 2010-08-16 20:47 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, linux-wireless, b43-dev, Larry Finger,
Rafał Miłecki
In-Reply-To: <1281991157-1557-4-git-send-email-netrolller.3d@gmail.com>
On 08/16/2010 10:39 PM, Gábor Stefanik wrote:
> +static void b43_nphy_set_rx_core_state(struct b43_wldev *dev, u8 mask)
> +{
> + struct b43_phy *phy =&dev->phy;
> + struct b43_phy_n *nphy = phy->n;
> + u16 buf[16];
> + if (maskbits& 0x3 != 0x3) {
Does this even compile? I don't see maskbits being defined.
--
Greetings Michael.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-08-16
From: David Miller @ 2010-08-16 20:56 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100816203440.GG2656@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 16 Aug 2010 16:34:41 -0400
> This group of fixes is intended for 2.6.36. This includes a fix for a
> warning backtrace related to pm_qos in ipw2100, a packet injection oops
> for ath9k_htc, a connectivity regression for ath9k_htc related to HT
> capabilities handling, a scanning regression in wl1251,
> a firmware loading error in ath9k_htc, and a patch to disable L0s for
> all ath5k cards (causes misc wierdness).
Pulled, thanks a lot John.
^ permalink raw reply
* Re: nl80211 scanning from userspace
From: Christopher Piggott @ 2010-08-16 21:22 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1281987696.3683.32.camel@jlt3.sipsolutions.net>
It's hard to figure out what's going on sometimes. I set up an error handler:
static int error_handler(struct sockaddr_nl *nla, struct nlmsgerr
*err, void *arg) {
printf("ERROR %s (%d)\n", strerror(err->error), err->error);
return NL_SKIP;
}
which also returns -95 (operation not supported) just as you said.
So, I'll have to figure out what you mean by "dumping."
I did find this:
mcid = nl_get_multicast_id(state->nl_sock, "nl80211", "scan");
in iw:event.c and traced it to some code in iw:genl.c, a file that
starts out by commenting "This ought to be provided by libnl". That
situation doesn't seem to have changed.
Is this the area of the code you mean when you say "dump" ? That I
need to register myself to receive the scan results?
--C
^ permalink raw reply
* Re: nl80211 scanning from userspace
From: Johannes Berg @ 2010-08-16 21:43 UTC (permalink / raw)
To: Christopher Piggott; +Cc: linux-wireless
In-Reply-To: <AANLkTi=ALaGb=UcWAuB_N8E9j95f0Hgxtw0Dhh7xaPh2@mail.gmail.com>
On Mon, 2010-08-16 at 17:22 -0400, Christopher Piggott wrote:
> It's hard to figure out what's going on sometimes. I set up an error handler:
>
> static int error_handler(struct sockaddr_nl *nla, struct nlmsgerr
> *err, void *arg) {
> printf("ERROR %s (%d)\n", strerror(err->error), err->error);
> return NL_SKIP;
> }
>
> which also returns -95 (operation not supported) just as you said.
> So, I'll have to figure out what you mean by "dumping."
>
> I did find this:
>
> mcid = nl_get_multicast_id(state->nl_sock, "nl80211", "scan");
>
> in iw:event.c and traced it to some code in iw:genl.c, a file that
> starts out by commenting "This ought to be provided by libnl". That
> situation doesn't seem to have changed.
>
> Is this the area of the code you mean when you say "dump" ? That I
> need to register myself to receive the scan results?
No, you need to use NLM_F_DUMP etc. Really, check wpa_supplicant :)
johannes
^ permalink raw reply
* Re: nl80211 scanning from userspace
From: Christopher Piggott @ 2010-08-16 21:55 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1281995025.3683.34.camel@jlt3.sipsolutions.net>
OHHH. I am with you now. I looked at driver_nl80211.c and somehow
had a blind spot when it came to message NLM_F_DUMP. I see it now,
and it's sending me back results.
I am tempted to write a slightly higher level API on top of some of
this, once I understand the semantics of all of this a little better.
I will search around first and see if any attempts have already been
made.
Thank you very much for pushing me in the right direction.
--Chris
On Mon, Aug 16, 2010 at 5:43 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2010-08-16 at 17:22 -0400, Christopher Piggott wrote:
>> It's hard to figure out what's going on sometimes. I set up an error handler:
>>
>> static int error_handler(struct sockaddr_nl *nla, struct nlmsgerr
>> *err, void *arg) {
>> printf("ERROR %s (%d)\n", strerror(err->error), err->error);
>> return NL_SKIP;
>> }
>>
>> which also returns -95 (operation not supported) just as you said.
>> So, I'll have to figure out what you mean by "dumping."
>>
>> I did find this:
>>
>> mcid = nl_get_multicast_id(state->nl_sock, "nl80211", "scan");
>>
>> in iw:event.c and traced it to some code in iw:genl.c, a file that
>> starts out by commenting "This ought to be provided by libnl". That
>> situation doesn't seem to have changed.
>>
>> Is this the area of the code you mean when you say "dump" ? That I
>> need to register myself to receive the scan results?
>
> No, you need to use NLM_F_DUMP etc. Really, check wpa_supplicant :)
>
> johannes
>
>
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Chris Vine @ 2010-08-16 22:35 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linux-wireless, b43-dev
In-Reply-To: <20100816204154.5100b604@boulder.homenet>
On Mon, 16 Aug 2010 20:41:54 +0100
Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> On Mon, 16 Aug 2010 19:59:36 +0200
> Gábor Stefanik <netrolller.3d@gmail.com> wrote:
> > Hello Everyone!
> >
> > If you are experiencing DMA errors on a BCM4312, please test the
> > attached patch. It implements the PCI-E SERDES workaround, which the
> > hybrid driver is applying during early init to LP-PHY cards, and
> > which is a good candidate for the cause of the DMA error.
> > Note that this is not a final patch & it may cause collateral damage
> > for non-4312 cards; if it helps the 4312 problem, I will submit a
> > cleaned-up version.
>
> This applies to 2.6.35.2, but does not compile:
>
> drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_set_block':
> drivers/ssb/driver_pcicore.c:457: error: 'i' undeclared (first use in
> this function) drivers/ssb/driver_pcicore.c:457: error: (Each
> undeclared identifier is reported only once
> drivers/ssb/driver_pcicore.c:457: error: for each function it appears
> in.) drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_read':
> drivers/ssb/driver_pcicore.c:503: error: expected ';' before
> 'pcicore_write32'
>
> With the obvious fixes (providing a variable 'i' of int type as the
> count variable and terminating the line which had no terminating
> semi-colon), it compiled OK and the first time I booted up, booted up
> OK but didn't fix the DMA error. Subsequent attempts to boot up gave
> me a slew of errors on boot up so I am not sure what is going on
> there.
>
> You might want to check that the obvious fixes to the patch are
> complete.
I have more or less tracked down what is happening.
The first thing to report is that this does not fix the DMA error.
The second thing is that with the patch applied, and with _all_
wireless/ssb modules blacklisted (ssb, b43, wl), if the wl module is
present the kernel bizarrely still tries to load it on boot up and
shortly thereafter hangs with a number of errors reported, which differ
on different boots (there is no particular pattern to them). That in
turn causes some file system corruption which affects further boots
even if the wl module is removed. The corruption is not that serious
and appears only to affect the kernel image and/or the wl module.
Reinstalling both solved the problem, so far. ef2fsck -f only reported
that the time stamps were wrong, but inodes and directory structures
were reported as OK.
But caveat testor so far as the corruption is concerned. I might have
been lucky.
Chris
^ permalink raw reply
* Re: [PATCH] compat-wireless: make patches apply again.
From: Luis R. Rodriguez @ 2010-08-16 22:49 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof
In-Reply-To: <1281875290-8821-1-git-send-email-hauke@hauke-m.de>
On Sun, Aug 15, 2010 at 5:28 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Thanks, applied!
Luis
^ permalink raw reply
* Re: nl80211 scanning from userspace
From: Christopher Piggott @ 2010-08-16 23:16 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <AANLkTi=sb0PT4FHsjbuAOQjnDq79GHEj8LbCLTtO8MeS@mail.gmail.com>
Forgive me if this is an obtuse question but why would one use
nl_socket_add_membership, if all that isn't necessary to get back the
scan results?
On Mon, Aug 16, 2010 at 5:55 PM, Christopher Piggott <cpiggott@gmail.com> wrote:
> OHHH. I am with you now. I looked at driver_nl80211.c and somehow
> had a blind spot when it came to message NLM_F_DUMP. I see it now,
> and it's sending me back results.
>
> I am tempted to write a slightly higher level API on top of some of
> this, once I understand the semantics of all of this a little better.
> I will search around first and see if any attempts have already been
> made.
>
> Thank you very much for pushing me in the right direction.
>
> --Chris
>
>
> On Mon, Aug 16, 2010 at 5:43 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Mon, 2010-08-16 at 17:22 -0400, Christopher Piggott wrote:
>>> It's hard to figure out what's going on sometimes. I set up an error handler:
>>>
>>> static int error_handler(struct sockaddr_nl *nla, struct nlmsgerr
>>> *err, void *arg) {
>>> printf("ERROR %s (%d)\n", strerror(err->error), err->error);
>>> return NL_SKIP;
>>> }
>>>
>>> which also returns -95 (operation not supported) just as you said.
>>> So, I'll have to figure out what you mean by "dumping."
>>>
>>> I did find this:
>>>
>>> mcid = nl_get_multicast_id(state->nl_sock, "nl80211", "scan");
>>>
>>> in iw:event.c and traced it to some code in iw:genl.c, a file that
>>> starts out by commenting "This ought to be provided by libnl". That
>>> situation doesn't seem to have changed.
>>>
>>> Is this the area of the code you mean when you say "dump" ? That I
>>> need to register myself to receive the scan results?
>>
>> No, you need to use NLM_F_DUMP etc. Really, check wpa_supplicant :)
>>
>> johannes
>>
>>
>
^ permalink raw reply
* [PATCH 1/2] p54spi: fix eeprom checksum
From: Christian Lamparter @ 2010-08-16 23:16 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
This patch corrects the bogus descriptor checksum of our
Nokia N8XX EEPROM blob.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/drivers/net/wireless/p54/p54spi_eeprom.h b/drivers/net/wireless/p54/p54spi_eeprom.h
index 1ea1050..d592cbd 100644
--- a/drivers/net/wireless/p54/p54spi_eeprom.h
+++ b/drivers/net/wireless/p54/p54spi_eeprom.h
@@ -671,7 +671,7 @@ static unsigned char p54spi_eeprom[] = {
0xa8, 0x09, 0x25, 0x00, 0xf5, 0xff, 0xf9, 0xff, 0x00, 0x01,
0x02, 0x00, 0x00, 0x00, /* PDR_END */
- 0xa8, 0xf5 /* bogus data */
+ 0x67, 0x99,
};
#endif /* P54SPI_EEPROM_H */
^ permalink raw reply related
* [PATCH 2/2] p54: improve eeprom parser
From: Christian Lamparter @ 2010-08-16 23:16 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
Like other vendors, p54* devices have a checksum for
the EEPROM descriptor data. This patch enhances the
parser code to generate and verify the data fields,
before initializing the radio-chip on the card.
Note:
If you have to bootstrap an alternative EEPROM image
for your device and you don't know how to generate a
valid crc ccitt checksum, you should take a look at:
http://git.kernel.org/?p=linux/kernel/git/chr/p54tools.git
The "checksum" utility loads a binary p54 EEPROM blob
(use the -f switch, to skip the check) and applies
the correct crc automatically.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/drivers/net/wireless/p54/Kconfig b/drivers/net/wireless/p54/Kconfig
index b0342a5..60a930e 100644
--- a/drivers/net/wireless/p54/Kconfig
+++ b/drivers/net/wireless/p54/Kconfig
@@ -2,6 +2,7 @@ config P54_COMMON
tristate "Softmac Prism54 support"
depends on MAC80211 && EXPERIMENTAL
select FW_LOADER
+ select CRC_CCITT
---help---
This is common code for isl38xx/stlc45xx based modules.
This module does nothing by itself - the USB/PCI/SPI front-ends
diff --git a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
index d687cb7..32d3f99 100644
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -23,6 +23,7 @@
#include <linux/slab.h>
#include <net/mac80211.h>
+#include <linux/crc-ccitt.h>
#include "p54.h"
#include "eeprom.h"
@@ -540,6 +541,7 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
int err;
u8 *end = (u8 *)eeprom + len;
u16 synth = 0;
+ u16 crc16 = ~0;
wrap = (struct eeprom_pda_wrap *) eeprom;
entry = (void *)wrap->data + le16_to_cpu(wrap->len);
@@ -655,16 +657,29 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
}
break;
case PDR_END:
- /* make it overrun */
- entry_len = len;
+ crc16 = ~crc_ccitt(crc16, (u8 *) entry, sizeof(*entry));
+ if (crc16 != le16_to_cpup((__le16 *)entry->data)) {
+ wiphy_err(dev->wiphy, "eeprom failed checksum "
+ "test!\n");
+ err = -ENOMSG;
+ goto err;
+ } else {
+ goto good_eeprom;
+ }
break;
default:
break;
}
- entry = (void *)entry + (entry_len + 1)*2;
+ crc16 = crc_ccitt(crc16, (u8 *)entry, (entry_len + 1) * 2);
+ entry = (void *)entry + (entry_len + 1) * 2;
}
+ wiphy_err(dev->wiphy, "unexpected end of eeprom data.\n");
+ err = -ENODATA;
+ goto err;
+
+good_eeprom:
if (!synth || !priv->iq_autocal || !priv->output_limit ||
!priv->curve_data) {
wiphy_err(dev->wiphy,
^ permalink raw reply related
* Re: [PATCH 2/2] p54: improve eeprom parser
From: Larry Finger @ 2010-08-16 23:51 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John W. Linville
In-Reply-To: <201008170116.58759.chunkeey@googlemail.com>
On 08/16/2010 06:16 PM, Christian Lamparter wrote:
> Like other vendors, p54* devices have a checksum for
> the EEPROM descriptor data. This patch enhances the
> parser code to generate and verify the data fields,
> before initializing the radio-chip on the card.
>
> Note:
> If you have to bootstrap an alternative EEPROM image
> for your device and you don't know how to generate a
> valid crc ccitt checksum, you should take a look at:
> http://git.kernel.org/?p=linux/kernel/git/chr/p54tools.git
>
> The "checksum" utility loads a binary p54 EEPROM blob
> (use the -f switch, to skip the check) and applies
> the correct crc automatically.
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
ACK for p54usb.
Larry
^ permalink raw reply
* Re: [RFT] BCM4312 users with DMA errors, please test!
From: Larry Finger @ 2010-08-16 23:53 UTC (permalink / raw)
To: Chris Vine; +Cc: Gábor Stefanik, linux-wireless, b43-dev
In-Reply-To: <20100816233544.40f0e1d4@boulder.homenet>
On 08/16/2010 05:35 PM, Chris Vine wrote:
> On Mon, 16 Aug 2010 20:41:54 +0100
> Chris Vine <chris@cvine.freeserve.co.uk> wrote:
>
>> On Mon, 16 Aug 2010 19:59:36 +0200
>> Gábor Stefanik <netrolller.3d@gmail.com> wrote:
>>> Hello Everyone!
>>>
>>> If you are experiencing DMA errors on a BCM4312, please test the
>>> attached patch. It implements the PCI-E SERDES workaround, which the
>>> hybrid driver is applying during early init to LP-PHY cards, and
>>> which is a good candidate for the cause of the DMA error.
>>> Note that this is not a final patch & it may cause collateral damage
>>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>>> cleaned-up version.
>>
>> This applies to 2.6.35.2, but does not compile:
>>
>> drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_set_block':
>> drivers/ssb/driver_pcicore.c:457: error: 'i' undeclared (first use in
>> this function) drivers/ssb/driver_pcicore.c:457: error: (Each
>> undeclared identifier is reported only once
>> drivers/ssb/driver_pcicore.c:457: error: for each function it appears
>> in.) drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_read':
>> drivers/ssb/driver_pcicore.c:503: error: expected ';' before
>> 'pcicore_write32'
>>
>> With the obvious fixes (providing a variable 'i' of int type as the
>> count variable and terminating the line which had no terminating
>> semi-colon), it compiled OK and the first time I booted up, booted up
>> OK but didn't fix the DMA error. Subsequent attempts to boot up gave
>> me a slew of errors on boot up so I am not sure what is going on
>> there.
>>
>> You might want to check that the obvious fixes to the patch are
>> complete.
>
> I have more or less tracked down what is happening.
>
> The first thing to report is that this does not fix the DMA error.
>
> The second thing is that with the patch applied, and with _all_
> wireless/ssb modules blacklisted (ssb, b43, wl), if the wl module is
> present the kernel bizarrely still tries to load it on boot up and
> shortly thereafter hangs with a number of errors reported, which differ
> on different boots (there is no particular pattern to them). That in
> turn causes some file system corruption which affects further boots
> even if the wl module is removed. The corruption is not that serious
> and appears only to affect the kernel image and/or the wl module.
> Reinstalling both solved the problem, so far. ef2fsck -f only reported
> that the time stamps were wrong, but inodes and directory structures
> were reported as OK.
>
> But caveat testor so far as the corruption is concerned. I might have
> been lucky.
I tried to duplicate your boot problems without anything unexpected happening.
I don't know what happened, but I doubt that this ssb patch was responsible.
Larry
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox