* RE: [PATCH v7] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-07-19 7:25 UTC (permalink / raw)
To: Kalle Valo, Eyal Reizer
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-spi@vger.kernel.org, robh@kernel.org
In-Reply-To: <87poqaum6t.fsf@kamboji.qca.qualcomm.com>
> > From: Eyal Reizer <eyalreizer@gmail.com>
> >
> > Add support for using with both wl12xx and wl18xx.
> >
> > - all wilink family needs special init command for entering wspi mode.
> > extra clock cycles should be sent after the spi init command while the
> > cs pin is high.
> > - Use inverted chip select for sending a dummy 4 bytes command that
> > completes the init stage.
> >
> > Signed-off-by: Eyal Reizer <eyalr@ti.com>
> > Acked-by: Rob Herring <robh@kernel.org>
>
> This looks ok in patchwork:
>
> https://patchwork.kernel.org/patch/9235983/
>
> Because you used ti.com in S-o-b I assume From should also use ti.com. I can
> fix that before I apply but please confirm that's really the case?
>
Yes, S-o-b is eyalr@ti.com.
Thank you!
--
Eyal Reizer
^ permalink raw reply
* Re: [PATCH v7] wlcore: spi: add wl18xx support
From: Kalle Valo @ 2016-07-19 7:22 UTC (permalink / raw)
To: Eyal Reizer
Cc: linux-wireless, netdev, linux-kernel, devicetree, linux-spi, robh,
Eyal Reizer
In-Reply-To: <1468911482-32560-1-git-send-email-eyalr@ti.com>
Eyal Reizer <eyalreizer@gmail.com> writes:
> From: Eyal Reizer <eyalreizer@gmail.com>
>
> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
> extra clock cycles should be sent after the spi init command while the
> cs pin is high.
> - Use inverted chip select for sending a dummy 4 bytes command that
> completes the init stage.
>
> Signed-off-by: Eyal Reizer <eyalr@ti.com>
> Acked-by: Rob Herring <robh@kernel.org>
This looks ok in patchwork:
https://patchwork.kernel.org/patch/9235983/
Because you used ti.com in S-o-b I assume From should also use ti.com. I
can fix that before I apply but please confirm that's really the case?
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Rafał Miłecki @ 2016-07-19 7:11 UTC (permalink / raw)
To: Kalle Valo
Cc: Brian Norris, linux-mtd@lists.infradead.org, Stephen Rothwell,
linux-wireless@vger.kernel.org, linux-next,
Linux Kernel Mailing List
In-Reply-To: <871t2qw1cz.fsf@kamboji.qca.qualcomm.com>
On 19 July 2016 at 09:09, Kalle Valo <kvalo@codeaurora.org> wrote:
> Rafał Miłecki <zajec5@gmail.com> writes:
>
>> On 19 July 2016 at 08:30, Kalle Valo <kvalo@codeaurora.org> wrote:
>>> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>>>
>>>> After merging the wireless-drivers-next tree, today's linux-next build
>>>> (powerpc allyesconfig) failed like this:
>>>>
>>>> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>>>> drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>>>> b47s->window = ioremap_cache(res->start, resource_size(res));
>>>> ^
>>>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>>>> b47s->window = ioremap_cache(res->start, resource_size(res));
>>>> ^
>>>>
>>>> Caused by commit
>>>>
>>>> 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>>>>
>>>> I have reverted that commit for today.
>>>
>>> Thanks, kbuild bot also notified about this.
>>>
>>> Rafał, as the merge window is getting really close I would like to
>>> revert this for now and we can reapply it once we the problem is fully
>>> solved. And we can use my pending branch for build testing the patch
>>> with kbuild bot. What do you think?
>>
>> The simplest fix sounds pretty much as simple as the revert.
>
> The problem is that I don't have much time, I need to send the pull
> request to Dave within next few days. The fix might create other
> problems so I'm not enthusiastic about iterating with this patch at the
> moment. I think it can wait for 4.9.
I sent a patch seconds ago, you may just take a look at it. If you
still prefer to revert my commit, go ahead.
--
Rafał
^ permalink raw reply
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Kalle Valo @ 2016-07-19 7:09 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Brian Norris, linux-mtd@lists.infradead.org, Stephen Rothwell,
linux-wireless@vger.kernel.org, linux-next,
Linux Kernel Mailing List
In-Reply-To: <CACna6rxVFD1MpAEYP_Zd4W8CvgnxSQpa0wJs83jwDJ5v11gZ=Q@mail.gmail.com>
Rafał Miłecki <zajec5@gmail.com> writes:
> On 19 July 2016 at 08:30, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>>
>>> After merging the wireless-drivers-next tree, today's linux-next build
>>> (powerpc allyesconfig) failed like this:
>>>
>>> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>>> drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>>> b47s->window = ioremap_cache(res->start, resource_size(res));
>>> ^
>>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>>> b47s->window = ioremap_cache(res->start, resource_size(res));
>>> ^
>>>
>>> Caused by commit
>>>
>>> 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>>>
>>> I have reverted that commit for today.
>>
>> Thanks, kbuild bot also notified about this.
>>
>> Rafał, as the merge window is getting really close I would like to
>> revert this for now and we can reapply it once we the problem is fully
>> solved. And we can use my pending branch for build testing the patch
>> with kbuild bot. What do you think?
>
> The simplest fix sounds pretty much as simple as the revert.
The problem is that I don't have much time, I need to send the pull
request to Dave within next few days. The fix might create other
problems so I'm not enthusiastic about iterating with this patch at the
moment. I think it can wait for 4.9.
--
Kalle Valo
^ permalink raw reply
* [PATCH] mtd: add arch dependency for MTD_BCM47XXSFLASH symbol
From: Rafał Miłecki @ 2016-07-19 7:08 UTC (permalink / raw)
To: Kalle Valo, linux-wireless
Cc: Rafał Miłecki, Brian Norris, David Woodhouse,
open list:MEMORY TECHNOLOGY DEVICES (MTD), open list
We dropped strict MIPS dependency for bcm47xxsflash driver in:
commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of
KSEG0ADDR()") but using ioremap_cache still limits building it to few
selected architectures only.
A recent commit 57d8f7dd2132 ("bcma: allow enabling serial flash support
on non-MIPS SoCs") automatically dropped MIPS dependency for
MTD_BCM47XXSFLASH which broke building e.g. on powerpc and cris.
The bcma change is alright as it doesn't break building bcma code in any
way. MTD_BCM47XXSFLASH on the other hand should be limited to archs
which need it and can build it (by providing ioremap_cache).
Fixes: 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Cc: Brian Norris <computersforpeace@gmail.com>
---
That bcma commit breaking building landed in the wireless-drivers-next.
Is that possible to get this patch through the same tree?
---
drivers/mtd/devices/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index f73c416..64a2485 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -114,7 +114,7 @@ config MTD_SST25L
config MTD_BCM47XXSFLASH
tristate "R/O support for serial flash on BCMA bus"
- depends on BCMA_SFLASH
+ depends on BCMA_SFLASH && (MIPS || ARM)
help
BCMA bus can have various flash memories attached, they are
registered by bcma as platform devices. This enables driver for
--
1.8.4.5
^ permalink raw reply related
* [PATCH v7] wlcore: spi: add wl18xx support
From: Eyal Reizer @ 2016-07-19 6:58 UTC (permalink / raw)
To: kvalo, linux-wireless, netdev, linux-kernel, devicetree,
linux-spi, robh
Cc: Eyal Reizer, Eyal Reizer
From: Eyal Reizer <eyalreizer@gmail.com>
Add support for using with both wl12xx and wl18xx.
- all wilink family needs special init command for entering wspi mode.
extra clock cycles should be sent after the spi init command while the
cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
completes the init stage.
Signed-off-by: Eyal Reizer <eyalr@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select instead
for sending the extra init cycle which, achieves the same hardware purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip select
number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next
v5->v6: Add ACKs
v6->v7: Mail format issues
.../bindings/net/wireless/ti,wlcore,spi.txt | 41 +++++--
drivers/net/wireless/ti/wlcore/spi.c | 123 ++++++++++++++++++---
2 files changed, 137 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
document describes the binding for the SPI connected chip.
Required properties:
-- compatible : Should be "ti,wl1271"
+- compatible : Should be one of the following:
+ * "ti,wl1271"
+ * "ti,wl1273"
+ * "ti,wl1281"
+ * "ti,wl1283"
+ * "ti,wl1801"
+ * "ti,wl1805"
+ * "ti,wl1807"
+ * "ti,wl1831"
+ * "ti,wl1835"
+ * "ti,wl1837"
- reg : Chip select address of device
- spi-max-frequency : Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
- interrupt-parent, interrupts :
Should contain parameters for 1 interrupt line.
Interrupt parameters: parent, line number, type.
-- vwlan-supply : Point the node of the regulator that powers/enable the wl1271 chip
+- vwlan-supply : Point the node of the regulator that powers/enable the
+ wl12xx/wl18xx chip
Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for wl12xx)
- clock-xtal : boolean, clock is generated from XTAL
- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:
Examples:
+For wl12xx family:
&spi1 {
- wl1271@1 {
+ wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <48000000>;
- clock-xtal;
- ref-clock-frequency = <38400000>;
interrupt-parent = <&gpio3>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <&vwlan_fixed>;
+ clock-xtal;
+ ref-clock-frequency = <38400000>;
+ };
+};
+
+For wl18xx family:
+&spi0 {
+ wlcore: wlcore@0 {
+ compatible = "ti,wl1835";
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ vwlan-supply = <&vwlan_fixed>;
};
};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..73fbcf1 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
#define WSPI_MAX_CHUNK_SIZE 4092
/*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for wl18xx
*/
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
/* Maximum number of SPI write chunks */
#define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
+struct wilink_familiy_data {
+ char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+ .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+ .name = "wl12xx",
+};
+
struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+ struct spi_device *spi = to_spi_device(glue->dev);
u8 *cmd = kzalloc(WSPI_INIT_CMD_LEN, GFP_KERNEL);
if (!cmd) {
@@ -151,6 +166,7 @@ static void wl12xx_spi_init(struct device *child)
cmd[6] |= WSPI_INIT_CMD_EN_FIXEDBUSY;
cmd[7] = crc7_be(0, cmd+2, WSPI_INIT_CMD_CRC_LEN) | WSPI_INIT_CMD_END;
+
/*
* The above is the logical order; it must actually be stored
* in the buffer byte-swapped.
@@ -163,6 +179,28 @@ static void wl12xx_spi_init(struct device *child)
spi_message_add_tail(&t, &m);
spi_sync(to_spi_device(glue->dev), &m);
+
+ /* Send extra clocks with inverted CS (high). this is required
+ * by the wilink family in order to successfully enter WSPI mode.
+ */
+ spi->mode ^= SPI_CS_HIGH;
+ memset(&m, 0, sizeof(m));
+ spi_message_init(&m);
+
+ cmd[0] = 0xff;
+ cmd[1] = 0xff;
+ cmd[2] = 0xff;
+ cmd[3] = 0xff;
+ __swab32s((u32 *)cmd);
+
+ t.tx_buf = cmd;
+ t.len = 4;
+ spi_message_add_tail(&t, &m);
+
+ spi_sync(to_spi_device(glue->dev), &m);
+
+ /* Restore chip select configration to normal */
+ spi->mode ^= SPI_CS_HIGH;
kfree(cmd);
}
@@ -270,22 +308,25 @@ static int __must_check wl12xx_spi_raw_read(struct device *child, int addr,
return 0;
}
-static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
- void *buf, size_t len, bool fixed)
+static int __wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed)
{
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
- /* SPI write buffers - 2 for each chunk */
- struct spi_transfer t[2 * WSPI_MAX_NUM_OF_CHUNKS];
+ struct spi_transfer *t;
struct spi_message m;
u32 commands[WSPI_MAX_NUM_OF_CHUNKS]; /* 1 command per chunk */
u32 *cmd;
u32 chunk_len;
int i;
+ /* SPI write buffers - 2 for each chunk */
+ t = kzalloc(sizeof(*t) * 2 * WSPI_MAX_NUM_OF_CHUNKS, GFP_KERNEL);
+ if (!t)
+ return -ENOMEM;
+
WARN_ON(len > SPI_AGGR_BUFFER_SIZE);
spi_message_init(&m);
- memset(t, 0, sizeof(t));
cmd = &commands[0];
i = 0;
@@ -318,9 +359,26 @@ static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
spi_sync(to_spi_device(glue->dev), &m);
+ kfree(t);
return 0;
}
+static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed)
+{
+ int ret;
+
+ /* The ELP wakeup write may fail the first time due to internal
+ * hardware latency. It is safer to send the wakeup command twice to
+ * avoid unexpected failures.
+ */
+ if (addr == HW_ACCESS_ELP_CTRL_REG)
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+
+ return ret;
+}
+
/**
* wl12xx_spi_set_power - power on/off the wl12xx unit
* @child: wl12xx device handle.
@@ -349,17 +407,38 @@ static int wl12xx_spi_set_power(struct device *child, bool enable)
return ret;
}
+/**
+ * wl12xx_spi_set_block_size
+ *
+ * This function is not needed for spi mode, but need to be present.
+ * Without it defined the wlcore fallback to use the wrong packet
+ * allignment on tx.
+ */
+static void wl12xx_spi_set_block_size(struct device *child,
+ unsigned int blksz)
+{
+}
+
static struct wl1271_if_operations spi_ops = {
.read = wl12xx_spi_raw_read,
.write = wl12xx_spi_raw_write,
.reset = wl12xx_spi_reset,
.init = wl12xx_spi_init,
.power = wl12xx_spi_set_power,
- .set_block_size = NULL,
+ .set_block_size = wl12xx_spi_set_block_size,
};
static const struct of_device_id wlcore_spi_of_match_table[] = {
- { .compatible = "ti,wl1271" },
+ { .compatible = "ti,wl1271", .data = &wl12xx_data},
+ { .compatible = "ti,wl1273", .data = &wl12xx_data},
+ { .compatible = "ti,wl1281", .data = &wl12xx_data},
+ { .compatible = "ti,wl1283", .data = &wl12xx_data},
+ { .compatible = "ti,wl1801", .data = &wl18xx_data},
+ { .compatible = "ti,wl1805", .data = &wl18xx_data},
+ { .compatible = "ti,wl1807", .data = &wl18xx_data},
+ { .compatible = "ti,wl1831", .data = &wl18xx_data},
+ { .compatible = "ti,wl1835", .data = &wl18xx_data},
+ { .compatible = "ti,wl1837", .data = &wl18xx_data},
{ }
};
MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table);
@@ -376,17 +455,24 @@ static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue *glue,
{
struct device_node *dt_node = spi->dev.of_node;
int ret;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_node(wlcore_spi_of_match_table, dt_node);
+ if (!of_id)
+ return -ENODEV;
+
+ wilink_data = of_id->data;
+ dev_info(&spi->dev, "selected chip familiy is %s\n",
+ wilink_data->name);
if (of_find_property(dt_node, "clock-xtal", NULL))
pdev_data->ref_clock_xtal = true;
- ret = of_property_read_u32(dt_node, "ref-clock-frequency",
- &pdev_data->ref_clock_freq);
- if (ret) {
- dev_err(glue->dev,
- "can't get reference clock frequency (%d)\n", ret);
- return ret;
- }
+ /* optional clock frequency params */
+ of_property_read_u32(dt_node, "ref-clock-frequency",
+ &pdev_data->ref_clock_freq);
+ of_property_read_u32(dt_node, "tcxo-clock-frequency",
+ &pdev_data->tcxo_clock_freq);
return 0;
}
@@ -437,7 +523,8 @@ static int wl1271_probe(struct spi_device *spi)
return ret;
}
- glue->core = platform_device_alloc("wl12xx", PLATFORM_DEVID_AUTO);
+ glue->core = platform_device_alloc(wilink_data->name,
+ PLATFORM_DEVID_AUTO);
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device\n");
return -ENOMEM;
--
2.7.4
^ permalink raw reply related
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Rafał Miłecki @ 2016-07-19 6:51 UTC (permalink / raw)
To: Kalle Valo, Brian Norris, linux-mtd@lists.infradead.org
Cc: Stephen Rothwell, linux-wireless@vger.kernel.org, linux-next,
Linux Kernel Mailing List
In-Reply-To: <8760s2w369.fsf@kamboji.qca.qualcomm.com>
On 19 July 2016 at 08:30, Kalle Valo <kvalo@codeaurora.org> wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>
>> After merging the wireless-drivers-next tree, today's linux-next build
>> (powerpc allyesconfig) failed like this:
>>
>> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>> drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>> b47s->window = ioremap_cache(res->start, resource_size(res));
>> ^
>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
>> b47s->window = ioremap_cache(res->start, resource_size(res));
>> ^
>>
>> Caused by commit
>>
>> 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>>
>> I have reverted that commit for today.
>
> Thanks, kbuild bot also notified about this.
>
> Rafał, as the merge window is getting really close I would like to
> revert this for now and we can reapply it once we the problem is fully
> solved. And we can use my pending branch for build testing the patch
> with kbuild bot. What do you think?
The simplest fix sounds pretty much as simple as the revert. In the
seconds thread I was considering two fixes: switching to memremap and
adding depends on.
What about trying a simple "depends on"?
--
Rafał
^ permalink raw reply
* [PATCH v6] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-07-19 6:30 UTC (permalink / raw)
To: Kalle Valo
Cc: Rob Herring, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-spi@vger.kernel.org
In-Reply-To: <1468907385-31844-1-git-send-email-eyalr@ti.com>
Add support for using with both wl12xx and wl18xx.
- all wilink family needs special init command for entering wspi mode.
extra clock cycles should be sent after the spi init command while the
cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
completes the init stage.
Signed-off-by: Eyal Reizer <eyalr@ti.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select
v2->instead
for sending the extra init cycle which, achieves the same hardware purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip
v3->select
number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next
v5->v6: Add ACKs
.../bindings/net/wireless/ti,wlcore,spi.txt | 41 +++++--
drivers/net/wireless/ti/wlcore/spi.c | 123 ++++++++++++++++++---
2 files changed, 137 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller
-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
document describes the binding for the SPI connected chip.
Required properties:
-- compatible : Should be "ti,wl1271"
+- compatible : Should be one of the following:
+ * "ti,wl1271"
+ * "ti,wl1273"
+ * "ti,wl1281"
+ * "ti,wl1283"
+ * "ti,wl1801"
+ * "ti,wl1805"
+ * "ti,wl1807"
+ * "ti,wl1831"
+ * "ti,wl1835"
+ * "ti,wl1837"
- reg : Chip select address of device
- spi-max-frequency : Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
- interrupt-parent, interrupts :
Should contain parameters for 1 interrupt line.
Interrupt parameters: parent, line number, type.
-- vwlan-supply : Point the node of the regulator that powers/enable the wl1271 chip
+- vwlan-supply : Point the node of the regulator that powers/enable the
+ wl12xx/wl18xx chip
Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for
+wl12xx)
- clock-xtal : boolean, clock is generated from XTAL
- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:
Examples:
+For wl12xx family:
&spi1 {
- wl1271@1 {
+ wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <48000000>;
- clock-xtal;
- ref-clock-frequency = <38400000>;
interrupt-parent = <&gpio3>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <&vwlan_fixed>;
+ clock-xtal;
+ ref-clock-frequency = <38400000>;
+ };
+};
+
+For wl18xx family:
+&spi0 {
+ wlcore: wlcore@0 {
+ compatible = "ti,wl1835";
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+ vwlan-supply = <&vwlan_fixed>;
};
};
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..73fbcf1 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
#define WSPI_MAX_CHUNK_SIZE 4092
/*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared
+ to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for
+ wl18xx
*/
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
/* Maximum number of SPI write chunks */ #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
+struct wilink_familiy_data {
+ char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+ .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+ .name = "wl12xx",
+};
+
struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+ struct spi_device *spi = to_spi_device(glue->dev);
u8 *cmd = kzalloc(WSPI_INIT_CMD_LEN, GFP_KERNEL);
if (!cmd) {
@@ -151,6 +166,7 @@ static void wl12xx_spi_init(struct device *child)
cmd[6] |= WSPI_INIT_CMD_EN_FIXEDBUSY;
cmd[7] = crc7_be(0, cmd+2, WSPI_INIT_CMD_CRC_LEN) | WSPI_INIT_CMD_END;
+
/*
* The above is the logical order; it must actually be stored
* in the buffer byte-swapped.
@@ -163,6 +179,28 @@ static void wl12xx_spi_init(struct device *child)
spi_message_add_tail(&t, &m);
spi_sync(to_spi_device(glue->dev), &m);
+
+ /* Send extra clocks with inverted CS (high). this is required
+ * by the wilink family in order to successfully enter WSPI mode.
+ */
+ spi->mode ^= SPI_CS_HIGH;
+ memset(&m, 0, sizeof(m));
+ spi_message_init(&m);
+
+ cmd[0] = 0xff;
+ cmd[1] = 0xff;
+ cmd[2] = 0xff;
+ cmd[3] = 0xff;
+ __swab32s((u32 *)cmd);
+
+ t.tx_buf = cmd;
+ t.len = 4;
+ spi_message_add_tail(&t, &m);
+
+ spi_sync(to_spi_device(glue->dev), &m);
+
+ /* Restore chip select configration to normal */
+ spi->mode ^= SPI_CS_HIGH;
kfree(cmd);
}
@@ -270,22 +308,25 @@ static int __must_check wl12xx_spi_raw_read(struct device *child, int addr,
return 0;
}
-static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
- void *buf, size_t len, bool fixed)
+static int __wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed)
{
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
- /* SPI write buffers - 2 for each chunk */
- struct spi_transfer t[2 * WSPI_MAX_NUM_OF_CHUNKS];
+ struct spi_transfer *t;
struct spi_message m;
u32 commands[WSPI_MAX_NUM_OF_CHUNKS]; /* 1 command per chunk */
u32 *cmd;
u32 chunk_len;
int i;
+ /* SPI write buffers - 2 for each chunk */
+ t = kzalloc(sizeof(*t) * 2 * WSPI_MAX_NUM_OF_CHUNKS, GFP_KERNEL);
+ if (!t)
+ return -ENOMEM;
+
WARN_ON(len > SPI_AGGR_BUFFER_SIZE);
spi_message_init(&m);
- memset(t, 0, sizeof(t));
cmd = &commands[0];
i = 0;
@@ -318,9 +359,26 @@ static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
spi_sync(to_spi_device(glue->dev), &m);
+ kfree(t);
return 0;
}
+static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
+ void *buf, size_t len, bool fixed) {
+ int ret;
+
+ /* The ELP wakeup write may fail the first time due to internal
+ * hardware latency. It is safer to send the wakeup command twice to
+ * avoid unexpected failures.
+ */
+ if (addr == HW_ACCESS_ELP_CTRL_REG)
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+ ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
+
+ return ret;
+}
+
/**
* wl12xx_spi_set_power - power on/off the wl12xx unit
* @child: wl12xx device handle.
@@ -349,17 +407,38 @@ static int wl12xx_spi_set_power(struct device *child, bool enable)
return ret;
}
+/**
+ * wl12xx_spi_set_block_size
+ *
+ * This function is not needed for spi mode, but need to be present.
+ * Without it defined the wlcore fallback to use the wrong packet
+ * allignment on tx.
+ */
+static void wl12xx_spi_set_block_size(struct device *child,
+ unsigned int blksz)
+{
+}
+
static struct wl1271_if_operations spi_ops = {
.read = wl12xx_spi_raw_read,
.write = wl12xx_spi_raw_write,
.reset = wl12xx_spi_reset,
.init = wl12xx_spi_init,
.power = wl12xx_spi_set_power,
- .set_block_size = NULL,
+ .set_block_size = wl12xx_spi_set_block_size,
};
static const struct of_device_id wlcore_spi_of_match_table[] = {
- { .compatible = "ti,wl1271" },
+ { .compatible = "ti,wl1271", .data = &wl12xx_data},
+ { .compatible = "ti,wl1273", .data = &wl12xx_data},
+ { .compatible = "ti,wl1281", .data = &wl12xx_data},
+ { .compatible = "ti,wl1283", .data = &wl12xx_data},
+ { .compatible = "ti,wl1801", .data = &wl18xx_data},
+ { .compatible = "ti,wl1805", .data = &wl18xx_data},
+ { .compatible = "ti,wl1807", .data = &wl18xx_data},
+ { .compatible = "ti,wl1831", .data = &wl18xx_data},
+ { .compatible = "ti,wl1835", .data = &wl18xx_data},
+ { .compatible = "ti,wl1837", .data = &wl18xx_data},
{ }
};
MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table); @@ -376,17 +455,24 @@ static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue *glue, {
struct device_node *dt_node = spi->dev.of_node;
int ret;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_node(wlcore_spi_of_match_table, dt_node);
+ if (!of_id)
+ return -ENODEV;
+
+ wilink_data = of_id->data;
+ dev_info(&spi->dev, "selected chip familiy is %s\n",
+ wilink_data->name);
if (of_find_property(dt_node, "clock-xtal", NULL))
pdev_data->ref_clock_xtal = true;
- ret = of_property_read_u32(dt_node, "ref-clock-frequency",
- &pdev_data->ref_clock_freq);
- if (ret) {
- dev_err(glue->dev,
- "can't get reference clock frequency (%d)\n", ret);
- return ret;
- }
+ /* optional clock frequency params */
+ of_property_read_u32(dt_node, "ref-clock-frequency",
+ &pdev_data->ref_clock_freq);
+ of_property_read_u32(dt_node, "tcxo-clock-frequency",
+ &pdev_data->tcxo_clock_freq);
return 0;
}
@@ -437,7 +523,8 @@ static int wl1271_probe(struct spi_device *spi)
return ret;
}
- glue->core = platform_device_alloc("wl12xx", PLATFORM_DEVID_AUTO);
+ glue->core = platform_device_alloc(wilink_data->name,
+ PLATFORM_DEVID_AUTO);
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device\n");
return -ENOMEM;
--
2.7.4
^ permalink raw reply related
* Re: linux-next: build failure after merge of the wireless-drivers-next tree
From: Kalle Valo @ 2016-07-19 6:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-wireless, linux-next, linux-kernel, Rafał Miłecki
In-Reply-To: <20160719160831.79c0303f@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> After merging the wireless-drivers-next tree, today's linux-next build
> (powerpc allyesconfig) failed like this:
>
> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
> drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
> b47s->window = ioremap_cache(res->start, resource_size(res));
> ^
> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
> b47s->window = ioremap_cache(res->start, resource_size(res));
> ^
>
> Caused by commit
>
> 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
>
> I have reverted that commit for today.
Thanks, kbuild bot also notified about this.
Rafał, as the merge window is getting really close I would like to
revert this for now and we can reapply it once we the problem is fully
solved. And we can use my pending branch for build testing the patch
with kbuild bot. What do you think?
--
Kalle Valo
^ permalink raw reply
* linux-next: build failure after merge of the wireless-drivers-next tree
From: Stephen Rothwell @ 2016-07-19 6:08 UTC (permalink / raw)
To: Kalle Valo, linux-wireless
Cc: linux-next, linux-kernel, Rafał Miłecki
Hi all,
After merging the wireless-drivers-next tree, today's linux-next build
(powerpc allyesconfig) failed like this:
drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
drivers/mtd/devices/bcm47xxsflash.c:299:17: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
b47s->window = ioremap_cache(res->start, resource_size(res));
^
drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
b47s->window = ioremap_cache(res->start, resource_size(res));
^
Caused by commit
57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [ath6kl:pending 14/24] drivers/mtd/devices/bcm47xxsflash.c:299:2: error: implicit declaration of function 'ioremap_cache'
From: Rafał Miłecki @ 2016-07-19 5:56 UTC (permalink / raw)
To: kbuild test robot, Brian Norris
Cc: kbuild-all, ath10k, Kalle Valo, linux-mtd, linux-wireless
In-Reply-To: <201607190916.c8xDOxpA%fengguang.wu@intel.com>
Resending reply with proper To/Cc.
On 07/19/2016 03:14 AM, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
> head: 7a1b79bd39dda1f12b9f6708583250f40354c981
> commit: 57d8f7dd2132df3ac21044e93a8ecdc9744b4459 [14/24] bcma: allow enabling serial flash support on non-MIPS SoCs
> config: cris-allmodconfig (attached as .config)
> compiler: cris-linux-gcc (GCC) 4.6.3
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 57d8f7dd2132df3ac21044e93a8ecdc9744b4459
> # save the attached .config to linux build tree
> make.cross ARCH=cris
>
> All error/warnings (new ones prefixed by >>):
>
> drivers/mtd/devices/bcm47xxsflash.c: In function 'bcm47xxsflash_bcma_probe':
>>> drivers/mtd/devices/bcm47xxsflash.c:299:2: error: implicit declaration of function 'ioremap_cache' [-Werror=implicit-function-declaration]
>>> drivers/mtd/devices/bcm47xxsflash.c:299:15: warning: assignment makes pointer from integer without a cast [enabled by default]
> cc1: some warnings being treated as errors
Oh, great :( With commit:
5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()")
we believed to make this driver compilable on all architectures. It seems that
ioremap_cache is available only on arm, arm64, ia64, mips, sh, x86 and xtensa.
I noticed that kernel/memremap.c implements ioremap_cache on its own for archs
that don't provide it. There is a comment in this file:
/* temporary while we convert existing ioremap_cache users to memremap */
Should we use memremap? I don't understand this function well, it seems I could
call it with with MEMREMAP_WB flag (and trigger ioremap_cache call), but is it a
correct thing to do?
Or should we simply make some symbol (CONFIG_MTD_BCM47XXSFLASH?) depend on
ARM || MIPS?
> vim +/ioremap_cache +299 drivers/mtd/devices/bcm47xxsflash.c
>
> 5fe42d5bf Rafał Miłecki 2012-09-17 283
> 5651d6aaf Brian Norris 2016-02-26 284 b47s = devm_kzalloc(dev, sizeof(*b47s), GFP_KERNEL);
> d2b1bd142 Libo Chen 2013-05-30 285 if (!b47s)
> d2b1bd142 Libo Chen 2013-05-30 286 return -ENOMEM;
> a2f74a7da Rafał Miłecki 2013-01-06 287 sflash->priv = b47s;
> a2f74a7da Rafał Miłecki 2013-01-06 288
> 5651d6aaf Brian Norris 2016-02-26 289 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> 5651d6aaf Brian Norris 2016-02-26 290 if (!res) {
> 5651d6aaf Brian Norris 2016-02-26 291 dev_err(dev, "invalid resource\n");
> 5651d6aaf Brian Norris 2016-02-26 292 return -EINVAL;
> 5651d6aaf Brian Norris 2016-02-26 293 }
> 5651d6aaf Brian Norris 2016-02-26 294 if (!devm_request_mem_region(dev, res->start, resource_size(res),
> 5651d6aaf Brian Norris 2016-02-26 295 res->name)) {
> 5651d6aaf Brian Norris 2016-02-26 296 dev_err(dev, "can't request region for resource %pR\n", res);
> 5651d6aaf Brian Norris 2016-02-26 297 return -EBUSY;
> 5651d6aaf Brian Norris 2016-02-26 298 }
> 5651d6aaf Brian Norris 2016-02-26 @299 b47s->window = ioremap_cache(res->start, resource_size(res));
> 5651d6aaf Brian Norris 2016-02-26 300 if (!b47s->window) {
> 5651d6aaf Brian Norris 2016-02-26 301 dev_err(dev, "ioremap failed for resource %pR\n", res);
> 5651d6aaf Brian Norris 2016-02-26 302 return -ENOMEM;
> 5651d6aaf Brian Norris 2016-02-26 303 }
> 5651d6aaf Brian Norris 2016-02-26 304
> 41c81536e Rafał Miłecki 2013-03-06 305 b47s->bcma_cc = container_of(sflash, struct bcma_drv_cc, sflash);
> 265dfbd9a Rafał Miłecki 2013-03-24 306 b47s->cc_read = bcm47xxsflash_bcma_cc_read;
> 265dfbd9a Rafał Miłecki 2013-03-24 307 b47s->cc_write = bcm47xxsflash_bcma_cc_write;
>
> :::::: The code at line 299 was first introduced by commit
> :::::: 5651d6aaf489d1db48c253cf884b40214e91c2c5 mtd: bcm47xxsflash: use ioremap_cache() instead of KSEG0ADDR()
>
> :::::: TO: Brian Norris <computersforpeace@gmail.com>
> :::::: CC: Brian Norris <computersforpeace@gmail.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Masashi Honma @ 2016-07-19 2:16 UTC (permalink / raw)
To: Bob Copeland; +Cc: johannes, linux-wireless, j
In-Reply-To: <20160713135021.GE7819@localhost>
On 2016年07月13日 22:50, Bob Copeland wrote:
>
> Hmm, my recollection on this stuff is a little fuzzy. So we only get
> here if the peer sta is in doze state, but it shouldn't do that if we
> are in an MPSP.
Yes. In the MPSP, local peer only transmits frame when opposite peer is in
AWAKE. This patch expects we lost opposite peer accidentally
(AC adapter unplugged).
> So, is the real problem that we don't wait for an ack
> from the peer before marking ourselves in a MPSP?
>
This patch does not fix starting MPSP, this patch fixes ending of MPSP.
Without this patch, local peer continues MPSP even if we lost opposite peer
accidentally.
^ permalink raw reply
* [PATCH 4/4] brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()
From: Florian Fainelli @ 2016-07-18 23:24 UTC (permalink / raw)
To: brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, arend.vanspriel, hante.meuleman,
Florian Fainelli
In-Reply-To: <1468884277-18606-1-git-send-email-f.fainelli@gmail.com>
wlc_phy_txpower_get_current() does a logical OR of power->flags, which
presumes that power.flags was initiliazed earlier by the caller,
unfortunately, this is not the case, so make sure we zero out the struct
tx_power before calling into wlc_phy_txpower_get_current().
Reported-by: coverity (CID 146011)
Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c
index dd9162722495..0ab865de1491 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c
@@ -87,7 +87,7 @@ void
brcms_c_stf_ss_algo_channel_get(struct brcms_c_info *wlc, u16 *ss_algo_channel,
u16 chanspec)
{
- struct tx_power power;
+ struct tx_power power = { };
u8 siso_mcs_id, cdd_mcs_id, stbc_mcs_id;
/* Clear previous settings */
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211
From: Florian Fainelli @ 2016-07-18 23:24 UTC (permalink / raw)
To: brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, arend.vanspriel, hante.meuleman,
Florian Fainelli
In-Reply-To: <1468884277-18606-1-git-send-email-f.fainelli@gmail.com>
struct ieee80211_rts::ra is only ETH_ALEN wide, yet we attempt to copy 2
* ETH_ALEN, which will potentially overrun the destination buffer.
Reported-by: coverity (CID 145657)
Fixes: 5b435de0d7868 ("net: wireless: add brcm80211 drivers")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
index c2a938b59044..59813a3666eb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
@@ -6671,7 +6671,7 @@ brcms_c_d11hdrs_mac80211(struct brcms_c_info *wlc, struct ieee80211_hw *hw,
rts->frame_control = cpu_to_le16(IEEE80211_FTYPE_CTL |
IEEE80211_STYPE_RTS);
- memcpy(&rts->ra, &h->addr1, 2 * ETH_ALEN);
+ memcpy(&rts->ra, &h->addr1, ETH_ALEN);
}
/* mainrate
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill
From: Florian Fainelli @ 2016-07-18 23:24 UTC (permalink / raw)
To: brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, arend.vanspriel, hante.meuleman,
Florian Fainelli
In-Reply-To: <1468884277-18606-1-git-send-email-f.fainelli@gmail.com>
In case dma_mapping_error() returns an error in dma_rxfill, we would be
leaking a packet that we allocated with brcmu_pkt_buf_get_skb().
Reported-by: coverity (CID 1081819)
Fixes: 67d0cf50bd32 ("brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
index 796f5f9d5d5a..b7df576bb84d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c
@@ -1079,8 +1079,10 @@ bool dma_rxfill(struct dma_pub *pub)
pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
DMA_FROM_DEVICE);
- if (dma_mapping_error(di->dmadev, pa))
+ if (dma_mapping_error(di->dmadev, pa)) {
+ brcmu_pkt_buf_free_skb(p);
return false;
+ }
/* save the free packet pointer */
di->rxp[rxout] = p;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/4] brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain
From: Florian Fainelli @ 2016-07-18 23:24 UTC (permalink / raw)
To: brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, arend.vanspriel, hante.meuleman,
Florian Fainelli
In-Reply-To: <1468884277-18606-1-git-send-email-f.fainelli@gmail.com>
In case brcmf_sdiod_recv_chain() cannot complete a succeful call to
brcmf_sdiod_buffrw, we would be leaking glom_skb and not free it as we
should, fix this.
Reported-by: coverity (CID 1164856)
Fixes: a413e39a38573 ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg support")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index c4b89d27e2e8..f549c25608d6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -726,8 +726,10 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
return -ENOMEM;
err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
glom_skb);
- if (err)
+ if (err) {
+ brcmu_pkt_buf_free_skb(glom_skb);
goto done;
+ }
skb_queue_walk(pktq, skb) {
memcpy(skb->data, glom_skb->data, skb->len);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] brcm80211: Misc coverity fixes
From: Florian Fainelli @ 2016-07-18 23:24 UTC (permalink / raw)
To: brcm80211-dev-list.pdl
Cc: linux-wireless, pieterpg, kvalo, arend.vanspriel, hante.meuleman,
Florian Fainelli
Hi,
This patch series addresses several coverity issues, they all seemed relevant
to me.
There is also a ton of warnings in Coverity caused by brcmf_fil_iovar_int_get()
and friends because of the initial access:
__le32 data_le = cpu_to_le32(*data) which can utilize unitialized memory. I am
not sure if we actually care about any kind of initial, value, but if we don't,
then the fix should be fairly obvious.
Thanks!
Florian Fainelli (4):
brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain
brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill
brcmsmac: Fix invalid memcpy() size in brcms_c_d11hdrs_mac80211
brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++-
drivers/net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 4 +++-
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 2 +-
drivers/net/wireless/broadcom/brcm80211/brcmsmac/stf.c | 2 +-
4 files changed, 8 insertions(+), 4 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Dave Taht @ 2016-07-18 22:02 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Felix Fietkau, linux-wireless, Michal Kazior
In-Reply-To: <87d1mar50e.fsf@toke.dk>
Just to add another datapoint, the "rack" optimization for tcp entered
the kernel recently. It has some "interesting" timing/batching
sensitive behaviors. While the TSO case is described, the packet
aggregation case seems similar, and is not.
https://www.ietf.org/proceedings/96/slides/slides-96-tcpm-3.pdf
10 Jan 2016
https://kernelnewbies.org/Linux_4.4#head-2583c31a65e6592bef9af426a78940078df7f630
The draft was significantly updated this month.
https://tools.ietf.org/html/draft-cheng-tcpm-rack-01
-- Andrew Shewmaker
On Mon, Jul 18, 2016 at 2:49 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
>> Felix Fietkau <nbd@nbd.name> writes:
>>
>>> Hi,
>>>
>>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>>> regression when running local iperf on an AP (running the txq stuff) to
>>> a wireless client.
>>>
>>> Here's some things that I found:
>>> - when I use only one TCP stream I get around 90-110 Mbit/s
>>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>>> - fairness between TCP streams looks completely fine
>>> - there's no big queue buildup, the code never actually drops any packets
>>> - if I put a hack in the fq code to force the hash to a constant value
>>> (effectively disabling fq without disabling codel), the problem
>>> disappears and even multiple streams get proper performance.
>>>
>>> Please let me know if you have any ideas.
>>
>> Hmm, I see two TCP streams get about the same aggregate throughput as
>> one, both when started from the AP and when started one hop away.
>
> So while I have still not been able to reproduce the issue you
> described, I have seen something else that is at least puzzling, and may
> or may not be related:
>
> When monitoring the output of /sys/kernel/debug/ieee80211/phy0/aqm I see
> that all stations have their queues empty all the way to zero several
> times per second. This is a bit puzzling; the queue should be kept under
> control, but really shouldn't empty completely. I figure this might also
> be the reason why you're seeing degraded performance...
>
> Since the stats output doesn't include a counter for drops, I haven't
> gotten any further with figuring out if it's CoDel that's being too
> aggressive, or what is happening. But will probably add that in and take
> another look.
>
> -Toke
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Toke Høiland-Jørgensen @ 2016-07-18 21:49 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <87shvfujl4.fsf@toke.dk>
Toke Høiland-Jørgensen <toke@toke.dk> writes:
> Felix Fietkau <nbd@nbd.name> writes:
>
>> Hi,
>>
>> With Toke's ath9k txq patch I've noticed a pretty nasty performance
>> regression when running local iperf on an AP (running the txq stuff) to
>> a wireless client.
>>
>> Here's some things that I found:
>> - when I use only one TCP stream I get around 90-110 Mbit/s
>> - when running multiple TCP streams, I get only 35-40 Mbit/s total
>> - fairness between TCP streams looks completely fine
>> - there's no big queue buildup, the code never actually drops any packets
>> - if I put a hack in the fq code to force the hash to a constant value
>> (effectively disabling fq without disabling codel), the problem
>> disappears and even multiple streams get proper performance.
>>
>> Please let me know if you have any ideas.
>
> Hmm, I see two TCP streams get about the same aggregate throughput as
> one, both when started from the AP and when started one hop away.
So while I have still not been able to reproduce the issue you
described, I have seen something else that is at least puzzling, and may
or may not be related:
When monitoring the output of /sys/kernel/debug/ieee80211/phy0/aqm I see
that all stations have their queues empty all the way to zero several
times per second. This is a bit puzzling; the queue should be kept under
control, but really shouldn't empty completely. I figure this might also
be the reason why you're seeing degraded performance...
Since the stats output doesn't include a counter for drops, I haven't
gotten any further with figuring out if it's CoDel that's being too
aggressive, or what is happening. But will probably add that in and take
another look.
-Toke
^ permalink raw reply
* Re: ath10k: add support for controlling tx power to a station
From: Kalle Valo @ 2016-07-18 20:08 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: ath10k, Ashok Raj Nagarajan, arnagara, linux-wireless
In-Reply-To: <1465925914-6404-1-git-send-email-arnagara@qti.qualcomm.com>
Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> wrote:
> This patch will add the support to control the transmit power for traffic
> to a station associated with the AP. Userspace provide the transmit power
> value in mBm units and the allowed range is from 0 to 70. Underlying FW
> will enforce that the maximum tx power will be based on the regulatory
> requirements. If the user given transmit power is greater than the allowed
> tx power in the given channel, then the FW will use the maximum tx power
> in the same channel.
>
> When 0 is sent to the FW as tx power, it will revert to the automatic tx
> power for the station.
>
> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
(A note to patchwork)
Depends on these patches:
cfg80211: Add support to set tx power for a station associated
https://patchwork.kernel.org/patch/9176355/
mac80211: store tx power value from user to station
https://patchwork.kernel.org/patch/9176359/
Both are currently in state Changes Requested.
--
Sent by pwcli
https://patchwork.kernel.org/patch/9176353/
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2016-07-11
From: Kalle Valo @ 2016-07-18 19:47 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, Grumbach, Emmanuel
In-Reply-To: <1468236322.25088.114.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> I have one more patch intended for 4.8. I had forgotten to bump the FW
> API version that our driver is now able to load. I hope there is still
> time to get it included for 4.8.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 6f482e37b75d4e56cdb9b56ae7057f3ce67097bc:
>
> iwlwifi: move iwl_drv to be shared across transports (2016-07-06 10:37:44 +0300)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2016-07-11
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: bcma: allow enabling serial flash support on non-MIPS SoCs
From: Kalle Valo @ 2016-07-18 19:43 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless, Rafał Miłecki, open list
In-Reply-To: <1468838054-17014-1-git-send-email-zajec5@gmail.com>
Rafał Miłecki wrote:
> So far we had only MIPS devices with serial flash connected to the SoC's
> ChipCommon. ARM devices got a separated SPI controller and weere using
> standard SPI drivers.
> This has changed with the wireless SoC BCM47189B0. It's ARM based but
> has serial flash attached just like older devices. This allows using
> existing driver with these devices.
>
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
57d8f7dd2132 bcma: allow enabling serial flash support on non-MIPS SoCs
--
Sent by pwcli
https://patchwork.kernel.org/patch/9234387/
^ permalink raw reply
* Re: [1/2] mwifiex: fix PCIe legacy interrupt problem
From: Kalle Valo @ 2016-07-18 19:43 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1468589825-9188-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> In corner case, we may end up processing same interrupt twice.
> We have a logic to read pending interrupts at the end of interrupt
> processing routine. It has a race with interrupts read in interrupt
> handler. This patch solves the problem by ORing the interrupt bitmap
> in this case.
>
> The symptom for this bug is below messages in dmesg log.
>
> [ 11.522123] mwifiex_pcie 0000:01:00.0: CMD_RESP: invalid cmd resp
> [ 11.680412] mwifiex_pcie 0000:01:00.0: There is no command but got cmdrsp
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=109681
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
Thanks, 2 patches applied to wireless-drivers-next.git:
514952889544 mwifiex: fix PCIe legacy interrupt problem
2fd40d2d349f mwifiex: update command response skb length correctly
--
Sent by pwcli
https://patchwork.kernel.org/patch/9232091/
^ permalink raw reply
* Re: mwifiex: Fix request_irq() failure handling
From: Kalle Valo @ 2016-07-18 19:42 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Karthik D A,
Amitkumar Karwar
In-Reply-To: <1468586919-7534-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Karthik D A <karthida@marvell.com>
>
> It's been observed that request_irq() failure leads to a system crash
> due to a bug in mwifiex driver.
> When this failure happens, mwifiex_add_card() already takes care of
> clearing and freeing adapter->card pointer. This patch removes the
> redundant cleanup code causing crash.
>
> Signed-off-by: Karthik D A <karthida@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
2af86f9d954e mwifiex: Fix request_irq() failure handling
--
Sent by pwcli
https://patchwork.kernel.org/patch/9231905/
^ permalink raw reply
* Re: brcmfmac: defer DPC processing during probe
From: Kalle Valo @ 2016-07-18 19:42 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1468579153-14292-1-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> The sdio dpc starts processing when in SDIOD_STATE_DATA. This state was
> entered right after firmware download. This patch moves that transition
> just before enabling sdio interrupt handling thus avoiding watchdog
> expiry which would put the bus to sleep while probing.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
fd3ed33f51c2 brcmfmac: defer DPC processing during probe
--
Sent by pwcli
https://patchwork.kernel.org/patch/9231665/
^ 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