The Broadcom pinctrl bindings are incomplete for child nodes as they are
missing 'unevaluatedProperties: false' to prevent unknown properties.
Fixing this reveals many warnings including having grandchild nodes in some
cases. Many cases in the examples use 'group' property which is
undocumented and not used by the driver. As the schemas define 'pins', I
assume that is the correct name except for the one case, 6358, using
'groups' which is documented.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231020185203.3941590-2-robh@kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
intel-pinctrl for v6.7-1
* Merge "Drop runtime PM support for Baytrail and Lynxpoint pinctrl" (Raag)
* Small improvements here and there in the Intel pin control drivers (Raag)
* Switch to RAII for locking in the Intel core and Cherry View drivers
* Enable non-ACPI enumeration in the Intel Denverton driver
* Use MODULE_DEVICE_TABLE() instead of MODULE_ALIAS() in a couple of drivers
* Introduce array_size.h and use in in the Intel pin control drivers
The following is an automated git shortlog grouped by driver:
baytrail:
- Replace kernel.h by what is actually being used
- drop runtime PM support
- fix debounce disable case
broxton:
- Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
cherryview:
- reduce scope of PIN_CONFIG_BIAS_HIGH_IMPEDANCE case
- Convert to platform remove callback returning void
- Simplify code with cleanup helpers
- Avoid duplicated I/O
- Replace kernel.h by what is actually being used
denverton:
- Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
- Enable platform device in the absence of ACPI enumeration
intel:
- fetch community only when we need it
- refine intel_config_set_pull() function
- Replace kernel.h by what is actually being used
- Simplify code with cleanup helpers
lynxpoint:
- Replace kernel.h by what is actually being used
- drop runtime PM support
merrifield:
- Replace kernel.h by what is actually being used
moorefield:
- Replace kernel.h by what is actually being used
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Samsung pinctrl drivers changes for v6.7
Few cleanups, improvements (use __counted_by annotation) and finally
switch to dynamic allocation of GPIO numberspace.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
pinctrl: renesas: Updates for v6.7 (take two)
- Add pin groups for the Local Bus State Controller (LBSC) on R-Car
M1A,
- Add support for the RZ/G3S (R9A08G045) SoC,
- Miscellaneous fixes and improvements.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20231009083856.222030-20-u.kleine-koenig@pengutronix.de
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
RZ/G3S supports different drive strength values for different power
sources and pin groups (A, B, C). On each group there could be up to 4
drive strength values per power source. Available power sources are
1v8, 2v5, 3v3. Drive strength values are more fine tuned than what was
previously available on the driver thus the necessity of having
micro-amp support. As drive strength and power source values are linked
together the hardware setup for these was moved at the end of
rzg2l_pinctrl_pinconf_set() to ensure proper validation of the new
values.
The drive strength values are expected to be initialized though the
SoC-specific hardware configuration data structure.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230929053915.1530607-19-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
On RZ/G3S PFC register allow setting 8 functions for individual ports
(function1 to function8). For function1 the register need to be
configured with 0, for function8 the register need to be configured with
7. We cannot use zero based addressing when requesting functions from
different code places as the documentation
(RZG3S_pinfunction_List_r1.0.xlsx) states explicitly that function0 is
GPIO.
Add a new member to struct rzg2l_hwcfg that will keep the offset that
needs to be substracted before applying a value to a PFC register.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230929053915.1530607-17-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
To get the address that needs to be read/written for specific port
functionalities, the P(), PM(), PMC(), PFC(), PIN(), IOLH() IEN(),
ISEL() macros are used. Some of these macros receive as argument the
hardware port identifier, some the hardware port offset address (e.g.
ISEL() received port identifier, IOLH() received port offset address).
This makes it hard to extend the current driver for SoCs where port
identifiers are not contiguous in the memory map of the pin controller.
This is the case for the RZ/G3S pin controller where ports are mapped as
follows:
port offset port identifier
----------- ---------------
0x20 P0
0x21 P5
0x22 P6
0x23 P11
0x24 P12
0x25 P13
0x26 P14
0x27 P15
0x28 P16
0x29 P17
0x2a P18
0x30 P1
0x31 P2
0x32 P3
0x33 P4
0x34 P7
0x35 P8
0x36 P8
0x37 P10
To make this achievable, change all the above macros used to get the
address of a port register for a specific port functionality based on
the port hardware address. Summarized, all the above macros will get as
argument the port offset address listed in the above table.
With this RZG2L_SINGLE_PIN_GET_PORT_OFFSET(),
RZG2L_PIN_ID_TO_PORT_OFFSET() and RZG2L_GPIO_PORT_GET_INDEX() were
replaced by RZG2L_PIN_CFG_TO_PORT_OFFSET(); RZG2L_SINGLE_PIN_GET_CFGS()
and RZG2L_GPIO_PORT_GET_CFGS() were replaced by RZG2L_PIN_CFG_TO_CAPS().
Also rzg2l_pinctrl_set_pfc_mode() does not need the port argument
anymore. Also rzg2l_gpio_direction_input() and
rzg2l_gpio_direction_output() do not need to translate port and bit
locally as this can be done by rzg2l_gpio_set_direction().
To use the same naming for port, bit/pin, and register offset, replace
the port_offset variable names in different places by variables named
off. There is no longer a need to initialize cfg and bit in different
code places.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20230929053915.1530607-15-claudiu.beznea@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
We have a couple of pinconfig cases inside the braces which are meant for
PIN_CONFIG_BIAS_HIGH_IMPEDANCE case. Although it is valid C, it makes the
code less readable and prone to misinterpretation. Limit the braces to
PIN_CONFIG_BIAS_HIGH_IMPEDANCE case to avoid this.
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
To convert the sprd-sc9860 driver, make sprd_pinctrl_remove()
return void (instead of zero) and use .remove_new as callback.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009162510.335208-4-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
To convert all those qcom pinctrl drivers, make msm_pinctrl_remove()
return void (instead of zero) and use .remove_new in all drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009162510.335208-3-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
To convert all those qcom pinctrl drivers, make msm_pinctrl_remove()
return void (instead of zero) and use .remove_new in all drivers.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009162510.335208-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-21-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-19-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-18-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-17-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-16-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-15-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-14-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-13-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20231009083856.222030-12-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-11-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Link: https://lore.kernel.org/r/20231009083856.222030-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20231009083856.222030-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The driver core has no handling for errors returned by the .remove()
callback. The only action on error is a dev_warn() with generic error
message that the returned value is returned.
Replace it by a more specific and useful message. Then returning zero is
the right thing to do, the only effect is to suppress the core's
warning.
This prepares the driver for the conversion to .remove_new().
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231009083856.222030-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
make CHECK_DTBS=y st/stm32f469-disco.dtb
brings up a warning about a missing argument:
stm32f469-disco.dtb: pinctrl@40020000: st,syscfg:0: [21, 8] is too short
The description of the third entry indicates that this entry is optional.
The code in stm32_pctrl_dt_setup_irq parses st,syscfg and treats the third
entry as optional. It defaults to 0xf if not present in the devicetree.
Update the schema to require at least two entries, use the same syntax as
the description of renesas,ipmmu-main in
Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231006082247.3830719-1-martin@kaiser.cx
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some platforms unfortunately have their SPI mode selection bits
strapped incorrectly (such as being configured for passthrough mode
when master mode is in fact the only useful configuration for it) and
thus require correction in software. Add the SPI mode bits to the
GPIO passthrough bits as the exceptions to the read-only rule for the
hardware strap register so that the pinctrl subsystem can be used for
such corrections.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Link: https://lore.kernel.org/r/20231005030849.11352-2-zev@bewilderbeest.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The 'fsl,mxs-gpio' property is not documented in gpio-mxs.yaml, but
the imx23 and imx28 dtsi describe the gpios as:
compatible = "fsl,imx28-gpio", "fsl,mxs-gpio";
This gives schema warnings like:
imx28-cfa10037.dtb: pinctrl@80018000: gpio@0:compatible: ['fsl,imx28-gpio', 'fsl,mxs-gpio'] is too long
from schema $id: http://devicetree.org/schemas/gpio/gpio-mxs.yaml#
"fsl,mxs-gpio" is only used inside pinctrl-mxs, but can be removed if
the compatible check is done against fsl,imx23-gpio and fsl,imx28-gpio.
Introduce is_mxs_gpio() and remove the need for "fsl,mxs-gpio".
Tested on a imx28-evk.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20230928134321.438547-1-festevam@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Past versions of this driver have manually calculated base values for
both the pinctrl numberspace and the global GPIO numberspace, giving
both the same values. This was necessary for the global GPIO
numberspace, since its values need to be unique system-wide. However, it
was not necessary for the pinctrl numberspace, since its values only
need to be unique for a single instance of the pinctrl device. It was
just convenient to use the same values for both spaces.
Right now those calculations are only used for the pinctrl numberspace,
since GPIO numberspace bases are selected by the GPIO subsystem.
Therefore, those calculations are unnecessary.
Signed-off-by: Mateusz Majewski <m.majewski2@samsung.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Sam Protsenko <semen.protsenko@linaro.org>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20231006125557.212681-5-m.majewski2@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
