<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/pinctrl, branch v6.6.39</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.39</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.39'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-07-05T07:33:54+00:00</updated>
<entry>
<title>pinctrl: qcom: spmi-gpio: drop broken pm8008 support</title>
<updated>2024-07-05T07:33:54+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan+linaro@kernel.org</email>
</author>
<published>2024-05-29T16:29:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c2a78811ff9b67be7484cd673d8b94fc310badb0'/>
<id>urn:sha1:c2a78811ff9b67be7484cd673d8b94fc310badb0</id>
<content type='text'>
commit 8da86499d4cd125a9561f9cd1de7fba99b0aecbf upstream.

The SPMI GPIO driver assumes that the parent device is an SPMI device
and accesses random data when backcasting the parent struct device
pointer for non-SPMI devices.

Fortunately this does not seem to cause any issues currently when the
parent device is an I2C client like the PM8008, but this could change if
the structures are reorganised (e.g. using structure randomisation).

Notably the interrupt implementation is also broken for non-SPMI devices.

Also note that the two GPIO pins on PM8008 are used for interrupts and
reset so their practical use should be limited.

Drop the broken GPIO support for PM8008 for now.

Fixes: ea119e5a482a ("pinctrl: qcom-pmic-gpio: Add support for pm8008")
Cc: stable@vger.kernel.org	# 5.13
Reviewed-by: Bryan O'Donoghue &lt;bryan.odonoghue@linaro.org&gt;
Reviewed-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Link: https://lore.kernel.org/r/20240529162958.18081-9-johan+linaro@kernel.org
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: rockchip: fix pinmux reset in rockchip_pmx_set</title>
<updated>2024-07-05T07:33:44+00:00</updated>
<author>
<name>Huang-Huang Bao</name>
<email>i@eh5.me</email>
</author>
<published>2024-06-06T12:57:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2838dfa5290ffb6011104c8eca6ecc69de4e1461'/>
<id>urn:sha1:2838dfa5290ffb6011104c8eca6ecc69de4e1461</id>
<content type='text'>
[ Upstream commit 4ea4d4808e342ddf89ba24b93ffa2057005aaced ]

rockchip_pmx_set reset all pinmuxs in group to 0 in the case of error,
add missing bank data retrieval in that code to avoid setting mux on
unexpected pins.

Fixes: 14797189b35e ("pinctrl: rockchip: add return value to rockchip_set_mux")
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Huang-Huang Bao &lt;i@eh5.me&gt;
Link: https://lore.kernel.org/r/20240606125755.53778-5-i@eh5.me
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>pinctrl: rockchip: use dedicated pinctrl type for RK3328</title>
<updated>2024-07-05T07:33:43+00:00</updated>
<author>
<name>Huang-Huang Bao</name>
<email>i@eh5.me</email>
</author>
<published>2024-06-06T12:57:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b85dec60a3748fb81f49aa2901abdde17c6a28fb'/>
<id>urn:sha1:b85dec60a3748fb81f49aa2901abdde17c6a28fb</id>
<content type='text'>
[ Upstream commit 01b4b1d1cec48ef4c26616c2fc4600b2c9fec05a ]

rk3328_pin_ctrl uses type of RK3288 which has a hack in
rockchip_pinctrl_suspend and rockchip_pinctrl_resume to restore GPIO6-C6
at assume, the hack is not applicable to RK3328 as GPIO6 is not even
exist in it. So use a dedicated pinctrl type to skip this hack.

Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Signed-off-by: Huang-Huang Bao &lt;i@eh5.me&gt;
Link: https://lore.kernel.org/r/20240606125755.53778-4-i@eh5.me
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>pinctrl: rockchip: fix pinmux bits for RK3328 GPIO3-B pins</title>
<updated>2024-07-05T07:33:43+00:00</updated>
<author>
<name>Huang-Huang Bao</name>
<email>i@eh5.me</email>
</author>
<published>2024-06-06T12:57:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=14f6c7bf21ce15ba2d2e094366eadf3190b722c1'/>
<id>urn:sha1:14f6c7bf21ce15ba2d2e094366eadf3190b722c1</id>
<content type='text'>
[ Upstream commit 5ef6914e0bf578357b4c906ffe6b26e7eedb8ccf ]

The pinmux bits for GPIO3-B1 to GPIO3-B6 pins are not explicitly
specified in RK3328 TRM, however we can get hint from pad name and its
correspinding IOMUX setting for pins in interface descriptions. The
correspinding IOMIX settings for these pins can be found in the same
row next to occurrences of following pad names in RK3328 TRM.

GPIO3-B1:  IO_TSPd5m0_CIFdata5m0_GPIO3B1vccio6
GPIO3-B2: IO_TSPd6m0_CIFdata6m0_GPIO3B2vccio6
GPIO3-B3: IO_TSPd7m0_CIFdata7m0_GPIO3B3vccio6
GPIO3-B4: IO_CARDclkm0_GPIO3B4vccio6
GPIO3-B5: IO_CARDrstm0_GPIO3B5vccio6
GPIO3-B6: IO_CARDdetm0_GPIO3B6vccio6

