From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756133AbbA2RXV (ORCPT ); Thu, 29 Jan 2015 12:23:21 -0500 Received: from mail-bl2on0055.outbound.protection.outlook.com ([65.55.169.55]:46067 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754220AbbA2RXT (ORCPT ); Thu, 29 Jan 2015 12:23:19 -0500 Date: Thu, 29 Jan 2015 09:23:14 -0800 From: =?utf-8?B?U8O2cmVu?= Brinkmann To: Linus Walleij CC: Alexandre Courbot , Johan Hovold , , Linux Kernel Mailing List , "linux-gpio@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: Re: [PATCH v4] gpio: lib-sysfs: Add 'wakeup' attribute References: <1421351389-11660-1-git-send-email-soren.brinkmann@xilinx.com> <20150116111108.GG30960@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1018-21292.001 X-TM-AS-User-Approved-Sender: Yes;Yes Message-ID: X-EOPAttributedMessage: 0 Authentication-Results: spf=pass (sender IP is 149.199.60.83) smtp.mailfrom=soren.brinkmann@xilinx.com; vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=permerror action=none header.from=xilinx.com; X-Forefront-Antispam-Report: CIP:149.199.60.83;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(377454003)(164054003)(377424004)(24454002)(52604005)(51704005)(86362001)(19580395003)(53416004)(104016003)(85182001)(87936001)(50986999)(47776003)(83506001)(110136001)(92726002)(85202003)(93886004)(46102003)(108616004)(74316001)(106466001)(76176999)(54356999)(92566002)(50466002)(62966003)(6806004)(77156002)(23676002)(2950100001)(19580405001)(107986001)(24736002);DIR:OUT;SFP:1101;SCL:1;SRVR:BL2FFO11HUB024;H:xsj-pvapsmtpgw01;FPR:;SPF:None;MLV:sfv;LANG:en; X-DmarcAction-Test: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BL2FFO11HUB024; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004);SRVR:BL2FFO11HUB024; X-Forefront-PRVS: 0471B73328 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BL2FFO11HUB024; X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2015 17:23:16.3264 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.83] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2FFO11HUB024 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, On Mon, 2015-01-19 at 09:54AM +0100, Linus Walleij wrote: > On Mon, Jan 19, 2015 at 5:20 AM, Alexandre Courbot wrote: > > On Sat, Jan 17, 2015 at 1:49 AM, Sören Brinkmann wrote: > >> On Fri, 2015-01-16 at 12:11PM +0100, Johan Hovold wrote: > > >>> Implementing proper wakeup support for unclaimed GPIOs would take some > >>> work (if at all desired), but that is not a reason to be adding custom > >>> implementations that violates the kernel's power policies and new ABIs > >>> that would need to be maintained forever. > (...) > >>> Meanwhile you can (should) use gpio-keys if you need to wake your system > >>> on gpio events. > >> > >> We had that discussion and I don't think GPIO keys is the right solution > >> for every use-case. > > > > Sorry, it has been a while - can you remind us of why? > > There are such cases. Of course keys should be handled by GPIO-keys > and these will trigger the right wakeup events in such cases. > > This is for more esoteric cases: we cannot have a kernel module for > everything people want to do with GPIOs, and the use case I accept > is GPIOs used in automatic control etc, think factory lines or doors. > We can't have a "door" driver or "punch arm" or "fire alarm" driver > in the kernel. Those are userspace things. > > Still such embedded systems need to be able to go to idle and > sleep to conerve power, and then they need to put wakeups on > these GPIOs. > > So it is a feature userspace needs, though as with much of the > sysfs ABI it is very often abused for things like keys and LEDs which > is an abomination but we can't do much about it :( Thanks for clearing that up. What does that mean for this patch? Are we going ahead, accepting the extension of this API or do all these use-cases have to wait for the rewrite of a proper GPIO userspace interface? Thanks, Sören