Re: [PATCH 00/11] Add mt76x0 driver

2018-07-20 Thread Stanislaw Gruszka
On Sat, Jul 07, 2018 at 10:38:27AM +0200, Hans Ulli Kroll wrote:
> > > My integration efforts can be traced here:
> > > https://github.com/sgruszka/wireless-drivers-next/commits/mt76x0-draft
> > > 
> > 
> > I just had a brief review of the code and I compiled the driver since at
> > the moment I had no adapter for that chipset.
> > As a remainder for future improvements/integration most of the code in 
> > dma.c, usb.c (except probe/disconnect functions) and tx.c can use the 
> > related
> > routines in the mt76-usb layer (we need to fill function pointer for chipset
> > related stuff if there are differences with mt76x2u, not looked yet).
> > Moreover mcu code can use utility routines in usb-mcu.c
> > I have not looked at mt76x2 common code yet.
> > 
> > Regards,
> > Lorenzo
> > 
> 
> It is also possible to reuse 
> struct mt76x2_txwi
> struct mt76x2_rxwi
> 
> They have the same memory layout for both mt76x0u and mt76x2u chipsets.
> 
> Lorenzo can you move them up to
> mt76.h
> and rename them to
> struct mt76_txwi
> struct mt76_rxwi
> 
> And we can also do this for
> struct mt76x2_vif

For the record. I unified bunch of mac80211 callbacks and mac/wcid functions
and structures (including structures pointed above) into new mt76xx_lib
module. I also rebased the changes on top of latest wireless-drivers-next
master and mt76x2u patches in new branch mt76x0-draft-v2:
https://github.com/sgruszka/wireless-drivers-next/commits/mt76x0-draft-v2

Regards
Stanislaw


Re: [PATCH 00/11] Add mt76x0 driver

2018-07-20 Thread Stanislaw Gruszka
On Fri, Jul 20, 2018 at 12:30:32PM +0200, Stanislaw Gruszka wrote:
> On Sat, Jul 07, 2018 at 10:38:27AM +0200, Hans Ulli Kroll wrote:
> > > > My integration efforts can be traced here:
> > > > https://github.com/sgruszka/wireless-drivers-next/commits/mt76x0-draft
> > > > 
> > > 
> > > I just had a brief review of the code and I compiled the driver since at
> > > the moment I had no adapter for that chipset.
> > > As a remainder for future improvements/integration most of the code in 
> > > dma.c, usb.c (except probe/disconnect functions) and tx.c can use the 
> > > related
> > > routines in the mt76-usb layer (we need to fill function pointer for 
> > > chipset
> > > related stuff if there are differences with mt76x2u, not looked yet).
> > > Moreover mcu code can use utility routines in usb-mcu.c
> > > I have not looked at mt76x2 common code yet.
> > > 
> > > Regards,
> > > Lorenzo
> > > 
> > 
> > It is also possible to reuse 
> > struct mt76x2_txwi
> > struct mt76x2_rxwi
> > 
> > They have the same memory layout for both mt76x0u and mt76x2u chipsets.
> > 
> > Lorenzo can you move them up to
> > mt76.h
> > and rename them to
> > struct mt76_txwi
> > struct mt76_rxwi
> > 
> > And we can also do this for
> > struct mt76x2_vif
> 
> For the record. I unified bunch of mac80211 callbacks and mac/wcid functions
> and structures (including structures pointed above) into new mt76xx_lib
> module. I also rebased the changes on top of latest wireless-drivers-next
> master and mt76x2u patches in new branch mt76x0-draft-v2:
> https://github.com/sgruszka/wireless-drivers-next/commits/mt76x0-draft-v2

Forgot to wrote that I tested changes only for mt76x0 (sill waiting for
ordered mt76x2 HW) but common code is basically a copy of mt76x2 code
(if mt76x0 implementation differ, the one form mt76x2 was used). However
there are some changes that affect mt76x2 as well. Hopefully I did not break
anything there, but I can not be sure for now.

Stanislaw 


[PATCH 1/4] staging: wilc1000: remove gpio parameter from wilc_netdev_init()

