Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1602142 > unrolled thread
| Started by | Rafał Miłecki <zajec5@gmail.com> |
|---|---|
| First post | 2017-03-16 11:00 +0100 |
| Last post | 2017-03-16 14:50 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function Rafał Miłecki <zajec5@gmail.com> - 2017-03-16 11:00 +0100
Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function Greg KH <gregkh@linuxfoundation.org> - 2017-03-16 14:50 +0100
| From | Rafał Miłecki <zajec5@gmail.com> |
|---|---|
| Date | 2017-03-16 11:00 +0100 |
| Subject | Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function |
| Message-ID | <tlAmm-4QJ-5@gated-at.bofh.it> |
On 23 February 2017 at 19:30, Rafał Miłecki <zajec5@gmail.com> wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > So far we got only one function for loading firmware asynchronously: > request_firmware_nowait. It didn't allow much customization of firmware > loading process - there is only one bool uevent argument. Moreover this > bool also controls user helper in an unclear way. > > Resolve this problem by adding one internally shared function that > allows specifying any flags manually. > > This implementation: > 1) Allows keeping old request_firmware_nowait API unchanged > 2) Doesn't require adjusting / rewriting current drivers > 3) Minimizes risk of regressions > 4) Adds new function for drivers that need more control over loading a > firmware. > > The new function takes options struct pointer as an argument to make > further improvements possible (without any big reworks). > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > --- > V3: Don't expose all FW_OPT_* flags. > As Luis noted we want a struct so add struct firmware_opts for real > flexibility. > Thank you Luis for your review! > > Ming/Luis/Greg: assuming this gets a positive review, could someone of you pick > this patchset? Ping. I hope it's relatively simple and non-intrusive change with a proper design now. Is there some who could pick this small patchset?
[toc] | [next] | [standalone]
| From | Greg KH <gregkh@linuxfoundation.org> |
|---|---|
| Date | 2017-03-16 14:50 +0100 |
| Subject | Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function |
| Message-ID | <tlDWW-7vw-25@gated-at.bofh.it> |
| In reply to | #1602142 |
On Thu, Mar 16, 2017 at 10:57:00AM +0100, Rafał Miłecki wrote: > On 23 February 2017 at 19:30, Rafał Miłecki <zajec5@gmail.com> wrote: > > From: Rafał Miłecki <rafal@milecki.pl> > > > > So far we got only one function for loading firmware asynchronously: > > request_firmware_nowait. It didn't allow much customization of firmware > > loading process - there is only one bool uevent argument. Moreover this > > bool also controls user helper in an unclear way. > > > > Resolve this problem by adding one internally shared function that > > allows specifying any flags manually. > > > > This implementation: > > 1) Allows keeping old request_firmware_nowait API unchanged > > 2) Doesn't require adjusting / rewriting current drivers > > 3) Minimizes risk of regressions > > 4) Adds new function for drivers that need more control over loading a > > firmware. > > > > The new function takes options struct pointer as an argument to make > > further improvements possible (without any big reworks). > > > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > > --- > > V3: Don't expose all FW_OPT_* flags. > > As Luis noted we want a struct so add struct firmware_opts for real > > flexibility. > > Thank you Luis for your review! > > > > Ming/Luis/Greg: assuming this gets a positive review, could someone of you pick > > this patchset? > > Ping. I hope it's relatively simple and non-intrusive change with a > proper design now. > > Is there some who could pick this small patchset? It would be nice if the firmware maintainer could review it, I can't do anything with this until then... thanks, greg k-h
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web