[PATCH linux dev-4.7 v3 2/2] ARM: dts: Enable checkstop and cooling gpio keys

[Brad Bishop]

> On Apr 20, 2017, at 12:34 AM, Andrew Jeffery <andrew at aj.id.au> wrote:
> 
> On Wed, 2017-04-19 at 10:38 -0400, Brad Bishop wrote:
>>>>> On Apr 19, 2017, at 10:29 AM, Andrew Jeffery <andrew at aj.id.au> wrote:
>>> 
>>> Hi Brad,
>>> 
>>> If you do future revisions of these patches, can you please Cc me?
>> 
>> will do.
>> 
>>> 
>>> On Wed, 2017-04-19 at 00:18 -0400, Brad Bishop wrote:
>>>> Enable gpio-keys events for the checkstop and water/air cooled
>>>> gpios for use by applications on the Witherspoon system.
>>>> 
>>>>> Signed-off-by: Brad Bishop <bradleyb at fuzziesquirrel.com>
>>>> 
>>>> ---
>>>>  arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts | 20 ++++++++++++++++++++
>>>>  1 file changed, 20 insertions(+)
>>>> 
>>>> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>> index e3a7b77..aa1708e 100644
>>>> --- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
>>>> @@ -31,6 +31,26 @@
>>>>>>>>>  		};
>>>>>  	};
>>>> 
>>>>  
>>>> +	gpio-keys at 0 {
>>> 
>>> does the @0 give us a stable device name for userspace to open?
>> 
>> No it doesn’t.  This is my lack of DT skillz showing.  I was looking
>> into how we can give userspace a stable device name.  I was going
>> down the udev path but I can’t find any any of the information from
>> these DT nodes in the udev event.
>> 
>>> 
>>> Do we really want to go this way? We now have useful unique codes for
>>> the "key"s, why not use the one node? Or is your concern we've now tied
>> 
>> Each gpio will have an application waiting for its state to change.  My
>> concern was waking up x number of applications every time any gpio changes
>> state.  Is that a valid concern?
> 
> How many applications do we expect to be reading the evdev? What are
> our expected interrupt rates? What are the worst expected cases?

For Witherspoon/Zaius or any OpenBMC platform?  I obviously can’t say for the
latter case.  On a bigger/enterprise systems I can see on the order of 10 to 100
applications looking at these.  I don’t have a good sense of how often.

On Witherspoon/Zaius, sure, we only have a handful of applications and the
interrupt rate should be very infrequent.

I think you typically see all the gpio keys mapped to a single device because
the usual thing to do is have a single application (Xorg) treat it like a keyboard.

We aren’t structured that way so rethinking the usual approach seems reasonable.  
Another reason I went for per gpio devices because it prevents applications from
reacting to each others events without any special library code.  

I’m not saying there aren’t disadvantages to this approach - I just don’t know what
they are?

> 
> It's hard to judge without knowing the numbers, but considering the
> chips we run on I agree we should generally favour performance if
> design is getting in the way. But to make that trade off we should be

Again, what exactly is being traded-off ?

> clear on the performance numbers.
> 
> Andrew