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;
Date:   Tue, 27 Aug 2019 12:40:02 +0200
Message-ID: <s5hwoeyj3i5.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     Scott Branden <scott.branden@broadcom.com>
Cc:     Luis Chamberlain <mcgrof@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        David Brown <david.brown@linaro.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Shuah Khan <shuah@kernel.org>, bjorn.andersson@linaro.org,
        Shuah Khan <skhan@linuxfoundation.org>,
        Arnd Bergmann <arnd@arndb.de>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        linux-fsdevel@vger.kernel.org,
        BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
        Olof Johansson <olof@lixom.net>,
        Andrew Morton <akpm@linux-foundation.org>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Colin Ian King <colin.king@canonical.com>,
        Kees Cook <keescook@chromium.org>,
        linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 2/7] firmware: add offset to request_firmware_into_buf
In-Reply-To: <b440f372-45be-c06c-94a1-44ae6b1e7eb8@broadcom.com>
References: <20190822192451.5983-1-scott.branden@broadcom.com>
        <20190822192451.5983-3-scott.branden@broadcom.com>
        <s5hef1crybq.wl-tiwai@suse.de>
        <10461fcf-9eca-32b6-0f9d-23c63b3f3442@broadcom.com>
        <s5hr258j6ln.wl-tiwai@suse.de>
        <93b8285a-e5eb-d4a4-545d-426bbbeb8008@broadcom.com>
        <s5ho90byhnv.wl-tiwai@suse.de>
        <b440f372-45be-c06c-94a1-44ae6b1e7eb8@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

On Mon, 26 Aug 2019 19:24:22 +0200,
Scott Branden wrote:
> 
> Hi Takashi,
> 
> On 2019-08-26 10:12 a.m., Takashi Iwai wrote:
> > 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()...
> Yes, we access the PCI region directly in the driver and thus also
> through request_firmware_into_buf.

Then you really need to access via the standard APIs for iomem.
The normal memory copy would work only on some architectures like
x86.

> I will admit I am not familiar with every subtlety of PCI
> accesses. Any comments to the Valkyrie driver in this patch series are
> appreciated.
> But not all drivers need to work on all architectures. I can add a
> depends on x86 64bit architectures to the driver to limit it to such.

But it's an individual board on PCIe, and should work no matter which
architecture is?  Or is this really exclusive to x86?


thanks,

Takashi