Re: [PATCH v6 00/11] Raspberry Pi PoE HAT fan support
On Mon, Jan 11, 2021 at 10:02 PM Nicolas Saenz Julienne wrote: > I'd say at this point the series is pretty clean and, AFAIK, there aren't any > objections. I'm not so sure who should take it, given that it covers numerous > subsystems. Any suggestions on how to handle it? This is one of those cases where I would suggest collect ACKs from affected subsystem maintainers and send a pull request to the SoC tree for this hairy bundle. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-dts: match pinctrl nodes with its binding documentation
On Mon, Jan 4, 2021 at 4:06 PM Sergio Paracuellos wrote: > According to the binding documentation pinctrl related nodes > must use '-pins$' and ''^(.*-)?pinmux$'' as names. Change all > to properly match them. Also default state is for consumer > nodes and shall be removed from here. > > Signed-off-by: Sergio Paracuellos Acked-by: Linus Walleij Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/8] pinctrl: ralink: rt2880: Some minimal clean ups
On Sun, Dec 13, 2020 at 5:17 PM Sergio Paracuellos wrote: > After this driver was moved from staging into pinctrl subsytems > some reviews for bindigns and driver itself comes from Ron Herring > and Dan Carpenter. Get rid of all the comments to properly be in > a good shape before merge window. Applied patches 1-7 to the pinctrl tree, patch 8 needs to be sent to Greg. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/8] pinctrl: ralink: rt2880: Some minimal clean ups
On Sun, Dec 13, 2020 at 5:17 PM Sergio Paracuellos wrote: > After this driver was moved from staging into pinctrl subsytems > some reviews for bindigns and driver itself comes from Ron Herring > and Dan Carpenter. Get rid of all the comments to properly be in > a good shape before merge window. Reviewed-by: Linus Walleij If Greg wants he can queue them last minute. Else I'll apply these after the merge window, no big deal. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] pinctrl: ralink: add a pinctrl driver for the rt2880 family
On Tue, Dec 8, 2020 at 8:55 AM Sergio Paracuellos wrote: > These Socs have 1-3 banks of 8-32 gpios. Rather then setting the muxing of > each > pin individually, these socs have mux groups that when set will effect 1-N > pins. > Pin groups have a 2, 4 or 8 different muxes. > > Acked-by: Linus Walleij > Signed-off-by: Sergio Paracuellos Greg I'm happy if you just apply this right now for v5.11, as Sergio is obviously on top of things and the DT bindings will get there eventually so I don't see any need to hold back the de-staging just waiting for patch 1 (which I will eventually apply directly anyway). Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] pinctrl: ralink: add a pinctrl driver for the rt2880 family
Hi Serigio, I dug around some to try to understand the patch I think I get it now :) Squash this with the third patch so it becomes a "move" of this file, preserving history. With that: Acked-by: Linus Walleij I have ideas, but it is better to move the driver out of staging and improve it in pinctrl. Since there might be many sub-SoCs for this pin controller, what about creating drivers/pinctrl/ralink/* for this at the same time? On Mon, Dec 7, 2020 at 8:21 PM Sergio Paracuellos wrote: > > These Socs have 1-3 banks of 8-32 gpios. Rather then setting the muxing of > each > pin individually, these socs have mux groups that when set will effect 1-N > pins. > Pin groups have a 2, 4 or 8 different muxes. > > Signed-off-by: Sergio Paracuellos (...) > +#include > +#include > +#include I think in the next step we should move the contents of rt2880_pinmux_data into this driver, then we can drop these mach-headers and show the way for the rest of the ralink chips to push their data down into this driver (or subdrivers) and depopulate mach-ralink a bit. > + p->groups = rt2880_pinmux_data; So this is where the driver actually gets a pointer to all groups and functions, and these groups and functions all come from arch/mips/ralink/mt7621.c right? I think after this first step we should move mt7621.c to pinctrl and become a subdriver for this pin controller and then we can hopefully move the rest as well once you set the pattern for how we do this. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] dt-bindings: pinctrl: rt2880: add binding document
Hi Sergio, thanks for driving this! On Mon, Dec 7, 2020 at 8:21 PM Sergio Paracuellos wrote: > The commit adds rt2880 compatible node in binding document. > > Signed-off-by: Sergio Paracuellos (...) > +description: > + The rt2880 pinmux can only set the muxing of pin groups. muxing indiviual > pins > + is not supported. There is no pinconf support. OK! > +properties: > + compatible: > +enum: > + - ralink,rt2880-pinmux > + > + pinctrl-0: > +description: > + A phandle to the node containing the subnodes containing default > + configurations. As it is a node on the pin controller itself, this is a hog so write something about that this is for pinctrl hogs. > + pinctrl-names: > +description: > + A pinctrl state named "default" must be defined. > +const: default Is it really compulsory? > +required: > + - compatible > + - pinctrl-names > + - pinctrl-0 I wonder if the hogs are really compulsory. > +patternProperties: > + '^.*$': That's liberal node naming! What about [a-z0-9_-]+ or something? > +if: > + type: object > + description: | > +A pinctrl node should contain at least one subnodes representing the > +pinctrl groups available on the machine. > + $ref: "pinmux-node.yaml" > + required: > +- groups > +- function > + additionalProperties: false > +then: > + properties: > +groups: > + description: > +Name of the pin group to use for the functions. > + $ref: "/schemas/types.yaml#/definitions/string" > + enum: [i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, mdio, > + pcie, sdhci] > +function: > + description: > +The mux function to select > + $ref: "/schemas/types.yaml#/definitions/string" > + enum: [gpio, i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, > + mdio, nand1, nand2, sdhci] Why do we have this complex if: clause? $ref: "pinmux-node.yaml" should bring in the groups and function properties. Then you can add some further restrictions on top of that, right? I would just do: patternProperties: '^[a-z0-9_]+$': type: object description: node for pinctrl $ref "pinmux-node.yaml" properties: groups: description: groups... enum: [i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, mdio, pcie, sdhci] function: description: function... enum: [gpio, i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, mdio, nand1, nand2, sdhci] Note: the function names are fine but the group names are a bit confusion since often a group can be used for more than one function, and e.g. function = "i2c"; group = "uart1"; to use the uart1 pins for an i2c is gonna look mildly confusing. But if this is what the hardware calls it I suppose it is fine. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-pinctrl: stop using the deprecated 'pinctrl_add_gpio_range'
On Mon, Dec 7, 2020 at 4:49 PM Greg KH wrote: > Sometimes we just do a "add a new driver to the real spot" that goes > through the subsystem tree, and when that is accepted, I delete the > driver in the staging tree. This is most often in networking. That's unnice, it will loose the history, it is so nice to git blame the source. > Or you can wait until -rc1 and do a move in your tree, or just tell me > to do the move in my tree with an ack, and I can handle it all. > > Whatever is easier for you is fine with me, I'm flexible :) I say let's move it to my subsystem before the merge window if there is time. I'll provide ACK. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-pinctrl: stop using the deprecated 'pinctrl_add_gpio_range'
On Mon, Dec 7, 2020 at 2:57 PM Sergio Paracuellos wrote: > On Mon, Dec 7, 2020 at 2:05 PM Linus Walleij wrote: > > After this I think the driver looks good and can graduate from staging. > > Can you send a patch to move this to drivers/pinctrl next > > > > I think drivers/pinctrl/pinctrl-rt2880.c since we don't expect a lot > > more of them. > > Perfect, let me write the bindings yaml file and send the patch moving this. > > What git tree do you prefer the patch to be rebased onto? I suppose Gregs since he has some changes to it that it need to be based on. After v5.11-rc1 it could be the pinctrl tree as well. I don't know if Greg has a favourite way to de-stage drivers? Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: mt7621-pinctrl: stop using the deprecated 'pinctrl_add_gpio_range'
On Sun, Dec 6, 2020 at 11:53 AM Sergio Paracuellos wrote: > If the gpio DT node has the 'gpio-ranges' property, the range will be > added by the gpio core and doesn't need to be added by the pinctrl > driver. > > By having the gpio-ranges property, we can map every pin between > gpio node and pinctrl node and we can stop using the deprecated > pinctrl_add_gpio_range() function. > > Signed-off-by: Sergio Paracuellos Reviewed-by: Linus Walleij After this I think the driver looks good and can graduate from staging. Can you send a patch to move this to drivers/pinctrl next? I think drivers/pinctrl/pinctrl-rt2880.c since we don't expect a lot more of them. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: media: atomisp: Convert to GPIO descriptors
Convert the atomisp LM3554 driver to use GPIO descriptors
fully. It was already retrieveing the GPIO lines as descriptors
but for some reason converting them back into global GPIO
numbers. There is no reason to do this, just deal with the
descriptors as-is.
Cc: Mauro Carvalho Chehab
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebased on v5.9-rc1
---
.../media/atomisp/i2c/atomisp-lm3554.c| 68 ---
.../media/atomisp/include/media/lm3554.h | 7 +-
2 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 809010af7855..7ca7378b1859 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -19,14 +19,13 @@
#include
#include
#include
-#include
+#include
#include
#include "../include/media/lm3554.h"
#include
#include
#include
-#include
#include "../include/linux/atomisp_gmin_platform.h"
#include "../include/linux/atomisp.h"
@@ -173,7 +172,7 @@ static void lm3554_flash_off_delay(struct timer_list *t)
struct lm3554 *flash = from_timer(flash, t, flash_off_delay);
struct lm3554_platform_data *pdata = flash->pdata;
- gpio_set_value(pdata->gpio_strobe, 0);
+ gpiod_set_value(pdata->gpio_strobe, 0);
}
static int lm3554_hw_strobe(struct i2c_client *client, bool strobe)
@@ -209,7 +208,7 @@ static int lm3554_hw_strobe(struct i2c_client *client, bool
strobe)
* so must strobe off here
*/
if (timer_pending)
- gpio_set_value(pdata->gpio_strobe, 0);
+ gpiod_set_value(pdata->gpio_strobe, 0);
/* Restore flash current settings */
ret = lm3554_set_flash(flash);
@@ -217,7 +216,7 @@ static int lm3554_hw_strobe(struct i2c_client *client, bool
strobe)
goto err;
/* Strobe on Flash */
- gpio_set_value(pdata->gpio_strobe, 1);
+ gpiod_set_value(pdata->gpio_strobe, 1);
return 0;
err:
@@ -627,7 +626,7 @@ static int __lm3554_s_power(struct lm3554 *flash, int power)
int ret;
/*initialize flash driver*/
- gpio_set_value(pdata->gpio_reset, power);
+ gpiod_set_value(pdata->gpio_reset, power);
usleep_range(100, 100 + 1);
if (power) {
@@ -766,33 +765,22 @@ static int lm3554_gpio_init(struct i2c_client *client)
struct lm3554_platform_data *pdata = flash->pdata;
int ret;
- if (!gpio_is_valid(pdata->gpio_reset))
+ if (!pdata->gpio_reset)
return -EINVAL;
- ret = gpio_direction_output(pdata->gpio_reset, 0);
+ ret = gpiod_direction_output(pdata->gpio_reset, 0);
if (ret < 0)
- goto err_gpio_reset;
+ return ret;
dev_info(&client->dev, "flash led reset successfully\n");
- if (!gpio_is_valid(pdata->gpio_strobe)) {
- ret = -EINVAL;
- goto err_gpio_dir_reset;
- }
+ if (!pdata->gpio_strobe)
+ return -EINVAL;
- ret = gpio_direction_output(pdata->gpio_strobe, 0);
+ ret = gpiod_direction_output(pdata->gpio_strobe, 0);
if (ret < 0)
- goto err_gpio_strobe;
+ return ret;
return 0;
-
-err_gpio_strobe:
- gpio_free(pdata->gpio_strobe);
-err_gpio_dir_reset:
- gpio_direction_output(pdata->gpio_reset, 0);
-err_gpio_reset:
- gpio_free(pdata->gpio_reset);
-
- return ret;
}
static int lm3554_gpio_uninit(struct i2c_client *client)
@@ -802,16 +790,14 @@ static int lm3554_gpio_uninit(struct i2c_client *client)
struct lm3554_platform_data *pdata = flash->pdata;
int ret;
- ret = gpio_direction_output(pdata->gpio_strobe, 0);
+ ret = gpiod_direction_output(pdata->gpio_strobe, 0);
if (ret < 0)
return ret;
- ret = gpio_direction_output(pdata->gpio_reset, 0);
+ ret = gpiod_direction_output(pdata->gpio_reset, 0);
if (ret < 0)
return ret;
- gpio_free(pdata->gpio_strobe);
- gpio_free(pdata->gpio_reset);
return 0;
}
@@ -819,18 +805,18 @@ static void *lm3554_platform_data_func(struct i2c_client
*client)
{
static struct lm3554_platform_data platform_data;
- platform_data.gpio_reset =
- desc_to_gpio(gpiod_get_index(&client->dev,
-NULL, 2, GPIOD_OUT_LOW));
- platform_data.gpio_strobe =
- desc_to_gpio(gpiod_get_index(&client->dev,
-NULL, 0, GPIOD_OUT_LOW));
- platform_data.gpio_torch =
- desc_to_gpio(gpiod_get_index(&client->dev,
-
[PATCH] staging: greybus: gpio: Use irqchip template
This makes the driver use the irqchip template to assign
properties to the gpio_irq_chip instead of using the
explicit calls to gpiochip_irqchip_add(). The irqchip is
instead added while adding the gpiochip.
Cc: Nishad Kamdar
Cc: Johan Hovold
Signed-off-by: Linus Walleij
---
drivers/staging/greybus/gpio.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 36d99f9e419e..7e6347fe93f9 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -504,6 +504,7 @@ static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
struct gb_connection *connection;
struct gb_gpio_controller *ggc;
struct gpio_chip *gpio;
+ struct gpio_irq_chip *girq;
struct irq_chip *irqc;
int ret;
@@ -561,6 +562,15 @@ static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
gpio->ngpio = ggc->line_max + 1;
gpio->can_sleep = true;
+ girq = &gpio->irq;
+ girq->chip = irqc;
+ /* The event comes from the outside so no parent handler */
+ girq->parent_handler = NULL;
+ girq->num_parents = 0;
+ girq->parents = NULL;
+ girq->default_type = IRQ_TYPE_NONE;
+ girq->handler = handle_level_irq;
+
ret = gb_connection_enable(connection);
if (ret)
goto exit_line_free;
@@ -571,18 +581,9 @@ static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
goto exit_line_free;
}
- ret = gpiochip_irqchip_add(gpio, irqc, 0, handle_level_irq,
- IRQ_TYPE_NONE);
- if (ret) {
- dev_err(&gbphy_dev->dev, "failed to add irq chip: %d\n", ret);
- goto exit_gpiochip_remove;
- }
-
gbphy_runtime_put_autosuspend(gbphy_dev);
return 0;
-exit_gpiochip_remove:
- gpiochip_remove(gpio);
exit_line_free:
kfree(ggc->lines);
exit_connection_disable:
--
2.26.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5] staging: wfx: Get descriptors for GPIOs
The code has the functionality to insert the GPIO lines using
the global GPIO numbers through module parameters.
As we are clearly deprecating the use of global GPIO numbers
look up the GPIO descriptors from the device instead. This
usually falls back to device hardware descriptions using e.g.
device tree or ACPI. This device clearly supports device
tree when used over SPI for example.
For example, this can be supplied in the device tree like so:
wfx@0x01 {
compatible = "silabs,wf200";
reset-gpios = <&gpio0 1>;
wakeup-gpios = <&gpio0 2>;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v4->v5:
- Make the wakeup GPIO optional.
ChangeLog v3->v4:
- Finally figured out how to compile this by selecting SPI
host and deselecting MMC host.
- Initialize the reset GPIO as OUT_LOW
- Initialize the wakeup GPIO as OUT_LOW
- Drop one more desc_to_gpio()
- Update the warning if GPIO is not found.
ChangeLog v2->v3:
- ERR_CAST not PTR_CAST
ChangeLog v1->v2:
- Fixed a cast and a variable name.
- I still don't know how to compile this but hey the zeroday
robot does.
---
drivers/staging/wfx/bus_spi.c | 14 +--
drivers/staging/wfx/main.c| 47 ++-
drivers/staging/wfx/main.h| 2 --
3 files changed, 14 insertions(+), 49 deletions(-)
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index e8da61fb096b..d19c0478e8be 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -8,7 +8,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -21,10 +20,6 @@
#include "main.h"
#include "bh.h"
-static int gpio_reset = -2;
-module_param(gpio_reset, int, 0644);
-MODULE_PARM_DESC(gpio_reset, "gpio number for reset. -1 for none.");
-
#define SET_WRITE 0x7FFF/* usage: and operation */
#define SET_READ 0x8000 /* usage: or operation */
@@ -211,10 +206,15 @@ static int wfx_spi_probe(struct spi_device *func)
bus->need_swab = true;
spi_set_drvdata(func, bus);
- bus->gpio_reset = wfx_get_gpio(&func->dev, gpio_reset, "reset");
+ bus->gpio_reset = devm_gpiod_get_optional(&func->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(bus->gpio_reset))
+ return PTR_ERR(bus->gpio_reset);
if (!bus->gpio_reset) {
- dev_warn(&func->dev, "try to load firmware anyway\n");
+ dev_warn(&func->dev,
+"gpio reset is not defined, trying to load firmware
anyway\n");
} else {
+ gpiod_set_consumer_name(bus->gpio_reset, "wfx reset");
if (spi_get_device_id(func)->driver_data & WFX_RESET_INVERTED)
gpiod_toggle_active_low(bus->gpio_reset);
gpiod_set_value_cansleep(bus->gpio_reset, 1);
diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 6bd96f476388..1b220befa272 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -41,10 +40,6 @@ MODULE_DESCRIPTION("Silicon Labs 802.11 Wireless LAN driver
for WFx");
MODULE_AUTHOR("Jérôme Pouiller ");
MODULE_LICENSE("GPL");
-static int gpio_wakeup = -2;
-module_param(gpio_wakeup, int, 0644);
-MODULE_PARM_DESC(gpio_wakeup, "gpio number for wakeup. -1 for none.");
-
#define RATETAB_ENT(_rate, _rateid, _flags) { \
.bitrate = (_rate), \
.hw_value = (_rateid), \
@@ -170,38 +165,6 @@ bool wfx_api_older_than(struct wfx_dev *wdev, int major,
int minor)
return false;
}
-struct gpio_desc *wfx_get_gpio(struct device *dev,
- int override, const char *label)
-{
- struct gpio_desc *ret;
- char label_buf[256];
-
- if (override >= 0) {
- snprintf(label_buf, sizeof(label_buf), "wfx_%s", label);
- ret = ERR_PTR(devm_gpio_request_one(dev, override,
- GPIOF_OUT_INIT_LOW,
- label_buf));
- if (!ret)
- ret = gpio_to_desc(override);
- } else if (override == -1) {
- ret = NULL;
- } else {
- ret = devm_gpiod_get(dev, label, GPIOD_OUT_LOW);
- }
- if (IS_ERR_OR_NULL(ret)) {
- if (!ret || PTR_ERR(ret) == -ENOENT)
- dev_warn(dev, "gpio %s is not defined\n", label);
- else
- dev_warn(dev, "error while requesting gpio %s\n",
-label);
- ret = N
[PATCH v4] staging: wfx: Get descriptors for GPIOs
The code has the functionality to insert the GPIO lines using
the global GPIO numbers through module parameters.
As we are clearly deprecating the use of global GPIO numbers
look up the GPIO descriptors from the device instead. This
usually falls back to device hardware descriptions using e.g.
device tree or ACPI. This device clearly supports device
tree when used over SPI for example.
For example, this can be supplied in the device tree like so:
wfx@0x01 {
compatible = "silabs,wf200";
reset-gpios = <&gpio0 1>;
wakeup-gpios = <&gpio0 2>;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v3->v4:
- Finally figured out how to compile this by selecting SPI
host and deselecting MMC host.
- Initialize the reset GPIO as OUT_LOW
- Initialize the wakeup GPIO as OUT_LOW
- Drop one more desc_to_gpio()
- Update the warning if GPIO is not found.
ChangeLog v2->v3:
- ERR_CAST not PTR_CAST
ChangeLog v1->v2:
- Fixed a cast and a variable name.
- I still don't know how to compile this but hey the zeroday
robot does.
---
drivers/staging/wfx/bus_spi.c | 14 +--
drivers/staging/wfx/main.c| 45 ---
drivers/staging/wfx/main.h| 2 --
3 files changed, 12 insertions(+), 49 deletions(-)
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index e8da61fb096b..d19c0478e8be 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -8,7 +8,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -21,10 +20,6 @@
#include "main.h"
#include "bh.h"
-static int gpio_reset = -2;
-module_param(gpio_reset, int, 0644);
-MODULE_PARM_DESC(gpio_reset, "gpio number for reset. -1 for none.");
-
#define SET_WRITE 0x7FFF/* usage: and operation */
#define SET_READ 0x8000 /* usage: or operation */
@@ -211,10 +206,15 @@ static int wfx_spi_probe(struct spi_device *func)
bus->need_swab = true;
spi_set_drvdata(func, bus);
- bus->gpio_reset = wfx_get_gpio(&func->dev, gpio_reset, "reset");
+ bus->gpio_reset = devm_gpiod_get_optional(&func->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(bus->gpio_reset))
+ return PTR_ERR(bus->gpio_reset);
if (!bus->gpio_reset) {
- dev_warn(&func->dev, "try to load firmware anyway\n");
+ dev_warn(&func->dev,
+"gpio reset is not defined, trying to load firmware
anyway\n");
} else {
+ gpiod_set_consumer_name(bus->gpio_reset, "wfx reset");
if (spi_get_device_id(func)->driver_data & WFX_RESET_INVERTED)
gpiod_toggle_active_low(bus->gpio_reset);
gpiod_set_value_cansleep(bus->gpio_reset, 1);
diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 6bd96f476388..3828a2652313 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -41,10 +40,6 @@ MODULE_DESCRIPTION("Silicon Labs 802.11 Wireless LAN driver
for WFx");
MODULE_AUTHOR("Jérôme Pouiller ");
MODULE_LICENSE("GPL");
-static int gpio_wakeup = -2;
-module_param(gpio_wakeup, int, 0644);
-MODULE_PARM_DESC(gpio_wakeup, "gpio number for wakeup. -1 for none.");
-
#define RATETAB_ENT(_rate, _rateid, _flags) { \
.bitrate = (_rate), \
.hw_value = (_rateid), \
@@ -170,38 +165,6 @@ bool wfx_api_older_than(struct wfx_dev *wdev, int major,
int minor)
return false;
}
-struct gpio_desc *wfx_get_gpio(struct device *dev,
- int override, const char *label)
-{
- struct gpio_desc *ret;
- char label_buf[256];
-
- if (override >= 0) {
- snprintf(label_buf, sizeof(label_buf), "wfx_%s", label);
- ret = ERR_PTR(devm_gpio_request_one(dev, override,
- GPIOF_OUT_INIT_LOW,
- label_buf));
- if (!ret)
- ret = gpio_to_desc(override);
- } else if (override == -1) {
- ret = NULL;
- } else {
- ret = devm_gpiod_get(dev, label, GPIOD_OUT_LOW);
- }
- if (IS_ERR_OR_NULL(ret)) {
- if (!ret || PTR_ERR(ret) == -ENOENT)
- dev_warn(dev, "gpio %s is not defined\n", label);
- else
- dev_warn(dev, "error while requesting gpio %s\n",
-label);
- ret = NULL;
- } else {
- dev_d
Re: [PATCH v3] staging: wfx: Get descriptors for GPIOs
On Sun, Jun 28, 2020 at 12:43 PM Greg KH wrote: > On Sun, Jun 28, 2020 at 10:52:36AM +0200, Linus Walleij wrote: > > ChangeLog v2->v3: > > - ERR_CAST not PTR_CAST > > ChangeLog v1->v2: > > - Fixed a cast and a variable name. > > - I still don't know how to compile this but hey the zeroday > > robot does. > > I can build this on my desktop, and this patch still blows up the build. > What is wrong with your setup that this doesn't build for you? Don't know exactly, probably that all my builds are so ARM-fixated. I'll try to learn my way around the x86 config properly so I can properly compile-test this, the other patch I managed to test after a long menuconfig session. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: wfx: Get descriptors for GPIOs
The code has the functionality to insert the GPIO lines using
the global GPIO numbers through module parameters.
As we are clearly deprecating the use of global GPIO numbers
look up the GPIO descriptors from the device instead. This
usually falls back to device hardware descriptions using e.g.
device tree or ACPI. This device clearly supports device
tree when used over SPI for example.
For example, this can be supplied in the device tree like so:
wfx@0x01 {
compatible = "silabs,wf200";
reset-gpios = <&gpio0 1>;
wakeup-gpios = <&gpio0 2>;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- ERR_CAST not PTR_CAST
ChangeLog v1->v2:
- Fixed a cast and a variable name.
- I still don't know how to compile this but hey the zeroday
robot does.
---
drivers/staging/wfx/bus_spi.c | 11 +
drivers/staging/wfx/main.c| 42 ---
drivers/staging/wfx/main.h| 2 --
3 files changed, 9 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index e8da61fb096b..88ca5d453e83 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -8,7 +8,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -21,10 +20,6 @@
#include "main.h"
#include "bh.h"
-static int gpio_reset = -2;
-module_param(gpio_reset, int, 0644);
-MODULE_PARM_DESC(gpio_reset, "gpio number for reset. -1 for none.");
-
#define SET_WRITE 0x7FFF/* usage: and operation */
#define SET_READ 0x8000 /* usage: or operation */
@@ -211,10 +206,14 @@ static int wfx_spi_probe(struct spi_device *func)
bus->need_swab = true;
spi_set_drvdata(func, bus);
- bus->gpio_reset = wfx_get_gpio(&func->dev, gpio_reset, "reset");
+ bus->gpio_reset = devm_gpiod_get_optional(&func->dev, "reset"
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(bus->gpio_reset))
+ return PTR_ERR(bus->gpio_reset);
if (!bus->gpio_reset) {
dev_warn(&func->dev, "try to load firmware anyway\n");
} else {
+ gpiod_set_consumer_name(bus->gpio_reset, "wfx reset");
if (spi_get_device_id(func)->driver_data & WFX_RESET_INVERTED)
gpiod_toggle_active_low(bus->gpio_reset);
gpiod_set_value_cansleep(bus->gpio_reset, 1);
diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 6bd96f476388..d90169fe1851 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -41,10 +40,6 @@ MODULE_DESCRIPTION("Silicon Labs 802.11 Wireless LAN driver
for WFx");
MODULE_AUTHOR("Jérôme Pouiller ");
MODULE_LICENSE("GPL");
-static int gpio_wakeup = -2;
-module_param(gpio_wakeup, int, 0644);
-MODULE_PARM_DESC(gpio_wakeup, "gpio number for wakeup. -1 for none.");
-
#define RATETAB_ENT(_rate, _rateid, _flags) { \
.bitrate = (_rate), \
.hw_value = (_rateid), \
@@ -170,38 +165,6 @@ bool wfx_api_older_than(struct wfx_dev *wdev, int major,
int minor)
return false;
}
-struct gpio_desc *wfx_get_gpio(struct device *dev,
- int override, const char *label)
-{
- struct gpio_desc *ret;
- char label_buf[256];
-
- if (override >= 0) {
- snprintf(label_buf, sizeof(label_buf), "wfx_%s", label);
- ret = ERR_PTR(devm_gpio_request_one(dev, override,
- GPIOF_OUT_INIT_LOW,
- label_buf));
- if (!ret)
- ret = gpio_to_desc(override);
- } else if (override == -1) {
- ret = NULL;
- } else {
- ret = devm_gpiod_get(dev, label, GPIOD_OUT_LOW);
- }
- if (IS_ERR_OR_NULL(ret)) {
- if (!ret || PTR_ERR(ret) == -ENOENT)
- dev_warn(dev, "gpio %s is not defined\n", label);
- else
- dev_warn(dev, "error while requesting gpio %s\n",
-label);
- ret = NULL;
- } else {
- dev_dbg(dev, "using gpio %d for %s\n",
- desc_to_gpio(ret), label);
- }
- return ret;
-}
-
/* NOTE: wfx_send_pds() destroy buf */
int wfx_send_pds(struct wfx_dev *wdev, u8 *buf, size_t len)
{
@@ -340,7 +303,10 @@ struct wfx_dev *wfx_init_common(struct device *dev,
memcpy(&wdev->pdata, pdata, sizeof(*pdata));
of_property_read_string(dev->of_node, "
[PATCH v2] staging: wfx: Get descriptors for GPIOs
The code has the functionality to insert the GPIO lines using
the global GPIO numbers through module parameters.
As we are clearly deprecating the use of global GPIO numbers
look up the GPIO descriptors from the device instead. This
usually falls back to device hardware descriptions using e.g.
device tree or ACPI. This device clearly supports device
tree when used over SPI for example.
For example, this can be supplied in the device tree like so:
wfx@0x01 {
compatible = "silabs,wf200";
reset-gpios = <&gpio0 1>;
wakeup-gpios = <&gpio0 2>;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Fixed a cast and a variable name.
- I still don't know how to compile this but hey the zeroday
robot does.
---
drivers/staging/wfx/bus_spi.c | 11 +
drivers/staging/wfx/main.c| 42 ---
drivers/staging/wfx/main.h| 2 --
3 files changed, 9 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index e8da61fb096b..88ca5d453e83 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -8,7 +8,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -21,10 +20,6 @@
#include "main.h"
#include "bh.h"
-static int gpio_reset = -2;
-module_param(gpio_reset, int, 0644);
-MODULE_PARM_DESC(gpio_reset, "gpio number for reset. -1 for none.");
-
#define SET_WRITE 0x7FFF/* usage: and operation */
#define SET_READ 0x8000 /* usage: or operation */
@@ -211,10 +206,14 @@ static int wfx_spi_probe(struct spi_device *func)
bus->need_swab = true;
spi_set_drvdata(func, bus);
- bus->gpio_reset = wfx_get_gpio(&func->dev, gpio_reset, "reset");
+ bus->gpio_reset = devm_gpiod_get_optional(&func->dev, "reset"
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(bus->gpio_reset))
+ return PTR_ERR(bus->gpio_reset);
if (!bus->gpio_reset) {
dev_warn(&func->dev, "try to load firmware anyway\n");
} else {
+ gpiod_set_consumer_name(bus->gpio_reset, "wfx reset");
if (spi_get_device_id(func)->driver_data & WFX_RESET_INVERTED)
gpiod_toggle_active_low(bus->gpio_reset);
gpiod_set_value_cansleep(bus->gpio_reset, 1);
diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 6bd96f476388..4d9119529c94 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -41,10 +40,6 @@ MODULE_DESCRIPTION("Silicon Labs 802.11 Wireless LAN driver
for WFx");
MODULE_AUTHOR("Jérôme Pouiller ");
MODULE_LICENSE("GPL");
-static int gpio_wakeup = -2;
-module_param(gpio_wakeup, int, 0644);
-MODULE_PARM_DESC(gpio_wakeup, "gpio number for wakeup. -1 for none.");
-
#define RATETAB_ENT(_rate, _rateid, _flags) { \
.bitrate = (_rate), \
.hw_value = (_rateid), \
@@ -170,38 +165,6 @@ bool wfx_api_older_than(struct wfx_dev *wdev, int major,
int minor)
return false;
}
-struct gpio_desc *wfx_get_gpio(struct device *dev,
- int override, const char *label)
-{
- struct gpio_desc *ret;
- char label_buf[256];
-
- if (override >= 0) {
- snprintf(label_buf, sizeof(label_buf), "wfx_%s", label);
- ret = ERR_PTR(devm_gpio_request_one(dev, override,
- GPIOF_OUT_INIT_LOW,
- label_buf));
- if (!ret)
- ret = gpio_to_desc(override);
- } else if (override == -1) {
- ret = NULL;
- } else {
- ret = devm_gpiod_get(dev, label, GPIOD_OUT_LOW);
- }
- if (IS_ERR_OR_NULL(ret)) {
- if (!ret || PTR_ERR(ret) == -ENOENT)
- dev_warn(dev, "gpio %s is not defined\n", label);
- else
- dev_warn(dev, "error while requesting gpio %s\n",
-label);
- ret = NULL;
- } else {
- dev_dbg(dev, "using gpio %d for %s\n",
- desc_to_gpio(ret), label);
- }
- return ret;
-}
-
/* NOTE: wfx_send_pds() destroy buf */
int wfx_send_pds(struct wfx_dev *wdev, u8 *buf, size_t len)
{
@@ -340,7 +303,10 @@ struct wfx_dev *wfx_init_common(struct device *dev,
memcpy(&wdev->pdata, pdata, sizeof(*pdata));
of_property_read_string(dev->of_node, "config-file",
[PATCH] staging: media: atomisp: Convert to GPIO descriptors
Convert the atomisp LM3554 driver to use GPIO descriptors
fully. It was already retrieveing the GPIO lines as descriptors
but for some reason converting them back into global GPIO
numbers. There is no reason to do this, just deal with the
descriptors as-is.
Cc: Mauro Carvalho Chehab
Signed-off-by: Linus Walleij
---
.../media/atomisp/i2c/atomisp-lm3554.c| 68 ---
.../media/atomisp/include/media/lm3554.h | 7 +-
2 files changed, 32 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 809010af7855..7ca7378b1859 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -19,14 +19,13 @@
#include
#include
#include
-#include
+#include
#include
#include "../include/media/lm3554.h"
#include
#include
#include
-#include
#include "../include/linux/atomisp_gmin_platform.h"
#include "../include/linux/atomisp.h"
@@ -173,7 +172,7 @@ static void lm3554_flash_off_delay(struct timer_list *t)
struct lm3554 *flash = from_timer(flash, t, flash_off_delay);
struct lm3554_platform_data *pdata = flash->pdata;
- gpio_set_value(pdata->gpio_strobe, 0);
+ gpiod_set_value(pdata->gpio_strobe, 0);
}
static int lm3554_hw_strobe(struct i2c_client *client, bool strobe)
@@ -209,7 +208,7 @@ static int lm3554_hw_strobe(struct i2c_client *client, bool
strobe)
* so must strobe off here
*/
if (timer_pending)
- gpio_set_value(pdata->gpio_strobe, 0);
+ gpiod_set_value(pdata->gpio_strobe, 0);
/* Restore flash current settings */
ret = lm3554_set_flash(flash);
@@ -217,7 +216,7 @@ static int lm3554_hw_strobe(struct i2c_client *client, bool
strobe)
goto err;
/* Strobe on Flash */
- gpio_set_value(pdata->gpio_strobe, 1);
+ gpiod_set_value(pdata->gpio_strobe, 1);
return 0;
err:
@@ -627,7 +626,7 @@ static int __lm3554_s_power(struct lm3554 *flash, int power)
int ret;
/*initialize flash driver*/
- gpio_set_value(pdata->gpio_reset, power);
+ gpiod_set_value(pdata->gpio_reset, power);
usleep_range(100, 100 + 1);
if (power) {
@@ -766,33 +765,22 @@ static int lm3554_gpio_init(struct i2c_client *client)
struct lm3554_platform_data *pdata = flash->pdata;
int ret;
- if (!gpio_is_valid(pdata->gpio_reset))
+ if (!pdata->gpio_reset)
return -EINVAL;
- ret = gpio_direction_output(pdata->gpio_reset, 0);
+ ret = gpiod_direction_output(pdata->gpio_reset, 0);
if (ret < 0)
- goto err_gpio_reset;
+ return ret;
dev_info(&client->dev, "flash led reset successfully\n");
- if (!gpio_is_valid(pdata->gpio_strobe)) {
- ret = -EINVAL;
- goto err_gpio_dir_reset;
- }
+ if (!pdata->gpio_strobe)
+ return -EINVAL;
- ret = gpio_direction_output(pdata->gpio_strobe, 0);
+ ret = gpiod_direction_output(pdata->gpio_strobe, 0);
if (ret < 0)
- goto err_gpio_strobe;
+ return ret;
return 0;
-
-err_gpio_strobe:
- gpio_free(pdata->gpio_strobe);
-err_gpio_dir_reset:
- gpio_direction_output(pdata->gpio_reset, 0);
-err_gpio_reset:
- gpio_free(pdata->gpio_reset);
-
- return ret;
}
static int lm3554_gpio_uninit(struct i2c_client *client)
@@ -802,16 +790,14 @@ static int lm3554_gpio_uninit(struct i2c_client *client)
struct lm3554_platform_data *pdata = flash->pdata;
int ret;
- ret = gpio_direction_output(pdata->gpio_strobe, 0);
+ ret = gpiod_direction_output(pdata->gpio_strobe, 0);
if (ret < 0)
return ret;
- ret = gpio_direction_output(pdata->gpio_reset, 0);
+ ret = gpiod_direction_output(pdata->gpio_reset, 0);
if (ret < 0)
return ret;
- gpio_free(pdata->gpio_strobe);
- gpio_free(pdata->gpio_reset);
return 0;
}
@@ -819,18 +805,18 @@ static void *lm3554_platform_data_func(struct i2c_client
*client)
{
static struct lm3554_platform_data platform_data;
- platform_data.gpio_reset =
- desc_to_gpio(gpiod_get_index(&client->dev,
-NULL, 2, GPIOD_OUT_LOW));
- platform_data.gpio_strobe =
- desc_to_gpio(gpiod_get_index(&client->dev,
-NULL, 0, GPIOD_OUT_LOW));
- platform_data.gpio_torch =
- desc_to_gpio(gpiod_get_index(&client->dev,
-NULL, 1, GPIOD_OUT
[PATCH] staging: wfx: Get descriptors for GPIOs
The code has the functionality to insert the GPIO lines using
the global GPIO numbers through module parameters.
As we are clearly deprecating the use of global GPIO numbers
look up the GPIO descriptors from the device instead. This
usually falls back to device hardware descriptions using e.g.
device tree or ACPI. This device clearly supports device
tree when used over SPI for example.
For example, this can be supplied in the device tree like so:
wfx@0x01 {
compatible = "silabs,wf200";
reset-gpios = <&gpio0 1>;
wakeup-gpios = <&gpio0 2>;
};
Cc: Jérôme Pouiller
Signed-off-by: Linus Walleij
---
drivers/staging/wfx/bus_spi.c | 11 +
drivers/staging/wfx/main.c| 42 ---
drivers/staging/wfx/main.h| 2 --
3 files changed, 9 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c
index e8da61fb096b..88ca5d453e83 100644
--- a/drivers/staging/wfx/bus_spi.c
+++ b/drivers/staging/wfx/bus_spi.c
@@ -8,7 +8,6 @@
*/
#include
#include
-#include
#include
#include
#include
@@ -21,10 +20,6 @@
#include "main.h"
#include "bh.h"
-static int gpio_reset = -2;
-module_param(gpio_reset, int, 0644);
-MODULE_PARM_DESC(gpio_reset, "gpio number for reset. -1 for none.");
-
#define SET_WRITE 0x7FFF/* usage: and operation */
#define SET_READ 0x8000 /* usage: or operation */
@@ -211,10 +206,14 @@ static int wfx_spi_probe(struct spi_device *func)
bus->need_swab = true;
spi_set_drvdata(func, bus);
- bus->gpio_reset = wfx_get_gpio(&func->dev, gpio_reset, "reset");
+ bus->gpio_reset = devm_gpiod_get_optional(&func->dev, "reset"
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(bus->gpio_reset))
+ return PTR_ERR(bus->gpio_reset);
if (!bus->gpio_reset) {
dev_warn(&func->dev, "try to load firmware anyway\n");
} else {
+ gpiod_set_consumer_name(bus->gpio_reset, "wfx reset");
if (spi_get_device_id(func)->driver_data & WFX_RESET_INVERTED)
gpiod_toggle_active_low(bus->gpio_reset);
gpiod_set_value_cansleep(bus->gpio_reset, 1);
diff --git a/drivers/staging/wfx/main.c b/drivers/staging/wfx/main.c
index 6bd96f476388..cd58173f7294 100644
--- a/drivers/staging/wfx/main.c
+++ b/drivers/staging/wfx/main.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -41,10 +40,6 @@ MODULE_DESCRIPTION("Silicon Labs 802.11 Wireless LAN driver
for WFx");
MODULE_AUTHOR("Jérôme Pouiller ");
MODULE_LICENSE("GPL");
-static int gpio_wakeup = -2;
-module_param(gpio_wakeup, int, 0644);
-MODULE_PARM_DESC(gpio_wakeup, "gpio number for wakeup. -1 for none.");
-
#define RATETAB_ENT(_rate, _rateid, _flags) { \
.bitrate = (_rate), \
.hw_value = (_rateid), \
@@ -170,38 +165,6 @@ bool wfx_api_older_than(struct wfx_dev *wdev, int major,
int minor)
return false;
}
-struct gpio_desc *wfx_get_gpio(struct device *dev,
- int override, const char *label)
-{
- struct gpio_desc *ret;
- char label_buf[256];
-
- if (override >= 0) {
- snprintf(label_buf, sizeof(label_buf), "wfx_%s", label);
- ret = ERR_PTR(devm_gpio_request_one(dev, override,
- GPIOF_OUT_INIT_LOW,
- label_buf));
- if (!ret)
- ret = gpio_to_desc(override);
- } else if (override == -1) {
- ret = NULL;
- } else {
- ret = devm_gpiod_get(dev, label, GPIOD_OUT_LOW);
- }
- if (IS_ERR_OR_NULL(ret)) {
- if (!ret || PTR_ERR(ret) == -ENOENT)
- dev_warn(dev, "gpio %s is not defined\n", label);
- else
- dev_warn(dev, "error while requesting gpio %s\n",
-label);
- ret = NULL;
- } else {
- dev_dbg(dev, "using gpio %d for %s\n",
- desc_to_gpio(ret), label);
- }
- return ret;
-}
-
/* NOTE: wfx_send_pds() destroy buf */
int wfx_send_pds(struct wfx_dev *wdev, u8 *buf, size_t len)
{
@@ -340,7 +303,10 @@ struct wfx_dev *wfx_init_common(struct device *dev,
memcpy(&wdev->pdata, pdata, sizeof(*pdata));
of_property_read_string(dev->of_node, "config-file",
&wdev->pdata.file_pds);
- wdev->pdata.gpio_wakeup = wfx_get_gpio(dev, gpio_wakeup, "wakeup");
+ wdev-
Re: [PATCH v1 0/3] Tegra GPIO: Minor code clean up
On Tue, Jan 7, 2020 at 10:31 AM Bartosz Golaszewski wrote: > wt., 7 sty 2020 o 10:29 Linus Walleij napisał(a): > > > Ugh, I now noticed I responded to Thierry only after applying this to my > > > tree. > > > > > > Anyway, it shouldn't be a problem. I'll take more care next time. > > > > OK shall I drop the patches from my tree then? No big deal. > > > > If you're fine with this, sure! OK dropped them, hadn't even pushed the branch out yet. Soon reaching the top of my mailbox so I will be pushing the branches for the autobuilders and later tonight for-next. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 0/3] Tegra GPIO: Minor code clean up
On Tue, Jan 7, 2020 at 9:25 AM Bartosz Golaszewski wrote: > pon., 6 sty 2020 o 23:59 Linus Walleij napisał(a): > > On Sun, Dec 15, 2019 at 7:31 PM Dmitry Osipenko wrote: > > > > > I was investigating why CPU hangs during of GPIO driver suspend and in > > > the end it turned out that it is a Broadcom WiFi driver problem because > > > it keeps OOB wake-interrupt enabled while WLAN interface is DOWN and this > > > may cause a bit weird CPU hang on writing to INT_ENB register during of > > > GPIO driver suspend. Meanwhile I also noticed that a few things could be > > > improved in the driver, that's what this small series addresses. > > > > > > Dmitry Osipenko (3): > > > gpio: tegra: Use generic readl_relaxed/writel_relaxed accessors > > > gpio: tegra: Properly handle irq_set_irq_wake() error > > > gpio: tegra: Use NOIRQ phase for suspend/resume > > > > All three patches applied with Thierry's review/test tag. > > > > Yours, > > Linus Walleij > > Ugh, I now noticed I responded to Thierry only after applying this to my tree. > > Anyway, it shouldn't be a problem. I'll take more care next time. OK shall I drop the patches from my tree then? No big deal. Thanks, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1 0/3] Tegra GPIO: Minor code clean up
On Sun, Dec 15, 2019 at 7:31 PM Dmitry Osipenko wrote: > I was investigating why CPU hangs during of GPIO driver suspend and in > the end it turned out that it is a Broadcom WiFi driver problem because > it keeps OOB wake-interrupt enabled while WLAN interface is DOWN and this > may cause a bit weird CPU hang on writing to INT_ENB register during of > GPIO driver suspend. Meanwhile I also noticed that a few things could be > improved in the driver, that's what this small series addresses. > > Dmitry Osipenko (3): > gpio: tegra: Use generic readl_relaxed/writel_relaxed accessors > gpio: tegra: Properly handle irq_set_irq_wake() error > gpio: tegra: Use NOIRQ phase for suspend/resume All three patches applied with Thierry's review/test tag. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fbtft: Do not hardcode SPI CS polarity inversion
The current use of the mode flag SPI_CS_HIGH is fragile: it
overwrites anything already assigned by the SPI core.
Assign ^= SPI_CS_HIGH since we might be active high
already, and that is usually the case with GPIOs used
for chip select, even if they are in practice active low.
Add a comment clarifying why ^= SPI_CS_HIGH is the right
choice here.
Reported-by: Mark Brown
Signed-off-by: Linus Walleij
---
drivers/staging/fbtft/fb_uc1611.c| 12 +---
drivers/staging/fbtft/fb_watterott.c | 13 ++---
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/fbtft/fb_uc1611.c
b/drivers/staging/fbtft/fb_uc1611.c
index e763205e9e4f..f61e373c75e9 100644
--- a/drivers/staging/fbtft/fb_uc1611.c
+++ b/drivers/staging/fbtft/fb_uc1611.c
@@ -63,11 +63,17 @@ static int init_display(struct fbtft_par *par)
{
int ret;
- /* Set CS active high */
- par->spi->mode |= SPI_CS_HIGH;
+ /*
+* Set CS active inverse polarity: just setting SPI_CS_HIGH does not
+* work with GPIO based chip selects that are logically active high
+* but inverted inside the GPIO library, so enforce inverted
+* semantics.
+*/
+ par->spi->mode ^= SPI_CS_HIGH;
ret = spi_setup(par->spi);
if (ret) {
- dev_err(par->info->device, "Could not set SPI_CS_HIGH\n");
+ dev_err(par->info->device,
+ "Could not set inverse CS polarity\n");
return ret;
}
diff --git a/drivers/staging/fbtft/fb_watterott.c
b/drivers/staging/fbtft/fb_watterott.c
index 27cc8eabcbe9..76b25df376b8 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -150,10 +150,17 @@ static int init_display(struct fbtft_par *par)
/* enable SPI interface by having CS and MOSI low during reset */
save_mode = par->spi->mode;
- par->spi->mode |= SPI_CS_HIGH;
- ret = spi_setup(par->spi); /* set CS inactive low */
+ /*
+* Set CS active inverse polarity: just setting SPI_CS_HIGH does not
+* work with GPIO based chip selects that are logically active high
+* but inverted inside the GPIO library, so enforce inverted
+* semantics.
+*/
+ par->spi->mode ^= SPI_CS_HIGH;
+ ret = spi_setup(par->spi);
if (ret) {
- dev_err(par->info->device, "Could not set SPI_CS_HIGH\n");
+ dev_err(par->info->device,
+ "Could not set inverse CS polarity\n");
return ret;
}
write_reg(par, 0x00); /* make sure mode is set */
--
2.23.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] gpiolib: Fix incorrect use of find_next_zero_bit()
On Sat, Sep 29, 2018 at 2:19 PM Janusz Krzysztofik wrote:
> Commit b17566a6b08b ("gpiolib: Implement fast processing path in
> get/set array"), already fixed to some extent with commit 5d581d7e8cdc
> ("gpiolib: Fix missing updates of bitmap index"), introduced a new mode
> of processing bitmaps where bits applicable for fast bitmap processing
> path are supposed to be skipped while iterating bits which don't apply.
> Unfortunately, find_next_zero_bit() function supposed to skip over
> those fast bits is always called with a 'start' argument equal to an
> index of last zero bit found and returns that index value again an
> again, causing an infinite loop.
>
> Fix it by incrementing the index uncoditionally before
> find_next_zero_bit() is optionally called.
>
> Reported-by: Marek Szyprowski
> Signed-off-by: Janusz Krzysztofik
Patch applied with Marek's Tested-by.
Thanks to both of you for digging in and fixing this up!
Now we are in good shape for the v4.20 cycle :)
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] gpiolib: Fix array members of same chip processed separately
On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik wrote:
> New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays
> matching GPIO hardware") forcibly tries to find an array member which
> has its array index number equal to its hardware pin number and set
> up an array info for possible fast bitmap processing of all arrray
> pins belonging to that chip which also satisfy that numbering rule.
>
> Depending on array content, it may happen that consecutive array
> members which belong to the same chip but don't have array indexes
> equal to their pin hardware numbers will be split into groups, some of
> them processed together via the fast bitmap path, and rest of them
> separetely. However, applications may expect all those pins being
> processed together with a single call to .set_multiple() chip callback,
> like that was done before the change.
>
> Limit applicability of fast bitmap processing path to cases where all
> pins of consecutive array members starting from 0 which belong to the
> same chip have their hardware numbers equal to their corresponding
> array indexes. That should still speed up processing of applications
> using whole GPIO banks as I/O ports, while not breaking simultaneous
> manipulation of consecutive pins of the same chip which don't follow
> the equal numbering rule.
>
> Cc: Jonathan Corbet
> Signed-off-by: Janusz Krzysztofik
Patch applied!
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] gpiolib: Fix missing updates of bitmap index
On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik wrote:
> In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast
> processing path in get/set array"), bitmap index is not updated with
> next found zero bit position as it should while skipping over pins
> already processed via fast bitmap path, possibly resulting in an
> infinite loop. Fix it.
>
> Signed-off-by: Janusz Krzysztofik
Patch applied!
Thanks for working on getting this into shape!
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 4/4] gpiolib: Implement fast processing path in get/set array
On Thu, Sep 20, 2018 at 3:11 AM Marek Szyprowski wrote: > I've just noticed that this patch landed in today's linux-next. Sadly it > breaks booting of Exynos5250-based Samsung Snow Chromebook (ARM 32bit, > device-tree source arch/arm/boot/dts/exynos5250-snow.dts). Thanks for testing on this platform! > Booting hangs after detecting MMC cards. Reverting this patch fixes the > boot. I will try later to add some debugs and investigate it further what > really happens when booting hangs. How typical. I hope we can fix it, because this should mean speedups for your platform. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 0/4] gpiolib: speed up GPIO array processing
On Thu, Sep 13, 2018 at 2:22 AM Linus Walleij wrote: > On Wed, Sep 5, 2018 at 11:49 PM Janusz Krzysztofik > wrote: > > > The goal is to boost performance of get/set array functions while > > processing GPIO arrays which represent pins of a signle chip in > > hardware order. If resulting performance is close to PIO, GPIO API > > can be used for data I/O without much loss of speed. > > I applied the v8 to an immutable branch and pushed to kernelorg > so the build servers can churn it a bit, and if it works fine > then we can merge this into the devel branch and also set up > that as something other subsystems can pull in if they need it. > > I'm really excited to merge this! The branch built with no problems, and now I merged this into devel. If that also builds fine, I will let it hit linux-next so we can stabilize it for v4.20. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v8 0/4] gpiolib: speed up GPIO array processing
On Wed, Sep 5, 2018 at 11:49 PM Janusz Krzysztofik wrote: > The goal is to boost performance of get/set array functions while > processing GPIO arrays which represent pins of a signle chip in > hardware order. If resulting performance is close to PIO, GPIO API > can be used for data I/O without much loss of speed. I applied the v8 to an immutable branch and pushed to kernelorg so the build servers can churn it a bit, and if it works fine then we can merge this into the devel branch and also set up that as something other subsystems can pull in if they need it. I'm really excited to merge this! Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 1/4] gpiolib: Pass bitmaps, not integer arrays, to get/set array
On Wed, Aug 29, 2018 at 10:48 PM Janusz Krzysztofik wrote:
So it's no secret that I strongly fancy this patch set.
What would be great at this point is to have some people test
that the drivers still work as expected, even better if they can do
some benchmarking.
> - values[PIN_DATA0 + i] = !!(val & BIT(i));
> - values[PIN_CTRL_RS] = rs;
> + value_bitmap[0] = val;
> + __assign_bit(PIN_CTRL_RS, value_bitmap, rs);
> n = 9;
> if (hd->pins[PIN_CTRL_RW]) {
> - values[PIN_CTRL_RW] = 0;
> + __clear_bit(PIN_CTRL_RW, value_bitmap);
This seems fine to me, but I understand the comment that the
code becomes harder to read.
I think part of it is those __assign_bit() and __clear_bit() with
the double-underscore of unclear meaning. The meaning is
"non atomic" IIRC, so maybe I should move forward
with my plan to send a sed script to Torvalds just renaming all
of those to something sane in the next merge window.
Like __assign_bit() -> assign_bit_nonatomic()
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC RFT PATCH 0/4] gpiolib: speed up GPIO array processing
On Tue, Aug 21, 2018 at 1:42 AM Janusz Krzysztofik wrote: > This series is a follow up of the former "mtd: rawnand: ams-delta: Use > gpio-omap accessors for data I/O" which already contained some changes > to gpiolib. Those previous attempts were commented by Borris Brezillon > who suggested using GPIO API modified to accept bitmaps, and by Linus > Walleij who suggested still more great ideas for further immprovement > of the proposed API changes - thanks! > > The goal is to boost performans of get/set array functions while > processing GPIO arrays which represent pins of a signle chip in > hardware order. If resulting performance is close to PIO, GPIO API > can be used for data I/O without much loss of speed. Hands down, this is a very pretty patch set. I'm a big fan already. This is mainly because it fulfills the requirement for libraries to be narrow and deep, which is what we want. This refers to John Ousterhouts software design philosophy, here is a great lecture if you haven't seen it already: https://www.youtube.com/watch?v=bmSAYlu0NcY Let's get this into v1 and get some testing and merge it for v4.20 ASAP so we get some proper testing before the v4.20 merge window. It would be excellent if some of the current users of the array API could provide tested-by's or at least ACKs. For example ts-nbus.c must be a big benefactor. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/4] staging: wilc1000: use descriptor-based interface for GPIO
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 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/2] gpio: mediatek: add driver for MT7621
On Thu, Jul 5, 2018 at 3:43 PM Sergio Paracuellos wrote: > Add driver support for gpio of MT7621 SoC. > > Signed-off-by: Sergio Paracuellos > Reviewed-by: NeilBrown This is looking really good. Patch applied: anything remaining can surely be patched up in-tree. > +/* > + * Copyright (C) 2009-2011 Gabor Juhos > + * Copyright (C) 2013 John Crispin > + */ All OpenWRT drivers are moving upstream and I like it :) Gabo and John wrote like 90% of them on their own :D > +#define GPIO_BANK_WIDE 0x04 Nitpick: we usually call this "stride" rather than "wide". I changed it while applying the patch. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/2] dt-bindings: document gpio-mt7621 bindings
On Thu, Jul 5, 2018 at 3:43 PM Sergio Paracuellos wrote: > Add a devicetree binding documentation for the mt7621 gpio. > > Signed-off-by: Sergio Paracuellos > Reviewed-by: NeilBrown Patch applied with Rob's review tag. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] dt-bindings: document gpio-mt7621 bindings
On Thu, Jun 14, 2018 at 4:33 PM, Rob Herring wrote: > On Thu, Jun 14, 2018 at 8:14 AM, Linus Walleij > wrote: >> On Wed, Jun 13, 2018 at 9:28 PM, Rob Herring wrote: >> >>>> "Some system-on-chips (SoCs) use the concept of GPIO banks. ... >>>> Usually each such bank is >>>> exposed in the device tree as an individual gpio-controller node. ..." >>> >>> This should be conditioned on being able to divide up the registers by >>> bank which seems like you can't. Or there's the case like the DW GPIO >>> block and the number of banks is configurable. >> >> If it is possible to create one device per bank I usually prefer that >> approach, as it also (often) makes it possible to use the >> generic GPIO library, i.e. the hardware abstraction start to >> share more with other GPIO controllers. > > But that should be possible whether there are banks in DT or not, right? Possible yes, but more complex, requireing a bigger and more complex chunk of code to get it right. Which we don't have for Linux (I don't know about $OS). For 1 bank = 1 device, all callbacks etc naturally offsets to something like 0..31 landing in (1 << offset) which makes for a simple support library. If there is more complex calculations, more complex helper libs are required and maybe not even worth it, ending up with more duplicated or slightly-different code. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] dt-bindings: document gpio-mt7621 bindings
On Thu, Jun 14, 2018 at 6:45 AM, Sergio Paracuellos
wrote:
> Ok, so... does the following single node sounds acceptable?
>
> gpio: gpio@600 {
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> compatible = "mediatek,mt7621-gpio";
> gpio-controller;
> interrupt-controller;
> reg = <0x600 0x60>;
> interrupt-parent = <&gic>;
> interrupts = ;
> mediatek,gpio-bank-widths = <32 32 32>;
Why would you need this? It is pretty obvious from the
compatible string isn't it? Just use that to tell that
"aha, it is mediatek,mt7321-gpio, so it has 3x32 GPIOs
indexed from 0..95".
No need of overspecifying stuff.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] dt-bindings: document gpio-mt7621 bindings
On Wed, Jun 13, 2018 at 9:28 PM, Rob Herring wrote: >> "Some system-on-chips (SoCs) use the concept of GPIO banks. ... >> Usually each such bank is >> exposed in the device tree as an individual gpio-controller node. ..." > > This should be conditioned on being able to divide up the registers by > bank which seems like you can't. Or there's the case like the DW GPIO > block and the number of banks is configurable. If it is possible to create one device per bank I usually prefer that approach, as it also (often) makes it possible to use the generic GPIO library, i.e. the hardware abstraction start to share more with other GPIO controllers. >> If this is not a good approach, could you please me point me out to a >> device tree example where >> the correct approach is being used? > > I'm not sure offhand. There are lots of examples of single nodes I'm > sure. Which ones have banks I haven't a clue. IIRC, there were some > cases where the bank # was part of the GPIO cells, but I seem to > recall Linus prefers not having 3 cells. I don't like 3 cells, stuff is complicated enough as it is already. Better in that case to concatenate the offsets and instead of having an extra cell 0, 1 and offsets 0-31, 0-31 have two cells and offsets 0-63. My reasoning is that since it is represented by a single device we are indexing into that one device from 0-n. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] gpio: mediatek: add driver for MT7621
A second thought:
On Fri, Jun 8, 2018 at 1:59 PM, Linus Walleij wrote:
>> + select GPIOLIB_IRQCHIP
>
> You are not using this so I guess remove that line.
(...)
>> +static int
>> +mediatek_gpio_to_irq(struct gpio_chip *chip, unsigned int pin)
>> +{
>> + struct mtk_data *gpio_data = gpiochip_get_data(chip);
>> + struct mtk_gc *rg = to_mediatek_gpio(chip);
>> +
>> + return irq_create_mapping(gpio_data->gpio_irq_domain,
>> + pin + (rg->bank * MTK_BANK_WIDTH));
>> +}
>
> So this is the result of a custom IRQdomain because you
> can't use the generic GPIO IRQ lib. Oh well, we have to live
> with it I guess.
I think maybe you can actually use the generic GPIO IRQCHIP.
It is OK to call gpiochip_set_chained_irqchip() several times.
If you just mark the line with IRQF_SHARED then the handler
will just loop over all three banks until you find a hit, provided
you code it up properly.
There were some problems with removing an irqchip like
that but your driver is anyway a bool so I think it might work
just fine.
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] gpio: mediatek: add driver for MT7621
REG_STAT, BIT(bit));
> + }
> + }
> +}
> +
> +static void
> +mediatek_gpio_irq_unmask(struct irq_data *d)
> +{
> + struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
> + int pin = d->hwirq;
> + int bank = pin / MTK_BANK_WIDTH;
> + struct mtk_gc *rg = &gpio_data->gc_map[bank];
> + unsigned long flags;
> + u32 rise, fall;
> +
> + if (!rg)
> + return;
> +
> + spin_lock_irqsave(&rg->lock, flags);
> + rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
> + fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
> + mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (PIN_MASK(pin) & rg->rising));
> + mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (PIN_MASK(pin) &
> rg->falling));
> + spin_unlock_irqrestore(&rg->lock, flags);
> +}
> +
> +static void
> +mediatek_gpio_irq_mask(struct irq_data *d)
> +{
> + struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
> + int pin = d->hwirq;
> + int bank = pin / MTK_BANK_WIDTH;
> + struct mtk_gc *rg = &gpio_data->gc_map[bank];
> + unsigned long flags;
> + u32 rise, fall;
> +
> + if (!rg)
> + return;
> +
> + spin_lock_irqsave(&rg->lock, flags);
> + rise = mtk_gpio_r32(rg, GPIO_REG_REDGE);
> + fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
> + mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall & ~PIN_MASK(pin));
> + mtk_gpio_w32(rg, GPIO_REG_REDGE, rise & ~PIN_MASK(pin));
> + spin_unlock_irqrestore(&rg->lock, flags);
> +}
Looks OK.
> +static int
> +mediatek_gpio_irq_type(struct irq_data *d, unsigned int type)
> +{
> + struct mtk_data *gpio_data = irq_data_get_irq_chip_data(d);
> + int pin = d->hwirq;
> + int bank = pin / MTK_BANK_WIDTH;
> + struct mtk_gc *rg = &gpio_data->gc_map[bank];
> + u32 mask = PIN_MASK(pin);
> +
> + if (!rg)
> + return -1;
> +
> + if (type == IRQ_TYPE_PROBE) {
> + if ((rg->rising | rg->falling) & mask)
> + return 0;
> +
> + type = IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING;
> + }
> +
> + if (type & IRQ_TYPE_EDGE_RISING)
> + rg->rising |= mask;
> + else
> + rg->rising &= ~mask;
> +
> + if (type & IRQ_TYPE_EDGE_FALLING)
> + rg->falling |= mask;
> + else
> + rg->falling &= ~mask;
I don't understand this, the register map contains:
GPIO_REG_HLVL, GPIO_REG_LLVL, yet high/low level
interrupts are not implemented? Why not? Can't be that hard
now that you fixed everything else!
> +static struct irq_chip mediatek_gpio_irq_chip = {
> + .name = "GPIO",
> + .irq_unmask = mediatek_gpio_irq_unmask,
> + .irq_mask = mediatek_gpio_irq_mask,
> + .irq_mask_ack = mediatek_gpio_irq_mask,
> + .irq_set_type = mediatek_gpio_irq_type,
> +};
When implementing custom irqchips it is important to also
implement .irq_request_resources() and
.irq_release_resources() and make sure these call
gpiochip_[un]lock_as_irq().
See for example
drivers/gpio/gpio-dwapb.c
for an example.
> +static const struct of_device_id mediatek_gpio_match[] = {
> + { .compatible = "mediatek,mt7621-gpio" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mediatek_gpio_match);
> +
> +static struct platform_driver mediatek_gpio_driver = {
> + .probe = mediatek_gpio_probe,
> + .driver = {
> + .name = "mt7621_gpio",
> + .of_match_table = mediatek_gpio_match,
> + },
> +};
> +
> +module_platform_driver(mediatek_gpio_driver);
If you're not implementing .remove() I don't think this will
really work fine as a module. Also the Kconfig is a bool.
I guess you want to use
builtin_platform_driver()?
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: nvec: convert to use GPIO descriptors
On Thu, Apr 19, 2018 at 1:01 PM, Marc Dietrich wrote: > Use GPIO descriptors instead of relying on the old method. > > Cc: Linus Walleij > Signed-off-by: Marc Dietrich > --- > This obsolets the ToDo reminder sent by Linus a few hours ago. Awesome :) Reviewed-by: Linus Walleij Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/9] staging: greybus: Add TODO file with GPIO work items
To make sure that these drivers do not leave staging before they are properly converted to use the new GPIO descriptor API, and the GPIOLIB_IRQCHIP helper library, create the TODO file with these work items. Cc: Johan Hovold Signed-off-by: Linus Walleij --- I started some work in this area, make sure to just throw me in on CC whenever anyone works on it and I will happily help and provide examples! --- drivers/staging/greybus/TODO | 5 + 1 file changed, 5 insertions(+) create mode 100644 drivers/staging/greybus/TODO diff --git a/drivers/staging/greybus/TODO b/drivers/staging/greybus/TODO new file mode 100644 index ..3b90a5711998 --- /dev/null +++ b/drivers/staging/greybus/TODO @@ -0,0 +1,5 @@ +* Convert all uses of the old GPIO API from to the + GPIO descriptor API in and look up GPIO + lines from device tree or ACPI. +* Convert the GPIO driver to use the GPIO irqchip library + GPIOLIB_IRQCHIP instead of reimplementing the same. -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/9] staging: gpio-mt7621: Include the right header
GPIO drivers should include only, the header is deprecated. Cc: John Crispin Cc: Zhiyong Tao Cc: Sean Wang Signed-off-by: Linus Walleij --- I was philosophizing whether pinctrl/mediatek/pinctrl-mt7622 is similar to this and can drive also the mt7621 but what do I know. Sean can you have a look at this staging driver and give some directions? --- drivers/staging/mt7621-gpio/gpio-mt7621.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c b/drivers/staging/mt7621-gpio/gpio-mt7621.c index 51235687ddb6..ca105b171a06 100644 --- a/drivers/staging/mt7621-gpio/gpio-mt7621.c +++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c @@ -9,7 +9,7 @@ #include #include -#include +#include #include #include #include -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 8/9] staging: olpc_dcon: Augment TODO file with GPIO work item
To make sure that this driver does not leave staging before it is properly converted to use the new GPIO descriptor API, augment the TODO file with this work item. Cc: Andres Salomon Cc: Jens Frederich Signed-off-by: Linus Walleij --- drivers/staging/olpc_dcon/TODO | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/olpc_dcon/TODO b/drivers/staging/olpc_dcon/TODO index 61c2e65ac354..665a0b061719 100644 --- a/drivers/staging/olpc_dcon/TODO +++ b/drivers/staging/olpc_dcon/TODO @@ -1,6 +1,10 @@ TODO: - see if vx855 gpio API can be made similar enough to cs5535 so we can share more code + - 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 - allow simultaneous XO-1 and XO-1.5 support Please send patches to Greg Kroah-Hartman and -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 9/9] staging: wilc1000: Augment TODO file with GPIO work item
To make sure that this driver does not leave staging before it is properly converted to use the new GPIO descriptor API, augment the TODO file with this work item. Cc: Johnny Kim Cc: Nicolas Ferre Signed-off-by: Linus Walleij --- drivers/staging/wilc1000/TODO | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/wilc1000/TODO b/drivers/staging/wilc1000/TODO index ae61b55f14fd..c441beba75bd 100644 --- a/drivers/staging/wilc1000/TODO +++ b/drivers/staging/wilc1000/TODO @@ -16,3 +16,7 @@ TODO: - support resume/suspend function - replace SIOCDEVPRIVATE commands with generic API functions - use wext-core handling instead of private SIOCSIWPRIV implementation +- 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 -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/9] staging: nvec: Augment TODO file with GPIO work item
To make sure that this driver does not leave staging before it is properly converted to use the new GPIO descriptor API, augment the TODO file with this work item. Cc: Marc Dietrich Signed-off-by: Linus Walleij --- drivers/staging/nvec/TODO | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/staging/nvec/TODO b/drivers/staging/nvec/TODO index e4d85d9b4681..78b84c243df4 100644 --- a/drivers/staging/nvec/TODO +++ b/drivers/staging/nvec/TODO @@ -4,3 +4,8 @@ ToDo list (incomplete, unordered) - move event handling to nvec_events - finish suspend/resume support - add support for more device implementations + - convert all uses of the old GPIO API from to the + GPIO descriptor API in and look up GPIO + line descriptor from device tree, ACPI or board files + - drop the dependency on altogether when migrating + to GPIO descriptors -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/9] staging: fbtft: Add TODO file with GPIO work item
To make sure that these drivers do not leave staging before they are properly converted to use the new GPIO descriptor API, create the TODO file with this work item. Cc: Thomas Petazzoni Cc: Noralf Tronnes Signed-off-by: Linus Walleij --- drivers/staging/fbtft/TODO | 4 1 file changed, 4 insertions(+) create mode 100644 drivers/staging/fbtft/TODO diff --git a/drivers/staging/fbtft/TODO b/drivers/staging/fbtft/TODO new file mode 100644 index ..7e64c7e438f0 --- /dev/null +++ b/drivers/staging/fbtft/TODO @@ -0,0 +1,4 @@ +* 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 -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/9] staging: emxx_udc: Add GPIO descriptor work to TODO
To make sure this driver does not leave staging without a proper conversion to the GPIO descriptor API, leave a note in the TODO. Cc: Magnus Damm Cc: Simon Horman Cc: Geert Uytterhoeven Signed-off-by: Linus Walleij --- drivers/staging/emxx_udc/TODO | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/emxx_udc/TODO b/drivers/staging/emxx_udc/TODO index 1319379beb7e..471529a470c7 100644 --- a/drivers/staging/emxx_udc/TODO +++ b/drivers/staging/emxx_udc/TODO @@ -1,4 +1,6 @@ * add clock framework support (platform device with CCF needs special care) * break out board-specific VBUS GPIO to work with multiplatform +* convert VBUS GPIO to use GPIO descriptors from + and stop using the old GPIO API * DT bindings * move driver into drivers/usb/gadget/ -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/9] staging: Anchor GPIO descriptors
Trying to be helpful for people who want to clean up the staging drivers: point out the drivers that need to be converted to use GPIO descriptors and a little bit on how to do it. Linus Walleij (9): staging: emxx_udc: Add GPIO descriptor work to TODO staging: fbtft: Add TODO file with GPIO work item staging: greybus: Add TODO file with GPIO work items staging: iio: Augment TODO file with GPIO work item staging: atomisp: Augment TODO file with GPIO work item staging: gpio-mt7621: Include the right header staging: nvec: Augment TODO file with GPIO work item staging: olpc_dcon: Augment TODO file with GPIO work item staging: wilc1000: Augment TODO file with GPIO work item drivers/staging/emxx_udc/TODO | 2 ++ drivers/staging/fbtft/TODO| 4 drivers/staging/greybus/TODO | 5 + drivers/staging/iio/TODO | 9 - drivers/staging/media/atomisp/TODO| 5 + drivers/staging/mt7621-gpio/gpio-mt7621.c | 2 +- drivers/staging/nvec/TODO | 5 + drivers/staging/olpc_dcon/TODO| 4 drivers/staging/wilc1000/TODO | 4 9 files changed, 38 insertions(+), 2 deletions(-) create mode 100644 drivers/staging/fbtft/TODO create mode 100644 drivers/staging/greybus/TODO -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/9] staging: atomisp: Augment TODO file with GPIO work item
To make sure that these drivers do not leave staging before they are properly converted to use the new GPIO descriptor API, augment the TODO file with this work item. Cc: Alan Cox Cc: Andy Shevchenko Signed-off-by: Linus Walleij --- I'm happy to help to move this forward, however Andy is the authority on x86 platform drivers and probably knows best how to deal with these GPIOs going forward. --- drivers/staging/media/atomisp/TODO | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/staging/media/atomisp/TODO b/drivers/staging/media/atomisp/TODO index 255ce3630c2a..683da0cfc313 100644 --- a/drivers/staging/media/atomisp/TODO +++ b/drivers/staging/media/atomisp/TODO @@ -50,6 +50,11 @@ 11. Switch from videobuf1 to videobuf2. Videobuf1 is being removed! +12. Convert all uses of the old GPIO API from to the +GPIO descriptor API in and look up GPIO +lines from device properties. See other platform drivers for +examples. + Limitations: 1. To test the patches, you also need the ISP firmware -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/9] staging: iio: Augment TODO file with GPIO work item
To make sure that these drivers do not leave staging before they are properly converted to use the new GPIO descriptor API, augment the TODO file with this work item. Cc: Jonathan Cameron Signed-off-by: Linus Walleij --- drivers/staging/iio/TODO | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/staging/iio/TODO b/drivers/staging/iio/TODO index 4922402e2e98..1b8ebf2c1b69 100644 --- a/drivers/staging/iio/TODO +++ b/drivers/staging/iio/TODO @@ -1,4 +1,11 @@ -2016 10/09 +2018-04-15 + +All affected drivers: +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 . + ADI Drivers: CC the device-drivers-de...@blackfin.uclinux.org mailing list when -- 2.14.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
On Sat, Oct 14, 2017 at 8:52 PM, Florian Fainelli wrote: > The most deployed switch device drivers have been converted to DSA > already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in > tree, and now we are getting new submissions from Michrochip to support > their pretty large KSZ series. Converting from swconfig to DSA is > actually quite simple, but like anything requires time and testing, and > access to hardware and ideally datasheet. Hm, I have a Realtek RB8366RB in this router on my desk. I guess that means I should just take the old switchdev-based SMI-driver and convert it to DSA. I bet I can do that :D Well, I will try. Because it's blocking me to work on the Gemini ethernet driver. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
Top posting and resending since net...@vger.kernel.org is the right mail address for this. Mea culpa. Linus Walleij On Sat, Oct 14, 2017 at 11:35 AM, Linus Walleij wrote: > On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu > wrote: > >> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs >> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages >> switch objects discovered on the fsl-mc bus. A description of the driver >> can be found in the associated README file. >> >> The patchset consists of: >> * A set of libraries containing APIs for configuring and controlling >> Management Complex (MC) switch objects >> * The DPAA2 Ethernet Switch driver >> * Patch adding ethtool support > > So it appears that ethernet switches is a class of device that need their own > subsystem in Linux, before this driver can move out of staging. > > I ran into the problem in OpenWRT that has these out-of-tree patches for > off-chip ethernet switches, conveniently placed under net/phy: > https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy > > These are some 12 different ethernet switches. It is used in more or > less every home router out there. > > It's not really working to have all of this out-of-tree, there must have been > discussions about the requirements for a proper ethernet switch subsystem. > > I'm not a good net developers, just a grumpy user having to deal with all > of this out-of-tree code that's not helpful with changing interfaces like > device tree and so on. > > Can you people who worked on this over the years pit in with your > requirements for an ethernet switch subsystem so we can house these > drivers in a proper way? > > What we need AFAICT: > > - Consensus on userspace ABI > - Consensus on ethtool extenstions > - Consensus on where in drivers/net this goes > > You can kick me for not knowing what I'm talking about and how complex the > problem is now. > > Yours, > Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu wrote: > This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs > with DPAA2 (DataPath Acceleration Architecture v2). The driver manages > switch objects discovered on the fsl-mc bus. A description of the driver > can be found in the associated README file. > > The patchset consists of: > * A set of libraries containing APIs for configuring and controlling > Management Complex (MC) switch objects > * The DPAA2 Ethernet Switch driver > * Patch adding ethtool support So it appears that ethernet switches is a class of device that need their own subsystem in Linux, before this driver can move out of staging. I ran into the problem in OpenWRT that has these out-of-tree patches for off-chip ethernet switches, conveniently placed under net/phy: https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy These are some 12 different ethernet switches. It is used in more or less every home router out there. It's not really working to have all of this out-of-tree, there must have been discussions about the requirements for a proper ethernet switch subsystem. I'm not a good net developers, just a grumpy user having to deal with all of this out-of-tree code that's not helpful with changing interfaces like device tree and so on. Can you people who worked on this over the years pit in with your requirements for an ethernet switch subsystem so we can house these drivers in a proper way? What we need AFAICT: - Consensus on userspace ABI - Consensus on ethtool extenstions - Consensus on where in drivers/net this goes You can kick me for not knowing what I'm talking about and how complex the problem is now. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/20] gpio: pca953x: Add optional reset gpio control
On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
>
> Signed-off-by: Steve Longerbeam
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: linux-g...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
This seems like a separate patch from the other 19 patches so please send it
separately so I can handle logistics easier in the future.
> @@ -133,6 +134,7 @@ struct pca953x_chip {
> const char *const *names;
> unsigned long driver_data;
> struct regulator *regulator;
> + struct gpio_desc *reset_gpio;
Why do you even keep this around in the device state container?
As you only use it in the probe() function, use a local variable.
The descriptor will be free():ed by the devm infrastructure anyways.
> + /* see if we need to de-assert a reset pin */
> + chip->reset_gpio = devm_gpiod_get_optional(&client->dev,
> + "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(chip->reset_gpio)) {
> + dev_err(&client->dev, "request for reset pin
> failed\n");
> + return PTR_ERR(chip->reset_gpio);
> + }
Nice.
> + if (chip->reset_gpio) {
> + /* bring chip out of reset */
> + dev_info(&client->dev, "releasing reset\n");
> + gpiod_set_value(chip->reset_gpio, 0);
> + }
Is this really needed given that you set it low in the
devm_gpiod_get_optional()?
Yours,
Linus Walleij
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/6] gpio: cbc-presence: Add CBC presence detect as GPIO driver
On Fri, Oct 7, 2016 at 5:20 PM, Pantelis Antoniou wrote: > From: Georgi Vlaev > > This driver exports the CB FPGA presence detect bits from a > single 32bit CB register as GPIOs. > > Signed-off-by: Georgi Vlaev > Signed-off-by: Guenter Roeck > [Ported from Juniper kernel] > Signed-off-by: Pantelis Antoniou This needs some more verbose commit message and explanation. Note: GPIO = General Purpose Input/Output. This doesn't really sound like general purpose, more like special purpose. Consider drivers/input and drivers/connector classes for example. > +config GPIO_CBC_PRESENCE > + tristate "Juniper Networks PTX1K CBC presence detect as GPIO" > + depends on MFD_JUNIPER_CBC && OF > + default y if JNX_CONNECTOR > + help > + This driver exports the CH_PRS and OTHER_CH_PRS presence detect > + bits of the PTX1K RCB CBC FPGA as GPIOs on the relevant Juniper > + platforms. Select if JNX_CONNECTOR is selected. > + > + This driver can also be built as a module. If so, the module > + will be called gpio-cbc-presence. At least tell us *what* it is detecting the presence of. Apart from this it has some of the same issues pointed out in the other drivers, correct these as well. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/6] gpio: gpio-cbc: Document bindings of CBC FPGA GPIO block
On Fri, Oct 7, 2016 at 5:20 PM, Pantelis Antoniou wrote: > From: Georgi Vlaev > > Add device tree bindings document for the GPIO driver of > Juniper's CBC FPGA. > > Signed-off-by: Georgi Vlaev > [Ported from Juniper kernel] > Signed-off-by: Pantelis Antoniou > --- > .../devicetree/bindings/gpio/jnx,gpio-cbc.txt | 30 > ++ > 1 file changed, 30 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/jnx,gpio-cbc.txt > > diff --git a/Documentation/devicetree/bindings/gpio/jnx,gpio-cbc.txt > b/Documentation/devicetree/bindings/gpio/jnx,gpio-cbc.txt > new file mode 100644 > index 000..d205d0b > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/jnx,gpio-cbc.txt > @@ -0,0 +1,30 @@ > +Juniper CBC FPGA GPIO block > + > +Required properties: > + > +- compatible: > +Must be "jnx,cbc-gpio" > + > +Optional properties: > + > +- reg: > +Address and length of the register set for the device. This is optional > since > +usually the parent MFD driver fills it in. > + > +- #gpio-cells: > +Should be <2>. The first cell is the pin number (within the controller's > +pin space), and the second is used for the following flags: > + bit[0]: direction (0 = out, 1 = in) > + bit[1]: init high > + bit[2]: active low Can't you just refer to the generic bindings? Apart from that it looks fine. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/6] gpio: Add support for PTX1K CBC FPGA spare GPIOs
On Fri, Oct 7, 2016 at 5:20 PM, Pantelis Antoniou wrote: > From: Georgi Vlaev > > Add support for the GPIO block in Juniper's CBC FPGA. > > A number of GPIOs exported by different kind of boards > is supported. > > Signed-off-by: Georgi Vlaev > Signed-off-by: Guenter Roeck > [Ported from Juniper kernel] > Signed-off-by: Pantelis Antoniou Again pretty much the same comments. The drivers not supporting IRQ will be pretty quick and easy to fix up I guess, the IRQ drivers will require some effort. An approach is to split these in two: one for the basic GPIO and a separate add-on patch for the IRQ functionality. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] RFC: staging: greybus: shape up greybus GPIO
Greybus GPIO seems to reimplement the already existing generic
gpiolib irqchip. Also use gpiochip_get_data(). Also use
devm_gpiochip_add_data().
Cc: Viresh Kumar
Cc: Axel Haslam
Cc: Johan Hovold
Cc: Sandeep Patil
Cc: Rui Miguel Silva
Cc: Greg Kroah-Hartman
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Add the hunk adding select GPIOLIB_IRQCHIP to Kconfig,
sorry for sending patches too late in the night.
Greybus folks: please look at this. I expect something like this
to be applied before migrating from staging, I can't test it
obviously.
---
drivers/staging/greybus/Kconfig | 1 +
drivers/staging/greybus/gpio.c | 183 +---
2 files changed, 24 insertions(+), 160 deletions(-)
diff --git a/drivers/staging/greybus/Kconfig b/drivers/staging/greybus/Kconfig
index 50de2d72dde0..b05a8f4657e3 100644
--- a/drivers/staging/greybus/Kconfig
+++ b/drivers/staging/greybus/Kconfig
@@ -148,6 +148,7 @@ if GREYBUS_BRIDGED_PHY
config GREYBUS_GPIO
tristate "Greybus GPIO Bridged PHY driver"
depends on GPIOLIB
+ select GPIOLIB_IRQCHIP
---help---
Select this option if you have a device that follows the
Greybus GPIO Bridged PHY Class specification.
diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 5e06e4229e42..07ccd819ee1c 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -41,14 +41,8 @@ struct gb_gpio_controller {
struct gpio_chipchip;
struct irq_chip irqc;
struct irq_chip *irqchip;
- struct irq_domain *irqdomain;
- unsigned intirq_base;
- irq_flow_handler_t irq_handler;
- unsigned intirq_default_type;
struct mutexirq_lock;
};
-#define gpio_chip_to_gb_gpio_controller(chip) \
- container_of(chip, struct gb_gpio_controller, chip)
#define irq_data_to_gpio_chip(d) (d->domain->host_data)
static int gb_gpio_line_count_operation(struct gb_gpio_controller *ggc)
@@ -277,7 +271,7 @@ static void _gb_gpio_irq_set_type(struct gb_gpio_controller
*ggc,
static void gb_gpio_irq_mask(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
line->masked = true;
@@ -287,7 +281,7 @@ static void gb_gpio_irq_mask(struct irq_data *d)
static void gb_gpio_irq_unmask(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
line->masked = false;
@@ -297,7 +291,7 @@ static void gb_gpio_irq_unmask(struct irq_data *d)
static int gb_gpio_irq_set_type(struct irq_data *d, unsigned int type)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
struct device *dev = &ggc->gbphy_dev->dev;
u8 irq_type;
@@ -335,7 +329,7 @@ static int gb_gpio_irq_set_type(struct irq_data *d,
unsigned int type)
static void gb_gpio_irq_bus_lock(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
mutex_lock(&ggc->irq_lock);
}
@@ -343,7 +337,7 @@ static void gb_gpio_irq_bus_lock(struct irq_data *d)
static void gb_gpio_irq_bus_sync_unlock(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
if (line->irq_type_pending) {
@@ -392,7 +386,7 @@ static int gb_gpio_request_handler(struct gb_operation *op)
return -EINVAL;
}
- irq = irq_find_mapping(ggc->irqdomain, event->which);
+ irq = irq_find_mapping(ggc->chip.irqdomain, event->which);
if (!irq) {
dev_err(dev, "failed to find IRQ\n");
return -EINVAL;
@@ -412,21 +406,21 @@ static int gb_gpio_request_handler(struct gb_operation
*op)
static int gb_gpio_request(struct gpio_chip *chip, unsigned offset)
{
-
[PATCH] RFC: staging: greybus: shape up greybus GPIO
Greybus GPIO seems to reimplement the already existing generic
gpiolib irqchip. Also use gpiochip_get_data(). Also use
devm_gpiochip_add_data().
Cc: Viresh Kumar
Cc: Axel Haslam
Cc: Johan Hovold
Cc: Sandeep Patil
Cc: Rui Miguel Silva
Cc: Greg Kroah-Hartman
Signed-off-by: Linus Walleij
---
Greybus folks: please look at this. I expect something like this
to be applied before migrating from staging, I can't test it
obviously.
---
drivers/staging/greybus/gpio.c | 183 ++---
1 file changed, 23 insertions(+), 160 deletions(-)
diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 5e06e4229e42..07ccd819ee1c 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -41,14 +41,8 @@ struct gb_gpio_controller {
struct gpio_chipchip;
struct irq_chip irqc;
struct irq_chip *irqchip;
- struct irq_domain *irqdomain;
- unsigned intirq_base;
- irq_flow_handler_t irq_handler;
- unsigned intirq_default_type;
struct mutexirq_lock;
};
-#define gpio_chip_to_gb_gpio_controller(chip) \
- container_of(chip, struct gb_gpio_controller, chip)
#define irq_data_to_gpio_chip(d) (d->domain->host_data)
static int gb_gpio_line_count_operation(struct gb_gpio_controller *ggc)
@@ -277,7 +271,7 @@ static void _gb_gpio_irq_set_type(struct gb_gpio_controller
*ggc,
static void gb_gpio_irq_mask(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
line->masked = true;
@@ -287,7 +281,7 @@ static void gb_gpio_irq_mask(struct irq_data *d)
static void gb_gpio_irq_unmask(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
line->masked = false;
@@ -297,7 +291,7 @@ static void gb_gpio_irq_unmask(struct irq_data *d)
static int gb_gpio_irq_set_type(struct irq_data *d, unsigned int type)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
struct device *dev = &ggc->gbphy_dev->dev;
u8 irq_type;
@@ -335,7 +329,7 @@ static int gb_gpio_irq_set_type(struct irq_data *d,
unsigned int type)
static void gb_gpio_irq_bus_lock(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
mutex_lock(&ggc->irq_lock);
}
@@ -343,7 +337,7 @@ static void gb_gpio_irq_bus_lock(struct irq_data *d)
static void gb_gpio_irq_bus_sync_unlock(struct irq_data *d)
{
struct gpio_chip *chip = irq_data_to_gpio_chip(d);
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
struct gb_gpio_line *line = &ggc->lines[d->hwirq];
if (line->irq_type_pending) {
@@ -392,7 +386,7 @@ static int gb_gpio_request_handler(struct gb_operation *op)
return -EINVAL;
}
- irq = irq_find_mapping(ggc->irqdomain, event->which);
+ irq = irq_find_mapping(ggc->chip.irqdomain, event->which);
if (!irq) {
dev_err(dev, "failed to find IRQ\n");
return -EINVAL;
@@ -412,21 +406,21 @@ static int gb_gpio_request_handler(struct gb_operation
*op)
static int gb_gpio_request(struct gpio_chip *chip, unsigned offset)
{
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
return gb_gpio_activate_operation(ggc, (u8)offset);
}
static void gb_gpio_free(struct gpio_chip *chip, unsigned offset)
{
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_data(chip);
gb_gpio_deactivate_operation(ggc, (u8)offset);
}
static int gb_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
{
- struct gb_gpio_controller *ggc = gpio_chip_to_gb_gpio_controller(chip);
+ struct gb_gpio_controller *ggc = gpiochip_get_da
Re: [PATCH 172/182] staging: vme: use gpiochip data pointer
On Fri, Dec 11, 2015 at 7:58 AM, Martyn Welch wrote: > On 09/12/15 13:50, Linus Walleij wrote: >> >> This makes the driver use the data pointer added to the gpio_chip >> to store a pointer to the state container instead of relying on >> container_of(). >> >> Cc: Greg Kroah-Hartman >> Cc: Martyn Welch >> Cc: Manohar Vanga >> Cc: de...@driverdev.osuosl.org >> Signed-off-by: Linus Walleij > > > Signed-of-by: Martyn Welch Signed-off is for the delivery path so I assume you meant Acked-by and I added that. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 172/182] staging: vme: use gpiochip data pointer
This makes the driver use the data pointer added to the gpio_chip
to store a pointer to the state container instead of relying on
container_of().
Cc: Greg Kroah-Hartman
Cc: Martyn Welch
Cc: Manohar Vanga
Cc: de...@driverdev.osuosl.org
Signed-off-by: Linus Walleij
---
Greg, please ACK this so I can take this through the GPIO tree.
---
drivers/staging/vme/devices/vme_pio2_gpio.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vme/devices/vme_pio2_gpio.c
b/drivers/staging/vme/devices/vme_pio2_gpio.c
index 77901b345a71..a2b740ab7ffe 100644
--- a/drivers/staging/vme/devices/vme_pio2_gpio.c
+++ b/drivers/staging/vme/devices/vme_pio2_gpio.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -25,16 +25,11 @@
static const char driver_name[] = "pio2_gpio";
-static struct pio2_card *gpio_to_pio2_card(struct gpio_chip *chip)
-{
- return container_of(chip, struct pio2_card, gc);
-}
-
static int pio2_gpio_get(struct gpio_chip *chip, unsigned int offset)
{
u8 reg;
int retval;
- struct pio2_card *card = gpio_to_pio2_card(chip);
+ struct pio2_card *card = gpiochip_get_data(chip);
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == OUTPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -72,7 +67,7 @@ static void pio2_gpio_set(struct gpio_chip *chip, unsigned
int offset,
{
u8 reg;
int retval;
- struct pio2_card *card = gpio_to_pio2_card(chip);
+ struct pio2_card *card = gpiochip_get_data(chip);
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == INPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -102,7 +97,7 @@ static void pio2_gpio_set(struct gpio_chip *chip, unsigned
int offset,
static int pio2_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
{
int data;
- struct pio2_card *card = gpio_to_pio2_card(chip);
+ struct pio2_card *card = gpiochip_get_data(chip);
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == OUTPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -121,7 +116,7 @@ static int pio2_gpio_dir_in(struct gpio_chip *chip,
unsigned offset)
static int pio2_gpio_dir_out(struct gpio_chip *chip, unsigned offset, int
value)
{
int data;
- struct pio2_card *card = gpio_to_pio2_card(chip);
+ struct pio2_card *card = gpiochip_get_data(chip);
if ((card->bank[PIO2_CHANNEL_BANK[offset]].config == INPUT) |
(card->bank[PIO2_CHANNEL_BANK[offset]].config == NOFIT)) {
@@ -207,7 +202,7 @@ int pio2_gpio_init(struct pio2_card *card)
card->gc.set = pio2_gpio_set;
/* This function adds a memory mapped GPIO chip */
- retval = gpiochip_add(&(card->gc));
+ retval = gpiochip_add_data(&(card->gc), card);
if (retval) {
dev_err(&card->vdev->dev, "Unable to register GPIO\n");
kfree(card->gc.label);
--
2.4.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ste_rmi4: avoid unused function warnings
On Fri, Nov 20, 2015 at 10:59 PM, Arnd Bergmann wrote: > The rmi4 touchscreen driver encloses the power-management > functions in #ifdef CONFIG_PM, but the smtcfb_pci_suspend/resume > functions are only really used when CONFIG_PM_SLEEP is also > set, as a frequent gcc warning shows: > > ste_rmi4/synaptics_i2c_rmi4.c:1050:12: warning: 'synaptics_rmi4_suspend' > defined but not used > ste_rmi4/synaptics_i2c_rmi4.c:1084:12: warning: 'synaptics_rmi4_resume' > defined but not used > > This changes the driver to remove the #ifdef and instead mark > the functions as __maybe_unused, which is a nicer anyway, as it > provides build testing for all the code in all configurations > and is harder to get wrong. > > Signed-off-by: Arnd Bergmann Acked-by: Linus Walleij Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Status of RMI4 drivers?
On Tue, Jul 8, 2014 at 12:12 PM, Kristina Martšenko wrote: > On 06/07/14 21:12, Dmitry Torokhov wrote: >> I was supposed to uprev the driver to the latest kernel and start >> merging it, unfortunately last month and a half was quite a mess. >> Hopefully now I should have more time since I can do bunch of this >> work during normal hours. > > Good to know, thanks. So what happens to the staging drivers once you > merge the driver? Will their devices be supported by the new driver or > will someone have to merge their functionality into the new driver (and > test it)? I can do that once the touchscreen portions are in place. I'm just not quite familiar with the structure of the new RMI4 framework so I will need some time on it. Yours, Linus Walleij ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
