Received: by 2002:ac0:e350:0:0:0:0:0 with SMTP id g16csp1491018imn; Sun, 31 Jul 2022 09:00:46 -0700 (PDT) X-Google-Smtp-Source: AA6agR5Mu1XCJaPqqzKD6r0FFtikl0EFUFmgT6ImmzpRc4nM+NVPmQXPNKhJlmKGuutA3FaGqNL4 X-Received: by 2002:a17:902:830c:b0:16e:ccf7:aa8c with SMTP id bd12-20020a170902830c00b0016eccf7aa8cmr7129709plb.10.1659283245978; Sun, 31 Jul 2022 09:00:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659283245; cv=none; d=google.com; s=arc-20160816; b=aDFNMxEe/kBiwz18vHwgBXF2lQX6kVO/R4yCCm9wgAU8BuZFM7R76UBGe+fvYwn4c4 E5kiXPuUTPXjgrLdaKs8VRSRmuZgRXSGcSepDu3AHrSWAcizCX+m+t01q5Z/Nj4qdykG LXadKaanx50Qnvx0brTtzGM+l4ZFpmg7TgrjYAU0lCeV67Nw7K9lJ9l/ms7M4dlTHHUg UM7eKrH5rjjpUBAmKzwONQQcJhJalF+Mv7dSqev+iJepO8Nnnu7B+05I5tTWICs3BVF9 vNtfZeL7XM4p9zu1SJvwmQyZ5yqGo1aeblaVCkl/eVuzf8RGy6nnRnO5eMUHYZZla7gS fy8A== 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=4eB2VODr+0qCxbAW7BEEzvMOUvlQ5Vk+lICZ8qaxZMI=; b=HSbjZUebuEJeassM8ipSN7TOmPWX4foHRG26PmzyyulGjAEVifg0nNszxkpPM2zthF c+DePHPlqeYqvrgV81VUIN12aVVMeMxXiGTGg6wK/AAkHqt41GAisn/Z8G4UVuuoF32P PPk8YZGB20wo9elXbOw3KQcxik2JYb+BcTbqQwYMrsZUJvVbUlQxJK+CZWnrtw+Ivdpo tFTvRfCYvHiSxx1NsOCEEabnrtZvEfDVH9ynFT7D5Ho9K7GUicDvaR1H8aZA2rxRyrhR nb/5MyO5kONAAdW3TIH3/GTeslyCcSWHxJW1AbOIRd7JZ6Be3IvrKNI+FltG2ydImPzS 0QbA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=QDeMG3c1; 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 s34-20020a056a0017a200b0052d70adee62si1031590pfg.309.2022.07.31.09.00.31; Sun, 31 Jul 2022 09:00:45 -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=QDeMG3c1; 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 S237052AbiGaPyV (ORCPT + 99 others); Sun, 31 Jul 2022 11:54:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237343AbiGaPyP (ORCPT ); Sun, 31 Jul 2022 11:54:15 -0400 Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E124FE0BE for ; Sun, 31 Jul 2022 08:54:13 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id h12so9840306ljg.7 for ; Sun, 31 Jul 2022 08:54:13 -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=4eB2VODr+0qCxbAW7BEEzvMOUvlQ5Vk+lICZ8qaxZMI=; b=QDeMG3c1dnSJnu0g+xKTtGTgXxlOQoPvzoCiV+1HlbbdFruMsPo2ZE+eVtH6/cjhdc gcyLcbNZNyqEf3AugVUJQB5dwRJC4T2D9eJp//DlQ9O7NZCA0rcrVJD8m+kJPyWS1Pn5 7uX4gmcLBkhrfe7Tp+78Rc43h3NZ43QuBORiE= 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=4eB2VODr+0qCxbAW7BEEzvMOUvlQ5Vk+lICZ8qaxZMI=; b=z4P/r55slkHWtK4cYLMCbiMC9CeFvKGbW1iJSVh5EMUKB1LKIxL474FPiSb+AiYS+Z hJf+OHSEKSprvdRr+6GUBFOSepASNK3/V8qAhX+Q/QG3lZtEOug+I9DJo0Ws6bEuxVzt vdtC6e0E3B6ezE34oVSvbs5p1ImNbiqRHsDV4DcejUy7a3g5yxGFVcNCADT+xXI+dN/7 azuVpE2vozV7Eiv+B0Wt1QmMtLzW2W7oZVUXBFsaCYJMlMD5/LdprLbRTjVjsB7koqWq C5WNluO7icVfx/aih28wcXNscDfymN8FKCwaqKZQdEF6A+zta/G3Baa8/agtg2mkSHg6 YCUw== X-Gm-Message-State: ACgBeo2wXEiQzbfFaoJe5v+VQw11/gLYoBLrQmvZiIIwHobbURVO9Hnf 4Y+eQg8FQLLJ/HnwRXHQeRzqa+D2fFZl/t02vb0NXQ== X-Received: by 2002:a05:651c:335:b0:25e:4ac0:86e2 with SMTP id b21-20020a05651c033500b0025e4ac086e2mr1207861ljp.427.1659282852262; Sun, 31 Jul 2022 08:54:12 -0700 (PDT) MIME-Version: 1.0 References: <20220726210217.3368497-9-dario.binacchi@amarulasolutions.com> <20220727113054.ffcckzlcipcxer2c@pengutronix.de> <20220727192839.707a3453.max@enpas.org> <20220727182414.3mysdeam7mtnqyfx@pengutronix.de> <20220728090228.nckgpmfe7rpnfcyr@pengutronix.de> <20220728105049.43gbjuctezxzmm4j@pengutronix.de> <20220728125734.1c380d25.max@enpas.org> <20220729073352.rfxdyjvttjp7rnfk@pengutronix.de> In-Reply-To: <20220729073352.rfxdyjvttjp7rnfk@pengutronix.de> From: Dario Binacchi Date: Sun, 31 Jul 2022 17:54:01 +0200 Message-ID: Subject: Re: [RFC PATCH v3 8/9] can: slcan: add support to set bit time register (btr) To: Marc Kleine-Budde Cc: Max Staudt , linux-kernel@vger.kernel.org, linux-can@vger.kernel.org, Oliver Hartkopp , michael@amarulasolutions.com, Amarula patchwork , Jeroen Hofstee , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Wolfgang Grandegger , 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=ham 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 Marc, On Fri, Jul 29, 2022 at 9:33 AM Marc Kleine-Budde wrote: > > On 29.07.2022 08:52:07, Dario Binacchi wrote: > > Hello Marc and Max, > > > > On Thu, Jul 28, 2022 at 12:57 PM Max Staudt wrote: > > > > > > On Thu, 28 Jul 2022 12:50:49 +0200 > > > Marc Kleine-Budde wrote: > > > > > > > On 28.07.2022 12:23:04, Dario Binacchi wrote: > > > > > > > Does it make sense to use the device tree > > > > > > > > > > > > The driver doesn't support DT and DT only works for static serial > > > > > > interfaces. > > > > > > > > Have you seen my remarks about Device Tree? > > > > > > Dario, there seems to be a misunderstanding about the Device Tree. > > > > > > It is used *only* for hardware that is permanently attached, present at > > > boot, and forever after. Not for dyamically added stuff, and definitely > > > not for ldiscs that have to be attached manually by the user. > > > > > > > > > The only exception to this is if you have an embedded device with an > > > slcan adapter permanently attached to one of its UARTs. Then you can > > > use the serdev ldisc adapter to attach the ldisc automatically at boot. > > > > It is evident that I am lacking some skills (I will try to fix it :)). > > We're all here to learn something! > > > I think it is equally clear that it is not worth going down this path. > > If you have a static attached serial devices serdev is the way to go. > But slcan has so many drawbacks compared to "real" CAN adapters that I > hope the no one uses them in such a scenario. > > > > If you are actively developing for such a use case, please let us know, > > > so we know what you're after and can help you better :) > > > > I don't have a use case, other than to try, if possible, to make the driver > > autonomous from slcand / slcan_attach for the CAN bus setup. > > From my point of view your job is done! Ok. > > > Returning to Marc's previous analysis: > > "... Some USB CAN drivers query the bit timing const from the USB device." > > > > Can we think of taking the gs_usb driver as inspiration for getting/setting the > > bit timings? > > > > https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/gs_usb.c#L951 > > https://elixir.bootlin.com/linux/latest/source/drivers/net/can/usb/gs_usb.c#L510 > > > > and, as done with patches: > > > > can: slcan: extend the protocol with CAN state info > > can: slcan: extend the protocol with error info > > You can define a way to query bit timing constants and CAN clock rate, > but you have to get this into the "official" firmware. You have to roll > out a firmware update to all devices. What about non official firmware? > > > further extend the protocol to get/set the bit timing from / to the adapter ? > > In the case of non-standard bit rates, the driver would try, depending on the > > firmware of the adapter, to calculate and set the bit timings autonomously. > > If an adapter follows 100% the official firmware doc the BTR registers > are interpreted as SJA1000 with 8 MHz CAN clock. I checked the sources and documentation of the usb adapter I used (i. e. Https://www.fischl.de/usbtin/): ... sxxyyzz[CR] Set can bitrate registers of MCP2515. You can set non-standard baudrates which are not supported by the "Sx" command. xx: CNF1 as hexadecimal value (00-FF) yy: CNF2 as hexadecimal value (00-FF) zz: CNF3 as hexadecimal value ... Different from what is reported by can232_ver3_Manual.pdf : sxxyy[CR] Setup with BTR0/BTR1 CAN bit-rates where xx and yy is a hex value. This command is only active if the CAN And here is the type of control carried out by the slcan_attach for the btr parameter: https://github.com/linux-can/can-utils/blob/master/slcan_attach.c#L144 When I would have expected a different check (i. e. if (strlen(btr) > 4). Therefore it is possible that each adapter uses these bytes in its own way as well as in the content and also in the number of bytes. Thanks and regards, Dario > > See > > | https://lore.kernel.org/all/20220728105049.43gbjuctezxzmm4j@pengutronix.de > > where I compare the 125 Kbit/s BTR config of the documentation with the > bit timing calculated by the kernel algorithm. > > regards, > Marc > > -- > Pengutronix e.K. | Marc Kleine-Budde | > Embedded Linux | https://www.pengutronix.de | > Vertretung West/Dortmund | Phone: +49-231-2826-924 | > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- 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