Convert the driver to immutable irq-chip with a bit of
intuition.
I switched to consistently using irqd_to_hwirq() consistently
while we are at it.
As the driver now needs to get the gpio_chip in the .irq_mask
and .irq_unmask callbacks, I switched to a pattern where we
first fetch the gpio_chip and then the state container from
that in two steps. The compiler will do the same thing anyway.
Convert the driver to immutable irq-chip with a bit of
intuition.
I switched to using irqd_to_hwirq() consistently while we
are at it.
This driver does not use the GPIOCHIP_IRQ_RESOURCE_HELPERS
as it defines its own resource reservations, simply in
order to turn IRQ lines into inputs on initialization.
Also switched the open coded calls to gpiochip_lock_as_irq()
to gpiochip_reqres_irq() so we also get the right module
reference counting.
Convert the driver to immutable irq-chip with a bit of
intuition.
I refactored the way the state container was accessed in
the irq_chip callbacks to all look the same and switch to
use irqd_to_hwirq() while we are at it.
Merge tag 'qcom-pinctrl-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt into devel
Qualcomm pinctrl Devicetree bindings changes for v6.4
Cleanup and improvement of the bindings to use "unevaluatedProperties"
instead of "additionalProperties", which allows to accept all the
properties already parsed by referenced common qcom,tlmm-common.yaml
schema.
That common qcom,tlmm-common.yaml binding is going to remove
"input-enable" property, thus using "unevaluatedProperties" allows such
change to propagate to other bindings automatically.
dt-bindings: pinctrl: qcom,sm8550-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm8450-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm8350-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm8250: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm8150: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm6375-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm6350-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm6125-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sm6115-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sdx65-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sdx55: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sdm845: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
This also fixes warnings like:
sdm845-cheza-r1.dtb: pinctrl@3400000: qspi-sleep-state: 'oneOf' conditional failed, one must be fixed:
'output-disable' does not match any of the regexes: 'pinctrl-[0-9]+'
dt-bindings: pinctrl: qcom,sdm670-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sdm630: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sc8180x-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,sc7280-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
This also fixes warnings like:
sc7280-herobrine-evoker.dtb: pinctrl@f100000: qspi-sleep-state: 'oneOf' conditional failed, one must be fixed:
'output-disable' does not match any of the regexes: 'pinctrl-[0-9]+'
dt-bindings: pinctrl: qcom,sc7180-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
This also fixes warnings like:
c7180-trogdor-coachz-r1.dtb: pinctrl@3500000: qspi-sleep-state: 'oneOf' conditional failed, one must be fixed:
'output-disable' does not match any of the regexes: 'pinctrl-[0-9]+'
dt-bindings: pinctrl: qcom,sa8775p-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,qdu1000-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,qcs404: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8998: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8996: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8994: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8976: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8974: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8960: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8953: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8916: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8909-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8660: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,msm8226: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,mdm9615: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,mdm9607-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,ipq8074: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,ipq6018: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
dt-bindings: pinctrl: qcom,ipq5332-tlmm: simplify with unevaluatedProperties
All Qualcomm SoC Top Level Mode Multiplexer pin controllers have similar
capabilities regarding pin properties, thus we can just accept entire
set provided by qcom,tlmm-common.yaml schema.
Merge tag 'renesas-pinctrl-for-v6.4-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel
pinctrl: renesas: Updates for v6.4 (take two)
- Retain POCCTRL0 register across s2ram on R-Car D3,
- Add support for Ethernet power-sources on R-Car V3M, V3H, E3, D3,
and V4H,
- Annotate sentinels in tables,
- Add bias pinconf support and PWM pin groups on R-Car H1,
- Miscellaneous fixes and improvements.
dt-bindings: pinctrl: mediatek: deprecate custom bias pull properties for mt8365
In order to be more generic, "mediatek,pull-up-adv" and
"mediatek,pull-down-adv" should be deprecated. Use "bias-pull-up" and
"bias-pull-down" instead.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230327-cleanup-pinctrl-binding-v3-2-6f56d5c7a8de@baylibre.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Deprecate mediatek,drive-strength-adv which shall not exist, that was an
unnecessary property that leaked upstream from downstream kernels and
there's no reason to use it.
The generic property drive-strength-microamp should be used instead.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230327-cleanup-pinctrl-binding-v3-1-6f56d5c7a8de@baylibre.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
dt-bindings: pinctrl: xway: drop the deprecated compatible strings
This code are marked as deprecated since kernel 4.5[1]. Downstream OpenWRT
and upstream switched to the new string compatible 7 years ago. The old
compatible strings can safely be dropped.
[1] commit be14811c03cf ("pinctrl/lantiq: introduce new dedicated devicetree bindings")
pinctrl: xway: drop the deprecated compatible strings
This code are marked as deprecated since kernel 4.5[1]. Downstream OpenWRT
and upstream switched to the new string compatible 7 years ago. The old
compatible strings can safely be dropped.
[1] commit be14811c03cf ("pinctrl/lantiq: introduce new dedicated devicetree bindings")
pinctrl: amd: Add fields for interrupt status and wake status
If the firmware has misconfigured a GPIO it may cause interrupt
status or wake status bits to be set and not asserted. Add these
to debug output to catch this case.
pinctrl: renesas: core: Drop unneeded #ifdef CONFIG_OF
As the of_node member of struct device always exists, and there is a
dummy of of_device_get_match_data() for the !CONFIG_OF case, there is no
longer a need to protect code using these interfaces with an #ifdef.
pinctrl: renesas: r8a779g0: Add support for AVB/TSN power-sources
Add support for configuring the I/O voltage levels of the Ethernet AVB
and Ethernet TSN pins on the R-Car V4H SoC. "PIN_VDDQ_AVB[012]" and
"PIN_VDDQ_TSN0" can be configured for 1.8V or 2.5V operation.
pinctrl: renesas: r8a77995: Add support for AVB power-source
Add support for configuring the I/O voltage level of the Ethernet AVB
pins on the R-Car D3 SoC. "PIN_VDDQ_AVB0" can be configured for 2.5V or
3.3V operation.
pinctrl: renesas: r8a77990: Add support for AVB power-source
Add support for configuring the I/O voltage level of the Ethernet AVB
pins on the R-Car E3 SoC. "PIN_VDDQ_AVB0" can be configured for 2.5V or
3.3V operation.
pinctrl: renesas: r8a77980: Add support for AVB/GE power-sources
Add support for configuring the I/O voltage levels of the Ethernet AVB
and Gigabit Ethernet pins on the R-Car V3H SoC. "PIN_VDDQ_AVB" and
"PIN_VDDQ_GE" can be configured for 2.5V or 3.3V operation.
pinctrl: renesas: r8a77970: Add support for AVB power-source
Add support for configuring the I/O voltage level of the Ethernet AVB
pins on the R-Car V3M SoC. "PIN_VDDQ_AVB0" can be configured for 2.5V
or 3.3V operation.
pinctrl: renesas: Add support for 1.8V/2.5V I/O voltage levels
Currently, the Renesas pin control driver supports pins that can switch
their I/O voltage levels between either 1.8V and 3.3V, or between 2.5V
and 3.3V. However, some SoCs have pins that can switch between 1.8V and
2.5V.
Add support for this by replacing the separate SH_PFC_PIN_CFG_IO_VOLTAGE
capability and voltage level flags by a 2-bit field, to cover three
possible I/O voltage switching options.
pinctrl: renesas: rcar: Phase out old SH_PFC_PIN_CFG_IO_VOLTAGE flag
Commit 537db25ca330dce0 ("pinctrl: renesas: Add I/O voltage level
flag") introduced new flags to support pins that can switch their
voltage levels between either 1.8V and 3.3V, or between 2.5V and 3.3V.
The old SH_PFC_PIN_CFG_IO_VOLTAGE flag was retained to avoid having to
change existing drivers.
Replace SH_PFC_PIN_CFG_IO_VOLTAGE by SH_PFC_PIN_CFG_IO_VOLTAGE_18_33, to
make the voltage configuration explicit, and to prepare for the advent
of support for more voltage levels.
pinctrl: renesas: r8a77995: Retain POCCTRL0 register across suspend/resume
The POC Control Register 0 (POCCTRL0) on R-Car D3 is not registered in
the pinmux_ioctrl_regs[] array. Hence it is not saved/restored during
suspend/resume, and its contents may be lost after s2ram.
This went unnoticed when improving suspend/resume support in commit d92ee9cf8ec8d7fe ("pinctrl: sh-pfc: rcar-gen3: Retain TDSELCTRL register
across suspend/resume").
Fix this by moving the pinmux_ioctrl_regs[] array up, and adding the
POCCTRL0 register.
Douglas Anderson [Thu, 23 Mar 2023 17:30:12 +0000 (10:30 -0700)]
pinctrl: qcom: Support OUTPUT_ENABLE; deprecate INPUT_ENABLE
The Qualcomm pinctrl driver has been violating the documented meaning
of PIN_CONFIG_INPUT_ENABLE. That documentation says:
Note that this does not affect the pin's ability to drive output.
...yet the Qualcomm driver's sole action when asked to "enable input"
on a pin is to disable its output.
The Qualcomm driver's implementation stems from the fact that
"output-disable" is a "new" property from 2017. It was introduced in
commit 425562429d4f ("pinctrl: generic: Add output-enable
property"). The "input-enable" handling in Qualcomm drivers is from
2015 introduced in commit 407f5e392f9c ("pinctrl: qcom: handle
input-enable pinconf property").
Let's change the Qualcomm driver to move us in the right direction. As
part of this:
1. We'll now support PIN_CONFIG_OUTPUT_ENABLE
2. We'll still support using PIN_CONFIG_INPUT_ENABLE to disable a
pin's output (in violation of the docs) with a big comment in the
code. This is needed because old device trees have "input-enable"
in them and, in some cases, people might need the old
behavior. While we could programmatically change all old device
trees, it doesn't really hurt to keep supporting the old behavior
and we're _supposed_ to try to be compatible with old device trees
anyway.
It can also be noted that the PIN_CONFIG_INPUT_ENABLE handling code
seems to have purposefully ignored its argument. That means that old
boards that had _either_ "input-disable" or "input-enable" in them
would have had the effect of disabling a pin's output. While we could
change this behavior, since we're only leaving the
PIN_CONFIG_INPUT_ENABLE there for backward compatibility we might as
well be fully backward compatible.
NOTE: despite the fact that we'll still support
PIN_CONFIG_INPUT_ENABLE for _setting_ config, we take it away from
msm_config_group_get(). This appears to be only used for populating
debugfs and fixing debugfs to "output enabled" where relevant instead
of "input enabled" makes more sense and has more truthiness.
Douglas Anderson [Thu, 23 Mar 2023 17:30:11 +0000 (10:30 -0700)]
dt-bindings: pinctrl: qcom: Add output-enable
In the patch ("dt-bindings: pinctrl: qcom: tlmm should use
output-disable, not input-enable") we allowed setting "output-disable"
for TLMM pinctrl states. Let's also add "output-enable".
At first blush this seems a needless thing to do. Specifically:
- In Linux (and presumably any other OSes using the same device trees)
the GPIO/pinctrl driver knows to automatically enable the output
when a GPIO is changed to an output. Thus in most cases specifying
"output-enable" is superfluous and should be avoided.
- If we need to set a pin's default state we already have
"output-high" and "output-low" and these properties already imply
"output-enabled" (at least on the Linux Qualcomm TLMM driver).
However, there is one instance where "output-enable" seems like it
could be useful: sleep states. It's not uncommon to want to configure
pins as inputs (with appropriate pulls) when the driver controlling
them is in a low power state. Then we want the pins back to outputs
when the driver wants things running normally. To accomplish this we'd
want to be able to use "output-enable". Then the "default" state could
have "output-enable" and the "sleep" state could have
"output-disable".
NOTE: in all instances I'm aware of, we'd only want to use
"output-enable" on pins that are configured as "gpio". The Qualcomm
documentation that I have access to says that "output-enable" only
does something useful when in GPIO mode.
Douglas Anderson [Thu, 23 Mar 2023 17:30:10 +0000 (10:30 -0700)]
dt-bindings: pinctrl: qcom: tlmm should use output-disable, not input-enable
As evidenced by the Qualcomm TLMM Linux driver, the TLMM IP block in
Qualcomm SoCs has a bit to enable/disable the output for a pin that's
configured as a GPIO but _not_ a bit to enable/disable an input
buffer. Current device trees that are specifying "input-enable" for
pins managed by TLMM are either doing so needlessly or are using it to
mean "output-disable".
Presumably the current convention of using "input-enable" to mean
"output-disable" stems from the fact that "output-disable" is a "new"
property from 2017. It was introduced in commit 425562429d4f
("pinctrl: generic: Add output-enable property"). The "input-enable"
handling in Qualcomm drivers is from 2015 introduced in commit 407f5e392f9c ("pinctrl: qcom: handle input-enable pinconf property").
Given that there's no other use for "input-enable" for TLMM, we can
still handle old device trees in code, but let's encourage people to
move to the proper / documented property by updating the bindings.
Chester Lin [Mon, 27 Mar 2023 06:27:50 +0000 (14:27 +0800)]
pinctrl: s32: refine error/return/config checks and simplify driver codes
Improve error/return code handlings and config checks in order to have
better reliability and simplify driver codes such as removing/changing
improper macros, blanks, print formats and helper calls.
Rob Herring [Fri, 10 Mar 2023 14:47:20 +0000 (08:47 -0600)]
pinctrl: Use of_property_present() for testing DT property presence
It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.
Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230310144721.1544669-1-robh@kernel.org
[Dropped hunk hitting drivers/pinctrl/renesas/pinctrl.c] Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Arınç ÜNAL [Fri, 17 Mar 2023 21:30:11 +0000 (00:30 +0300)]
MAINTAINERS: move ralink pinctrl to mediatek mips pinctrl
The Ralink pinctrl driver is now under the name of MediaTek MIPS pin
controller. Move the maintainer information accordingly. Add dt-binding
schema files. Add linux-mediatek@lists.infradead.org as an associated
mailing list.
The MT7628 and MT7688 SoCs contain different pin muxing information,
therefore, should be split. This can be done now that there are compatible
strings to distinguish them from other SoCs.
Split the schema out to mediatek,mt76x8-pinctrl.yaml.
The RT3352 and RT5350 SoCs each contain different pin muxing information,
therefore, should be split. This can be done now that there are compatible
strings to distinguish them from other SoCs.
Split the schema out to ralink,rt3352-pinctrl.yaml and
ralink,rt5350-pinctrl.yaml.
Remove ralink,rt3352-pinctrl and ralink,rt5350-pinctrl from rt305x.