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 4D5A4C3A5A1 for ; Thu, 22 Aug 2019 23:30:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 124182173E for ; Thu, 22 Aug 2019 23:30:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=broadcom.com header.i=@broadcom.com header.b="hMnkoT5t" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726364AbfHVXam (ORCPT ); Thu, 22 Aug 2019 19:30:42 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:39032 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726347AbfHVXal (ORCPT ); Thu, 22 Aug 2019 19:30:41 -0400 Received: by mail-pf1-f193.google.com with SMTP id f17so5021604pfn.6 for ; Thu, 22 Aug 2019 16:30:41 -0700 (PDT) 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=pipHIj2z8t6n6jqMVgjlsl2tSXUd+7sKmIuVqD9kPY4=; b=hMnkoT5tbbKTZsnL0o1jbPhA9Rz8Qwpwy4McYBokvjjLVHvSW4wOMynuN5oMcP122a 7WuQfzvAX0353Q+FkxsoKOMI95qLc2yuaJ1UYcq6w9RXgM4ouNA07MzId4svJ02rAvrs ZYfoOc+wEVTW6rnnvuG4FkOXzoQ9sH0pA1diY= 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=pipHIj2z8t6n6jqMVgjlsl2tSXUd+7sKmIuVqD9kPY4=; b=c43wTOI+egKZc4FBhnHfI2kAlZUYUGPVYlhcGTkn/sJWrmE0myjrGnNAEJ3vRv525R Mfa7he9/ndUxSbFPmZMKpuO5aK4sX74xoT1UpShP3OZE82j2Tq1WCGVMvr/OoSU7Ifvs xE0zkZ3jG97T4PIwnjHK7vwwq2YaJwLADvYyBYpQu7T4PGvWOlD9TnoZnlqMSRi6y72d kkWmBm+iqpCt32lc1XVz0pO5G2x3F1sSUENQSjr1ilVo9OeJqEzVcoZdaYRsrpbB3jaC eyGfgZIWgLLKsV25TBNURBxnBK8QLcN1Ew9KgH+fwdtWMfuCFynxDbP/I1MlOcLjMyrB lImg== X-Gm-Message-State: APjAAAXdGSYqh9gk1L7CB5AWG0OL4M59Wqzm66fY6pwnn5NhJU1TPXGw cMlboJ/Vn9Ruy5fsn144UyAGAw== X-Google-Smtp-Source: APXvYqzKrKT+k/MJjU1tTcW0RKdJpKgeuPCz/JwywMw0aLkN5Y6KHgx4CNyQzDQLoks+nrLfaVWIWQ== X-Received: by 2002:a17:90a:234f:: with SMTP id f73mr2274285pje.130.1566516640592; Thu, 22 Aug 2019 16:30:40 -0700 (PDT) Received: from [10.136.13.65] ([192.19.228.250]) by smtp.gmail.com with ESMTPSA id c12sm526175pfc.22.2019.08.22.16.30.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Aug 2019 16:30:40 -0700 (PDT) Subject: Re: [PATCH 2/7] firmware: add offset to request_firmware_into_buf To: Luis Chamberlain Cc: 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 , Takashi Iwai , linux-kselftest@vger.kernel.org References: <20190822192451.5983-1-scott.branden@broadcom.com> <20190822192451.5983-3-scott.branden@broadcom.com> <20190822194712.GG16384@42.do-not-panic.com> <7ee02971-e177-af05-28e0-90575ebe12e0@broadcom.com> <20190822211220.GR16384@42.do-not-panic.com> From: Scott Branden Message-ID: <009295ce-bdc5-61d8-b450-5fcdae041922@broadcom.com> Date: Thu, 22 Aug 2019 16:30:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190822211220.GR16384@42.do-not-panic.com> 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 Luis, On 2019-08-22 2:12 p.m., Luis Chamberlain wrote: > On Thu, Aug 22, 2019 at 01:07:41PM -0700, Scott Branden wrote: >> On 2019-08-22 12:47 p.m., Luis Chamberlain wrote: >>> This implies you having to change the other callers, and while currently >>> our list of drivers is small, >> Yes, the list is small, very small. >> >> There is a single driver making a call to the existing API. >> >> And, the maintainer of that driver wanted >> to start utilizing my enhanced API instead of the current API. > You mean in the near term future? Your change makes it use the full file. > Just checking. The change in the patch keeps the existing functionality in the qcom mdt_loader by reading the full file using the enhanced api. I don't know when Bjorn will switch to use the partial firmware load: https://lkml.org/lkml/2019/5/27/9 > >> As such I think it is very reasonable to update the API right now. > I'd prefer to see it separate, and we fix the race *before* we introduce > the new functionality. I'll be poking at that shortly but I should note > that I leave on vacation this weekend and won't be back for a good while. > I already have an idea of how to approach this. > > When the current user want to use the new API it can do so, and then we > just kill the older caller. We can kill the older api right now as my patch in qcom mdt_loader calls the new API which allows reading of full or partial files? > >>> following the history of the firmware API >>> and the long history of debate of *how* we should evolve its API, its >>> preferred we add yet another new caller for this functionality. So >>> please add a new caller, and use EXPORT_SYMBOL_GPL(). >>> >>> And while at it, pleaase use firmware_request_*() as the prefix, as we >>> have want to use that as the instilled prefix. We have yet to complete >>> the rename of the others older callers but its just a matter of time. >>> >>> So something like: firmware_request_into_buf_offset() >> I would prefer to rename the API at this time given there is only a single >> user. >> >> Otherwise I would need to duplicate quite a bit in the test code to support >> testing the single user of the old api and then enhanced API. >> Or, I can leave existing API in place and change the test case to >> just test the enhanced API to keep things simpler in the test code? > If the new user is going to move to the API once available I will be > happy to then leave out testing for the older API. That would make > sense. I have switched the single user of the existing api to the new API in the patch already?  And both full and partial reads using the new API are tested with this patch series.  If you really insist on keeping the old API for a single user I can drop that change from the patch series and have the old request_firmware_api call simply be a wrapper calling the new API. > > But if you do want to keep testing for the old API, and allow an easy > removal for it on the test driver, wouldn't a function pointer suffice > for which API call to use based on a boolean? > > But yeah if we're going to abandon the old mechanism I'm happy to skip > its te We can skip right now then.  As enhanced API is a superset of old API. If you want the old API left in place I can just add the wrapper described and only test the newly named function and thus indirectly test the old request_firmware_into_buf. > sting. > > Luis