2018-07-20 Thread Ajay Singh
Instead of passing the gpio as parameter to wilc_netdev_init() now
setting its value after finishing wilc_netdev_init() call. Avoided
passing of extra parameter to wilc_netdev_init().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/linux_wlan.c | 3 +--
 drivers/staging/wilc1000/wilc_sdio.c  | 4 ++--
 drivers/staging/wilc1000/wilc_spi.c   | 3 ++-
 drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 2f4bf8e..8f43a1f 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1053,7 +1053,7 @@ static const struct net_device_ops wilc_netdev_ops = {
 };
 
 int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type,
-int gpio, const struct wilc_hif_func *ops)
+const struct wilc_hif_func *ops)
 {
int i, ret;
struct wilc_vif *vif;
@@ -1066,7 +1066,6 @@ int wilc_netdev_init(struct wilc **wilc, struct device 
*dev, int io_type,
 
*wilc = wl;
wl->io_type = io_type;
-   wl->gpio = gpio;
wl->hif_func = ops;
INIT_LIST_HEAD(&wl->txq_head.list);
INIT_LIST_HEAD(&wl->rxq_head.list);
diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index 4ab43f9..7a2fc79 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -118,14 +118,14 @@ static int linux_sdio_probe(struct sdio_func *func,
}
 
dev_dbg(&func->dev, "Initializing netdev\n");
-   ret = wilc_netdev_init(&wilc, &func->dev, HIF_SDIO, gpio,
-  &wilc_hif_sdio);
+   ret = wilc_netdev_init(&wilc, &func->dev, HIF_SDIO, &wilc_hif_sdio);
if (ret) {
dev_err(&func->dev, "Couldn't initialize netdev\n");
return ret;
}
sdio_set_drvdata(func, wilc);
wilc->dev = &func->dev;
+   wilc->gpio = gpio;
 
dev_info(&func->dev, "Driver Initializing success\n");
return 0;
diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 6475263..69b2c3c 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -113,12 +113,13 @@ static int wilc_bus_probe(struct spi_device *spi)
if (gpio < 0)
gpio = GPIO_NUM;
 
-   ret = wilc_netdev_init(&wilc, NULL, HIF_SPI, GPIO_NUM, &wilc_hif_spi);
+   ret = wilc_netdev_init(&wilc, NULL, HIF_SPI, &wilc_hif_spi);
if (ret)
return ret;
 
spi_set_drvdata(spi, wilc);
wilc->dev = &spi->dev;
+   wilc->gpio = gpio;
 
return 0;
 }
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 765681a..add76c7 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -174,7 +174,7 @@ void wilc_frmw_to_linux(struct wilc *wilc, u8 *buff, u32 
size, u32 pkt_offset);
 void wilc_mac_indicate(struct wilc *wilc);
 void wilc_netdev_cleanup(struct wilc *wilc);
 int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type,
-int gpio, const struct wilc_hif_func *ops);
+const struct wilc_hif_func *ops);
 void wilc_wfi_mgmt_rx(struct wilc *wilc, u8 *buff, u32 size);
 int wilc_wlan_set_bssid(struct net_device *wilc_netdev, u8 *bssid, u8 mode);
 
-- 
2.7.4



[PATCH 0/4] staging: wilc1000: make use of descriptor-based interface for GPIO

2018-07-20 Thread Ajay Singh
This patch series contains changes mainly related to make use of
descriptor-based interface instead of integer-based interface for GPIO.
Modified the compatible string to use 'microchip' instead of 'atmel' prefix.
Also added the DT binding reference file.

This patch is created on top of [1] patch series.

[1]. https://www.spinics.net/lists/linux-wireless/msg175360.html

