Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp14964843rwb; Mon, 28 Nov 2022 06:43:39 -0800 (PST) X-Google-Smtp-Source: AA0mqf7MsIWQhRF/s6iB7/6QljQ6BeOJVX0vP3nMhYKkINC+It4ImJ0S7v1NAu0gb57e0s8sFTcw X-Received: by 2002:a05:6a00:5:b0:574:f82c:9389 with SMTP id h5-20020a056a00000500b00574f82c9389mr10363800pfk.39.1669646619732; Mon, 28 Nov 2022 06:43:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669646619; cv=none; d=google.com; s=arc-20160816; b=RaPWXKxJDd8CW+vFcg14V8p7qE1u0d8IzHbHtlgoIgZz6PN41O4mkfkL13CULTNvsH AGnj0uV6gFa+TlEc7Nyj673DSjBruzJYzxxciDDC92Z4YSEdbXp0X/xeY5vgMoiwEIys Y5b/jUI6dO2jmzR7vIRtut3P2u95rgmIcBFPlAUmrzHwb3+RcF6l8MgPqnpDqqrJYoVc /bxPcTmSaIay3RbYciT5GY2PyBKGl4rr7R/qIPq6vyvbz6KasRM7Gue2uCwSputPC07A cVzMvtoL9TovlE2kFHp7CoBHJno8iYgZeRJj1Bvk4Bfe3h8zWnQVx43QL+8/HuYWrVpZ rJDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=shIIJU9mUgqVvo7u+uZBJemwke0hUUcMwXAy+fLCBZg=; b=0A4lB/ppon9HwSZ1oNyIJOvhHEeGm7dCOZfsljoKLshloiuszM9P8m0qqB+cAphxWY V6JWuu0GqJSEy+s+xPBrlPK07y8Gu9QAy2rmOcj4XwUTjdEF90cruM4t1N5a+ahaK86O jNS6ATidr+F+1iF9WeV9gYAOIwKQGFurlYuW0HXQlKShvPyf2i+QAvZqBkZbFoes/XJy Ya2Ed1Tz1jVO5zJpK4LcHB3kTtMZwP6ErrzKxGmsHaoLfsWhXcGhlwxAnFduY5eSOZSe /tNMuqcDUFrWyKSN83siUBXBfWpVTjvbW5qdQzhDeuYDXkOSTEcoG9O6Y0egbbzunomc R0yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t20-20020a17090aba9400b0021936c913ccsi3157236pjr.80.2022.11.28.06.43.27; Mon, 28 Nov 2022 06:43:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232569AbiK1O3o (ORCPT + 85 others); Mon, 28 Nov 2022 09:29:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232502AbiK1O30 (ORCPT ); Mon, 28 Nov 2022 09:29:26 -0500 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C393A1F63A; Mon, 28 Nov 2022 06:29:24 -0800 (PST) Received: by mail-pj1-f42.google.com with SMTP id t17so9635280pjo.3; Mon, 28 Nov 2022 06:29:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=shIIJU9mUgqVvo7u+uZBJemwke0hUUcMwXAy+fLCBZg=; b=clea3xd9sSvB/Y917+W1DUpsu9JjgVpy74IadlgPmJ0L7feaeCpnaAumZyWPQUCDRi vZ+o962LTHEkI1v65HsiVehDuYRpJDwsMOMASMxKAnRtHpWTnOESc76JbMYSlnMuk6O1 zr3evS7eVU3s8pBkWorauXy2/qIiIupIaVbAXkKpS7kCH2E/s0c1nkZr/TkWMrnJpoQK nKNhAkkvT94Jqgalagt63BMEeBjed4M0IammBsCOREMAEMkSe5uPv5MPUo1FJhGnperN GKY6KBw/+/uDjAQYQ3cSl1CAPa+6o/L/gzHEstZOW4qjY5pPE6LZLnL/99XU1aSeK/NA ZlGg== X-Gm-Message-State: ANoB5plN00SkYar7LGIWYgyybhhzTzAAxq2Nxc+yczHwRKPKsvvAV5H/ 49JLZH1BHuC50Tl6xXrfzfrmIyThMfURVsndoYY= X-Received: by 2002:a17:902:b608:b0:189:7a8b:537d with SMTP id b8-20020a170902b60800b001897a8b537dmr10252626pls.95.1669645763894; Mon, 28 Nov 2022 06:29:23 -0800 (PST) MIME-Version: 1.0 References: <20221104073659.414147-1-mailhol.vincent@wanadoo.fr> <20221126162211.93322-1-mailhol.vincent@wanadoo.fr> <20221126162211.93322-3-mailhol.vincent@wanadoo.fr> In-Reply-To: From: Vincent MAILHOL Date: Mon, 28 Nov 2022 23:29:12 +0900 Message-ID: Subject: Re: [PATCH v4 2/6] can: etas_es58x: add devlink support To: Andrew Lunn Cc: Alan Stern , linux-can@vger.kernel.org, Marc Kleine-Budde , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , netdev@vger.kernel.org, linux-usb@vger.kernel.org, Saeed Mahameed , Jiri Pirko , Lukas Magel Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon. 28 Nov. 2022 at 22:45, Andrew Lunn wrote: > > > But if a driver does make the call, it should be careful to ensure that > > > the call happens _after_ the driver is finished using the interface-data > > > pointer. For example, after all outstanding URBs have completed, if the > > > completion handlers will need to call usb_get_intfdata(). > > > > ACK. I understand that it should be called *after* the completion of > > any ongoing task. > > What sometimes gets people is /sys, /proc. etc. A process can have > such a file open when the device is unplugged. If the read needs to > make use of your private data structure, you need to guarantee it > still exists. Ideally the core needs to wait and not call the > disconnect until all such files are closed. Probably the USB core > does, it is such an obvious issue, but i have no knowledge of USB. For USB drivers, the parallel of what you are describing are the URBs (USB request Buffers). The URB are sent asynchronously to the device. Each URB has a completion handler: https://elixir.bootlin.com/linux/v6.0/source/include/linux/usb.h#L1443 It is important to wait for all outstanding URB to complete before releasing your resources. But once you are able to guarantee that any ongoing actions were completed, the order in which you kfree() or usb_set_intfdata() to NULL matters less. Of course, the USB drivers could also have some /sys/ or /proc/ files opened, but this is not the case of the etas_es58x. By the way, the handling of outstanding URBs is done by es58x_free_urbs(): https://elixir.bootlin.com/linux/v6.0/source/drivers/net/can/usb/etas_es58x/es58x_core.c#L1745 which is called just before the devlink_free() and the usb_set_intfdata().