* [PATCH v4 1/2] firmware: add SmPL report for custom fallback mechanism [not found] ` <20170112144250.12376-1-mcgrof@kernel.org> @ 2017-01-12 14:42 ` Luis R. Rodriguez 2017-01-12 14:42 ` [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation Luis R. Rodriguez 1 sibling, 0 replies; 6+ messages in thread From: Luis R. Rodriguez @ 2017-01-12 14:42 UTC (permalink / raw) To: gregkh, ming.lei Cc: bp, wagi, teg, mchehab, zajec5, linux-kernel, markivx, stephen.boyd, broonie, zohar, tiwai, johannes, chunkeey, hauke, jwboyer, dmitry.torokhov, dwmw2, jslaby, torvalds, luto, fengguang.wu, rpurdie, j.anaszewski, Abhay_Salunke, Julia.Lawall, Gilles.Muller, nicolas.palix, dhowells, bjorn.andersson, arend.vanspriel, kvalo, Luis R. Rodriguez, linux-leds Even though most distributions today disable the fallback mechanism by default we've determined that we cannot remove them from the kernel. This is not well understood so document the reason and logic behind that. Recent discussions suggest some future userspace development prospects which may enable fallback mechanisms to become more useful while avoiding some historical issues. These discussions have made it clear though that there is less value to the custom fallback mechanism and an alternative can be provided in the future. Its also clear that some old users of the custom fallback mechanism were using it as a copy and paste error. Because of all this add a Coccinelle SmPL patch to help maintainers police for new incorrect users of the custom fallback mechanism. Best we can do for now then is police for new users of the custom fallback mechanism and and fix incorrect users when they are spotted. Drivers can only be transitioned out of the custom fallback mechanism once we know old userspace cannot be not be broken by a kernel change. The current SmPL patch reports: $ export COCCI=scripts/coccinelle/api/request_firmware-custom-fallback.cocci $ make coccicheck MODE=report drivers/leds/leds-lp55xx-common.c:227:8-31: WARNING: please check if driver really needs a custom fallback mechanism drivers/firmware/dell_rbu.c:622:17-40: WARNING: please check if driver really needs a custom fallback mechanism Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jacek Anaszewski <j.anaszewski@samsung.com> Cc: linux-leds@vger.kernel.org Cc: Abhay Salunke <Abhay_Salunke@dell.com> Acked-by: Julia.Lawall@lip6.fr Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> --- .../driver-api/firmware/fallback-mechanisms.rst | 17 +++++++++++ .../api/request_firmware-custom-fallback.cocci | 35 ++++++++++++++++++++++ 2 files changed, 52 insertions(+) create mode 100644 scripts/coccinelle/api/request_firmware-custom-fallback.cocci diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index d19354794e67..b87a292153c6 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -28,6 +28,12 @@ CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n the kobject uevent fallback mechanism will never take effect even for request_firmware_nowait() when uevent is set to true. +Although the fallback mechanisms are not used widely today they cannot be +removed from the kernel since some old userspace may exist which could +entirely depend on the fallback mechanism enabled with the kernel config option +CONFIG_FW_LOADER_USER_HELPER_FALLBACK. In the future though drivers may opt +to embrace a different API which provides alternative fallback mechanisms. + Justifying the firmware fallback mechanism ========================================== @@ -176,6 +182,17 @@ but you want to suppress kobject uevents, as you have a custom solution which will monitor for your device addition into the device hierarchy somehow and load firmware for you through a custom path. +The custom fallback mechanism can often be enabled by mistake. We currently +have only 2 users of it, and little justification to enable it for other users. +Since it is a common driver developer mistake to enable it, help police for +new users of the custom fallback mechanism with:: + + $ export COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci + $ make coccicheck MODE=report + +Drivers can only be transitioned out of the custom fallback mechanism +once we know old userspace cannot be not be broken by a kernel change. + Firmware fallback timeout ========================= diff --git a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci new file mode 100644 index 000000000000..0188d446b611 --- /dev/null +++ b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci @@ -0,0 +1,35 @@ +// Avoid the firmware custom fallback mechanism at all costs +// +// request_firmware_nowait() API enables explicit request for use of the custom +// fallback mechanism if firmware is not found. Chances are high its use is +// just a copy and paste bug. Before you fix the driver be sure to *verify* no +// custom firmware loading tool exists that would otherwise break if we replace +// the driver to use the uevent fallback mechanism. +// +// Confidence: High +// +// Copyright: (C) 2017 Luis R. Rodriguez <mcgrof@kernel.org> GPLv2. +// +// Options: --include-headers + +virtual report +virtual context + +@ r1 depends on report || context @ +expression mod, name, dev, gfp, drv, cb; +position p; +@@ + +( +*request_firmware_nowait@p(mod, false, name, dev, gfp, drv, cb) +| +*request_firmware_nowait@p(mod, 0, name, dev, gfp, drv, cb) +| +*request_firmware_nowait@p(mod, FW_ACTION_NOHOTPLUG, name, dev, gfp, drv, cb) +) + +@script:python depends on report@ +p << r1.p; +@@ + +coccilib.report.print_report(p[0], "WARNING: please check if driver really needs a custom fallback mechanism") -- 2.11.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation [not found] ` <20170112144250.12376-1-mcgrof@kernel.org> 2017-01-12 14:42 ` [PATCH v4 1/2] firmware: add SmPL report for custom fallback mechanism Luis R. Rodriguez @ 2017-01-12 14:42 ` Luis R. Rodriguez 2017-01-19 11:31 ` Greg KH 1 sibling, 1 reply; 6+ messages in thread From: Luis R. Rodriguez @ 2017-01-12 14:42 UTC (permalink / raw) To: gregkh, ming.lei Cc: bp, wagi, teg, mchehab, zajec5, linux-kernel, markivx, stephen.boyd, broonie, zohar, tiwai, johannes, chunkeey, hauke, jwboyer, dmitry.torokhov, dwmw2, jslaby, torvalds, luto, fengguang.wu, rpurdie, j.anaszewski, Abhay_Salunke, Julia.Lawall, Gilles.Muller, nicolas.palix, dhowells, bjorn.andersson, arend.vanspriel, kvalo, Luis R. Rodriguez, linux-leds We need to ensure that when driver developers use the custom firmware fallback mechanism it was not a copy and paste bug. These use cases on upstream drivers are rare, we only have 2 upstream users and its for really old drivers. Since valid uses are rare but possible enable a white-list for its use, and use this same white-list annotation to refer to the documentation covering the custom use case. New faulty users can be reported via 0-day now. v2: change dependencies on rules make more sense, and fixed context mode Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jacek Anaszewski <j.anaszewski@samsung.com> Cc: linux-leds@vger.kernel.org Cc: Abhay Salunke <Abhay_Salunke@dell.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> --- Documentation/driver-api/firmware/fallback-mechanisms.rst | 7 +++++-- drivers/firmware/dell_rbu.c | 1 + drivers/leds/leds-lp55xx-common.c | 1 + include/linux/firmware.h | 7 +++++++ scripts/coccinelle/api/request_firmware-custom-fallback.cocci | 9 ++++++++- 5 files changed, 22 insertions(+), 3 deletions(-) diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst index b87a292153c6..73f509a8d2de 100644 --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst @@ -184,8 +184,11 @@ load firmware for you through a custom path. The custom fallback mechanism can often be enabled by mistake. We currently have only 2 users of it, and little justification to enable it for other users. -Since it is a common driver developer mistake to enable it, help police for -new users of the custom fallback mechanism with:: +Since it is a common driver developer mistake to enable it, driver developers +should use DECLARE_FW_CUSTOM_FALLBACK() to both white-list and validate their +use and also refer to the documentation for the custom loading solution. + +Invalid users of the custom fallback mechanism can be policed using:: $ export COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci $ make coccicheck MODE=report diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c index 2f452f1f7c8a..3f2aa35bc54d 100644 --- a/drivers/firmware/dell_rbu.c +++ b/drivers/firmware/dell_rbu.c @@ -586,6 +586,7 @@ static ssize_t read_rbu_image_type(struct file *filp, struct kobject *kobj, return size; } +DECLARE_FW_CUSTOM_FALLBACK("Documentation/dell_rbu.txt"); static ssize_t write_rbu_image_type(struct file *filp, struct kobject *kobj, struct bin_attribute *bin_attr, char *buffer, loff_t pos, size_t count) diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c index 5377f22ff994..04161428ee3b 100644 --- a/drivers/leds/leds-lp55xx-common.c +++ b/drivers/leds/leds-lp55xx-common.c @@ -219,6 +219,7 @@ static void lp55xx_firmware_loaded(const struct firmware *fw, void *context) release_firmware(chip->fw); } +DECLARE_FW_CUSTOM_FALLBACK("Documentation/leds/leds-lp55xx.txt"); static int lp55xx_request_firmware(struct lp55xx_chip *chip) { const char *name = chip->cl->name; diff --git a/include/linux/firmware.h b/include/linux/firmware.h index b1f9f0ccb8ac..e6ca19c03dcc 100644 --- a/include/linux/firmware.h +++ b/include/linux/firmware.h @@ -8,6 +8,13 @@ #define FW_ACTION_NOHOTPLUG 0 #define FW_ACTION_HOTPLUG 1 +/* + * Helper for scripts/coccinelle/api/request_firmware-custom-fallback.cocci + * and so users can also easily search for the documentation for the + * respectively needed custom fallback mechanism. + */ +#define DECLARE_FW_CUSTOM_FALLBACK(__usermode_helper) + struct firmware { size_t size; const u8 *data; diff --git a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci index 0188d446b611..a1ed9d633441 100644 --- a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci +++ b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci @@ -15,7 +15,14 @@ virtual report virtual context -@ r1 depends on report || context @ +@ r0 depends on report || context @ +declarer name DECLARE_FW_CUSTOM_FALLBACK; +expression E; +@@ + +DECLARE_FW_CUSTOM_FALLBACK(E); + +@ r1 depends on !r0 && (report || context) @ expression mod, name, dev, gfp, drv, cb; position p; @@ -- 2.11.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation 2017-01-12 14:42 ` [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation Luis R. Rodriguez @ 2017-01-19 11:31 ` Greg KH 2017-01-19 16:08 ` Luis R. Rodriguez 0 siblings, 1 reply; 6+ messages in thread From: Greg KH @ 2017-01-19 11:31 UTC (permalink / raw) To: Luis R. Rodriguez Cc: ming.lei, bp, wagi, teg, mchehab, zajec5, linux-kernel, markivx, stephen.boyd, broonie, zohar, tiwai, johannes, chunkeey, hauke, jwboyer, dmitry.torokhov, dwmw2, jslaby, torvalds, luto, fengguang.wu, rpurdie, j.anaszewski, Abhay_Salunke, Julia.Lawall, Gilles.Muller, nicolas.palix, dhowells, bjorn.andersson, arend.vanspriel, kvalo, linux-leds On Thu, Jan 12, 2017 at 06:42:50AM -0800, Luis R. Rodriguez wrote: > We need to ensure that when driver developers use the custom firmware > fallback mechanism it was not a copy and paste bug. These use cases on > upstream drivers are rare, we only have 2 upstream users and its for > really old drivers. Since valid uses are rare but possible enable a > white-list for its use, and use this same white-list annotation to refer > to the documentation covering the custom use case. > > New faulty users can be reported via 0-day now. > > v2: change dependencies on rules make more sense, and fixed > context mode > > Cc: Fengguang Wu <fengguang.wu@intel.com> > Cc: Richard Purdie <rpurdie@rpsys.net> > Cc: Jacek Anaszewski <j.anaszewski@samsung.com> > Cc: linux-leds@vger.kernel.org > Cc: Abhay Salunke <Abhay_Salunke@dell.com> > Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> > Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> > --- > Documentation/driver-api/firmware/fallback-mechanisms.rst | 7 +++++-- > drivers/firmware/dell_rbu.c | 1 + > drivers/leds/leds-lp55xx-common.c | 1 + > include/linux/firmware.h | 7 +++++++ > scripts/coccinelle/api/request_firmware-custom-fallback.cocci | 9 ++++++++- > 5 files changed, 22 insertions(+), 3 deletions(-) > > diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst b/Documentation/driver-api/firmware/fallback-mechanisms.rst > index b87a292153c6..73f509a8d2de 100644 > --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst > +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst > @@ -184,8 +184,11 @@ load firmware for you through a custom path. > > The custom fallback mechanism can often be enabled by mistake. We currently > have only 2 users of it, and little justification to enable it for other users. > -Since it is a common driver developer mistake to enable it, help police for > -new users of the custom fallback mechanism with:: > +Since it is a common driver developer mistake to enable it, driver developers > +should use DECLARE_FW_CUSTOM_FALLBACK() to both white-list and validate their > +use and also refer to the documentation for the custom loading solution. > + > +Invalid users of the custom fallback mechanism can be policed using:: Ick, no, why? Why not just add a checkpatch rule instead? > > $ export COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci > $ make coccicheck MODE=report > diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c > index 2f452f1f7c8a..3f2aa35bc54d 100644 > --- a/drivers/firmware/dell_rbu.c > +++ b/drivers/firmware/dell_rbu.c > @@ -586,6 +586,7 @@ static ssize_t read_rbu_image_type(struct file *filp, struct kobject *kobj, > return size; > } > > +DECLARE_FW_CUSTOM_FALLBACK("Documentation/dell_rbu.txt"); That's a pain. > static ssize_t write_rbu_image_type(struct file *filp, struct kobject *kobj, > struct bin_attribute *bin_attr, > char *buffer, loff_t pos, size_t count) > diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c > index 5377f22ff994..04161428ee3b 100644 > --- a/drivers/leds/leds-lp55xx-common.c > +++ b/drivers/leds/leds-lp55xx-common.c > @@ -219,6 +219,7 @@ static void lp55xx_firmware_loaded(const struct firmware *fw, void *context) > release_firmware(chip->fw); > } > > +DECLARE_FW_CUSTOM_FALLBACK("Documentation/leds/leds-lp55xx.txt"); Same here. > static int lp55xx_request_firmware(struct lp55xx_chip *chip) > { > const char *name = chip->cl->name; > diff --git a/include/linux/firmware.h b/include/linux/firmware.h > index b1f9f0ccb8ac..e6ca19c03dcc 100644 > --- a/include/linux/firmware.h > +++ b/include/linux/firmware.h > @@ -8,6 +8,13 @@ > #define FW_ACTION_NOHOTPLUG 0 > #define FW_ACTION_HOTPLUG 1 > > +/* > + * Helper for scripts/coccinelle/api/request_firmware-custom-fallback.cocci > + * and so users can also easily search for the documentation for the > + * respectively needed custom fallback mechanism. > + */ > +#define DECLARE_FW_CUSTOM_FALLBACK(__usermode_helper) So you really don't need to put anything "valid" in the define argument? This feels like such a horrid hack, I really don't like it, especially as we don't do it anywhere else in the kernel, right? Why start now? thanks, greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation 2017-01-19 11:31 ` Greg KH @ 2017-01-19 16:08 ` Luis R. Rodriguez 2017-01-19 16:14 ` Greg KH 0 siblings, 1 reply; 6+ messages in thread From: Luis R. Rodriguez @ 2017-01-19 16:08 UTC (permalink / raw) To: Greg KH Cc: Luis R. Rodriguez, ming.lei, bp, wagi, teg, mchehab, zajec5, linux-kernel, markivx, stephen.boyd, broonie, zohar, tiwai, johannes, chunkeey, hauke, jwboyer, dmitry.torokhov, dwmw2, jslaby, torvalds, luto, fengguang.wu, rpurdie, j.anaszewski, Abhay_Salunke, Julia.Lawall, Gilles.Muller, nicolas.palix, dhowells, bjorn.andersson, arend.vanspriel, kvalo, linux-leds On Thu, Jan 19, 2017 at 12:31:11PM +0100, Greg KH wrote: > On Thu, Jan 12, 2017 at 06:42:50AM -0800, Luis R. Rodriguez wrote: > > +Invalid users of the custom fallback mechanism can be policed using:: > > Ick, no, why? Why not just add a checkpatch rule instead? If its easy to do, how would we do that? > > > > $ export COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci > > $ make coccicheck MODE=report > > diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c > > index 2f452f1f7c8a..3f2aa35bc54d 100644 > > --- a/drivers/firmware/dell_rbu.c > > +++ b/drivers/firmware/dell_rbu.c > > @@ -586,6 +586,7 @@ static ssize_t read_rbu_image_type(struct file *filp, struct kobject *kobj, > > return size; > > } > > > > +DECLARE_FW_CUSTOM_FALLBACK("Documentation/dell_rbu.txt"); > > That's a pain. It is easier with checkpatch? > > diff --git a/include/linux/firmware.h b/include/linux/firmware.h > > index b1f9f0ccb8ac..e6ca19c03dcc 100644 > > --- a/include/linux/firmware.h > > +++ b/include/linux/firmware.h > > @@ -8,6 +8,13 @@ > > #define FW_ACTION_NOHOTPLUG 0 > > #define FW_ACTION_HOTPLUG 1 > > > > +/* > > + * Helper for scripts/coccinelle/api/request_firmware-custom-fallback.cocci > > + * and so users can also easily search for the documentation for the > > + * respectively needed custom fallback mechanism. > > + */ > > +#define DECLARE_FW_CUSTOM_FALLBACK(__usermode_helper) > > So you really don't need to put anything "valid" in the define argument? > This feels like such a horrid hack, I really don't like it, especially > as we don't do it anywhere else in the kernel, right? Why start now? Correct me if I'm wrong but AFAICT we may not have had previous grammatical policing done before so I think this is a question of how we would want to handle such type of strategies. Indeed this is just one approach. Using checkpatch is certainly possible as well, I however think using checkpatch is a bit more hacky. I could also just drop this completely but figured its worth discussion. Luis ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation 2017-01-19 16:08 ` Luis R. Rodriguez @ 2017-01-19 16:14 ` Greg KH 2017-01-19 21:38 ` Luis R. Rodriguez 0 siblings, 1 reply; 6+ messages in thread From: Greg KH @ 2017-01-19 16:14 UTC (permalink / raw) To: Luis R. Rodriguez Cc: ming.lei, bp, wagi, teg, mchehab, zajec5, linux-kernel, markivx, stephen.boyd, broonie, zohar, tiwai, johannes, chunkeey, hauke, jwboyer, dmitry.torokhov, dwmw2, jslaby, torvalds, luto, fengguang.wu, rpurdie, j.anaszewski, Abhay_Salunke, Julia.Lawall, Gilles.Muller, nicolas.palix, dhowells, bjorn.andersson, arend.vanspriel, kvalo, linux-leds On Thu, Jan 19, 2017 at 05:08:25PM +0100, Luis R. Rodriguez wrote: > On Thu, Jan 19, 2017 at 12:31:11PM +0100, Greg KH wrote: > > On Thu, Jan 12, 2017 at 06:42:50AM -0800, Luis R. Rodriguez wrote: > > > +Invalid users of the custom fallback mechanism can be policed using:: > > > > Ick, no, why? Why not just add a checkpatch rule instead? > > If its easy to do, how would we do that? You just patch checkpatch.pl to test for the apis you don't want used anymore. > > > $ export COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci > > > $ make coccicheck MODE=report > > > diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c > > > index 2f452f1f7c8a..3f2aa35bc54d 100644 > > > --- a/drivers/firmware/dell_rbu.c > > > +++ b/drivers/firmware/dell_rbu.c > > > @@ -586,6 +586,7 @@ static ssize_t read_rbu_image_type(struct file *filp, struct kobject *kobj, > > > return size; > > > } > > > > > > +DECLARE_FW_CUSTOM_FALLBACK("Documentation/dell_rbu.txt"); > > > > That's a pain. > > It is easier with checkpatch? Yes. You are modifying the .c code just to "whitelist" an api you want to check for. What's the odds that someone who wants to use that api just cargo-cult-copies this line as well, to prevent the strange warning they are getting from the build system? :) In short, don't worry about this, it's not a big deal nor really worth the effort. thanks, greg k-h ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation 2017-01-19 16:14 ` Greg KH @ 2017-01-19 21:38 ` Luis R. Rodriguez 0 siblings, 0 replies; 6+ messages in thread From: Luis R. Rodriguez @ 2017-01-19 21:38 UTC (permalink / raw) To: Greg KH Cc: Luis R. Rodriguez, ming.lei, bp, wagi, teg, mchehab, zajec5, linux-kernel, markivx, stephen.boyd, broonie, zohar, tiwai, johannes, chunkeey, hauke, jwboyer, dmitry.torokhov, dwmw2, jslaby, torvalds, luto, fengguang.wu, rpurdie, j.anaszewski, Abhay_Salunke, Julia.Lawall, Gilles.Muller, nicolas.palix, dhowells, bjorn.andersson, arend.vanspriel, kvalo, linux-leds On Thu, Jan 19, 2017 at 05:14:36PM +0100, Greg KH wrote: > In short, don't worry about this, it's not a big deal nor really worth > the effort. Fine by me, I'll drop these two patches. Luis ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-19 21:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20161213030828.17820-4-mcgrof@kernel.org>
[not found] ` <20170112144250.12376-1-mcgrof@kernel.org>
2017-01-12 14:42 ` [PATCH v4 1/2] firmware: add SmPL report for custom fallback mechanism Luis R. Rodriguez
2017-01-12 14:42 ` [PATCH v4 2/2] firmware: add DECLARE_FW_CUSTOM_FALLBACK() annotation Luis R. Rodriguez
2017-01-19 11:31 ` Greg KH
2017-01-19 16:08 ` Luis R. Rodriguez
2017-01-19 16:14 ` Greg KH
2017-01-19 21:38 ` Luis R. Rodriguez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).