Received: by 10.192.165.156 with SMTP id m28csp1596341imm; Tue, 17 Apr 2018 02:00:16 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/B5vR/aPTutaHgF2ok2eDJKbDpTM/47mxDOu9sJ7A7UD0l2Q98mZiTp8bvkBfWASBjNbkR X-Received: by 10.99.188.9 with SMTP id q9mr1072818pge.381.1523955616931; Tue, 17 Apr 2018 02:00:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523955616; cv=none; d=google.com; s=arc-20160816; b=clMURPsS8KRvA2lwEu2xt4brruvf/gF0Cb4LUf5blDkQnV5JyQDu6yz9+6m95j2wZp IM9PhPZZ6UHQsWOPNyoT1m3jz1qUBDqD0nSe98WPgunzepUa1pqJzOJkRBkHluvdAV3k EZJqoHnInIuVAD4IAN3IQmetsG1feSQoSsXEzLFFTaVTF+be4twCjLCaZsyg1CYKSbhR oS0wuOpvhaECDl+J/WPeDEGOxoMh0uT+PQYkB+z5xAUMJVuv1P1a7W24Q3HB/DKFnAi5 l0Met8ZGdhg8yTztVyHogury/YTUoDWVdo22KV8OSjfdvSGdmaoIzHtHgWmZoKdnBygH NpTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=v63NvxHfZaQJZcSUERyR1c7CoXnxodhR6CDtJOjXKXw=; b=O6UC2P1iYEQoJWzeMVgjyXOYnZC8iTd/UoevLW6f+lGK/17in9/zm6qBJsJJG+seEp Fk7G56DkyyLjk0GJiykdydAXvtgKk+7ZdS5/lAHo2EiBhwMA8CBWZttvCu6xpCufnHTa dVH/j4EMa1dJ4U3mrZ1DH3ZmI5aCzhXu2K0GE+j00XX7rtEMz0J2nrquhXzK1Y5ln6XY p+BcPabNrKToBqiqV0jurBgkfXrwjYu2tVfct8x7sgesRoV190JDhVG8NzuGC4TMPXuA nFS4oEYeoALzem48gWXLykCAXHoa7fNJibAlemCS/9KtsoihLtUQGmAgbenbiUWvhNXa U8Cg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g9si5870071pgc.318.2018.04.17.02.00.02; Tue, 17 Apr 2018 02:00:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752082AbeDQI6p (ORCPT + 99 others); Tue, 17 Apr 2018 04:58:45 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:46000 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbeDQI6n (ORCPT ); Tue, 17 Apr 2018 04:58:43 -0400 Received: by mail-wr0-f196.google.com with SMTP id u11so33227314wri.12 for ; Tue, 17 Apr 2018 01:58:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v63NvxHfZaQJZcSUERyR1c7CoXnxodhR6CDtJOjXKXw=; b=Oc4W2KROwov2m24XimaIsOE65bayMpKmhWWdx3rJYPhd8ngRzXzhEFx5/5u5g2uCki KoKF2LS8jHYPpI9LkiQJIZrTzc/4PeVq+k49R2NZk0Uw4EF60VCkZc0RdD1lnwuhWenH Gtu6qpo3knnV7lNkD8WYZbrrncqluLoEJ0R18192djrDwyNNs/gV99+ngpF8H5JDRUXr mardMu+Qt5Yx7MxRwOmM83id4Y8QKNwSsHwrYYkKCOdt+k3OCV7VoE2hYCzONx5MNuBg 9nkWfEMUATmG3rCv+9Ivg3yYWp8WT9dNm8zfIK3B5uqZFYgBraCQVEkiUyPXl663RXwe AN9w== X-Gm-Message-State: ALQs6tCe8onz2nQqUfJOYAQuHbgo6sLFZdU5me5c0UiwEmM+18Qmd6Mi ojmZe4Np1PPQtHT32U5xuuO/Kw== X-Received: by 10.80.179.45 with SMTP id q42mr2036848edd.264.1523955521884; Tue, 17 Apr 2018 01:58:41 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id c5sm3996105ede.63.2018.04.17.01.58.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 01:58:41 -0700 (PDT) Subject: Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support To: "Luis R. Rodriguez" , Andres Rodriguez , Dmitry Torokhov Cc: Darren Hart , Andy Shevchenko , Ard Biesheuvel , Greg Kroah-Hartman , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Jones , Dave Olsthoorn , Will Deacon , Andy Lutomirski , Matt Fleming , David Howells , Mimi Zohar , Josh Triplett , dmitry.torokhov@gmail.com, mfuzzey@parkeon.com, keescook@chromium.org, Kalle Valo , Arend Van Spriel , Linus Torvalds , nbroeking@me.com, bjorn.andersson@linaro.org, Torsten Duwe , x86@kernel.org, linux-efi@vger.kernel.org References: <20180408174014.21908-1-hdegoede@redhat.com> <20180408174014.21908-3-hdegoede@redhat.com> <20180417001738.GN30543@wotan.suse.de> From: Hans de Goede Message-ID: Date: Tue, 17 Apr 2018 10:58:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180417001738.GN30543@wotan.suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 17-04-18 02:17, Luis R. Rodriguez wrote: > On Sun, Apr 08, 2018 at 07:40:11PM +0200, Hans de Goede wrote: >> static void firmware_free_data(const struct firmware *fw) >> { >> @@ -576,6 +600,15 @@ _request_firmware(const struct firmware **firmware_p, const char *name, >> goto out; >> >> ret = fw_get_filesystem_firmware(device, fw->priv); >> +#ifdef CONFIG_EFI_EMBEDDED_FIRMWARE >> + if (ret && device && >> + device_property_read_bool(device, "efi-embedded-firmware")) { >> + ret = fw_get_efi_embedded_fw(device, fw->priv, ret); >> + if (ret == 0) >> + ret = assign_fw(fw, device, opt_flags | FW_OPT_NOCACHE); >> + goto out; >> + } >> +#endif > > You mussed what I asked for in terms of adding a new flag, (please work on top > of Andre's patches as those likely will be merged first, and also have kdocs > for the flags) Ok I will base my next version on top of Andres' series. > and then a new firmware API to wrap the above into a function > which would only do something if the driver *asked* for it on their firmware > API call. > Ie, please add a new firmware_request_efi_fw(). As I tried to explain in the changelog the problem with doing this, is that this makes it a driver decision, where it really needs to be platform-code driven, not driver driven. Take for example the drivers/input/touchscreen/silead.c code that is used on a lot of 32 bit ARM platforms too, which don't have EFI at all, so if that needs to call request_firmware_efi() then should I add: #ifdef CONFIG_X86 fw = request_firmware_efi(...); #else fw = request_firmware(...); #endif ? But even on x86 only some devices with a silead touchscreen have EFI embedded firmware, so then I would need something like: #ifdef CONFIG_X86 if (device_property_get_bool(dev, "some-prop-name")) fw = request_firmware_efi(...); else #else fw = request_firmware(...); #endif That is assuming I still want the normal fallback path in the case no EFI firmware is available, which I do because then something like packagekit may see if the firmware is packaged in one of the configured distro repositories. We already have (x86) platform code in place to attach properties (like a board specific firmware filename) to the device using device-properties so that drivers like silead.c don't get filled / polluted with board/platform specific knowledge, which IMHO is the place where the knowledge fallback to an EFI embedded firmware copy belongs. As the further patches in v3 of this series shows, this actually works quite nicely, because this also allows bundling the EFI-embedded firmware info (prefix, length, crc, name) together with the other board specific properties. TL;DR: using request_firmware_efi() vs request_firmware() is a driver decision, but whether EFI firmware fallback should be is board/platform specific not driver specific, therefor I believe that using a device-property to signal this is better. If you insist on me adding a request_firmware_efi() I can give this a shot, but I know that Dmitry (the input maintainer) will very much dislike the silead.c changes that implies... Still a question for lets sat we go that route, what do we then do with request_firmware_efi() when CONFIG_EFI is not set ? Should it be defined then or not, and if it should be defined when CONFIG_EFI is not set what should it do then? > Also if you see the > work I've done to remove the ifdefs over fallback mechanism you'll see it helps > split code and make it easier to read. We should strive to not add any more > ifdefery and instead make tehis code read easily. So looking at how the CONFIG_FW_LOADER_USER_HELPER stuff deals with this, I should: 1) Move the definition of fw_get_efi_embedded_fw() to a new drivers/base/firmware_loader/fallback_efi.c, which only gets build if CONFIG_EFI_EMBEDDED_FIRMWARE is set 2) Put the following in fallback.h: #ifdef CONFIG_EFI_EMBEDDED_FIRMWARE int fw_get_efi_embedded_fw(struct device *dev, struct fw_priv *fw_priv, int ret); #else static inline int fw_get_efi_embedded_fw(struct device *dev, struct fw_priv *fw_priv, int ret) { return ret; } #endif have I got that right? Regards, Hans