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=-7.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 E960DC433E0 for ; Tue, 2 Feb 2021 10:17:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A73F64E30 for ; Tue, 2 Feb 2021 10:17:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229631AbhBBKR3 (ORCPT ); Tue, 2 Feb 2021 05:17:29 -0500 Received: from mo4-p01-ob.smtp.rzone.de ([81.169.146.167]:32487 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229572AbhBBKR2 (ORCPT ); Tue, 2 Feb 2021 05:17:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1612260876; s=strato-dkim-0002; d=hartkopp.net; h=In-Reply-To:Date:Message-ID:From:References:Cc:To:Subject:Cc:Date: From:Subject:Sender; bh=qDOi0hXSjBqnavrfN868Xj6/fqoBRWS97C75b2d7tdo=; b=XhIjlF9U1lZMcFFByVx287Ud3RFqooWY+Xi6ZPT+EVf+akXwn0+F/H9U8tgneIJwFq CUxqueHT2Ggp92F7yHaSTwQneZAhC9Pm5MVBL+f9G+m4XBMcM1HNAfU4WaawYic1OIM2 KwTMsdX8M5XsVCvcC9ED+LW42I3iKnlLpRZodrDCkEHT133dtUf9fKYsR2MLfD0uPvs/ BY9B2OX/eSj3dzbOHM8XtHgrxlffqf4HZEzJkiMHgq7wuetqNPOJysAp4mq02kUibh8Q WXpvWJgw2LCg7l2EgINdpDHJ0b4oKiO+/i4Mn8UJhab5qgMWscRJpDNfw6l+HE5gvs5g WdYA== X-RZG-AUTH: ":P2MHfkW8eP4Mre39l357AZT/I7AY/7nT2yrDxb8mjG14FZxedJy6qgO1o3TMaFqTGVxiOMtqpw==" X-RZG-CLASS-ID: mo00 Received: from [192.168.10.137] by smtp.strato.de (RZmta 47.16.0 DYNA|AUTH) with ESMTPSA id w076a1x12AEUG52 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 2 Feb 2021 11:14:30 +0100 (CET) Subject: Re: [Question] Sending CAN error frames To: Vincent MAILHOL Cc: Marc Kleine-Budde , Jimmy Assarsson , Jimmy Assarsson , linux-can References: <87e3dd54-50ab-1190-efdb-18ddb3b21a02@hartkopp.net> <42080d05-7ab3-99be-92e2-73ed262350ba@gmail.com> <1debcaeb-71c7-6b78-88b3-7f121a33c1c1@kvaser.com> <17b14b11-87bf-9508-0da5-1031c5d5e132@pengutronix.de> <20210202082340.GA23043@x1.vandijck-laurijssen.be> <8050d433-591c-2d1f-f0c7-ffa92e33032d@pengutronix.de> <1b82f875-5884-3bf6-7891-2e4461d2a72a@pengutronix.de> From: Oliver Hartkopp Message-ID: Date: Tue, 2 Feb 2021 11:14:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org On 02.02.21 11:00, Vincent MAILHOL wrote: >>> If CAN_CTRLMODE_TX_ERR has been added to the kernel and >>> can_dropped_invalid_skb() is updated, then a CAN frame with CAN_ERR_FLAG set >>> would be either send as an error frame or dropped by can_dropped_invalid_skb(). >>> >>> So it would be echoed only if the driver supports CAN_CTRLMODE_TX_ERR and it's >>> enabled. >> >> ACK. > > The echo would be special here. We have to remember that the > payload of the CAN_ERR_FLAG frames is an arbitrary design. This > payload has no meaning for the data link. > > When we echo back the frame, only the DLC, CAN ID and payload of > the TX frame are irrelevant (except for vcan). > > My current idea would be to follow what Kvaser did: they send the > frame and the device reports the error flag (c.f. the example > given by Jimmy above). So the echo feature would not be used > for error flags. In fact I would suggest to think a about a proper API (aka CAN frame content definition) for outgoing CAN frames with the CAN_ERR_FLAG set. The CAN_ERR_FLAG has been renamed in the documentation to indicate "error messages" from the CAN controller, as an error frame is something completely different. Now as we are talking about having CAN_ERR_FLAG in the TX path besides the vcan testing stuff, we should think about an API for the really outgoing frames. We could not only think about "create an error frame right now" but also think about a more intelligent CAN node, which also offers to destroy one or more specific CAN ID(s) at a specific bit position after detecting that CAN ID. We could use the CAN_RTR_FLAG and the data[] section of the outgoing error CAN frames for such an API. Regards, Oliver