08 Jun, 2016
1 commit
-
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
Signed-off-by: Linus Walleij
23 Feb, 2016
1 commit
-
Use devm_gpiochip_add_data() for GPIO registration and remove the
need of driver callback .remove.Signed-off-by: Laxman Dewangan
05 Jan, 2016
1 commit
-
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
Signed-off-by: Linus Walleij
21 Dec, 2015
1 commit
-
Linux 4.4-rc6
19 Nov, 2015
1 commit
-
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->parentand:
@@
struct gpio_chip var;
@@
-var.dev
+var.parentand:
@@
struct bgpio_chip *var;
@@
-var->gc.dev
+var->gc.parentPlus 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
Cc: Rafał Miłecki
Cc: Richard Purdie
Cc: Mauro Carvalho Chehab
Cc: Alek Du
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Acked-by: Dmitry Torokhov
Acked-by: Greg Kroah-Hartman
Acked-by: Lee Jones
Acked-by: Jiri Kosina
Acked-by: Hans-Christian Egtvedt
Acked-by: Jacek Anaszewski
Signed-off-by: Linus Walleij
17 Nov, 2015
1 commit
-
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
Signed-off-by: Linus Walleij
27 Mar, 2015
1 commit
-
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
Tested-by: Murali Karicheri
Acked-by: Santosh Shilimkar
Signed-off-by: Grygorii Strashko
Signed-off-by: Linus Walleij
20 Oct, 2014
1 commit
-
A platform_driver does not need to set an owner, it will be populated by the
driver core.Signed-off-by: Wolfram Sang
17 Sep, 2014
3 commits
-
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
Signed-off-by: Linus Walleij -
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 = ;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 = ;In such way, the support of multiple Syscon GPIO devices is added.
Signed-off-by: Grygorii Strashko
Signed-off-by: Linus Walleij -
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
Signed-off-by: Linus Walleij
22 Jul, 2014
1 commit
-
Signed-off-by: abdoulaye berthe
Signed-off-by: Linus Walleij
18 Mar, 2014
1 commit
-
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
Signed-off-by: Linus Walleij