From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pf0-f176.google.com ([209.85.192.176]:34440 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758435AbcHCUuX (ORCPT ); Wed, 3 Aug 2016 16:50:23 -0400 Received: by mail-pf0-f176.google.com with SMTP id p64so80841098pfb.1 for ; Wed, 03 Aug 2016 13:50:23 -0700 (PDT) Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion To: Dmitry Torokhov References: <20160730165817.GQ3296@wotan.suse.de> <37a3cd66-262e-ffbe-ea7a-a6d5b1ca1c8b@bmw-carit.de> <20160801194408.GZ3296@wotan.suse.de> <0f9350fa-e8b5-9d64-b2d3-afda5e5f6bbf@bmw-carit.de> <20160802063419.GG3296@wotan.suse.de> <2713d779-ef55-793d-f37e-d1414bb1bfc2@bmw-carit.de> <20160802074106.GI3296@wotan.suse.de> <0e20a2dc-ed76-b209-5c01-387f1c444b19@broadcom.com> <20160803153506.GC29702@dtor-ws> Cc: "Luis R. Rodriguez" , Daniel Wagner , Bjorn Andersson , Daniel Wagner , Bastien Nocera , Greg Kroah-Hartman , Johannes Berg , Kalle Valo , Ohad Ben-Cohen , Mimi Zohar , David Howells , Andy Lutomirski , David Woodhouse , Julia Lawall , "linux-input@vger.kernel.org" , linux-kselftest@vger.kernel.org, linux-wireless , lkml From: Arend van Spriel Message-ID: (sfid-20160803_225028_619188_D18D1BE9) Date: Wed, 3 Aug 2016 22:42:43 +0200 MIME-Version: 1.0 In-Reply-To: <20160803153506.GC29702@dtor-ws> Content-Type: text/plain; charset=windows-1252 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 03-08-16 17:35, Dmitry Torokhov wrote: >> In my opinion the kernel should provide functionality to user-space and >> > user-space providing functionality to the kernel should be avoided. > Why? We have bunch of stuff running in userspace for the kernel. Fuse > for example. I am sure there are more. To me "running in user-space" is not the same as providing functionality, but I see your point given below. >> > >>> > > If we solve waiting for rootfs (or something else that may contain >>> > > firmware) then these cases will not need to use usermode helper. >> > >> > If firmware (or whatever) API could get notification of mount syscall it >> > could be used to retry firmware loading instead of periodic polling. >> > That leaves the question raised by you about when to stop trying. The >> > initlevel stuff is probably a user-space only concept, right? So no >> > ideas how the kernel itself could decide except for a "long" timeout. > The kernel really does not know, it can only guess. The firmware may get > delivered by motorized carrier pidgeons. But distribution does know how > they set up, so they are in position to tell the kernel "go" or "give > up". What distro employs pidgeons. Like to give it a spin ;-) Maybe the latest idea from Luis is a viable option. Regards, Arend From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arend van Spriel Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion Date: Wed, 3 Aug 2016 22:42:43 +0200 Message-ID: References: <20160730165817.GQ3296@wotan.suse.de> <37a3cd66-262e-ffbe-ea7a-a6d5b1ca1c8b@bmw-carit.de> <20160801194408.GZ3296@wotan.suse.de> <0f9350fa-e8b5-9d64-b2d3-afda5e5f6bbf@bmw-carit.de> <20160802063419.GG3296@wotan.suse.de> <2713d779-ef55-793d-f37e-d1414bb1bfc2@bmw-carit.de> <20160802074106.GI3296@wotan.suse.de> <0e20a2dc-ed76-b209-5c01-387f1c444b19@broadcom.com> <20160803153506.GC29702@dtor-ws> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160803153506.GC29702@dtor-ws> Sender: linux-wireless-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dmitry Torokhov Cc: "Luis R. Rodriguez" , Daniel Wagner , Bjorn Andersson , Daniel Wagner , Bastien Nocera , Greg Kroah-Hartman , Johannes Berg , Kalle Valo , Ohad Ben-Cohen , Mimi Zohar , David Howells , Andy Lutomirski , David Woodhouse , Julia Lawall , "linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-kselftest-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-wireless , lkml List-Id: linux-input@vger.kernel.org On 03-08-16 17:35, Dmitry Torokhov wrote: >> In my opinion the kernel should provide functionality to user-space and >> > user-space providing functionality to the kernel should be avoided. > Why? We have bunch of stuff running in userspace for the kernel. Fuse > for example. I am sure there are more. To me "running in user-space" is not the same as providing functionality, but I see your point given below. >> > >>> > > If we solve waiting for rootfs (or something else that may contain >>> > > firmware) then these cases will not need to use usermode helper. >> > >> > If firmware (or whatever) API could get notification of mount syscall it >> > could be used to retry firmware loading instead of periodic polling. >> > That leaves the question raised by you about when to stop trying. The >> > initlevel stuff is probably a user-space only concept, right? So no >> > ideas how the kernel itself could decide except for a "long" timeout. > The kernel really does not know, it can only guess. The firmware may get > delivered by motorized carrier pidgeons. But distribution does know how > they set up, so they are in position to tell the kernel "go" or "give > up". What distro employs pidgeons. Like to give it a spin ;-) Maybe the latest idea from Luis is a viable option. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html