Ajay Singh (4):
  staging: wilc1000: remove gpio parameter from wilc_netdev_init()
  staging: wilc1000: rename variable from 'gpio' to 'gpio_irq'
  staging: wilc1000: change compatible string from atmel to microchip
  staging: wilc1000: use descriptor-based interface for GPIO

 drivers/staging/wilc1000/TODO  |  4 ---
 drivers/staging/wilc1000/linux_wlan.c  | 42 +-
 .../staging/wilc1000/microchip,wilc1000,sdio.txt   | 32 +
 .../staging/wilc1000/microchip,wilc1000,spi.txt| 26 ++
 drivers/staging/wilc1000/wilc_sdio.c   | 38 ++--
 drivers/staging/wilc1000/wilc_spi.c| 40 +
 drivers/staging/wilc1000/wilc_wfi_netdevice.h  |  5 +--
 7 files changed, 130 insertions(+), 57 deletions(-)
 create mode 100644 drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
 create mode 100644 drivers/staging/wilc1000/microchip,wilc1000,spi.txt

-- 
2.7.4



[PATCH 3/4] staging: wilc1000: change compatible string from atmel to microchip

2018-07-20 Thread Ajay Singh
Use 'microchip' in compatible string instead of 'atmel', also replace '_'
with '-' before the module. Remove 'wilc1000' prefix from device table
name.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/wilc_sdio.c | 11 +--
 drivers/staging/wilc1000/wilc_spi.c  | 14 +++---
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index 07cb8a6..afb91e5 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -199,21 +199,28 @@ static int wilc_sdio_resume(struct device *dev)
return 0;
 }
 
