public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Ante Knezic <ante.knezic@helmholz.de>
Cc: UNGLinuxDriver@microchip.com, andrew@lunn.ch,
	conor+dt@kernel.org, davem@davemloft.net,
	devicetree@vger.kernel.org, edumazet@google.com,
	f.fainelli@gmail.com, krzysztof.kozlowski+dt@linaro.org,
	kuba@kernel.org, linux-kernel@vger.kernel.org, marex@denx.de,
	netdev@vger.kernel.org, o.rempel@pengutronix.de,
	pabeni@redhat.com, robh+dt@kernel.org, woojung.huh@microchip.com
Subject: Re: [PATCH net-next v4 2/2] net:dsa:microchip: add property to select
Date: Mon, 23 Oct 2023 15:19:24 +0300	[thread overview]
Message-ID: <20231023121924.udseyuy7t77dscwl@skbuf> (raw)
In-Reply-To: <20231023072700.17060-1-ante.knezic@helmholz.de>

On Mon, Oct 23, 2023 at 09:27:00AM +0200, Ante Knezic wrote:
> As far as I am aware only the KSZ8863 and KSZ8873 have this property available,
> but the biggger issue might be in scaling this to port property as the register
> "Forward Invalid VID Frame and Host Mode" where the setting is applied is
> located under "Advanced Control Registers" section which is actually global at
> least looking from the switch point of view. Usually port properties are more
> applicable when registers in question are located under "Port Registers" section.
> This is somewhat similar to for example enabling the tail tag mode which is 
> again used only by the port 3 interface and is control from "Global Control 1"
> register.
> With this in mind - if you still believe we should move this to port dt 
> property, then should we forbid setting the property for any other port other 
> than port 3, and can/should this be enforced by the dt schema?

I have no doubt that RMII settings are port settings. Scaling up the implementation
to multiple ports on other switches doesn't mean that the DT binding shouldn't be
per port.

Anyway, the per-port access to a global switch setting is indeed a common theme
with the old Micrel switches. I once tried to introduce the concept of "wacky"
regmap regfields for that:
https://patchwork.kernel.org/project/netdevbpf/patch/20230316161250.3286055-3-vladimir.oltean@nxp.com/

but I don't have hardware to test and nobody who does picked up upon the regfield
idea, it seems.

  parent reply	other threads:[~2023-10-23 12:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-20 14:25 [PATCH net-next v4 0/2] net: dsa: microchip: enable setting rmii reference Ante Knezic
2023-10-20 14:25 ` [PATCH net-next v4 1/2] dt-bindings: net: microchip,ksz: document microchip,rmii-clk-internal Ante Knezic
2023-10-20 15:45   ` Conor Dooley
2023-10-20 14:25 ` [PATCH net-next v4 2/2] net: dsa: microchip: add property to select internal RMII reference clock Ante Knezic
2023-10-20 14:37   ` Vladimir Oltean
2023-10-23  7:27     ` [PATCH net-next v4 2/2] net:dsa:microchip: add property to select Ante Knezic
2023-10-23  7:58       ` Oleksij Rempel
2023-10-23  8:22         ` Ante Knezic
2023-10-23  8:41           ` Oleksij Rempel
2023-10-23  8:57             ` Ante Knezic
2023-10-23 11:49               ` Oleksij Rempel
2023-10-23 12:41                 ` Ante Knezic
2023-10-23 14:36                   ` Oleksij Rempel
2023-10-24  7:56                     ` Ante Knezic
2023-10-24 10:09                       ` Oleksij Rempel
2023-10-24 13:08                         ` Ante Knezic
2023-10-24 14:24                           ` Oleksij Rempel
2023-10-27  6:37                             ` Ante Knezic
2023-10-30 17:42                               ` Vladimir Oltean
2023-10-31  1:00                                 ` Andrew Lunn
2023-10-31  7:28                                   ` Oleksij Rempel
2023-11-02 10:44                                     ` Vladimir Oltean
2023-10-31  6:27                                 ` Oleksij Rempel
2023-10-23 12:19       ` Vladimir Oltean [this message]
2023-10-23 12:46         ` Ante Knezic

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=20231023121924.udseyuy7t77dscwl@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=ante.knezic@helmholz.de \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=robh+dt@kernel.org \
    --cc=woojung.huh@microchip.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox