lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 13 Oct 2021 17:55:05 +0800
From:   DENG Qingfang <dqfext@...il.com>
To:     Alvin Šipraga <alvin@...s.dk>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Alvin Šipraga <alsi@...g-olufsen.dk>,
        Michael Rasmussen <mir@...g-olufsen.dk>,
        netdev@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 5/6] net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC

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 */

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