31 Dec, 2019
1 commit
-
[ Upstream commit be4c60b563edee3712d392aaeb0943a768df7023 ]
When populating the pinctrl mapping table entries for a device, the
'dev_name' field for each entry is initialised to point directly at the
string returned by 'dev_name()' for the device and subsequently used by
'create_pinctrl()' when looking up the mappings for the device being
probed.This is unreliable in the presence of calls to 'dev_set_name()', which may
reallocate the device name string leaving the pinctrl mappings with a
dangling reference. This then leads to a use-after-free every time the
name is dereferenced by a device probe:| BUG: KASAN: invalid-access in strcmp+0x20/0x64
| Read of size 1 at addr 13ffffc153494b00 by task modprobe/590
| Pointer tag: [13], memory tag: [fe]
|
| Call trace:
| __kasan_report+0x16c/0x1dc
| kasan_report+0x10/0x18
| check_memory_region
| __hwasan_load1_noabort+0x4c/0x54
| strcmp+0x20/0x64
| create_pinctrl+0x18c/0x7f4
| pinctrl_get+0x90/0x114
| devm_pinctrl_get+0x44/0x98
| pinctrl_bind_pins+0x5c/0x450
| really_probe+0x1c8/0x9a4
| driver_probe_device+0x120/0x1d8Follow the example of sysfs, and duplicate the device name string before
stashing it away in the pinctrl mapping entries.Cc: Linus Walleij
Reported-by: Elena Petrova
Tested-by: Elena Petrova
Signed-off-by: Will Deacon
Link: https://lore.kernel.org/r/20191002124206.22928-1-will@kernel.org
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
05 Aug, 2019
1 commit
-
Improve readability by replacing a hardcoded number requiring a comment
by strlen().Gcc is smart enough to evaluate the length of a constant string at
compile-time.Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20190731132917.17607-2-geert+renesas@glider.be
Signed-off-by: Linus Walleij
04 Jul, 2019
1 commit
-
Some subsystems, such as pinctrl, allow continuing to defer probe
indefinitely. This is useful for devices that depend on resources
provided by devices that are only probed after the init stage.One example of this can be seen on Tegra, where the DPAUX hardware
contains pinmuxing controls for pins that it shares with an I2C
controller. The I2C controller is typically used for communication
with a monitor over HDMI (DDC). However, other instances of the I2C
controller are used to access system critical components, such as a
PMIC. The I2C controller driver will therefore usually be a builtin
driver, whereas the DPAUX driver is part of the display driver that
is loaded from a module to avoid bloating the kernel image with all
of the DRM/KMS subsystem.In this particular case the pins used by this I2C/DDC controller
become accessible very late in the boot process. However, since the
controller is only used in conjunction with display, that's not an
issue.Unfortunately the driver core currently outputs a warning message
when a device fails to get the pinctrl before the end of the init
stage. That can be confusing for the user because it may sound like
an unwanted error occurred, whereas it's really an expected and
harmless situation.In order to eliminate this warning, this patch allows callers of the
driver_deferred_probe_check_state() helper to specify that they want
to continue deferring probe, regardless of whether we're past the
init stage or not. All of the callers of that function are updated
for the new signature, but only the pinctrl subsystem passes a true
value in the new persist parameter if appropriate.Signed-off-by: Thierry Reding
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Linus Walleij
Link: https://lore.kernel.org/r/20190621151725.20414-1-thierry.reding@gmail.com
Signed-off-by: Greg Kroah-Hartman
31 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms and conditions of the gnu general public license
version 2 as published by the free software foundation this program
is distributed in the hope it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details you should have received a copy of the gnu general
public license along with this program if not see http www gnu org
licensesextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 228 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Reviewed-by: Steve Winslow
Reviewed-by: Richard Fontana
Reviewed-by: Alexios Zavras
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190528171438.107155473@linutronix.de
Signed-off-by: Greg Kroah-Hartman
10 Jul, 2018
1 commit
-
Pinctrl drivers are a common dependency which can prevent a system
booting even if the default or bootloader configured settings can work.
If a pinctrl node in DT indicates that the default pin setup can be used
with the 'pinctrl-use-default' property, then only defer probe until
initcalls are done. If the deferred probe timeout is enabled or loadable
modules are disabled, then we'll stop deferring probe regardless of the
DT property. This gives platforms the option to work without their
pinctrl driver being enabled.Dropped the pinctrl specific deferring probe message as the driver core
can print deferred probe related messages if needed.Reviewed-by: Linus Walleij
Signed-off-by: Rob Herring
Signed-off-by: Greg Kroah-Hartman
18 Jun, 2018
1 commit
-
Commit b89405b6102f ("pinctrl: devicetree: Fix dt_to_map_one_config
handling of hogs") causes the pinctrl hog pins to not get initialized
on i.MX platforms leaving them with the IOMUX settings untouched.This causes several regressions on i.MX such as:
- OV5640 camera driver can not be probed anymore on imx6qdl-sabresd
because the camera clock pin is in a pinctrl_hog group and since
its pinctrl initialization is skipped, the camera clock is kept
in GPIO functionality instead of CLK_CKO function.- Audio stopped working on imx6qdl-wandboard and imx53-qsb for
the same reason.Richard Fitzgerald explains the problem:
"I see the bug. If the hog node isn't a 1st level child of the pinctrl
parent node it will go around the for(;;) loop again but on the first
pass I overwrite pctldev with the result of
get_pinctrl_dev_from_of_node() so it doesn't point to the pinctrl driver
any more."Fix the issue by stashing the original pctldev so it doesn't
get overwritten.Fixes: b89405b6102f ("pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs")
Cc:
Reported-by: Mika Penttilä
Reported-by: Steve Longerbeam
Suggested-by: Richard Fitzgerald
Signed-off-by: Fabio Estevam
Reviewed-by: Dong Aisheng
Reviewed-by: Richard Fitzgerald
Signed-off-by: Linus Walleij
02 Mar, 2018
1 commit
-
When dt_to_map_one_config() is called with a pinctrl_dev passed
in, it should only be using this if the node being looked up
is a hog. The code was always using the passed pinctrl_dev
without checking whether the dt node referred to it.A pin controller can have pinctrl-n dependencies on other pin
controllers in these cases:- the pin controller hardware is external, for example I2C, so
needs other pin controller(s) to be setup to communicate with
the hardware device.- it is a child of a composite MFD so its of_node is shared with
the parent MFD and other children of that MFD. Any part of that
MFD could have dependencies on other pin controllers.Because of this, dt_to_map_one_config() can't assume that if it
has a pinctrl_dev passed in then the node it looks up must be
a hog. It could be a reference to some other pin controller.Signed-off-by: Richard Fitzgerald
Signed-off-by: Linus Walleij
31 Aug, 2017
1 commit
-
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
Signed-off-by: Linus Walleij
14 Aug, 2017
1 commit
-
Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.Signed-off-by: Rob Herring
Cc: Linus Walleij
Cc: Lee Jones
Cc: Stefan Wahren
Cc: Florian Fainelli
Cc: Ray Jui
Cc: Scott Branden
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Tomasz Figa
Cc: Sylwester Nawrocki
Cc: Laurent Pinchart
Cc: Barry Song
Cc: linux-gpio@vger.kernel.org
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: kernel@stlinux.com
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Acked-by: Krzysztof Kozlowski
Acked-by: Ludovic Desroches
Acked-by: Patrice Chotard
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
Acked-by: Eric Anholt
Signed-off-by: Linus Walleij
10 Jan, 2017
1 commit
-
If the pin controller driver is using devm_kzalloc, there may not be
anything to do for dt_free_map. Let's make it optional to avoid
unncessary boilerplate code.Signed-off-by: Tony Lindgren
Signed-off-by: Linus Walleij
03 Jan, 2017
1 commit
-
Having the pin control framework call pin controller functions
before it's probe has finished is not nice as the pin controller
device driver does not yet have struct pinctrl_dev handle.Let's fix this issue by adding deferred work for late init. This is
needed to be able to add pinctrl generic helper functions that expect
to know struct pinctrl_dev handle. Note that we now need to call
create_pinctrl() directly as we don't want to add the pin controller
to the list of controllers until the hogs are claimed. We also need
to pass the pinctrl_dev to the device tree parser functions as they
otherwise won't find the right controller at this point.Signed-off-by: Tony Lindgren
Signed-off-by: Linus Walleij
05 Nov, 2016
1 commit
-
Introduce #pinctrl-cells helper binding and generic helper functions
pinctrl_count_index_with_args() and pinctrl_parse_index_with_args().Acked-by: Rob Herring
Signed-off-by: Tony Lindgren
[Forward-declare of_phandle_args]
Signed-off-by: Linus Walleij
18 Jun, 2016
1 commit
-
When pinctrl_get() is called for a device, it will return a valid handle
even if the device itself has no pinctrl state entries defined in
device-tree. This is caused by the function pinctrl_dt_to_map() which
will return success even if the first pinctrl state, 'pinctrl-0', is not
found in the device-tree node for a device.According to the pinctrl device-tree binding documentation, pinctrl
states must be numbered starting from 0 and so 'pinctrl-0' should always
be present if a device uses pinctrl and therefore, if 'pinctrl-0' is not
present it seems valid that we should not return a valid pinctrl handle.Fix this by returning an error code if the property 'pinctrl-0' is not
present for a device.Signed-off-by: Jon Hunter
Signed-off-by: Linus Walleij
16 Jul, 2015
1 commit
-
This commit does not change the logic at all.
Signed-off-by: Masahiro Yamada
Signed-off-by: Linus Walleij
06 May, 2015
1 commit
-
Way back, when the world was a simpler place and there was no war, no
evil, and no kernel bugs, there was just a single pinctrl lock. That
was how the world was when (57291ce pinctrl: core device tree mapping
table parsing support) was written. In that case, there were
instances where the pinctrl mutex was already held when
pinctrl_register_map() was called, hence a "locked" parameter was
passed to the function to indicate that the mutex was already locked
(so we shouldn't lock it again).A few years ago in (42fed7b pinctrl: move subsystem mutex to
pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
...but (oops) we forgot to re-think about the whole "locked" parameter
for pinctrl_register_map(). Basically the "locked" parameter appears
to still refer to whether the bigger pinctrl_dev mutex is locked, but
we're using it to skip locks of our (now separate) pinctrl_maps_mutex.That's kind of a bad thing(TM). Probably nobody noticed because most
of the calls to pinctrl_register_map happen at boot time and we've got
synchronous device probing. ...and even cases where we're
asynchronous don't end up actually hitting the race too often. ...but
after banging my head against the wall for a bug that reproduced 1 out
of 1000 reboots and lots of looking through kgdb, I finally noticed
this.Anyway, we can now safely remove the "locked" parameter and go back to
a war-free, evil-free, and kernel-bug-free world.Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Signed-off-by: Doug Anderson
Signed-off-by: Linus Walleij
24 Feb, 2014
1 commit
-
On systems which were not booted using DT it is entirely unsurprising that
device nodes don't have any DT information and this is going to happen for
every single device in the system. Make pinctrl be less chatty about this
situation by only logging in the case where we have DT.Signed-off-by: Mark Brown
Signed-off-by: Linus Walleij
26 Apr, 2013
1 commit
-
This mutex avoids deadlock in case of use of multiple pin
controllers. Before this modification, by using a global
mutex, deadlock appeared when, for example, a call to
pinctrl_pins_show() locked the pinctrl_mutex, called the
ops->pin_dbg_show of a particular pin controller. If this
pin controller needs I2C access to retrieve configuration
information and I2C driver is using pinctrl to drive its
pins, a call to pinctrl_select_state() try to lock again
pinctrl_mutex which leads to a deadlock.Notice that the mutex grab from the two direction functions
was moved into pinctrl_gpio_direction().For several cases, we can't replace pinctrl_mutex by
pctldev->mutex, because at this stage, pctldev is
not accessible :
- pinctrl_get()/pinctrl_put()
- pinctrl_register_maps()So add respectively pinctrl_list_mutex and
pinctrl_maps_mutex in order to protect
pinctrl_list and pinctrl_maps list instead.Reintroduce pinctrldev_list_mutex in
find_pinctrl_by_of_node(),
pinctrl_find_and_add_gpio_range()
pinctrl_request_gpio(), pinctrl_free_gpio(),
pinctrl_gpio_direction(), pinctrl_devices_show(),
pinctrl_register() and pinctrl_unregister() to
protect pinctrldev_list.Changes v2->v3:
- Fix a missing EXPORT_SYMBOL_GPL() for pinctrl_select_state().Changes v1->v2:
- pinctrl_select_state_locked() is removed, all lock mechanism
is located inside pinctrl_select_state(). When parsing
the state->setting list, take the per-pin-controller driver
lock. (Patrice).
- Introduce pinctrldev_list_mutex to protect pinctrldev_list
in all functions which parse or modify pictrldev_list.
(Patrice).
- move find_pinctrl_by_of_node() from pinctrl/devicetree.c to
pinctrl/core.c in order to protect pinctrldev_list.
(Patrice).
- Sink mutex:es into some functions and remove some _locked
variants down to where the lists are actually accessed to
make things simpler. (Linus)
- Drop *all* mutexes completely from pinctrl_lookup_state()
and pinctrl_select_state() - no relevant mutex was taken
and it was unclear what this was protecting against. (Linus)Reported by : Seraphin Bonnaffe
Signed-off-by: Patrice Chotard
Signed-off-by: Linus Walleij
07 Mar, 2013
1 commit
-
The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.Signed-off-by: Laurent Pinchart
Signed-off-by: Linus Walleij
12 Jan, 2013
1 commit
-
commit af1024e0f7cde9023ddd0f3116db03911d5914c0
"pinctrl: skip deferral of hogs"Attempts to avoid probe deferral on hogged pins, but we
forgot the device tree case. This patch fixes this.Cc: Laurent Pinchart
Reported-by: Stephen Warren
Signed-off-by: Linus Walleij
12 Nov, 2012
2 commits
-
The fact that of_gpiochip_add_pin_range() and
gpiochip_add_pin_range() share too much code is fragile and
will invariably mean that bugs need to be fixed in two places
instead of one.So separate the concerns of gpiolib.c and gpiolib-of.c and
have the latter call the former as back-end. This is necessary
also when going forward with other device descriptions such
as ACPI.This is done by:
- Adding a return code to gpiochip_add_pin_range() so we can
reliably check whether this succeeds.- Get rid of the custom of_pinctrl_add_gpio_range() from
pinctrl. Instead create of_pinctrl_get() to just retrive the
pin controller per se from an OF node. This composite
function was just begging to be deleted, it was way to
purpose-specific.- Use pinctrl_dev_get_name() to get the name of the retrieved
pin controller and use that to call back into the generic
gpiochip_add_pin_range().Now the pin range is only allocated and tied to a pin
controller from the core implementation in gpiolib.c.Signed-off-by: Linus Walleij
-
pinctrl subsystem needs gpio chip base to prepare set of gpio
pin ranges, which a given pinctrl driver can handle. This is
important to handle pinctrl gpio request calls in order to
program a given pin properly for gpio operation.As gpio base is allocated dynamically during gpiochip
registration, presently there exists no clean way to pass this
information to the pinctrl subsystem.After few discussions from [1], it was concluded that may be
gpio controller reporting the pin range it supports, is a
better way than pinctrl subsystem directly registering it.[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
Cc: Grant Likely
Signed-off-by: Viresh Kumar
Signed-off-by: Shiraz Hashim
[Edited documentation a bit]
Signed-off-by: Linus Walleij
18 Apr, 2012
2 commits
-
If drivers try to obtain pinctrl handles for a pin controller that
has not yet registered to the subsystem, we need to be able to
back out and retry with deferred probing. So let's return
-EPROBE_DEFER whenever this location fails. Also downgrade the
errors to info, maybe we will even set them to debug once the
deferred probing is commonplace.Cc: Arnd Bergmann
Reviewed-by: Mark Brown
Acked-by: Stephen Warren
Signed-off-by: Linus Walleij -
During pinctrl_get(), if the client device has a device tree node, look
for the common pinctrl properties there. If found, parse the referenced
device tree nodes, with the help of the pinctrl drivers, and generate
mapping table entries from them.During pinctrl_put(), free any results of device tree parsing.
Acked-by: Dong Aisheng
Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
