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] [day] [month] [year] [list]
Date:   Fri, 28 Aug 2020 16:18:09 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Al Cooper <alcooperx@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-usb <linux-usb@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH 1/3] dt-bindings: Add support for Broadcom USB pin map driver

Hi Linus et al,

On Fri, Aug 28, 2020 at 4:00 PM Linus Walleij <linus.walleij@...aro.org> wrote:
> On Wed, Aug 12, 2020 at 10:20 PM Al Cooper <alcooperx@...il.com> wrote:
> > Add DT bindings for the Broadcom USB pin map driver. This driver allows
> > some USB input and output signals to be mapped to any GPIO instead
> > of the normal dedicated pins to/from the XHCI controller.
> >
> > Signed-off-by: Al Cooper <alcooperx@...il.com>
> (...)
> > +title: Broadcom USB pin map Controller Device Tree Bindings
> > +
> > +maintainers:
> > +  - Al Cooper <alcooperx@...il.com>
> > +
> > +properties:
> > +  compatible:
> > +      items:
> > +          - const: brcm,usb-pinmap
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  interrupts:
> > +    maxItems: 1
> > +    description: Must be defined if any out-gpios are specified.
> > +
> > +  in-gpios:
> > +    description: Array of one or more GPIO pins used for input signals.
> > +
> > +  in-names:
> > +    description: Array of input signal names, one per gpio in in-gpios.
> > +
> > +  in-masks:
> > +    description: Array of enable and mask pairs, one per gpio in-gpios.
> > +
> > +  out-gpios:
> > +    description: Array of one or more GPIO pins used for output signals.
> > +
> > +  out-names:
> > +    description: Array of output signal names, one per gpio in out-gpios.
> > +
> > +  out-masks:
> > +    description: Array of enable, value, changed and clear masks, one
> > +      per gpio in out-gpios.
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    usb_pinmap: usb-pinmap@...00d0 {
> > +        compatible = "brcm,usb-pinmap";
> > +        reg = <0x22000d0 0x4>;
> > +        in-gpios = <&gpio 18 0>, <&gpio 19 0>;
> > +        in-names = "VBUS", "PWRFLT";
> > +        in-masks = <0x8000 0x40000 0x10000 0x80000>;
> > +        out-gpios = <&gpio 20 0>;
> > +        out-names = "PWRON";
> > +        out-masks = <0x20000 0x800000 0x400000 0x200000>;
> > +        interrupts = <0x0 0xb2 0x4>;
> > +    };
>
> Wow look at that.
>
> This looks very much like Geert's just invented GPIO aggregator.
> But in hardware!
>
> See:
> drivers/gpio/gpio-aggregator.c
>
> I think Geert is intending to add bindings to the aggregator, and
> while I do think this should be its own driver (in drivers/usb) these
> bindings and whatever Geert want to use for the aggregator
> should certainly be the same.

I don't intend to add any DT bindings to the GPIO Aggregator, as it's
meant to be an "abstract base" driver.  Actual hardware blocks for which
the GPIO Aggregator could be a suitable driver should have their own DT
bindings, and their compatible values added to the GPIO Aggregator
driver's match table.

Anyway, DT bindings would just be a compatible value, and a gpios
property.

> Geert what do you think?

This USB pin map driver seems to map GPIO pins to USB pins, not other
GPIO pins, so to me it looks like something different than the GPIO
Aggregator: a hardware mux instead of a software mux.

BTW, at least on most Renesas SoCs, you can usually mux output functions
to multiple pins at the same time, which could be considered mirroring,
too.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