linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Darren Hart <dvhart@infradead.org>,
	Andy Shevchenko <andy@infradead.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>, Peter Jones <pjones@redhat.com>,
	Dave Olsthoorn <dave@bewaar.me>,
	x86@kernel.org, platform-driver-x86@vger.kernel.org,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-input@vger.kernel.org
Subject: Re: [PATCH v7 4/8] firmware: Add new platform fallback mechanism and firmware_request_platform()
Date: Fri, 11 Oct 2019 15:31:22 +0000	[thread overview]
Message-ID: <20191011153122.GR16384@42.do-not-panic.com> (raw)
In-Reply-To: <20191004231733.GF22365@dtor-ws>

On Fri, Oct 04, 2019 at 04:17:33PM -0700, Dmitry Torokhov wrote:
> Hi Hans,
> 
> On Fri, Oct 04, 2019 at 04:50:52PM +0200, 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.
> 
> Why would drivers not want to fetch firmware from system firmware if it
> is not present on disk? I would say let driver to opt-out of this
> fallback, but default request_firmware() should do it by default.

It is the otherw way around, this looks first for the file on disk, and
if not present it looks for the firmware sprinked on EFI firmware, if
the driver was expected this fallback option for the device.

  Luis

  parent reply	other threads:[~2019-10-11 15:31 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04 14:50 [PATCH v7 0/8] efi/firmware/platform-x86: Add EFI embedded fw support Hans de Goede
2019-10-04 14:50 ` [PATCH v7 1/8] efi: Export boot-services code and data as debugfs-blobs Hans de Goede
2019-10-09 13:07   ` Ard Biesheuvel
2019-10-09 13:18     ` Hans de Goede
2019-10-09 13:35       ` Ard Biesheuvel
2019-10-09 13:59         ` Hans de Goede
2019-10-09 14:01           ` Ard Biesheuvel
2019-10-14  9:11   ` Luis Chamberlain
2019-11-14 11:31     ` Hans de Goede
2019-10-04 14:50 ` [PATCH v7 2/8] efi: Add embedded peripheral firmware support Hans de Goede
2019-10-11 14:48   ` Luis Chamberlain
2019-11-14 11:27     ` Hans de Goede
2019-11-14 19:42       ` Luis Chamberlain
2019-11-14 20:13         ` Hans de Goede
2019-11-14 20:48           ` Hans de Goede
2019-11-14 21:50             ` Luis Chamberlain
2019-11-15 12:09               ` Hans de Goede
2019-10-04 14:50 ` [PATCH v7 3/8] firmware: Rename FW_OPT_NOFALLBACK to FW_OPT_NOFALLBACK_SYSFS Hans de Goede
2019-10-11 15:02   ` Luis Chamberlain
2019-11-14 20:22     ` Hans de Goede
2019-10-04 14:50 ` [PATCH v7 4/8] firmware: Add new platform fallback mechanism and firmware_request_platform() Hans de Goede
2019-10-04 19:33   ` kbuild test robot
2019-10-04 20:45   ` kbuild test robot
2019-10-04 23:17   ` Dmitry Torokhov
2019-10-05  9:53     ` Hans de Goede
2019-10-11 15:31     ` Luis Chamberlain [this message]
2019-10-11 15:29   ` Luis Chamberlain
2019-11-14 11:32     ` Hans de Goede
2019-10-04 14:50 ` [PATCH v7 5/8] Input: silead - Switch to firmware_request_platform for retreiving the fw Hans de Goede
2019-10-11  0:47   ` Dmitry Torokhov
2019-10-04 14:50 ` [PATCH v7 6/8] Input: icn8505 " Hans de Goede
2019-10-11  0:47   ` Dmitry Torokhov
2019-10-04 14:50 ` [PATCH v7 7/8] platform/x86: touchscreen_dmi: Add EFI embedded firmware info support Hans de Goede
2019-10-05  3:03   ` kbuild test robot
2019-10-05  7:13   ` kbuild test robot
2019-10-04 14:50 ` [PATCH v7 8/8] platform/x86: touchscreen_dmi: Add info for the Chuwi Vi8 Plus tablet Hans de Goede
2019-10-07 14:19 ` [PATCH v7 0/8] efi/firmware/platform-x86: Add EFI embedded fw support Ingo Molnar
2019-10-08  9:35   ` Hans de Goede
2019-10-08 11:05     ` Ingo Molnar
2019-10-11 14:10 ` Luis Chamberlain
2019-10-11 14:31   ` Hans de Goede
2019-10-11 15:38     ` Luis Chamberlain
2019-10-11 16:38       ` Greg Kroah-Hartman
2019-10-14  9:22         ` Luis Chamberlain
2019-10-14  9:29           ` Greg Kroah-Hartman
2019-10-14 10:31             ` Luis Chamberlain
2019-10-14 10:57               ` Greg Kroah-Hartman
2019-10-16 12:45                 ` Luis Chamberlain

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=20191011153122.GR16384@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=andy@infradead.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave@bewaar.me \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pjones@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).