From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E38BC33CA9 for ; Sun, 12 Jan 2020 22:54:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4F96B21556 for ; Sun, 12 Jan 2020 22:54:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578869659; bh=OTPSk1FDbrul0QY/pUOTlMEtUEMURhj6Q/PvlUu/sI8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=abgA/nhdsY9KqJmMNpQC7htUkjT6lgPOwlGCKK5NGP2czJPQZdL7FJL4Zl7zcUf/9 FJh+4Ti/BFt6Tiy0DNjpNRF2kjN8MucHHqVZxBWnACH7Usnd/bXzRUdAOc9eLZc2Id IVIt5A9gDsf1TE80bhAnhAIpThvlo+UJoz/L3iGw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387482AbgALWyS (ORCPT ); Sun, 12 Jan 2020 17:54:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:56922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727222AbgALWyR (ORCPT ); Sun, 12 Jan 2020 17:54:17 -0500 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CF7E721556 for ; Sun, 12 Jan 2020 22:54:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1578869657; bh=OTPSk1FDbrul0QY/pUOTlMEtUEMURhj6Q/PvlUu/sI8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hzhvSFdpz62gogZ9QN7lfmafoGsakUjT1kaPTgxvKWg5Xq+befE3iVxPLwm79hZTC daPQyiQvVm0j+WIy9HH+k4T6lNya6yT+5xyuppstOXHcEnLAtcJfMXOwB4xoUxPQBi wd32iWGi8yUPDeOVPUB/jfWtezETqeizKYZhYU6U= Received: by mail-wr1-f43.google.com with SMTP id w15so6814015wru.4 for ; Sun, 12 Jan 2020 14:54:16 -0800 (PST) X-Gm-Message-State: APjAAAU5NXUoZBpEfJORJws9/eCqh7hL3oMlE39/CXPqzcU4bhy299zT yjJp65iZ0rrcThlnj48DzET+SDqAS4rGY10AJ64UOA== X-Google-Smtp-Source: APXvYqwqvYzhEdydCPNO7qcIvHe+8nzILh5eaIaQCyGHnDLwjQKEoFRnKyCjU2psD4HOU4Uu55mc3jpLpIFWqLzfw5Q= X-Received: by 2002:adf:f491:: with SMTP id l17mr14897341wro.149.1578869655295; Sun, 12 Jan 2020 14:54:15 -0800 (PST) MIME-Version: 1.0 References: <20200111145703.533809-1-hdegoede@redhat.com> <20200111145703.533809-5-hdegoede@redhat.com> In-Reply-To: <20200111145703.533809-5-hdegoede@redhat.com> From: Andy Lutomirski Date: Sun, 12 Jan 2020 14:54:04 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v11 04/10] firmware: Add new platform fallback mechanism and firmware_request_platform() To: Hans de Goede Cc: Ard Biesheuvel , Darren Hart , Andy Shevchenko , Luis Chamberlain , Greg Kroah-Hartman , "Rafael J . Wysocki" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Jonathan Corbet , Dmitry Torokhov , Peter Jones , Dave Olsthoorn , X86 ML , Platform Driver , linux-efi , LKML , "open list:DOCUMENTATION" , "open list:HID CORE LAYER" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 11, 2020 at 6:57 AM Hans de Goede wrote: > > In some cases the platform's main firmware (e.g. the UEFI fw) may contain > an embedded copy of device 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 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. After finally wrapping my head around how this all fits together: Early in boot, you check a bunch of firmware descriptors, bundled with drivers, to search EFI code and data for firmware before you free said code and data. You catalogue it by name. Later on, you use this list as a fallback, again catalogued by name. I think it would be rather nicer if you simply had a list in a single file containing all these descriptors rather than commingling it with the driver's internal dmi data. This gets rid of all the ifdeffery and module issues. It also avoids any potential nastiness when you have a dmi entry that contains driver_data that points into the driver when the driver is a module. And you can mark the entire list __initdata. And you can easily (now or later on) invert the code flow so you map each EFI region exactly once and then search for all the firmware in it. --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH v11 04/10] firmware: Add new platform fallback mechanism and firmware_request_platform() Date: Sun, 12 Jan 2020 14:54:04 -0800 Message-ID: References: <20200111145703.533809-1-hdegoede@redhat.com> <20200111145703.533809-5-hdegoede@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20200111145703.533809-5-hdegoede@redhat.com> Sender: linux-doc-owner@vger.kernel.org To: Hans de Goede Cc: Ard Biesheuvel , Darren Hart , Andy Shevchenko , Luis Chamberlain , Greg Kroah-Hartman , "Rafael J . Wysocki" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Jonathan Corbet , Dmitry Torokhov , Peter Jones , Dave Olsthoorn , X86 ML , Platform Driver , linux-efi , LKML , "open list:DOCUMENTATION" "open list:HID CORE LAYER"
  • List-Id: platform-driver-x86.vger.kernel.org On Sat, Jan 11, 2020 at 6:57 AM Hans de Goede wrote: > > In some cases the platform's main firmware (e.g. the UEFI fw) may contain > an embedded copy of device 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 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. After finally wrapping my head around how this all fits together: Early in boot, you check a bunch of firmware descriptors, bundled with drivers, to search EFI code and data for firmware before you free said code and data. You catalogue it by name. Later on, you use this list as a fallback, again catalogued by name. I think it would be rather nicer if you simply had a list in a single file containing all these descriptors rather than commingling it with the driver's internal dmi data. This gets rid of all the ifdeffery and module issues. It also avoids any potential nastiness when you have a dmi entry that contains driver_data that points into the driver when the driver is a module. And you can mark the entire list __initdata. And you can easily (now or later on) invert the code flow so you map each EFI region exactly once and then search for all the firmware in it. --Andy