Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4605773ybl; Mon, 26 Aug 2019 12:59:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqw1S42qQ19+Yfi+SmFC6rQVF/t/XagZo+/bOq8MDIgHxBWZOvzYSNbI1JcVCJLwYpoWcGwM X-Received: by 2002:a65:6713:: with SMTP id u19mr16873815pgf.403.1566849551925; Mon, 26 Aug 2019 12:59:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566849551; cv=none; d=google.com; s=arc-20160816; b=0byfGwcDmLfNCdnJddmEk0b65ezzcMxyQIQBvZdbNUAMWn8vpjPJmf3H7BVCBa/Vjg 0PFcyjzYyng3CBucF9GWL9phpCpVwl4dSf2bMBaUVf6cnOewMx2P+I3gJHLzDskNywY7 HxrsGSPpvRKUk198WD9g1ruOTVn1eQ/R6tFXToHlwa/uaO8qHkOgk3lWhq7IuQvUcamG ueHY0BF4xtLAnbJmrQIkdqLwrV3p+IJHm4xm9sgfVXZy8lNnUjxVaBdN9jyFo/QYH8HL 7jgU9+42sOPyTePiXek9zoB7AWgRwx4QCuTTZuY0RvVHhUW7qaYXPZ5nhXjo/PmaUInH 2TTg== 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:mime-version :user-agent:references:in-reply-to:subject:cc:to:from:message-id :date; bh=DAHupnOmu14RdhYGmp1AVjiRtub4jorOC90Qd2cc2mA=; b=ZBwNPHTBFwIcgtjLdNn6xoK4GwK9rHK6mJFBGIhiN821ArDzlgKpUVuBdh+beNDAOG Xtg93fKF/SxOgN8xH5rXCYQjTJhQjgg9MJ6CHWB0iO7HEymN5qibqgPdvsiZR+e4boH2 kUWa8Gq0Hh+SQ3/iUi9MdUiqZTgVV1jKKh3+1D7g8orj3haK0H7iq63ewnU2wsHMUeRE AacMYSvh9TzX6pB8N56JcBg3qbjstaAZEtMcd5kc+m2AS61aEKe4XHGjydSBz2GlMQ+g 4xo97ALSErYNqKQOLRZZp7/qCTAp8oH4iyzRdpUFbvNgCgfKkGxw1pBNN4ye3npPJwhu w7aw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l28si9656712pgm.311.2019.08.26.12.58.44; Mon, 26 Aug 2019 12:59:11 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732670AbfHZRMz (ORCPT + 99 others); Mon, 26 Aug 2019 13:12:55 -0400 Received: from mx2.suse.de ([195.135.220.15]:47908 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727815AbfHZRMy (ORCPT ); Mon, 26 Aug 2019 13:12:54 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7DBDEB633; Mon, 26 Aug 2019 17:12:52 +0000 (UTC) Date: Mon, 26 Aug 2019 19:12:52 +0200 Message-ID: From: Takashi Iwai To: Scott Branden Cc: Luis Chamberlain , Greg Kroah-Hartman , David Brown , Alexander Viro , Shuah Khan , bjorn.andersson@linaro.org, Shuah Khan , Arnd Bergmann , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-fsdevel@vger.kernel.org, BCM Kernel Feedback , Olof Johansson , Andrew Morton , Dan Carpenter , Colin Ian King , Kees Cook , linux-kselftest@vger.kernel.org Subject: Re: [PATCH 2/7] firmware: add offset to request_firmware_into_buf In-Reply-To: <93b8285a-e5eb-d4a4-545d-426bbbeb8008@broadcom.com> References: <20190822192451.5983-1-scott.branden@broadcom.com> <20190822192451.5983-3-scott.branden@broadcom.com> <10461fcf-9eca-32b6-0f9d-23c63b3f3442@broadcom.com> <93b8285a-e5eb-d4a4-545d-426bbbeb8008@broadcom.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 26 Aug 2019 17:41:40 +0200, Scott Branden wrote: > > HI Takashi, > > On 2019-08-26 8:20 a.m., Takashi Iwai wrote: > > On Fri, 23 Aug 2019 21:44:42 +0200, > > Scott Branden wrote: > >> Hi Takashi, > >> > >> Thanks for review.  comments below. > >> > >> On 2019-08-23 3:05 a.m., Takashi Iwai wrote: > >>> On Thu, 22 Aug 2019 21:24:46 +0200, > >>> Scott Branden wrote: > >>>> Add offset to request_firmware_into_buf to allow for portions > >>>> of firmware file to be read into a buffer. Necessary where firmware > >>>> needs to be loaded in portions from file in memory constrained systems. > >>> AFAIU, this won't work with the fallback user helper, right? > >> Seems to work fine in the fw_run_tests.sh with fallbacks. > > But how? You patch doesn't change anything about the fallback loading > > mechanism. > Correct - I didn't change any of the underlying mechanisms, > so however request_firmware_into_buf worked before it still does. > > Or, if the expected behavior is to load the whole content > > and then copy a part, what's the merit of this API? > The merit of the API is that the entire file is not copied into a buffer. > In my use case, the buffer is a memory region in PCIe space that isn't > even large enough for the whole file.  So the only way to get the file > is to read it > in portions. BTW: does the use case above mean that the firmware API directly writes onto the given PCI iomem region? If so, I'm not sure whether it would work as expected on all architectures. There must be a reason of the presence of iomem-related API like memcpy_toio()... thanks, Takashi