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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3BA17C43217 for ; Mon, 28 Nov 2022 22:50:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234567AbiK1Wu0 (ORCPT ); Mon, 28 Nov 2022 17:50:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234535AbiK1WuZ (ORCPT ); Mon, 28 Nov 2022 17:50:25 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A105A2A713; Mon, 28 Nov 2022 14:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=T9rYwEbRiQBED+qpRhzaD06PSzyyE+bp9qase0iwt68=; b=0talWK4KaQCdH5rTWh68JNXh5E FvGJmHuEORZ7f0M1LHuoHTeISlWVoRfrrwhKmJ1WJDZR8ifUE4CoqwY7ueglSZmvD7NgZ2MRtdgCn vekVek73CuvjTGvK2JQKLnE7SY6KWvSPqmIi7Ipzrl6DE3ZDvT5CsOv6cFWRxpRNYD4c=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1ozmuq-003nlP-MO; Mon, 28 Nov 2022 23:47:56 +0100 Date: Mon, 28 Nov 2022 23:47:56 +0100 From: Andrew Lunn To: Christoph Fritz Cc: Ryan Edwards , Oliver Hartkopp , Pavel Pisa , Andreas Lauser , Richard Weinberger , Wolfgang Grandegger , Marc Kleine-Budde , "David S . Miller" , Jakub Kicinski , Eric Dumazet , Paolo Abeni , Jonathan Corbet , linux-can@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 0/2] LIN support for Linux Message-ID: References: <20221127190244.888414-1-christoph.fritz@hexdev.de> <202211281549.47092.pisa@cmp.felk.cvut.cz> <202211281852.30067.pisa@cmp.felk.cvut.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-can@vger.kernel.org > - LIN devices with off loading capabilities are a bit special. For networking in general, we try very hard to make offload to hardware not special at all. It should just transparently work. One example of this is Ethernet switches which Linux controls. The ports of the switch are just normal Linux interfaces. You can put an IP address onto the ports in the normal way, you can add a port to a linux bridge in the normal way. If the switch can perform bridging in hardware, the linux bridge will offload it to the hardware. But for the user, its just a port added to a bridge, nothing special. And there are a lot more examples like this. I don't know CAN at all, but please try to avoid doing anything special for hardware offload. We don't want one way for software, and then 42 different ways for 42 different offload engines. Just one uAPI which works for everything. Andrew