From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0327AC4320A for ; Fri, 27 Aug 2021 22:25:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CA5D360F91 for ; Fri, 27 Aug 2021 22:24:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232167AbhH0WZp (ORCPT ); Fri, 27 Aug 2021 18:25:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232101AbhH0WZo (ORCPT ); Fri, 27 Aug 2021 18:25:44 -0400 Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36990C061796 for ; Fri, 27 Aug 2021 15:24:55 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id b4so17270473lfo.13 for ; Fri, 27 Aug 2021 15:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FpMQnWS/Idb7V4cplerWRjPC6X8Jz7LmylkwVXp0j6I=; b=ZpHX8TeYsHErvM6bpNGzQ2sOfpkfHyZaLiKvIG/qqAcbwr8BkRIh5FMx0vfgBq77ba mYSFFH44ORsKFpst9S9OpHMEi+mfYaG30hA/NVavodJ1+IfgtNrKg/PeVoguTwWjUhOS s5yboYNlnIa+RopfDKFwAW+xvljhaQXXKNctpnDqrrcAdYH6HTgb/U5YqG1WgvaOVjp2 kDaVirJj6fz6RzlbaT0pCOmDAi0S8NhXkZAMBjcd2LXFK+q/A15A43xCjB/XrEYnwKSF 1nCRPXi14H3ajDpLEpCa1iyiDZjOq4QtQn+2nwLdAvtBphjQ4NAhM27IzT5IjMVUKt8f ZxSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FpMQnWS/Idb7V4cplerWRjPC6X8Jz7LmylkwVXp0j6I=; b=dUb2baD/DmLU/TBC06DYB+IFo4XMH3iBwmEjU2CzPswoYXucNMml7LzHtnItF3vtcb fvXUHYskTEpgHioElAlrlUc7ZAA/iART9gU4+1OgZZ9uMP0cw2Fkv4HzHT1enGMuBYTf au2QMCfLlVMK0v2S/CwdBdall48uaJyXq54Pcms1PIpjJH+4MhvX/flxnKIXH5lGxqeC 2aGzMTP79jFyNIl22VKsorxftOW2Bbu5nSJ3v3BhuJxa1rHi25h/eZUzx8NDcN9P0PLR Z1OkG8BDRi9/sNyurtC7If2sZCKWIP0NdVD4iG1YFRrlArKULdBGQheZocUI/J8E+QMS Kesg== X-Gm-Message-State: AOAM530MeIT1IdxbKG6V+i9IL6HSgZnxpVpcVNAykxwHQySAchgz/MDe oyPza2rPdCMo4v8AeYSF0g2VLJM5V78E248amAH28g== X-Google-Smtp-Source: ABdhPJzY2a0iBh2SUwgB961qSHcMc6KG1k/nbmyRlu/YhfENDRRGN3HSBgvzlDdumO1AGXZZQB9r80OhSTuE25v5UGo= X-Received: by 2002:ac2:5d4a:: with SMTP id w10mr8503419lfd.529.1630103093434; Fri, 27 Aug 2021 15:24:53 -0700 (PDT) MIME-Version: 1.0 References: <20210822193145.1312668-1-alvin@pqrs.dk> <20210822193145.1312668-5-alvin@pqrs.dk> <20210822224805.p4ifpynog2jvx3il@skbuf> In-Reply-To: From: Linus Walleij Date: Sat, 28 Aug 2021 00:24:42 +0200 Message-ID: Subject: Re: [RFC PATCH net-next 4/5] net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC To: =?UTF-8?Q?Alvin_=C5=A0ipraga?= Cc: Vladimir Oltean , =?UTF-8?Q?Alvin_=C5=A0ipraga?= , Andrew Lunn , Vivien Didelot , Florian Fainelli , "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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 23, 2021 at 1:56 AM Alvin =C5=A0ipraga w= rote: > On 8/23/21 12:48 AM, Vladimir Oltean wrote: > > On Sun, Aug 22, 2021 at 09:31:42PM +0200, Alvin =C5=A0ipraga wrote: > >> +static int rtl8365mb_enable_vlan(struct realtek_smi *smi, bool enable= ) > >> +{ > >> + dev_dbg(smi->dev, "%s VLAN\n", enable ? "enable" : "disable"); > >> + return regmap_update_bits( > >> + smi->map, RTL8365MB_VLAN_CTRL_REG, RTL8365MB_VLAN_CTRL_EN= _MASK, > >> + FIELD_PREP(RTL8365MB_VLAN_CTRL_EN_MASK, enable ? 1 : 0)); > >> +} > >> + > >> +static int rtl8365mb_enable_vlan4k(struct realtek_smi *smi, bool enab= le) > >> +{ > >> + return rtl8365mb_enable_vlan(smi, enable); > >> +} > > > > I'm not going to lie, the realtek_smi_ops VLAN methods seem highly > > cryptic to me. Why do you do the same thing from .enable_vlan4k as from > > .enable_vlan? What are these supposed to do in the first place? > > Or to quote from rtl8366_vlan_add: "what's with this 4k business?" > > I think realtek-smi was written with rtl8366rb.c in mind, which appears > to have different control registers for VLAN and VLAN4k modes, whatever > that's supposed to mean. Since the RTL8365MB doesn't distinguish between > the two, I just route one to the other. The approach is one of caution, > since I don't want to break the other driver (I don't have hardware to > test for regressions). Maybe Linus can chime in? Sigh, I have zero documentation, I just mimic what the code dump from Realtek does. But my interpretation is that the RTL8366RB can operate with either 16 or 4096 VLAN (VID) member entries. (Called "mc", member configs) The support for 4096 "4k" entries need to be enabled explicitly, in succession after enabling the 16 entries, and this is what the code in rtl8366.c does, and we always enable all 4096 "mc:s" of course. I guess some older switch only supported 16 members and this is a hardware compatibility mode. Yours, Linus Walleij