Re: [PATCH v2 1/2] gpio: mediatek: add driver for MT7621
On Fri, Jun 29, 2018 at 2:43 PM, Sergio Paracuellos
wrote:
> Add driver support for gpio of MT7621 SoC.
>
> Signed-off-by: Sergio Paracuellos
> ---
> drivers/gpio/Kconfig | 8 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-mt7621.c | 320
> +
> 3 files changed, 329 insertions(+)
> create mode 100644 drivers/gpio/gpio-mt7621.c
Hi all,
Sorry for the noise. Ignore this and v3 for now. It seems the "only
one node" approach for the gpio in the device tree is not working
properly.
I thought it was but Neil points out here it was not:
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/122621.html
We'll send v4 with all properly working.
Thanks in advance and sorry again.
Best regards,
Sergio Paracuellos
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 71c0ab4..836aa21 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -359,6 +359,14 @@ config GPIO_MPC8XXX
> Say Y here if you're going to use hardware that connects to the
> MPC512x/831x/834x/837x/8572/8610/QorIQ GPIOs.
>
> +config GPIO_MT7621
> + bool "Mediatek MT7621 GPIO Support"
> + depends on SOC_MT7620 || SOC_MT7621 || COMPILE_TEST
> + select GPIO_GENERIC
> + select GPIOLIB_IRQCHIP
> + help
> + Say yes here to support the Mediatek MT7621 SoC GPIO device
> +
> config GPIO_MVEBU
> def_bool y
> depends on PLAT_ORION || ARCH_MVEBU
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 1324c8f..b264426 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -88,6 +88,7 @@ obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
> obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
> obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
> obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
> +obj-$(CONFIG_GPIO_MSIC)+= gpio-mt7621.o
> obj-$(CONFIG_GPIO_MVEBU)+= gpio-mvebu.o
> obj-$(CONFIG_GPIO_MXC) += gpio-mxc.o
> obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
> diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> new file mode 100644
> index 000..281e621
> --- /dev/null
> +++ b/drivers/gpio/gpio-mt7621.c
> @@ -0,0 +1,320 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2009-2011 Gabor Juhos
> + * Copyright (C) 2013 John Crispin
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MTK_BANK_CNT 3
> +#define MTK_BANK_WIDTH 32
> +
> +#define GPIO_BANK_WIDE 0x04
> +#define GPIO_REG_CTRL 0x00
> +#define GPIO_REG_POL 0x10
> +#define GPIO_REG_DATA 0x20
> +#define GPIO_REG_DSET 0x30
> +#define GPIO_REG_DCLR 0x40
> +#define GPIO_REG_REDGE 0x50
> +#define GPIO_REG_FEDGE 0x60
> +#define GPIO_REG_HLVL 0x70
> +#define GPIO_REG_LLVL 0x80
> +#define GPIO_REG_STAT 0x90
> +#define GPIO_REG_EDGE 0xA0
> +
> +struct mtk_gc {
> + struct gpio_chip chip;
> + spinlock_t lock;
> + int bank;
> + u32 rising;
> + u32 falling;
> + u32 hlevel;
> + u32 llevel;
> +};
> +
> +/**
> + * struct mtk_data - state container for
> + * data of the platform driver. It is 3
> + * separate gpio-chip each one with its
> + * own irq_chip.
> + * @dev: device instance
> + * @gpio_membase: memory base address
> + * @gpio_irq: irq number from the device tree
> + * @gc_map: array of the gpio chips
> + */
> +struct mtk_data {
> + struct device *dev;
> + void __iomem *gpio_membase;
> + int gpio_irq;
> + struct mtk_gc gc_map[MTK_BANK_CNT];
> +};
> +
> +static inline struct mtk_gc *
> +to_mediatek_gpio(struct gpio_chip *chip)
> +{
> + return container_of(chip, struct mtk_gc, chip);
> +}
> +
> +static inline void
> +mtk_gpio_w32(struct mtk_gc *rg, u32 offset, u32 val)
> +{
> + struct gpio_chip *gc = &rg->chip;
> + struct mtk_data *gpio_data = gpiochip_get_data(gc);
> +
> + offset = (rg->bank * GPIO_BANK_WIDE) + offset;
> + gc->write_reg(gpio_data->gpio_membase + offset, val);
> +}
> +
> +static inline u32
> +mtk_gpio_r32(struct mtk_gc *rg, u32 offset)
> +{
> + struct gpio_chip *gc = &rg->chip;
> + struct mtk_data *gpio_data = gpiochip_get_data(gc);
> +
> + offset = (rg->bank * GPIO_BANK_WIDE) + offset;
> + return gc->read_reg(gpio_data->gpio_membase + offset);
> +}
> +
> +static irqreturn_t
> +mediatek_gpio_irq_handler(int irq, void *data)
> +{
> + struct gpio_chip *gc = data;
> + struct mtk_gc *rg = to_mediatek_gpio(gc);
> + irqreturn_t ret = IRQ_NONE;
> + unsigned long pending;
> + int bit;
> +
> + pending = mtk_gpio_r32(rg, GPIO_REG_STAT);
> +
> + for_each_set_bit(bit, &pending, MTK_BANK_WIDTH) {
> + u32 map = irq_find_mapping(gc->irq.domain, bit);
> +
> + generic_handle_irq(map);
> + mtk_gpio_w32(rg, GPIO_REG_STAT, BIT(bi
Re: [PATCH v5 18/18] staging: mt7621-gpio: avoid use banks in device tree
On Sat, Jun 30, 2018 at 7:47 AM, NeilBrown wrote:
> On Mon, Jun 18 2018, Sergio Paracuellos wrote:
>
>> Banks shouldn't be defined in DT if number of resources
>> per bank is not variable. We actually know that this SoC
>> has three banks so take that into account in order to don't
>> overspecify the device tree. Device tree will only have one
>> node making it simple. Update device tree, binding doc and
>> code accordly.
>>
>> Signed-off-by: Sergio Paracuellos
>
> I'm sorry that I've been silent one these for a while - busy any all
> that.
>
> This last patch doesn't work. My test case works with all but this one
> applied, but this breaks it. I haven't had a chance to look into why
> yet. Sorry.
Thanks for pointing this out. All of them were applied so I though
there were no problem at all with any of them.
We should revert the last one or wait to your feedback about what is
breaking it and send a new patch fixing the problem.
Thanks in advance.
> NeilBrown
Best regards,
Sergio Paracuellos
>
>> ---
>> drivers/staging/mt7621-dts/gbpc1.dts | 10 ++--
>> drivers/staging/mt7621-dts/mt7621.dtsi | 31 ++--
>> drivers/staging/mt7621-gpio/gpio-mt7621.c | 21
>> .../staging/mt7621-gpio/mediatek,mt7621-gpio.txt | 59
>> +-
>> 4 files changed, 31 insertions(+), 90 deletions(-)
>>
>> diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
>> b/drivers/staging/mt7621-dts/gbpc1.dts
>> index 6b13d85..352945d 100644
>> --- a/drivers/staging/mt7621-dts/gbpc1.dts
>> +++ b/drivers/staging/mt7621-dts/gbpc1.dts
>> @@ -32,7 +32,7 @@
>>
>> reset {
>> label = "reset";
>> - gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
>> + gpios = <&gpio 18 GPIO_ACTIVE_HIGH>;
>> linux,code = ;
>> };
>> };
>> @@ -42,22 +42,22 @@
>>
>> system {
>> label = "gb-pc1:green:system";
>> - gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
>> + gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
>> };
>>
>> status {
>> label = "gb-pc1:green:status";
>> - gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
>> + gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
>> };
>>
>> lan1 {
>> label = "gb-pc1:green:lan1";
>> - gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
>> + gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
>> };
>>
>> lan2 {
>> label = "gb-pc1:green:lan2";
>> - gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
>> + gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
>> };
>> };
>> };
>> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
>> b/drivers/staging/mt7621-dts/mt7621.dtsi
>> index acb6b8c..02746af 100644
>> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
>> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
>> @@ -61,37 +61,14 @@
>> };
>>
>> gpio: gpio@600 {
>> - #address-cells = <1>;
>> - #size-cells = <0>;
>> -
>> + #gpio-cells = <2>;
>> + #interrupt-cells = <2>;
>> compatible = "mediatek,mt7621-gpio";
>> + gpio-controller;
>> + interrupt-controller;
>> reg = <0x600 0x100>;
>> -
>> interrupt-parent = <&gic>;
>> interrupts = ;
>> - interrupt-controller;
>> - #interrupt-cells = <2>;
>> -
>> - gpio0: bank@0 {
>> - reg = <0>;
>> - compatible = "mediatek,mt7621-gpio-bank";
>> - gpio-controller;
>> - #gpio-cells = <2>;
>> - };
>> -
>> - gpio1: bank@1 {
>> - reg = <1>;
>> - compatible = "mediatek,mt7621-gpio-bank";
>> - gpio-controller;
>> - #gpio-cells = <2>;
>> - };
>> -
>> - gpio2: bank@2 {
>> - reg = <2>;
>> - compatible = "mediatek,mt7621-gpio-bank";
>> - gpio-controller;
>> - #gpio-cells = <2>;
>> - };
>> };
>>
>> i2c: i2c@900 {
>> diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
>> b/drivers/staging/mt7621-gpio/gpio-mt7621.c
>> index 9a4a12f..281e621 100644
>> --- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
>> +++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
>> @@ -206,23 +206,20 @@ static inline const char * const
>> mediatek_gpio_bank_name(int bank)
>
Re: [PATCH v5 18/18] staging: mt7621-gpio: avoid use banks in device tree
On Mon, Jun 18 2018, Sergio Paracuellos wrote:
> Banks shouldn't be defined in DT if number of resources
> per bank is not variable. We actually know that this SoC
> has three banks so take that into account in order to don't
> overspecify the device tree. Device tree will only have one
> node making it simple. Update device tree, binding doc and
> code accordly.
>
> Signed-off-by: Sergio Paracuellos
I'm sorry that I've been silent one these for a while - busy any all
that.
This last patch doesn't work. My test case works with all but this one
applied, but this breaks it. I haven't had a chance to look into why
yet. Sorry.
NeilBrown
> ---
> drivers/staging/mt7621-dts/gbpc1.dts | 10 ++--
> drivers/staging/mt7621-dts/mt7621.dtsi | 31 ++--
> drivers/staging/mt7621-gpio/gpio-mt7621.c | 21
> .../staging/mt7621-gpio/mediatek,mt7621-gpio.txt | 59
> +-
> 4 files changed, 31 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/staging/mt7621-dts/gbpc1.dts
> b/drivers/staging/mt7621-dts/gbpc1.dts
> index 6b13d85..352945d 100644
> --- a/drivers/staging/mt7621-dts/gbpc1.dts
> +++ b/drivers/staging/mt7621-dts/gbpc1.dts
> @@ -32,7 +32,7 @@
>
> reset {
> label = "reset";
> - gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
> + gpios = <&gpio 18 GPIO_ACTIVE_HIGH>;
> linux,code = ;
> };
> };
> @@ -42,22 +42,22 @@
>
> system {
> label = "gb-pc1:green:system";
> - gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
> + gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
> };
>
> status {
> label = "gb-pc1:green:status";
> - gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
> + gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
> };
>
> lan1 {
> label = "gb-pc1:green:lan1";
> - gpios = <&gpio0 24 GPIO_ACTIVE_LOW>;
> + gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
> };
>
> lan2 {
> label = "gb-pc1:green:lan2";
> - gpios = <&gpio0 25 GPIO_ACTIVE_LOW>;
> + gpios = <&gpio 25 GPIO_ACTIVE_LOW>;
> };
> };
> };
> diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
> b/drivers/staging/mt7621-dts/mt7621.dtsi
> index acb6b8c..02746af 100644
> --- a/drivers/staging/mt7621-dts/mt7621.dtsi
> +++ b/drivers/staging/mt7621-dts/mt7621.dtsi
> @@ -61,37 +61,14 @@
> };
>
> gpio: gpio@600 {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> + #gpio-cells = <2>;
> + #interrupt-cells = <2>;
> compatible = "mediatek,mt7621-gpio";
> + gpio-controller;
> + interrupt-controller;
> reg = <0x600 0x100>;
> -
> interrupt-parent = <&gic>;
> interrupts = ;
> - interrupt-controller;
> - #interrupt-cells = <2>;
> -
> - gpio0: bank@0 {
> - reg = <0>;
> - compatible = "mediatek,mt7621-gpio-bank";
> - gpio-controller;
> - #gpio-cells = <2>;
> - };
> -
> - gpio1: bank@1 {
> - reg = <1>;
> - compatible = "mediatek,mt7621-gpio-bank";
> - gpio-controller;
> - #gpio-cells = <2>;
> - };
> -
> - gpio2: bank@2 {
> - reg = <2>;
> - compatible = "mediatek,mt7621-gpio-bank";
> - gpio-controller;
> - #gpio-cells = <2>;
> - };
> };
>
> i2c: i2c@900 {
> diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
> b/drivers/staging/mt7621-gpio/gpio-mt7621.c
> index 9a4a12f..281e621 100644
> --- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
> +++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
> @@ -206,23 +206,20 @@ static inline const char * const
> mediatek_gpio_bank_name(int bank)
> }
>
> static int
> -mediatek_gpio_bank_probe(struct platform_device *pdev, struct device_node
> *bank)
> +mediatek_gpio_bank_probe(struct platform_device *pdev,
> + struct device_node *node, int bank)
> {
> struct mtk_data *gpio = dev_get_drvdata(&pdev->dev);
> - const __be32 *id = of_get_property(bank, "reg", NULL);
> struct mtk_gc *rg;
> void __iomem *dat, *set, *ctrl, *diro;
> int ret;
>
> - if
[PATCH net] hv_netvsc: split sub-channel setup into async and sync
From: Stephen Hemminger
When doing device hotplug the sub channel must be async to avoid
deadlock issues because device is discovered in softirq context.
When doing changes to MTU and number of channels, the setup
must be synchronous to avoid races such as when MTU and device
settings are done in a single ip command.
Reported-by: Thomas Walker
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Fixes: 732e49850c5e ("netvsc: fix race on sub channel creation")
Signed-off-by: Stephen Hemminger
Signed-off-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 2 +-
drivers/net/hyperv/netvsc.c | 37 ++-
drivers/net/hyperv/netvsc_drv.c | 17 -
drivers/net/hyperv/rndis_filter.c | 61 ++-
4 files changed, 65 insertions(+), 52 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 1a924b867b07..4b6e308199d2 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -210,7 +210,7 @@ int netvsc_recv_callback(struct net_device *net,
void netvsc_channel_cb(void *context);
int netvsc_poll(struct napi_struct *napi, int budget);
-void rndis_set_subchannel(struct work_struct *w);
+int rndis_set_subchannel(struct net_device *ndev, struct netvsc_device *nvdev);
int rndis_filter_open(struct netvsc_device *nvdev);
int rndis_filter_close(struct netvsc_device *nvdev);
struct netvsc_device *rndis_filter_device_add(struct hv_device *dev,
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 5d5bd513847f..8e9d0ee1572b 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -65,6 +65,41 @@ void netvsc_switch_datapath(struct net_device *ndev, bool vf)
VM_PKT_DATA_INBAND, 0);
}
+/* Worker to setup sub channels on initial setup
+ * Initial hotplug event occurs in softirq context
+ * and can't wait for channels.
+ */
+static void netvsc_subchan_work(struct work_struct *w)
+{
+ struct netvsc_device *nvdev =
+ container_of(w, struct netvsc_device, subchan_work);
+ struct rndis_device *rdev;
+ int i, ret;
+
+ /* Avoid deadlock with device removal already under RTNL */
+ if (!rtnl_trylock()) {
+ schedule_work(w);
+ return;
+ }
+
+ rdev = nvdev->extension;
+ if (rdev) {
+ ret = rndis_set_subchannel(rdev->ndev, nvdev);
+ if (ret == 0) {
+ netif_device_attach(rdev->ndev);
+ } else {
+ /* fallback to only primary channel */
+ for (i = 1; i < nvdev->num_chn; i++)
+ netif_napi_del(&nvdev->chan_table[i].napi);
+
+ nvdev->max_chn = 1;
+ nvdev->num_chn = 1;
+ }
+ }
+
+ rtnl_unlock();
+}
+
static struct netvsc_device *alloc_net_device(void)
{
struct netvsc_device *net_device;
@@ -81,7 +116,7 @@ static struct netvsc_device *alloc_net_device(void)
init_completion(&net_device->channel_init_wait);
init_waitqueue_head(&net_device->subchan_open);
- INIT_WORK(&net_device->subchan_work, rndis_set_subchannel);
+ INIT_WORK(&net_device->subchan_work, netvsc_subchan_work);
return net_device;
}
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index fe2256bf1d13..dd1d6e115145 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -905,8 +905,20 @@ static int netvsc_attach(struct net_device *ndev,
if (IS_ERR(nvdev))
return PTR_ERR(nvdev);
- /* Note: enable and attach happen when sub-channels setup */
+ if (nvdev->num_chn > 1) {
+ ret = rndis_set_subchannel(ndev, nvdev);
+
+ /* if unavailable, just proceed with one queue */
+ if (ret) {
+ nvdev->max_chn = 1;
+ nvdev->num_chn = 1;
+ }
+ }
+
+ /* In any case device is now ready */
+ netif_device_attach(ndev);
+ /* Note: enable and attach happen when sub-channels setup */
netif_carrier_off(ndev);
if (netif_running(ndev)) {
@@ -2089,6 +2101,9 @@ static int netvsc_probe(struct hv_device *dev,
memcpy(net->dev_addr, device_info.mac_adr, ETH_ALEN);
+ if (nvdev->num_chn > 1)
+ schedule_work(&nvdev->subchan_work);
+
/* hw_features computed in rndis_netdev_set_hwcaps() */
net->features = net->hw_features |
NETIF_F_HIGHDMA | NETIF_F_SG |
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 5428bb261102..9b4e3c3787e5 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1062,29 +1062,15 @@ static void netvsc_sc_open(struct vmbus_channel *new_sc)
* This breaks overlap of processin
Hello
I believe you've a busy schedule and this is the only means I can get to you, I have a deal for you rely for more details ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] gpio: mediatek: add driver for MT7621
On Fri, Jun 29, 2018 at 6:52 PM, Sergio Paracuellos
wrote:
> On Fri, Jun 29, 2018 at 6:43 PM, kbuild test robot wrote:
>> Hi Sergio,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on gpio/for-next]
>> [also build test ERROR on v4.18-rc2 next-20180629]
>> [if your patch is applied to the wrong git tree, please drop us a note to
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Sergio-Paracuellos/gpio-mediatek-driver-for-gpio-chip-in-MT7621-SoC/20180629-225420
>> base:
>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
>> for-next
>> config: x86_64-randconfig-s0-06292230 (attached as .config)
>> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
>> reproduce:
>> # save the attached .config to linux build tree
>> make ARCH=x86_64
>>
>> All errors (new ones prefixed by >>):
>>
>>drivers/gpio/gpio-mt7621.c: In function 'mediatek_gpio_bank_probe':
>>>> drivers/gpio/gpio-mt7621.c:221:10: error: 'struct gpio_chip' has no member
>>>> named 'of_node'
>> rg->chip.of_node = node;
>> ^
>
> Should I have to add #ifdef CONFIG_OF_GPIO for this line? Is kind of
> ugly hack... Does exist another way to fix this?
>
Ah, this is v2 where the Makefile was wrong... I though it was v3. I
think we can ignore this and see what happen with likely correct v3.
Best regards,
Sergio Paracuellos
> Thanks,
> Sergio Paracuellos
>
>>
>> vim +221 drivers/gpio/gpio-mt7621.c
>>
>>207
>>208 static int
>>209 mediatek_gpio_bank_probe(struct platform_device *pdev,
>>210 struct device_node *node, int bank)
>>211 {
>>212 struct mtk_data *gpio = dev_get_drvdata(&pdev->dev);
>>213 struct mtk_gc *rg;
>>214 void __iomem *dat, *set, *ctrl, *diro;
>>215 int ret;
>>216
>>217 rg = &gpio->gc_map[bank];
>>218 memset(rg, 0, sizeof(*rg));
>>219
>>220 spin_lock_init(&rg->lock);
>> > 221 rg->chip.of_node = node;
>>222 rg->bank = bank;
>>223 rg->chip.label = mediatek_gpio_bank_name(rg->bank);
>>224
>>225 dat = gpio->gpio_membase + GPIO_REG_DATA + (rg->bank *
>> GPIO_BANK_WIDE);
>>226 set = gpio->gpio_membase + GPIO_REG_DSET + (rg->bank *
>> GPIO_BANK_WIDE);
>>227 ctrl = gpio->gpio_membase + GPIO_REG_DCLR + (rg->bank *
>> GPIO_BANK_WIDE);
>>228 diro = gpio->gpio_membase + GPIO_REG_CTRL + (rg->bank *
>> GPIO_BANK_WIDE);
>>229
>>230 ret = bgpio_init(&rg->chip, &pdev->dev, 4,
>>231 dat, set, ctrl, diro, NULL, 0);
>>232 if (ret) {
>>233 dev_err(&pdev->dev, "bgpio_init() failed\n");
>>234 return ret;
>>235 }
>>236
>>237 ret = devm_gpiochip_add_data(&pdev->dev, &rg->chip, gpio);
>>238 if (ret < 0) {
>>239 dev_err(&pdev->dev, "Could not register gpio %d,
>> ret=%d\n",
>>240 rg->chip.ngpio, ret);
>>241 return ret;
>>242 }
>>243
>>244 if (gpio->gpio_irq) {
>>245 /*
>>246 * Manually request the irq here instead of passing
>>247 * a flow-handler to gpiochip_set_chained_irqchip,
>>248 * because the irq is shared.
>>249 */
>>250 ret = devm_request_irq(&pdev->dev, gpio->gpio_irq,
>>251 mediatek_gpio_irq_handler,
>> IRQF_SHARED,
>>252 rg->chip.label, &rg->chip);
>>253
>>254 if (ret) {
>>255 dev_err(&pdev->dev, "Error requesting IRQ
>> %d: %d\n",
>>256 gpio->gpio_irq, ret);
>>257 return ret;
>>258 }
>>259
>>260 mediatek_gpio_irq_chip.name = rg->chip.label;
>>261
[PATCH] staging: rtl8188eu: remove unnecessary parentheses
Remove unnecessary parentheses as reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index 53c6ca85d69f..53e518148ae5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
@@ -81,7 +81,7 @@ u32 _rtw_init_sta_priv(struct sta_priv *pstapriv)
for (i = 0; i < NUM_STA; i++) {
_rtw_init_stainfo(psta);
- INIT_LIST_HEAD(&(pstapriv->sta_hash[i]));
+ INIT_LIST_HEAD(&pstapriv->sta_hash[i]);
list_add_tail(&psta->list,
get_list_head(&pstapriv->free_sta_queue));
@@ -138,7 +138,7 @@ u32 _rtw_free_sta_priv(struct sta_priv *pstapriv)
/* delete all reordering_ctrl_timer*/
spin_lock_bh(&pstapriv->sta_hash_lock);
for (index = 0; index < NUM_STA; index++) {
- phead = &(pstapriv->sta_hash[index]);
+ phead = &pstapriv->sta_hash[index];
plist = phead->next;
while (phead != plist) {
@@ -266,19 +266,19 @@ u32 rtw_free_stainfo(struct adapter *padapter,
struct sta_info *psta)
rtw_free_xmitframe_queue(pxmitpriv, &pstaxmitpriv->vo_q.sta_pending);
- list_del_init(&(pstaxmitpriv->vo_q.tx_pending));
+ list_del_init(&pstaxmitpriv->vo_q.tx_pending);
rtw_free_xmitframe_queue(pxmitpriv, &pstaxmitpriv->vi_q.sta_pending);
- list_del_init(&(pstaxmitpriv->vi_q.tx_pending));
+ list_del_init(&pstaxmitpriv->vi_q.tx_pending);
rtw_free_xmitframe_queue(pxmitpriv, &pstaxmitpriv->bk_q.sta_pending);
- list_del_init(&(pstaxmitpriv->bk_q.tx_pending));
+ list_del_init(&pstaxmitpriv->bk_q.tx_pending);
rtw_free_xmitframe_queue(pxmitpriv, &pstaxmitpriv->be_q.sta_pending);
- list_del_init(&(pstaxmitpriv->be_q.tx_pending));
+ list_del_init(&pstaxmitpriv->be_q.tx_pending);
spin_unlock_bh(&pxmitpriv->lock);
@@ -319,7 +319,7 @@ u32 rtw_free_stainfo(struct adapter *padapter, struct
sta_info *psta)
plist = plist->next;
- list_del_init(&(prframe->list));
+ list_del_init(&prframe->list);
rtw_free_recvframe(prframe, pfree_recv_queue);
}
@@ -363,7 +363,7 @@ u32 rtw_free_stainfo(struct adapter *padapter, struct
sta_info *psta)
#endif /* CONFIG_88EU_AP_MODE */
- spin_lock_bh(&(pfree_sta_queue->lock));
+ spin_lock_bh(&pfree_sta_queue->lock);
list_add_tail(&psta->list, get_list_head(pfree_sta_queue));
spin_unlock_bh(&pfree_sta_queue->lock);
@@ -387,7 +387,7 @@ void rtw_free_all_stainfo(struct adapter *padapter)
spin_lock_bh(&pstapriv->sta_hash_lock);
for (index = 0; index < NUM_STA; index++) {
- phead = &(pstapriv->sta_hash[index]);
+ phead = &pstapriv->sta_hash[index];
plist = phead->next;
while (phead != plist) {
@@ -423,7 +423,7 @@ struct sta_info *rtw_get_stainfo(struct sta_priv *pstapriv,
u8 *hwaddr)
spin_lock_bh(&pstapriv->sta_hash_lock);
- phead = &(pstapriv->sta_hash[index]);
+ phead = &pstapriv->sta_hash[index];
plist = phead->next;
while (phead != plist) {
@@ -481,7 +481,7 @@ u8 rtw_access_ctrl(struct adapter *padapter, u8 *mac_addr)
struct wlan_acl_pool *pacl_list = &pstapriv->acl_list;
struct __queue *pacl_node_q = &pacl_list->acl_node_q;
- spin_lock_bh(&(pacl_node_q->lock));
+ spin_lock_bh(&pacl_node_q->lock);
phead = get_list_head(pacl_node_q);
plist = phead->next;
while (phead != plist) {
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fbtft: fix line indent
On Fri, Jun 29, 2018 at 05:20:32PM +0200, Radek Dostál wrote: > Signed-off-by: Radek Dostál > --- > drivers/staging/fbtft/fbtft_device.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: rtl8192u Remove redundant #include directive
The file includes the file rtl819x_HT.h, which has already been included by
the previously included file ieee80211.h
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index a4fbc0435de5..3ce9ab6ab64f 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -5,7 +5,7 @@
* little changed. If any confusion caused, tell me. Created by WB. 2008.05.08
*/
#include "ieee80211.h"
-#include "rtl819x_HT.h"
+
u8 MCS_FILTER_ALL[16] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0x1f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
u8 MCS_FILTER_1SS[16] = {0xff, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: rtl8192u: Use __func__ instead of hardcoded string - Style
Chnaged logging statements to use %s and __func__ instead of hard coding the
function name in a string.
Signed-off-by: John Whitmore
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
index 1dd4c6ae7319..a4fbc0435de5 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
@@ -534,7 +534,7 @@ void HTConstructCapabilityElement(struct ieee80211_device
*ieee, u8 *posHTCap, u
//u8 bIsDeclareMCS13;
if (!posHTCap || !pHT) {
- IEEE80211_DEBUG(IEEE80211_DL_ERR, "posHTCap or pHTInfo can't be
null in HTConstructCapabilityElement()\n");
+ IEEE80211_DEBUG(IEEE80211_DL_ERR, "posHTCap or pHTInfo can't be
null in %s\n", __func__);
return;
}
memset(posHTCap, 0, *len);
@@ -645,7 +645,7 @@ void HTConstructInfoElement(struct ieee80211_device *ieee,
u8 *posHTInfo, u8 *le
PHT_INFORMATION_ELE pHTInfoEle =
(PHT_INFORMATION_ELE)posHTInfo;
if (!posHTInfo || !pHTInfoEle) {
- IEEE80211_DEBUG(IEEE80211_DL_ERR, "posHTInfo or pHTInfoEle
can't be null in HTConstructInfoElement()\n");
+ IEEE80211_DEBUG(IEEE80211_DL_ERR, "posHTInfo or pHTInfoEle
can't be null in %s\n", __func__);
return;
}
@@ -709,7 +709,7 @@ void HTConstructInfoElement(struct ieee80211_device *ieee,
u8 *posHTInfo, u8 *le
void HTConstructRT2RTAggElement(struct ieee80211_device *ieee, u8
*posRT2RTAgg, u8 *len)
{
if (!posRT2RTAgg) {
- IEEE80211_DEBUG(IEEE80211_DL_ERR, "posRT2RTAgg can't be null in
HTConstructRT2RTAggElement()\n");
+ IEEE80211_DEBUG(IEEE80211_DL_ERR, "posRT2RTAgg can't be null in
%s\n", __func__);
return;
}
memset(posRT2RTAgg, 0, *len);
@@ -758,7 +758,7 @@ static u8 HT_PickMCSRate(struct ieee80211_device *ieee, u8
*pOperateMCS)
u8 i;
if (!pOperateMCS) {
- IEEE80211_DEBUG(IEEE80211_DL_ERR, "pOperateMCS can't be null in
HT_PickMCSRate()\n");
+ IEEE80211_DEBUG(IEEE80211_DL_ERR, "pOperateMCS can't be null in
%s\n", __func__);
return false;
}
@@ -820,7 +820,7 @@ u8 HTGetHighestMCSRate(struct ieee80211_device *ieee, u8
*pMCSRateSet, u8 *pMCSF
u8 availableMcsRate[16];
if (!pMCSRateSet || !pMCSFilter) {
- IEEE80211_DEBUG(IEEE80211_DL_ERR, "pMCSRateSet or pMCSFilter
can't be null in HTGetHighestMCSRate()\n");
+ IEEE80211_DEBUG(IEEE80211_DL_ERR, "pMCSRateSet or pMCSFilter
can't be null in %s\n", __func__);
return false;
}
for (i = 0; i < 16; i++)
@@ -900,7 +900,7 @@ void HTOnAssocRsp(struct ieee80211_device *ieee)
static u8 EWC11NHTInfo[] = {0x00, 0x90,
0x4c, 0x34}; // For 11n EWC definition, 2007.07.17, by Emily
if (!pHTInfo->bCurrentHTSupport) {
- IEEE80211_DEBUG(IEEE80211_DL_ERR, "<=== HTOnAssocRsp():
HT_DISABLE\n");
+ IEEE80211_DEBUG(IEEE80211_DL_ERR, "<=== %s: HT_DISABLE\n",
__func__);
return;
}
IEEE80211_DEBUG(IEEE80211_DL_HT, "===> HTOnAssocRsp_wq(): HT_ENABLE\n");
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
staging: rtl8192u: RFC - harmonisation of rtl819x_HT.h ?
This patch set includes two fairly trivial patches but the third patch is possibly controversial. There are two files called rtl819x_HT.h $ find -name rtl819x_HT.h -print ./drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h ./drivers/staging/rtl8192e/rtl819x_HT.h The two files are very similar but the rtl8192u file includes more, and I think unused, definitions definitions. My, possibly flawed, thinking is that it might be easier to maintain a single file if the two could be merged into a single include file. As a first step towards this my third patch comments out unused definitions, from ./drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h At this point I have compiled all c files under ./drivers/staging/rtl8192u and all still compile. I may well have missed something, but I assume that no source file outside that sub tree should be including header files from that subtree. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: rtl8192u: Prune the rtl819x_HT.h file of unused definitions.
There are two files named "rtl819x_HT.h"
$ find . -name rtl819x_HT.h -print
./drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
./drivers/staging/rtl8192e/rtl819x_HT.h
The two files are very similar but differ slightly. Unsed definitions have
been removed from "drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h" as a first
step towards possibly merging the two files into one.
Signed-off-by: John Whitmore
---
.../staging/rtl8192u/ieee80211/rtl819x_HT.h | 190 +-
1 file changed, 93 insertions(+), 97 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
index a85036022aa8..30a00c73dd06 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
@@ -10,17 +10,17 @@
//
// Operation mode value
//
-#define HT_OPMODE_NO_PROTECT 0
-#define HT_OPMODE_OPTIONAL 1
-#define HT_OPMODE_40MHZ_PROTECT2
-#define HT_OPMODE_MIXED3
+//#define HT_OPMODE_NO_PROTECT 0
+//#define HT_OPMODE_OPTIONAL 1
+//#define HT_OPMODE_40MHZ_PROTECT 2
+//#define HT_OPMODE_MIXED 3
//
// MIMO Power Save Settings
//
#define MIMO_PS_STATIC 0
-#define MIMO_PS_DYNAMIC1
-#define MIMO_PS_NOLIMIT3
+//#define MIMO_PS_DYNAMIC 1
+//#define MIMO_PS_NOLIMIT 3
//
@@ -35,26 +35,25 @@
#define HT_SUPPORTED_MCS_2SS_BITMAP
0xff00
#define HT_SUPPORTED_MCS_1SS_2SS_BITMAP
HT_MCS_1SS_BITMAP|HT_MCS_1SS_2SS_BITMAP
-
-typedef enum _HT_MCS_RATE {
- HT_MCS0 = 0x0001,
- HT_MCS1 = 0x0002,
- HT_MCS2 = 0x0004,
- HT_MCS3 = 0x0008,
- HT_MCS4 = 0x0010,
- HT_MCS5 = 0x0020,
- HT_MCS6 = 0x0040,
- HT_MCS7 = 0x0080,
- HT_MCS8 = 0x0100,
- HT_MCS9 = 0x0200,
- HT_MCS10 = 0x0400,
- HT_MCS11 = 0x0800,
- HT_MCS12 = 0x1000,
- HT_MCS13 = 0x2000,
- HT_MCS14 = 0x4000,
- HT_MCS15 = 0x8000,
- // Do not define MCS32 here although 8190 support MCS32
-} HT_MCS_RATE, *PHT_MCS_RATE;
+//typedef enum _HT_MCS_RATE {
+// HT_MCS0 = 0x0001,
+// HT_MCS1 = 0x0002,
+// HT_MCS2 = 0x0004,
+// HT_MCS3 = 0x0008,
+// HT_MCS4 = 0x0010,
+// HT_MCS5 = 0x0020,
+// HT_MCS6 = 0x0040,
+// HT_MCS7 = 0x0080,
+// HT_MCS8 = 0x0100,
+// HT_MCS9 = 0x0200,
+// HT_MCS10 = 0x0400,
+// HT_MCS11 = 0x0800,
+// HT_MCS12 = 0x1000,
+// HT_MCS13 = 0x2000,
+// HT_MCS14 = 0x4000,
+// HT_MCS15 = 0x8000,
+// // Do not define MCS32 here although 8190 support MCS32
+//} HT_MCS_RATE, *PHT_MCS_RATE;
//
// Represent Channel Width in HT Capabilities
@@ -120,27 +119,26 @@ typedef union _HT_CAPABILITY_MACPARA{
}HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
*/
-typedef enum _HT_ACTION {
- ACT_RECOMMAND_WIDTH = 0,
- ACT_MIMO_PWR_SAVE = 1,
- ACT_PSMP= 2,
- ACT_SET_PCO_PHASE = 3,
- ACT_MIMO_CHL_MEASURE= 4,
- ACT_RECIPROCITY_CORRECT = 5,
- ACT_MIMO_CSI_MATRICS= 6,
- ACT_MIMO_NOCOMPR_STEER = 7,
- ACT_MIMO_COMPR_STEER= 8,
- ACT_ANTENNA_SELECT = 9,
-} HT_ACTION, *PHT_ACTION;
-
+//typedef enum _HT_ACTION {
+// ACT_RECOMMAND_WIDTH = 0,
+// ACT_MIMO_PWR_SAVE = 1,
+// ACT_PSMP= 2,
+// ACT_SET_PCO_PHASE = 3,
+// ACT_MIMO_CHL_MEASURE= 4,
+// ACT_RECIPROCITY_CORRECT = 5,
+// ACT_MIMO_CSI_MATRICS= 6,
+// ACT_MIMO_NOCOMPR_STEER = 7,
+// ACT_MIMO_COMPR_STEER= 8,
+// ACT_ANTENNA_SELECT = 9,
+//} HT_ACTION, *PHT_ACTION;
/* 2007/06/07 MH Define sub-carrier mode for 40MHZ. */
-typedef enum _HT_Bandwidth_40MHZ_Sub_Carrier {
- SC_MODE_DUPLICATE = 0,
- SC_MODE_LOWER = 1,
- SC_MODE_UPPER = 2,
- SC_MODE_FULL40MHZ = 3,
-}HT_BW40_SC_E;
+//typedef enum _HT_Bandwidth_40MHZ_Sub_Carrier {
+// SC_MODE_DUPLICATE = 0,
+// SC_MODE_LOWER = 1,
+// SC_MODE_UPPER = 2,
+// SC_MODE_FULL40MHZ = 3,
+//}HT_BW40_SC_E;
typedefstruct _HT_CAPABILITY_ELE {
@@ -216,11 +214,11 @@ typedef struct _HT_INFORMATION_ELE {
// MIMO Power Save control field.
// This is appear in MIMO Power Save Action Frame
//
-typedef struct _MIMOPS_CTRL {
- u8 MimoPsEnable:1;
- u8 MimoPsMode:1;
- u8 Reserved:6;
-} MIMOPS_CTRL, *PMIMOPS_CTRL;
+//typedef struct _MIMOPS_CTRL {
+// u8 MimoPsEnable:1;
+// u8 Mimo
Re: [PATCH v2 1/2] gpio: mediatek: add driver for MT7621
On Fri, Jun 29, 2018 at 6:43 PM, kbuild test robot wrote:
> Hi Sergio,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on gpio/for-next]
> [also build test ERROR on v4.18-rc2 next-20180629]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Sergio-Paracuellos/gpio-mediatek-driver-for-gpio-chip-in-MT7621-SoC/20180629-225420
> base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
> for-next
> config: x86_64-randconfig-s0-06292230 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>drivers/gpio/gpio-mt7621.c: In function 'mediatek_gpio_bank_probe':
>>> drivers/gpio/gpio-mt7621.c:221:10: error: 'struct gpio_chip' has no member
>>> named 'of_node'
> rg->chip.of_node = node;
> ^
Should I have to add #ifdef CONFIG_OF_GPIO for this line? Is kind of
ugly hack... Does exist another way to fix this?
Thanks,
Sergio Paracuellos
>
> vim +221 drivers/gpio/gpio-mt7621.c
>
>207
>208 static int
>209 mediatek_gpio_bank_probe(struct platform_device *pdev,
>210 struct device_node *node, int bank)
>211 {
>212 struct mtk_data *gpio = dev_get_drvdata(&pdev->dev);
>213 struct mtk_gc *rg;
>214 void __iomem *dat, *set, *ctrl, *diro;
>215 int ret;
>216
>217 rg = &gpio->gc_map[bank];
>218 memset(rg, 0, sizeof(*rg));
>219
>220 spin_lock_init(&rg->lock);
> > 221 rg->chip.of_node = node;
>222 rg->bank = bank;
>223 rg->chip.label = mediatek_gpio_bank_name(rg->bank);
>224
>225 dat = gpio->gpio_membase + GPIO_REG_DATA + (rg->bank *
> GPIO_BANK_WIDE);
>226 set = gpio->gpio_membase + GPIO_REG_DSET + (rg->bank *
> GPIO_BANK_WIDE);
>227 ctrl = gpio->gpio_membase + GPIO_REG_DCLR + (rg->bank *
> GPIO_BANK_WIDE);
>228 diro = gpio->gpio_membase + GPIO_REG_CTRL + (rg->bank *
> GPIO_BANK_WIDE);
>229
>230 ret = bgpio_init(&rg->chip, &pdev->dev, 4,
>231 dat, set, ctrl, diro, NULL, 0);
>232 if (ret) {
>233 dev_err(&pdev->dev, "bgpio_init() failed\n");
>234 return ret;
>235 }
>236
>237 ret = devm_gpiochip_add_data(&pdev->dev, &rg->chip, gpio);
>238 if (ret < 0) {
>239 dev_err(&pdev->dev, "Could not register gpio %d,
> ret=%d\n",
>240 rg->chip.ngpio, ret);
>241 return ret;
>242 }
>243
>244 if (gpio->gpio_irq) {
>245 /*
>246 * Manually request the irq here instead of passing
>247 * a flow-handler to gpiochip_set_chained_irqchip,
>248 * because the irq is shared.
>249 */
>250 ret = devm_request_irq(&pdev->dev, gpio->gpio_irq,
>251 mediatek_gpio_irq_handler,
> IRQF_SHARED,
>252 rg->chip.label, &rg->chip);
>253
>254 if (ret) {
>255 dev_err(&pdev->dev, "Error requesting IRQ %d:
> %d\n",
>256 gpio->gpio_irq, ret);
>257 return ret;
>258 }
>259
>260 mediatek_gpio_irq_chip.name = rg->chip.label;
>261 ret = gpiochip_irqchip_add(&rg->chip,
> &mediatek_gpio_irq_chip,
>262 0, handle_simple_irq,
> IRQ_TYPE_NONE);
>263 if (ret) {
>264 dev_err(&pdev->dev, "failed to add
> gpiochip_irqchip\n");
>265 return ret;
>266 }
>267
>268 gpiochip_set_chained_irqchip(&rg->chip,
> &mediatek_gpio_irq_chip,
>269 gpio->gpio_irq, NULL);
>270 }
>
Re: [PATCH v2 1/2] gpio: mediatek: add driver for MT7621
Hi Sergio,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.18-rc2 next-20180629]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sergio-Paracuellos/gpio-mediatek-driver-for-gpio-chip-in-MT7621-SoC/20180629-225420
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
for-next
config: x86_64-randconfig-s0-06292230 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpio/gpio-mt7621.c: In function 'mediatek_gpio_bank_probe':
>> drivers/gpio/gpio-mt7621.c:221:10: error: 'struct gpio_chip' has no member
>> named 'of_node'
rg->chip.of_node = node;
^
vim +221 drivers/gpio/gpio-mt7621.c
207
208 static int
209 mediatek_gpio_bank_probe(struct platform_device *pdev,
210 struct device_node *node, int bank)
211 {
212 struct mtk_data *gpio = dev_get_drvdata(&pdev->dev);
213 struct mtk_gc *rg;
214 void __iomem *dat, *set, *ctrl, *diro;
215 int ret;
216
217 rg = &gpio->gc_map[bank];
218 memset(rg, 0, sizeof(*rg));
219
220 spin_lock_init(&rg->lock);
> 221 rg->chip.of_node = node;
222 rg->bank = bank;
223 rg->chip.label = mediatek_gpio_bank_name(rg->bank);
224
225 dat = gpio->gpio_membase + GPIO_REG_DATA + (rg->bank *
GPIO_BANK_WIDE);
226 set = gpio->gpio_membase + GPIO_REG_DSET + (rg->bank *
GPIO_BANK_WIDE);
227 ctrl = gpio->gpio_membase + GPIO_REG_DCLR + (rg->bank *
GPIO_BANK_WIDE);
228 diro = gpio->gpio_membase + GPIO_REG_CTRL + (rg->bank *
GPIO_BANK_WIDE);
229
230 ret = bgpio_init(&rg->chip, &pdev->dev, 4,
231 dat, set, ctrl, diro, NULL, 0);
232 if (ret) {
233 dev_err(&pdev->dev, "bgpio_init() failed\n");
234 return ret;
235 }
236
237 ret = devm_gpiochip_add_data(&pdev->dev, &rg->chip, gpio);
238 if (ret < 0) {
239 dev_err(&pdev->dev, "Could not register gpio %d,
ret=%d\n",
240 rg->chip.ngpio, ret);
241 return ret;
242 }
243
244 if (gpio->gpio_irq) {
245 /*
246 * Manually request the irq here instead of passing
247 * a flow-handler to gpiochip_set_chained_irqchip,
248 * because the irq is shared.
249 */
250 ret = devm_request_irq(&pdev->dev, gpio->gpio_irq,
251 mediatek_gpio_irq_handler,
IRQF_SHARED,
252 rg->chip.label, &rg->chip);
253
254 if (ret) {
255 dev_err(&pdev->dev, "Error requesting IRQ %d:
%d\n",
256 gpio->gpio_irq, ret);
257 return ret;
258 }
259
260 mediatek_gpio_irq_chip.name = rg->chip.label;
261 ret = gpiochip_irqchip_add(&rg->chip,
&mediatek_gpio_irq_chip,
262 0, handle_simple_irq,
IRQ_TYPE_NONE);
263 if (ret) {
264 dev_err(&pdev->dev, "failed to add
gpiochip_irqchip\n");
265 return ret;
266 }
267
268 gpiochip_set_chained_irqchip(&rg->chip,
&mediatek_gpio_irq_chip,
269 gpio->gpio_irq, NULL);
270 }
271
272 /* set polarity to low for all gpios */
273 mtk_gpio_w32(rg, GPIO_REG_POL, 0);
274
275 dev_info(&pdev->dev, "registering %d gpios\n", rg->chip.ngpio);
276
277 return 0;
278 }
279
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fbtft: fix line indent
Signed-off-by: Radek Dostál
---
drivers/staging/fbtft/fbtft_device.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft_device.c
b/drivers/staging/fbtft/fbtft_device.c
index 4a54b46..cad244c 100644
--- a/drivers/staging/fbtft/fbtft_device.c
+++ b/drivers/staging/fbtft/fbtft_device.c
@@ -1232,14 +1232,14 @@ static struct fbtft_device_display displays[] = {
.name = "",
.id = 0,
.dev = {
- .release = fbtft_device_pdev_release,
- .platform_data = &(struct fbtft_platform_data) {
- .gpios = (const struct fbtft_gpio []) {
- {},
+ .release = fbtft_device_pdev_release,
+ .platform_data = &(struct fbtft_platform_data) {
+ .gpios = (const struct fbtft_gpio []) {
+ {},
+ },
},
},
},
- },
}
};
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] pci: host: pci-hyperv: Replace GFP_ATOMIC with GFP_KERNEL in new_pcichild_device
On Sun, Mar 18, 2018 at 10:53:28PM +0800, Jia-Ju Bai wrote: > new_pcichild_device() is not called in atomic context. > > The call chain ending up at new_pcichild_device() is: > [1] new_pcichild_device() <- pci_devices_present_work() > pci_devices_present_work() is only set in INIT_WORK(). > > Despite never getting called from atomic context, > new_pcichild_device() calls kzalloc with GFP_ATOMIC, > which waits busily for allocation. > GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL > to avoid busy waiting. > > This is found by a static analysis tool named DCNS written by myself. > > Signed-off-by: Jia-Ju Bai > --- > drivers/pci/host/pci-hyperv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied to pci/hv for v4.19, thanks. Lorenzo > diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c > index 0fe3ea1..289e31d 100644 > --- a/drivers/pci/host/pci-hyperv.c > +++ b/drivers/pci/host/pci-hyperv.c > @@ -1500,7 +1500,7 @@ static struct hv_pci_dev *new_pcichild_device(struct > hv_pcibus_device *hbus, > unsigned long flags; > int ret; > > - hpdev = kzalloc(sizeof(*hpdev), GFP_ATOMIC); > + hpdev = kzalloc(sizeof(*hpdev), GFP_KERNEL); > if (!hpdev) > return NULL; > > -- > 1.9.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] gpio: mediatek: add driver for MT7621
On Fri, Jun 29, 2018 at 3:31 PM, Dan Carpenter wrote: > Looks pretty clean to me. Sorry for not reviewing v1. Smatch (private > devel version) points out a little bit of dead code. > > drivers/staging/mt7621-gpio/gpio-mt7621.c:200 mediatek_gpio_irq_handler() > warn: address of 'gpio_data->gc_map[i]' is non-NULL > drivers/staging/mt7621-gpio/gpio-mt7621.c:225 mediatek_gpio_irq_unmask() > warn: address of 'gpio_data->gc_map[bank]' is non-NULL > drivers/staging/mt7621-gpio/gpio-mt7621.c:246 mediatek_gpio_irq_mask() warn: > address of 'gpio_data->gc_map[bank]' is non-NULL > drivers/staging/mt7621-gpio/gpio-mt7621.c:266 mediatek_gpio_irq_type() warn: > address of 'gpio_data->gc_map[bank]' is non-NULL > > But that's harmless and very minor. That warnings should not being in the staging version. Last patch series was applied yesterday... Maybe you have not run against the updated tree? This patch fix them: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing&id=bfb623c5b0935a2e4b5fe86eab79a37a37b67209 > > regards, > dan carpenter Thanks. Best regards, Sergio Paracuellos > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] gpio: mediatek: add driver for MT7621
On Fri, Jun 29, 2018 at 04:31:35PM +0300, Dan Carpenter wrote: > Looks pretty clean to me. Sorry for not reviewing v1. Smatch (private > devel version) points out a little bit of dead code. > > drivers/staging/mt7621-gpio/gpio-mt7621.c:200 mediatek_gpio_irq_handler() > warn: address of 'gpio_data->gc_map[i]' is non-NULL > drivers/staging/mt7621-gpio/gpio-mt7621.c:225 mediatek_gpio_irq_unmask() > warn: address of 'gpio_data->gc_map[bank]' is non-NULL > drivers/staging/mt7621-gpio/gpio-mt7621.c:246 mediatek_gpio_irq_mask() warn: > address of 'gpio_data->gc_map[bank]' is non-NULL > drivers/staging/mt7621-gpio/gpio-mt7621.c:266 mediatek_gpio_irq_type() warn: > address of 'gpio_data->gc_map[bank]' is non-NULL > > But that's harmless and very minor. I think you fixed all these in the non-staging version... That's fine then. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] gpio: mediatek: add driver for MT7621
Looks pretty clean to me. Sorry for not reviewing v1. Smatch (private devel version) points out a little bit of dead code. drivers/staging/mt7621-gpio/gpio-mt7621.c:200 mediatek_gpio_irq_handler() warn: address of 'gpio_data->gc_map[i]' is non-NULL drivers/staging/mt7621-gpio/gpio-mt7621.c:225 mediatek_gpio_irq_unmask() warn: address of 'gpio_data->gc_map[bank]' is non-NULL drivers/staging/mt7621-gpio/gpio-mt7621.c:246 mediatek_gpio_irq_mask() warn: address of 'gpio_data->gc_map[bank]' is non-NULL drivers/staging/mt7621-gpio/gpio-mt7621.c:266 mediatek_gpio_irq_type() warn: address of 'gpio_data->gc_map[bank]' is non-NULL But that's harmless and very minor. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: goldfish: cleanup in goldfish_audio
On Thu, Jun 28, 2018 at 06:19:14PM -0700, r...@google.com wrote:
> From: Roman Kiryanov
>
> * added a mutex to protect open/read/write/release calls;
> * put the global atomic counter for opened files into the
> driver state;
> * retired the global variable for the driver state;
These three should maybe be in the same patch? It's not clear if they
are separate things or related. The changelog should say why you are
doing it because it's not clear.
Right now the code only supports one open at a time. It looks like
this is an effort to add support for multiply opens at the same time
but it's not finished yet?
> * retired the ioctl calls because it does not do much and cmd=315
> looks obsolete.
This change is definitely unrelated.
> static int goldfish_audio_open(struct inode *ip, struct file *fp)
> {
> - if (!audio_data)
> + struct goldfish_audio *audio = fp->private_data;
I've never written a misc driver (or any substantial kernel code at all
if I'm being honest. :P) but I think fp->private_data is a pointer to
&goldfish_audio_device.
But then that wouldn't ever work, and how was this tested then???
> + int status;
> +
> + if (!audio)
> return -ENODEV;
>
> - if (atomic_inc_return(&open_count) == 1) {
> - fp->private_data = audio_data;
> - audio_data->buffer_status = (AUDIO_INT_WRITE_BUFFER_1_EMPTY |
> - AUDIO_INT_WRITE_BUFFER_2_EMPTY);
> - audio_write(audio_data, AUDIO_INT_ENABLE, AUDIO_INT_MASK);
> - return 0;
> + status = mutex_lock_interruptible(&audio->mutex);
> + if (status)
> + return status;
> +
> + if (audio->open_count) {
> + status = -EBUSY;
> + goto done;
> }
>
> - atomic_dec(&open_count);
> - return -EBUSY;
> + ++audio->open_count;
> + audio->buffer_status = (AUDIO_INT_WRITE_BUFFER_1_EMPTY |
> + AUDIO_INT_WRITE_BUFFER_2_EMPTY);
> + audio_write(audio, AUDIO_INT_ENABLE, AUDIO_INT_MASK);
> + fp->private_data = audio;
We set fp->private_data back to itself at the end of the function which
is obviously not right.
> +
> +done:
> + mutex_unlock(&audio->mutex);
> + return status;
> }
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/2] gpio: mediatek: add driver for MT7621
Add driver support for gpio of MT7621 SoC.
Signed-off-by: Sergio Paracuellos
---
drivers/gpio/Kconfig | 8 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mt7621.c | 320 +
3 files changed, 329 insertions(+)
create mode 100644 drivers/gpio/gpio-mt7621.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 71c0ab4..836aa21 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -359,6 +359,14 @@ config GPIO_MPC8XXX
Say Y here if you're going to use hardware that connects to the
MPC512x/831x/834x/837x/8572/8610/QorIQ GPIOs.
+config GPIO_MT7621
+ bool "Mediatek MT7621 GPIO Support"
+ depends on SOC_MT7620 || SOC_MT7621 || COMPILE_TEST
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to support the Mediatek MT7621 SoC GPIO device
+
config GPIO_MVEBU
def_bool y
depends on PLAT_ORION || ARCH_MVEBU
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 1324c8f..fc77989 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
+obj-$(CONFIG_GPIO_MT7621) += gpio-mt7621.o
obj-$(CONFIG_GPIO_MVEBU)+= gpio-mvebu.o
obj-$(CONFIG_GPIO_MXC) += gpio-mxc.o
obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
new file mode 100644
index 000..281e621
--- /dev/null
+++ b/drivers/gpio/gpio-mt7621.c
@@ -0,0 +1,320 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2009-2011 Gabor Juhos
+ * Copyright (C) 2013 John Crispin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_BANK_CNT 3
+#define MTK_BANK_WIDTH 32
+
+#define GPIO_BANK_WIDE 0x04
+#define GPIO_REG_CTRL 0x00
+#define GPIO_REG_POL 0x10
+#define GPIO_REG_DATA 0x20
+#define GPIO_REG_DSET 0x30
+#define GPIO_REG_DCLR 0x40
+#define GPIO_REG_REDGE 0x50
+#define GPIO_REG_FEDGE 0x60
+#define GPIO_REG_HLVL 0x70
+#define GPIO_REG_LLVL 0x80
+#define GPIO_REG_STAT 0x90
+#define GPIO_REG_EDGE 0xA0
+
+struct mtk_gc {
+ struct gpio_chip chip;
+ spinlock_t lock;
+ int bank;
+ u32 rising;
+ u32 falling;
+ u32 hlevel;
+ u32 llevel;
+};
+
+/**
+ * struct mtk_data - state container for
+ * data of the platform driver. It is 3
+ * separate gpio-chip each one with its
+ * own irq_chip.
+ * @dev: device instance
+ * @gpio_membase: memory base address
+ * @gpio_irq: irq number from the device tree
+ * @gc_map: array of the gpio chips
+ */
+struct mtk_data {
+ struct device *dev;
+ void __iomem *gpio_membase;
+ int gpio_irq;
+ struct mtk_gc gc_map[MTK_BANK_CNT];
+};
+
+static inline struct mtk_gc *
+to_mediatek_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct mtk_gc, chip);
+}
+
+static inline void
+mtk_gpio_w32(struct mtk_gc *rg, u32 offset, u32 val)
+{
+ struct gpio_chip *gc = &rg->chip;
+ struct mtk_data *gpio_data = gpiochip_get_data(gc);
+
+ offset = (rg->bank * GPIO_BANK_WIDE) + offset;
+ gc->write_reg(gpio_data->gpio_membase + offset, val);
+}
+
+static inline u32
+mtk_gpio_r32(struct mtk_gc *rg, u32 offset)
+{
+ struct gpio_chip *gc = &rg->chip;
+ struct mtk_data *gpio_data = gpiochip_get_data(gc);
+
+ offset = (rg->bank * GPIO_BANK_WIDE) + offset;
+ return gc->read_reg(gpio_data->gpio_membase + offset);
+}
+
+static irqreturn_t
+mediatek_gpio_irq_handler(int irq, void *data)
+{
+ struct gpio_chip *gc = data;
+ struct mtk_gc *rg = to_mediatek_gpio(gc);
+ irqreturn_t ret = IRQ_NONE;
+ unsigned long pending;
+ int bit;
+
+ pending = mtk_gpio_r32(rg, GPIO_REG_STAT);
+
+ for_each_set_bit(bit, &pending, MTK_BANK_WIDTH) {
+ u32 map = irq_find_mapping(gc->irq.domain, bit);
+
+ generic_handle_irq(map);
+ mtk_gpio_w32(rg, GPIO_REG_STAT, BIT(bit));
+ ret |= IRQ_HANDLED;
+ }
+
+ return ret;
+}
+
+static void
+mediatek_gpio_irq_unmask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct mtk_gc *rg = to_mediatek_gpio(gc);
+ int pin = d->hwirq;
+ unsigned long flags;
+ u32 rise, fall, high, low;
+
+ spin_lock_irqsave(&rg->lock, flags);
+ rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
+ fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
+ high = mtk_gpio_r32(rg, GPIO_REG_HLVL);
+ low = mtk_gpio_r32(rg, GPIO_REG_LLVL);
+ mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (BIT(pin) & rg->rising));
+ mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (BIT(pin) & rg->falling));
+ mtk_gpio_w32(rg, GPIO_REG_
[PATCH v3 2/2] dt-bindings: document gpio-mt7621 bindings
Add a devicetree binding documentation for the mt7621 gpio.
Signed-off-by: Sergio Paracuellos
---
.../bindings/gpio/mediatek,mt7621-gpio.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
new file mode 100644
index 000..ba45558
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
@@ -0,0 +1,35 @@
+Mediatek MT7621 SoC GPIO controller bindings
+
+The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
+The registers of all the banks are interwoven inside one single IO range.
+We load one GPIO controller instance per bank. Also the GPIO controller can
receive
+interrupts on any of the GPIOs, either edge or level. It then interrupts the
CPU
+using GIC INT12.
+
+Required properties for the top level node:
+- #gpio-cells : Should be two. The first cell is the GPIO pin number and the
+ second cell specifies GPIO flags, as defined in .
+ Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt. Should be 2. The first cell defines the interrupt number,
+ the second encodes the triger flags encoded as described in
+ Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+- compatible:
+ - "mediatek,mt7621-gpio" for Mediatek controllers
+- reg : Physical base address and length of the controller's registers
+- interrupt-parent : phandle of the parent interrupt controller.
+- interrupts : Interrupt specifier for the controllers interrupt.
+- interrupt-controller : Mark the device node as an interrupt controller.
+- gpio-controller : Marks the device node as a GPIO controller.
+
+Example:
+ gpio@600 {
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ compatible = "mediatek,mt7621-gpio";
+ gpio-controller;
+ interrupt-controller;
+ reg = <0x600 0x100>;
+ interrupt-parent = <&gic>;
+ interrupts = ;
+ };
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 0/2] gpio: mediatek: driver for gpio chip in MT7621 SoC
This patch series add support for gpio driver in mediatek MT7621 SoC. This driver has been in staging for a while and after some cleanups cycles we consider to give it a new try to get mainlined. Previous comments from Linus Walleij are here: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/121742.html Comments from Rob Herring are here: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/121974.html Changes in v3: - Fix added Makefile entry which was wrong. Changes in v2 are the ones pointed out in previous mails: - use bgpio_init - avoid custom irq_domain using IRQF_SHARED and gpiochip_set_chained_irqchip from GPIOLIB_IRQCHIP - use only one node in the device tree making it simple - Implement high and low level irqs - avoid include gpio.h - use builtin_platform_driver - add COMPILE_TEST - cleanups after this changes Hope this helps and thanks in advance. Best regards, Sergio Paracuellos Sergio Paracuellos (2): gpio: mediatek: add driver for MT7621 dt-bindings: document gpio-mt7621 bindings .../bindings/gpio/mediatek,mt7621-gpio.txt | 35 +++ drivers/gpio/Kconfig | 8 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-mt7621.c | 320 + 4 files changed, 364 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt create mode 100644 drivers/gpio/gpio-mt7621.c -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] dt-bindings: document gpio-mt7621 bindings
Add a devicetree binding documentation for the mt7621 gpio.
Signed-off-by: Sergio Paracuellos
---
.../bindings/gpio/mediatek,mt7621-gpio.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
new file mode 100644
index 000..ba45558
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt
@@ -0,0 +1,35 @@
+Mediatek MT7621 SoC GPIO controller bindings
+
+The IP core used inside these SoCs has 3 banks of 32 GPIOs each.
+The registers of all the banks are interwoven inside one single IO range.
+We load one GPIO controller instance per bank. Also the GPIO controller can
receive
+interrupts on any of the GPIOs, either edge or level. It then interrupts the
CPU
+using GIC INT12.
+
+Required properties for the top level node:
+- #gpio-cells : Should be two. The first cell is the GPIO pin number and the
+ second cell specifies GPIO flags, as defined in .
+ Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt. Should be 2. The first cell defines the interrupt number,
+ the second encodes the triger flags encoded as described in
+ Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+- compatible:
+ - "mediatek,mt7621-gpio" for Mediatek controllers
+- reg : Physical base address and length of the controller's registers
+- interrupt-parent : phandle of the parent interrupt controller.
+- interrupts : Interrupt specifier for the controllers interrupt.
+- interrupt-controller : Mark the device node as an interrupt controller.
+- gpio-controller : Marks the device node as a GPIO controller.
+
+Example:
+ gpio@600 {
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ compatible = "mediatek,mt7621-gpio";
+ gpio-controller;
+ interrupt-controller;
+ reg = <0x600 0x100>;
+ interrupt-parent = <&gic>;
+ interrupts = ;
+ };
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] gpio: mediatek: add driver for MT7621
Add driver support for gpio of MT7621 SoC.
Signed-off-by: Sergio Paracuellos
---
drivers/gpio/Kconfig | 8 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mt7621.c | 320 +
3 files changed, 329 insertions(+)
create mode 100644 drivers/gpio/gpio-mt7621.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 71c0ab4..836aa21 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -359,6 +359,14 @@ config GPIO_MPC8XXX
Say Y here if you're going to use hardware that connects to the
MPC512x/831x/834x/837x/8572/8610/QorIQ GPIOs.
+config GPIO_MT7621
+ bool "Mediatek MT7621 GPIO Support"
+ depends on SOC_MT7620 || SOC_MT7621 || COMPILE_TEST
+ select GPIO_GENERIC
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to support the Mediatek MT7621 SoC GPIO device
+
config GPIO_MVEBU
def_bool y
depends on PLAT_ORION || ARCH_MVEBU
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 1324c8f..b264426 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_GPIO_MOCKUP) += gpio-mockup.o
obj-$(CONFIG_GPIO_MPC5200) += gpio-mpc5200.o
obj-$(CONFIG_GPIO_MPC8XXX) += gpio-mpc8xxx.o
obj-$(CONFIG_GPIO_MSIC)+= gpio-msic.o
+obj-$(CONFIG_GPIO_MSIC)+= gpio-mt7621.o
obj-$(CONFIG_GPIO_MVEBU)+= gpio-mvebu.o
obj-$(CONFIG_GPIO_MXC) += gpio-mxc.o
obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
new file mode 100644
index 000..281e621
--- /dev/null
+++ b/drivers/gpio/gpio-mt7621.c
@@ -0,0 +1,320 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2009-2011 Gabor Juhos
+ * Copyright (C) 2013 John Crispin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_BANK_CNT 3
+#define MTK_BANK_WIDTH 32
+
+#define GPIO_BANK_WIDE 0x04
+#define GPIO_REG_CTRL 0x00
+#define GPIO_REG_POL 0x10
+#define GPIO_REG_DATA 0x20
+#define GPIO_REG_DSET 0x30
+#define GPIO_REG_DCLR 0x40
+#define GPIO_REG_REDGE 0x50
+#define GPIO_REG_FEDGE 0x60
+#define GPIO_REG_HLVL 0x70
+#define GPIO_REG_LLVL 0x80
+#define GPIO_REG_STAT 0x90
+#define GPIO_REG_EDGE 0xA0
+
+struct mtk_gc {
+ struct gpio_chip chip;
+ spinlock_t lock;
+ int bank;
+ u32 rising;
+ u32 falling;
+ u32 hlevel;
+ u32 llevel;
+};
+
+/**
+ * struct mtk_data - state container for
+ * data of the platform driver. It is 3
+ * separate gpio-chip each one with its
+ * own irq_chip.
+ * @dev: device instance
+ * @gpio_membase: memory base address
+ * @gpio_irq: irq number from the device tree
+ * @gc_map: array of the gpio chips
+ */
+struct mtk_data {
+ struct device *dev;
+ void __iomem *gpio_membase;
+ int gpio_irq;
+ struct mtk_gc gc_map[MTK_BANK_CNT];
+};
+
+static inline struct mtk_gc *
+to_mediatek_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct mtk_gc, chip);
+}
+
+static inline void
+mtk_gpio_w32(struct mtk_gc *rg, u32 offset, u32 val)
+{
+ struct gpio_chip *gc = &rg->chip;
+ struct mtk_data *gpio_data = gpiochip_get_data(gc);
+
+ offset = (rg->bank * GPIO_BANK_WIDE) + offset;
+ gc->write_reg(gpio_data->gpio_membase + offset, val);
+}
+
+static inline u32
+mtk_gpio_r32(struct mtk_gc *rg, u32 offset)
+{
+ struct gpio_chip *gc = &rg->chip;
+ struct mtk_data *gpio_data = gpiochip_get_data(gc);
+
+ offset = (rg->bank * GPIO_BANK_WIDE) + offset;
+ return gc->read_reg(gpio_data->gpio_membase + offset);
+}
+
+static irqreturn_t
+mediatek_gpio_irq_handler(int irq, void *data)
+{
+ struct gpio_chip *gc = data;
+ struct mtk_gc *rg = to_mediatek_gpio(gc);
+ irqreturn_t ret = IRQ_NONE;
+ unsigned long pending;
+ int bit;
+
+ pending = mtk_gpio_r32(rg, GPIO_REG_STAT);
+
+ for_each_set_bit(bit, &pending, MTK_BANK_WIDTH) {
+ u32 map = irq_find_mapping(gc->irq.domain, bit);
+
+ generic_handle_irq(map);
+ mtk_gpio_w32(rg, GPIO_REG_STAT, BIT(bit));
+ ret |= IRQ_HANDLED;
+ }
+
+ return ret;
+}
+
+static void
+mediatek_gpio_irq_unmask(struct irq_data *d)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+ struct mtk_gc *rg = to_mediatek_gpio(gc);
+ int pin = d->hwirq;
+ unsigned long flags;
+ u32 rise, fall, high, low;
+
+ spin_lock_irqsave(&rg->lock, flags);
+ rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
+ fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
+ high = mtk_gpio_r32(rg, GPIO_REG_HLVL);
+ low = mtk_gpio_r32(rg, GPIO_REG_LLVL);
+ mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (BIT(pin) & rg->rising));
+ mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (BIT(pin) & rg->falling));
+ mtk_gpio_w32(rg, GPIO_REG_
[PATCH v2 0/2] gpio: mediatek: driver for gpio chip in MT7621 SoC
This patch series add support for gpio driver in mediatek MT7621 SoC. This driver has been in staging for a while and after some cleanups cycles we consider to give it a new try to get mainlined. Previous comments from Linus Walleij are here: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/121742.html Comments from Rob Herring are here: http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-June/121974.html Changes in v2 are the ones pointed out in previous mails: - use bgpio_init - avoid custom irq_domain using IRQF_SHARED and gpiochip_set_chained_irqchip from GPIOLIB_IRQCHIP - use only one node in the device tree making it simple - Implement high and low level irqs - avoid include gpio.h - use builtin_platform_driver - add COMPILE_TEST - cleanups after this changes Hope this helps and thanks in advance. Best regards, Sergio Paracuellos Sergio Paracuellos (2): gpio: mediatek: add driver for MT7621 dt-bindings: document gpio-mt7621 bindings .../bindings/gpio/mediatek,mt7621-gpio.txt | 35 +++ drivers/gpio/Kconfig | 8 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-mt7621.c | 320 + 4 files changed, 364 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/mediatek,mt7621-gpio.txt create mode 100644 drivers/gpio/gpio-mt7621.c -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()
On Wed, Jun 13, 2018 at 10:50:05PM +, Dexuan Cui wrote: > > From: Bjorn Helgaas > > Sent: Wednesday, June 13, 2018 15:15 > > > ... > > > It looks Lorenzo's pci.git tree has not been updated for 3+ weeks. > > > I guess Lorenzo may be on vacation. > > > > > > @Bjorn, can this patch go through your tree? > > > Should I resubmit it? > > > > No need to resubmit it, Lorenzo has been out for a bit, but I'm sure > > he'll pick this up as he catches up. > OK, I see. Thanks! > > > You might, however, fix the commit log: > > > > This is not an issue because hv_pci_onchannelcallback() is not slow, > > and it not a hot path. > > > > This has at least one typo (I think you mean "and *is* not a hot > > path"). > Sorry -- yes, it's a typo. I hope Lorenzo can help to fix this, or I can > resubmit it if Lorenzo or you want me to do it. > > > I also don't understand the sentence as a whole because the > > hv_pci_onchannelcallback() comment says it's called whenever the host > > sends a packet to this channel, and that *does* sound like a hot path. > Sorry for not making it clear. > The host only sends a packet into the channel of the guest when there > is a change of device configuration (i.e. hot add or remove a device), or > the host is responding to the guest's request. > > The change of device configuration is only triggered on-demand by the > administrator on the host, and the guest's requests are one-off when > the device is probed. > > So IMO the callback is not a hot path. > > > I also don't understand the "hv_pci_onchannelcallback() is not slow" > > part. In other words, you're saying hv_pci_onchannelcallback() is > > fast and it's not a hot path. And apparently this has something to do > > with the difference between local_bh_disable() and local_irq_save()? > > > > Bjorn > Actually in my original internal version of the patch, I did use > local_irq_save/restore(). > > hv_pci_onchannelcallback() itself runs fast, but here since it's in a > loop (i.e. the while (!try_wait_for_completion(&comp.comp_pkt.host_event) > loop), IIRC I was asked if I really need local_irq_save/restore(), > and I answered "not really", so later I switched to > local_bh_disable()/enable(). > > However, recently I found that if we enable CONFIG_PROVE_LOCKING=y, > the local_bh_enable() can trigger a warning because the function > hv_compose_msi_msg() can be called with local IRQs disabled (BTW, > hv_compose_msi_msg() can also be called with local IRQS enabled in > another code path): > > IRQs not enabled as expected > WARNING: CPU: 0 PID: 408 at kernel/softirq.c:162 __local_bh_enable_ip > > Despite the warning, the code itself can still work correctly, but IMO we'd > better switch back to local_irq_save/restore(), and hence I made the patch. > > I hope the explanation sounds reasonable. :-) Sorry for the delay in replying. I need to understand if you are preventing a spurious lockdep warning or you are fixing a kernel bug. From your commit log, I assume the former option but I do not think that's what you are really doing. Apart from the commit log typos fixes I would like a log that explains *why* this is not a kernel bug fix rather than a harmless lockdep warning prevention. Thanks, Lorenzo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/4] staging:iio:adc:ad7280a: Use GFP_ATOMIC in interrupt handler
On Fri, Jun 29, 2018 at 01:49:28AM +0200, Karim Eshapa wrote: > Use GFP_ATOMIC rather GFP_KERNEL in interrupt handler, > as GFP_KERNEL may sleep according to slab allocator. > This is a threaded IRQ so it can sleep. You should always think about the impact of a bug. If this were a bug it would have showed up in testing right away. Most of my patches are in error handling and so the impact is zero unless you deliberately try to inject errors that's why they can go undetected for years. Also you should always use the Fixes tag to see how the patch was introduced. I often see bugs where the patch is new and it was introduced by someone doing major subsystem cleanups and they don't have the hardware so I know it hasn't been tested. If the patch is a couple years old and the bug is in the success path which every one tests then I wonder if I am misreading the code somehow. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: goldfish: fix whitespace in goldfish_audio
On Thu, Jun 28, 2018 at 06:19:13PM -0700, r...@google.com wrote:
> From: Roman Kiryanov
>
> Linux kernel coding style: spaces are never used for
> indentation.
>
> Signed-off-by: Roman Kiryanov
> ---
> drivers/staging/goldfish/goldfish_audio.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/goldfish/goldfish_audio.c
> b/drivers/staging/goldfish/goldfish_audio.c
> index b7004edd3ce2..3a75df1d2a0a 100644
> --- a/drivers/staging/goldfish/goldfish_audio.c
> +++ b/drivers/staging/goldfish/goldfish_audio.c
> @@ -38,18 +38,19 @@ MODULE_VERSION("1.0");
> struct goldfish_audio {
> char __iomem *reg_base;
> int irq;
> +
That's not a space/tab issue?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: goldfish: cleanup in goldfish_audio
On Thu, Jun 28, 2018 at 06:19:14PM -0700, r...@google.com wrote: > From: Roman Kiryanov > > * added a mutex to protect open/read/write/release calls; > * put the global atomic counter for opened files into the > driver state; > * retired the global variable for the driver state; > * retired the ioctl calls because it does not do much and cmd=315 > looks obsolete. When you have to provide a list of things you are doing in a single patch, that is a huge hint you need to split that patch up into smaller pieces. Each of these bullets should be a single patch. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Remove references to the retired driver from README
On Thu, Jun 28, 2018 at 01:33:23PM -0700, r...@google.com wrote: > From: Roman Kiryanov > > The goldfish nand driver was retired (not used). > > Signed-off-by: Roman Kiryanov > --- > drivers/staging/goldfish/README | 6 -- > 1 file changed, 6 deletions(-) Your subject line needs to say where in the kernel you are touching a file :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