Add pinmux data to rk3328_mux_recalced_data as mux register offset for
these pins does not follow rockchip convention.

Signed-off-by: Huang-Huang Bao &lt;i@eh5.me&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
Link: https://lore.kernel.org/r/20240606125755.53778-3-i@eh5.me
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>pinctrl: rockchip: fix pinmux bits for RK3328 GPIO2-B pins</title>
<updated>2024-07-05T07:33:43+00:00</updated>
<author>
<name>Huang-Huang Bao</name>
<email>i@eh5.me</email>
</author>
<published>2024-06-06T12:57:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=98db009476973faeb6def5026af89b3f04dffb0d'/>
<id>urn:sha1:98db009476973faeb6def5026af89b3f04dffb0d</id>
<content type='text'>
[ Upstream commit e8448a6c817c2aa6c6af785b1d45678bd5977e8d ]

The pinmux bits for GPIO2-B0 to GPIO2-B6 actually have 2 bits width,
correct the bank flag for GPIO2-B. The pinmux bits for GPIO2-B7 is
recalculated so it remain unchanged.

The pinmux bits for those pins are not explicitly specified in RK3328
TRM, however we can get hint from pad name and its correspinding IOMUX
setting for pins in interface descriptions. The correspinding IOMIX
settings for GPIO2-B0 to GPIO2-B6 can be found in the same row next to
occurrences of following pad names in RK3328 TRM.

GPIO2-B0: IO_SPIclkm0_GPIO2B0vccio5
GPIO2-B1: IO_SPItxdm0_GPIO2B1vccio5
GPIO2-B2: IO_SPIrxdm0_GPIO2B2vccio5
GPIO2-B3: IO_SPIcsn0m0_GPIO2B3vccio5
GPIO2-B4: IO_SPIcsn1m0_FLASHvol_sel_GPIO2B4vccio5
GPIO2-B5: IO_ I2C2sda_TSADCshut_GPIO2B5vccio5
GPIO2-B6: IO_ I2C2scl_GPIO2B6vccio5

This fix has been tested on NanoPi R2S for fixing confliting pinmux bits
between GPIO2-B7 with GPIO2-B5.

Signed-off-by: Huang-Huang Bao &lt;i@eh5.me&gt;
Reviewed-by: Heiko Stuebner &lt;heiko@sntech.de&gt;
Fixes: 3818e4a7678e ("pinctrl: rockchip: Add rk3328 pinctrl support")
Link: https://lore.kernel.org/r/20240606125755.53778-2-i@eh5.me
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>pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER</title>
<updated>2024-07-05T07:33:43+00:00</updated>
<author>
<name>Hagar Hemdan</name>
<email>hagarhem@amazon.com</email>
</author>
<published>2024-06-04T08:58:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4038c57bf61631219b31f1bd6e92106ec7f084dc'/>
<id>urn:sha1:4038c57bf61631219b31f1bd6e92106ec7f084dc</id>
<content type='text'>
[ Upstream commit adec57ff8e66aee632f3dd1f93787c13d112b7a1 ]

In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
a potential deadlock.

This patch resolves the issue by releasing pinctrl_maps_mutex before
calling pinctrl_free(), preventing the deadlock.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.

Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Suggested-by: Maximilian Heyne &lt;mheyne@amazon.de&gt;
Signed-off-by: Hagar Hemdan &lt;hagarhem@amazon.com&gt;
Link: https://lore.kernel.org/r/20240604085838.3344-1-hagarhem@amazon.com
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>pinctrl: qcom: pinctrl-sm7150: Fix sdc1 and ufs special pins regs</title>
<updated>2024-06-12T09:12:24+00:00</updated>
<author>
<name>Danila Tikhonov</name>
<email>danila@jiaxyga.com</email>
</author>
<published>2024-04-23T20:32:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd283810f6ae9ea6220a4b1dd3164b91462a5cee'/>
<id>urn:sha1:cd283810f6ae9ea6220a4b1dd3164b91462a5cee</id>
<content type='text'>
[ Upstream commit 5ed79863fae5c06eb33f5cd6b6bdf22dd7089392 ]

SDC1 and UFS_RESET special pins are located in the west memory bank.

SDC1 have address 0x359a000:
0x3500000 (TLMM BASE) + 0x0 (WEST) + 0x9a000 (SDC1_OFFSET) = 0x359a000

UFS_RESET have address 0x359f000:
0x3500000 (TLMM BASE) + 0x0 (WEST) + 0x9f000 (UFS_OFFSET) = 0x359a000

