29 Oct, 2018
16 commits
-
Pinctrl support of a device tree property "pinctrl-assert-gpios"
under client device node to select function at a board level pin
multiplexer. The pin route is controlled by a GPIO or i2c/spi expander
GPIO.For i2c/spi expander GPIO, it may be loaded after client device that
set "pinctrl-assert-gpios" property in devicetree. Then the client device's
pin function doesn't work.So it should add defer probe check for the GPIO pin.
Acked-by: Leonard Crestez
Signed-off-by: Fugang Duan -
Add i.MX8MM pinctrl driver support.
Signed-off-by: Anson Huang
Reviewed-by: Bai Ping -
First of all, the design of using CONFIG_IBE_OBE is wrong as both VF and
IMX has IBE and OBE while current code defined it in common code but for
only IMX which causes a bit confusing.Second, remove the following invalid comments as we will clear IBE.
"IBE always enabled allows us to read the value on the wire"Last, replace the complicated "if else" statement with a much simpler one.
Cc: Bai Ping
Reviewed-by: Peng Fan
Reviewed-by: Fugang Duan
Fixes: 07787c40ff3b ("MLK-13485-3 pinctrl: imx: modify the imx pinctrl to support imx7ulp gpio")
Signed-off-by: Dong Aisheng -
Add i.MX8MQ pinctrl driver support.
Signed-off-by: Anson Huang
-
As i.MX8MQ is a ARM64 SoC but it does NOT use SCU pinctrl, so
need to support both SCU and MEMMAP pinctrl together for ARM64
build.use IMX8_USE_SCU flag to distinguish SCU and MEMMAP pinctrl
type.Signed-off-by: Anson Huang
Signed-off-by: Peng Fan -
switch to use new format. Split mux out from pad config.
Change the high two bits in pad config to 0, because driver
will automatically set that two bits to 1.Signed-off-by: Peng Fan
-
list is a local variable, each time imx_pinctrl_parse_pin is
invoked, list points to the first pin. Directly use list_p in
imx_pinctrl_parse_pin to fix it.When splitting pinctrl-imx.c, two pieces code is correctly moved.
- In imx_pmx_set_one_pin, when mux_reg is -1, need to return 0 to
let the caller continue the loop.
- In imx_pinctrl_parse_pin, need to use (mux_reg != -1) when calculating
the pin_id.Signed-off-by: Peng Fan
-
Add i.MX8QXP pinctrl driver support.
Signed-off-by: Anson Huang
-
Add i.MX8QM pinctrl driver support.
Signed-off-by: Anson Huang
Signed-off-by: Peng Fan -
On i.MX8QM/QXP, pin is handled by SCU, A53/72 can not directly
handle pinmux as i.MX6/7.Split the original pinctrl-imx.c to two parts, the pinctrl-memmap.c
will handle the memory mapped access for i.MX6/7. pinctrl-imx.c
will be shared by legacy i.mx and i.MX8.Introduce pinctrl-scu.c to handle the connection with SCU to configure
pin settings.Signed-off-by: Peng Fan
Signed-off-by: Anson HuangRebased on top of 4.14 changes
Signed-off-by: Leonard Crestez
-
This makes imx7ulp boot.
Signed-off-by: Leonard Crestez
-
Add support for imx7ulp iomux controller.
Signed-off-by: Fugang Duan
Merged with upstream 4.14 version
Signed-off-by: Leonard Crestez
-
Add pinctrl driver support for i.MX6SLL.
Signed-off-by: Anson Huang
Signed-off-by: Bai Ping -
On i.MX6ULL, the BOOT_MODEx and TAMPERx pin MUX and CTRL register
have been moved from IOMUXC to IOMUXC_SNVS, so the pinctrl driver
should be modified to support the IOMUXC_SNVS.Signed-off-by: Bai Ping
-
To support pinctl hog restore after LPSR resume back,
add suspend/resume in pinctrl driver.Signed-off-by: Robin Gong
-
It's pretty common that on some reference design or validation boards,
one pin could be used by two devices on board, and the pin route is
controlled by a GPIO. So to assert the pin for given device, not only
the pinmux controller in SoC needs to be set up properly but also the
GPIO needs to be pulled up/down.The patch adds support of a device tree property "pinctrl-assert-gpios"
under client device node. It plays pretty much like a board level pin
multiplexer, and steers the pin route by controlling the GPIOs. When
client device has the property represent in its node, pinctrl device
tree mapping function will firstly pull up/down the GPIOs to assert the
pins for the device at board level.[shawn.guo: cherry-pick commit e5a718edab82 from imx_3.10.y]
Signed-off-by: Shawn Guo
18 Oct, 2018
1 commit
-
commit f259f896f2348f0302f6f88d4382378cf9d23a7e upstream.
Since 'commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' the
irq request isn't the last devm_* allocation. Without a deeper look at
the irq and testing this isn't a good solution. Since this driver relies
on the devm mechanism, requesting a interrupt should be the last thing
to avoid memory corruptions during unbinding.'Commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' fixed the
order for the interrupt-controller use case only. The
mcp23s08_irq_setup() must be split into two to fix it for the
interrupt-controller use case and to register the irq at last. So the
irq will be freed first during unbind.Cc: stable@vger.kernel.org
Cc: Jan Kundrát
Cc: Dmitry Mastykin
Cc: Sebastian Reichel
Fixes: 82039d244f87 ("pinctrl: mcp23s08: add pinconf support")
Fixes: 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")
Signed-off-by: Marco Felsch
Tested-by: Phil Reid
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
26 Sep, 2018
3 commits
-
[ Upstream commit 1cf86bc21257a330e3af51f2a4e885f1a705f6a5 ]
If you do this on an sdm845 board:
grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups...it looks like nonsense. For every pin you see listed:
input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ...That's because pmic_gpio_config_get() isn't complying with the rules
that pinconf_generic_dump_one() expects. Specifically for boolean
parameters (anything with a "struct pin_config_item" where has_arg is
false) the function expects that the function should return its value
not through the "config" parameter but should return "0" if the value
is set and "-EINVAL" if the value isn't set.Let's fix this.
>From a quick sample of other pinctrl drivers, it appears to be
tradition to also return 1 through the config parameter for these
boolean parameters when they exist. I'm not one to knock tradition,
so I'll follow tradition and return 1 in these cases. While I'm at
it, I'll also continue searching for four leaf clovers, kocking on
wood three times, and trying not to break mirrors.NOTE: This also fixes an apparent typo for reading
PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally
using "=" instead of "==" and thus was setting some internal
state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops.Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver")
Signed-off-by: Douglas Anderson
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 05e0c828955c1cab58dd71a04539442e5375d917 ]
If you do this on an sdm845 board:
cat /sys/kernel/debug/pinctrl/3400000.pinctrl/pinconf-groups...it looks like nonsense. For every pin you see listed:
input bias bus hold, input bias disabled, input bias pull down, input bias pull upThat's because msm_config_group_get() isn't complying with the rules
that pinconf_generic_dump_one() expects. Specifically for boolean
parameters (anything with a "struct pin_config_item" where has_arg is
false) the function expects that the function should return its value
not through the "config" parameter but should return "0" if the value
is set and "-EINVAL" if the value isn't set.Let's fix this.
>From a quick sample of other pinctrl drivers, it appears to be
tradition to also return 1 through the config parameter for these
boolean parameters when they exist. I'm not one to knock tradition,
so I'll follow tradition and return 1 in these cases. While I'm at
it, I'll also continue searching for four leaf clovers, kocking on
wood three times, and trying not to break mirrors.Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Signed-off-by: Douglas Anderson
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit dc4003d260594aa300028c3c5d040c5719abd19b ]
We must use a mutex around the generic_add functions and save the
function and group selector in case we need to remove them. Otherwise
the selector use will be racy for deferred probe at least.Fixes: 5a49b644b307 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
Reported-by: H. Nikolaus Schaller
Cc: Christ van Willegen
Cc: Haojian Zhuang
Cc: Paul Cercueil
Cc: Sean Wang
Acked-by: Jacopo Mondi
Signed-off-by: Tony Lindgren
Tested-By: H. Nikolaus Schaller
Reviewed-by: Andy Shevchenko
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
20 Sep, 2018
2 commits
-
[ Upstream commit 8bbed1eef001fdfc0ee9595f64cc4f769d265af4 ]
The AMD pinctrl driver demultiplexes GPIO interrupts and fires off their
individual handlers.If one of these GPIO irqs is configured as a level interrupt, and its
downstream handler is a threaded ONESHOT interrupt, the GPIO interrupt
source is masked by handle_level_irq() until the eventual return of the
threaded irq handler. During this time the level GPIO interrupt status
will still report as high until the actual gpio source is cleared - both
in the individual GPIO interrupt status bit (INTERRUPT_STS_OFF) and in
its corresponding "WAKE_INT_STATUS_REG" bit.Thus, if another GPIO interrupt occurs during this time,
amd_gpio_irq_handler() will see that the (masked-and-not-yet-cleared)
level irq is still pending and incorrectly call its handler again.To fix this, have amd_gpio_irq_handler() check for both interrupts status
and mask before calling generic_handle_irq().Note: Is it possible that this bug was the source of the interrupt storm
on Ryzen when using chained interrupts before commit ba714a9c1dea85
("pinctrl/amd: Use regular interrupt instead of chained")?Signed-off-by: Daniel Kurtz
Acked-by: Thomas Gleixner
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b4859f3edb47825f62d1b2efdd75fe7945996f49 ]
The > should really be >= here. It's harmless because
pinctrl_generic_get_group() will return a NULL if group is invalid.Fixes: ae75ff814538 ("pinctrl: pinctrl-imx: add imx pinctrl core driver")
Reported-by: Dong Aisheng
Signed-off-by: Dan Carpenter
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
05 Sep, 2018
1 commit
-
commit 19da44cd33a3a6ff7c97fff0189999ff15b241e4 upstream.
The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It
has info->ngroups elements. Thus the > here should be >= to prevent
reading one element beyond the end of the array.Cc: stable@vger.kernel.org
Fixes: 30612cd90005 ("pinctrl: imx1 core driver")
Signed-off-by: Dan Carpenter
Reviewed-by: Uwe Kleine-König
Acked-by: Dong Aisheng
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
24 Aug, 2018
3 commits
-
[ Upstream commit c29e9da56bebb4c2c794e871b0dc0298bbf08142 ]
platform_get_resource() may fail and return NULL, so we should
better check it's return value to avoid a NULL pointer dereference
a bit later in the code.This is detected by Coccinelle semantic patch.
@@
expression pdev, res, n, t, e, e1, e2;
@@res = platform_get_resource(pdev, t, n);
+ if (!res)
+ return -EINVAL;
... when != res == NULL
e = devm_ioremap_nocache(e1, res->start, e2);Fixes: cc4fa83f66e9 ("pinctrl: nsp: add pinmux driver support for Broadcom NSP SoC")
Signed-off-by: Wei Yongjun
Reviewed-by: Ray Jui
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit f90a21c898db58eaea14b8ad7e9af3b9e15e5f8a ]
The > comparisons should be >= or else we read beyond the end of the
pinctrl->functions[] array.Fixes: cc4fa83f66e9 ("pinctrl: nsp: add pinmux driver support for Broadcom NSP SoC")
Signed-off-by: Dan Carpenter
Reviewed-by: Ray Jui
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 0084a786ca8c84b443f67c4a697b4f2552761650 ]
The .gpio_set_direction() callback was setting inverted direction
for SoCs older than the JZ4770, this restores the correct behaviour.Signed-off-by: Paul Cercueil
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
03 Aug, 2018
1 commit
-
[ Upstream commit 21816364715f508c10da1e087e352bc1e326614f ]
The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr)://
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@for_each_child_of_node(root, child) {
... when != of_node_put(child)
when != e = child
+ of_node_put(child);
? break;
...
}
... when != child
//Signed-off-by: Julia Lawall
Acked-by: Ludovic Desroches
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2018
2 commits
-
commit bc3322bc166a2905bc91f774d7b22773dc7c063a upstream.
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
Signed-off-by: Greg Kroah-Hartman -
commit 5cf9a338db94cfd570aa2607bef1b30996f188e3 upstream.
All banks with GPIO interrupts should be at beginning of bank array and
without any other types of banks between them. This order is expected
by exynos_eint_gpio_irq, when doing interrupt group to bank translation.
Otherwise, kernel NULL pointer dereference would happen when trying to
handle interrupt, due to wrong bank being looked up. Observed on
s5pv210, when trying to handle gpj0 interrupt, where kernel was mapping
it to gpi bank.Cc: stable@vger.kernel.org
Fixes: 023e06dfa688 ("pinctrl: exynos: add exynos5410 SoC specific data")
Fixes: 608a26a7bc04 ("pinctrl: Add s5pv210 support to pinctrl-exynos)
Signed-off-by: Paweł Chmiel
Reviewed-by: Tomasz Figa
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Greg Kroah-Hartman
05 Jun, 2018
1 commit
-
This reverts commit bd36ea57d6d58041180c4f7d2c2bf5194c26845d which is
commit a7aa75a2a7dba32594291a71c3704000a2fd7089 upstream.There's been too many complaints about this. Personally I think it's
going to blow up when people hit this in mainline, but hey, it's not my
systems. At least we don't have to backport the mess to the stable
kernels to give them some more life to live unscathed :)Reported-by: Timur Tabi
Reported-by: Sebastian Gottschall
Cc: Bjorn Andersson
Cc: Linus Walleij
Cc: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
30 May, 2018
4 commits
-
[ Upstream commit 9b3e4207661e67f04c72af15e29f74cd944f5964 ]
The SPI version of this chip allows several devices to be present on the
same SPI bus via a local address. If this is in action and if the kernel
has debugfs, however, the code attempts to create duplicate entries for
the regmap's debugfs:mcp23s08 spi1.1: Failed to create debugfs directory
This patch simply assigns a local name matching the device logical
address to the `struct regmap_config`.No changes are needed for MCP23S18 because that device does not support
any logical addressing. Similarly, I2C devices do not need any action,
either, because they are already different in their I2C address.A similar problem is present for the pinctrl debugfs instance, but that
one is not addressed by this patch.Signed-off-by: Jan Kundrát
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]
The base of the TLMM gpiochip should not be statically defined as 0, fix
this to not artificially restrict the existence of multiple pinctrl-msm
devices.Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
Reported-by: Timur Tabi
Signed-off-by: Bjorn Andersson
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b418c4609d5052d174668ad6d13efe023c45c595 ]
This patch fixes MOD_SEL1 bit20 and MOD_SEL2 bit20, bit21 pin assignment
for SSI pins group.This is a correction to the incorrect implementation of MOD_SEL register
pin assignment for R8A7796 SoC specification of R-Car Gen3 Hardware
User's Manual Rev.0.51E or later.Fixes: f9aece7344bd ("pinctrl: sh-pfc: Initial R8A7796 PFC support")
Signed-off-by: Takeshi Kihara
Signed-off-by: Ulrich Hecht
Reviewed-by: Simon Horman
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit b89405b6102fcc3746f43697b826028caa94c823 ]
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
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
29 Apr, 2018
1 commit
-
This reverts commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257
Mike writes:
It seems that commit f5a26acf0162 ("pinctrl: intel: Initialize GPIO
properly when used through irqchip") can cause problems on some Skylake
systems with Sunrisepoint PCH-H. Namely on certain systems it may turn
the backlight PWM pin from native mode to GPIO which makes the screen
blank during boot.There is more information here:
https://bugzilla.redhat.com/show_bug.cgi?id=1543769
The actual reason is that GPIO numbering used in BIOS is using "Windows"
numbers meaning that they don't match the hardware 1:1 and because of
this a wrong pin (backlight PWM) is picked and switched to GPIO mode.There is a proper fix for this but since it has quite many dependencies
on commits that cannot be considered stable material, I suggest we
revert commit f5a26acf0162 from stable trees 4.9, 4.14 and 4.15 to
prevent the backlight issue.Reported-by: Mika Westerberg
Fixes: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
Cc: Daniel Drake
Cc: Chris Chiu
Cc: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
12 Apr, 2018
1 commit
-
[ Upstream commit 9291c65b01d1c67ebd56644cb19317ad665c44b3 ]
On some systems, some PCB traces attached to GpioInts are routed in such
a way that they pick up enough interference to constantly (many times per
second) trigger.Enabling glitch-filtering fixes this.
Signed-off-by: Hans de Goede
Acked-by: Mika Westerberg
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
29 Mar, 2018
1 commit
-
commit 93b0beae721b3344923b4b8317e9d83b542f4ca6 upstream.
Driver uses alias from Device Tree as an index of pin controller data
array. In case of a wrong DTB or an out-of-tree DTB, the alias could be
outside of this data array leading to out-of-bounds access.Depending on binary and memory layout, this could be handled properly
(showing error like "samsung-pinctrl 3860000.pinctrl: driver data not
available") or could lead to exceptions.Reported-by: Geert Uytterhoeven
Cc:
Fixes: 30574f0db1b1 ("pinctrl: add samsung pinctrl and gpiolib driver")
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Geert Uytterhoeven
Acked-by: Tomasz Figa
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
24 Mar, 2018
2 commits
-
[ Upstream commit 5c9d8c4f6b8168738a26bcf288516cc3a0886810 ]
We generally leave the GPIO clock disabled, unless an interrupt is
requested or we're accessing IO registers. We forgot to do this for the
->get_direction() callback, which means we can sometimes [1] get
incorrect results [2] from, e.g., /sys/kernel/debug/gpio.Enable the clock, so we get the right results!
[1] Sometimes, because many systems have 1 or mor interrupt requested on
each GPIO bank, so they always leave their clock on.[2] Incorrect, meaning the register returns 0, and so we interpret that
as "input".Signed-off-by: Brian Norris
Reviewed-by: Heiko Stuebner
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ]
In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and resumes
in a way that the pin states are not preserved by the hardware, when we
resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
-> pinctrl_select_state() and the first thing we do is check that the
pins state is the same as before, and do nothing.In order to fix this, decouple the actual state change from
pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
the p->state == state check in pinctrl_select_state() not to change the
caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
are updated to bypass the state check by calling pinctrl_commit_state().[Linus Walleij]
The forced pin control states are currently only used in some pin
controller drivers that grab their own reference to their own pins.
This is equal to the pin control hogs: pins taken by pin control
devices since there are no corresponding device in the Linux device
hierarchy, such as memory controller lines or unused GPIO lines,
or GPIO lines that are used orthogonally from the GPIO subsystem
but pincontrol-wise managed as hogs (non-strict mode, allowing
simultaneous use by GPIO and pin control). For this case forcing
the state from the drivers' suspend()/resume() callbacks makes
sense and should semantically match the name of the function.Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
Signed-off-by: Florian Fainelli
Reviewed-by: Andy Shevchenko
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
19 Mar, 2018
1 commit
-
[ Upstream commit b16cd900de7911f96af17327a081a2141a0b763f ]
This patch fixes the implementation incorrect of MOD_SEL1 bit[25:24]
value when STP_ISEN_1_D pin function is selected for IPSR16 bit[27:24].This is a correction to the incorrect implementation of MOD_SEL register
pin assignment for R8A7795 SoC specification of R-Car Gen3 Hardware
User's Manual Rev.0.51E.Fixes: 0b0ffc96dbe30fa9 ("pinctrl: sh-pfc: Initial R8A7795 PFC support)
Signed-off-by: Takeshi Kihara
Signed-off-by: Yoshihiro Kaneko
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman