| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch changes the compatibility string to match with the smallest
supported chip (EP7209). Since the DT-support for this CPU is not yet
announced, this change is safe.
Signed-off-by: Alexander Shiyan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.
Signed-off-by: Laxman Dewangan <[email protected]>
|
|
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: Alexander Shiyan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Linux 4.4-rc6
|
|
The name .dev in a struct is normally reserved for a struct device
that is let us say a superclass to the thing described by the struct.
struct gpio_chip stands out by confusingly using a struct device *dev
to point to the parent device (such as a platform_device) that
represents the hardware. As we want to give gpio_chip:s real devices,
this is not working. We need to rename this member to parent.
This was done by two coccinelle scripts, I guess it is possible to
combine them into one, but I don't know such stuff. They look like
this:
@@
struct gpio_chip *var;
@@
-var->dev
+var->parent
and:
@@
struct gpio_chip var;
@@
-var.dev
+var.parent
and:
@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parent
Plus a few instances of bgpio that I couldn't figure out how
to teach Coccinelle to rewrite.
This patch hits all over the place, but I *strongly* prefer this
solution to any piecemal approaches that just exercise patch
mechanics all over the place. It mainly hits drivers/gpio and
drivers/pinctrl which is my own backyard anyway.
Cc: Haavard Skinnemoen <[email protected]>
Cc: Rafał Miłecki <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Alek Du <[email protected]>
Cc: Jaroslav Kysela <[email protected]>
Cc: Takashi Iwai <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Lee Jones <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Acked-by: Hans-Christian Egtvedt <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
of_match_device could return NULL, and so cause a NULL pointer
dereference later at line 199:
priv->flags = of_id->data;
Reported-by: coverity (CID 1324140)
Signed-off-by: LABBE Corentin <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Now GPIO syscon driver produces bunch of warnings during the
boot of Kesytone 2 SoCs:
gpio-syscon soc:keystone_dsp_gpio@02620240: can't read the dir register offset!
gpio-syscon soc:keystone_dsp_gpio@2620244: can't read the dir register offset!
This message unintentionally was added using dev_err(), but its
actual log level is debug, because third cell of "ti,syscon-dev" is
optional.
Hence change it to dev_dbg() as it should be.
This patch fixes commit:
5a3e3f8 ("gpio: syscon: retriave syscon node and regs offsets from dt")
Reported-by: Russell King <[email protected]>
Tested-by: Murali Karicheri <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Wolfram Sang <[email protected]>
|
|
On Keystone SOCs, ARM host can send interrupts to DSP cores using the
DSP GPIO controller IP. Each DSP GPIO controller provides 28 IRQ signals for
each DSP core. This is one of the component used by the IPC mechanism used
on Keystone SOCs.
Keystone 2 DSP GPIO controller has specific features:
- each GPIO can be configured only as output pin;
- setting GPIO value to 1 causes IRQ generation on target DSP core;
- reading pin value returns 0 - if IRQ was handled or 1 - IRQ is still
pending.
This patch updates gpio-syscon driver to be reused by Keystone 2 SoCs,
because the Keystone 2 DSP GPIO controller is controlled through Syscon
devices and, as requested by Linus Walleij, such kind of GPIO controllers
should be integrated with drivers/gpio/gpio-syscon.c driver.
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
This patch adds handling of new "gpio,syscon-dev" DT property,
which allows to specify syscon node and data/direction registers
offsets in DT.
"gpio,syscon-dev" has following format:
gpio,syscon-dev = <&syscon_dev data_reg_offset [direction_reg_offset]>;
where
- syscon_dev - phandle on syscon node
- data_reg_offset - offset of data register (in bytes)
- direction_reg_offset - offset of dirrection register (optional, in bytes)
for example:
gpio,syscon-dev = <&devctrl 0x254>;
In such way, the support of multiple Syscon GPIO devices is added.
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Some SoCs (like Keystone) may require to perform special
sequence of operations to assign output GPIO value, so default
implementation of .set() callback from gpio-syscon driver
can't be used.
Hence, add optional, SoC specific callback to assign output
gpio value.
Signed-off-by: Grygorii Strashko <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
Signed-off-by: abdoulaye berthe <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|
|
SYSCON driver was designed for using memory areas (registers)
that are used in several subsystems. There are systems (CPUs)
which use bits in one register for various purposes and thus
should be handled by various kernel subsystems. This driver
allows you to use the individual SYSCON bits as GPIOs.
ARM CLPS711X SYSFLG1 input lines has been added as first user
of this driver.
Signed-off-by: Alexander Shiyan <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
|