Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp2510485imi; Sun, 24 Jul 2022 23:45:21 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sO8qM2V/pcNmC3u1JlYkaHmxjPIo0IQbP+LSfPu3vShhtXA2m1UoNqwelJN54KP1+EEwnc X-Received: by 2002:a17:907:7395:b0:72b:86f2:4fd5 with SMTP id er21-20020a170907739500b0072b86f24fd5mr8759797ejc.332.1658731521126; Sun, 24 Jul 2022 23:45:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658731521; cv=none; d=google.com; s=arc-20160816; b=cfs6+N1ZEBoONeQTw3Pf+qnu6Ibn3qZkBeBWgIYLmseV1JAkh7f/Jp8uMJ8FTqh75R Tx82slQ+Vl7cIcN2GH1SqCil4Xy0oB6AqMvbzaEVrxF4kusfKMYo+jMl+ipjQzKlv5nY vjRI6I+0+adxmNWJErPrrnsSmoBYA1/Oy5wi90TV4PVS1+R8pEE31PRSGB8bNHEu1rm+ HsbrTmrzoICLOCQO3L1D9VRkSHXQHU1ktlc7olqwKFwU2yOJcjW0G6JQAAgz2wYVMeV2 y0/WwifVrR7B2OqT55G/6PEoJMgjatXvwZ8ziCF07QVfxTPOEpmkLulS7b5F175v7qKP hYTw== 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:dkim-signature; bh=3n2kEuwuuK7IkJ0ff/d4b/av1Jc3vPr0Y+VbQ9saI84=; b=NHXKTtUbM0VF5D5vQzesQcDcjCWdjdj36wvV8AjOtgA9hJAn/mYP5CrquAxeHp+VcX vx6h8CyttZ+iRxHs3iXY1jG9yoyQo5PLYjmM/i6L691Lgc2Ynvbjn+3k7buKQa1yS2nY w9nspKAEjZ/BRKkhNddyZ9arfPJqHpMt8DamKRh8TtW0eV6Rul4I8Ehk8kj/jjot5EtX PsrszQY+K6j7HslwyBbPq+1/M4Iwia+4sJEEesfll2lXVmeuynjsk9KxfJYQGZE0qN2D FEHTixTiKweXHq15DGPuHfRgb0hodjSDjzb61R+2kXNv+tGwhwF1TNqxNPkcgdi6g807 Lfcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=LMFj5Zua; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hq20-20020a1709073f1400b0072b9928acfesi6934602ejc.581.2022.07.24.23.44.55; Sun, 24 Jul 2022 23:45:21 -0700 (PDT) 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; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=LMFj5Zua; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230394AbiGYGkm (ORCPT + 99 others); Mon, 25 Jul 2022 02:40:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230049AbiGYGkk (ORCPT ); Mon, 25 Jul 2022 02:40:40 -0400 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD6142ACD for ; Sun, 24 Jul 2022 23:40:37 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id r14so11979347ljp.2 for ; Sun, 24 Jul 2022 23:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3n2kEuwuuK7IkJ0ff/d4b/av1Jc3vPr0Y+VbQ9saI84=; b=LMFj5ZuaBlD5A8dOVY5use5OPng2TabtOQeQh3sj1+jQuFlqkgAZUEmCK8tSwYgexa o2MsvhXhVrSMXTC9diMSKAfs4wAZuvHIqEhL/GdOURDxkZOeJ7e/fIS5RBAjIuiKWfcA gqtQq0NLk4mZWY2TGmOQJx/c1R0bJUVAsjrac= 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=3n2kEuwuuK7IkJ0ff/d4b/av1Jc3vPr0Y+VbQ9saI84=; b=WOrFuJxE19b/t1IubuotlgdRvkITX8jHdWmkFgmN37cZFU0oAvD1AztZr9Enljv5mk 0WYfITqqwH8vUdMACLee1vaqzMFqirGTGVWIn+gSPJCy7bOGESCUocXeoveF4ffkqYAk 2XseFd5c9ck3hMmmDRxXP+dfYulsfCI/zyRNvsB7BRTgA2WAGq2KqGa/o/9AUfvKGtr0 QC1Lq2EzEQan8dBRNm9JSIu09WNVYqkf+97dfUwQt5DNlhk+KwIgGSWJfVwXoyRZjR6N 8H0ZNd3YbDZancEiiIXbm+XjQYfwYBTDACVp7mGI9k7NMSJ2LodCHFjETf0usgmWm7Ar O4ig== X-Gm-Message-State: AJIora9pTC1AOcA7cKly8/5aBDQvXWgSmUeF9f/TYzUfzpWMxgvB0gS8 dvukhxCXDPrIBxaJol+3cfNQTZgqb2utHFWcWF9D7w== X-Received: by 2002:a2e:bf0e:0:b0:258:e99e:998c with SMTP id c14-20020a2ebf0e000000b00258e99e998cmr3841212ljr.365.1658731236073; Sun, 24 Jul 2022 23:40:36 -0700 (PDT) MIME-Version: 1.0 References: <20220716170007.2020037-1-dario.binacchi@amarulasolutions.com> <20220716170007.2020037-3-dario.binacchi@amarulasolutions.com> <20220717233842.1451e349.max@enpas.org> In-Reply-To: <20220717233842.1451e349.max@enpas.org> From: Dario Binacchi Date: Mon, 25 Jul 2022 08:40:24 +0200 Message-ID: Subject: Re: [RFC PATCH 2/5] can: slcan: remove legacy infrastructure To: Max Staudt Cc: linux-kernel@vger.kernel.org, Jeroen Hofstee , michael@amarulasolutions.com, Amarula patchwork , "David S. Miller" , Eric Dumazet , Greg Kroah-Hartman , Jakub Kicinski , Jiri Slaby , Marc Kleine-Budde , Paolo Abeni , Vincent Mailhol , Wolfgang Grandegger , linux-can@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 Hi Max, First of all thank you for your review, it took me a while to get back to you because I wanted to do some analysis and tests regarding the code you suggested I change and also last week was very busy. On Sun, Jul 17, 2022 at 11:38 PM Max Staudt wrote: > > Hi Dario, > > This looks good, thank you for continuing to look after slcan! > > A few comments below. > > > > On Sat, 16 Jul 2022 19:00:04 +0200 > Dario Binacchi wrote: > > [...] > > > > @@ -68,7 +62,6 @@ MODULE_PARM_DESC(maxdev, "Maximum number of slcan interfaces"); > > SLC_STATE_BE_TXCNT_LEN) > > struct slcan { > > struct can_priv can; > > - int magic; > > > > /* Various fields. */ > > struct tty_struct *tty; /* ptr to TTY structure */ > > @@ -84,17 +77,14 @@ struct slcan { > > int xleft; /* bytes left in XMIT queue */ > > > > unsigned long flags; /* Flag values/ mode etc */ > > -#define SLF_INUSE 0 /* Channel in use */ > > -#define SLF_ERROR 1 /* Parity, etc. error */ > > -#define SLF_XCMD 2 /* Command transmission */ > > +#define SLF_ERROR 0 /* Parity, etc. error */ > > +#define SLF_XCMD 1 /* Command transmission */ > > unsigned long cmd_flags; /* Command flags */ > > #define CF_ERR_RST 0 /* Reset errors on open */ > > wait_queue_head_t xcmd_wait; /* Wait queue for commands */ > > I assume xcmd_wait() came in as part of the previous patch series? > Yes, correct. > > [...] > > > > /* Send a can_frame to a TTY queue. */ > > @@ -652,25 +637,21 @@ static int slc_close(struct net_device *dev) > > struct slcan *sl = netdev_priv(dev); > > int err; > > > > - spin_lock_bh(&sl->lock); > > - if (sl->tty) { > > - if (sl->can.bittiming.bitrate && > > - sl->can.bittiming.bitrate != CAN_BITRATE_UNKNOWN) { > > - spin_unlock_bh(&sl->lock); > > - err = slcan_transmit_cmd(sl, "C\r"); > > - spin_lock_bh(&sl->lock); > > - if (err) > > - netdev_warn(dev, > > - "failed to send close command 'C\\r'\n"); > > - } > > - > > - /* TTY discipline is running. */ > > - clear_bit(TTY_DO_WRITE_WAKEUP, &sl->tty->flags); > > + if (sl->can.bittiming.bitrate && > > + sl->can.bittiming.bitrate != CAN_BITRATE_UNKNOWN) { > > + err = slcan_transmit_cmd(sl, "C\r"); > > + if (err) > > + netdev_warn(dev, > > + "failed to send close command 'C\\r'\n"); > > } > > + > > + /* TTY discipline is running. */ > > + clear_bit(TTY_DO_WRITE_WAKEUP, &sl->tty->flags); > > + flush_work(&sl->tx_work); > > + > > netif_stop_queue(dev); > > sl->rcount = 0; > > sl->xleft = 0; > > I suggest moving these two assignments to slc_open() - see below. > > > [...] > > > > @@ -883,72 +786,50 @@ static int slcan_open(struct tty_struct *tty) > > if (!tty->ops->write) > > return -EOPNOTSUPP; > > > > - /* RTnetlink lock is misused here to serialize concurrent > > - * opens of slcan channels. There are better ways, but it is > > - * the simplest one. > > - */ > > - rtnl_lock(); > > + dev = alloc_candev(sizeof(*sl), 1); > > + if (!dev) > > + return -ENFILE; > > > > - /* Collect hanged up channels. */ > > - slc_sync(); > > + sl = netdev_priv(dev); > > > > - sl = tty->disc_data; > > + /* Configure TTY interface */ > > + tty->receive_room = 65536; /* We don't flow control */ > > + sl->rcount = 0; > > + sl->xleft = 0; > > I suggest moving the zeroing to slc_open() - i.e. to the netdev open > function. As a bonus, you can then remove the same two assignments from > slc_close() (see above). They are only used when netif_running(), with > appropiate guards already in place as far as I can see. I think it is better to keep the code as it is, since at the entry of the netdev open function, netif_running already returns true (it is set to true by the calling function) and therefore it would be less safe to reset the rcount and xleft fields. Thanks and regards, Dario > > > > + spin_lock_init(&sl->lock); > > + INIT_WORK(&sl->tx_work, slcan_transmit); > > + init_waitqueue_head(&sl->xcmd_wait); > > > > - err = -EEXIST; > > - /* First make sure we're not already connected. */ > > - if (sl && sl->magic == SLCAN_MAGIC) > > - goto err_exit; > > + /* Configure CAN metadata */ > > + sl->can.bitrate_const = slcan_bitrate_const; > > + sl->can.bitrate_const_cnt = ARRAY_SIZE(slcan_bitrate_const); > > > > - /* OK. Find a free SLCAN channel to use. */ > > - err = -ENFILE; > > - sl = slc_alloc(); > > - if (!sl) > > - goto err_exit; > > + /* Configure netdev interface */ > > + sl->dev = dev; > > + strscpy(dev->name, "slcan%d", sizeof(dev->name)); > > The third parameter looks... unintentional :) > > What do the maintainers think of dropping the old "slcan" name, and > just allowing this to be a normal canX device? These patches do bring > it closer to that, after all. In this case, this name string magic > could be dropped altogether. > > > [...] > > > > This looks good to me overall. > > Thanks Dario! > > > Max -- Dario Binacchi Embedded Linux Developer dario.binacchi@amarulasolutions.com __________________________________ Amarula Solutions SRL Via Le Canevare 30, 31100 Treviso, Veneto, IT T. +39 042 243 5310 info@amarulasolutions.com www.amarulasolutions.com