Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp1261702pxv; Fri, 23 Jul 2021 04:10:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxPdRc3PXV/SGpQEYuC+KhN/Ssm6C8olnY/PEJk4Rdi4bNs88yGZrsrqFZvSnYmj4HNTeA X-Received: by 2002:a17:906:3693:: with SMTP id a19mr4255932ejc.237.1627038612401; Fri, 23 Jul 2021 04:10:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627038612; cv=none; d=google.com; s=arc-20160816; b=aAK4ezoCt5fr4sg2ZwbKAOW//+Dl/4ehy3URiNyMgXA7xltARXkkqspMN3v5WkPLg6 4nsLqNMctruXEuu0PbXVcc5q2tC6RYIL6IKR1/V10thCw0UbnqklZVFSlY0esd/zyKsG xtARStdEhsnVf//xeeZNHwSMszi1gf3YWe3b7pS1r8PFdk90CzEswwAxmiPJiGuvdAXy yuNPqmN25zc4nfxSYQU6jFmMgeUmn4qof/xtc3ra3vQ3HphPcddJfsOTP6E0QKXb2IY7 p+BFB90IRxzuoNqOEb70rfAeKWgQoKV8ufkNXu9ig5hafi5a56rbqMu1DAz18WmLK0bC gj7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=ZvOmuGDjboR93aCXrzX4U2TF9OvHadby7OHnyO1dGdc=; b=h9aiAQDUUqylYn1JPCPje1e7zBL5fWO2CONwV69pueQ/eTfgItiK0I+ivUOs+SaMCk 8atmXGil2Pg8a+jEAmyvM9eoR1DohYYYHiMXqDu26WvPEUuuSXFGlHiU2LrxpInCCPxv 8xdtLUWJK3aHdRTti47TBmNHfyNp2O9XLEUqGnI4hqLfMRvhBPYdM+0MI3KABI3+reo1 guKWPhb8j6Lg1VlpB0nmxkwzRSU4/wd7eB8zMbow4dKCg3aFUDVRg15On8x466Kt+aZC /BgszftChBuJEWzCjyo9UwZ7JQRB7OMikjFd5K1R6rFbNH5dZM32TAW5aHp+uUgqlAKB mpTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cEnVnGpD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jy1si35397667ejc.592.2021.07.23.04.09.48; Fri, 23 Jul 2021 04:10:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cEnVnGpD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231760AbhGWKYg (ORCPT + 99 others); Fri, 23 Jul 2021 06:24:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231296AbhGWKYg (ORCPT ); Fri, 23 Jul 2021 06:24:36 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ED749C061575; Fri, 23 Jul 2021 04:05:08 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id gn11so3240188ejc.0; Fri, 23 Jul 2021 04:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ZvOmuGDjboR93aCXrzX4U2TF9OvHadby7OHnyO1dGdc=; b=cEnVnGpDkavf9X4sTJbxQwJBP2ILnS2Tvy7GZKQrKj5iinFuOKRqgBfM58DMuu9Xhf rbcl/ircBWtpt39Rc9adb5ODyEdlgtj+zUqgc0t6kM0PUClEpTWxY3gb4YpjgfpAYsQL H7rqdOQk+A+b5al/0wMM0U4NNnVzIq3tHPF+ZM9+zbb1ux0Rwoa+0PZhRmfdaHk41eYH +JcZxUyp7pYbcQGSASjldrNmY3XwLHaKDmy3ZKKA5C0KYFS42ztfA8AQceGK6leBf9IT 1+ZfuqsWXQmkNTxjJ+nyEPwjxFNTIVUsrcJdUfcPg7vvj5jwOJWTzV+uVa28TN7rKQkb T4Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=ZvOmuGDjboR93aCXrzX4U2TF9OvHadby7OHnyO1dGdc=; b=edWt7S4DAUR7JngbJi8Mt2eOIZ7KTq6MPAYEjkkNTWtKaIIgMc0MWWiIralo8ELwdB B5fN0u9DkxUMLIGML+GTYAqA+YC5J88Z7yMlmOzLr4XH4Mgj0DKkgYX05Hf8aHYKzeRo Im8CCCqhkVsTiYIyi30qc9f0ixzuOPvWWgH6U1tZ6EdwzCjMv1EfN4N/TpMtm0lTzqov q4eWm3OwMzwgWMCD2opK+u1BjtnmaJhm6ATty/fEifF60QjoMJSC0f+s7NsSq/YfeZ/H ut92aBzi1HKuRteRJBbpr++lDAMVP+7l1F6EvqtVrLVeLUTHFgVHEzJ6LHifb428ZFbb N8EQ== X-Gm-Message-State: AOAM530gQc4cKx4RRduTpZu8n19KeBnO/b9r0DxXwMpkn0Qa609zU6vy cJs1IBtu3sMcyilS52feqQ0= X-Received: by 2002:a17:906:5fc1:: with SMTP id k1mr4001512ejv.360.1627038307340; Fri, 23 Jul 2021 04:05:07 -0700 (PDT) Received: from Ansuel-xps.localdomain (host-79-26-254-101.retail.telecomitalia.it. [79.26.254.101]) by smtp.googlemail.com with ESMTPSA id kj26sm10670958ejc.24.2021.07.23.04.05.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jul 2021 04:05:06 -0700 (PDT) From: Ansuel Smith To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Ansuel Smith Subject: [RFC] dsa: register every port with of_platform Date: Fri, 23 Jul 2021 13:05:05 +0200 Message-Id: <20210723110505.9872-1-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The declaration of a different mac-addr using the nvmem framework is currently broken. The dsa code uses the generic of_get_mac_address where the nvmem function requires the device node to be registered in the of_platform to be found by of_find_device_by_node. Register every port in the of_platform so they can correctly found and a custom mac-addr can correctly be declared using a nvmem-cell declared in the dts. An example of this would be a device that use a specific mac-addr for the wan port and declare the source of that with a nvmem-cell. In the current state, nvmem will always fail to find the declared cell but registering the devicenode with the of_platform doesn't look correct to me so am I missing something? Is this not supported? (declaring nvmem cell for the mac-addrs in the port node) In theory it should since of_get_mac_address supports exactly that. If I'm not missing something, I see this as the only solution or change the logic of how the function in of_get_mac_address find the cell. I hope someone take care of this as currently the function doesn't work most of the time, if this workaround is not used. Since mtd now actually supports declaring of nvmem cells, we are starting to adopt this new implementation and we found this problem. Also a mediatek drivert suffer of the same problem where it does declare special mac port without using the of_platform (and so requires manual registration using the function in this patch) with the compatible "mediatek,eth-mac" Signed-off-by: Ansuel Smith --- net/dsa/dsa2.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c index b71e87909f0e..30b1df69ace6 100644 --- a/net/dsa/dsa2.c +++ b/net/dsa/dsa2.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include "dsa_priv.h" @@ -392,6 +393,7 @@ static int dsa_port_setup(struct dsa_port *dp) break; case DSA_PORT_TYPE_USER: + of_platform_device_create(dp->dn, NULL, NULL); of_get_mac_address(dp->dn, dp->mac); err = dsa_slave_create(dp); if (err) -- 2.31.1