<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux/gpio, branch v4.18.17</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.18.17</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.18.17'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-11-04T13:51:50+00:00</updated>
<entry>
<title>gpio: Assign gpio_irq_chip::parents to non-stack pointer</title>
<updated>2018-11-04T13:51:50+00:00</updated>
<author>
<name>Stephen Boyd</name>
<email>swboyd@chromium.org</email>
</author>
<published>2018-10-08T16:32:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e14b8b11ac50531ee0b670fa1f9fe762b7dd70e1'/>
<id>urn:sha1:e14b8b11ac50531ee0b670fa1f9fe762b7dd70e1</id>
<content type='text'>
[ Upstream commit 3e779a2e7f909015f21428b66834127496110b6d ]

gpiochip_set_cascaded_irqchip() is passed 'parent_irq' as an argument
and then the address of that argument is assigned to the gpio chips
gpio_irq_chip 'parents' pointer shortly thereafter. This can't ever
work, because we've just assigned some stack address to a pointer that
we plan to dereference later in gpiochip_irq_map(). I ran into this
issue with the KASAN report below when gpiochip_irq_map() tried to setup
the parent irq with a total junk pointer for the 'parents' array.

BUG: KASAN: stack-out-of-bounds in gpiochip_irq_map+0x228/0x248
Read of size 4 at addr ffffffc0dde472e0 by task swapper/0/1

CPU: 7 PID: 1 Comm: swapper/0 Not tainted 4.14.72 #34
Call trace:
[&lt;ffffff9008093638&gt;] dump_backtrace+0x0/0x718
[&lt;ffffff9008093da4&gt;] show_stack+0x20/0x2c
[&lt;ffffff90096b9224&gt;] __dump_stack+0x20/0x28
[&lt;ffffff90096b91c8&gt;] dump_stack+0x80/0xbc
[&lt;ffffff900845a350&gt;] print_address_description+0x70/0x238
[&lt;ffffff900845a8e4&gt;] kasan_report+0x1cc/0x260
[&lt;ffffff900845aa14&gt;] __asan_report_load4_noabort+0x2c/0x38
[&lt;ffffff900897e098&gt;] gpiochip_irq_map+0x228/0x248
[&lt;ffffff900820cc08&gt;] irq_domain_associate+0x114/0x2ec
[&lt;ffffff900820d13c&gt;] irq_create_mapping+0x120/0x234
[&lt;ffffff900820da78&gt;] irq_create_fwspec_mapping+0x4c8/0x88c
[&lt;ffffff900820e2d8&gt;] irq_create_of_mapping+0x180/0x210
[&lt;ffffff900917114c&gt;] of_irq_get+0x138/0x198
[&lt;ffffff9008dc70ac&gt;] spi_drv_probe+0x94/0x178
[&lt;ffffff9008ca5168&gt;] driver_probe_device+0x51c/0x824
[&lt;ffffff9008ca6538&gt;] __device_attach_driver+0x148/0x20c
[&lt;ffffff9008ca14cc&gt;] bus_for_each_drv+0x120/0x188
[&lt;ffffff9008ca570c&gt;] __device_attach+0x19c/0x2dc
[&lt;ffffff9008ca586c&gt;] device_initial_probe+0x20/0x2c
[&lt;ffffff9008ca18bc&gt;] bus_probe_device+0x80/0x154
[&lt;ffffff9008c9b9b4&gt;] device_add+0x9b8/0xbdc
[&lt;ffffff9008dc7640&gt;] spi_add_device+0x1b8/0x380
[&lt;ffffff9008dcbaf0&gt;] spi_register_controller+0x111c/0x1378
[&lt;ffffff9008dd6b10&gt;] spi_geni_probe+0x4dc/0x6f8
[&lt;ffffff9008cab058&gt;] platform_drv_probe+0xdc/0x130
[&lt;ffffff9008ca5168&gt;] driver_probe_device+0x51c/0x824
[&lt;ffffff9008ca59cc&gt;] __driver_attach+0x100/0x194
[&lt;ffffff9008ca0ea8&gt;] bus_for_each_dev+0x104/0x16c
[&lt;ffffff9008ca58c0&gt;] driver_attach+0x48/0x54
[&lt;ffffff9008ca1edc&gt;] bus_add_driver+0x274/0x498
[&lt;ffffff9008ca8448&gt;] driver_register+0x1ac/0x230
[&lt;ffffff9008caaf6c&gt;] __platform_driver_register+0xcc/0xdc
[&lt;ffffff9009c4b33c&gt;] spi_geni_driver_init+0x1c/0x24
[&lt;ffffff9008084cb8&gt;] do_one_initcall+0x240/0x3dc
[&lt;ffffff9009c017d0&gt;] kernel_init_freeable+0x378/0x468
[&lt;ffffff90096e8240&gt;] kernel_init+0x14/0x110
[&lt;ffffff9008086fcc&gt;] ret_from_fork+0x10/0x18

