Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 9月, 2018 1 次提交
    • U
      gpiolib: Don't support irq sharing for userspace · fa38869b
      由 Uwe Kleine-König 提交于 
      This concerns gpio edge detection for GPIO IRQs used from
userspace for GPIO event listeners.

Trying to work out the right event if it's not sure that the
examined gpio actually moved is impossible.

Consider two gpios "gpioA" and "gpioB" that share an interrupt.
gpioA's irq should trigger on any edge, gpioB's on a falling edge.
If now the common irq fires and both gpio lines are high, there
are several possibilities that could have happend:

 a) gpioA just had a low-to-high edge
 b) gpioB just had a high-to-low-to-high spike
 c) a combination of both a) and b)

While c) is unlikely (in most setups) a) and b) alone are bad
enough. Currently the code assumes case a) unconditionally and
doesn't report an event for gpioB. Note that even if there is no
irq sharing involved a spike for a gpio might not result in an
event if it's configured to trigger for a single edge only.

The only way to improve this is to drop support for interrupt
sharing. This way a spike results in an event for the right gpio
at least. Note that apart from dropping IRQF_SHARED this
effectively undoes commit df1e76f2
("gpiolib: skip unwanted events, don't convert them to opposite edge").

This obviously breaks setups that rely on interrupt sharing,
but given that this cannot be reliable, this is probably an
acceptable trade-off.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
[Assuming there are no users of interrupt sharing yet]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      fa38869b
  3. 10 9月, 2018 4 次提交
    • H
      gpiolib: override irq_enable/disable · 461c1a7d
      由 Hans Verkuil 提交于 
      When using the gpiolib irqchip helpers install irq_enable/disable
hooks for the irqchip to ensure that gpiolib knows when the irq
is enabled or disabled, allowing drivers to disable the irq and then
use it as an output pin, and later switch the direction to input and
re-enable the irq.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      461c1a7d
    • H
      gpiolib: add flag to indicate if the irq is disabled · 4e9439dd
      由 Hans Verkuil 提交于 
      GPIO drivers call gpiochip_(un)lock_as_irq whenever they want to use a gpio
as an interrupt. This is done when the irq is requested and it marks the
gpio as in use by an interrupt.

This is problematic for cases where a gpio pin is used as an interrupt
pin, then, after the irq is disabled, is used as a regular gpio pin.
Currently it is not possible to do this other than by first freeing
the interrupt so gpiochip_unlock_as_irq is called, since an attempt to
switch the gpio direction for output will fail since gpiolib believes
that the gpio is in use for an interrupt and it does not know that it
the irq is actually disabled.

There are currently two drivers that would like to be able to do this:
the tda998x_drv.c driver where a regular gpio pin needs to be temporarily
reconfigured as an interrupt pin during CEC calibration, and the cec-gpio
driver where you want to configure the gpio pin as an interrupt while
waiting for traffic over the CEC bus, or as a regular pin when receiving or
transmitting a CEC message.

The solution is to add a new flag that is set when the irq is enabled,
and have gpiod_direction_output check for that flag.

We also add functions that drivers that do not use GPIOLIB_IRQCHIP
can call when they enable/disable the irq.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      4e9439dd
    • H
      gliolib: set hooks in gpiochip_set_irq_hooks() · ca620f2d
      由 Hans Verkuil 提交于 
      Centralize setting the irq_request/release_resources callbacks
in one function since we'll be adding more callbacks to that.

Also fix the removal of the callback overrides: this should
only be done if we actually installed our own callback there.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      ca620f2d
    • H
      gpiolib: export gpiochip_irq_reqres/relres() · 4e6b8238
      由 Hans Verkuil 提交于 
      GPIO drivers that do not use GPIOLIB_IRQCHIP can hook these into
the irq_request_resource and irq_release_resource callbacks of the
irq_chip so they correctly 'get' the module and lock the gpio line
for IRQ use.

This will simplify driver code.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      4e6b8238
  5. 11 8月, 2018 2 次提交
  7. 07 8月, 2018 1 次提交
  9. 30 7月, 2018 1 次提交
  11. 16 7月, 2018 2 次提交
  13. 13 7月, 2018 2 次提交
  15. 09 7月, 2018 3 次提交
  17. 18 6月, 2018 1 次提交
    • L
      gpio: Add API to explicitly name a consumer · 90b39402
      由 Linus Walleij 提交于 
      The GPIO (descriptor) API registers a "label" naming what is
currently using the GPIO line. Typically this is taken from
things like the device tree node, so "reset-gpios" will result
in he line being labeled "reset".

The technical effect is pretty much zero: the use is for
debug and introspection, such as "lsgpio" and debugfs files.