+static const struct of_device_id wilc_of_match[] = {
+   { .compatible = "microchip,wilc1000-sdio", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, wilc_of_match);
+
 static const struct dev_pm_ops wilc_sdio_pm_ops = {
.suspend = wilc_sdio_suspend,
.resume = wilc_sdio_resume,
 };
 
-static struct sdio_driver wilc1000_sdio_driver = {
+static struct sdio_driver wilc_sdio_driver = {
.name   = SDIO_MODALIAS,
.id_table   = wilc_sdio_ids,
.probe  = linux_sdio_probe,
.remove = linux_sdio_remove,
.drv = {
.pm = &wilc_sdio_pm_ops,
+   .of_match_table = wilc_of_match,
}
 };
-module_driver(wilc1000_sdio_driver,
+module_driver(wilc_sdio_driver,
  sdio_register_driver,
  sdio_unregister_driver);
 MODULE_LICENSE("GPL");
diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 8cb286b..7d4c7c5 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -130,21 +130,21 @@ static int wilc_bus_remove(struct spi_device *spi)
return 0;
 }
 
-static const struct of_device_id wilc1000_of_match[] = {
-   { .compatible = "atmel,wilc_spi", },
-   {}
+static const struct of_device_id wilc_of_match[] = {
+   { .compatible = "microchip,wilc1000-spi", },
+   { /* sentinel */ }
 };
-MODULE_DEVICE_TABLE(of, wilc1000_of_match);
+MODULE_DEVICE_TABLE(of, wilc_of_match);
 
-static struct spi_driver wilc1000_spi_driver = {
+static struct spi_driver wilc_spi_driver = {
.driver = {
.name = MODALIAS,
-   .of_match_table = wilc1000_of_match,
+   .of_match_table = wilc_of_match,
},
.probe =  wilc_bus_probe,
.remove = wilc_bus_remove,
 };
-module_spi_driver(wilc1000_spi_driver);
+module_spi_driver(wilc_spi_driver);
 MODULE_LICENSE("GPL");
 
 static int wilc_spi_tx(struct wilc *wilc, u8 *b, u32 len)
-- 
2.7.4



[PATCH 2/4] staging: wilc1000: rename variable from 'gpio' to 'gpio_irq'

2018-07-20 Thread Ajay Singh
Rename from 'gpio' to 'gpio_irq', so its inlcude the information about
the purpose of GPIO.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/linux_wlan.c | 17 +
 drivers/staging/wilc1000/wilc_sdio.c  |  2 +-
 drivers/staging/wilc1000/wilc_spi.c   |  2 +-
 drivers/staging/wilc1000/wilc_wfi_netdevice.h |  2 +-
 4 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 8f43a1f..74e7180 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -127,9 +127,9 @@ static int init_irq(struct net_device *dev)
struct wilc_vif *vif = netdev_priv(dev);
struct wilc *wl = vif->wilc;
 
-   if ((gpio_request(wl->gpio, "WILC_INTR") == 0) &&
-   (gpio_direction_input(wl->gpio) == 0)) {
-   wl->dev_irq_num = gpio_to_irq(wl->gpio);
+   if ((gpio_request(wl->gpio_irq, "WILC_INTR") == 0) &&
+   (gpio_direction_input(wl->gpio_irq) == 0)) {
+   wl->dev_irq_num = gpio_to_irq(wl->gpio_irq);
} else {
ret = -1;
netdev_err(dev, "could not obtain gpio for WILC_INTR\n");
@@ -140,13 +140,14 @@ static int init_irq(struct net_device *dev)
  isr_bh_routine,
  IRQF_TRIGGER_LOW | IRQF_ONESHOT,
  "WILC_IRQ", dev) < 0) {
-   netdev_err(dev, "Failed to request IRQ GPIO: %d\n", wl->gpio);
-   gpio_free(wl->gpio);
+   netdev_err(dev, "Failed to request IRQ GPIO: %d\n",
+  wl->gpio_irq);
+   gpio_free(wl->gpio_irq);
ret = -1;
} else {
netdev_dbg(dev,
   "IRQ request succeeded IRQ-NUM= %d on GPIO: %d\n",
-  wl->dev_irq_num, wl->gpio);
+  wl->dev_irq_num, wl->gpio_irq);
}
 
return ret;
@@ -160,7 +161,7 @@ static void deinit_irq(struct net_device *dev)
/* Deinitialize IRQ */
if (wilc->dev_irq_num) {
free_irq(wilc->dev_irq_num, wilc);
-   gpio_free(wilc->gpio);
+   gpio_free(wilc->gpio_irq);
}
 }
 
@@ -651,7 +652,7 @@ static int wilc_wlan_initialize(struct net_device *dev, 
struct wilc_vif *vif)
goto fail_locks;
}
 
-   if (wl->gpio >= 0 && init_irq(dev)) {
+   if (wl->gpio_irq >= 0 && init_irq(dev)) {
ret = -EIO;
goto fail_locks;
}
diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index 7a2fc79..07cb8a6 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -125,7 +125,7 @@ static int linux_sdio_probe(struct sdio_func *func,
}
sdio_set_drvdata(func, wilc);
wilc->dev = &func->dev;
-   wilc->gpio = gpio;
+   wilc->gpio_irq = gpio;
 
dev_info(&func->dev, "Driver Initializing success\n");
return 0;
diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 69b2c3c..8cb286b 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -119,7 +119,7 @@ static int wilc_bus_probe(struct spi_device *spi)
 
spi_set_drvdata(spi, wilc);
wilc->dev = &spi->dev;
-   wilc->gpio = gpio;
+   wilc->gpio_irq = gpio;
 
return 0;
 }
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index add76c7..74c2a17 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -121,7 +121,7 @@ struct wilc {
const struct wilc_hif_func *hif_func;
int io_type;
int mac_status;
-   int gpio;
+   int gpio_irq;
bool initialized;
int dev_irq_num;
int close;
-- 
2.7.4



[PATCH 4/4] staging: wilc1000: use descriptor-based interface for GPIO

2018-07-20 Thread Ajay Singh
Now making use of descriptor-based interface instead of integer-based
interface for IRQ GPIO.
Added device tree binding reference for WILC SDIO and SPI interface
module. Also moved the code to free gpio descriptor in module remove
as the reference was fetched in probe function.
Updated the TODO file

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/TODO  |  4 ---
 drivers/staging/wilc1000/linux_wlan.c  | 40 +-
 .../staging/wilc1000/microchip,wilc1000,sdio.txt   | 32 +
 .../staging/wilc1000/microchip,wilc1000,spi.txt| 26 ++
 drivers/staging/wilc1000/wilc_sdio.c   | 23 +
 drivers/staging/wilc1000/wilc_spi.c| 23 +
 drivers/staging/wilc1000/wilc_wfi_netdevice.h  |  3 +-
 7 files changed, 108 insertions(+), 43 deletions(-)
 create mode 100644 drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
 create mode 100644 drivers/staging/wilc1000/microchip,wilc1000,spi.txt

diff --git a/drivers/staging/wilc1000/TODO b/drivers/staging/wilc1000/TODO
index 725bede..3d82bb0 100644
--- a/drivers/staging/wilc1000/TODO
+++ b/drivers/staging/wilc1000/TODO
@@ -3,7 +3,3 @@ TODO:
 - make spi and sdio components coexist in one build
 - support soft-ap and p2p mode
 - support resume/suspend function
-- convert all uses of the old GPIO API from  to the
-  GPIO descriptor API in  and look up GPIO
-  lines from device tree, ACPI or board files, board files should
-  use 
diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 74e7180..64c5d69 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1,6 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -127,28 +126,23 @@ static int init_irq(struct net_device *dev)
struct wilc_vif *vif = netdev_priv(dev);
struct wilc *wl = vif->wilc;
 
-   if ((gpio_request(wl->gpio_irq, "WILC_INTR") == 0) &&
-   (gpio_direction_input(wl->gpio_irq) == 0)) {
-   wl->dev_irq_num = gpio_to_irq(wl->gpio_irq);
-   } else {
-   ret = -1;
+   ret = gpiod_direction_input(wl->gpio_irq);
+   if (ret) {
netdev_err(dev, "could not obtain gpio for WILC_INTR\n");
+   return ret;
}
 
-   if (ret != -1 && request_threaded_irq(wl->dev_irq_num,
- isr_uh_routine,
- isr_bh_routine,
- IRQF_TRIGGER_LOW | IRQF_ONESHOT,
- "WILC_IRQ", dev) < 0) {
-   netdev_err(dev, "Failed to request IRQ GPIO: %d\n",
-  wl->gpio_irq);
-   gpio_free(wl->gpio_irq);
-   ret = -1;
-   } else {
-   netdev_dbg(dev,
-  "IRQ request succeeded IRQ-NUM= %d on GPIO: %d\n",
-  wl->dev_irq_num, wl->gpio_irq);
-   }
+   wl->dev_irq_num = gpiod_to_irq(wl->gpio_irq);
+
+   ret = request_threaded_irq(wl->dev_irq_num, isr_uh_routine,
+  isr_bh_routine,
+  IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+  "WILC_IRQ", dev);
+   if (ret < 0)
+   netdev_err(dev, "Failed to request IRQ\n");
+   else
+   netdev_dbg(dev, "IRQ request succeeded IRQ-NUM= %d\n",
+  wl->dev_irq_num);
 
return ret;
 }
@@ -159,10 +153,8 @@ static void deinit_irq(struct net_device *dev)
struct wilc *wilc = vif->wilc;
 
/* Deinitialize IRQ */
-   if (wilc->dev_irq_num) {
+   if (wilc->dev_irq_num)
free_irq(wilc->dev_irq_num, wilc);
-   gpio_free(wilc->gpio_irq);
-   }
 }
 
 void wilc_mac_indicate(struct wilc *wilc)
@@ -652,7 +644,7 @@ static int wilc_wlan_initialize(struct net_device *dev, 
struct wilc_vif *vif)
goto fail_locks;
}
 
