Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3297341pxb; Wed, 13 Oct 2021 03:15:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwzjgAvrWjGymEVORMxtQa+tTtiIJF8uA3FoNy0/iI9GKIq8lYgqCTA8jWU6CPzAAjSjDGZ X-Received: by 2002:a17:90a:df13:: with SMTP id gp19mr10310602pjb.151.1634120112468; Wed, 13 Oct 2021 03:15:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634120112; cv=none; d=google.com; s=arc-20160816; b=OIiCvub+swggRk8zk777OmzQjKs33xeLXQM+O0xOrKEDWqDfrBSAOCcaqWj04eR49W k4qNgKuoqjjMn2qZbOpLIIS5/uk4qwlcH3qlD0cbbbU7J+DyLQScU+Kpa9erCZ4Nr2Sy j05PsKBw4V6jFSZ06k6QqSvtHeaKenDfoppdOQBrf8M2hIGsQIDAu2qmF4IJq+NRyqn3 B01RO9gDUHHxlz7mn2EaJNkSipYYNEjRw+xJJ9jC3pbNz2TuG+0rkaz37DIZM9VncPew ez+a7+UYR/Gjb2u6YAbaoijcFyXHJ9QB4GtosIlLRut3HR2cIFNdUJeTbITEt0B9lBUS Bl8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-disposition :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=1dUeTZLXCuNXDhj8msmYssPF3RGBm/4w14GViom8/z8=; b=sS5L9yxvbqo9yrTp5/gyc7SiTufrUJx8MTipNiZFvxt2UK4HTT9FtliLQPBoBkSphV X2ymt9UTD11T+EprG9eidAed1U1Wz/c40MUH8HIXnjQhRJZcfoZEVH5MmMyCOU9fSBWC DGbB04VN3hKbVUNSxXwBtH2HN3ltrtOH+j8HDyFI6naVZ9zM+BxM1LX3kp8pxqOVtEbE rR4rt19By40kdZ1uUicRp4wr7YI4EGcxz9fr34IGfP9QHgbe1eDggVPrK+eQLnO1lrnp AwoPKJkXyVu0IJ2XIjDxS9Xxn6s6ENDeJa8xy5uNyWIrv1BYhESp9LPjsjfbFkJxNcNP kEcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=E5P+abuu; 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 i6si4022904plr.36.2021.10.13.03.14.58; Wed, 13 Oct 2021 03:15: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=20210112 header.b=E5P+abuu; 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 S239257AbhJMKPy (ORCPT + 99 others); Wed, 13 Oct 2021 06:15:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46566 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237525AbhJMKPx (ORCPT ); Wed, 13 Oct 2021 06:15:53 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB5FEC061570; Wed, 13 Oct 2021 03:13:50 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id ls18so1812265pjb.3; Wed, 13 Oct 2021 03:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-disposition:content-transfer-encoding; bh=1dUeTZLXCuNXDhj8msmYssPF3RGBm/4w14GViom8/z8=; b=E5P+abuumiIOCiu+ElUEX2ETeN6nH/SD0vtRth4wjleHKZv0MBERHK6yLO8UtObpBJ 950msUkL69OFeoJpmdS6V2HkJiDagXtOYfN/mlirF7dfy++1MF6V6zewRitwv65inEJS nJvk/R4W6sUMDZODcvri7B5eVwLzxrq22iNnWlcAg0JWFFZYA54KudHI0vtoO+7UAM6v DPVjCJMdGXT4UgaObzScpHIMJhaNyB5+6daiPba5bDzHxSRNr9T2Tvwggv/OVXF51MJk RMRuto6NRST/UL3FsCxjpc00IZFqsRFD1xBnoodIpTDCIPZAS5yNMpCFygubXiYpbyzK 5j2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-disposition :content-transfer-encoding; bh=1dUeTZLXCuNXDhj8msmYssPF3RGBm/4w14GViom8/z8=; b=B5eNHjhBBtn0zL9ajqHSyloMOGXoosiccu3w7SOvvSWG22lL4RBZw0ulTl83Yj3DYC qfbFBkjfarCb7TdGEAWCcJ3BXWfcmlAWBaFx9ZjiAMNA4slm7d3vtg0rmw7FBFkiPMDx 9aQNgVmnN4dRfWMnsduraUhii3aZ7tI4cVJyFnxh/TJImOV02u5a8TyE9xDBr6Q69GqJ SLEqzbcJdZljpogYTL0k5BwVuXG7BgXCGTEDi6aGENNpQI2DQMCJqtFJL+YZ2SC42Yuj EKLtVHhrnpx5bFewMP3FgoCCEkse7d11YIWEymcHq45kcr7xIXo0BxIPpwO+T/BmKNNs RCzA== X-Gm-Message-State: AOAM531LEAH7D1KwlBmt6rrCqQ/Utlp+Lg8FKsUg3aVu71MNMZuMxVdc sg7by4g1dErdfOp5QlUU/UU= X-Received: by 2002:a17:90b:3749:: with SMTP id ne9mr12487858pjb.192.1634120030029; Wed, 13 Oct 2021 03:13:50 -0700 (PDT) Received: from localhost.localdomain ([171.211.26.24]) by smtp.gmail.com with ESMTPSA id a11sm14018427pgj.75.2021.10.13.03.13.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 03:13:49 -0700 (PDT) From: DENG Qingfang To: Alvin =?utf-8?Q?=C5=A0ipraga?= Cc: Alvin =?utf-8?Q?=C5=A0ipraga?= , Linus Walleij , Andrew Lunn , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Rob Herring , Heiner Kallweit , Russell King , Michael Rasmussen , "netdev@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH net-next 5/6] net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC Date: Wed, 13 Oct 2021 18:13:41 +0800 Message-Id: <20211013101341.56223-1-dqfext@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <32ffccb4-ff8b-5e60-ad29-e32bcb22969f@bang-olufsen.dk> References: <20211012123557.3547280-1-alvin@pqrs.dk> <20211012123557.3547280-6-alvin@pqrs.dk> <20211013095505.55966-1-dqfext@gmail.com> <32ffccb4-ff8b-5e60-ad29-e32bcb22969f@bang-olufsen.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 13, 2021 at 10:05:21AM +0000, Alvin Šipraga wrote: > Andrew also suggested this, but the discontinuity in port IDs seems to > be an invitation for trouble. Here is an example of a series of > functions from dsa.h: > > static inline struct dsa_port *dsa_to_port(struct dsa_switch *ds, int p) > { > struct dsa_switch_tree *dst = ds->dst; > struct dsa_port *dp; > > list_for_each_entry(dp, &dst->ports, list) > if (dp->ds == ds && dp->index == p) > return dp; > > return NULL; > } > > static inline bool dsa_is_user_port(struct dsa_switch *ds, int p) > { > return dsa_to_port(ds, p)->type == DSA_PORT_TYPE_USER; > } > > static inline u32 dsa_user_ports(struct dsa_switch *ds) > { > u32 mask = 0; > int p; > > for (p = 0; p < ds->num_ports; p++) > if (dsa_is_user_port(ds, p)) > mask |= BIT(p); > > return mask; > } > > My reading of dsa_user_ports() is that the port IDs run from 0 to > (ds->num_ports - 1). If num_ports is 5 (4 user ports and 1 CPU port, as > in my case), but the CPU is port 6, will we not dereference NULL when > calling dsa_is_user_port(ds, 4)? So set num_ports to 7. > > > > >> + > >> +/* Chip-specific data and limits */ >