Commit 6c846d026d ("gpio: Don't fiddle with irqchips marked as
immutable") added a warning to indicate if the gpiolib is altering the
internals of irqchips. Following this change the following warning is
now observed for the max77620 gpio driver ...
WARNING KERN gpio gpiochip0: (max77620-gpio): not an immutable chip,
please consider fixing it!
Fix the above warning by making the max77620 gpio driver immutable.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Add support for pca6408 which is the 8-bit version of the pca6416.
https://www.nxp.com/docs/en/data-sheet/PCA6408A.pdf
Signed-off-by: Justin Chen <justinpopo6@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The fwnode of GPIO IRQ must be set to its own fwnode, not the fwnode of the
parent IRQ. Therefore, this sets own fwnode instead of the parent IRQ fwnode to
GPIO IRQ's.
Fixes: 2ad74f40da ("gpio: visconti: Add Toshiba Visconti GPIO support")
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The only user of max732x_platform_data is arch/arm/mach-pxa/littleton.c
and it only uses .gpio_base. So drop the other members from the data struct
and simplify the driver accordingly.
The motivating side effect of this change is that the .remove() callback
cannot return a nonzero error code any more which prepares making i2c
remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
This patch adds new clock type for the GPIO controller which can
timestamp gpio lines in using hardware means. To expose such
functionalities to the userspace, code has been added where
during line create or set config API calls, it checks for new
clock type and if requested, calls HTE API. During line change
event, the HTE subsystem pushes timestamp data to userspace
through gpiolib-cdev.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra194 AON GPIO controller with the use of its internal hardware
timestamping engine (HTE), also known as GTE, can timestamp GPIO lines
through system counter. This patch implements enable/disable callbacks
for the GPIO controller. In enable call, it will set timestamp function
bit and GPIO line rising/falling edges in the config register. In
disable call, it restores the state.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some GPIO chip can provide hardware timestamp support on its GPIO lines
, in order to support that, additional API needs to be added which
can talk to both GPIO chip and HTE (hardware timestamping engine)
providers if there is any dependencies. This patch introduces optional
hooks to enable and disable hardware timestamping related features
in the GPIO controller chip.
Signed-off-by: Dipen Patel <dipenp@nvidia.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
i.MX7ULP, i.MX8 and i.MX9 use this driver, so drop
the SOC_VF610 dependcy to make the driver could be built
for i.MX platform.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
* Introduce helpers to iterate over GPIO chip nodes and covert some drivers
The following is an automated git shortlog grouped by driver:
gpiolib:
- Introduce a helper to get first GPIO controller node
- Introduce gpiochip_node_count() helper
- Introduce for_each_gpiochip_node() loop helper
pinctrl:
- meson: Replace custom code by gpiochip_node_count() call
- meson: Enable COMPILE_TEST
- meson: Rename REG_* to MESON_REG_*
- armada-37xx: Reuse GPIO fwnode in armada_37xx_irqchip_register()
- armada-37xx: Switch to use fwnode instead of of_node
- samsung: Switch to use for_each_gpiochip_node() helper
- samsung: Drop redundant node parameter in samsung_banks_of_node_get()
- npcm7xx: Switch to use for_each_gpiochip_node() helper
- renesas: rza1: Switch to use for_each_gpiochip_node() helper
- renesas: rza1: Replace custom code by gpiochip_node_count() call
- stm32: Switch to use for_each_gpiochip_node() helper
- stm32: Replace custom code by gpiochip_node_count() call
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSu93Raj3rZDNXzGZv7cr9lmVa5zAUCYmwsmgAKCRD7cr9lmVa5
zEYPAP4q31AbTJHk6Fs1A79esVSo+DZSkZSzbk/n8Vr3oYG56gD/dVu5EmLNKPHU
6o5+BvdXqjHrymihHasdyD9YqI30zwM=
=MIEU
-----END PGP SIGNATURE-----
Merge tag 'intel-gpio-v5.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-next
intel-gpio for v5.19-1
* Introduce helpers to iterate over GPIO chip nodes and covert some drivers
gpiolib:
- Introduce a helper to get first GPIO controller node
- Introduce gpiochip_node_count() helper
- Introduce for_each_gpiochip_node() loop helper
pinctrl:
- meson: Replace custom code by gpiochip_node_count() call
- meson: Enable COMPILE_TEST
- meson: Rename REG_* to MESON_REG_*
- armada-37xx: Reuse GPIO fwnode in armada_37xx_irqchip_register()
- armada-37xx: Switch to use fwnode instead of of_node
- samsung: Switch to use for_each_gpiochip_node() helper
- samsung: Drop redundant node parameter in samsung_banks_of_node_get()
- npcm7xx: Switch to use for_each_gpiochip_node() helper
- renesas: rza1: Switch to use for_each_gpiochip_node() helper
- renesas: rza1: Replace custom code by gpiochip_node_count() call
- stm32: Switch to use for_each_gpiochip_node() helper
- stm32: Replace custom code by gpiochip_node_count() call
pwmchip_add() unconditionally assigns the base ID dynamically. Commit
f9a8ee8c8b ("pwm: Always allocate PWM chip base ID dynamically")
dropped all base assignment from drivers under drivers/pwm/. It missed
this driver. Fix that.
Fixes: f9a8ee8c8b ("pwm: Always allocate PWM chip base ID dynamically")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Gpiolib interprets the elements of "gpio-reserved-ranges" as "start,size"
because it clears "size" bits starting from the "start" bit in the according
bitmap. So it has to use "greater" instead of "greater or equal" when performs
bounds check to make sure that GPIOs are in the available range.
Previous implementation skipped ranges that include the last GPIO in
the range.
I wrote the mail to the maintainers
(https://lore.kernel.org/linux-gpio/20220412115554.159435-1-andrei.lalaev@emlid.com/T/#u)
of the questioned DTSes (because I couldn't understand how the maintainers
interpreted this property), but I haven't received a response.
Since the questioned DTSes use "gpio-reserved-ranges = <0 4>"
(i.e., the beginning of the range), this patch doesn't affect these DTSes at all.
TBH this patch doesn't break any existing DTSes because none of them
reserve gpios at the end of range.
Fixes: 726cb3ba49 ("gpiolib: Support 'gpio-reserved-ranges' property")
Signed-off-by: Andrei Lalaev <andrei.lalaev@emlid.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Since version 5.13, the standard syscon bindings have been added
to all clps711x DT nodes, so we can now use the more general
syscon_regmap_lookup_by_phandle function to get the syscon pointer.
This patch removes the usage of the syscon_regmap_lookup_by_compatible
function as it is no longer used in the driver.
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmJu9FYeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGAyEH/16xtJSpLmLwrQzG
o+4ToQxSQ+/9UHyu0RTEvHg2THm9/8emtIuYyc/5FgdoWctcSa3AaDcveWmuWmkS
KYcdhfJsaEqjNHS3OPYXN84fmo9Hel7263shu5+IYmP/sN0DfQp6UWTryX1q4B3Q
4Pdutkuq63Uwd8nBZ5LXQBumaBrmkkuMgWEdT4+6FOo1mPzwdIGBxCuz1UsNNl5k
chLWxkQfe2eqgWbYJrgCQfrVdORXVtoU2fGilZUNrHRVGkkldXkkz5clJfapyZD3
odmZCEbrE4GPKgZwCmDERMfD1hzhZDtYKiHfOQ506szH5ykJjPBcOjHed7dA60eB
J3+wdek=
=39Ca
-----END PGP SIGNATURE-----
Merge tag 'v5.18-rc5' into devel
Merge in Linux 5.18-rc5 since new code to the STM32 driver
depend in a non-trivial way on the fixes merged in -rc5.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
All teardown functions return 0. Also there is little sense in returning
a negative error code from an i2c remove function as this only results in
emitting an error message but the device is removed nevertheless.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The boardfiles for IXP4xx have been deleted. Delete all the
quirks and code dealing with that boot path and rely solely on
device tree boot.
Fix some missing static keywords that the kernel test robot
was complaining about while we're at it.
Cc: Bartosz Golaszewski <brgl@bgdev.pl>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Commit 5467801f1f ("gpio: Restrict usage of GPIO chip irq members
before initialization") attempted to fix a race condition that lead to a
NULL pointer, but in the process caused a regression for _AEI/_EVT
declared GPIOs.
This manifests in messages showing deferred probing while trying to
allocate IRQs like so:
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517
[ .. more of the same .. ]
The code for walking _AEI doesn't handle deferred probing and so this
leads to non-functional GPIO interrupts.
Fix this issue by moving the call to `acpi_gpiochip_request_interrupts`
to occur after gc->irc.initialized is set.
Fixes: 5467801f1f ("gpio: Restrict usage of GPIO chip irq members before initialization")
Link: https://lore.kernel.org/linux-gpio/BL1PR12MB51577A77F000A008AA694675E2EF9@BL1PR12MB5157.namprd12.prod.outlook.com/
Link: https://bugzilla.suse.com/show_bug.cgi?id=1198697
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215850
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1979
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1976
Reported-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Shreeya Patel <shreeya.patel@collabora.com>
Tested-By: Samuel Čavoj <samuel@cavoj.net>
Tested-By: lukeluk498@gmail.com Link:
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-and-tested-by: Takashi Iwai <tiwai@suse.de>
Cc: Shreeya Patel <shreeya.patel@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add support for deferring other params like PIN_CONFIG_INPUT_ENABLE.
This will be used to add support for PIN_CONFIG_INPUT_ENABLE to the
driver.
Fixes: e7165b1dff ("pinctrl/rockchip: add a queue for deferred pin output settings on probe")
Fixes: 59dd178e1d ("gpio/rockchip: fetch deferred output settings on probe")
Signed-off-by: Caleb Connolly <kc@postmarketos.org>
Link: https://lore.kernel.org/r/20220328005005.72492-2-kc@postmarketos.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit 2ab73c6d83 ("gpio: Support GPIO controllers without pin-ranges")
the device tree nodes of GPIO controller need the gpio-ranges property to
handle gpio-hogs. Unfortunately it's impossible to guarantee that every new
kernel is shipped with an updated device tree binary.
In order to provide backward compatibility with those older DTB, we need a
callback within of_gpiochip_add_pin_range() so the relevant platform driver
can handle this case.
Fixes: 2ab73c6d83 ("gpio: Support GPIO controllers without pin-ranges")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Bartosz Golaszewski <brgl@bgdev.pl>
Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* irq/gpio-immutable:
: .
: First try at preventing the GPIO subsystem from abusing irq_chip
: data structures. The general idea is to have an irq_chip flag
: to tell the GPIO subsystem that these structures are immutable,
: and to convert drivers one by one.
: .
Documentation: Update the recommended pattern for GPIO irqchips
gpio: Update TODO to mention immutable irq_chip structures
pinctrl: amd: Make the irqchip immutable
pinctrl: msmgpio: Make the irqchip immutable
pinctrl: apple-gpio: Make the irqchip immutable
gpio: pl061: Make the irqchip immutable
gpio: tegra186: Make the irqchip immutable
gpio: Add helpers to ease the transition towards immutable irq_chip
gpio: Expose the gpiochip_irq_re[ql]res helpers
gpio: Don't fiddle with irqchips marked as immutable
Signed-off-by: Marc Zyngier <maz@kernel.org>
5 drivers are converted, a few hundred to go. Definitely worth of
a TODO entry, in the hope that someone will notice it and do
a bulk update.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220419141846.598305-10-maz@kernel.org
Prevent gpiolib from messing with the irqchip by advertising
the irq_chip structure as immutable, making it const, and adding
the various calls that gpiolib relies upon.
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220419141846.598305-6-maz@kernel.org
Prevent gpiolib from messing with the irqchip by advertising
the irq_chip structure as immutable, making it const, and adding
the various calls that gpiolib relies upon.
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220419141846.598305-5-maz@kernel.org
The GPIO subsystem has a couple of internal helpers to manage
resources on behalf of the irqchip. Expose them so that GPIO
drivers can use them directly.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220419141846.598305-3-maz@kernel.org
In order to move away from gpiolib messing with the internals of
unsuspecting irqchips, add a flag by which irqchips advertise
that they are not to be messed with, and do solemnly swear that
they correctly call into the gpiolib helpers when required.
Also nudge the users into converting their drivers to the
new model.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220419141846.598305-2-maz@kernel.org
There are some special clock amendments for two machines
formerly detected by their machine_is() boardfile macro.
They are now migrated to device tree so use
of_machine_is_compatible() instead.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
* Couple of fixes related to handling unsigned value of the pin from ACPI
The following is an automated git shortlog grouped by driver:
gpiolib:
- acpi: Convert type for pin to be unsigned
- acpi: use correct format characters
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAmJUN7cACgkQb7wzTHR8
rCjeMQ/+KZHhBgPHE2Rl928bI/IQYuhcGjFmsLUt/KRFFsjVpzFQro9QI0IFRava
/8j6cUy8mTV6v5cxScljusS7++j8K3C6kazsXr2ieGPKpaGDHtKs93QjbC52jF/T
x/CI7NbnkvJHPWmpIYSuc/vGHHCHAAsnI62OHAIyEARRYBbd5VAkyrvnchH2skaK
bHH0+1La4l2fBkmfA6fpnwLVnRNXEeRTUdQdGk/14Snv1zGNeciGR2/wbg0YtEtf
CvEPi9U7d7RJCjBiege9kcb8R4ABOngypL1C9r7XvtFy17glxkc+6nrJx3NgW3bY
Eksi4naML2oe4R/PyZ740wztJCUKdR6oV/OmyRz5FhTA4+ZWRz3pL3o2Rv+DTZ5g
AcugQZCMe8mNGerFLPxBHpD1s0eD5Gxrnq7CeEpQ0wpBqBj90iZPAvE2mMTghqjH
Vm9OsLX/X8/vAPLeMLgHy9tDwl5FRqkM7BxV3qBp14MBpPfzDmQc3VS5SGcw/car
eZI7mQH85iSpnYjkqfDAwQtr3Jbxt8OuEnADWPiJknuTwGigQm9MLh37cW9xih0r
BQWsHMO9ephWhDSwpKVl+7fbQpIUd2TQFFBOnzIW69ALevD16FkEdnn08HEI2Kd6
mEB60/aA04PNyS6EtbD4ZbCNDjdB3S7EITPPrVPeGycD2JAp5sA=
=i+RD
-----END PGP SIGNATURE-----
Merge tag 'intel-gpio-v5.18-2' of gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-current
intel-gpio for v5.18-2
* Couple of fixes related to handling unsigned value of the pin from ACPI
gpiolib:
- acpi: Convert type for pin to be unsigned
- acpi: use correct format characters
We need to take mask into account in the set/get_multiple() callbacks.
Use bitmap_replace() instead of bitmap_copy().
Fixes: cb8c474e79 ("gpio: sim: new testing module")
Cc: stable@vger.kernel.org
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The RTL931x SoC series has support for 32 GPIOs, although not all lines
may be broken out to a physical pad.
The GPIO bank's parent interrupt can be routed to either or both of the
SoC's CPU cores by the GIC. Line-by-line IRQ balancing is not possible
on these SoCs.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The RTL930x SoC series has support for 24 GPIOs, with the port order
reversed compared to RTL838x and RTL839x. The RTL930x series also has
two CPUs (VPEs) and can distribute individual GPIO interrupts between
them.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
On SoCs with multiple cores, it is possible that the GPIO interrupt
controller supports assigning specific pins to one or more cores.
IRQ balancing can be performed on a line-by-line basis if the parent
interrupt is routed to all available cores, which is the default upon
initialisation.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The GPIO port layout on the RTL930x SoC series is reversed compared to
the RTL838x and RTL839x SoC series. Add new port offset calculator
functions to ensure the correct order is used when reading port IRQ
data, and ensure bgpio uses the right byte ordering.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
In couple of cases we are using the same code to wrap ->get() callback.
Extract that code into a helper for the sake of better maintenance.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Use for_each_gpio_desc() and since we would need to touch the entire
conditionals, do the following:
- rename last occurrence of gdesc to desc
- use short ternary operator ?:
- join two seq_printf() calls into single one
- fix indentation of the seq_printf() parameters
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
In some cases we want to traverse all GPIO descriptors for given
chip, let's split out for_each_gpio_desc() macro for such cases.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The iterator loop is used exclusively to get a descriptor, which in its
turn is what is being used by the caller. Embed the iterator variable
into the loop in the for_each_gpio_desc_with_flag() macro helper.
Suggested-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
An error path is a slow path, no need to block other CPUs
when printing error messages.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
A pin that comes from ACPI tables is of unsigned type. This also applies
to the internal APIs which use unsigned int to store the pin. Convert
type for pin to be unsigned in the places where it's not yet true.
While at it, add a stub for acpi_get_and_request_gpiod() for the sake
of consistency in the APIs.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
When compiling with -Wformat, clang emits the following warning:
gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat]
pin);
^~~
So warning that '%hhX' is paired with an 'int' is all just completely
mindless and wrong. Sadly, I can see a different bogus warning reason
why people would want to use '%02hhX'.
Again, the *sane* thing from a human perspective is to use '%02X. But
if the compiler doesn't do any range analysis at all, it could decide
that "Oh, that print format could need up to 8 bytes of space in the
result". Using '%02hhX' would cut that down to two.
And since we use
char ev_name[5];
and currently use "_%c%02hhX" as the format string, even a compiler
that doesn't notice that "pin <= 255" test that guards this all will
go "OK, that's at most 4 bytes and the final NUL termination, so it's
fine".
While a compiler - like gcc - that only sees that the original source
of the 'pin' value is a 'unsigned short' array, and then doesn't take
the "pin <= 255" into account, will warn like this:
gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt':
gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=]
sprintf(ev_name, "_%c%02X",
^~~~
gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535]
because gcc isn't being very good at that argument range analysis either.
In other words, the original use of 'hhx' was bogus to begin with, and
due to *another* compiler warning being bad, and we had that bad code
being written back in 2016 to work around _that_ compiler warning
(commit e40a3ae1f7: "gpio: acpi: work around false-positive
-Wstring-overflow warning").
Sadly, two different bad compiler warnings together does not make for
one good one.
It just makes for even more pain.
End result: I think the simplest and cleanest option is simply the
proposed change which undoes that '%hhX' change for gcc, and replaces
it with just using a slightly bigger stack allocation. It's not like
a 5-byte allocation is in any way likely to have saved any actual stack,
since all the other variables in that function are 'int' or bigger.
False-positive compiler warnings really do make people write worse
code, and that's a problem. But on a scale of bad code, I feel that
extending the buffer trivially is better than adding a pointless cast
that literally makes no sense.
At least in this case the end result isn't unreadable or buggy. We've
had several cases of bad compiler warnings that caused changes that
were actually horrendously wrong.
Fixes: e40a3ae1f7 ("gpio: acpi: work around false-positive -Wstring-overflow warning")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
R-Car V3U (R8A779A0) was the first member of the R-Car Gen4 family.
Generalize the support for R-Car V3U to other SoCs in the R-Car Gen4
family by adding a family-specific compatible value.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
In the snippets like the following
if (...)
return / goto / break / continue ...;
else
...
the 'else' is redundant. Get rid of it. In case of IOCTLs use
switch-case pattern that seems the usual in such cases.
While at it, clarify necessity of else in gpiod_direction_output()
by attaching else if to the closing curly brace on a previous line.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
GPIO chip irq members are exposed before they could be completely
initialized and this leads to race conditions.
One such issue was observed for the gc->irq.domain variable which
was accessed through the I2C interface in gpiochip_to_irq() before
it could be initialized by gpiochip_add_irqchip(). This resulted in
Kernel NULL pointer dereference.
Following are the logs for reference :-
kernel: Call Trace:
kernel: gpiod_to_irq+0x53/0x70
kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0
kernel: i2c_acpi_get_irq+0xc0/0xd0
kernel: i2c_device_probe+0x28a/0x2a0
kernel: really_probe+0xf2/0x460
kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0
To avoid such scenarios, restrict usage of GPIO chip irq members before
they are completely initialized.
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Cc: stable@vger.kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
- grammar and formatting fixes in comments for gpio-ts4900
- correct links in gpio-ts5500
- fix a warning in doc generation for the core GPIO documentation
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmJHBBQACgkQEacuoBRx
13Ih3A//bkylULu9FUjRS+zFlpbN+BFFNtDTfVKic0wRsJhU+eJb4pbpC6ZokyqT
NxkIm8qvZHb3RUFB6qPm44UbuELjeU09E4atxUfuiBNyb0t8WAW0YgFAQql7RweX
mwTQ82+ARQm1qGhsqxKwRn0qFlMEdBLvYVGffVZp3NbOGaAIIKpCu5ZvWg9yC6rW
ksAE0jmmxY1ak2H0q5D0VPj1aScZhXjaN94GTCYbTRAY0SSZMxbkuG3Mo6vLO8go
u3jsZ7hGaGvadNcpmtmA0sqWLXVq7qCi6CdmUM6iTnIsPMHwUi9I722VKQzE2yS/
bp8v7YOUhEAT+324QzLxTDZjZWSJnFf9tJ24pjUl0V9M6+31iSnf3uNWijfCJgG5
SHdJeZUx6vqqyN2JObHng5zdYS38TksywmkijrVas/C7IHl9sRZLJPM5Qg9bKuGO
PwOr0zuOlTxhi3R91dvOECZsan159gnnpnZFinYrqsIrOOt9VRkdv97en+4nV2p0
vgnwLRBDanMF7y7/8yyZzDGip+qI+3L3j/6x6WvFhPWaXqda3Xoh6rSj0JHM0BOi
x1qvzI/wokOZN6aBrbJoFfDcbL6nU+QWLBxlB2/prMMVh7KD7yDyE3wvQVZGx/xt
zPQJksXIFLebtVQ1TGfClgsqYoPfk/E3epouOfdaryXb1tPiD0A=
=9+Rg
-----END PGP SIGNATURE-----
Merge tag 'gpio-fixes-for-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- grammar and formatting fixes in comments for gpio-ts4900
- correct links in gpio-ts5500
- fix a warning in doc generation for the core GPIO documentation
* tag 'gpio-fixes-for-v5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: ts5500: Fix Links to Technologic Systems web resources
gpio: Properly document parent data union
gpio: ts4900: Fix comment formatting and grammar
Technologic Systems has rebranded as embeddedTS with the current
domain eventually going offline. Update web/doc URLs to correct
resource locations.
Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
The issues were pointed out after the prior commit was applied.
Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Here is the big set of char/misc and other small driver subsystem
updates for 5.18-rc1.
Included in here are merges from driver subsystems which contain:
- iio driver updates and new drivers
- fsi driver updates
- fpga driver updates
- habanalabs driver updates and support for new hardware
- soundwire driver updates and new drivers
- phy driver updates and new drivers
- coresight driver updates
- icc driver updates
Individual changes include:
- mei driver updates
- interconnect driver updates
- new PECI driver subsystem added
- vmci driver updates
- lots of tiny misc/char driver updates
There will be two merge conflicts with your tree, one in MAINTAINERS
which is obvious to fix up, and one in drivers/phy/freescale/Kconfig
which also should be easy to resolve.
All of these have been in linux-next for a while with no reported
problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCYkG3fQ8cZ3JlZ0Brcm9h
aC5jb20ACgkQMUfUDdst+ykNEgCfaRG8CRxewDXOO4+GSeA3NGK+AIoAnR89donC
R4bgCjfg8BWIBcVVXg3/
=WWXC
-----END PGP SIGNATURE-----
Merge tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc and other driver updates from Greg KH:
"Here is the big set of char/misc and other small driver subsystem
updates for 5.18-rc1.
Included in here are merges from driver subsystems which contain:
- iio driver updates and new drivers
- fsi driver updates
- fpga driver updates
- habanalabs driver updates and support for new hardware
- soundwire driver updates and new drivers
- phy driver updates and new drivers
- coresight driver updates
- icc driver updates
Individual changes include:
- mei driver updates
- interconnect driver updates
- new PECI driver subsystem added
- vmci driver updates
- lots of tiny misc/char driver updates
All of these have been in linux-next for a while with no reported
problems"
* tag 'char-misc-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (556 commits)
firmware: google: Properly state IOMEM dependency
kgdbts: fix return value of __setup handler
firmware: sysfb: fix platform-device leak in error path
firmware: stratix10-svc: add missing callback parameter on RSU
arm64: dts: qcom: add non-secure domain property to fastrpc nodes
misc: fastrpc: Add dma handle implementation
misc: fastrpc: Add fdlist implementation
misc: fastrpc: Add helper function to get list and page
misc: fastrpc: Add support to secure memory map
dt-bindings: misc: add fastrpc domain vmid property
misc: fastrpc: check before loading process to the DSP
misc: fastrpc: add secure domain support
dt-bindings: misc: add property to support non-secure DSP
misc: fastrpc: Add support to get DSP capabilities
misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP
misc: fastrpc: separate fastrpc device from channel context
dt-bindings: nvmem: brcm,nvram: add basic NVMEM cells
dt-bindings: nvmem: make "reg" property optional
nvmem: brcm_nvram: parse NVRAM content into NVMEM cells
nvmem: dt-bindings: Fix the error of dt-bindings check
...
- new driver: gpio-en7523
- dt-bindings: convertion of faraday,ftgpio010 to YAML, new compatible string
in gpio-vf610 and a bugfix in an example
- gpiolib core: several improvements and some code shrink
- documentation: convert all public docs into kerneldoc format
- set IRQ bus token in gpio-crystalcove (addresses a debugfs issue)
- add a missing return value check for kstrdup() in gpio-merrifield
- allow gpio-tps68470 to be built as module
- more work on limiting usage of of_node in GPIO drivers
- several sysfs interface improvements
- use SDPX in gpio-ts4900
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmI7SAwACgkQEacuoBRx
13JJEA/+MdTAmPHyCp55POmKmxMIafejc2EXaZKYK82WhuqOBWyc4UHMzGGD/7YF
TXKidJ8Bnzki2XiAJlHuyRLrBR67qUs79UkCKQPoEsaBJ4AeQj48bR8YHb+1x+gS
2LS7IqW4sFB5O61ZCB1Bg8k8Ots9E5OI4Q9+gGxyLVbCK0L8mN8U63a/Fhv4sIJU
z5WBXVTOsIMrprN2N9/VxNnSUkRqaUcl78ko0yV9B6vi957pojkFApg3rdJmWqV6
RLGdrQIklY95SdlnTHuG8+7Jy0Ut/ohwdUFDpyd/Hv/qvzE/vRWdvsccSS8KHwtL
dK+8sGN67QWfLmUhjqd0Y+Q/f/IIZyGHTkHWUojPE9cW6HJudgXQlCkcbjdV+tdB
2DO67wal6UKIw6efScLeBB7N/x9p8UioxVwHQiy05GBZJYTI184NWoel5hKqUbnh
GZVBf30fVQxmsJoHJa7e+xPLcHOrrTU+80CR9NhZBBm6xNLbkl1MidbJWfuEgNC1
6+o6jhy5K+SS09NKQteJFNQtc7f2Mt3Rc1NQzxJc2AaQXFvqbQLC36qkk5oqeDKH
Ndw4AYuxXWBU62sHZCJkWtG2CIAykvBNRoje3rXukbcv583jx18WScWJx/FKS9hh
k//1hdlesCV1ouo4qDvCiEC5hby0+FQ/HWgkXGIlNC/gZ6fcrZs=
=0SYv
-----END PGP SIGNATURE-----
Merge tag 'gpio-updates-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio updates from Bartosz Golaszewski:
"Relatively few updates for this release cycle. We have a single new
driver and some minor changes in drivers, more work on limiting the
usage of of_node in drivers and DT updates:
- new driver: gpio-en7523
- dt-bindings: convertion of faraday,ftgpio010 to YAML, new
compatible string in gpio-vf610 and a bugfix in an example
- gpiolib core: several improvements and some code shrink
- documentation: convert all public docs into kerneldoc format
- set IRQ bus token in gpio-crystalcove (addresses a debugfs issue)
- add a missing return value check for kstrdup() in gpio-merrifield
- allow gpio-tps68470 to be built as module
- more work on limiting usage of of_node in GPIO drivers
- several sysfs interface improvements
- use SDPX in gpio-ts4900"
* tag 'gpio-updates-for-v5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: ts4900: Use SPDX header
gpiolib: Use list_first_entry()/list_last_entry()
gpiolib: sysfs: Simplify edge handling in the code
gpiolib: sysfs: Move kstrtox() calls outside of the mutex lock
gpiolib: sysfs: Move sysfs_emit() calls outside of the mutex lock
gpiolib: make struct comments into real kernel docs
dt-bindings: gpio: convert faraday,ftgpio01 to yaml
dt-bindings: gpio: gpio-vf610: Add imx93 compatible string
gpiolib: Simplify error path in gpiod_get_index() when requesting GPIO
gpiolib: Use short form of ternary operator in gpiod_get_index()
gpiolib: Introduce for_each_gpio_desc_with_flag() macro
gpio: Add support for Airoha EN7523 GPIO controller
dt-bindings: arm: airoha: Add binding for Airoha GPIO controller
dt-bindings: gpio: fix gpio-hog example
gpio: tps68470: Allow building as module
gpio: tegra: Get rid of duplicate of_node assignment
gpio: altera-a10sr: Switch to use fwnode instead of of_node
gpio: merrifield: check the return value of devm_kstrdup()
gpio: crystalcove: Set IRQ domain bus token to DOMAIN_BUS_WIRED
