linux-kernel - RE: [PATCH v2 2/3] gpio: Add support for TPS68470 GPIOs

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, 6 Jul 2017 01:49:28 +0000
From:   "Mani, Rajmohan" <rajmohan.mani@...el.com>
To:     'Andy Shevchenko' <andy.shevchenko@...il.com>
CC:     "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
        "'linux-gpio@...r.kernel.org'" <linux-gpio@...r.kernel.org>,
        "'linux-acpi@...r.kernel.org'" <linux-acpi@...r.kernel.org>,
        'Lee Jones' <lee.jones@...aro.org>,
        'Linus Walleij' <linus.walleij@...aro.org>,
        'Alexandre Courbot' <gnurou@...il.com>,
        "'Rafael J. Wysocki'" <rjw@...ysocki.net>,
        'Len Brown' <lenb@...nel.org>
Subject: RE: [PATCH v2 2/3] gpio: Add support for TPS68470 GPIOs

Hi Andy and all,

Thanks for your patience.

> >
> > Main points (some I already told in an answer to Sakari's mail):
> > 1. Consider 2 GPIO chips over 1.
> 
> I am looking into this.
> 

For the second GPIO chip, the call to acpi_attach_data() fails with AE_ALREADY_EXISTS, as below with 4.12 rc3 kernel.

acpi_gpiochip_add()
	acpi_attach_data() 
		acpi_ns_attach_data() fails with AE_ALREADY_EXISTS for the second GPIO chip.
		/* We only allow one attachment per handler */ drivers/acpi/acpica/nsobject.c

Also, I tried the following experiment, since we know the number of GPIOs for the second GPIO chip is 3, just to see if I can get further along after a successful call to acpi_attach_data().

Since the acpi_gpio_chip_dh is used as the handler in all acpi_gpiochip_* calls, I tried to use another handler (acpi_gpio_chip_dh2). But now, as expected, acpi_gpiochip_request_regions() failed inside acpi_gpiochip_add(), as only one OpRegion handler can be installed for a given OpRegion code. Due to this, when I try to set the GPIO 9 (which is now GPIO 2 of the second GPIO chip of 2 GPIO chips implementation), the OpRegion handler is called with the information / region_context pointer of the first GPIO chip, which is not desired.

It sounds like there are 2 issues with the 2 GPIO chips implementation.

1) How to get acpi_ns_attach_data() done successfully for the second GPIO chip, given the observation above and

2) How to get the GPIO OpRegion handler to be called with the right GPIO chip information / region_context pointer

I need pointers to make further progress here.

> > 2. Fix FIXME(s).
> 
> Leaving this on, until I see how this can be fixed.
> 

These FIXME code will be removed from the driver, as we are working to get this done through platform firmware.

> > 3. If there is hardware bug we should work around it must be clarified.
> 
> Ack
> If this is about initializing the GPIOs with zero, I have removed this code for
> now.
> 
> > 4. You missed Linus' comments here (switch to the data pointer inside
> > GPIO chip and remove platform driver data stuff from the driver).
> >
> 
> I have fixed this with v3