30 Sep, 2022

1 commit

  • This is the 5.15.71 stable release

    * tag 'v5.15.71': (144 commits)
    Linux 5.15.71
    ext4: use locality group preallocation for small closed files
    ext4: avoid unnecessary spreading of allocations among groups
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/net/phy/aquantia_main.c
    drivers/tty/serial/fsl_lpuart.c

    Jason Liu
     

28 Sep, 2022

3 commits

  • commit 69bef19d6b9700e96285f4b4e28691cda3dcd0d1 upstream.

    When running gpio test on nxp-ls1028 platform with below command
    gpiomon --num-events=3 --rising-edge gpiochip1 25
    There will be a warning trace as below:
    Call trace:
    free_irq+0x204/0x360
    lineevent_free+0x64/0x70
    gpio_ioctl+0x598/0x6a0
    __arm64_sys_ioctl+0xb4/0x100
    invoke_syscall+0x5c/0x130
    ......
    el0t_64_sync+0x1a0/0x1a4
    The reason of this issue is that calling request_threaded_irq()
    function failed, and then lineevent_free() is invoked to release
    the resource. Since the lineevent_state::irq was already set, so
    the subsequent invocation of free_irq() would trigger the above
    warning call trace. To fix this issue, set the lineevent_state::irq
    after the IRQ register successfully.

    Fixes: 468242724143 ("gpiolib: cdev: refactor lineevent cleanup into lineevent_free")
    Cc: stable@vger.kernel.org
    Signed-off-by: Meng Li
    Reviewed-by: Kent Gibson
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Meng Li
     
  • commit 02743c4091ccfb246f5cdbbe3f44b152d5d12933 upstream.

    If creation of software node fails, the locally allocated string
    array is left unfreed. Free it on error path.

    Fixes: 6fda593f3082 ("gpio: mockup: Convert to use software nodes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Andy Shevchenko
     
  • commit b7df41a6f79dfb18ba2203f8c5f0e9c0b9b57f68 upstream.

    We now remove the device's debugfs entries when unbinding the driver.
    This now causes a NULL-pointer dereference on module exit because the
    platform devices are unregistered *after* the global debugfs directory
    has been recursively removed. Fix it by unregistering the devices first.

    Fixes: 303e6da99429 ("gpio: mockup: remove gpio debugfs when remove device")
    Cc: Wei Yongjun
    Cc: stable@vger.kernel.org
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Bartosz Golaszewski
     

27 Sep, 2022

1 commit

  • This is the 5.15.70 stable release

    * tag 'v5.15.70': (2444 commits)
    Linux 5.15.70
    ALSA: hda/sigmatel: Fix unused variable warning for beep power change
    cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    arch/arm/boot/dts/imx6ul.dtsi
    arch/arm/mm/mmu.c
    arch/arm64/boot/dts/freescale/imx8mp-evk.dts
    drivers/gpu/drm/imx/dcss/dcss-kms.c
    drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
    drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h
    drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
    drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
    drivers/soc/fsl/Kconfig
    drivers/soc/imx/gpcv2.c
    drivers/usb/dwc3/host.c
    net/dsa/slave.c
    sound/soc/fsl/imx-card.c

    Jason Liu
     

23 Sep, 2022

2 commits

  • [ Upstream commit 279c12df8d2efb28def9d037f288cbfb97c30fe2 ]

    Commit e39d5ef67804 ("powerpc/5xxx: extend mpc8xxx_gpio driver to support
    mpc512x gpios") implemented support for IRQ_TYPE_LEVEL_LOW flow type in
    mpc512x via falling edge type. Do same for mpc85xx which support was added
    in commit 345e5c8a1cc3 ("powerpc: Add interrupt support to mpc8xxx_gpio").

    Fixes probing of lm90 hwmon driver on mpc85xx based board which use level
    interrupt. Without it kernel prints error and refuse lm90 to work:

    [ 15.258370] genirq: Setting trigger mode 8 for irq 49 failed (mpc8xxx_irq_set_type+0x0/0xf8)
    [ 15.267168] lm90 0-004c: cannot request IRQ 49
    [ 15.272708] lm90: probe of 0-004c failed with error -22

    Fixes: 345e5c8a1cc3 ("powerpc: Add interrupt support to mpc8xxx_gpio")
    Signed-off-by: Pali Rohár
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Pali Rohár
     
  • [ Upstream commit b871656aa4f54e04207f62bdd0d7572be1d86b36 ]

    Switching between falling/rising edges for IRQ_TYPE_EDGE_BOTH on pins that
    require debounce can cause the device to lose events due to a desync
    between pin state and irq type.

    This problem is resolved by switching between IRQ_TYPE_LEVEL_LOW and
    IRQ_TYPE_LEVEL_HIGH instead.

    Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio")
    Signed-off-by: João H. Spies
    Link: https://lore.kernel.org/r/20220808025121.110223-1-jhlspies@gmail.com
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    João H. Spies
     

20 Sep, 2022

1 commit

  • [ Upstream commit 303e6da99429510b1e4edf833afe90ac8542e747 ]

    GPIO mockup debugfs is created in gpio_mockup_probe() but
    forgot to remove when remove device. This patch add a devm
    managed callback for removing them.

    Signed-off-by: Wei Yongjun
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Wei Yongjun
     

08 Sep, 2022

1 commit

  • [ Upstream commit 518e26f11af2fe4f5bebf9a0351595d508c7077f ]

    The regcache sync will set the cache_bypass = true, at that
    time, when there is regmap write operation, it will bypass
    the regmap cache, then the regcache sync will write back the
    value from cache to register, which is not as our expectation.

    Though regmap already use its internal lock to avoid such issue,
    but this driver force disable the regmap internal lock in its
    regmap config: disable_locking = true

    To avoid this issue, use the driver's own lock to do the protect
    in system PM.

    Fixes: b76574300504 ("gpio: pca953x: Restore registers after suspend/resume cycle")
    Signed-off-by: Haibo Chen
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Haibo Chen
     

06 Sep, 2022

1 commit

  • The system crashes when using the pad wakeup feature on i.mx8 boards.
    When GPIO works under the pad wakeup mode, the power for GPIO module
    will be off when system enters into suspend. When system resume, the
    gpio interrupt handler needs to access the GPIO states, and at that
    time the module is not powered on yet so the system crashes. This patch
    just uses the pad to wake up the system, and no need to handle it in
    the interrupt handler.

    Signed-off-by: Shenwei Wang
    Reviewed-and-Tested-by: Haibo Chen
    Acked-by: Jason Liu

    Shenwei Wang
     

17 Aug, 2022

1 commit

  • [ Upstream commit 5d07a692f9562f9c06e62cce369e9dd108173a0f ]

    We should use of_node_get() when a new reference of device_node
    is created. It is noted that the old reference stored in
    'mm_gc->gc.of_node' should also be decreased.

    This patch is based on the fact that there is a call site in function
    'qe_add_gpiochips()' of src file 'drivers\soc\fsl\qe\gpio.c'. In this
    function, of_mm_gpiochip_add_data() is contained in an iteration of
    for_each_compatible_node() which will automatically increase and
    decrease the refcount. So we need additional of_node_get() for the
    reference escape in of_mm_gpiochip_add_data().

    Fixes: a19e3da5bc5f ("of/gpio: Kill of_gpio_chip and add members directly to gpio_chip")
    Signed-off-by: Liang He
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Liang He
     

29 Jul, 2022

4 commits

  • [ Upstream commit 32c094a09d5829ad9b02cdf667569aefa8de0ea6 ]

    Current implementation is not able to configure more than 32 pins
    due to incorrect data type. So type casting with unsigned long
    to avoid it.

    Fixes: 02b3f84d9080 ("xilinx: Switch to use bitmap APIs")
    Signed-off-by: Srinivas Neeli
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Srinivas Neeli
     
  • [ Upstream commit b8c768ccdd8338504fb78370747728d5002b1b5a ]

    For regcache_sync_region, we need to use pca953x_recalc_addr() to get
    the real register address.

    Fixes: ec82d1eba346 ("gpio: pca953x: Zap ad-hoc reg_output cache")
    Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache")
    Signed-off-by: Haibo Chen
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Haibo Chen
     
  • [ Upstream commit 2abc17a93867dc816f0ed9d32021dda8078e7330 ]

    regmap will sync a range of registers, here use the correct range
    to make sure the sync do not touch other unexpected registers.

    Find on pca9557pw on imx8qxp/dxl evk board, this device support
    8 pin, so only need one register(8 bits) to cover all the 8 pins's
    property setting. But when sync the output, we find it actually
    update two registers, output register and the following register.

    Fixes: b76574300504 ("gpio: pca953x: Restore registers after suspend/resume cycle")
    Fixes: ec82d1eba346 ("gpio: pca953x: Zap ad-hoc reg_output cache")
    Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache")
    Signed-off-by: Haibo Chen
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Haibo Chen
     
  • [ Upstream commit db8edaa09d7461ec08672a92a2eef63d5882bb79 ]

    For the device use NO AI mode(not support auto address increment),
    only use the single read/write when config the regmap.

    We meet issue on PCA9557PW on i.MX8QXP/DXL evk board, this device
    do not support AI mode, but when do the regmap sync, regmap will
    sync 3 byte data to register 1, logically this means write first
    data to register 1, write second data to register 2, write third data
    to register 3. But this device do not support AI mode, finally, these
    three data write only into register 1 one by one. the reault is the
    value of register 1 alway equal to the latest data, here is the third
    data, no operation happened on register 2 and register 3. This is
    not what we expect.

    Fixes: 49427232764d ("gpio: pca953x: Perform basic regmap conversion")
    Signed-off-by: Haibo Chen
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Haibo Chen
     

21 Jul, 2022

3 commits

  • For regcache_sync_region, need to use pca953x_recalc_addr() to get
    the real register address.

    Fixes: ec82d1eba346 ("gpio: pca953x: Zap ad-hoc reg_output cache")
    Fixes: 0f25fda840a9 ("gpio: pca953x: Zap ad-hoc reg_direction cache")
    Signed-off-by: Haibo Chen
    Reviewed-by: Jun Li

    Haibo Chen
     
  • regmap will sync a range of registers, here use the correct range
    to make sure the sync do not touch other unexpected registers.

    Find on pca9557pw on imx8qxp/dxl evk board, this device support
    8 pin, so only need one register(8 bits) to cover all the 8 pins's
    compatible setting. But when sync the output, we find it actually
    update two register, output register and the following register.

    Signed-off-by: Haibo Chen
    Reviewed-by: Jun Li

    Haibo Chen
     
  • For the device use NO AI mode(not support auto address increment),
    only use the single read/write when config the regmap.

    We meet issue on PCA9557PW on i.MX8QXP/DXL evk board, this device
    do not support AI mode, but when do the regmap sync, regmap will
    sync 3 byte data to register 1, logically this means write first
    data to register 1, write second data to register 2, write third data
    to register 3. But this device do not support AI mode, finally, these
    three data write only into register 1 one by one. the reault is the
    value of register 1 alway equal to the latest data, here is the third
    data, no operation happened on register 2 and register 3. This is
    not what we expect.

    Signed-off-by: Haibo Chen
    Reviewed-by: Jun Li

    Haibo Chen
     

11 Jul, 2022

3 commits

  • The logic of this patch is incorrect, in the pca953x_suspend(), it enable the regmap
    cache, and disable regmap cache in pca953x_resume(). So no matter whether there is
    vcc regulator, we need to do regcache sync.

    Find this issue when we add LVDS panel on imx93-11x11-evk board. This LVDS panel use
    one pad of pcal6524 to control its 12V voltage supply (regulator). The sequence in
    the system suspend is regulator(disable)->pca953x->drm, but the resume sequence is
    drm->regulator(enable)->pca953x, this means there is one gpio operation happen before
    the pca953x resume, since we already enable the regmap cache, so this gpio operation
    only save in the regmap cache, do not really config in the pcal6534 register. Then in
    pca953x resume, skip this regcache sync, then we miss this gpio operation. LVDS panel
    can't light up after system resume.

    This reverts commit 1681044121fa74b4909feec0fc1928737d7494b2.
    Signed-off-by: Haibo Chen
    Reviewed-by: Jun Li
    (cherry picked from commit 5ac575879823f3cf6bd9dc36543c798a9fc54824)

    Haibo Chen
     
  • Need to revert commit 1681044121fa ("gpio: pca953x: no need to do
    regcache sync without vcc regulator"). So current patch no need any
    more.

    This reverts commit 7b513df1623f8add24f681a0d11600ae9a619ed2.
    Signed-off-by: Haibo Chen
    Reviewed-by: Jun Li
    (cherry picked from commit 784bffa3741a26e5a0f1e5b1e69ba7c20dc73d4c)

    Haibo Chen
     
  • This is gpio function support for MFD adp5585.

    Signed-off-by: Haibo Chen
    Reviewed-by: Jun Li
    (cherry picked from commit 3b84aa6cd11c96449eafb6dc6f769cb44652d13c)

    Haibo Chen
     

30 Jun, 2022

3 commits

  • This is the 5.15.51 stable release

    * tag 'v5.15.51': (136 commits)
    Linux 5.15.51
    powerpc/pseries: wire up rng during setup_arch()
    kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS (2nd attempt)
    ...

    Signed-off-by: Jason Liu

    Jason Liu
     
  • This is the 5.15.50 stable release

    * tag 'v5.15.50': (1395 commits)
    Linux 5.15.50
    arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer
    serial: core: Initialize rs485 RTS polarity already on probe
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    drivers/bus/fsl-mc/fsl-mc-bus.c
    drivers/crypto/caam/ctrl.c
    drivers/pci/controller/dwc/pci-imx6.c
    drivers/spi/spi-fsl-qspi.c
    drivers/tty/serial/fsl_lpuart.c
    include/uapi/linux/dma-buf.h

    Jason Liu
     
  • This is the 5.15.41 stable release

    * tag 'v5.15.41': (1977 commits)
    Linux 5.15.41
    usb: gadget: uvc: allow for application to cleanly shutdown
    usb: gadget: uvc: rename function to be more consistent
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
    arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
    arch/arm64/configs/defconfig
    drivers/clk/imx/clk-imx8qxp-lpcg.c
    drivers/dma/imx-sdma.c
    drivers/gpu/drm/bridge/nwl-dsi.c
    drivers/mailbox/imx-mailbox.c
    drivers/net/phy/at803x.c
    drivers/tty/serial/fsl_lpuart.c
    security/keys/trusted-keys/trusted_core.c

    Jason Liu
     

29 Jun, 2022

2 commits

  • [ Upstream commit 9ca766eaea2e87b8b773bff04ee56c055cb76d4e ]

    This error path returns 1, but it should instead propagate the negative
    error code from winbond_sio_enter().

    Fixes: a0d65009411c ("gpio: winbond: Add driver")
    Signed-off-by: Dan Carpenter
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Dan Carpenter
     
  • [ Upstream commit c81aba8fde2aee4f5778ebab3a1d51bd2ef48e4c ]

    commit 979934da9e7a ("[PATCH] mips: update IRQ handling for vr41xx") added
    a function irq_dispatch, and it'll increase irq_err_count when the get_irq
    callback returns a negative value, but increase irq_err_count in get_irq
    was not removed.

    And also, modpost complains once gpio-vr41xx drivers become modules.
    ERROR: modpost: "irq_err_count" [drivers/gpio/gpio-vr41xx.ko] undefined!

    So it would be a good idea to remove repetitive increase irq_err_count in
    get_irq callback.

    Fixes: 27fdd325dace ("MIPS: Update VR41xx GPIO driver to use gpiolib")
    Fixes: 979934da9e7a ("[PATCH] mips: update IRQ handling for vr41xx")
    Reported-by: k2ci
    Signed-off-by: huhai
    Signed-off-by: Genjian Zhang
    Signed-off-by: Thomas Bogendoerfer
    Signed-off-by: Sasha Levin

    huhai
     

22 Jun, 2022

1 commit

  • [ Upstream commit 77006f6edc0e0f58617eb25e53731f78641e820d ]

    Currently if the APB or Debounce clocks aren't yet ready to be requested
    the DW GPIO driver will correctly handle that by deferring the probe
    procedure, but the error is still printed to the system log. It needlessly
    pollutes the log since there was no real error but a request to postpone
    the clock request procedure since the clocks subsystem hasn't been fully
    initialized yet. Let's fix that by using the dev_err_probe method to print
    the APB/clock request error status. It will correctly handle the deferred
    probe situation and print the error if it actually happens.

    Signed-off-by: Serge Semin
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Serge Semin
     

15 Jun, 2022

1 commit


09 Jun, 2022

2 commits

  • [ Upstream commit 8ce5ef64546850294b021497046588a7abcebe96 ]

    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: e7165b1dff06 ("pinctrl/rockchip: add a queue for deferred pin output settings on probe")
    Fixes: 59dd178e1d7c ("gpio/rockchip: fetch deferred output settings on probe")
    Signed-off-by: Caleb Connolly
    Link: https://lore.kernel.org/r/20220328005005.72492-2-kc@postmarketos.org
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Caleb Connolly
     
  • [ Upstream commit 3550bba25d5587a701e6edf20e20984d2ee72c78 ]

    Since commit 2ab73c6d8323 ("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: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
    Signed-off-by: Stefan Wahren
    Reviewed-by: Florian Fainelli
    Tested-by: Florian Fainelli
    Acked-by: Bartosz Golaszewski
    Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Stefan Wahren
     

25 May, 2022

2 commits

  • [ Upstream commit 3ecb10175b1f776f076553c24e2689e42953fef5 ]

    The driver doesn't take struct pwm_state::polarity into account when
    configuring the hardware, so refuse requests for inverted polarity.

    Fixes: 757642f9a584 ("gpio: mvebu: Add limited PWM support")
    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Uwe Kleine-König
     
  • [ Upstream commit 9bf3ac466faa83d51a8fe9212131701e58fdef74 ]

    For gpio controller contain register PDDR, when set one target bit,
    current logic will clear all other bits, this is wrong. Use operator
    '|=' to fix it.

    Fixes: 659d8a62311f ("gpio: vf610: add imx7ulp support")
    Reviewed-by: Peng Fan
    Signed-off-by: Haibo Chen
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Haibo Chen
     

12 May, 2022

4 commits

  • [ Upstream commit e5f6e5d554ac274f9c8ba60078103d0425b93c19 ]

    pwmchip_add() unconditionally assigns the base ID dynamically. Commit
    f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
    dropped all base assignment from drivers under drivers/pwm/. It missed
    this driver. Fix that.

    Fixes: f9a8ee8c8bcd1 ("pwm: Always allocate PWM chip base ID dynamically")
    Signed-off-by: Baruch Siach
    Reviewed-by: Uwe Kleine-König
    Acked-by: Linus Walleij
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Sasha Levin

    Baruch Siach
     
  • commit dba785798526a3282cc4d0f0ea751883715dbbb4 upstream.

    When one port's input state get inverted (eg. from low to hight) after
    pca953x_irq_setup but before setting irq_mask (by some other driver such as
    "gpio-keys"), the next inversion of this port (eg. from hight to low) will not
    be triggered any more (because irq_stat is not updated at the first time). Issue
    should be fixed after this commit.

    Fixes: 89ea8bbe9c3e ("gpio: pca953x.c: add interrupt handling capability")
    Signed-off-by: Puyou Lu
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Puyou Lu
     
  • commit 171865dab096da1ab980a32eeea5d1b88cd7bc50 upstream.

    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: 2ad74f40dacc ("gpio: visconti: Add Toshiba Visconti GPIO support")
    Signed-off-by: Nobuhiro Iwamatsu
    Reviewed-by: Linus Walleij
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Nobuhiro Iwamatsu
     
  • commit e75f88efac05bf4e107e4171d8db6d8c3937252d upstream.

    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 = "
    (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: 726cb3ba4969 ("gpiolib: Support 'gpio-reserved-ranges' property")
    Signed-off-by: Andrei Lalaev
    Reviewed-by: Andy Shevchenko
    Reviewed-by: Linus Walleij
    Cc: stable@vger.kernel.org
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Andrei Lalaev
     

09 May, 2022

1 commit


27 Apr, 2022

1 commit

  • commit 06fb4ecfeac7e00d6704fa5ed19299f2fefb3cc9 upstream.

    Commit 5467801f1fcb ("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: 5467801f1fcb ("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
    Signed-off-by: Mario Limonciello
    Reviewed-by: Shreeya Patel
    Tested-By: Samuel Čavoj
    Tested-By: lukeluk498@gmail.com Link:
    Reviewed-by: Andy Shevchenko
    Acked-by: Linus Walleij
    Reviewed-and-tested-by: Takashi Iwai
    Cc: Shreeya Patel
    Cc: stable@vger.kernel.org
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Mario Limonciello
     

20 Apr, 2022

1 commit

  • [ Upstream commit 213d266ebfb1621aab79cfe63388facc520a1381 ]

    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
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Sasha Levin

    Linus Torvalds
     

14 Apr, 2022

1 commit

  • commit 5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320 upstream.

    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
    Cc: stable@vger.kernel.org
    Reviewed-by: Andy Shevchenko
    Reviewed-by: Linus Walleij
    Signed-off-by: Bartosz Golaszewski
    Signed-off-by: Greg Kroah-Hartman

    Shreeya Patel