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]
Message-ID: <bd5453e1-0279-02ab-3304-edc6ebf509dc@siemens.com>
Date:   Fri, 26 Apr 2019 15:36:34 +0200
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH 2/2] gpio: sch: Add interrupt support

On 26.04.19 15:06, Andy Shevchenko wrote:
> On Wed, Apr 24, 2019 at 12:39:35PM +0200, Jan Kiszka wrote:
>> On 24.04.19 12:33, Mika Westerberg wrote:
>>> On Wed, Apr 24, 2019 at 12:19:02PM +0200, Jan Kiszka wrote:
> 
>>>> And even if that were possible, we would be back to the square of existing
>>>> devices without those definitions. If this were a recent chipset, I would
>>>> say, "go, fix future firmware versions". But this one is legacy.
>>>
>>> Is it fixing some real issue with these legacy platforms? I mean without
>>> the patch some GPE event is not handled properly? It was not clear to me
>>> from the commit message.
>>>
>>
>> Without that patch, you are forced to poll for event changes in your
>> application, timer-driven. There are application that cannot process these
>> GPIOs because they lack such logic (mraa with node-red-node-intel-gpio is a
>> public example).
> 
> Just a side note: MRAA is a hack itself. It abuses almost all interfaces Linux
> kernel provides.
> 

Yes, very well aware of that. I have some patches that started to clean up at 
least parts of it, but that effort stalled over to many other fires. At the same 
time, there are no real alternatives - to my knowledge - for the value it brings 
(various bindings) to simply switch the engine.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