From patchwork Mon Jul 24 03:25:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Marangi X-Patchwork-Id: 124800 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9010:0:b0:3e4:2afc:c1 with SMTP id l16csp1720627vqg; Mon, 24 Jul 2023 04:07:20 -0700 (PDT) X-Google-Smtp-Source: APBJJlFnQu3J7UOvyr+83xmf6QW7fDiL7DR52DZz2+1LCyYjhsX+cavvy31QNld0Otk7T6U+QCkF X-Received: by 2002:a05:6358:e490:b0:134:e631:fd2b with SMTP id by16-20020a056358e49000b00134e631fd2bmr4558868rwb.0.1690196839522; Mon, 24 Jul 2023 04:07:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690196839; cv=none; d=google.com; s=arc-20160816; b=Rx/8l9lghd6zj/gX2u8Fjs3py0AihvonmXJEjv8mxd1tLDMcn/Gt9ceP+A86hwDyaW BU0NbEP0dLCCM5GkLgV7Z/Ee1TJkyCKNWNBqB9iesfS52Vzux4OKp+zn0TL9wUbfB3PJ HIEb0s45SHcxd38XggacxqDFsPZY1Ykylcc1XVeG+UdK8iUOc9FWHIdF6ivMDq5cELNx hAlrh1+K3lTOZDJRuoZey9ksdS0xHqFnnju92VZNbtJ2w3gf1pS6SWG96JfReWMQ899U srwLDmXKIX9btZuEmEZJHOWMjIrAY/RScAYHu0aPXfvYVsdA8aayaLL8L7PJvHdnCZTr 9bHw== 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=jm2AmYXeSq7Hv1D3EYH8vxoR54aZLC/z7y6TUDXlfXw=; fh=xvjLPbA4rv1Ki7LS7wlMBxUSRCFQII/YiWxsvhO8gOw=; b=O6qdSL1nTlYqarrlltQJc1HvNrWedjkfMcFSYaOG+RBxQc7VIug6RTkPeej0oO1bpo OCn205xsww+sXEo2t9HGPrS5qBS59TFD17iJRtz59OiV5cV30PZpTHd6APgyJQqv862U 3nl4yvHSrn2mpPUUhm6s7ObgckyjyT4z/j6nXw4BPhZQM0PEnZhJMh1pZtoW0m16fG3M xdpmmWRoX8Q35xA0BkTT1OjQiw+nLzv4xoj4ofUSxCx8Hi4SxDrKQCm9w8r5Lsi1EzuV 2xUiv9FfbKMEkI58a6yrL6PicR/DfUnBT9BP4/4qUdV0XrinRDdPYFGlo/vNwQYzGIQG bJVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20221208 header.b=d9UMgBhP; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y26-20020a637d1a000000b0055dcb8ea01csi8861450pgc.141.2023.07.24.04.07.05; Mon, 24 Jul 2023 04:07:19 -0700 (PDT) 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=@gmail.com header.s=20221208 header.b=d9UMgBhP; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232973AbjGXKyc (ORCPT + 99 others); Mon, 24 Jul 2023 06:54:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49350 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbjGXKyb (ORCPT ); Mon, 24 Jul 2023 06:54:31 -0400 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E442A90; Mon, 24 Jul 2023 03:54:29 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-3fd190065a7so32623325e9.2; Mon, 24 Jul 2023 03:54:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690196068; x=1690800868; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=jm2AmYXeSq7Hv1D3EYH8vxoR54aZLC/z7y6TUDXlfXw=; b=d9UMgBhPwr9+yS0cB8RgNScyWl6BhHVnRy8vrVAfOBKNk6b2xc+GWR5P56tHAcVBZT ckIoK4Eqrokqg700VJ3UnLuEVrOCK8jrRwCBv3BOS8u8NST3tSx+CltWurz5swA81Mfv A2Es1/fkBb+zs4Tv2VY8QEmqRZhwg4BZ7Ym4fqUQjP5d9XBO1OHi9GojHgOGw7V46DGX de/BS6iskM9gQnfDrdHjzG4mi4aQBOC5HguEkLHuomkhX6N0kordNQlWGky/OwvcKisN iP0OG97pozmINDmZ8dHhnrLnq4o534AgT29943ny4cLzpbvknbksrSq+f82ZoOIHFO7I vu+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690196068; x=1690800868; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=jm2AmYXeSq7Hv1D3EYH8vxoR54aZLC/z7y6TUDXlfXw=; b=dSvhFHEwvlz2I0V269xO062qdp8QOI2MzyVlgYj3efoQaUvETQ1eusOnVd8RhJyuDK 4slC2GKD02JoDQ7MCTBWXKlaG2KednNL13hU0EGxV3EUl/L98U4S2iRRVpa4b0NH6O09 y8EHRROeNuq77Hch3YVyOapK8ptr06cObWiAIx3MVRQ9uAHlam5eQ7NbLiuRuNjKExhq ECJ6W9JJPPMiNB6TqrSnAfnk8H0MReI3RbzISD+T15GnuoghloOWnOv21z33sCj7kVhv WdMZ1LmZOLbcI84jkiZNoVl4puK9LuRM0e68DQXD49gyIhNP4n8omuPc85QeV962xOe7 Uw1g== X-Gm-Message-State: ABy/qLaTscQvWstrY4BOU4IeHt9qbUgAVP2F/z8OZa/hX18dvUgtPNLo PzBfanXjIuiZrMKLN0+wSX4= X-Received: by 2002:a5d:5909:0:b0:317:60ae:2ef5 with SMTP id v9-20020a5d5909000000b0031760ae2ef5mr1036070wrd.31.1690196068041; Mon, 24 Jul 2023 03:54:28 -0700 (PDT) Received: from localhost.localdomain (93-34-89-13.ip49.fastwebnet.it. [93.34.89.13]) by smtp.googlemail.com with ESMTPSA id j6-20020adfff86000000b0031274a184d5sm12529631wrr.109.2023.07.24.03.54.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jul 2023 03:54:27 -0700 (PDT) From: Christian Marangi To: Andrew Lunn , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Marangi , Atin Bainada , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Mark Brown , stable@vger.kernel.org Subject: [net PATCH 1/4] net: dsa: qca8k: enable use_single_write for qca8xxx Date: Mon, 24 Jul 2023 05:25:28 +0200 Message-Id: <20230724032531.15998-1-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00,DATE_IN_PAST_06_12, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no 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 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772299841316740511 X-GMAIL-MSGID: 1772299841316740511 The qca8xxx switch supports 2 way to write reg values, a slow way using mdio and a fast way by sending specially crafted mgmt packet to read/write reg. The fast way can support up to 32 bytes of data as eth packet are used to send/receive. This correctly works for almost the entire regmap of the switch but with the use of some kernel selftests for dsa drivers it was found a funny and interesting hw defect/limitation. For some specific reg, bulk write won't work and will result in writing only part of the requested regs resulting in half data written. This was especially hard to track and discover due to the total strangeness of the problem and also by the specific regs where this occurs. This occurs in the specific regs of the ATU table, where multiple entry needs to be written to compose the entire entry. It was discovered that with a bulk write of 12 bytes on QCA8K_REG_ATU_DATA0 only QCA8K_REG_ATU_DATA0 and QCA8K_REG_ATU_DATA2 were written, but QCA8K_REG_ATU_DATA1 was always zero. Tcpdump was used to make sure the specially crafted packet was correct and this was confirmed. The problem was hard to track as the lack of QCA8K_REG_ATU_DATA1 resulted in an entry somehow possible as the first bytes of the mac address are set in QCA8K_REG_ATU_DATA0 and the entry type is set in QCA8K_REG_ATU_DATA2. Funlly enough writing QCA8K_REG_ATU_DATA1 results in the same problem with QCA8K_REG_ATU_DATA2 empty and QCA8K_REG_ATU_DATA1 and QCA8K_REG_ATU_FUNC correctly written. A speculation on the problem might be that there are some kind of indirection internally when accessing these regs and they can't be accessed all together, due to the fact that it's really a table mapped somewhere in the switch SRAM. Even more funny is the fact that every other reg was tested with all kind of combination and they are not affected by this problem. Read operation was also tested and always worked so it's not affected by this problem. The problem is not present if we limit writing a single reg at times. To handle this hardware defect, enable use_single_write so that bulk api can correctly split the write in multiple different operation effectively reverting to a non-bulk write. Cc: Mark Brown Fixes: c766e077d927 ("net: dsa: qca8k: convert to regmap read/write API") Signed-off-by: Christian Marangi Cc: stable@vger.kernel.org --- drivers/net/dsa/qca/qca8k-8xxx.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/dsa/qca/qca8k-8xxx.c b/drivers/net/dsa/qca/qca8k-8xxx.c index dee7b6579916..ae088a4df794 100644 --- a/drivers/net/dsa/qca/qca8k-8xxx.c +++ b/drivers/net/dsa/qca/qca8k-8xxx.c @@ -576,8 +576,11 @@ static struct regmap_config qca8k_regmap_config = { .rd_table = &qca8k_readable_table, .disable_locking = true, /* Locking is handled by qca8k read/write */ .cache_type = REGCACHE_NONE, /* Explicitly disable CACHE */ - .max_raw_read = 32, /* mgmt eth can read/write up to 8 registers at time */ - .max_raw_write = 32, + .max_raw_read = 32, /* mgmt eth can read up to 8 registers at time */ + /* ATU regs suffer from a bug where some data are not correctly + * written. Disable bulk write to correctly write ATU entry. + */ + .use_single_write = true, }; static int