Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp1209180rwl; Thu, 5 Jan 2023 10:06:54 -0800 (PST) X-Google-Smtp-Source: AMrXdXsAuJrjqalTZDGzyHHMgg5BIlfFxkgaCPzIaB5+CotQADEzCi9OF90EZz6gUCzdSamgH8dh X-Received: by 2002:a17:90a:9483:b0:226:2ec:2f66 with SMTP id s3-20020a17090a948300b0022602ec2f66mr34536662pjo.13.1672942014233; Thu, 05 Jan 2023 10:06:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672942014; cv=none; d=google.com; s=arc-20160816; b=XKlsnGyRntKxTV+wfoPtt75gPRbaXKIZjfxKgZTxIT4OXS4YxU4X13IELLll1LRWSA YKQNH0H+haFU0vBIMhsxoPYeUp998cyX5n7EAeb6xBb49cJGDwdGFl5kr/rWDD/esEPf jr/CFZbGPHCNreJ9ig2r68WkpsmzNnwHp+WxPl/FtqEofKvM2q7Je74MiDq9rmgLcb3m VvbMt/FcNYKmxLboyo+x20KwlQFLFql0dhhTXmyTocpvne77sf/FZvfwhvSCp0DnUc+Z 2E4ln8lnWHGpj1/hg3ykShNSRabFZaWZIr0f4UyvukhtxsMRgXP/EY591vKk+4yoa/rI GVeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:organization:references:in-reply-to :message-id:subject:cc:to:from:date:dkim-signature; bh=vgxfht1qCanXLi0U+RL9riFtYEW17cKX1yDlrdAShes=; b=g0ul8w5gKAFSKAsKqtAPydbF+8e6hTkYKvu1iWwpymBm6jVLtl4YW3QtzxqnqTsNcT UiPObNbcWY5mEUVlo2BYDaK6vhd0HyVBoQBuKZoZ3ByDM9rpacsPLLxBo3Rud/1T8dLE r7oBI0SvfeGq5R+rPv55xQkwtow8y5SwKXcb8AvtriyziLGb6VSFNs8+yOFSWWE7a62R nCwxtoY+j85U1d+5jc/i8xtOT/xWS/WALV+CTwV0iommH9jYYajlefodNNmfCwDb3TZO 8K/OSrnwWs1BWbQpY97t5bg1BwG4wbZTdZ4J7hnUr9PbQh6wHbdcBX6wK5ByJHEeVDLO 0IFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@denx.de header.s=phobos-20191101 header.b=jpVJ1FBa; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n1-20020a63b441000000b004a2e20a1682si12115092pgu.95.2023.01.05.10.06.47; Thu, 05 Jan 2023 10:06:54 -0800 (PST) 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=@denx.de header.s=phobos-20191101 header.b=jpVJ1FBa; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235281AbjAERoj (ORCPT + 55 others); Thu, 5 Jan 2023 12:44:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232273AbjAERoh (ORCPT ); Thu, 5 Jan 2023 12:44:37 -0500 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 672693DBDE; Thu, 5 Jan 2023 09:44:35 -0800 (PST) Received: from wsk (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lukma@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 75AC485172; Thu, 5 Jan 2023 18:44:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1672940673; bh=vgxfht1qCanXLi0U+RL9riFtYEW17cKX1yDlrdAShes=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jpVJ1FBan8bihsKzVWSalku+BZtFfdWLsqVkVcgv5URCRyU5uNKz8GFzNjJ2pgk6f TC/Gs3VXq+/NUuTic1uF3NilE1gtGjVo7UQBBQJMyha40cLxaCEWk1f0nusUrPRZQn 3IlaeMVDoVxODgT7AVasQEGVEyRT+AdI4tYXEj9e99O9fe3fLdWkL1RxjInS/TQK7S EE26LPfL5YvCHxcLyuIFSIIW3E94NnOZMxN8QDvwR5gOZKiVryoqzKGVXeSZAtKH3q HOCHnBUtNj39so+o17yR1x6TOwYLRKqdeAh7h0By0ToxxO9N5AIdy4NvXVUaXVKx/H uEu/Uf14vHQdQ== Date: Thu, 5 Jan 2023 18:44:19 +0100 From: Lukasz Majewski To: Alexander Duyck Cc: Andrew Lunn , Vladimir Oltean , Eric Dumazet , Florian Fainelli , "David S. Miller" , Jakub Kicinski , Russell King , Paolo Abeni , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/3] dsa: marvell: Provide per device information about max frame size Message-ID: <20230105184419.7b409a2d@wsk> In-Reply-To: References: <20230102150209.985419-1-lukma@denx.de> <20230103100251.08a5db46@wsk> <20230105113712.2bf0d37b@wsk> Organization: denx.de X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ZHXtXWOGpywgiwRYNY4ds54"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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 --Sig_/ZHXtXWOGpywgiwRYNY4ds54 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Alexander > On Thu, Jan 5, 2023 at 2:37 AM Lukasz Majewski wrote: > > > > Hi Andrew, Alexander, > > =20 > > > Hi Andrew, > > > =20 > > > > > @@ -3548,7 +3548,9 @@ static int mv88e6xxx_get_max_mtu(struct > > > > > dsa_switch *ds, int port) if > > > > > (chip->info->ops->port_set_jumbo_size) return 10240 - > > > > > VLAN_ETH_HLEN - EDSA_HLEN - ETH_FCS_LEN; else if > > > > > (chip->info->ops->set_max_frame_size) > > > > > - return 1632 - VLAN_ETH_HLEN - EDSA_HLEN - > > > > > ETH_FCS_LEN; > > > > > + return (max_t(int, chip->info->max_frame_size, > > > > > 1632) > > > > > + - VLAN_ETH_HLEN - EDSA_HLEN - > > > > > ETH_FCS_LEN); + > > > > > return 1522 - VLAN_ETH_HLEN - EDSA_HLEN - ETH_FCS_LEN; > > > > > =20 > > > > > > > > I would also prefer if all this if/else logic is removed, and > > > > the code simply returned chip->info->max_frame_size - > > > > VLAN_ETH_HLEN - EDSA_HLEN - ETH_FCS_LEN; > > > > =20 > > > > > > So then the mv88e6xxx_get_max_mtu shall look like: > > > > > > WARN_ON_ONCE(!chip->info->max_frame_size) > > > > > > if (chip->info->ops->port_set_jumbo_size) > > > ... > > > else > > > return chip->info->max_frame_size - VLAN_ETH_HLEN - > > > EDSA_HLEN - ETH_FCS_LEN; > > > > > > > > > Or shall I put WARN_ON_ONCE to the mv88e6xxx_probe() function? > > > > > > > > > The above approach is contrary to one proposed by Alexander, who > > > wanted to improve the defensive approach in this driver (to avoid > > > situation where the max_frame_size callback is not defined and > > > max_frame_size member of *_info struct is not added by developer). > > > > > > Which approach is the recommended one for this driver? =20 > > > > Is there any decision regarding the preferred approach to rewrite > > this code? =20 >=20 > I would defer to what Andrew proposed since he has more experience > with the DSA code than I do. >=20 Ok, then I will prepare v4 according to Andrew suggestions. Thanks for the update :-) > Thanks, >=20 > - Alex Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de --Sig_/ZHXtXWOGpywgiwRYNY4ds54 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAmO3DHMACgkQAR8vZIA0 zr1iaQgAxgSS4qcjJ3bj72zzCG0v08fmLzxYZzg7ge+ooLbzqjzOVHONWWvPZmtu zSE21mRcUOQqh7E0NRoVJ0A9sXKVtFVMUk/EIlZNa9cXFTiKw14FYrAlv4NXujDO LVjs8lY40rUbY5wOploY9KIZk5eXLFhwWo6WNTuor5ogutg3/jpNlj0LHjmyQe9v B2mPPJuSmcGFOfS4yC+GXBsK7oAToa3ULLxWjiwfvL5xRfO3shh4VSaYupu47nwJ j1DTeCWuaTDYYo6CLXlukV35KAvsDE/lA6NtTJOg43FaPBUUB2nW6YrUfk5x+mS0 tBt7+FySdBAUJ6IE1YY9YH0uMWuX/w== =okRi -----END PGP SIGNATURE----- --Sig_/ZHXtXWOGpywgiwRYNY4ds54--