However sometimes the user want this cuddly feeling of
listing all GPIO lines and seeing exactly what they are for
and it gives a very fulfilling sense of control. Especially
in the cases when the device tree node doesn't provide a
good name, or anonymous GPIO lines assigned just to
"gpios" in the device tree because the usage is implicit.

For these cases it may be nice to be able to label the
line directly and explicitly.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      90b39402
  19. 07 6月, 2018 1 次提交
    • K
      treewide: Use struct_size() for kmalloc()-family · acafe7e3
      由 Kees Cook 提交于 
      One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
    int stuff;
    void *entry[];
};

instance = kmalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kmalloc(struct_size(instance, entry, count), GFP_KERNEL);

This patch makes the changes for kmalloc()-family (and kvmalloc()-family)
uses. It was done via automatic conversion with manual review for the
"CHECKME" non-standard cases noted below, using the following Coccinelle
script:

// pkey_cache = kmalloc(sizeof *pkey_cache + tprops->pkey_tbl_len *
//                      sizeof *pkey_cache->table, GFP_KERNEL);
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
identifier VAR, ELEMENT;
expression COUNT;
@@

- alloc(sizeof(*VAR) + COUNT * sizeof(*VAR->ELEMENT), GFP)
+ alloc(struct_size(VAR, ELEMENT, COUNT), GFP)

// mr = kzalloc(sizeof(*mr) + m * sizeof(mr->map[0]), GFP_KERNEL);
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
identifier VAR, ELEMENT;
expression COUNT;
@@

- alloc(sizeof(*VAR) + COUNT * sizeof(VAR->ELEMENT[0]), GFP)
+ alloc(struct_size(VAR, ELEMENT, COUNT), GFP)

// Same pattern, but can't trivially locate the trailing element name,
// or variable name.
@@
identifier alloc =~ "kmalloc|kzalloc|kvmalloc|kvzalloc";
expression GFP;
expression SOMETHING, COUNT, ELEMENT;
@@

- alloc(sizeof(SOMETHING) + COUNT * sizeof(ELEMENT), GFP)
+ alloc(CHECKME_struct_size(&SOMETHING, ELEMENT, COUNT), GFP)
Signed-off-by: NKees Cook <keescook@chromium.org>
      acafe7e3
  21. 24 5月, 2018 1 次提交
  23. 23 5月, 2018 1 次提交
  25. 16 5月, 2018 2 次提交
  27. 27 4月, 2018 1 次提交
  29. 26 4月, 2018 1 次提交
  31. 27 3月, 2018 3 次提交
  33. 02 3月, 2018 1 次提交
  35. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      由 Linus Torvalds 提交于 
      This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  37. 23 1月, 2018 2 次提交
  39. 17 1月, 2018 2 次提交
  41. 12 1月, 2018 2 次提交
    • L
      gpio: Export devm_gpiod_get_from_of_node() for consumers · 92542edc
      由 Linus Walleij 提交于 
      We have been holding back on adding an API for fetching GPIO handles
directly from device nodes, strongly preferring to get it from the
spawn devices instead.

The fwnode interface however already contains an API for doing this,
as it is used for opaque device tree nodes or ACPI nodes for getting
handles to LEDs and keys that use GPIO: those are specified as one
child per LED/key in the device tree and are not individual devices.

However regulators present a special problem as they already have
helper functions to traverse the device tree from a regulator node
and two levels down to fill in data, and as it already traverses
GPIO nodes in its own way, and already holds a pointer to each
regulators device tree node, it makes most sense to export an
API to fetch the GPIO descriptor directly from the node.

We only support the devm_* version for now, hopefully no non-devres
version will be needed.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      92542edc
    • L
      gpio: Break out code to get a descriptor from a DT node · 6392cca4
      由 Linus Walleij 提交于 
      Sometimes a GPIO needs to be taken from a node without
a device associated with it. The fwnode accessor does this,
let's however break out the DT code for now.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      6392cca4
  43. 10 1月, 2018 2 次提交
  45. 09 1月, 2018 1 次提交
  47. 05 1月, 2018 1 次提交
    • L
      gpio: label descriptors using the device name · 24e78079
      由 Linus Walleij 提交于 
      Some GPIO lines appear named "?" in the lsgpio dump due to their
requesting drivers not passing a reasonable label.

Most typically this happens if a device tree node just defines
gpios = <...> and not foo-gpios = <...>, the former gets named
"foo" and the latter gets named "?".

However the struct device passed in is always valid so let's
just label the GPIO with dev_name() on the device if no proper
label was passed.

Cc: Reported-by: Jason Kridner <jkridner@beagleboard.org>
Reported-by: NJason Kridner <jkridner@beagleboard.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      24e78079
  49. 02 1月, 2018 1 次提交