| Message ID | 20191004145056.43267-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | efi/firmware/platform-x86: Add EFI embedded fw support | expand |
* Hans de Goede <hdegoede@redhat.com> wrote: > Hi All, > > Here is v7 of my patch-set to add support for EFI embedded fw to the kernel. > > v6 was posted a long time ago, around the 4.18 days. The long wait was for > a suitable secure-hash for checking the firmware we find embedded in the EFI > is the one we expect. > > With 5.4-rc1 we finally have a standalone sha256 lib, so that hurdle for > this patch-set is now gone. > > I've tried to address all review-remarks against v6 in this new version: > > Changes in v7: > - Split drivers/firmware/efi and drivers/base/firmware_loader changes into > 2 patches > - Use new, standalone, lib/crypto/sha256.c code > - Address kdoc comments from Randy Dunlap > - Add new FW_OPT_FALLBACK_PLATFORM flag and firmware_request_platform() > _request_firmware() wrapper, as requested by Luis R. Rodriguez > - Stop using "efi-embedded-firmware" device-property, now that drivers need to > use the new firmware_request_platform() to enable fallback to a device fw > copy embedded in the platform's main firmware, we no longer need a property > on the device to trigger this behavior > - Use security_kernel_load_data instead of calling > security_kernel_read_file with a NULL file pointer argument > - Move the docs to Documentation/driver-api/firmware/fallback-mechanisms.rst > - Document the new firmware_request_platform() function in > Documentation/driver-api/firmware/request_firmware.rst > - Add 2 new patches for the silead and chipone-icn8505 touchscreen drivers > to use the new firmware_request_platform() method > - Rebased on top of 5.4-rc1 > > I guess this will probably need another round (ot two) of review + fixing, > but eventually this can hopefully be merged. Since this touches a bunch > of different subsystems the question is how to merge this? Most of the > touched files outside of the firmware-loader code do not see a lot of > churn, so my proposal would be to merge patches 1-6 through the tree > which carries firmware-loader changes; and then provide an immutable > branch for the platform/x86 maintainers to merge and then they can merge > the last 2 patches (as the touchscreen_dmi.c file does see quite a bit > of changes every release). So I was looking for a high level 0/ boilerplate description of this series, to explain what "EFI embedded fw" is, what problems it solves and how it helps the kernel in general - and found this in 2/8: >> Just like with PCI options ROMs, which we save in the setup_efi_pci* >> functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself >> sometimes may contain data which is useful/necessary for peripheral drivers >> to have access to. >> >> Specifically the EFI code may contain an embedded copy of firmware which >> needs to be (re)loaded into the peripheral. Normally such firmware would be >> part of linux-firmware, but in some cases this is not feasible, for 2 >> reasons: >> >> 1) The firmware is customized for a specific use-case of the chipset / use >> with a specific hardware model, so we cannot have a single firmware file >> for the chipset. E.g. touchscreen controller firmwares are compiled >> specifically for the hardware model they are used with, as they are >> calibrated for a specific model digitizer. >> >> 2) Despite repeated attempts we have failed to get permission to >> redistribute the firmware. This is especially a problem with customized >> firmwares, these get created by the chip vendor for a specific ODM and the >> copyright may partially belong with the ODM, so the chip vendor cannot >> give a blanket permission to distribute these. >> >> This commit adds support for finding peripheral firmware embedded in the >> EFI code and makes the found firmware available through the new >> efi_get_embedded_fw() function. >> >> Support for loading these firmwares through the standard firmware loading >> mechanism is added in a follow-up commit in this patch-series. >> >> Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end >> of start_kernel(), just before calling rest_init(), this is on purpose >> because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for >> early_memremap(), so the check must be done after mm_init(). This relies >> on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services() >> is called, which means that this will only work on x86 for now. >> >> Reported-by: Dave Olsthoorn <dave@bewaar.me> >> Suggested-by: Peter Jones <pjones@redhat.com> >> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> There's also patch #3, which explains how this is used: >> This commit adds a new platform fallback mechanism to the firmware loader >> which will try to lookup a device fw copy embedded in the platform's main >> firmware if direct filesystem lookup fails. >> >> Drivers which need such embedded fw copies can enable this fallback >> mechanism by using the new firmware_request_platform() function. >> >> Note that for now this is only supported on EFI platforms and even on >> these platforms firmware_fallback_platform() only works if >> CONFIG_EFI_EMBEDDED_FIRMWARE is enabled (this gets selected by drivers >> which need this), in all other cases firmware_fallback_platform() simply >> always returns -ENOENT. Plus there's 3 patches that opt in three drivers to this new EFI-firmware loading mechanism, right? A couple of high level questions: - How common are these kinds of firmware files that should be loaded into the device by the OS device driver? Common? Or 1% of systems? 0.1% of systems? 0.0001%? - Can there be a situation where linux-firmware already includes an older copy of the firmware, and the EFI firmware has a newer version? If this can plausibly happen, shouldn't the fallback mechanism do some sort of version check (if that's possible), and load the newer version? - I'm worried about the explicit opt-in nature of these firmware files - the OS driver has to be explicitly aware of this possibility. Shouldn't we at minimum have some sort of boot time check to see whether a device has an embedded fw blob, and warn the user if we don't actually load it? Which would generate some gentle pressure to fix our drivers? - I think the config option should be default-y, because AFAICS this mechanism makes broken drivers/devices work. - Finally, is there any question of trust or a potential for other security pitfalls here, where we'd trust linux-firmware over what the EFI firmware says is the proper firmware for a device? My default assumption would be that we are exposed to the EFI firmware anyway, and it comes with the hardware just like the devices come with the hardware, so we can generally trust it. But I might be missing something. If there's any plausible question of trust (for example can attackers hide rooted firmware in the EFI image, without triggering filesystem integrity checks on the regular filesystem side?) then it might make sense to offer a boot parameter to disable this, beyond the config parameter. Thanks, Ingo
Hi Ingo, On 07-10-2019 16:19, Ingo Molnar wrote: > > * Hans de Goede <hdegoede@redhat.com> wrote: > >> Hi All, >> >> Here is v7 of my patch-set to add support for EFI embedded fw to the kernel. >> >> v6 was posted a long time ago, around the 4.18 days. The long wait was for >> a suitable secure-hash for checking the firmware we find embedded in the EFI >> is the one we expect. >> >> With 5.4-rc1 we finally have a standalone sha256 lib, so that hurdle for >> this patch-set is now gone. >> >> I've tried to address all review-remarks against v6 in this new version: >> >> Changes in v7: >> - Split drivers/firmware/efi and drivers/base/firmware_loader changes into >> 2 patches >> - Use new, standalone, lib/crypto/sha256.c code >> - Address kdoc comments from Randy Dunlap >> - Add new FW_OPT_FALLBACK_PLATFORM flag and firmware_request_platform() >> _request_firmware() wrapper, as requested by Luis R. Rodriguez >> - Stop using "efi-embedded-firmware" device-property, now that drivers need to >> use the new firmware_request_platform() to enable fallback to a device fw >> copy embedded in the platform's main firmware, we no longer need a property >> on the device to trigger this behavior >> - Use security_kernel_load_data instead of calling >> security_kernel_read_file with a NULL file pointer argument >> - Move the docs to Documentation/driver-api/firmware/fallback-mechanisms.rst >> - Document the new firmware_request_platform() function in >> Documentation/driver-api/firmware/request_firmware.rst >> - Add 2 new patches for the silead and chipone-icn8505 touchscreen drivers >> to use the new firmware_request_platform() method >> - Rebased on top of 5.4-rc1 >> >> I guess this will probably need another round (or two) of review + fixing, >> but eventually this can hopefully be merged. Since this touches a bunch >> of different subsystems the question is how to merge this? Most of the >> touched files outside of the firmware-loader code do not see a lot of >> churn, so my proposal would be to merge patches 1-6 through the tree >> which carries firmware-loader changes; and then provide an immutable >> branch for the platform/x86 maintainers to merge and then they can merge >> the last 2 patches (as the touchscreen_dmi.c file does see quite a bit >> of changes every release). > > So I was looking for a high level 0/ boilerplate description of this > series, to explain what "EFI embedded fw" is, what problems it solves and > how it helps the kernel in general - and found this in 2/8: Sorry you had to dig into the individual patch changelogs for that I sorta assumed that everyone involved would still vaguely remember what this series is about. >>> Just like with PCI options ROMs, which we save in the setup_efi_pci* >>> functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself >>> sometimes may contain data which is useful/necessary for peripheral drivers >>> to have access to. >>> >>> Specifically the EFI code may contain an embedded copy of firmware which >>> needs to be (re)loaded into the peripheral. Normally such firmware would be >>> part of linux-firmware, but in some cases this is not feasible, for 2 >>> reasons: >>> >>> 1) The firmware is customized for a specific use-case of the chipset / use >>> with a specific hardware model, so we cannot have a single firmware file >>> for the chipset. E.g. touchscreen controller firmwares are compiled >>> specifically for the hardware model they are used with, as they are >>> calibrated for a specific model digitizer. >>> >>> 2) Despite repeated attempts we have failed to get permission to >>> redistribute the firmware. This is especially a problem with customized >>> firmwares, these get created by the chip vendor for a specific ODM and the >>> copyright may partially belong with the ODM, so the chip vendor cannot >>> give a blanket permission to distribute these. >>> >>> This commit adds support for finding peripheral firmware embedded in the >>> EFI code and makes the found firmware available through the new >>> efi_get_embedded_fw() function. >>> >>> Support for loading these firmwares through the standard firmware loading >>> mechanism is added in a follow-up commit in this patch-series. >>> >>> Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end >>> of start_kernel(), just before calling rest_init(), this is on purpose >>> because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for >>> early_memremap(), so the check must be done after mm_init(). This relies >>> on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services() >>> is called, which means that this will only work on x86 for now. >>> >>> Reported-by: Dave Olsthoorn <dave@bewaar.me> >>> Suggested-by: Peter Jones <pjones@redhat.com> >>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >>> Signed-off-by: Hans de Goede <hdegoede@redhat.com> > > There's also patch #3, which explains how this is used: > >>> This commit adds a new platform fallback mechanism to the firmware loader >>> which will try to lookup a device fw copy embedded in the platform's main >>> firmware if direct filesystem lookup fails. >>> >>> Drivers which need such embedded fw copies can enable this fallback >>> mechanism by using the new firmware_request_platform() function. >>> >>> Note that for now this is only supported on EFI platforms and even on >>> these platforms firmware_fallback_platform() only works if >>> CONFIG_EFI_EMBEDDED_FIRMWARE is enabled (this gets selected by drivers >>> which need this), in all other cases firmware_fallback_platform() simply >>> always returns -ENOENT. > > Plus there's 3 patches that opt in three drivers to this new EFI-firmware > loading mechanism, right? There is 1 pseudo driver drivers/platform/touchscreen_dmi.c which provides info which under Windows is hardcoded in device-model specific drivers to the touchscreen drivers as device-properties. This pseudo driver is modified to provide the info which drivers/firmware/efi/embedded-firmware.c needs to find the firmware, so that we keep the per-model info in 1 file. Then 2 normal touchscreen drivers are modified to opt-in into the new EFI-firmware loading mechanism. > A couple of high level questions: > > - How common are these kinds of firmware files that should be loaded into > the device by the OS device driver? Common? Or 1% of systems? 0.1% of > systems? 0.0001%? This whole thing is a clever hack to get around us being unable to get redistribution permission for (touchscreen) firmwares where the chip vendor says the firmware is model specific so part of the copyright lays with the odm/oem and we should talk to them (the odm) and the odm/oem points back to the chip vendor... Windows does not get the firmware from the UEFI copy, the windows driver is model specific. The windows driver is part of the os-image the device ships with and you are in trouble if you loose the driver. This windows driver has its own embedded copy of the model specific touchscreen firmware (oh if only they had put said firmware in some nvram on the chip). In some cases, mostly on Intel Cherry Trail based tablets, which are cheap and thus use the cheapest touchscreens which have this problem, the UEFI contains a "mouse" driver which has a copy, which is what this patch set adds support for to get around the not being able to distribute problem. As such this is not really common, still there are a lot of those cheap Cherry Trail tablets and new ones are still being manufactured. One of the reasons I'm spending time on making these work 100% OOTB is to get around the standard Linux sucks at tablets because desktop devs have no tablet hw to develop a tablet ui on issue. I also have tried to make the mechanism generic since I guess it might become in handy for some other scenarios in the future. Putting a number on this is hard. I do know several members of my local hackerspace have such tablets since they are cheap and it is nice to play around with Linux on them. I would guess a number would be between 1% and 0.1%, but I may be way off. > - Can there be a situation where linux-firmware already includes an older > copy of the firmware, and the EFI firmware has a newer version? If this > can plausibly happen, shouldn't the fallback mechanism do some sort of > version check (if that's possible), and load the newer version? I would assume that if we can get distribution permission we will also be able to update the linux-firmware version later. So atm I'm not worried about this scenario. > - I'm worried about the explicit opt-in nature of these firmware files - > the OS driver has to be explicitly aware of this possibility. Shouldn't > we at minimum have some sort of boot time check to see whether a device > has an embedded fw blob, and warn the user if we don't actually load > it? Which would generate some gentle pressure to fix our drivers? The way this works is that drivers/firmware/efi/embedded-firmware.c only checks for firmwares listed in its embedded_fw_table[]. Entries in this table need to be manually added. We basically do a brute-force search of the EFI_BOOT_SERVICES_CODE segments looking for a magic prefix and then checking for a known SHA256 sum. This is triggered by a DMI match to avoid slowing the boot with the search on other devices (UEFI has no standard way to get embedded firmware copies out of it). I would assume someone going through the trouble to add an entry to embedded_fw_table[] to also check that things work without a copy in /lib/firmware. So the scenario of a new entry showing up, without the matching driver getting modified is somewhat unlikely. At the same time the firmware-loader people want to avoid changing the fw-load code paths for all drivers, for something which so far is used by only very few drivers. > - I think the config option should be default-y, because AFAICS this > mechanism makes broken drivers/devices work. It is a hidden option and drivers which need this already select it in this patch-set. > - Finally, is there any question of trust or a potential for other > security pitfalls here, where we'd trust linux-firmware over what the > EFI firmware says is the proper firmware for a device? My default > assumption would be that we are exposed to the EFI firmware anyway, and > it comes with the hardware just like the devices come with the > hardware, so we can generally trust it. But I might be missing > something. If there's any plausible question of trust (for example can > attackers hide rooted firmware in the EFI image, without triggering > filesystem integrity checks on the regular filesystem side?) then it > might make sense to offer a boot parameter to disable this, beyond the > config parameter. You are right that we are exposed to the EFI firmware anyway on top we only load embedded firmwares with a known SHA256 and so far the firmware only gets used for touchscreen controllers which cannot do DMA. So all in all I am not concerned about security. An attacker would need to be able to write EFI_BOOT_SERVICES_CODE segments, yet not be able to find a better attack vector then this; and he would need to be able to fake an expected SHA256 sum on a Trojan firmware payload, which all is quite unlikely. Regards, Hans
* Hans de Goede <hdegoede@redhat.com> wrote: > > So I was looking for a high level 0/ boilerplate description of this > > series, to explain what "EFI embedded fw" is, what problems it solves and > > how it helps the kernel in general - and found this in 2/8: > > Sorry you had to dig into the individual patch changelogs for that > I sorta assumed that everyone involved would still vaguely remember > what this series is about. Wasn't *that* hard to do and I intended to read the patches anyway. ;-) Thanks for the explanation and the answers, this all looks good to me in principle and in implementation as well. Thanks, Ingo
Hey Hans, thanks for staying on top of this and follow up! For some reason the universe conspired against your first and last patch ([1/8], [8/8]), and I never got them. Could you bounce these or resend in case others confirm they also didn't get it? While at it, can you Cc scott.branden@broadcom.com in further communications about this patchset, he's interest in some other changes we'll need to coordinate if we get to have some other development in line for the next merge window. Luis
Hi, On 10/11/19 4:10 PM, Luis Chamberlain wrote: > Hey Hans, thanks for staying on top of this and follow up! For some > reason the universe conspired against your first and last patch ([1/8], > [8/8]), and I never got them. Could you bounce these or resend in case > others confirm they also didn't get it? I have received feedback from others on the first patch, so at least that one has reached others. I've bounced patches 1 and 8 to you. > While at it, can you Cc scott.branden@broadcom.com in further > communications about this patchset, he's interest in some other changes > we'll need to coordinate if we get to have some other development in > line for the next merge window. Will do. Regards, Hans
On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > Hi, > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > Hey Hans, thanks for staying on top of this and follow up! For some > > reason the universe conspired against your first and last patch ([1/8], > > [8/8]), and I never got them. Could you bounce these or resend in case > > others confirm they also didn't get it? > > I have received feedback from others on the first patch, so at least > that one has reached others. I've bounced patches 1 and 8 to you. Thanks, can you also bounce the feedback received? Luis
On Fri, Oct 11, 2019 at 03:38:23PM +0000, Luis Chamberlain wrote: > On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > > Hi, > > > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > > Hey Hans, thanks for staying on top of this and follow up! For some > > > reason the universe conspired against your first and last patch ([1/8], > > > [8/8]), and I never got them. Could you bounce these or resend in case > > > others confirm they also didn't get it? > > > > I have received feedback from others on the first patch, so at least > > that one has reached others. I've bounced patches 1 and 8 to you. > > Thanks, can you also bounce the feedback received? That is what lore.kernel.org is for...
On Fri, Oct 11, 2019 at 06:38:19PM +0200, Greg Kroah-Hartman wrote: > On Fri, Oct 11, 2019 at 03:38:23PM +0000, Luis Chamberlain wrote: > > On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > > > Hi, > > > > > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > > > Hey Hans, thanks for staying on top of this and follow up! For some > > > > reason the universe conspired against your first and last patch ([1/8], > > > > [8/8]), and I never got them. Could you bounce these or resend in case > > > > others confirm they also didn't get it? > > > > > > I have received feedback from others on the first patch, so at least > > > that one has reached others. I've bounced patches 1 and 8 to you. > > > > Thanks, can you also bounce the feedback received? > > That is what lore.kernel.org is for... If I have feedback on an email which I did not get I cannot easily reply to it. In the future I'd like lore to let me bounce emails from a thread to me, but that is not possible today AFAICT? Luis
On Mon, Oct 14, 2019 at 09:22:16AM +0000, Luis Chamberlain wrote: > On Fri, Oct 11, 2019 at 06:38:19PM +0200, Greg Kroah-Hartman wrote: > > On Fri, Oct 11, 2019 at 03:38:23PM +0000, Luis Chamberlain wrote: > > > On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > > > > Hi, > > > > > > > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > > > > Hey Hans, thanks for staying on top of this and follow up! For some > > > > > reason the universe conspired against your first and last patch ([1/8], > > > > > [8/8]), and I never got them. Could you bounce these or resend in case > > > > > others confirm they also didn't get it? > > > > > > > > I have received feedback from others on the first patch, so at least > > > > that one has reached others. I've bounced patches 1 and 8 to you. > > > > > > Thanks, can you also bounce the feedback received? > > > > That is what lore.kernel.org is for... > > If I have feedback on an email which I did not get I cannot easily reply to it. I meant, use lore.kernel.org to download the mbox of the thread and then use your email client to respond to whatever you need there. This all is public, no need to ask anyone else to bounce emails to you. greg k-h
On Mon, Oct 14, 2019 at 11:29:29AM +0200, Greg Kroah-Hartman wrote: > On Mon, Oct 14, 2019 at 09:22:16AM +0000, Luis Chamberlain wrote: > > On Fri, Oct 11, 2019 at 06:38:19PM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Oct 11, 2019 at 03:38:23PM +0000, Luis Chamberlain wrote: > > > > On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > > > > > Hi, > > > > > > > > > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > > > > > Hey Hans, thanks for staying on top of this and follow up! For some > > > > > > reason the universe conspired against your first and last patch ([1/8], > > > > > > [8/8]), and I never got them. Could you bounce these or resend in case > > > > > > others confirm they also didn't get it? > > > > > > > > > > I have received feedback from others on the first patch, so at least > > > > > that one has reached others. I've bounced patches 1 and 8 to you. > > > > > > > > Thanks, can you also bounce the feedback received? > > > > > > That is what lore.kernel.org is for... > > > > If I have feedback on an email which I did not get I cannot easily reply to it. > > I meant, use lore.kernel.org to download the mbox of the thread and then > use your email client to respond to whatever you need there. This all > is public, no need to ask anyone else to bounce emails to you. Last I looked it didn't allow you to downlaod an mbox of a thread... I'll take a look next time I miss a few emails. Luis
On Mon, Oct 14, 2019 at 10:31:50AM +0000, Luis Chamberlain wrote: > On Mon, Oct 14, 2019 at 11:29:29AM +0200, Greg Kroah-Hartman wrote: > > On Mon, Oct 14, 2019 at 09:22:16AM +0000, Luis Chamberlain wrote: > > > On Fri, Oct 11, 2019 at 06:38:19PM +0200, Greg Kroah-Hartman wrote: > > > > On Fri, Oct 11, 2019 at 03:38:23PM +0000, Luis Chamberlain wrote: > > > > > On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > > > > > > Hi, > > > > > > > > > > > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > > > > > > Hey Hans, thanks for staying on top of this and follow up! For some > > > > > > > reason the universe conspired against your first and last patch ([1/8], > > > > > > > [8/8]), and I never got them. Could you bounce these or resend in case > > > > > > > others confirm they also didn't get it? > > > > > > > > > > > > I have received feedback from others on the first patch, so at least > > > > > > that one has reached others. I've bounced patches 1 and 8 to you. > > > > > > > > > > Thanks, can you also bounce the feedback received? > > > > > > > > That is what lore.kernel.org is for... > > > > > > If I have feedback on an email which I did not get I cannot easily reply to it. > > > > I meant, use lore.kernel.org to download the mbox of the thread and then > > use your email client to respond to whatever you need there. This all > > is public, no need to ask anyone else to bounce emails to you. > > Last I looked it didn't allow you to downlaod an mbox of a thread... It can, from the front page of "all" threads, or on the thread itself, at the bottom of the page. Search for "download" on the page. greg k-h
On Mon, Oct 14, 2019 at 12:57:54PM +0200, Greg Kroah-Hartman wrote: > On Mon, Oct 14, 2019 at 10:31:50AM +0000, Luis Chamberlain wrote: > > On Mon, Oct 14, 2019 at 11:29:29AM +0200, Greg Kroah-Hartman wrote: > > > On Mon, Oct 14, 2019 at 09:22:16AM +0000, Luis Chamberlain wrote: > > > > On Fri, Oct 11, 2019 at 06:38:19PM +0200, Greg Kroah-Hartman wrote: > > > > > On Fri, Oct 11, 2019 at 03:38:23PM +0000, Luis Chamberlain wrote: > > > > > > On Fri, Oct 11, 2019 at 04:31:26PM +0200, Hans de Goede wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On 10/11/19 4:10 PM, Luis Chamberlain wrote: > > > > > > > > Hey Hans, thanks for staying on top of this and follow up! For some > > > > > > > > reason the universe conspired against your first and last patch ([1/8], > > > > > > > > [8/8]), and I never got them. Could you bounce these or resend in case > > > > > > > > others confirm they also didn't get it? > > > > > > > > > > > > > > I have received feedback from others on the first patch, so at least > > > > > > > that one has reached others. I've bounced patches 1 and 8 to you. > > > > > > > > > > > > Thanks, can you also bounce the feedback received? > > > > > > > > > > That is what lore.kernel.org is for... > > > > > > > > If I have feedback on an email which I did not get I cannot easily reply to it. > > > > > > I meant, use lore.kernel.org to download the mbox of the thread and then > > > use your email client to respond to whatever you need there. This all > > > is public, no need to ask anyone else to bounce emails to you. > > > > Last I looked it didn't allow you to downlaod an mbox of a thread... > > It can, from the front page of "all" threads, or on the thread itself, > at the bottom of the page. Search for "download" on the page. Sweet! <insert sound of discovering an item in Legend of Zelda> Luis