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 3F993C433EF for ; Mon, 9 May 2022 11:56:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233532AbiEIMAI (ORCPT ); Mon, 9 May 2022 08:00:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233494AbiEIMAD (ORCPT ); Mon, 9 May 2022 08:00:03 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 803D823AF26 for ; Mon, 9 May 2022 04:56:08 -0700 (PDT) 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=6p0B4iriaGCJg0r/xi44uje9TH51cFyn8C3DVTYwsi4=; b=2QyZwCJ1FR8ToW+zwq/kX/jIB2 WZy0dA76G3DRBYN8665KsV75C80efGBZGHEXKmgiFI1sA2YmqHm03754QhX8uW5QQ8acF2uJISmLw mbRYtnCGKd+q61BEHA6Kc7Tc0Tn/tpSj7YS5SQIrpYJFO9aDt/sXhOtxVLYpdN1LDZ8Q=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1no1zV-001w7D-8y; Mon, 09 May 2022 13:55:53 +0200 Date: Mon, 9 May 2022 13:55:53 +0200 From: Andrew Lunn To: Luiz Angelo Daros de Luca Cc: Hauke Mehrtens , "David S. Miller" , Jakub Kicinski , Linus Walleij , Alvin =?utf-8?Q?=C5=A0ipraga?= , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "open list:NETWORKING DRIVERS" Subject: Re: [PATCH 3/4] net: dsa: realtek: rtl8365mb: Add setting MTU Message-ID: References: <20220508224848.2384723-1-hauke@hauke-m.de> <20220508224848.2384723-4-hauke@hauke-m.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > +static int rtl8365mb_port_change_mtu(struct dsa_switch *ds, int port, > > + int new_mtu) > > +{ > > + struct dsa_port *dp = dsa_to_port(ds, port); > > + struct realtek_priv *priv = ds->priv; > > + int length; > > + > > + /* When a new MTU is set, DSA always set the CPU port's MTU to the > > + * largest MTU of the slave ports. Because the switch only has a global > > + * RX length register, only allowing CPU port here is enough. > > + */ > > + if (!dsa_is_cpu_port(ds, port)) > > + return 0; > > + > > + length = new_mtu + ETH_HLEN + ETH_FCS_LEN; > > + length += dp->tag_ops->needed_headroom; > > + length += dp->tag_ops->needed_tailroom; > > Isn't it better to keep that within the driver? No matter the tag > position, it will be either 4 (RTL8365MB_CPU_FORMAT_4BYTES) or 8 > (RTL8365MB_CPU_FORMAT_8BYTES) bytes. You can retrieve that from > priv->chip_data->cpu->format, but the driver will probably never > support RTL8365MB_CPU_FORMAT_4BYTES. Until someone does implement the > 4-bytes tag (for some mysterious reason), I believe we could simply > use a constant here (using a proper new macro). Another option is to simply always use the bigger header length. I doubt there are many people actually using jumbo frames, and do they really care about 0x3FFF-4, vs 0x3FFF-8? > > + > > + if (length > RTL8365MB_CFG0_MAX_LEN_MASK) > > + return -EINVAL; > > + > > + return regmap_update_bits(priv->map, RTL8365MB_CFG0_MAX_LEN_REG, > > + RTL8365MB_CFG0_MAX_LEN_MASK, > > + FIELD_PREP(RTL8365MB_CFG0_MAX_LEN_MASK, > > + length)); > > +} > > + > > +static int rtl8365mb_port_max_mtu(struct dsa_switch *ds, int port) > > +{ > > + return RTL8365MB_CFG0_MAX_LEN_MASK - ETH_HLEN - ETH_FCS_LEN - 8; > > What is this magic 8? RTL8_4_TAG_LEN? There are some DSA headers in include/linux/dsa, probably a new one should be added with this RTL8_4_TAG_LEN. Andrew