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=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 6E8C8C433DB for ; Fri, 8 Jan 2021 09:21:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32AF8233EA for ; Fri, 8 Jan 2021 09:21:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728105AbhAHJVK (ORCPT ); Fri, 8 Jan 2021 04:21:10 -0500 Received: from mail.kernel.org ([198.145.29.99]:49738 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727478AbhAHJVJ (ORCPT ); Fri, 8 Jan 2021 04:21:09 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 19BF323372; Fri, 8 Jan 2021 09:20:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610097628; bh=oiPKPwrLUTXmyxEg4htGUPgFpzc+ZSlNsGuIlmxZcHA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FmG54POPm2c2tiKdpWlDe940ivqmckLWEjMutD1Z9iWCYSH1oOGMajQcbIW3dJMec n9TFS+6rhKwqcvHge4pnOswKtWes6MxZUvil9oNN4hUhJyuCaofAqFpYXsdRw5Bjfy a7lkb0cRHVP+PxTQy62P2GE/d3k7oCBGoOFbXSRdjbzX9YcRRTZmhsLY/fdzw+pDMP HBtNNxb3lQEYayOFbkI7wAPEOuggq7xk3P2nSlM+c+P5n17w90rX9o5JJIUN8FE/KZ pzVGRvRLjOM4zY99FjwjvuyGp9rX8XwxhtEZmg3e5gL4IaT+QS0ONb9h/CXJOyxfo7 cUblV5M4jCQoQ== Received: from johan by xi.lan with local (Exim 4.93.0.4) (envelope-from ) id 1kxnwd-00019U-DK; Fri, 08 Jan 2021 10:20:31 +0100 Date: Fri, 8 Jan 2021 10:20:31 +0100 From: Johan Hovold To: Anant Thazhemadam Cc: Johan Hovold , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 05/15] usb: misc: emi26: update to use usb_control_msg_send() Message-ID: References: <20201130011819.2576481-1-anant.thazhemadam@gmail.com> <20201130012847.2579463-1-anant.thazhemadam@gmail.com> <6806f8e4-c2f7-3c6a-b855-3f87ab8d9e22@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6806f8e4-c2f7-3c6a-b855-3f87ab8d9e22@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 07, 2021 at 07:43:54PM +0530, Anant Thazhemadam wrote: > On 04/12/20 8:11 pm, Johan Hovold wrote: > > On Mon, Nov 30, 2020 at 06:58:47AM +0530, Anant Thazhemadam wrote: > >> The newer usb_control_msg_{send|recv}() API are an improvement on the > >> existing usb_control_msg() as it ensures that a short read/write is treated > >> as an error, > > Short writes have always been treated as an error. The new send helper > > only changes the return value from the transfer size to 0. > > > > And this driver never reads. > > > > Try to describe the motivation for changing this driver which is to > > avoid the explicit kmemdup(). > >> /* thanks to drivers/usb/serial/keyspan_pda.c code */ > >> @@ -77,11 +67,7 @@ static int emi26_load_firmware (struct usb_device *dev) > >> int err = -ENOMEM; > >> int i; > >> __u32 addr; /* Address to write */ > >> - __u8 *buf; > >> - > >> - buf = kmalloc(FW_LOAD_SIZE, GFP_KERNEL); > >> - if (!buf) > >> - goto wraperr; > >> + __u8 buf[FW_LOAD_SIZE]; > > As the build bots reported, you must not put large structures like this > > on the stack. > > Understood.  > But I'm considering dropping this change (and the one proposed for > emi62) altogether in v3 - since these would end up requiring memory to > dynamically allocated twice for the same purpose. However, if you > still think the pros of updating this (and emi62) outweigh the cons, > please let me know, and I'll make sure to send in another version > fixing it. The redundant memdup() is already there for the firmware buffer and changing to usb_control_msg_send() will only make it slightly harder to get rid of that, if anyone would bother. But yeah, it's probably not worth switching usb_control_msg_send() for these drivers. Johan