Fixes: b915395c9e04 ("pinctrl: qcom: Add SM7150 pinctrl driver")
Signed-off-by: Danila Tikhonov &lt;danila@jiaxyga.com&gt;
Message-ID: &lt;20240423203245.188480-1-danila@jiaxyga.com&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>pinctrl: devicetree: fix refcount leak in pinctrl_dt_to_map()</title>
<updated>2024-05-17T10:01:58+00:00</updated>
<author>
<name>Zeng Heng</name>
<email>zengheng4@huawei.com</email>
</author>
<published>2024-04-15T10:53:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=026e24cf31733dbd97f41cc9bc5273ace428eeec'/>
<id>urn:sha1:026e24cf31733dbd97f41cc9bc5273ace428eeec</id>
<content type='text'>
[ Upstream commit a0cedbcc8852d6c77b00634b81e41f17f29d9404 ]

If we fail to allocate propname buffer, we need to drop the reference
count we just took. Because the pinctrl_dt_free_maps() includes the
droping operation, here we call it directly.

Fixes: 91d5c5060ee2 ("pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map")
Suggested-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Signed-off-by: Zeng Heng &lt;zengheng4@huawei.com&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Message-ID: &lt;20240415105328.3651441-1-zengheng4@huawei.com&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>pinctrl: baytrail: Fix selecting gpio pinctrl state</title>
<updated>2024-05-17T10:01:58+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2024-04-07T17:50:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc8cbe3a58a0faa308ef1a55ad43a6617ceb2bb2'/>
<id>urn:sha1:fc8cbe3a58a0faa308ef1a55ad43a6617ceb2bb2</id>
<content type='text'>
[ Upstream commit fed6d9a8e6a60ecf6506d0ea004040fbaa109927 ]

For all the "score" pin-groups all the intel_pingroup-s to select
the non GPIO function are re-used for byt_score_gpio_groups[].

But this is incorrect since a pin-group includes the mode setting,
which for the non GPIO functions generally is 1, where as to select
the GPIO function mode must be set to 0.

So the GPIO function needs separate intel_pingroup-s with their own mode
value of 0.

Add a new PIN_GROUP_GPIO macro which adds a foo_gpio entry to each
pin-group defined this way and update byt_score_gpio_groups[] to point
to the new foo_gpio entries.

The "sus" usb_oc_grp usb_ulpi_grp and pcu_spi_grp pin-groups are special
because these have a non 0 mode value to select the GPIO functions and
these already have matching foo_gpio pin-groups, leave these are unchanged.

The pmu_clk "sus" groups added in commit 2f46d7f7e959 ("pinctrl: baytrail:
Add pinconf group + function for the pmu_clk") do need to use the new
PIN_GROUP_GPIO macro.

Fixes: 2f46d7f7e959 ("pinctrl: baytrail: Add pinconf group + function for the pmu_clk")
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>pinctrl: mediatek: paris: Rework support for PIN_CONFIG_{INPUT,OUTPUT}_ENABLE</title>
<updated>2024-05-17T10:01:57+00:00</updated>
<author>
<name>Chen-Yu Tsai</name>
<email>wenst@chromium.org</email>
</author>
<published>2024-03-27T09:13:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=30287d2018b441c9f4cc6c4dd6cde2cf32cb8bd5'/>
<id>urn:sha1:30287d2018b441c9f4cc6c4dd6cde2cf32cb8bd5</id>
<content type='text'>
[ Upstream commit c5d3b64c568a344e998830e0e94a7c04e372f89b ]

There is a misinterpretation of some of the PIN_CONFIG_* options in this
driver library. PIN_CONFIG_OUTPUT_ENABLE should refer to a buffer or
switch in the output direction of the electrical path. The MediaTek
hardware does not have such a thing. The driver incorrectly maps this
option to the GPIO function's direction.

Likewise, PIN_CONFIG_INPUT_ENABLE should refer to a buffer or switch in
the input direction. The hardware does have such a mechanism, and is
mapped to the IES bit. The driver however sets the direction in addition
to the IES bit, which is incorrect. On readback, the IES bit isn't even
considered.

Ironically, the driver does not support readback for PIN_CONFIG_OUTPUT,
while its readback of PIN_CONFIG_{INPUT,OUTPUT}_ENABLE is what it should
be doing for PIN_CONFIG_OUTPUT.

Rework support for these three options, so that PIN_CONFIG_OUTPUT_ENABLE
is completely removed, PIN_CONFIG_INPUT_ENABLE is only linked to the IES
bit, and PIN_CONFIG_OUTPUT is linked to the GPIO function's direction
and output level.

Fixes: 805250982bb5 ("pinctrl: mediatek: add pinctrl-paris that implements the vendor dt-bindings")
Signed-off-by: Chen-Yu Tsai &lt;wenst@chromium.org&gt;
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Message-ID: &lt;20240327091336.3434141-3-wenst@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>
</feed>
