* [PATCH 4/4] gpio: Update documentation with ast2600 controllers
From: Rashmica Gupta @ 2019-09-04 6:12 UTC (permalink / raw)
To: linus.walleij, linux-gpio, bgolaszewski
Cc: linux-arm-kernel, linux-aspeed, linux-kernel, joel, andrew,
Rashmica Gupta
In-Reply-To: <20190904061245.30770-1-rashmica.g@gmail.com>
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
index 7e9b586770b0..cd388797e07c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
@@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings
-------------------------------------------
Required properties:
-- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio"
+- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio",
+ "aspeed,ast2600-gpio", or "aspeed,ast2600-1-8v-gpio"
- #gpio-cells : Should be two
- First cell is the GPIO line number
--
2.20.1
^ permalink raw reply related
* [PATCH 3/4] gpio: Add in ast2600 details to Aspeed driver
From: Rashmica Gupta @ 2019-09-04 6:12 UTC (permalink / raw)
To: linus.walleij, linux-gpio, bgolaszewski
Cc: linux-arm-kernel, linux-aspeed, linux-kernel, joel, andrew,
Rashmica Gupta
In-Reply-To: <20190904061245.30770-1-rashmica.g@gmail.com>
The ast2600 has two gpio controllers, one for 3.6V GPIOS and one for 1.8V GPIOS.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 29 +++++++++++++++++++++++++++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 60ab042c9129..98881c99d0b9 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -662,12 +662,14 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct irq_chip *ic = irq_desc_get_chip(desc);
struct aspeed_gpio *data = gpiochip_get_data(gc);
- unsigned int i, p, girq;
+ unsigned int i, p, girq, banks;
unsigned long reg;
+ struct aspeed_gpio *gpio = gpiochip_get_data(gc);
chained_irq_enter(ic, desc);
- for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
+ banks = (gpio->config->nr_gpios >> 5) + 1;
+ for (i = 0; i < banks; i++) {
const struct aspeed_gpio_bank *bank = &aspeed_gpio_banks[i];
reg = ioread32(bank_reg(data, bank, reg_irq_status));
@@ -1108,9 +1110,32 @@ static const struct aspeed_gpio_config ast2500_config =
/* 232 for simplicity, actual number is 228 (4-GPIO hole in GPIOAB) */
{ .nr_gpios = 232, .props = ast2500_bank_props, };
+static const struct aspeed_bank_props ast2600_bank_props[] = {
+ /* input output */
+ {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
+ {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
+ { },
+};
+
+static const struct aspeed_gpio_config ast2600_config =
+ /* 208 3.6V GPIOs */
+ { .nr_gpios = 208, .props = ast2600_bank_props, };
+
+static const struct aspeed_bank_props ast2600_1_8v_bank_props[] = {
+ /* input output */
+ {1, 0x0000000f, 0x0000000f}, /* E */
+ { },
+};
+
+static const struct aspeed_gpio_config ast2600_1_8v_config =
+ /* 36 1.8V GPIOs */
+ { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
+
static const struct of_device_id aspeed_gpio_of_table[] = {
{ .compatible = "aspeed,ast2400-gpio", .data = &ast2400_config, },
{ .compatible = "aspeed,ast2500-gpio", .data = &ast2500_config, },
+ { .compatible = "aspeed,ast2600-gpio", .data = &ast2600_config, },
+ { .compatible = "aspeed,ast2600-1-8v-gpio", .data = &ast2600_1_8v_config,},
{}
};
MODULE_DEVICE_TABLE(of, aspeed_gpio_of_table);
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] gpio/aspeed: Setup irqchip dynamically
From: Rashmica Gupta @ 2019-09-04 6:12 UTC (permalink / raw)
To: linus.walleij, linux-gpio, bgolaszewski
Cc: linux-arm-kernel, linux-aspeed, linux-kernel, joel, andrew,
Rashmica Gupta
In-Reply-To: <20190904061245.30770-1-rashmica.g@gmail.com>
This is in preparation for ast2600 as we will have two gpio drivers
which need their own irqchip.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 77752b2624e8..60ab042c9129 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -52,6 +52,7 @@ struct aspeed_gpio_config {
*/
struct aspeed_gpio {
struct gpio_chip chip;
+ struct irq_chip irqc;
spinlock_t lock;
void __iomem *base;
int irq;
@@ -681,14 +682,6 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(ic, desc);
}
-static struct irq_chip aspeed_gpio_irqchip = {
- .name = "aspeed-gpio",
- .irq_ack = aspeed_gpio_irq_ack,
- .irq_mask = aspeed_gpio_irq_mask,
- .irq_unmask = aspeed_gpio_irq_unmask,
- .irq_set_type = aspeed_gpio_set_type,
-};
-
static void set_irq_valid_mask(struct aspeed_gpio *gpio)
{
const struct aspeed_bank_props *props = gpio->config->props;
@@ -1192,7 +1185,12 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->irq = rc;
girq = &gpio->chip.irq;
- girq->chip = &aspeed_gpio_irqchip;
+ girq->chip = &gpio->irqc;
+ girq->chip->name = dev_name(&pdev->dev);
+ girq->chip->irq_ack = aspeed_gpio_irq_ack;
+ girq->chip->irq_mask = aspeed_gpio_irq_mask;
+ girq->chip->irq_unmask = aspeed_gpio_irq_unmask;
+ girq->chip->irq_set_type = aspeed_gpio_set_type;
girq->parent_handler = aspeed_gpio_irq_handler;
girq->num_parents = 1;
girq->parents = devm_kcalloc(&pdev->dev, 1,
--
2.20.1
^ permalink raw reply related
* [PATCH 1/4] gpio/aspeed: Fix incorrect number of banks
From: Rashmica Gupta @ 2019-09-04 6:12 UTC (permalink / raw)
To: linus.walleij, linux-gpio, bgolaszewski
Cc: linux-arm-kernel, linux-aspeed, linux-kernel, joel, andrew,
Rashmica Gupta
Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 9defe25d4721..77752b2624e8 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->chip.base = -1;
/* Allocate a cache of the output registers */
- banks = gpio->config->nr_gpios >> 5;
+ banks = (gpio->config->nr_gpios >> 5) + 1;
gpio->dcache = devm_kcalloc(&pdev->dev,
banks, sizeof(u32), GFP_KERNEL);
if (!gpio->dcache)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings
From: Harish Jenny K N @ 2019-09-04 4:58 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, robh
Cc: Bartosz Golaszewski, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Balasubramani Vivekanandan
In-Reply-To: <6673873d-3ed2-ba98-8448-8047eccc994f@mentor.com>
Hi Rob, Hi Linus,
On 30/08/19 10:51 AM, Harish Jenny K N wrote:
> Hi Rob,
>
>
> On 27/08/19 1:17 PM, Harish Jenny K N wrote:
>> Hi Rob,
>>
>>
>> On 19/08/19 3:06 PM, Harish Jenny K N wrote:
>>> Hi Rob,
>>>
>>>
>>> On 10/08/19 2:21 PM, Linus Walleij wrote:
>>>> On Fri, Aug 9, 2019 at 4:08 PM Rob Herring <robh+dt@kernel.org> wrote:
>>>>> On Mon, Aug 5, 2019 at 5:15 AM Linus Walleij <linus.walleij@linaro.org> wrote:
>>>>>> There is some level of ambition here which is inherently a bit fuzzy
>>>>>> around the edges. ("How long is the coast of Britain?" comes to mind.)
>>>>>>
>>>>>> Surely the intention of device tree is not to recreate the schematic
>>>>>> in all detail. What we want is a model of the hardware that will
>>>>>> suffice for the operating system usecases.
>>>>>>
>>>>>> But sometimes the DTS files will become confusing: why is this
>>>>>> component using GPIO_ACTIVE_LOW when another system
>>>>>> doesn't have that flag? If there is an explicit inverter, the
>>>>>> DTS gets more readable for a human.
>>>>>>
>>>>>> But arguable that is case for adding inverters as syntactic
>>>>>> sugar in the DTS compiler instead...
>>>>> If you really want something more explicit, then add a new GPIO
>>>>> 'inverted' flag. Then a device can always have the same HIGH/LOW flag.
>>>>> That also solves the abstract it for userspace problem.
>>>> I think there are some intricate ontologies at work here.
>>>>
>>>> Consider this example: a GPIO is controlling a chip select
>>>> regulator, say Acme Foo. The chip select
>>>> has a pin named CSN. We know from convention that the
>>>> "N" at the end of that pin name means "negative" i.e. active
>>>> low, and that is how the electronics engineers think about
>>>> that chip select line: it activates the IC when
>>>> the line goes low.
>>>>
>>>> The regulator subsystem and I think all subsystems in the
>>>> Linux kernel say the consumer pin should be named and
>>>> tagged after the datsheet of the regulator.
>>>>
>>>> So it has for example:
>>>>
>>>> foo {
>>>> compatible = "acme,foo";
>>>> cs-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
>>>> };
>>>>
>>>> (It would be inappropriate to name it "csn-gpios" since
>>>> we have an established flag for active low. But it is another
>>>> of these syntactic choices where people likely do mistakes.)
>>>>
>>>> I think it would be appropriate for the DT binding to say
>>>> that this flag must always be GPIO_ACTIVE_LOW since
>>>> the bindings are seen from the component point of view,
>>>> and thus this is always active low.
>>>>
>>>> It would even be reasonable for a yaml schema to enfore
>>>> this, if it could. It is defined as active low after all.
>>>>
>>>> Now if someone adds an inverter on that line between
>>>> gpio0 and Acme Foo it looks like this:
>>>>
>>>> foo {
>>>> compatible = "acme,foo";
>>>> cs-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>>> };
>>>>
>>>> And now we get cognitive dissonance or whatever I should
>>>> call it: someone reading this DTS sheet and the data
>>>> sheet for the component Acme Foo to troubleshoot
>>>> this will be confused: this component has CS active
>>>> low and still it is specified as active high? Unless they
>>>> also look at the schematic or the board and find the
>>>> inverter things are pretty muddy and they will likely curse
>>>> and solve the situation with the usual trial-and-error,
>>>> inserting some random cursewords as a comment.
>>>>
>>>> With an intermediate inverter node, the cs-gpios
>>>> can go back to GPIO_ACTIVE_LOW and follow
>>>> the bindings:
>>>>
>>>> inv0: inverter {
>>>> compatible = "gpio-inverter";
>>>> gpio-controller;
>>>> #gpio-cells = <1>;
>>>> inverted-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>>> };
>>>>
>>>> foo {
>>>> compatible = "acme,foo";
>>>> cs-gpios = <&inv0 0 GPIO_ACTIVE_LOW>;
>>>> };
>>>>
>>>> And now Acme Foo bindings can keep enforcing cs-gpios
>>>> to always be tagged GPIO_ACTIVE_LOW.
>>> Can you please review/let us know your opinion on this ? I think the idea here is to also isolate the changes to a separate consumer driver and avoid getting inversions inside gpiolib.
>>>
>>>
>>> Thanks.
>>>
>>>
>>> Regards,
>>>
>>> Harish Jenny K N
>>>
>> Can you please comment on this ?
>>
>>
>> Thanks,
>>
>> Harish Jenny K N
>>
> Friendly Reminder.
>
> can we please finalize this ?
>
> Linus has also mentioned in another patchset "[PATCH v2] Input: tsc2007 - use GPIO descriptor" that
>
> he is in favor of introducing explicit inverters in device tree.
>
>
> Please consider this and let us know your inputs.
>
>
>
> Thanks,
>
> Harish Jenny K N
>
Can we please finalize this ?
Sorry for the repeated emails.
Am I missing something here ? I am not getting replies.
Thanks,
Harish Jenny K N
^ permalink raw reply
* Re: [PATCH] pinctrl: qcom: sdm845: Fix UFS_RESET pin
From: Bjorn Andersson @ 2019-09-04 4:10 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-kernel, linux-arm-msm, linux-gpio, Linus Walleij,
Andy Gross
In-Reply-To: <20190830060227.12792-1-swboyd@chromium.org>
On Thu 29 Aug 23:02 PDT 2019, Stephen Boyd wrote:
> The UFS_RESET pin is the magical pin #150 now, not 153 per the
> sdm845_groups array declared in this file. Fix the order of pins so that
> UFS_RESET is 150 and the SDC pins follow after.
>
Woops, thanks
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Fixes: 53a5372ce326 ("pinctrl: qcom: sdm845: Expose ufs_reset as gpio")
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
> drivers/pinctrl/qcom/pinctrl-sdm845.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-sdm845.c b/drivers/pinctrl/qcom/pinctrl-sdm845.c
> index 39f498c09906..ce495970459d 100644
> --- a/drivers/pinctrl/qcom/pinctrl-sdm845.c
> +++ b/drivers/pinctrl/qcom/pinctrl-sdm845.c
> @@ -262,10 +262,10 @@ static const struct pinctrl_pin_desc sdm845_pins[] = {
> PINCTRL_PIN(147, "GPIO_147"),
> PINCTRL_PIN(148, "GPIO_148"),
> PINCTRL_PIN(149, "GPIO_149"),
> - PINCTRL_PIN(150, "SDC2_CLK"),
> - PINCTRL_PIN(151, "SDC2_CMD"),
> - PINCTRL_PIN(152, "SDC2_DATA"),
> - PINCTRL_PIN(153, "UFS_RESET"),
> + PINCTRL_PIN(150, "UFS_RESET"),
> + PINCTRL_PIN(151, "SDC2_CLK"),
> + PINCTRL_PIN(152, "SDC2_CMD"),
> + PINCTRL_PIN(153, "SDC2_DATA"),
> };
>
> #define DECLARE_MSM_GPIO_PINS(pin) \
> --
> Sent by a computer through tubes
>
^ permalink raw reply
* linusw/for-next boot: 60 boots: 2 failed, 58 passed (v5.3-rc6-62-g0f40dd225a88)
From: kernelci.org bot @ 2019-09-04 0:43 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/for-next boot: 60 boots: 2 failed, 58 passed (v5.3-rc6-62-g0f40dd225a88)
Full Boot Summary: https://kernelci.org/boot/all/job/linusw/branch/for-next/kernel/v5.3-rc6-62-g0f40dd225a88/
Full Build Summary: https://kernelci.org/build/linusw/branch/for-next/kernel/v5.3-rc6-62-g0f40dd225a88/
Tree: linusw
Branch: for-next
Git Describe: v5.3-rc6-62-g0f40dd225a88
Git Commit: 0f40dd225a8823102f558bc9f0b663e8bb4be32d
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Tested: 45 unique boards, 14 SoC families, 3 builds out of 6
Boot Regressions Detected:
arm64:
defconfig:
gcc-8:
meson-gxl-s805x-libretech-ac:
lab-baylibre: new failure (last pass: v5.3-rc6-51-g1fc4f3c962b7)
meson-gxl-s905d-p230:
lab-baylibre: new failure (last pass: v5.3-rc6-51-g1fc4f3c962b7)
Boot Failures Detected:
arm64:
defconfig:
gcc-8:
meson-gxl-s805x-libretech-ac: 1 failed lab
meson-gxl-s905d-p230: 1 failed lab
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* linusw/for-next build: 6 builds: 0 failed, 6 passed, 30 warnings (v5.3-rc6-62-g0f40dd225a88)
From: kernelci.org bot @ 2019-09-03 23:58 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/for-next build: 6 builds: 0 failed, 6 passed, 30 warnings (v5.3-rc6-62-g0f40dd225a88)
Full Build Summary: https://kernelci.org/build/linusw/branch/for-next/kernel/v5.3-rc6-62-g0f40dd225a88/
Tree: linusw
Branch: for-next
Git Describe: v5.3-rc6-62-g0f40dd225a88
Git Commit: 0f40dd225a8823102f558bc9f0b663e8bb4be32d
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 6 unique architectures
Warnings Detected:
arc:
nsim_hs_defconfig (gcc-8): 5 warnings
arm64:
defconfig (gcc-8): 3 warnings
arm:
multi_v7_defconfig (gcc-8): 19 warnings
mips:
32r2el_defconfig (gcc-8): 3 warnings
riscv:
x86_64:
Warnings summary:
5 <stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:800:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:795:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
2 drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
1 arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:795:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:800:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 19 warnings, 0 section mismatches
Warnings:
drivers/dma/imx-dma.c:542:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2415:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2422:28: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/mmc/host/atmel-mci.c:2426:40: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:795:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:800:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:2086:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/video/fbdev/sh_mobile_lcdcfb.c:1596:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:424:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:440:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:459:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:332:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:352:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/usb/phy/phy-ab8500-usb.c:370:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:853:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/gpu/drm/sti/sti_hdmi.c:855:13: warning: this statement may fall through [-Wimplicit-fallthrough=]
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 5 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
include/linux/compiler.h:328:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:827:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
arch/arc/kernel/unwind.c:836:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* [PATCH] gpiolib: of: fix fallback quirks handling
From: Dmitry Torokhov @ 2019-09-03 23:18 UTC (permalink / raw)
To: Linus Walleij
Cc: Andy Shevchenko, Andreas Kemnade, linux-gpio, linux-spi,
linux-kernel
We should only try to execute fallback quirks handling when previous
call returned -ENOENT, and not when we did not get -EPROBE_DEFER.
The other errors should be treated as hard errors: we did find the GPIO
description, but for some reason we failed to handle it properly.
The fallbacks should only be executed when previous handlers returned
-ENOENT, which means the mapping/description was not found.
Also let's remove the explicit deferral handling when iterating through
GPIO suffixes: it is not needed anymore as we will not be calling
fallbacks for anything but -ENOENT.
Fixes: df451f83e1fc ("gpio: of: fix Freescale SPI CS quirk handling")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/gpio/gpiolib-of.c | 27 +++++++++------------------
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index b034abe59f28..b45b39c48a34 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -457,36 +457,27 @@ struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
desc = of_get_named_gpiod_flags(dev->of_node, prop_name, idx,
&of_flags);
- /*
- * -EPROBE_DEFER in our case means that we found a
- * valid GPIO property, but no controller has been
- * registered so far.
- *
- * This means we don't need to look any further for
- * alternate name conventions, and we should really
- * preserve the return code for our user to be able to
- * retry probing later.
- */
- if (IS_ERR(desc) && PTR_ERR(desc) == -EPROBE_DEFER)
- return desc;
- if (!IS_ERR(desc) || (PTR_ERR(desc) != -ENOENT))
+ if (!IS_ERR(desc) || PTR_ERR(desc) != -ENOENT)
break;
}
- /* Special handling for SPI GPIOs if used */
- if (IS_ERR(desc))
+ if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT) {
+ /* Special handling for SPI GPIOs if used */
desc = of_find_spi_gpio(dev, con_id, &of_flags);
- if (IS_ERR(desc) && PTR_ERR(desc) != -EPROBE_DEFER) {
+ }
+
+ if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT) {
/* This quirk looks up flags and all */
desc = of_find_spi_cs_gpio(dev, con_id, idx, flags);
if (!IS_ERR(desc))
return desc;
}
- /* Special handling for regulator GPIOs if used */
- if (IS_ERR(desc) && PTR_ERR(desc) != -EPROBE_DEFER)
+ if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT) {
+ /* Special handling for regulator GPIOs if used */
desc = of_find_regulator_gpio(dev, con_id, &of_flags);
+ }
if (IS_ERR(desc))
return desc;
--
2.23.0.187.g17f5b7556c-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH RFC 03/14] drivers: irqchip: add PDC irqdomain for wakeup capable GPIOs
From: Stephen Boyd @ 2019-09-03 22:51 UTC (permalink / raw)
To: Lina Iyer, evgreen, linus.walleij, marc.zyngier
Cc: linux-kernel, linux-arm-msm, bjorn.andersson, mkshah, linux-gpio,
rnayak, Lina Iyer
In-Reply-To: <20190829181203.2660-4-ilina@codeaurora.org>
Quoting Lina Iyer (2019-08-29 11:11:52)
> Introduce a new domain for wakeup capable GPIOs. The domain can be
> requested using the bus token DOMAIN_BUS_WAKEUP. In the following
> patches, we will specify PDC as the wakeup-parent for the TLMM GPIO
> irqchip. Requesting a wakeup GPIO will setup the GPIO and the
> corresponding PDC interrupt as its parent.
>
> Co-developed-by: Stephen Boyd <swboyd@chromium.org>
Per the Documentation about Co-developed-by this should have my
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
here. Please add it for the next version.
> Signed-off-by: Lina Iyer <ilina@codeaurora.org>
> ---
> drivers/irqchip/qcom-pdc.c | 104 ++++++++++++++++++++++++++++++++---
> include/linux/soc/qcom/irq.h | 34 ++++++++++++
> 2 files changed, 129 insertions(+), 9 deletions(-)
> create mode 100644 include/linux/soc/qcom/irq.h
>
> diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
> index 338fae604af5..ad1faf634bcf 100644
> --- a/drivers/irqchip/qcom-pdc.c
> +++ b/drivers/irqchip/qcom-pdc.c
> @@ -244,6 +261,60 @@ static const struct irq_domain_ops qcom_pdc_ops = {
> .free = irq_domain_free_irqs_common,
> };
>
> +static int qcom_pdc_gpio_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *data)
> +{
> + struct irq_fwspec *fwspec = data;
> + struct irq_fwspec parent_fwspec;
> + irq_hw_number_t hwirq, parent_hwirq;
> + unsigned int type;
> + int ret;
> +
> + ret = qcom_pdc_translate(domain, fwspec, &hwirq, &type);
> + if (ret)
> + return ret;
> +
> + ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> + &qcom_pdc_gic_chip, NULL);
> + if (ret)
> + return ret;
> +
> + if (hwirq == GPIO_NO_WAKE_IRQ)
> + return 0;
> +
> + parent_hwirq = get_parent_hwirq(hwirq);
> + if (parent_hwirq == PDC_NO_PARENT_IRQ)
> + return 0;
> +
> + if (type & IRQ_TYPE_EDGE_BOTH)
> + type = IRQ_TYPE_EDGE_RISING;
> +
> + if (type & IRQ_TYPE_LEVEL_MASK)
> + type = IRQ_TYPE_LEVEL_HIGH;
> +
> + parent_fwspec.fwnode = domain->parent->fwnode;
> + parent_fwspec.param_count = 3;
> + parent_fwspec.param[0] = 0;
> + parent_fwspec.param[1] = parent_hwirq;
> + parent_fwspec.param[2] = type;
> +
> + return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
> + &parent_fwspec);
> +}
> +
> +static int qcom_pdc_gpio_domain_select(struct irq_domain *d,
> + struct irq_fwspec *fwspec,
> + enum irq_domain_bus_token bus_token)
> +{
> + return (bus_token == DOMAIN_BUS_WAKEUP);
Drop the parenthesis please.
> +}
> +
> +static const struct irq_domain_ops qcom_pdc_gpio_ops = {
> + .select = qcom_pdc_gpio_domain_select,
> + .alloc = qcom_pdc_gpio_alloc,
> + .free = irq_domain_free_irqs_common,
> +};
> +
> static int pdc_setup_pin_mapping(struct device_node *np)
> {
> int ret, n;
> @@ -282,7 +353,7 @@ static int pdc_setup_pin_mapping(struct device_node *np)
>
> static int qcom_pdc_init(struct device_node *node, struct device_node *parent)
> {
> - struct irq_domain *parent_domain, *pdc_domain;
> + struct irq_domain *parent_domain, *pdc_domain, *pdc_gpio_domain;
> int ret;
>
> pdc_base = of_iomap(node, 0);
> @@ -313,8 +384,23 @@ static int qcom_pdc_init(struct device_node *node, struct device_node *parent)
> goto fail;
> }
>
> + pdc_gpio_domain = irq_domain_create_hierarchy(parent_domain,
> + IRQ_DOMAIN_FLAG_QCOM_PDC_WAKEUP,
> + PDC_MAX_GPIO_IRQS,
> + of_fwnode_handle(node),
> + &qcom_pdc_gpio_ops, NULL);
> + if (!pdc_gpio_domain) {
> + pr_err("%pOF: GIC domain add failed for GPIO domain\n", node);
s/GIC/PDC/?
> + ret = -ENOMEM;
> + goto remove;
> + }
> +
> + irq_domain_update_bus_token(pdc_gpio_domain, DOMAIN_BUS_WAKEUP);
> +
> return 0;
>
> +remove:
> + irq_domain_remove(pdc_domain);
> fail:
> kfree(pdc_region);
> iounmap(pdc_base);
> diff --git a/include/linux/soc/qcom/irq.h b/include/linux/soc/qcom/irq.h
> new file mode 100644
> index 000000000000..73239917dc38
> --- /dev/null
> +++ b/include/linux/soc/qcom/irq.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef __QCOM_IRQ_H
> +#define __QCOM_IRQ_H
> +
> +#include <linux/irqdomain.h>
Just forward declare struct irq_domain instead?
> +
> +#define GPIO_NO_WAKE_IRQ ~0U
> +
> +/**
> + * QCOM specific IRQ domain flags that distinguishes the handling of wakeup
> + * capable interrupts by different interrupt controllers.
> + *
> + * IRQ_DOMAIN_FLAG_QCOM_PDC_WAKEUP: Line must be masked at TLMM and the
> + * interrupt configuration is done at PDC
> + * IRQ_DOMAIN_FLAG_QCOM_MPM_WAKEUP: Interrupt configuration is handled at TLMM
> + */
> +#define IRQ_DOMAIN_FLAG_QCOM_PDC_WAKEUP (1 << 17)
> +#define IRQ_DOMAIN_FLAG_QCOM_MPM_WAKEUP (1 << 18)
Why do these numbers start at 17?
> +
> +/**
> + * irq_domain_qcom_handle_wakeup: Return if the domain handles interrupt
> + * configuration
> + * @parent: irq domain
> + *
> + * This QCOM specific irq domain call returns if the interrupt controller
> + * requires the interrupt be masked at the child interrupt controller.
> + */
> +static inline bool irq_domain_qcom_handle_wakeup(struct irq_domain *parent)
> +{
> + return (parent->flags & IRQ_DOMAIN_FLAG_QCOM_PDC_WAKEUP);
> +}
> +
> +#endif
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* linusw/devel boot: 53 boots: 1 failed, 52 passed (v5.3-rc1-58-g8a6abcd04e4c)
From: kernelci.org bot @ 2019-09-03 17:23 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/devel boot: 53 boots: 1 failed, 52 passed (v5.3-rc1-58-g8a6abcd04e4c)
Full Boot Summary: https://kernelci.org/boot/all/job/linusw/branch/devel/kernel/v5.3-rc1-58-g8a6abcd04e4c/
Full Build Summary: https://kernelci.org/build/linusw/branch/devel/kernel/v5.3-rc1-58-g8a6abcd04e4c/
Tree: linusw
Branch: devel
Git Describe: v5.3-rc1-58-g8a6abcd04e4c
Git Commit: 8a6abcd04e4cdf6088f11212570c3e5ec36ee5c3
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Tested: 42 unique boards, 15 SoC families, 3 builds out of 6
Boot Regressions Detected:
arm64:
defconfig:
gcc-8:
apq8016-sbc:
lab-mhart: failing since 35 days (last pass: v5.2-10808-g9637d517347e - first fail: v5.3-rc1-5-ga299726da44f)
Boot Failure Detected:
arm64:
defconfig:
gcc-8:
apq8016-sbc: 1 failed lab
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* Re: [PATCH RFC 05/14] dt-bindings/interrupt-controller: pdc: add SPI config register
From: Lina Iyer @ 2019-09-03 17:07 UTC (permalink / raw)
To: Marc Zyngier
Cc: Rob Herring, swboyd, evgreen, linus.walleij, linux-kernel,
linux-arm-msm, bjorn.andersson, mkshah, linux-gpio, rnayak,
devicetree
In-Reply-To: <102c9268-c4ce-6133-3b0a-67c2fcba1e7a@arm.com>
On Mon, Sep 02 2019 at 07:58 -0600, Marc Zyngier wrote:
>On 02/09/2019 14:38, Rob Herring wrote:
>> On Thu, Aug 29, 2019 at 12:11:54PM -0600, Lina Iyer wrote:
>>> In addition to configuring the PDC, additional registers that interface
>>> the GIC have to be configured to match the GPIO type. The registers on
>>> some QCOM SoCs are access restricted, while on other SoCs are not. They
>>> SoCs with access restriction to these SPI registers need to be written
>>
>> Took me a minute to figure out this is GIC SPI interrupts, not SPI bus.
>>
>>> from the firmware using the SCM interface. Add a flag to indicate if the
>>> register is to be written using SCM interface.
>>>
>>> Cc: devicetree@vger.kernel.org
>>> Signed-off-by: Lina Iyer <ilina@codeaurora.org>
>>> ---
>>> .../bindings/interrupt-controller/qcom,pdc.txt | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
>>> index 8e0797cb1487..852fcba98ea6 100644
>>> --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
>>> +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
>>> @@ -50,15 +50,22 @@ Properties:
>>> The second element is the GIC hwirq number for the PDC port.
>>> The third element is the number of interrupts in sequence.
>>>
>>> +- qcom,scm-spi-cfg:
>>> + Usage: optional
>>> + Value type: <bool>
>>> + Definition: Specifies if the SPI configuration registers have to be
>>> + written from the firmware.
>>> +
>>> Example:
>>>
>>> pdc: interrupt-controller@b220000 {
>>> compatible = "qcom,sdm845-pdc";
>>> - reg = <0xb220000 0x30000>;
>>> + reg = <0xb220000 0x30000>, <0x179900f0 0x60>;
>>
>> There needs to be a description for reg updated. These aren't GIC
>> registers are they? Because those go in the GIC node.
>
They are not GIC registers. I will update this documentation.
>This is completely insane. Why are the GIC registers configured as
>secure the first place, if they are expected to be in control of the
>non-secure?
These are not GIC registers but located on the PDC interface to the GIC.
They may or may not be secure access controlled, depending on the SoC.
Thanks,
Lina
^ permalink raw reply
* linusw/devel build: 6 builds: 0 failed, 6 passed, 13 warnings (v5.3-rc1-58-g8a6abcd04e4c)
From: kernelci.org bot @ 2019-09-03 16:38 UTC (permalink / raw)
To: linux-gpio, fellows
linusw/devel build: 6 builds: 0 failed, 6 passed, 13 warnings (v5.3-rc1-58-g8a6abcd04e4c)
Full Build Summary: https://kernelci.org/build/linusw/branch/devel/kernel/v5.3-rc1-58-g8a6abcd04e4c/
Tree: linusw
Branch: devel
Git Describe: v5.3-rc1-58-g8a6abcd04e4c
Git Commit: 8a6abcd04e4cdf6088f11212570c3e5ec36ee5c3
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/
Built: 6 unique architectures
Warnings Detected:
arc:
nsim_hs_defconfig (gcc-8): 2 warnings
arm64:
arm:
multi_v7_defconfig (gcc-8): 6 warnings
mips:
32r2el_defconfig (gcc-8): 3 warnings
riscv:
defconfig (gcc-8): 2 warnings
x86_64:
Warnings summary:
7 <stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
1 arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 6 warnings, 0 section mismatches
Warnings:
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:129.4-18: Warning (reg_format): /mdio-bus-mux/mdio@200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #address-cells value
arch/arm/boot/dts/bcm47094-linksys-panamera.dts:128.22-132.5: Warning (avoid_default_addr_size): /mdio-bus-mux/mdio@200: Relying on default #size-cells value
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
<stdin>:1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* [PATCH AUTOSEL 4.19 151/167] gpio: don't WARN() on NULL descs if gpiolib is disabled
From: Sasha Levin @ 2019-09-03 16:25 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bartosz Golaszewski, Claus H . Stovgaard, Sasha Levin, linux-gpio
In-Reply-To: <20190903162519.7136-1-sashal@kernel.org>
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
[ Upstream commit ffe0bbabb0cffceceae07484fde1ec2a63b1537c ]
If gpiolib is disabled, we use the inline stubs from gpio/consumer.h
instead of regular definitions of GPIO API. The stubs for 'optional'
variants of gpiod_get routines return NULL in this case as if the
relevant GPIO wasn't found. This is correct so far.
Calling other (non-gpio_get) stubs from this header triggers a warning
because the GPIO descriptor couldn't have been requested. The warning
however is unconditional (WARN_ON(1)) and is emitted even if the passed
descriptor pointer is NULL.
We don't want to force the users of 'optional' gpio_get to check the
returned pointer before calling e.g. gpiod_set_value() so let's only
WARN on non-NULL descriptors.
Cc: stable@vger.kernel.org
Reported-by: Claus H. Stovgaard <cst@phaseone.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/gpio/consumer.h | 62 +++++++++++++++++------------------
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index acc4279ad5e3f..412098b24f58b 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -222,7 +222,7 @@ static inline void gpiod_put(struct gpio_desc *desc)
might_sleep();
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
}
static inline void gpiod_put_array(struct gpio_descs *descs)
@@ -230,7 +230,7 @@ static inline void gpiod_put_array(struct gpio_descs *descs)
might_sleep();
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(descs);
}
static inline struct gpio_desc *__must_check
@@ -283,7 +283,7 @@ static inline void devm_gpiod_put(struct device *dev, struct gpio_desc *desc)
might_sleep();
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
}
static inline void devm_gpiod_put_array(struct device *dev,
@@ -292,32 +292,32 @@ static inline void devm_gpiod_put_array(struct device *dev,
might_sleep();
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(descs);
}
static inline int gpiod_get_direction(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -ENOSYS;
}
static inline int gpiod_direction_input(struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -ENOSYS;
}
static inline int gpiod_direction_output(struct gpio_desc *desc, int value)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -ENOSYS;
}
static inline int gpiod_direction_output_raw(struct gpio_desc *desc, int value)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -ENOSYS;
}
@@ -325,7 +325,7 @@ static inline int gpiod_direction_output_raw(struct gpio_desc *desc, int value)
static inline int gpiod_get_value(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return 0;
}
static inline int gpiod_get_array_value(unsigned int array_size,
@@ -333,25 +333,25 @@ static inline int gpiod_get_array_value(unsigned int array_size,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
return 0;
}
static inline void gpiod_set_value(struct gpio_desc *desc, int value)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
}
static inline void gpiod_set_array_value(unsigned int array_size,
struct gpio_desc **desc_array,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
}
static inline int gpiod_get_raw_value(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return 0;
}
static inline int gpiod_get_raw_array_value(unsigned int array_size,
@@ -359,27 +359,27 @@ static inline int gpiod_get_raw_array_value(unsigned int array_size,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
return 0;
}
static inline void gpiod_set_raw_value(struct gpio_desc *desc, int value)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
}
static inline int gpiod_set_raw_array_value(unsigned int array_size,
struct gpio_desc **desc_array,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
return 0;
}
static inline int gpiod_get_value_cansleep(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return 0;
}
static inline int gpiod_get_array_value_cansleep(unsigned int array_size,
@@ -387,25 +387,25 @@ static inline int gpiod_get_array_value_cansleep(unsigned int array_size,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
return 0;
}
static inline void gpiod_set_value_cansleep(struct gpio_desc *desc, int value)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
}
static inline void gpiod_set_array_value_cansleep(unsigned int array_size,
struct gpio_desc **desc_array,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
}
static inline int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return 0;
}
static inline int gpiod_get_raw_array_value_cansleep(unsigned int array_size,
@@ -413,55 +413,55 @@ static inline int gpiod_get_raw_array_value_cansleep(unsigned int array_size,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
return 0;
}
static inline void gpiod_set_raw_value_cansleep(struct gpio_desc *desc,
int value)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
}
static inline int gpiod_set_raw_array_value_cansleep(unsigned int array_size,
struct gpio_desc **desc_array,
int *value_array)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc_array);
return 0;
}
static inline int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -ENOSYS;
}
static inline int gpiod_set_transitory(struct gpio_desc *desc, bool transitory)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -ENOSYS;
}
static inline int gpiod_is_active_low(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return 0;
}
static inline int gpiod_cansleep(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return 0;
}
static inline int gpiod_to_irq(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -EINVAL;
}
@@ -469,7 +469,7 @@ static inline int gpiod_set_consumer_name(struct gpio_desc *desc,
const char *name)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -EINVAL;
}
@@ -481,7 +481,7 @@ static inline struct gpio_desc *gpio_to_desc(unsigned gpio)
static inline int desc_to_gpio(const struct gpio_desc *desc)
{
/* GPIO can never have been requested */
- WARN_ON(1);
+ WARN_ON(desc);
return -EINVAL;
}
--
2.20.1
^ permalink raw reply related
* Re: [GIT PULL] gpio: updates for v5.4
From: Linus Walleij @ 2019-09-03 14:05 UTC (permalink / raw)
To: Bartosz Golaszewski; +Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski
In-Reply-To: <20190903120214.16375-1-brgl@bgdev.pl>
Hi Bartosz,
On Tue, Sep 3, 2019 at 2:02 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> include/linux/gpio/driver.h | 27 +++----
I get some really serious merge conflicts from this (due to other patch from
Yue), but I did my best to sort it out, let's hope it builds and runs...
watch out for explosions :D
Yours,
Linus Walleij
^ permalink raw reply
* [GIT PULL] intel-pinctrl for v5.4
From: Mika Westerberg @ 2019-09-03 13:25 UTC (permalink / raw)
To: Linus Walleij; +Cc: Linux pin control, Andy Shevchenko, Mika Westerberg
Hi Linus,
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git tags/intel-pinctrl-v5.4
for you to fetch changes up to 6cb0880f08229360c6c57416de075aa96930be78:
pinctrl: intel: remap the pin number to gpio offset for irq enabled pin (2019-08-19 12:41:44 +0300)
----------------------------------------------------------------
intel-pinctrl for v5.4
A collection of improvements and fixes for Intel pinctrl drivers
including:
- Converting drivers to use new devm_platform_ioremap_resource()
helper function.
- Make Interrupt Status (IS) register configurable.
- Allow locked pins to be requested and used as long as they are not
modified.
- Fix intel_pinctrl_should_save() to translate pin number to GPIO
number where needed. This fixes Asus X571GT touchpad
unresponsiveness issue after suspend/resume cycle.
----------------------------------------------------------------
Andy Shevchenko (18):
pinctrl: baytrail: Use devm_platform_ioremap_resource()
pinctrl: cherryview: Use devm_platform_ioremap_resource()
pinctrl: intel: Use devm_platform_ioremap_resource()
pinctrl: merrifield: Use devm_platform_ioremap_resource()
pinctrl: intel: Drop double check for data in intel_pinctrl_probe_by_uid()
pinctrl: intel: Simplify offset validation in intel_get_padcfg()
pinctrl: broxton: Provide Interrupt Status register offset
pinctrl: cannonlake: Provide Interrupt Status register offset
pinctrl: geminilake: Provide Interrupt Status register offset
pinctrl: icelake: Provide Interrupt Status register offset
pinctrl: sunrisepoint: Provide Interrupt Status register offset
pinctrl: denverton: Provide Interrupt Status register offset
pinctrl: lewisburg: Provide Interrupt Status register offset
pinctrl: intel: Remove default Interrupt Status offset
pinctrl: baytrail: Re-use data structures from pinctrl-intel.h (part 2)
pinctrl: intel: Use NSEC_PER_USEC for debounce calculus
pinctrl: denverton: Update pin names according to v1.08
pinctrl: intel: Allow to request locked pads
Chris Chiu (1):
pinctrl: intel: remap the pin number to gpio offset for irq enabled pin
Stephen Boyd (2):
pinctrl: intel: Remove dev_err() usage after platform_get_irq()
pinctrl: cherryview: Remove dev_err() usage after platform_get_irq()
drivers/pinctrl/intel/pinctrl-baytrail.c | 67 +++++----------
drivers/pinctrl/intel/pinctrl-broxton.c | 4 +-
drivers/pinctrl/intel/pinctrl-cannonlake.c | 2 +
drivers/pinctrl/intel/pinctrl-cherryview.c | 8 +-
drivers/pinctrl/intel/pinctrl-denverton.c | 53 ++++++------
drivers/pinctrl/intel/pinctrl-geminilake.c | 2 +
drivers/pinctrl/intel/pinctrl-icelake.c | 2 +
drivers/pinctrl/intel/pinctrl-intel.c | 120 +++++++++++++++++++--------
drivers/pinctrl/intel/pinctrl-intel.h | 9 +-
drivers/pinctrl/intel/pinctrl-lewisburg.c | 2 +
drivers/pinctrl/intel/pinctrl-merrifield.c | 4 +-
drivers/pinctrl/intel/pinctrl-sunrisepoint.c | 2 +
12 files changed, 156 insertions(+), 119 deletions(-)
^ permalink raw reply
* [GIT PULL] gpio: updates for v5.4
From: Bartosz Golaszewski @ 2019-09-03 12:02 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio, Bartosz Golaszewski
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git tags/gpio-v5.4-updates-for-linus
for you to fetch changes up to f2ee73147a3f23cc4b032a76b5677b4b8441ba74:
gpio: lpc32xx: allow building on non-lpc32xx targets (2019-08-12 09:10:00 +0200)
----------------------------------------------------------------
gpio: updates for v5.4
- use a helper variable for &pdev->dev in gpio-em
- tweak the ifdefs in GPIO headers
- fix function links in HTML docs
- remove an unneeded error message from ixp4xx
- use the optional clk_get in gpio-mxc instead of checking the return value
- a couple improvements in pca953x
- allow to build gpio-lpc32xx on non-lpc32xx targets
----------------------------------------------------------------
Andy Shevchenko (4):
gpio: pca953x: Switch to use device_get_match_data()
gpio: pca953x: Use GENMASK() consistently
gpio: pca953x: Remove explicit comparison with 0
gpio: pca953x: Drop %s for constant string literals
Anson Huang (1):
gpio: mxc: Use devm_clk_get_optional instead of devm_clk_get
Arnd Bergmann (1):
gpio: lpc32xx: allow building on non-lpc32xx targets
Bartosz Golaszewski (1):
gpio: em: use a helper variable for &pdev->dev
Ding Xiang (1):
gpio: ixp4xx: remove redundant dev_err message
Jeremy Cline (1):
Documentation: gpio: fix function links in the HTML docs
Masahiro Yamada (1):
gpio: remove less important #ifdef around declarations
Documentation/driver-api/gpio/driver.rst | 16 ++---
arch/arm/configs/lpc32xx_defconfig | 1 +
drivers/gpio/Kconfig | 7 ++
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpio-em.c | 37 +++++-----
drivers/gpio/gpio-ixp4xx.c | 4 +-
drivers/gpio/gpio-lpc32xx.c | 118 ++++++++++++++++++-------------
drivers/gpio/gpio-mxc.c | 9 +--
drivers/gpio/gpio-pca953x.c | 70 +++++++++---------
include/linux/gpio/driver.h | 27 +++----
10 files changed, 149 insertions(+), 142 deletions(-)
^ permalink raw reply
* [BACKPORT 4.14.y 5/8] pinctrl: sprd: Use define directive for sprd_pinconf_params values
From: Baolin Wang @ 2019-09-03 6:59 UTC (permalink / raw)
To: stable, linus.walleij, natechancellor
Cc: linux-gpio, arnd, baolin.wang, orsonzhai, vincent.guittot,
linux-kernel
In-Reply-To: <cover.1567492316.git.baolin.wang@linaro.org>
From: Nathan Chancellor <natechancellor@gmail.com>
Clang warns when one enumerated type is implicitly converted to another:
drivers/pinctrl/sprd/pinctrl-sprd.c:845:19: warning: implicit conversion
from enumeration type 'enum sprd_pinconf_params' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"sprd,control", SPRD_PIN_CONFIG_CONTROL, 0},
~ ^~~~~~~~~~~~~~~~~~~~~~~
drivers/pinctrl/sprd/pinctrl-sprd.c:846:22: warning: implicit conversion
from enumeration type 'enum sprd_pinconf_params' to different
enumeration type 'enum pin_config_param' [-Wenum-conversion]
{"sprd,sleep-mode", SPRD_PIN_CONFIG_SLEEP_MODE, 0},
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
It is expected that pinctrl drivers can extend pin_config_param because
of the gap between PIN_CONFIG_END and PIN_CONFIG_MAX so this conversion
isn't an issue. Most drivers that take advantage of this define the
PIN_CONFIG variables as constants, rather than enumerated values. Do the
same thing here so that Clang no longer warns.
Link: https://github.com/ClangBuiltLinux/linux/issues/138
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
---
drivers/pinctrl/sprd/pinctrl-sprd.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/sprd/pinctrl-sprd.c b/drivers/pinctrl/sprd/pinctrl-sprd.c
index 6352991..83958bd 100644
--- a/drivers/pinctrl/sprd/pinctrl-sprd.c
+++ b/drivers/pinctrl/sprd/pinctrl-sprd.c
@@ -159,10 +159,8 @@ struct sprd_pinctrl {
struct sprd_pinctrl_soc_info *info;
};
-enum sprd_pinconf_params {
- SPRD_PIN_CONFIG_CONTROL = PIN_CONFIG_END + 1,
- SPRD_PIN_CONFIG_SLEEP_MODE = PIN_CONFIG_END + 2,
-};
+#define SPRD_PIN_CONFIG_CONTROL (PIN_CONFIG_END + 1)
+#define SPRD_PIN_CONFIG_SLEEP_MODE (PIN_CONFIG_END + 2)
static int sprd_pinctrl_get_id_by_name(struct sprd_pinctrl *sprd_pctl,
const char *name)
--
1.7.9.5
^ permalink raw reply related
* [BACKPORT 4.14.y 0/8] Candidates from Spreadtrum 4.14 product kernel
From: Baolin Wang @ 2019-09-03 6:53 UTC (permalink / raw)
To: stable, chris, airlied, davem, kuznet, yoshfuji, edumazet, peterz,
mingo, vyasevich, nhorman, linus.walleij, natechancellor, sre,
paulus, gregkh
Cc: intel-gfx, dri-devel, netdev, longman, hariprasad.kelam,
linux-sctp, linux-gpio, david, linux-pm, ebiggers, linux-ppp,
lanqing.liu, linux-serial, arnd, baolin.wang, orsonzhai,
vincent.guittot, linux-kernel
With Arnd's script [1] help, I found some bugfixes in Spreadtrum 4.14 product
kernel, but missing in v4.14.141:
86fda90ab588 net: sctp: fix warning "NULL check before some freeing functions is not needed"
25a09ce79639 ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
d9b308b1f8a1 drm/i915/fbdev: Actually configure untiled displays
47d3d7fdb10a ip6: fix skb leak in ip6frag_expire_frag_queue()
5b9cea15a3de serial: sprd: Modify the baud rate calculation formula
513e1073d52e locking/lockdep: Add debug_locks check in __lock_downgrade()
957063c92473 pinctrl: sprd: Use define directive for sprd_pinconf_params values
87a2b65fc855 power: supply: sysfs: ratelimit property read error message
[1] https://lore.kernel.org/lkml/20190322154425.3852517-19-arnd@arndb.de/T/
Chris Wilson (1):
drm/i915/fbdev: Actually configure untiled displays
David Lechner (1):
power: supply: sysfs: ratelimit property read error message
Eric Biggers (1):
ppp: mppe: Revert "ppp: mppe: Add softdep to arc4"
Eric Dumazet (1):
ip6: fix skb leak in ip6frag_expire_frag_queue()
Hariprasad Kelam (1):
net: sctp: fix warning "NULL check before some freeing functions is
not needed"
Lanqing Liu (1):
serial: sprd: Modify the baud rate calculation formula
Nathan Chancellor (1):
pinctrl: sprd: Use define directive for sprd_pinconf_params values
Waiman Long (1):
locking/lockdep: Add debug_locks check in __lock_downgrade()
drivers/gpu/drm/i915/intel_fbdev.c | 12 +++++++-----
drivers/net/ppp/ppp_mppe.c | 1 -
drivers/pinctrl/sprd/pinctrl-sprd.c | 6 ++----
drivers/power/supply/power_supply_sysfs.c | 3 ++-
drivers/tty/serial/sprd_serial.c | 2 +-
include/net/ipv6_frag.h | 1 -
kernel/locking/lockdep.c | 3 +++
net/sctp/sm_make_chunk.c | 12 ++++--------
8 files changed, 19 insertions(+), 21 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: acpi: add quirk to override GpioInt polarity
From: Andy Shevchenko @ 2019-09-02 16:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Peter Cai, Rafael J. Wysocki, Len Brown, Mika Westerberg,
Bartosz Golaszewski, Bastien Nocera, Dmitry Torokhov,
open list:GPIO SUBSYSTEM, ACPI Devel Maling List,
linux-kernel@vger.kernel.org, Linux Input
In-Reply-To: <CACRpkdaY_TT_m3XEh_J9TqMQijzUieQDBn+t4=uGUyfP+V0Hzg@mail.gmail.com>
On Mon, Sep 02, 2019 at 03:36:24PM +0200, Linus Walleij wrote:
> On Mon, Sep 2, 2019 at 12:01 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Sat, Aug 31, 2019 at 11:09:14AM +0800, Peter Cai wrote:
> > > On GPD P2 Max, the firmware could not reset the touch panel correctly.
> > > The kernel needs to take on the job instead, but the GpioInt definition
> > > in DSDT specifies ActiveHigh while the GPIO pin should actually be
> > > ActiveLow.
> > >
> > > We need to override the polarity defined by DSDT. The GPIO driver
> > > already allows defining polarity in acpi_gpio_params, but the option is
> > > not applied to GpioInt.
> > >
> > > This patch adds a new quirk that enables the polarity specified in
> > > acpi_gpio_params to also be applied to GpioInt.
> >
> > Thank you for an update!
> >
> > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > on the condition that Dmitry and other input / Goodix developers are okay with
> > the approach in general.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> In case Dmitry needs to merge this.
>
> Or should I simply merge this patch to the GPIO tree?
For my opinion Input subsystem should decide how to proceed with this.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] pinctrl-mcp23s08: Fix property-name in dt-example
From: Rob Herring @ 2019-09-02 14:40 UTC (permalink / raw)
To: Peter Vernia
Cc: peter.vernia, linus.walleij, robh+dt, mark.rutland, linux-gpio,
devicetree, linux-kernel, poeschel
In-Reply-To: <20190828195609.4176-1-peter.vernia@gmail.com>
On Wed, 28 Aug 2019 15:56:09 -0400, Peter Vernia wrote:
> The device-tree properties documentation-file specifies the property
> "microchip,spi-present-mask" as required for MCP23SXX chips. However,
> the device-tree-source example below it uses only "spi-present-mask".
> Without "microchip," on the front, the driver will print "missing
> spi-present-mask" when it initializes.
>
> Update the device-tree example with the correct property-name.
>
> Signed-off-by: Peter Vernia <peter.vernia@gmail.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH RFC 05/14] dt-bindings/interrupt-controller: pdc: add SPI config register
From: Marc Zyngier @ 2019-09-02 13:53 UTC (permalink / raw)
To: Rob Herring, Lina Iyer
Cc: swboyd, evgreen, linus.walleij, linux-kernel, linux-arm-msm,
bjorn.andersson, mkshah, linux-gpio, rnayak, devicetree
In-Reply-To: <5d6d1b72.1c69fb81.ee88.efcf@mx.google.com>
On 02/09/2019 14:38, Rob Herring wrote:
> On Thu, Aug 29, 2019 at 12:11:54PM -0600, Lina Iyer wrote:
>> In addition to configuring the PDC, additional registers that interface
>> the GIC have to be configured to match the GPIO type. The registers on
>> some QCOM SoCs are access restricted, while on other SoCs are not. They
>> SoCs with access restriction to these SPI registers need to be written
>
> Took me a minute to figure out this is GIC SPI interrupts, not SPI bus.
>
>> from the firmware using the SCM interface. Add a flag to indicate if the
>> register is to be written using SCM interface.
>>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Lina Iyer <ilina@codeaurora.org>
>> ---
>> .../bindings/interrupt-controller/qcom,pdc.txt | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
>> index 8e0797cb1487..852fcba98ea6 100644
>> --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
>> +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
>> @@ -50,15 +50,22 @@ Properties:
>> The second element is the GIC hwirq number for the PDC port.
>> The third element is the number of interrupts in sequence.
>>
>> +- qcom,scm-spi-cfg:
>> + Usage: optional
>> + Value type: <bool>
>> + Definition: Specifies if the SPI configuration registers have to be
>> + written from the firmware.
>> +
>> Example:
>>
>> pdc: interrupt-controller@b220000 {
>> compatible = "qcom,sdm845-pdc";
>> - reg = <0xb220000 0x30000>;
>> + reg = <0xb220000 0x30000>, <0x179900f0 0x60>;
>
> There needs to be a description for reg updated. These aren't GIC
> registers are they? Because those go in the GIC node.
This is completely insane. Why are the GIC registers configured as
secure the first place, if they are expected to be in control of the
non-secure?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH RFC 04/14] of: irq: document properties for wakeup interrupt parent
From: Rob Herring @ 2019-09-02 13:38 UTC (permalink / raw)
To: Lina Iyer
Cc: swboyd, evgreen, marc.zyngier, linus.walleij, linux-kernel,
linux-arm-msm, bjorn.andersson, mkshah, linux-gpio, rnayak,
Lina Iyer, devicetree
In-Reply-To: <20190829181203.2660-5-ilina@codeaurora.org>
On Thu, 29 Aug 2019 12:11:53 -0600, Lina Iyer wrote:
> Some interrupt controllers in a SoC, are always powered on and have a
> select interrupts routed to them, so that they can wakeup the SoC from
> suspend. Add wakeup-parent DT property to refer to these interrupt
> controllers.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Lina Iyer <ilina@codeaurora.org>
> ---
> .../bindings/interrupt-controller/interrupts.txt | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC 05/14] dt-bindings/interrupt-controller: pdc: add SPI config register
From: Rob Herring @ 2019-09-02 13:38 UTC (permalink / raw)
To: Lina Iyer
Cc: swboyd, evgreen, marc.zyngier, linus.walleij, linux-kernel,
linux-arm-msm, bjorn.andersson, mkshah, linux-gpio, rnayak,
devicetree
In-Reply-To: <20190829181203.2660-6-ilina@codeaurora.org>
On Thu, Aug 29, 2019 at 12:11:54PM -0600, Lina Iyer wrote:
> In addition to configuring the PDC, additional registers that interface
> the GIC have to be configured to match the GPIO type. The registers on
> some QCOM SoCs are access restricted, while on other SoCs are not. They
> SoCs with access restriction to these SPI registers need to be written
Took me a minute to figure out this is GIC SPI interrupts, not SPI bus.
> from the firmware using the SCM interface. Add a flag to indicate if the
> register is to be written using SCM interface.
>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Lina Iyer <ilina@codeaurora.org>
> ---
> .../bindings/interrupt-controller/qcom,pdc.txt | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
> index 8e0797cb1487..852fcba98ea6 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
> @@ -50,15 +50,22 @@ Properties:
> The second element is the GIC hwirq number for the PDC port.
> The third element is the number of interrupts in sequence.
>
> +- qcom,scm-spi-cfg:
> + Usage: optional
> + Value type: <bool>
> + Definition: Specifies if the SPI configuration registers have to be
> + written from the firmware.
> +
> Example:
>
> pdc: interrupt-controller@b220000 {
> compatible = "qcom,sdm845-pdc";
> - reg = <0xb220000 0x30000>;
> + reg = <0xb220000 0x30000>, <0x179900f0 0x60>;
There needs to be a description for reg updated. These aren't GIC
registers are they? Because those go in the GIC node.
> qcom,pdc-ranges = <0 512 94>, <94 641 15>, <115 662 7>;
> #interrupt-cells = <2>;
> interrupt-parent = <&intc>;
> interrupt-controller;
> + qcom,scm-spi-cfg;
> };
>
> DT binding of a device that wants to use the GIC SPI 514 as a wakeup
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH v2 1/2] gpio: acpi: add quirk to override GpioInt polarity
From: Linus Walleij @ 2019-09-02 13:36 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Peter Cai, Rafael J. Wysocki, Len Brown, Mika Westerberg,
Bartosz Golaszewski, Bastien Nocera, Dmitry Torokhov,
open list:GPIO SUBSYSTEM, ACPI Devel Maling List,
linux-kernel@vger.kernel.org, Linux Input
In-Reply-To: <20190902100141.GW2680@smile.fi.intel.com>
On Mon, Sep 2, 2019 at 12:01 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Sat, Aug 31, 2019 at 11:09:14AM +0800, Peter Cai wrote:
> > On GPD P2 Max, the firmware could not reset the touch panel correctly.
> > The kernel needs to take on the job instead, but the GpioInt definition
> > in DSDT specifies ActiveHigh while the GPIO pin should actually be
> > ActiveLow.
> >
> > We need to override the polarity defined by DSDT. The GPIO driver
> > already allows defining polarity in acpi_gpio_params, but the option is
> > not applied to GpioInt.
> >
> > This patch adds a new quirk that enables the polarity specified in
> > acpi_gpio_params to also be applied to GpioInt.
>
> Thank you for an update!
>
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> on the condition that Dmitry and other input / Goodix developers are okay with
> the approach in general.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
In case Dmitry needs to merge this.
Or should I simply merge this patch to the GPIO tree?
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox