12 Feb, 2019

16 commits


13 Jan, 2019

1 commit

  • [ Upstream commit 614b1868a125a0ba24be08f3a7fa832ddcde6bca ]

    We just changed the code so we apply bias disable on the correct
    register but forgot to align the register calculation. The result
    is that we apply the change on the correct register, but possibly
    at the incorrect offset/bit

    This went undetected because offsets tends to be the same between
    REG_PULL and REG_PULLEN for a given pin the EE controller. This
    is not true for the AO controller.

    Fixes: e39f9dd8206a ("pinctrl: meson: fix pinconf bias disable")
    Signed-off-by: Jerome Brunet
    Acked-by: Neil Armstrong
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Jerome Brunet
     

21 Dec, 2018

1 commit

  • commit 478b6767ad26ab86d9ecc341027dd09a87b1f997 upstream.

    Pin PH11 is used on various A83T board to detect a change in the OTG
    port's ID pin, as in when an OTG host cable is plugged in.

    The incorrect offset meant the gpiochip/irqchip was activating the wrong
    pin for interrupts.

    Fixes: 4730f33f0d82 ("pinctrl: sunxi: add allwinner A83T PIO controller support")
    Cc:
    Signed-off-by: Chen-Yu Tsai
    Acked-by: Maxime Ripard
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Chen-Yu Tsai
     

01 Dec, 2018

1 commit

  • [ Upstream commit e39f9dd8206ad66992ac0e6218ef1ba746f2cce9 ]

    If a bias is enabled on a pin of an Amlogic SoC, calling .pin_config_set()
    with PIN_CONFIG_BIAS_DISABLE will not disable the bias. Instead it will
    force a pull-down bias on the pin.

    Instead of the pull type register bank, the driver should access the pull
    enable register bank.

    Fixes: 6ac730951104 ("pinctrl: add driver for Amlogic Meson SoCs")
    Signed-off-by: Jerome Brunet
    Acked-by: Neil Armstrong
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin

    Jerome Brunet
     

14 Nov, 2018

