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 F3E87ECAAA1 for ; Thu, 27 Oct 2022 19:10:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235160AbiJ0TK2 (ORCPT ); Thu, 27 Oct 2022 15:10:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234810AbiJ0TKZ (ORCPT ); Thu, 27 Oct 2022 15:10:25 -0400 Received: from mail.3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE2D1C3B; Thu, 27 Oct 2022 12:10:22 -0700 (PDT) Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 0E7B61B40; Thu, 27 Oct 2022 21:10:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1666897821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bP6tBJ5LItFY8cd4o65sGEV49YMopXKugfmg9p8xRTM=; b=C/RCOzPpijiskM8GR4oWBWVhWGDQYsLqZMnjGE/cuPhXKJpyx7M9UEqDaODTkB7HbFPBkE 77Muipe+zGVcdfPeTxIb1giXj4JWHmr6SXkqleqXLj3eKTeXc5/zakRA6sKenGG3fxP0We /pwpfDY5Rzh6jENo0sWyYoSHhyZyjPBcoIfPymYY4YjTPzZPPc7LLaf2oLFLotFdmr0Omc Dp5IButJAWziLhCReJxzplljbOaFXjDR4s2fQ3gmbgtPd7KECppSkh1rk8kEPVT9JSla6v 4BFkjozxh1HpMBN88KkafrYpPSRmO6122qDvDOBOeqmP99kJtn3x6N7/4Z5loQ== MIME-Version: 1.0 Date: Thu, 27 Oct 2022 21:10:20 +0200 From: Michael Walle To: Vladimir Oltean Cc: Shawn Guo , Leo Li , Rob Herring , Krzysztof Kozlowski , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Heiko Thiery , Andrew Lunn , Florian Fainelli Subject: Re: [PATCH] Revert "arm64: dts: ls1028a: sl28: use ocelot-8021q tagging by default" In-Reply-To: <20221027180445.74btifpmfhkt74zy@skbuf> References: <20221027113248.420216-1-michael@walle.cc> <20221027120519.7f3xun66l4lamcq6@skbuf> <20221027122727.fhs35eqtzmeen6x4@skbuf> <84c5e0a041909615a1ba8a4508131206@walle.cc> <20221027180445.74btifpmfhkt74zy@skbuf> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <3ea25819670c088df0cc6f483ab4fe01@walle.cc> X-Sender: michael@walle.cc Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 2022-10-27 20:04, schrieb Vladimir Oltean: > On Thu, Oct 27, 2022 at 06:00:04PM +0200, Michael Walle wrote: >> > - change the MODULE_ALIAS() of all tagging protocol driver modules from >> > "dsa_tag-> > proposed. I don't know why the current MODULE_ALIAS() is formatted the >> > way it is. Maybe Andrew can comment on whether this is feasible. >> > I think there isn't any backwards compatibility concern, since only >> > modules compiled for a certain kernel version are expected to be >> > loaded. >> >> FWIW, you can have multiple aliases if we somehow need to keep the >> IDs, >> too. > > Yeah, that's worth exploring, but it means that we have 2 code paths > for > request_module() with different string formats. To me this is slightly > undesirable, we should try to consolidate the mechanisms in the core. > >> > - put a translation table between string and MODULE_ALIAS() inside >> > dsa_core.ko, which potentially duplicates code. Maybe if we >> > auto-generate it somehow? >> >> Yeah, I also thought of a table with of name to module alias mapping. >> But then you'd have two places to keep in sync (of not autogenerated). > > Well, to be fair, this is not exactly true. As far as I could find > (grep for "ops->name" in net/dsa), there are only 3 instances of > reading > the "name" field of struct dsa_device_ops, and none of them are from a > fast path. > > I can imagine a table along the lines of: > > static const char * const dsa_tag_proto_names[] = { > [DSA_TAG_PROTO_NONE] = "none", > [DSA_TAG_PROTO_BRCM] = "brcm", > .... > }; > > which is then used to directly replace ops->name > (becomes dsa_tag_proto_names[ops->proto]). > > Then, we could add a new function "dsa_tag_protocol_name_to_id()" or > something along those lines, and construct the modalias string based on > that. > > No duplication necessary, since we would remove dsa_device_ops :: name. If one would a new tagger you'd need to add it to dsa_tag_proto_names[] as well as adding the tagger source file. Thus, two places to keep in sync. And you don't have all the information in one place, e.g. the tagger module. The name of the tagger as used in sysfs or device tree is then in the core. Just wanted to point that out. After all it's up to you as the maintainer to decide ;) -michael