linux-kernel - Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)

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:	Thu, 19 Mar 2015 09:18:01 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	David Cohen <david.a.cohen@...ux.intel.com>
Cc:	Felipe Balbi <balbi@...com>,
	Robert Baldyga <r.baldyga@...sung.com>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	MyungJoo Ham <myungjoo.ham@...sung.com>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	baolu.lu@...ux.intel.com
Subject: Re: [PATCH v2] extcon: otg_gpio: add driver for USB OTG port
 controlled by GPIO(s)

On Mon, Mar 9, 2015 at 8:10 PM, David Cohen
<david.a.cohen@...ux.intel.com> wrote:

> But at least on ACPI case, GPIO API blocks the ability to create
> children platform devices that require GPIO as platform data, despite
> we've many drivers on upstream that expect this behavior: e.g. extcon-gpio.c
>
> Are we considering those driver deprecated from the GPIO point of view?
> If yes, we need to provide an update for them (we can't let upstreamed
> drivers broken). If no, we need to provide a way to move forward the
> GPIO to children devices.

Aha OK... Let me paste this code from
arch/arm/mach-integrator/impd1.c - this is not an MFD (it would
be if we implemented it today) but you can see the idea I deploy:

    for (i = 0; i < ARRAY_SIZE(impd1_devs); i++) {
        struct impd1_device *idev = impd1_devs + i;
        struct amba_device *d;
        unsigned long pc_base;
        char devname[32];
        int irq1 = idev->irq[0];
        int irq2 = idev->irq[1];

        /* Translate IRQs to IM-PD1 local numberspace */
        if (irq1)
            irq1 += irq_base;
        if (irq2)
            irq2 += irq_base;

        pc_base = dev->resource.start + idev->offset;
        snprintf(devname, 32, "lm%x:%5.5lx", dev->id, idev->offset >> 12);

        /* Add GPIO descriptor lookup table for the PL061 block */
        if (idev->offset == 0x00400000) {
            struct gpiod_lookup_table *lookup;
            char *chipname;
            char *mmciname;

            lookup = devm_kzalloc(&dev->dev,
                          sizeof(*lookup) + 3 * sizeof(struct gpiod_lookup),
                          GFP_KERNEL);
            chipname = devm_kstrdup(&dev->dev, devname, GFP_KERNEL);
            mmciname = kasprintf(GFP_KERNEL, "lm%x:00700", dev->id);
            lookup->dev_id = mmciname;
            /*
             * Offsets on GPIO block 1:
             * 3 = MMC WP (write protect)
             * 4 = MMC CD (card detect)
             *
             * Offsets on GPIO block 2:
             * 0 = Up key
             * 1 = Down key
             * 2 = Left key
             * 3 = Right key
             * 4 = Key lower left
             * 5 = Key lower right
             */
            /* We need the two MMCI GPIO entries */
            lookup->table[0].chip_label = chipname;
            lookup->table[0].chip_hwnum = 3;
            lookup->table[0].con_id = "wp";
            lookup->table[1].chip_label = chipname;
            lookup->table[1].chip_hwnum = 4;
            lookup->table[1].con_id = "cd";
            lookup->table[1].flags = GPIO_ACTIVE_LOW;
            gpiod_add_lookup_table(lookup);
        }

        d = amba_ahb_device_add_res(&dev->dev, devname, pc_base, SZ_4K,
                        irq1, irq2,
                        idev->platform_data, idev->id,
                        &dev->resource);
        if (IS_ERR(d)) {
            dev_err(&dev->dev, "unable to register device: %ld\n", PTR_ERR(d));
            continue;
        }
    }

Notice how I build a dynamic lookup table.

I don't see any problem for an MFD nexus doing this too, just need
some quirks I guess.

But I guess it's not that simple, i.e. the GPIOs are not just
"appearing" in the system like here (the devices we add has a GPIO
block going with it) but it's external GPIOs.

So I presume we are talking about the case of GPIO forwarding that
was mentioned earlier, so that GPIOs are defined for the nexus
(MFD) device and need to be forwarded to the clients so they can
issue gpiod_get() on their own struct device*?


Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/