linux-kernel - Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes

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:	Tue, 07 Apr 2015 11:39:36 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Octavian Purdila <octavian.purdila@...el.com>
CC:	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Robert Dolca <robert.dolca@...il.com>,
	Robert Dolca <robert.dolca@...el.com>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	Jonathan Cameron <jic23@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Hartmut Knaack <knaack.h@....de>,
	Peter Meerwald <pmeerw@...erw.net>,
	Denis CIOCCA <denis.ciocca@...com>
Subject: Re: [PATCH] IIO: Adds ACPI support for ST gyroscopes

On 04/07/2015 11:35 AM, Linus Walleij wrote:
> On Mon, Mar 30, 2015 at 3:52 PM, Octavian Purdila
> <octavian.purdila@...el.com> wrote:
>> On Mon, Mar 30, 2015 at 4:33 PM, Mika Westerberg
>> <mika.westerberg@...ux.intel.com> wrote:
>>> On Mon, Mar 30, 2015 at 03:55:14PM +0300, Octavian Purdila wrote:
>>>> On Mon, Mar 30, 2015 at 12:52 PM, Mika Westerberg
>>>> <mika.westerberg@...ux.intel.com> wrote:
>>>>> On Fri, Mar 27, 2015 at 11:36:25AM +0100, Linus Walleij wrote:
>>>>>> On Fri, Mar 27, 2015 at 11:06 AM, Mika Westerberg
>>>>>> <mika.westerberg@...ux.intel.com> wrote:
>>>>>>> On Thu, Mar 26, 2015 at 06:28:19PM +0200, Octavian Purdila wrote:
>>>>>>
>>>>>>>> For the sleep case I think the GPIO controller needs to do the pin
>>>>>>>> enable and set input direction operation in it's irq_bus_sync_unlock.
>>>>>>>
>>>>>>> I wonder how DT handles all this? Is it the boot firmware that sets up
>>>>>>> the pins accordingly or is there something we are missing?
>>>>>>
>>>>>> DT systems mostly do not have firmware for power usecases, they
>>>>>> handle it all using pin control. I would more say that is a feature of
>>>>>> all-SW systems without power-firmware ideas, without ACPI and
>>>>>> without PSCI (well PSCI systems do not care about much more
>>>>>> than CPU power down in firmware anyway...)
>>>>>
>>>>> OK, thanks.
>>>>>
>>>>> In case of ACPI (where firmware does lot more) it is supposed to
>>>>> configure pins based on what is connected, if the firmware knows that.
>>>>> Due to bugs in the boot firmware that obviously does not happen in all
>>>>> cases (like this one).
>>>>>
>>>>
>>>> Ah, interesting, I was not aware that the firmware was supposed to do
>>>> the pin configuration. In this case I think your patch can be merged
>>>> as it is Mika, mine doesn't make sense anymore.
>>>
>>> Unfortunately because of bugs we can't rely that the firmware (BIOS)
>>> gets those always right :-(
>>>
>>>> This particular case is special since we did not performed the tests
>>>> on a full system that has the component integrated. We instead used
>>>> and I2C to USB bridge to which we connected the component and we
>>>> loaded the ACPI table dynamically.
>>>
>>> Regardless of how did the device appear this always works:
>>>
>>>    1) request the GPIO (with GPIOD_IN)
>>>    2) convert it to IRQ using gpiod_to_irq()
>>>
>>> Since we cannot be sure that the firmware has configured the pin
>>> properly, rather than adding automatic IRQ <-> GPIO translation for ACPI
>>> GpioInt I think we are better off if drivers explictly request their
>>> GPIOs and configure them as needed.
>>
>>
>> Yes, this is what we are doing now and it works well.
>>
>> But I am not yet ready to give-up on the automatic IRQ <-> GPIO translation :)
>>
>> What if we can do the pin configuration in gpiolib right after the
>> GPIO controller is initialized. I am thinking of searching the ACPI
>> namespace and looking for resources that have GpioInt entries for that
>> particular GPIO controller and use them to set the pins to input (and
>> ideally also set the other properties like pullups, pulldowns, etc.)
>
> I would rather say that since the gpiolib and irqchip APIs are
> supposed to be orthogonal, the irqchip request/unmask or
> whatever functions are enabling IRQs should just go and poke
> the necessary bits in the GPIO registers to turn the pin into
> an input.

Yes, especially considering that for some controllers they actually are 
orthogonal. I.e. different bits need to be set depending on whether the pin 
should be used as a GPIO input or as a interrupt pin.

It may make sense to offer some helper functions or flags for those chips 
were the pin needs to be configured as input so the core can take care of it 
and not every driver needs to do it on its own.

- Lars
--
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/