All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alvin Šipraga" <alvin@pqrs.dk>
To: hauke@hauke-m.de, "Linus Walleij" <linus.walleij@linaro.org>,
	"Alvin Šipraga" <alsi@bang-olufsen.dk>,
	"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>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Russell King" <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH net-next v3 0/5] net: dsa: realtek: rtl8365mb: improve handling of PHY modes
Date: Thu, 16 Jun 2022 00:51:10 +0200	[thread overview]
Message-ID: <20220615225116.432283-1-alvin@pqrs.dk> (raw)

From: Alvin Šipraga <alsi@bang-olufsen.dk>

This series introduces some minor cleanup of the driver and improves the
handling of PHY interface modes to break the assumption that CPU ports
are always over an external interface, and the assumption that user
ports are always using an internal PHY.

Changes v2 -> v3:

 - rebased on net-next

 - no code change

 - patch 5: reworded the last paragraph based on Russel's feedback;
   hopefully it is clear now that my intent is just to fix the
   semantics, and that the new "feature" of treating ports with external
   interfaces as user ports, or ports with internal PHY as CPU ports, is
   just a side-effect of this fix - I make no claim as to the utility of
   such configurations and just note that they are permissible as far as
   the hardware is concerned

 - patch 5: added Luiz and Russel's Acked-by

Changes v1 -> v2:

 - patches 1-4: no code change

 - add Luiz' reviewed-by to some of the patches

 - patch 5: put the chip_infos into a static array and get rid of the
   switch in the detect function; also remove the macros for various
   chip ID/versions and embed them directly into the array

 - patch 5: use array of size 3 rather than flexible array for extints
   in the chip_info struct; gcc complained about initialization of
   flexible array members in a nested context, and anyway, we know that
   the max number of external interfaces is 3


Alvin Šipraga (5):
  net: dsa: realtek: rtl8365mb: rename macro RTL8367RB -> RTL8367RB_VB
  net: dsa: realtek: rtl8365mb: remove port_mask private data member
  net: dsa: realtek: rtl8365mb: correct the max number of ports
  net: dsa: realtek: rtl8365mb: remove learn_limit_max private data
    member
  net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly

 drivers/net/dsa/realtek/rtl8365mb.c | 299 ++++++++++++++++------------
 1 file changed, 177 insertions(+), 122 deletions(-)

-- 
2.36.1


             reply	other threads:[~2022-06-15 22:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-15 22:51 Alvin Šipraga [this message]
2022-06-15 22:51 ` [PATCH net-next v3 1/5] net: dsa: realtek: rtl8365mb: rename macro RTL8367RB -> RTL8367RB_VB Alvin Šipraga
2022-06-15 22:51 ` [PATCH net-next v3 2/5] net: dsa: realtek: rtl8365mb: remove port_mask private data member Alvin Šipraga
2022-06-15 22:51 ` [PATCH net-next v3 3/5] net: dsa: realtek: rtl8365mb: correct the max number of ports Alvin Šipraga
2022-06-15 22:51 ` [PATCH net-next v3 4/5] net: dsa: realtek: rtl8365mb: remove learn_limit_max private data member Alvin Šipraga
2022-06-15 22:51 ` [PATCH net-next v3 5/5] net: dsa: realtek: rtl8365mb: handle PHY interface modes correctly Alvin Šipraga
2022-06-17  3:50 ` [PATCH net-next v3 0/5] net: dsa: realtek: rtl8365mb: improve handling of PHY modes patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220615225116.432283-1-alvin@pqrs.dk \
    --to=alvin@pqrs.dk \
    --cc=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hauke@hauke-m.de \
    --cc=kuba@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.