-   if (wl->gpio_irq >= 0 && init_irq(dev)) {
+   if (wl->gpio_irq && init_irq(dev)) {
ret = -EIO;
goto fail_locks;
}
diff --git a/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt 
b/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
new file mode 100644
index 000..4f7d1c2
--- /dev/null
+++ b/drivers/staging/wilc1000/microchip,wilc1000,sdio.txt
@@ -0,0 +1,32 @@
+* Microchip WILC wireless SDIO device
+
+The wilc1000 chips can be connected via SDIO. The node is used to specifiy
+child node to the SDIO controller that connects the device to the system.
+
+Required properties:
+- compatible   :   Should be "microchip,wilc1000-spi"
+- irq-gpios:   Connect to a host IRQ
+- reg  :   Slot ID used in the controller
+
+Optional:

Re: [PATCH 00/11] Add mt76x0 driver

2018-07-20 Thread Lorenzo Bianconi
> On Sat, Jul 07, 2018 at 10:38:27AM +0200, Hans Ulli Kroll wrote:
> > > > My integration efforts can be traced here:
> > > > https://github.com/sgruszka/wireless-drivers-next/commits/mt76x0-draft
> > > > 
> > > 
> > > I just had a brief review of the code and I compiled the driver since at
> > > the moment I had no adapter for that chipset.
> > > As a remainder for future improvements/integration most of the code in 
> > > dma.c, usb.c (except probe/disconnect functions) and tx.c can use the 
> > > related
> > > routines in the mt76-usb layer (we need to fill function pointer for 
> > > chipset
> > > related stuff if there are differences with mt76x2u, not looked yet).
> > > Moreover mcu code can use utility routines in usb-mcu.c
> > > I have not looked at mt76x2 common code yet.
> > > 
> > > Regards,
> > > Lorenzo
> > > 
> > 
> > It is also possible to reuse 
> > struct mt76x2_txwi
> > struct mt76x2_rxwi
> > 
> > They have the same memory layout for both mt76x0u and mt76x2u chipsets.
> > 
> > Lorenzo can you move them up to
> > mt76.h
> > and rename them to
> > struct mt76_txwi
> > struct mt76_rxwi
> > 
> > And we can also do this for
> > struct mt76x2_vif
> 
> For the record. I unified bunch of mac80211 callbacks and mac/wcid functions
> and structures (including structures pointed above) into new mt76xx_lib
> module. I also rebased the changes on top of latest wireless-drivers-next
> master and mt76x2u patches in new branch mt76x0-draft-v2:
> https://github.com/sgruszka/wireless-drivers-next/commits/mt76x0-draft-v2
> 

Sorry Hans, I forgot to reply to your email. I have already seen Stanislaw's
repo and I agree he can apply his patchset on top of mt76x2u one as soon as
it is merged in wireless-driver-next repo.
Moreover Stanislaw I started working on unifying mt76x2u/mt76x0 dma/usb code,
I have not sent you the patchset since I am waiting for the adapter. If you
want I can send you the code as soon as it is completed (just compiled, not
tested)

Regards,
Lorenzo

> Regards
> Stanislaw


Re: [PATCH v2 00/12] Add mt76x0 driver

2018-07-20 Thread Sean Wang
On Wed, 2018-07-11 at 10:07 +0200, Lorenzo Bianconi wrote:
> > On Tue, 2018-07-10 at 11:52 +0200, Stanislaw Gruszka wrote:
> > > On Tue, Jul 10, 2018 at 02:50:30PM +0800, Sean Wang wrote:
> > > > > For full support mt7610.bin firmware blob is need, hopefully with 
> > > > > the permission of Mediatek, the blob will be pushed into 
> > > > > linux-firmware
> > > > > git tree.
> > > > > 
> > > > 
> > > > Hi, Stanislaw
> > > > 
> > > > You can feel free to add mt7610.bin firmware blob to linux-firmware with
> > > > the license LICENCE.mediatek I added in [1].
> > > > 
> > > > 
> > > > [1]
> > > > http://lists.infradead.org/pipermail/linux-mediatek/2018-June/013759.html
> > > 
> > > Thank you Sean!
> > > 
> > > I guess there is no problem with similar submission for
> > > mt7662u.bin and mt7662u_rom_patch.bin needed for mt76x2u:
> > > https://marc.info/?l=linux-wireless&m=153045438821562&w=2
> > > 
> > 
> 
> Thanks Sean,
> 
> I will submit mt7662u.bin and mt7662u_rom_patch.bin with LICENCE.mediatek
> soon
> 
> > Sure, there is no any problem for submitting mt7662u.bin and
> > mt7662u_rom_patch.bin if they are added with LICENCE.mediatek.
> > 
> > Do you or Lorenzo have a plan to add MT7668u support to mt76?
> > MT7668 is a newer wifi device than MT7610u or MT7662u.
> > 
> 
> Cool, I am interested in adding MT7668u support to mt76 driver.
> Is the adapter available on the market?

I'm not sure if it can be got from the market easily.

I would like to say, mt7668 is based on new MTK wifi architecture. as
for mt7662/mt7612/mt7610, they all belong to legacy Ralink based design.
of course, we will never see any new chip based on Ralink based design
wifi in the future.

There must be really lots of differences exist between two types of
devices, such as MCU firmware download, MCU control interface, tx/rx
path, even hardware register layout all changed and so on.

I guess the hardware abstraction layer needs to be largely adjusted to
add the new device mt7668u into mt76 driver. And even I think it would
be easier for development and maintenance if we make a separate driver
and then pick up some pure software components from mt76 to reuse.

Maybe it's the time I want to test your tree first with 7612u (?) or
mt7610u (?) , what is suggested? and see how big the gap between this
two type of devices and last write some code based on your tree to test
mt7668u

Sean

> Regards,
> Lorenzo
> 
> > > Regards
> > > Stanislaw
> > > 
> > > ___
> > > Linux-mediatek mailing list
> > > linux-media...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> > 
> > 




[PATCH] cfg80211: Do not ignore user regulatory hint

2018-07-20 Thread Amar Singhal
Currently user regulatory hint is ignored if all wiphys
in the system are self managed. But the hint is not ignored
if there is no wiphy in the system. This affects the global
regulatory setting. Global regulatory setting needs to be
maintained so that it can be applied to a new wiphy entering
the system. Therefore, do not ignore user regulatory setting
even if all wiphys in the system are self managed.

Signed-off-by: Amar Singhal 
---
 net/wireless/reg.c | 28 +++-
 1 file changed, 3 insertions(+), 25 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index bbe6298..4fc66a1 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2240,7 +2240,9 @@ static void wiphy_update_regulatory(struct wiphy *wiphy,
 * as some drivers used this to restore its orig_* reg domain.
 */
if (initiator == NL80211_REGDOM_SET_BY_CORE &&
-   wiphy->regulatory_flags & REGULATORY_CUSTOM_REG)
+   wiphy->regulatory_flags & REGULATORY_CUSTOM_REG &&
+   !(wiphy->regulatory_flags &
+ REGULATORY_WIPHY_SELF_MANAGED))
reg_call_notifier(wiphy, lr);
return;
}
@@ -2787,26 +2789,6 @@ static void notify_self_managed_wiphys(struct 
regulatory_request *request)
}
 }
 
