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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 10A5CC35669 for ; Fri, 21 Feb 2020 23:38:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D9C6E20722 for ; Fri, 21 Feb 2020 23:38:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="BTbJ9DV5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729414AbgBUXhx (ORCPT ); Fri, 21 Feb 2020 18:37:53 -0500 Received: from mail-pg1-f196.google.com ([209.85.215.196]:36213 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729173AbgBUXhx (ORCPT ); Fri, 21 Feb 2020 18:37:53 -0500 Received: by mail-pg1-f196.google.com with SMTP id d9so1786452pgu.3 for ; Fri, 21 Feb 2020 15:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=U8GTXDQYqxVMWeiE3CeM22iOXjrDkwUgtcNqh51keqY=; b=BTbJ9DV5UnhS6c59epTpH7XTEnU2oooXg+g6bAhjUyVbujp1zj/9TaRU8cj0TPZwd3 CG8U0vdI5gFnoJTHTJLwe669yrJzuJv13qa3AVL8dmiMh5v19I5goaubVFzUpLjj3wTs 7lQz+6WG62x4T5Z+CFsJPY2Ds6kbuZLZW2JXM= 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-transfer-encoding :content-language; bh=U8GTXDQYqxVMWeiE3CeM22iOXjrDkwUgtcNqh51keqY=; b=lgo2c6gTaq6U8G35zlHmfkgIwETDVUVU8OAc4XrQKLWsBb8Dr4ZFTou0+pHX8/PKsc PasvD4RARIT/7uhumLfTZReqqf99Cmjp3m8jqnOobUDZwEpNnPqQWkQzyTT4svqYzLvI 0dtz9KI7pBSQAlzrucm98qDAMKQxsMNlnZ5N2mZUIgRAC5tNTWoDS8LjTVkMwzkQSYUp uUE0trF6TAPStfATvQjg/WEODykorUYId6O1kx6DusNznNVfTydOjAHawOrMDj7z3BKt 0P7SFSERSDkzqVLAiANg2OwE6UFkgleh6nFa3DagotqJU4DjKcuCAtcNXO+1zW4oM6nM l34w== X-Gm-Message-State: APjAAAWkYXCDFenqvsfBI+U86+u398VOPqTuA40bSuDERe12E0iBJuu0 MiBDSbsQfPmu7G07ZnrCYiP2dQ== X-Google-Smtp-Source: APXvYqzSKwENjp8Zc5/+UeGf1chfHFs+nHCsMZqHL9BYW/wJmsDWoBM6WNV9QMdjdezOfrljgme5xQ== X-Received: by 2002:a63:3c08:: with SMTP id j8mr40832260pga.223.1582328272147; Fri, 21 Feb 2020 15:37:52 -0800 (PST) Received: from [10.136.13.65] ([192.19.228.250]) by smtp.gmail.com with ESMTPSA id u23sm3891110pfm.29.2020.02.21.15.37.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Feb 2020 15:37:51 -0800 (PST) Subject: Re: [PATCH 2/7] firmware: add offset to request_firmware_into_buf To: Arnd Bergmann Cc: Luis Chamberlain , Takashi Iwai , Greg Kroah-Hartman , David Brown , Alexander Viro , Shuah Khan , Bjorn Andersson , Shuah Khan , "Rafael J . Wysocki" , "linux-kernel@vger.kernel.org" , linux-arm-msm , Linux FS-devel Mailing List , BCM Kernel Feedback , Olof Johansson , Andrew Morton , Dan Carpenter , Colin Ian King , Kees Cook , "open list:KERNEL SELFTEST FRAMEWORK" 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> <20191011133120.GP16384@42.do-not-panic.com> From: Scott Branden Message-ID: <3731a882-8784-b957-7628-49edfa9683e7@broadcom.com> Date: Fri, 21 Feb 2020 15:37:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi Arnd, On 2020-02-21 12:44 a.m., Arnd Bergmann wrote: > On Fri, Feb 21, 2020 at 1:11 AM Scott Branden > wrote: >> On 2019-10-11 6:31 a.m., Luis Chamberlain wrote: >>> On Tue, Aug 27, 2019 at 12:40:02PM +0200, Takashi Iwai wrote: >>>> On Mon, 26 Aug 2019 19:24:22 +0200, >>>> Scott Branden wrote: >>>>> 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? >>> Poke Scott. >> Yes, this is exclusive to x86. >> In particular, 64-bit x86 server class machines with PCIe gen3 support. >> There is no reason for these PCIe boards to run in other lower end >> machines or architectures. > It doesn't really matter that much what you expect your customers to > do with your product, or what works a particular machine today, drivers > should generally be written in a portable manner anyway and use > the documented APIs. memcpy() into an __iomem pointer is not > portable and while it probably works on any x86 machine today, please > just don't do it. If you use 'sparse' to check your code, that would normally > result in an address space warning, unless you add __force and a > long comment explaining why you cannot just use memcpy_to_io() > instead. At that point, you are already better off usingn memcpy_to_io() ;-) > > Arnd I am a not performing a memcpy at all right now. I am calling a request_firmware_into_buf call and do not need to make a copy. This function eventually calls kernel_read_file, which then makes at indirect call in __vfs_read to perform the read to memory. From there I am lost as to what operation happens to achieve this. The read function would need to detect the buf is in io space and perform the necessary operation. Anyone with any knowledge on how to make this read to io space would be appreciated? ssize_t __vfs_read(struct file *file, char __user *buf, size_t count,            loff_t *pos) {     if (file->f_op->read)         return file->f_op->read(file, buf, count, pos);     else if (file->f_op->read_iter)         return new_sync_read(file, buf, count, pos);     else         return -EINVAL; } ssize_t kernel_read(struct file *file, void *buf, size_t count, loff_t *pos) {     mm_segment_t old_fs;     ssize_t result;     old_fs = get_fs();     set_fs(KERNEL_DS);     /* The cast to a user pointer is valid due to the set_fs() */     result = vfs_read(file, (void __user *)buf, count, pos);     set_fs(old_fs);     return result; }