The buggy address belongs to the page:
page:ffffffbf037791c0 count:0 mapcount:0 mapping:          (null) index:0x0
flags: 0x4000000000000000()
raw: 4000000000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: ffffffbf037791e0 ffffffbf037791e0 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffffffc0dde47180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc0dde47200: f1 f1 f1 f1 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2
&gt;ffffffc0dde47280: f2 f2 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3
                                                       ^
 ffffffc0dde47300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffc0dde47380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Let's leave around one unsigned int in the gpio_irq_chip struct for the
single parent irq case and repoint the 'parents' array at it. This way
code is left mostly intact to setup parents and we waste an extra few
bytes per structure of which there should be only a handful in a system.

Cc: Evan Green &lt;evgreen@chromium.org&gt;
Cc: Thierry Reding &lt;treding@nvidia.com&gt;
Cc: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration")
Signed-off-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: Remove VLA from gpiolib</title>
<updated>2018-05-23T12:01:03+00:00</updated>
<author>
<name>Laura Abbott</name>
<email>labbott@redhat.com</email>
</author>
<published>2018-05-21T17:57:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3027743f83f867d85662f5134e835c2e199cb9be'/>
<id>urn:sha1:3027743f83f867d85662f5134e835c2e199cb9be</id>
<content type='text'>
The new challenge is to remove VLAs from the kernel
(see https://lkml.org/lkml/2018/3/7/621) to eventually
turn on -Wvla.

Using a kmalloc array is the easy way to fix this but kmalloc is still
more expensive than stack allocation. Introduce a fast path with a
fixed size stack array to cover most chip with gpios below some fixed
amount. The slow path dynamically allocates an array to cover those
chips with a large number of gpios.

Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Phil Reid &lt;preid@electromag.com.au&gt;
Reviewed-and-tested-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Laura Abbott &lt;labbott@redhat.com&gt;
Reviewed-by: Andy Shevchenko &lt;andy.shevchenko@gmail.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: add hogs support for machine code</title>
<updated>2018-05-16T12:35:24+00:00</updated>
<author>
<name>Bartosz Golaszewski</name>
<email>brgl@bgdev.pl</email>
</author>
<published>2018-04-10T20:30:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a411e81e61df24023f40255145d8f023402002c9'/>
<id>urn:sha1:a411e81e61df24023f40255145d8f023402002c9</id>
<content type='text'>
Board files constitute a significant part of the users of the legacy
GPIO framework. In many cases they only export a line and set its
desired value. We could use GPIO hogs for that like we do for DT and
ACPI but there's no support for that in machine code.

This patch proposes to extend the machine.h API with support for
registering hog tables in board files.

Signed-off-by: Bartosz Golaszewski &lt;brgl@bgdev.pl&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: Support 'gpio-reserved-ranges' property</title>
<updated>2018-03-27T13:34:20+00:00</updated>
<author>
<name>Stephen Boyd</name>
<email>sboyd@codeaurora.org</email>
</author>
<published>2018-03-23T16:34:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=726cb3ba49692bdae6caff457755e7cdb432efa4'/>
<id>urn:sha1:726cb3ba49692bdae6caff457755e7cdb432efa4</id>
<content type='text'>
Some qcom platforms make some GPIOs or pins unavailable for use by
non-secure operating systems, and thus reading or writing the registers
for those pins will cause access control issues. Add support for a DT
property to describe the set of GPIOs that are available for use so that
higher level OSes are able to know what pins to avoid reading/writing.
Non-DT platforms can add support by directly updating the
chip-&gt;valid_mask.

Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Signed-off-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Tested-by: Timur Tabi &lt;timur@codeaurora.org&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'gpio-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio</title>
<updated>2018-01-31T20:25:27+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-01-31T20:25:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9798f5178f5791f964562eccedcf4dabe02fd825'/>
<id>urn:sha1:9798f5178f5791f964562eccedcf4dabe02fd825</id>
<content type='text'>
Pull GPIO updates from Linus Walleij:
 "The is the bulk of GPIO changes for the v4.16 kernel cycle. It is
  pretty calm this time around I think. I even got time to get to things
  like starting to clean up header includes.

  Core changes:

   - Disallow open drain and open source flags to be set simultaneously.
     This doesn't make electrical sense, and would the hardware actually
     respond to this setting, the result would be short circuit.

   - ACPI GPIO has a new core infrastructure for handling quirks. The
     quirks are there to deal with broken ACPI tables centrally instead
     of pushing the work to individual drivers. In the world of BIOS
     writers, the ACPI tables are perfect. Until they find a mistake in
     it. When such a mistake is found, we can patch it with a quirk. It
     should never happen, the problem is that it happens. So we
     accomodate for it.

   - Several documentation updates.

   - Revert the patch setting up initial direction state from reading
     the device. This was causing bad things for drivers that can't read
     status on all its pins. It is only affecting debugfs information
     quality.

   - Label descriptors with the device name if no explicit label is
     passed in.

   - Pave the ground for transitioning SPI and regulators to use GPIO
     descriptors by implementing some quirks in the device tree GPIO
     parsing code.

  New drivers:

   - New driver for the Access PCIe IDIO 24 family.

  Other:

   - Major refactorings and improvements to the GPIO mockup driver used
     for test and verification.

   - Moved the AXP209 driver over to pin control since it gained a pin
     control back-end. These patches will appear (with the same hashes)
     in the pin control pull request as well.

   - Convert the onewire GPIO driver w1-gpio to use descriptors. This is
     merged here since the W1 maintainers send very few pull requests
     and he ACKed it.

   - Start to clean up driver headers using &lt;linux/gpio.h&gt; to just use
     &lt;linux/gpio/driver.h&gt; as appropriate"

* tag 'gpio-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (103 commits)
  gpio: Timestamp events in hardirq handler
  gpio: Fix kernel stack leak to userspace
  gpio: Fix a documentation spelling mistake
  gpio: Documentation update
  gpiolib: remove redundant initialization of pointer desc
  gpio: of: Fix NPE from OF flags
  gpio: stmpe: Delete an unnecessary variable initialisation in stmpe_gpio_probe()
  gpio: stmpe: Move an assignment in stmpe_gpio_probe()
  gpio: stmpe: Improve a size determination in stmpe_gpio_probe()
  gpio: stmpe: Use seq_putc() in stmpe_dbg_show()
  gpio: No NULL owner
  gpio: stmpe: i2c transfer are forbiden in atomic context
  gpio: davinci: Include proper header
  gpio: da905x: Include proper header
  gpio: cs5535: Include proper header
  gpio: crystalcove: Include proper header
  gpio: bt8xx: Include proper header
  gpio: bcm-kona: Include proper header
  gpio: arizona: Include proper header
  gpio: amd8111: Include proper header
  ...
</content>
</entry>
<entry>
<title>gpio: Export devm_gpiod_get_from_of_node() for consumers</title>
<updated>2018-01-12T10:05:24+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2017-12-29T21:52:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=92542edc42496ac4b8f5ba0ae81ab5776db9473b'/>
<id>urn:sha1:92542edc42496ac4b8f5ba0ae81ab5776db9473b</id>
<content type='text'>
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: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>gpiolib: Export gpiochip_irqchip_irq_valid() to drivers</title>
<updated>2018-01-10T13:21:25+00:00</updated>
<author>
<name>Stephen Boyd</name>
<email>sboyd@codeaurora.org</email>
</author>
<published>2018-01-10T01:58:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=64ff2c8e468ceff3cd678a4fa2edfc77dadc6bfe'/>
<id>urn:sha1:64ff2c8e468ceff3cd678a4fa2edfc77dadc6bfe</id>
<content type='text'>
Some pinctrl drivers can use the gpiochip irq valid information
to figure out if certain gpios are exposed to the kernel for
usage or not. Expose this API so we can use it in the
pinmux_ops::request ops.

Signed-off-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Acked-by: Bjorn Andersson &lt;bjorn.andersson@linaro.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>kernel/irq: Extend lockdep class for request mutex</title>
<updated>2017-12-28T11:26:35+00:00</updated>
<author>
<name>Andrew Lunn</name>
<email>andrew@lunn.ch</email>
</author>
<published>2017-12-02T17:11:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39c3fd58952d7599d367c84c1330b785d91d6088'/>
<id>urn:sha1:39c3fd58952d7599d367c84c1330b785d91d6088</id>
<content type='text'>
The IRQ code already has support for lockdep class for the lock mutex
in an interrupt descriptor. Extend this to add a second class for the
request mutex in the descriptor. Not having a class is resulting in
false positive splats in some code paths.

Signed-off-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: linus.walleij@linaro.org
Cc: grygorii.strashko@ti.com
Cc: f.fainelli@gmail.com
Link: https://lkml.kernel.org/r/1512234664-21555-1-git-send-email-andrew@lunn.ch

</content>
</entry>
<entry>
<title>gpio: gpiolib: Generalise state persistence beyond sleep</title>
<updated>2017-12-02T21:42:34+00:00</updated>
<author>
<name>Andrew Jeffery</name>
<email>andrew@aj.id.au</email>
</author>
<published>2017-11-30T03:55:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e10f72bf4b3e8885c1915a119141481e7fc45ca8'/>
<id>urn:sha1:e10f72bf4b3e8885c1915a119141481e7fc45ca8</id>
<content type='text'>
General support for state persistence is added to gpiolib with the
introduction of a new pinconf parameter to propagate the request to
hardware. The existing persistence support for sleep is adapted to
include hardware support if the GPIO driver provides it. Persistence
continues to be enabled by default; in-kernel consumers can opt out, but
userspace (currently) does not have a choice.

The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
renamed, dropping the SLEEP prefix to reflect that the concept is no
longer sleep-specific.  I feel that renaming to just *_MAY_LOSE_VALUE
could initially be misinterpreted, so I've further changed the symbols
to *_TRANSITORY and *_PERSISTENT to address this.

The sysfs interface is modified only to keep consistency with the
chardev interface in enforcing persistence for userspace exports.

Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Reviewed-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>Merge branch 'i2c/for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wsa/linux</title>
<updated>2017-11-15T01:52:21+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2017-11-15T01:52:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4008e6a9bcee2f3b61bb11951de0fb0ed764cb91'/>
<id>urn:sha1:4008e6a9bcee2f3b61bb11951de0fb0ed764cb91</id>
<content type='text'>
Pull i2c updates from Wolfram Sang:
 "This contains two bigger than usual tree-wide changes this time. They
  all have proper acks, caused no merge conflicts in linux-next where
  they have been for a while. They are namely:

   - to-gpiod conversion of the i2c-gpio driver and its users (touching
     arch/* and drivers/mfd/*)

   - adding a sbs-manager based on I2C core updates to SMBus alerts
     (touching drivers/power/*)

  Other notable changes:

   - i2c_boardinfo can now carry a dev_name to be used when the device
     is created. This is because some devices in ACPI world need fixed
     names to find the regulators.

   - the designware driver got a long discussed overhaul of its PM
     handling. img-scb and davinci got PM support, too.

   - at24 driver has way better OF support. And it has a new maintainer.
     Thanks Bartosz for stepping up!

  The rest is regular driver updates and fixes"

* 'i2c/for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (55 commits)
  ARM: sa1100: simpad: Correct I2C GPIO offsets
  i2c: aspeed: Deassert reset in probe
  eeprom: at24: Add OF device ID table
  MAINTAINERS: new maintainer for AT24 driver
  i2c: nuc900: remove platform_data, too
  i2c: thunderx: Remove duplicate NULL check
  i2c: taos-evm: Remove duplicate NULL check
  i2c: Make i2c_unregister_device() NULL-aware
  i2c: xgene-slimpro: Support v2
  i2c: mpc: remove useless variable initialization
  i2c: omap: Trigger bus recovery in lockup case
  i2c: gpio: Add support for named gpios in DT
  dt-bindings: i2c: i2c-gpio: Add support for named gpios
  i2c: gpio: Local vars in probe
  i2c: gpio: Augment all boardfiles to use open drain
  i2c: gpio: Enforce open drain through gpiolib
  gpio: Make it possible for consumers to enforce open drain
  i2c: gpio: Convert to use descriptors
  power: supply: sbs-message: fix some code style issues
  power: supply: sbs-battery: remove unchecked return var
  ...
</content>
</entry>
</feed>
