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;
From:   DENG Qingfang <dqfext@gmail.com>
To:     Alvin =?utf-8?Q?=C5=A0ipraga?= <alvin@pqrs.dk>
Cc:     Linus Walleij <linus.walleij@linaro.org>,
        Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        Alvin =?utf-8?Q?=C5=A0ipraga?= <alsi@bang-olufsen.dk>,
        Michael Rasmussen <mir@bang-olufsen.dk>,
        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 17:55:05 +0800
Message-Id: <20211013095505.55966-1-dqfext@gmail.com>
In-Reply-To: <20211012123557.3547280-6-alvin@pqrs.dk>
References: <20211012123557.3547280-1-alvin@pqrs.dk> <20211012123557.3547280-6-alvin@pqrs.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Tue, Oct 12, 2021 at 02:35:54PM +0200, Alvin Šipraga wrote:
> +/* Port mapping macros
> + *
> + * PORT_NUM_x2y: map a port number from domain x to domain y
> + * PORT_MASK_x2y: map a port mask from domain x to domain y
> + *
> + * L = logical port domain, i.e. dsa_port.index
> + * P = physical port domain, used by the Realtek ASIC for port indexing;
> + *     for ports with internal PHYs, this is also the PHY index
> + * E = extension port domain, used by the Realtek ASIC for managing EXT ports
> + *
> + * The terminology is borrowed from the vendor driver. The extension port domain
> + * is mostly used to navigate the labyrinthine layout of EXT port configuration
> + * registers and is not considered intuitive by the author.
> + *
> + * Unless a function is accessing chip registers, it should be using the logical
> + * port domain. Moreover, function arguments for port numbers and port masks
> + * must always be in the logical domain. The conversion must be done as close as
> + * possible to the register access to avoid chaos.
> + *
> + * The mappings vary between chips in the family supported by this driver. Here
> + * is an example of the mapping for the RTL8365MB-VC:
> + *
> + *    L | P | E | remark
> + *   ---+---+---+--------
> + *    0 | 0 |   | user port
> + *    1 | 1 |   | user port
> + *    2 | 2 |   | user port
> + *    3 | 3 |   | user port
> + *    4 | 6 | 1 | extension (CPU) port
> + *
> + * NOTE: Currently this is hardcoded for the RTL8365MB-VC. This will probably
> + * require a rework when adding support for other chips.
> + */
> +#define CPU_PORT_LOGICAL_NUM	4
> +#define CPU_PORT_LOGICAL_MASK	BIT(CPU_PORT_LOGICAL_NUM)
> +#define CPU_PORT_PHYSICAL_NUM	6
> +#define CPU_PORT_PHYSICAL_MASK	BIT(CPU_PORT_PHYSICAL_NUM)
> +#define CPU_PORT_EXTENSION_NUM	1
> +
> +static u32 rtl8365mb_port_num_l2p(u32 port)
> +{
> +	return port == CPU_PORT_LOGICAL_NUM ? CPU_PORT_PHYSICAL_NUM : port;
> +}
> +
> +static u32 rtl8365mb_port_mask_l2p(u32 mask)
> +{
> +	u32 phys_mask = mask & ~CPU_PORT_LOGICAL_MASK;
> +
> +	if (mask & CPU_PORT_LOGICAL_MASK)
> +		phys_mask |= CPU_PORT_PHYSICAL_MASK;
> +
> +	return phys_mask;
> +}
> +
> +static u32 rtl8365mb_port_mask_p2l(u32 phys_mask)
> +{
> +	u32 mask = phys_mask & ~CPU_PORT_PHYSICAL_MASK;
> +
> +	if (phys_mask & CPU_PORT_PHYSICAL_MASK)
> +		mask |= CPU_PORT_LOGICAL_MASK;
> +
> +	return mask;
> +}
> +
> +#define PORT_NUM_L2P(_p) (rtl8365mb_port_num_l2p(_p))
> +#define PORT_NUM_L2E(_p) (CPU_PORT_EXTENSION_NUM)
> +#define PORT_MASK_L2P(_m) (rtl8365mb_port_mask_l2p(_m))
> +#define PORT_MASK_P2L(_m) (rtl8365mb_port_mask_p2l(_m))

The whole port mapping thing can be avoided if you just use port 6 as the CPU
port.

> +
> +/* Chip-specific data and limits */