-static bool reg_only_self_managed_wiphys(void)
-{
-   struct cfg80211_registered_device *rdev;
-   struct wiphy *wiphy;
-   bool self_managed_found = false;
-
-   ASSERT_RTNL();
-
-   list_for_each_entry(rdev, &cfg80211_rdev_list, list) {
-   wiphy = &rdev->wiphy;
-   if (wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED)
-   self_managed_found = true;
-   else
-   return false;
-   }
-
-   /* make sure at least one self-managed wiphy exists */
-   return self_managed_found;
-}
-
 /*
  * Processes regulatory hints, this is all the NL80211_REGDOM_SET_BY_*
  * Regulatory hints come on a first come first serve basis and we
@@ -2839,10 +2821,6 @@ static void reg_process_pending_hints(void)
spin_unlock(®_requests_lock);
 
notify_self_managed_wiphys(reg_request);
-   if (reg_only_self_managed_wiphys()) {
-   reg_free_request(reg_request);
-   return;
-   }
 
reg_process_hint(reg_request);
 
-- 
1.9.1



Re: [PATCH 4/4] staging: wilc1000: use descriptor-based interface for GPIO

2018-07-20 Thread Linus Walleij
On Fri, Jul 20, 2018 at 2:02 PM Ajay Singh  wrote:

> Now making use of descriptor-based interface instead of integer-based
> interface for IRQ GPIO.
> Added device tree binding reference for WILC SDIO and SPI interface
> module. Also moved the code to free gpio descriptor in module remove
> as the reference was fetched in probe function.
> Updated the TODO file
>
> Signed-off-by: Ajay Singh 

Reviewed-by: Linus Walleij 

Thanks Ajay!

Yours,
Linus Walleij


Re: [RFC v2 1/4] mac80211: Add TXQ scheduling API

2018-07-20 Thread Rajkumar Manoharan

On 2018-07-19 07:18, Toke Høiland-Jørgensen wrote:

Rajkumar Manoharan  writes:


On 2018-07-13 06:39, Toke Høiland-Jørgensen wrote:

Rajkumar Manoharan  writes:



It is not generally predictable how many times this will loop before
exiting...


Agree.. It would be better If the driver does not worry about txq
sequence numbering. Perhaps one more API (ieee80211_first_txq) could
solve this. Will leave it to you.


That is basically what the second parameter to next_txq() does in the
current patchset. It just needs to be renamed...


Agree. As next_txq() increments seqno while starting loop for each AC,
It seems bit confusing. i.e A single ath_txq_schedule_all call will bump
schedule_seqno by 4. right?

Let assume below case where CPU1 is dequeuing skb from isr context and
CPU2 is enqueuing skbs into same txq.

CPU1  CPU2
  
ath_txq_schedule
  -> ieee80211_next_txq(first)
-> inc_seq
-> delete from list
-> txq->seqno = local->seqno
 ieee80211_tx/fast_xmit
-> ieee80211_queue_skb
-> 
ieee80211_schedule_txq(reset_seqno)

 -> list_add
 -> txqi->seqno 
= local->seqno - 1


In above sequence, it is quite possible that the same txq
will be served repeatedly and other txqs will be starved. am I right?
IMHO seqno mechanism will not guarantee that txqs will be processed
only once in an iteration.

[...]

Well, it could conceivably be done in a way that doesn't require 
taking

the activeq_lock. Adding another STOP flag to the TXQ, for instance.
From an API point of view I think that is more consistent with what 
we

have already...



Make sense. ieee80211_txq_may_pull would be better place to decide
whether given txq is allowed for transmission. It also makes drivers
do not have to worry about deficit. Still I may need
ieee80211_reorder_txq API after processing txq. isn't it?


The way I was assuming this would work (and what ath9k does), is that a
driver only operates on one TXQ at a time; so it can get that txq,
process it, and re-schedule it. In which case no other API is needed;
the rotating can be done in next_txq(), and schedule_txq() can insert
the txq back into the rotation as needed.

However, it sounds like this is not how ath10k does things? See below.

correct. The current rotation works only in push-only mode. i.e when 
firmware
is not deciding txqs and the driver picks priority txq from active_txqs 
list.
Unfortunately rotation won't work when the driver selects txq other than 
first
in the list. In any case separate API needed for rotation when the 
driver is

processing few packets from txq instead of all pending frames.


In push-pull method, driver reports to firmware that number of frames
queued for each tid per station by wake_tx_queue. Later firmware will
query N frames from each TID and after dequeue driver will update
remaining frames for that tid. In ATF case, when driver is not able to
dequeue frames, driver will simply update remaining frames. The
consecutive fetch_ind get opportunity to dequeue the frames. By This
way, transmission for serving client will be paused for a while and
opportunity will be given to others.


This sounds like the driver doesn't do anything other than notify the
firmware that a txq has pending frames, and everything else is handled
by the firmware? Is this the case?



Correct. In push-pull method, DRR algorithm running in firmware and so
firmware decides txq.


And if so, how does that interact with ath10k_mac_tx_push_pending()?
That function is basically doing the same thing that I explained above
for ath9k; in the previous version of this patch series I modified that
to use next_txq(). But is that a different TX path, or am I
misunderstanding you?

If you could point me to which parts of the ath10k code I should be
looking at, that would be helpful as well :)

Depends on firmware htt_tx_mode (push/push_pull), 
ath10k_mac_tx_push_pending()
downloads all/partial frames to firmware. Please take a look at 
ath10k_mac_tx_can_push()

in push_pending(). Let me know If you need any other details.

-Rajkumar