4 commits

  • [ Upstream commit b432414b996d32a1bd9afe2bd595bd5729c1477f ]

    If you look at "pinconf-groups" in debugfs for ssbi-gpio you'll notice
    it looks like nonsense.

    The problem is fairly well described in commit 1cf86bc21257 ("pinctrl:
    qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and
    commit 05e0c828955c ("pinctrl: msm: Fix msm_config_group_get() to be
    compliant"), but it was pointed out that ssbi-gpio has the same
    problem. Let's fix it there too.

    Fixes: b4c45fe974bc ("pinctrl: qcom: ssbi: Family A gpio & mpp drivers")
    Signed-off-by: Douglas Anderson
    Reviewed-by: Stephen Boyd
    Reviewed-by: Bjorn Andersson
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Douglas Anderson
     
  • [ Upstream commit 0d5b476f8f57fcb06c45fe27681ac47254f63fd2 ]

    If you look at "pinconf-groups" in debugfs for ssbi-mpp you'll notice
    it looks like nonsense.

    The problem is fairly well described in commit 1cf86bc21257 ("pinctrl:
    qcom: spmi-gpio: Fix pmic_gpio_config_get() to be compliant") and
    commit 05e0c828955c ("pinctrl: msm: Fix msm_config_group_get() to be
    compliant"), but it was pointed out that ssbi-mpp has the same
    problem. Let's fix it there too.

    NOTE: in case it's helpful to someone reading this, the way to tell
    whether to do the -EINVAL or not is to look at the PCONFDUMP for a
    given attribute. If the last element (has_arg) is false then you need
    to do the -EINVAL trick.

    ALSO NOTE: it seems unlikely that the values returned when we try to
    get PIN_CONFIG_BIAS_PULL_UP will actually be printed since "has_arg"
    is false for that one, but I guess it's still fine to return different
    values so I kept doing that. It seems like another driver (ssbi-gpio)
    uses a custom attribute (PM8XXX_QCOM_PULL_UP_STRENGTH) for something
    similar so maybe a future change should do that here too.

    Fixes: cfb24f6ebd38 ("pinctrl: Qualcomm SPMI PMIC MPP pin controller driver")
    Signed-off-by: Douglas Anderson
    Reviewed-by: Stephen Boyd
    Reviewed-by: Bjorn Andersson
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Douglas Anderson
     
  • [ Upstream commit 89c68b102f13f123aaef22b292526d6b92501334 ]

    It looks like we parse the drive strength setting here, but never
    actually write it into the hardware to update it. Parse the setting and
    then write it at the end of the pinconf setting function so that it
    actually sticks in the hardware.

    Fixes: 0e948042c420 ("pinctrl: qcom: spmi-mpp: Implement support for sink mode")
    Cc: Doug Anderson
    Signed-off-by: Stephen Boyd
    Reviewed-by: Bjorn Andersson
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Stephen Boyd
     
  • [ Upstream commit 69f8455f6cc78fa6cdf80d0105d7a748106271dc ]

    'ret' should be returned while pmic_mpp_write_mode_ctl fails.

    Fixes: 0e948042c420 ("pinctrl: qcom: spmi-mpp: Implement support for sink mode")
    Signed-off-by: YueHaibing
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    YueHaibing
     

18 Oct, 2018

1 commit

  • commit f259f896f2348f0302f6f88d4382378cf9d23a7e upstream.

    Since 'commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' the
    irq request isn't the last devm_* allocation. Without a deeper look at
    the irq and testing this isn't a good solution. Since this driver relies
    on the devm mechanism, requesting a interrupt should be the last thing
    to avoid memory corruptions during unbinding.

    'Commit 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")' fixed the
    order for the interrupt-controller use case only. The
    mcp23s08_irq_setup() must be split into two to fix it for the
    interrupt-controller use case and to register the irq at last. So the
    irq will be freed first during unbind.

    Cc: stable@vger.kernel.org
    Cc: Jan Kundrát
    Cc: Dmitry Mastykin
    Cc: Sebastian Reichel
    Fixes: 82039d244f87 ("pinctrl: mcp23s08: add pinconf support")
    Fixes: 02e389e63e35 ("pinctrl: mcp23s08: fix irq setup order")
    Signed-off-by: Marco Felsch
    Tested-by: Phil Reid
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Marco Felsch
     

26 Sep, 2018

3 commits

  • [ Upstream commit 1cf86bc21257a330e3af51f2a4e885f1a705f6a5 ]

    If you do this on an sdm845 board:
    grep "" /sys/kernel/debug/pinctrl/*spmi:pmic*/pinconf-groups

    ...it looks like nonsense. For every pin you see listed:
    input bias disabled, input bias high impedance, input bias pull down, input bias pull up, ...

    That's because pmic_gpio_config_get() isn't complying with the rules
    that pinconf_generic_dump_one() expects. Specifically for boolean
    parameters (anything with a "struct pin_config_item" where has_arg is
    false) the function expects that the function should return its value
    not through the "config" parameter but should return "0" if the value
    is set and "-EINVAL" if the value isn't set.

    Let's fix this.

    >From a quick sample of other pinctrl drivers, it appears to be
    tradition to also return 1 through the config parameter for these
    boolean parameters when they exist. I'm not one to knock tradition,
    so I'll follow tradition and return 1 in these cases. While I'm at
    it, I'll also continue searching for four leaf clovers, kocking on
    wood three times, and trying not to break mirrors.

    NOTE: This also fixes an apparent typo for reading
    PIN_CONFIG_BIAS_DISABLE where the old driver was accidentally
    using "=" instead of "==" and thus was setting some internal
    state when you tried to query PIN_CONFIG_BIAS_DISABLE. Oops.

    Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver")
    Signed-off-by: Douglas Anderson
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Douglas Anderson
     
  • [ Upstream commit 05e0c828955c1cab58dd71a04539442e5375d917 ]

    If you do this on an sdm845 board:
    cat /sys/kernel/debug/pinctrl/3400000.pinctrl/pinconf-groups

    ...it looks like nonsense. For every pin you see listed:
    input bias bus hold, input bias disabled, input bias pull down, input bias pull up

    That's because msm_config_group_get() isn't complying with the rules
    that pinconf_generic_dump_one() expects. Specifically for boolean
    parameters (anything with a "struct pin_config_item" where has_arg is
    false) the function expects that the function should return its value
    not through the "config" parameter but should return "0" if the value
    is set and "-EINVAL" if the value isn't set.

    Let's fix this.

    >From a quick sample of other pinctrl drivers, it appears to be
    tradition to also return 1 through the config parameter for these
    boolean parameters when they exist. I'm not one to knock tradition,
    so I'll follow tradition and return 1 in these cases. While I'm at
    it, I'll also continue searching for four leaf clovers, kocking on
    wood three times, and trying not to break mirrors.

    Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
    Signed-off-by: Douglas Anderson
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Douglas Anderson
     
  • [ Upstream commit dc4003d260594aa300028c3c5d040c5719abd19b ]

    We must use a mutex around the generic_add functions and save the
    function and group selector in case we need to remove them. Otherwise
    the selector use will be racy for deferred probe at least.

    Fixes: 5a49b644b307 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
    Reported-by: H. Nikolaus Schaller
    Cc: Christ van Willegen
    Cc: Haojian Zhuang
    Cc: Paul Cercueil
    Cc: Sean Wang
    Acked-by: Jacopo Mondi
    Signed-off-by: Tony Lindgren
    Tested-By: H. Nikolaus Schaller
    Reviewed-by: Andy Shevchenko
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Tony Lindgren
     

20 Sep, 2018

2 commits

  • [ Upstream commit 8bbed1eef001fdfc0ee9595f64cc4f769d265af4 ]

    The AMD pinctrl driver demultiplexes GPIO interrupts and fires off their
    individual handlers.

    If one of these GPIO irqs is configured as a level interrupt, and its
    downstream handler is a threaded ONESHOT interrupt, the GPIO interrupt
    source is masked by handle_level_irq() until the eventual return of the
    threaded irq handler. During this time the level GPIO interrupt status
    will still report as high until the actual gpio source is cleared - both
    in the individual GPIO interrupt status bit (INTERRUPT_STS_OFF) and in
    its corresponding "WAKE_INT_STATUS_REG" bit.

    Thus, if another GPIO interrupt occurs during this time,
    amd_gpio_irq_handler() will see that the (masked-and-not-yet-cleared)
    level irq is still pending and incorrectly call its handler again.

    To fix this, have amd_gpio_irq_handler() check for both interrupts status
    and mask before calling generic_handle_irq().

    Note: Is it possible that this bug was the source of the interrupt storm
    on Ryzen when using chained interrupts before commit ba714a9c1dea85
    ("pinctrl/amd: Use regular interrupt instead of chained")?

    Signed-off-by: Daniel Kurtz
    Acked-by: Thomas Gleixner
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Daniel Kurtz
     
  • [ Upstream commit b4859f3edb47825f62d1b2efdd75fe7945996f49 ]

    The > should really be >= here. It's harmless because
    pinctrl_generic_get_group() will return a NULL if group is invalid.

    Fixes: ae75ff814538 ("pinctrl: pinctrl-imx: add imx pinctrl core driver")
    Reported-by: Dong Aisheng
    Signed-off-by: Dan Carpenter
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     

05 Sep, 2018

1 commit

  • commit 19da44cd33a3a6ff7c97fff0189999ff15b241e4 upstream.

    The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It
    has info->ngroups elements. Thus the > here should be >= to prevent
    reading one element beyond the end of the array.

    Cc: stable@vger.kernel.org
    Fixes: 30612cd90005 ("pinctrl: imx1 core driver")
    Signed-off-by: Dan Carpenter
    Reviewed-by: Uwe Kleine-König
    Acked-by: Dong Aisheng
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     

24 Aug, 2018

3 commits

  • [ Upstream commit c29e9da56bebb4c2c794e871b0dc0298bbf08142 ]

    platform_get_resource() may fail and return NULL, so we should
    better check it's return value to avoid a NULL pointer dereference
    a bit later in the code.

    This is detected by Coccinelle semantic patch.

    @@
    expression pdev, res, n, t, e, e1, e2;
    @@

    res = platform_get_resource(pdev, t, n);
    + if (!res)
    + return -EINVAL;
    ... when != res == NULL
    e = devm_ioremap_nocache(e1, res->start, e2);

    Fixes: cc4fa83f66e9 ("pinctrl: nsp: add pinmux driver support for Broadcom NSP SoC")
    Signed-off-by: Wei Yongjun
    Reviewed-by: Ray Jui
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Wei Yongjun
     
  • [ Upstream commit f90a21c898db58eaea14b8ad7e9af3b9e15e5f8a ]

    The > comparisons should be >= or else we read beyond the end of the
    pinctrl->functions[] array.

    Fixes: cc4fa83f66e9 ("pinctrl: nsp: add pinmux driver support for Broadcom NSP SoC")
    Signed-off-by: Dan Carpenter
    Reviewed-by: Ray Jui
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     
  • [ Upstream commit 0084a786ca8c84b443f67c4a697b4f2552761650 ]

    The .gpio_set_direction() callback was setting inverted direction
    for SoCs older than the JZ4770, this restores the correct behaviour.

    Signed-off-by: Paul Cercueil
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Paul Cercueil
     

03 Aug, 2018

1 commit

  • [ Upstream commit 21816364715f508c10da1e087e352bc1e326614f ]

    The device node iterators perform an of_node_get on each iteration, so a
    jump out of the loop requires an of_node_put.

    The semantic patch that fixes this problem is as follows
    (http://coccinelle.lip6.fr):

    //
    @@
    expression root,e;
    local idexpression child;
    iterator name for_each_child_of_node;
    @@

    for_each_child_of_node(root, child) {
    ... when != of_node_put(child)
    when != e = child
    + of_node_put(child);
    ? break;
    ...
    }
    ... when != child
    //

    Signed-off-by: Julia Lawall
    Acked-by: Ludovic Desroches
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Julia Lawall
     

03 Jul, 2018

2 commits

  • commit bc3322bc166a2905bc91f774d7b22773dc7c063a upstream.

    Commit b89405b6102f ("pinctrl: devicetree: Fix dt_to_map_one_config
    handling of hogs") causes the pinctrl hog pins to not get initialized
    on i.MX platforms leaving them with the IOMUX settings untouched.

    This causes several regressions on i.MX such as:

    - OV5640 camera driver can not be probed anymore on imx6qdl-sabresd
    because the camera clock pin is in a pinctrl_hog group and since
    its pinctrl initialization is skipped, the camera clock is kept
    in GPIO functionality instead of CLK_CKO function.

    - Audio stopped working on imx6qdl-wandboard and imx53-qsb for
    the same reason.

    Richard Fitzgerald explains the problem:

    "I see the bug. If the hog node isn't a 1st level child of the pinctrl
    parent node it will go around the for(;;) loop again but on the first
    pass I overwrite pctldev with the result of
    get_pinctrl_dev_from_of_node() so it doesn't point to the pinctrl driver
    any more."

    Fix the issue by stashing the original pctldev so it doesn't
    get overwritten.

    Fixes: b89405b6102f ("pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs")
    Cc:
    Reported-by: Mika Penttilä
    Reported-by: Steve Longerbeam
    Suggested-by: Richard Fitzgerald
    Signed-off-by: Fabio Estevam
    Reviewed-by: Dong Aisheng
    Reviewed-by: Richard Fitzgerald
    Signed-off-by: Linus Walleij
    Signed-off-by: Greg Kroah-Hartman

    Fabio Estevam
     
  • commit 5cf9a338db94cfd570aa2607bef1b30996f188e3 upstream.

    All banks with GPIO interrupts should be at beginning of bank array and
    without any other types of banks between them. This order is expected
    by exynos_eint_gpio_irq, when doing interrupt group to bank translation.
    Otherwise, kernel NULL pointer dereference would happen when trying to
    handle interrupt, due to wrong bank being looked up. Observed on
    s5pv210, when trying to handle gpj0 interrupt, where kernel was mapping
    it to gpi bank.

    Cc: stable@vger.kernel.org
    Fixes: 023e06dfa688 ("pinctrl: exynos: add exynos5410 SoC specific data")
    Fixes: 608a26a7bc04 ("pinctrl: Add s5pv210 support to pinctrl-exynos)
    Signed-off-by: Paweł Chmiel
    Reviewed-by: Tomasz Figa
    Signed-off-by: Krzysztof Kozlowski
    Signed-off-by: Greg Kroah-Hartman

    Paweł Chmiel
     

05 Jun, 2018

1 commit

  • This reverts commit bd36ea57d6d58041180c4f7d2c2bf5194c26845d which is
    commit a7aa75a2a7dba32594291a71c3704000a2fd7089 upstream.

    There's been too many complaints about this. Personally I think it's
    going to blow up when people hit this in mainline, but hey, it's not my
    systems. At least we don't have to backport the mess to the stable
    kernels to give them some more life to live unscathed :)

    Reported-by: Timur Tabi
    Reported-by: Sebastian Gottschall
    Cc: Bjorn Andersson
    Cc: Linus Walleij
    Cc: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

30 May, 2018

3 commits

  • [ Upstream commit 9b3e4207661e67f04c72af15e29f74cd944f5964 ]

    The SPI version of this chip allows several devices to be present on the
    same SPI bus via a local address. If this is in action and if the kernel
    has debugfs, however, the code attempts to create duplicate entries for
    the regmap's debugfs:

    mcp23s08 spi1.1: Failed to create debugfs directory

    This patch simply assigns a local name matching the device logical
    address to the `struct regmap_config`.

    No changes are needed for MCP23S18 because that device does not support
    any logical addressing. Similarly, I2C devices do not need any action,
    either, because they are already different in their I2C address.

    A similar problem is present for the pinctrl debugfs instance, but that
    one is not addressed by this patch.

    Signed-off-by: Jan Kundrát
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Jan Kundrát
     
  • [ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]

    The base of the TLMM gpiochip should not be statically defined as 0, fix
    this to not artificially restrict the existence of multiple pinctrl-msm
    devices.

    Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
    Reported-by: Timur Tabi
    Signed-off-by: Bjorn Andersson
    Signed-off-by: Linus Walleij
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Bjorn Andersson
     
  • [ Upstream commit b418c4609d5052d174668ad6d13efe023c45c595 ]

    This patch fixes MOD_SEL1 bit20 and MOD_SEL2 bit20, bit21 pin assignment
    for SSI pins group.

    This is a correction to the incorrect implementation of MOD_SEL register
    pin assignment for R8A7796 SoC specification of R-Car Gen3 Hardware
    User's Manual Rev.0.51E or later.

    Fixes: f9aece7344bd ("pinctrl: sh-pfc: Initial R8A7796 PFC support")
    Signed-off-by: Takeshi Kihara
    Signed-off-by: Ulrich Hecht
    Reviewed-by: Simon Horman
    Signed-off-by: Geert Uytterhoeven
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Takeshi Kihara