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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8BA8C43334 for ; Tue, 7 Jun 2022 10:18:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240784AbiFGKSW (ORCPT ); Tue, 7 Jun 2022 06:18:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51632 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240840AbiFGKSV (ORCPT ); Tue, 7 Jun 2022 06:18:21 -0400 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D3B99A5AB8; Tue, 7 Jun 2022 03:18:19 -0700 (PDT) Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-31332df12a6so22245017b3.4; Tue, 07 Jun 2022 03:18:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wBzzjrW5juvtMxlABnBwXXEgrG6Shz7BoM3Ydn6iWhA=; b=MeMtQVL0KVK1hB9C8LvqNpZSfMLubwEXLJKZ5JRzvLnJK6+M94rPNTP419KGP3D+6H 5DunzGH4ba6UVXXlh+0p8DS9AIU8BhNydza8iPKTN5PcyWfvAzGFYqR0HHGDlgMMa5E2 w0TK1Ip55TQOoatOriaJsEodS8QXrzRytwW54HyHbhKAQ+o6zFLVL9rsmZUxVFkSAHip t5DPZ5tsr18MY8jIPBSOYRkxMboMCKEfwhVi3yjssy94xLvFxkpIKsczUbrPSmavT3fT QPiVND8dkck+1h2T+MNsAvm2ZPlvUmaevCRNK38nyhp8Fi0VlZrBjwE5vK/gBWvv/DGS jSRQ== X-Gm-Message-State: AOAM532DNN7Oqe31Zb5DPmJXdBP+sAr6BvnsgOr6YLq4Lmt2V017dtNd boo7TgcwEkxuJnSn94odPKTAzCxnsyJ3fpBQIvoETPVC1N2uZg== X-Google-Smtp-Source: ABdhPJwabTB68SgD2RHKpT9rlldr7Ana6c6z5pASJyhvX7TkJ3Houss4f+xvmVxYmfN4Pab+dnnionFkSFhb8beGLAY= X-Received: by 2002:a0d:ee47:0:b0:2ff:85e6:9e03 with SMTP id x68-20020a0dee47000000b002ff85e69e03mr30797967ywe.172.1654597099002; Tue, 07 Jun 2022 03:18:19 -0700 (PDT) MIME-Version: 1.0 References: <20220604144157.208849-1-mailhol.vincent@wanadoo.fr> <66b14321-667a-46a3-27db-cb8682bd5476@suse.com> In-Reply-To: <66b14321-667a-46a3-27db-cb8682bd5476@suse.com> From: Vincent MAILHOL Date: Tue, 7 Jun 2022 19:18:08 +0900 Message-ID: Subject: Re: [RFC PATCH] USB: core: urb: add new transfer flag URB_FREE_COHERENT To: Oliver Neukum Cc: Alan Stern , Rhett Aultman , Wolfgang Grandegger , Marc Kleine-Budde , Greg Kroah-Hartman , linux-can , linux-usb@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org On Tue. 7 Jun 2022 at 18:49, Oliver Neukum wrote: > On 05.06.22 15:45, Vincent MAILHOL wrote: > > > > This is how I see things: > > * In the open() function, the driver will do the coherent allocation > > for its transfer_buffers, fill those into URBs and add all the URBs in > > an anchor. > > * During runtime, the driver will keep recycling the same URBs (no > > need to kill URB nor to usb_free_coherent() the transfer_buffer). > Yes. > > * Finally, in the close() function, the driver has to kill the URBs > > and usb_free_coherent() the transfer_buffers. As far as I understand, > > no helper functions allow us to do all that, thus requiring the driver > > to iterate through the anchor to manually usb_free_coherent() the > > transfer buffer. > Yes. But you cannot nicely solve that with a flag as you proposed. You > would need to use a helper function. > > So, the intent of this patch is to provide a method to both kill the > > URBs and usb_free_coherent() the transfer buffer at once. The > Well, you don't directly. Your patch frees the buffer together with the URB. > That has some uses, but you still would need to iterate over the URBs > Yes, there is a helper for that, but then you cover one and only one > use case, that is, you leave no way to free the buffers without > at the same time discrading the URBs. > > You can do that, but it strikes me as unelegant. Elegancy is also my concern. My RFC originated from this patch: https://lore.kernel.org/linux-can/alpine.DEB.2.22.394.2206031547001.1630869@thelappy/ Here the proposed solution was to keep a pointer of all the transfer_buffer in a local array to be able to free them when closing. I really found that original patch to be unelegant which led me to propose this RFC. Comparatively, I still think my patch to be a more elegant solution, and the original author also seems to share my thoughts. If my patch is unelegant, then what would be the elegant/state of the art way to free all this DMA allocated memory? (pointing to any reference driver implementation should be enough for me to understand). Yours sincerely, Vincent Mailhol