linux-kernel - Re: [PATCH v6 2/2] gpio: uniphier: add UniPhier GPIO controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 Oct 2017 10:40:58 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Rob Herring <robh@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Rob Herring <robh+dt@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Rutland <mark.rutland@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v6 2/2] gpio: uniphier: add UniPhier GPIO controller driver

On Wed, Sep 27, 2017 at 4:40 AM, Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:

> This GPIO controller is used on UniPhier SoC family.
>
> It also serves as an interrupt controller, but interrupt signals are
> just delivered to the parent irqchip without any latching or OR'ing.
> This type of hardware can be well described with hierarchy IRQ domain.
>
> One unfortunate thing for this device is that the interrupt mapping to
> the interrupt parent is not contiguous.
>
> I asked how DT can describe interrupt mapping between two irqchips [1],
> but I could not find a good solution (at least in the framework level).
> In fact, irqchip drivers using hierarchy domain generally hard-code the
> DT binding of their parent.
>
> After tackling on several approaches such as hard-code of hwirqs,
> irq_domain_push_irq(), I ended up with a vendor specific property.
> If we come up with a good idea to support this in the framework, we
> can migrate over to it, but we can live with a driver-level solution
> for now.
>
> [1] https://lkml.org/lkml/2017/7/6/758
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>

Mostly happy with this.

> @@ -2036,6 +2036,7 @@ F:        arch/arm/mm/cache-uniphier.c
>  F:     arch/arm64/boot/dts/socionext/
>  F:     drivers/bus/uniphier-system-bus.c
>  F:     drivers/clk/uniphier/
> +F:     drivers/gpio/gpio-uniphier.c

Also add an entry for the device tree bindings please.

> +++ b/include/dt-bindings/gpio/uniphier-gpio.h
> @@ -0,0 +1,18 @@
> +/*
> + * Copyright (C) 2017 Socionext Inc.
> + *   Author: Masahiro Yamada <yamada.masahiro@...ionext.com>
> + */
> +
> +#ifndef _DT_BINDINGS_GPIO_UNIPHIER_H
> +#define _DT_BINDINGS_GPIO_UNIPHIER_H
> +
> +#define UNIPHIER_GPIO_LINES_PER_BANK   8
> +
> +#define UNIPHIER_GPIO_IRQ_OFFSET       ((UNIPHIER_GPIO_LINES_PER_BANK) * 15)
> +
> +#define UNIPHIER_GPIO_PORT(bank, line) \
> +                       ((UNIPHIER_GPIO_LINES_PER_BANK) * (bank) + (line))
> +
> +#define UNIPHIER_GPIO_IRQ(n)           ((UNIPHIER_GPIO_IRQ_OFFSET) + (n))
> +
> +#endif /* _DT_BINDINGS_GPIO_UNIPHIER_H */

I do not understand what some of these things are doing in the
device tree header file.

It just looks creepingly similar to some of the magic I've seen
in board files.

It makes much more sense that the device trees either:

- Use the interrupts as a flat array 0...N across all banks

- Model each bank as a separate GPIO chip

This is somewhere inbetween, you are modeling it as a single
gpiochip but still not, becuase the device tree author still need
to address banking, that is confusing.

Yours,
Linus Walleij