From: Daniel Wagner <daniel.wagner@bmw-carit.de> To: "Luis R. Rodriguez" <mcgrof@kernel.org> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>, Arend van Spriel <arend.vanspriel@broadcom.com>, Bjorn Andersson <bjorn.andersson@linaro.org>, Daniel Wagner <wagi@monom.org>, Bastien Nocera <hadess@hadess.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Johannes Berg <johannes.berg@intel.com>, Kalle Valo <kvalo@codeaurora.org>, Ohad Ben-Cohen <ohad@wizery.com>, Mimi Zohar <zohar@linux.vnet.ibm.com>, David Howells <dhowells@redhat.com>, Andy Lutomirski <luto@amacapital.net>, David Woodhouse <dwmw2@infradead.org>, Julia Lawall <julia.lawall@lip6.fr>, <linux-input@vger.kernel.org>, <linux-kselftest@vger.kernel.org>, <linux-wireless@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion Date: Wed, 3 Aug 2016 08:57:09 +0200 [thread overview] Message-ID: <ef14dc68-d2f8-0934-7be5-dfb3a4771f27@bmw-carit.de> (raw) In-Reply-To: <20160802074106.GI3296@wotan.suse.de> On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: >> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: >>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: >> So you argue for the remoteproc use case with 100+ MB firmware that >> if there is a way to load after pivot_root() (or other additional >> firmware partition shows up) then there is no need at all for >> usermode helper? > > No, I'm saying I'd like to hear valid uses cases for the usermode helper and so > far I have only found using coccinelle grammar 2 explicit users, that's it. My > patch series (not yet merge) then annotates these as valid as I've verified > through their documentation they have some quirky requirement. I got that question wrong. It should read something like 'for the remoteproc 100+MB there is no need for the user help?'. I've gone through your patches and they make perfectly sense too. Maybe I can convince you to take a better version of my patch 3 into your queue. And I help you converting the exiting drivers. Obviously if you like my help at all. > Other than these two drivers I'd like hear to valid requirements for it. > > The existential issue is a real issue but it does not look impossible to > resolve. It may be a solution to bloat up the kernel with 100+ MB size just to > stuff built-in firmware to avoid this issue, but it does not mean a solution > is not possible. > > Remind me -- why can remoteproc not stuff the firmware in initramfs ? I don't know. I was just bringing it up with the hope that Bjorn will defend it. It seems my tactics didn't work out :) > Anyway, here's a simple suggestion: fs/exec.c gets a sentinel file monitor > support per enum kernel_read_file_id. For instance we'd have one for > READING_FIRMWARE, one for READING_KEXEC_IMAGE, perhaps READING_POLICY, and this > would in turn be used as the system configurable deterministic file for > which to wait for to be present before enabling each enum kernel_read_file_id > type read. > > Thoughts ? Not sure if I get you here correctly. Is the 'system configurable deterministic file' is a knob which controlled by user space? Or it this something you define at compile time? Hmm, so it would allow to decided to ask a userspace helper or load the firmware directly (to be more precised the kernel_read_file_id type). If yes, than it is what currently already have just integrated nicely into the new sysdata API. cheers, daniel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Wagner <daniel.wagner@bmw-carit.de> To: "Luis R. Rodriguez" <mcgrof@kernel.org> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>, Arend van Spriel <arend.vanspriel@broadcom.com>, Bjorn Andersson <bjorn.andersson@linaro.org>, Daniel Wagner <wagi@monom.org>, Bastien Nocera <hadess@hadess.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Johannes Berg <johannes.berg@intel.com>, Kalle Valo <kvalo@codeaurora.org>, Ohad Ben-Cohen <ohad@wizery.com>, Mimi Zohar <zohar@linux.vnet.ibm.com>, David Howells <dhowells@redhat.com>, Andy Lutomirski <luto@amacapital.net>, David Woodhouse <dwmw2@infradead.org>, Julia Lawall <julia.lawall@lip6.fr>, linux-input@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion Date: Wed, 3 Aug 2016 08:57:09 +0200 [thread overview] Message-ID: <ef14dc68-d2f8-0934-7be5-dfb3a4771f27@bmw-carit.de> (raw) In-Reply-To: <20160802074106.GI3296@wotan.suse.de> On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: >> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: >>> On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: >> So you argue for the remoteproc use case with 100+ MB firmware that >> if there is a way to load after pivot_root() (or other additional >> firmware partition shows up) then there is no need at all for >> usermode helper? > > No, I'm saying I'd like to hear valid uses cases for the usermode helper and so > far I have only found using coccinelle grammar 2 explicit users, that's it. My > patch series (not yet merge) then annotates these as valid as I've verified > through their documentation they have some quirky requirement. I got that question wrong. It should read something like 'for the remoteproc 100+MB there is no need for the user help?'. I've gone through your patches and they make perfectly sense too. Maybe I can convince you to take a better version of my patch 3 into your queue. And I help you converting the exiting drivers. Obviously if you like my help at all. > Other than these two drivers I'd like hear to valid requirements for it. > > The existential issue is a real issue but it does not look impossible to > resolve. It may be a solution to bloat up the kernel with 100+ MB size just to > stuff built-in firmware to avoid this issue, but it does not mean a solution > is not possible. > > Remind me -- why can remoteproc not stuff the firmware in initramfs ? I don't know. I was just bringing it up with the hope that Bjorn will defend it. It seems my tactics didn't work out :) > Anyway, here's a simple suggestion: fs/exec.c gets a sentinel file monitor > support per enum kernel_read_file_id. For instance we'd have one for > READING_FIRMWARE, one for READING_KEXEC_IMAGE, perhaps READING_POLICY, and this > would in turn be used as the system configurable deterministic file for > which to wait for to be present before enabling each enum kernel_read_file_id > type read. > > Thoughts ? Not sure if I get you here correctly. Is the 'system configurable deterministic file' is a knob which controlled by user space? Or it this something you define at compile time? Hmm, so it would allow to decided to ask a userspace helper or load the firmware directly (to be more precised the kernel_read_file_id type). If yes, than it is what currently already have just integrated nicely into the new sysdata API. cheers, daniel
next prev parent reply other threads:[~2016-08-03 7:06 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-07-28 7:55 [RFC v0 0/8] Reuse firmware loader helpers Daniel Wagner 2016-07-28 7:55 ` [RFC v0 1/8] selftests: firmware: do not abort test too early Daniel Wagner 2016-07-28 7:55 ` [RFC v0 2/8] selftests: firmware: do not clutter output Daniel Wagner 2016-07-28 7:55 ` [RFC v0 3/8] firmware: Factor out firmware load helpers Daniel Wagner 2016-07-28 15:01 ` Dan Williams 2016-07-28 15:01 ` Dan Williams 2016-07-29 6:07 ` Daniel Wagner 2016-07-29 6:07 ` Daniel Wagner 2016-07-28 17:57 ` Dmitry Torokhov 2016-07-29 6:08 ` Daniel Wagner 2016-07-29 6:08 ` Daniel Wagner 2016-07-28 7:55 ` [RFC v0 4/8] Input: goodix: use firmware_stat instead of completion Daniel Wagner 2016-07-28 11:22 ` Bastien Nocera 2016-07-28 11:59 ` Daniel Wagner 2016-07-28 11:59 ` Daniel Wagner 2016-07-28 12:20 ` Bastien Nocera 2016-07-28 13:10 ` Daniel Wagner 2016-07-28 13:10 ` Daniel Wagner 2016-07-28 7:55 ` [RFC v0 5/8] ath9k_htc: " Daniel Wagner 2016-07-28 7:55 ` [RFC v0 6/8] remoteproc: " Daniel Wagner 2016-07-28 7:55 ` [RFC v0 7/8] Input: ims-pcu: " Daniel Wagner 2016-07-28 18:33 ` Dmitry Torokhov 2016-07-28 19:01 ` Bjorn Andersson 2016-07-29 6:13 ` Daniel Wagner 2016-07-29 6:13 ` Daniel Wagner 2016-07-30 12:42 ` Arend van Spriel 2016-07-30 16:58 ` Luis R. Rodriguez 2016-07-31 7:23 ` Dmitry Torokhov 2016-08-01 12:26 ` Daniel Wagner 2016-08-01 12:26 ` Daniel Wagner 2016-08-01 19:44 ` Luis R. Rodriguez 2016-08-01 19:44 ` Luis R. Rodriguez 2016-08-02 5:49 ` Daniel Wagner 2016-08-02 5:49 ` Daniel Wagner 2016-08-02 6:34 ` Luis R. Rodriguez 2016-08-02 6:53 ` Daniel Wagner 2016-08-02 6:53 ` Daniel Wagner 2016-08-02 7:41 ` Luis R. Rodriguez 2016-08-02 7:41 ` Luis R. Rodriguez 2016-08-03 6:57 ` Daniel Wagner [this message] 2016-08-03 6:57 ` Daniel Wagner 2016-08-03 15:55 ` Luis R. Rodriguez 2016-08-03 15:55 ` Luis R. Rodriguez 2016-08-03 16:18 ` Dmitry Torokhov 2016-08-03 17:37 ` Luis R. Rodriguez 2016-08-03 18:40 ` Luis R. Rodriguez 2016-08-03 18:40 ` Luis R. Rodriguez 2016-08-03 22:26 ` Bjorn Andersson 2016-08-03 7:42 ` Dmitry Torokhov 2016-08-03 11:43 ` Arend van Spriel 2016-08-03 15:18 ` Luis R. Rodriguez 2016-08-03 15:35 ` Dmitry Torokhov 2016-08-03 20:42 ` Arend van Spriel 2016-08-03 20:42 ` Arend van Spriel 2016-08-03 16:03 ` Luis R. Rodriguez 2016-08-03 17:39 ` Bjorn Andersson 2016-08-03 17:39 ` Bjorn Andersson 2016-08-03 18:08 ` Luis R. Rodriguez 2016-08-01 19:36 ` Luis R. Rodriguez 2016-08-01 17:19 ` Bjorn Andersson 2016-08-01 19:56 ` Luis R. Rodriguez 2016-08-01 21:34 ` Dmitry Torokhov 2016-07-31 7:17 ` Dmitry Torokhov 2016-07-28 7:55 ` [RFC v0 8/8] iwl4965: " Daniel Wagner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ef14dc68-d2f8-0934-7be5-dfb3a4771f27@bmw-carit.de \ --to=daniel.wagner@bmw-carit.de \ --cc=arend.vanspriel@broadcom.com \ --cc=bjorn.andersson@linaro.org \ --cc=dhowells@redhat.com \ --cc=dmitry.torokhov@gmail.com \ --cc=dwmw2@infradead.org \ --cc=gregkh@linuxfoundation.org \ --cc=hadess@hadess.net \ --cc=johannes.berg@intel.com \ --cc=julia.lawall@lip6.fr \ --cc=kvalo@codeaurora.org \ --cc=linux-input@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mcgrof@kernel.org \ --cc=ohad@wizery.com \ --cc=wagi@monom.org \ --cc=zohar@linux.vnet.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.