Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp536978iob; Wed, 18 May 2022 07:34:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwChNDF43cSV/wxbfqmltKwEZDqjDzXK8+TBIH0N+4DWjRq0bAXjIvp6lMvdSsKno2evTaX X-Received: by 2002:a63:c00c:0:b0:3f6:103:5bc1 with SMTP id h12-20020a63c00c000000b003f601035bc1mr3223649pgg.404.1652884476224; Wed, 18 May 2022 07:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652884476; cv=none; d=google.com; s=arc-20160816; b=QDlGhbkjoB1QFLi8EI5mFmnk7UWVZdbFJn2DVtNe4PE4+V5iW8k3hwILYxbPOZ/+9h GmLwG5/v8WWzekcuRkn8VpgE+j+PWcZ0AY4jvALPPI5QC1TUK9jtbf6JlA9h1HLMgMR7 r6XR9KpktnrhfDZ5E+zNGxRHVpYPVb8/yUhOA+QABfUJN15VDJ3twNhVslyWo1l7YOlP D4t13XReewy0pSiLfY+Hv7i4bXTaspT0c8AReP3ba7YsJLtRKx7K/85clGCHtFJwLtSb LYSB8/mnjG3VwhMPmh9zOHdYy6sGV+BfJsnXO69SApfFKbQPN8W2RZH11h3FKcKhimzd 0Z+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=86Er3ONQXvEiKRTEscf9XSc+0dLxP7J1WFsKTN+NR7Y=; b=lx6DWJaxi2lNS0OAaWqtHqE6IGWSp19ekIhku9jPLC/tkDZp56oiUvdW/Vv3SurUsn h3FKco9iZWUZQPPAZv0YWXt1Ui45EucrohOZ0FUcQUp3OrddO2bdntNBaMvdvTiQi7OF jFPCGamiqQ2RBbUJpdsiEyLUXIQCPAj1m8S9QVaWvRQnjCC8aSUqzxfV7aN6QaUfvEwd UXZrRBJu88bU5TeS1YdOe3ULId21A2brZEhbXGPZs156s6r24363wPe5k5SlAT/LXwAP IelNXacLFfYsEcmfH8paw4DqseTDiUcHhfDpuU5JHFDCqrminmt6U78klUrvHKX1UzTJ s6Bg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@hartkopp.net header.s=strato-dkim-0002 header.b=i1avzboQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id d10-20020a63734a000000b003f610ec0f1fsi1770587pgn.31.2022.05.18.07.34.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 May 2022 07:34:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@hartkopp.net header.s=strato-dkim-0002 header.b=i1avzboQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4335A1CE62E; Wed, 18 May 2022 07:34:15 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238683AbiEROeH (ORCPT + 99 others); Wed, 18 May 2022 10:34:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238567AbiEROeE (ORCPT ); Wed, 18 May 2022 10:34:04 -0400 Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.162]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB13D1B176E; Wed, 18 May 2022 07:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1652884439; s=strato-dkim-0002; d=hartkopp.net; h=In-Reply-To:From:References:Cc:To:Subject:Date:Message-ID:Cc:Date: From:Subject:Sender; bh=86Er3ONQXvEiKRTEscf9XSc+0dLxP7J1WFsKTN+NR7Y=; b=i1avzboQzaCFQYlGeiJHzoKUOtnu19aVV5TgRWHiydIoKKTiRHz01fvGISWyQAtONV LQkHCaL5aqDXGc3mZzc9FMkgd8oNjKUOhuoOMjNl3p4lk7xvwXTsRwN8W6vL4QWI7JGB xwNrWY45pRRF55AmRNyYg3FVU6h/h8wVw4KIgjPh3UR6qj9KfNCetyFap23XYibJDMZz j5mK/WefllBmtBU/dtdDPNNjv2iK3CJMWN9McEpY3ejUyjVI6H/DVYbNZOGbvtHm0ThQ TsSNQC6R9wezY5HihYUaXmGDdZanLyPlCFxIDdAsjfghlxxy14BISecl6iykT5MW8yOv 3/VA== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":P2MHfkW8eP4Mre39l357AZT/I7AY/7nT2yrDxb8mjG14FZxedJy6qgO1qCHSa1GLptZHusx3hdBqPeOuh2krLEWFUg==" X-RZG-CLASS-ID: mo00 Received: from [IPV6:2a00:6020:1cff:5b00::b82] by smtp.strato.de (RZmta 47.45.0 AUTH) with ESMTPSA id R0691fy4IEXxHnS (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Wed, 18 May 2022 16:33:59 +0200 (CEST) Message-ID: <3dbe135e-d13c-5c5d-e7e4-b9c13b820fb8@hartkopp.net> Date: Wed, 18 May 2022 16:33:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v3 3/4] can: skb:: move can_dropped_invalid_skb and can_skb_headroom_valid to skb.c Content-Language: en-US To: Vincent MAILHOL , Marc Kleine-Budde Cc: Max Staudt , linux-can@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org References: <20220517060821.akuqbqxro34tj7x6@pengutronix.de> <20220517104545.eslountqjppvcnz2@pengutronix.de> <20220517141404.578d188a.max@enpas.org> <20220517122153.4r6n6kkbdslsa2hv@pengutronix.de> <20220517143921.08458f2c.max@enpas.org> <0b505b1f-1ee4-5a2c-3bbf-6e9822f78817@hartkopp.net> <43768ff7-71f8-a6c3-18f8-28609e49eedd@hartkopp.net> <20220518132811.xfmwms2cu3bfxgrp@pengutronix.de> From: Oliver Hartkopp In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE 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 On 18.05.22 16:07, Vincent MAILHOL wrote: >>> It does. I've seen CAN setups (really more than one or two!) in VMs and >>> container environments that are fed by Ethernet tunnels - sometimes also in >>> embedded devices. > > Are those VM running custom builds of the kernel in which all the CAN > hardware devices have been removed? Also, isn't it hard to keep those > up to date with all the kernel security patches? AFAIK all kind of BSPs create custom configured kernels. And to remove attack surfaces the idea is to minimize the code size. That's not only to save some flash space. >>>> A two level split (with or without rx-offload) is what makes the most >>>> sense to me. >>>> >>>> Regardless, having the three level split is not harmful. And because >>>> there seems to be a consensus on that, I am fine to continue in this >>>> direction. >>> >>> Thanks! >>> >>> Should we remove the extra option for the bitrate calculation then? >> >> +1 > > I can imagine people wanting to ship a product with the bitrate > calculation removed. For example, an infotainment unit designed for > one specific vehicle platform (i.e. baudrate is fixed). In that case, > the integrator might decide to remove bittiming calculation and > hardcode all hand calculated bittiming parameters instead. > > So that one, I prefer to keep it. I just didn't mention it in my > previous message because it was already splitted out. Ok. Interesting that we have such different expectations. >>> And what about the LEDS support depending on BROKEN? >>> That was introduced by commit 30f3b42147ba6f ("can: mark led trigger as >>> broken") from Uwe as it seems there were some changes in 2018. >> >> There's a proper generic LED trigger now for network devices. So remove >> LED triggers, too. > > Yes, the broken LED topic also popped-up last year: > > https://lore.kernel.org/linux-can/20210906143057.zrpor5fkh67uqwi2@pengutronix.de/ > I am OK to add one patch to the series for LED removal. Hm. We have several drivers that support LED triggers: $ git grep led.h at91_can.c:#include c_can/c_can_main.c:#include ctucanfd/ctucanfd_base.c:#include dev/dev.c:#include flexcan/flexcan-core.c:#include led.c:#include m_can/m_can.h:#include rcar/rcar_can.c:#include rcar/rcar_canfd.c:#include sja1000/sja1000.c:#include spi/hi311x.c:#include spi/mcp251x.c:#include sun4i_can.c:#include ti_hecc.c:#include usb/mcba_usb.c:#include usb/usb_8dev.c:#include xilinx_can.c:#include And I personally like the ability to be able to fire some LEDS (either as GPIO or probably in a window manager). I would suggest to remove the Kconfig entry but not all the code inside the drivers, so that a volunteer can convert the LED support based on the existing trigger points in the drivers code later. Our would it make sense to just leave some comment at those places like: /* LED TX trigger here */ ?? > Just some > heads-up: I will take my time, it will definitely not be ready for the > v5.19 merge window. And I also expect that there will be at least one > more round of discussion. > > While I am at it, anything else to add to the wish list before I start > to working it? Not really. IMO we already share a common picture now. Thanks for picking this up! Best regards, Oliver