netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Daniel Golle <daniel@makrotopia.org>
Cc: netdev@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	"Russell King" <linux@armlinux.org.uk>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Lorenzo Bianconi" <lorenzo@kernel.org>,
	"Mark Lee" <Mark-MC.Lee@mediatek.com>,
	"John Crispin" <john@phrozen.org>, "Felix Fietkau" <nbd@nbd.name>,
	"AngeloGioacchino Del Regno"
	<angelogioacchino.delregno@collabora.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"DENG Qingfang" <dqfext@gmail.com>,
	"Landen Chao" <Landen.Chao@mediatek.com>,
	"Sean Wang" <sean.wang@mediatek.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"Florian Fainelli" <f.fainelli@gmail.com>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Jianhui Zhao" <zhaojh329@gmail.com>,
	"Bjørn Mork" <bjorn@mork.no>
Subject: Re: [PATCH v2 03/11] dt-bindings: arm: mediatek: add 'mediatek,pn_swap' property
Date: Thu, 9 Feb 2023 12:30:27 +0100	[thread overview]
Message-ID: <c29a3a22-cc23-35bf-c8e0-ebe1405a4d94@kernel.org> (raw)
In-Reply-To: <Y+QinJ9W8hIIF9Ni@makrotopia.org>

On 08/02/2023 23:30, Daniel Golle wrote:
> Hi Krzysztof,
> 
> thank you for taking the time to review and explain.
> 
> On Wed, Feb 08, 2023 at 09:08:40PM +0100, Krzysztof Kozlowski wrote:
>> On 08/02/2023 14:51, Daniel Golle wrote:
>>> On Wed, Feb 08, 2023 at 10:32:53AM +0100, Krzysztof Kozlowski wrote:
>>>> On 07/02/2023 19:00, Daniel Golle wrote:
>>>>> ...
>>>>>> 3. Does not look like property of this node. This is a clock controller
>>>>>> or system controller, not SGMII/phy etc.
>>>>>
>>>>> The register range referred to by this node *does* represent also an
>>>>> SGMII phy. These sgmiisys nodes also carry the 'syscon' compatible, and
>>>>> are referenced in the node of the Ethernet core, and then used by
>>>>> drivers/net/ethernet/mediatek/mtk_sgmii.c using syscon_node_to_regmap.
>>>>> (This is the current situation already, and not related to the patchset
>>>>> now adding only a new property to support hardware which needs that)
>>>>
>>>> Just because a register is located in syscon block, does not mean that
>>>> SGMII configuration is a property of this device.
>>>
>>> It's not just one register, the whole SGMII PCS is located in those
>>> mediatek,sgmiisys syscon nodes.
>>
>> Then maybe this should be a PCS PHY device instead of adding properties
>> unrelated to clock/system controller? I don't know, currently this
>> binding says it is a provider of clocks...
> 
> As in reality it is really a clock provider and also SGMII PCS at the
> same time, maybe we should just update the description of the binding
> to match that:
> 
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
> index d2c24c2775141..db6f75df200ba 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
> @@ -2,6 +2,7 @@ MediaTek SGMIISYS controller
>  ============================
>  
>  The MediaTek SGMIISYS controller provides various clocks to the system.
> +It also represents the SGMII PCS used by the Ethernet core.
>  
>  Required Properties:
>  
> 
> See
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mediatek/mtk_sgmii.c#n179
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt7986a.dtsi#n409

But it is not used as phy or PCS. It is used as syscon. If it was a phy
or PCS, then the property probably belonged here, but bindings and Linux
implementation were created in different way, so it is not a phy or PCS,
just a syscon.

>>>>> So: Should I introduce a new binding for the same compatible strings
>>>>> related to the SGMII PHY features? Or is it fine in this case to add
>>>>> this property to the existing binding?
>>>>
>>>> The user of syscon should configure it. I don't think you need new
>>>> binding. You just have to update the user of this syscon.
>>>
>>> Excuse my confusion, but it's still not entirely clear to me.
>>> So in this case I should add the description of the added propterty of
>>> the individual SGMII units (there can be more than one) to
>>> Documentation/devicetree/bindings/net/mediatek,net.yaml
>>> eventhough the properties are in the sgmiisys syscon nodes?
>>
>> I guess the property should be in the node representing the SGMII. You
>> add it now to the clock (or system) controller, so it does not look
>> right. It's not a property of a clock controller.
> 
> Well maybe this node needs to be split then into one node representing
> only the clock controller and another node representing the SGMII PCS?
> I'm not sure if this is even possible, some registers in this range
> represent clocks, other registers are accessed using regmap API in
> mtk_sgmii.c.

This can be the same node, but it must be used like PCS. syscon phandle
for getting regmap is something entirely else.

> 
> And (see the rest of this series) the exact same SGMII PCS can also be
> found in MT7531 switch IC which has it's own (a bit odd) way to access
> 32-bit registers over MDIO, also in this case it is simply not easily
> possible to represent the SGMII PCS in device tree.
> 
>>
>> Now which node should have this property depends on your devices - which
>> I have no clue about, I read what is in the bindings.
> 
> There isn't any other node exclusively representing the SGMII PCS.
> I guess the only other option would be to move the property to the
> Ethernet controller node, which imho complicates things as it is
> really a property of an individual SGMII PHY (of which there can be
> more than one).
> 
>>
>>>
>>> If so I will have to figure out how to describe properties of other
>>> nodes in the binding of the node referencing them. Are there any
>>> good examples for that?
>>
>> phys and pcs'es?
> 
> Hm, none of the current PCS (or PHY) drivers are represented by a
> syscon node... (and maybe that's the mistake in first place?)

Yes.


Best regards,
Krzysztof


  reply	other threads:[~2023-02-09 11:52 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 14:18 [PATCH v2 00/11] net: ethernet: mtk_eth_soc: various enhancements Daniel Golle
2023-02-07 14:18 ` [PATCH v2 01/11] net: ethernet: mtk_eth_soc: add support for MT7981 SoC Daniel Golle
2023-02-07 14:19 ` [PATCH v2 02/11] dt-bindings: net: mediatek,net: add mt7981-eth binding Daniel Golle
2023-02-07 17:36   ` Krzysztof Kozlowski
2023-02-07 14:19 ` [PATCH v2 03/11] dt-bindings: arm: mediatek: add 'mediatek,pn_swap' property Daniel Golle
2023-02-07 17:38   ` Krzysztof Kozlowski
2023-02-07 18:00     ` Daniel Golle
2023-02-08  9:32       ` Krzysztof Kozlowski
2023-02-08 13:51         ` Daniel Golle
2023-02-08 20:08           ` Krzysztof Kozlowski
2023-02-08 22:30             ` Daniel Golle
2023-02-09 11:30               ` Krzysztof Kozlowski [this message]
2023-02-10 10:34                 ` Russell King (Oracle)
2023-02-10 12:23                   ` Russell King (Oracle)
2023-02-10 12:35                     ` Krzysztof Kozlowski
2023-02-10 10:30     ` Russell King (Oracle)
2023-02-07 14:20 ` [PATCH v2 04/11] net: ethernet: mtk_eth_soc: set MDIO bus clock frequency Daniel Golle
2023-02-07 17:07   ` Andrew Lunn
2023-02-07 14:21 ` [PATCH v2 05/11] net: ethernet: mtk_eth_soc: reset PCS state Daniel Golle
2023-02-10 10:36   ` Russell King (Oracle)
2023-02-07 14:21 ` [PATCH v2 06/11] net: ethernet: mtk_eth_soc: only write values if needed Daniel Golle
2023-02-10 10:38   ` Russell King (Oracle)
2023-02-07 14:22 ` [PATCH v2 07/11] net: ethernet: mtk_eth_soc: fix RX data corruption issue Daniel Golle
2023-02-07 14:22 ` [PATCH v2 08/11] net: ethernet: mtk_eth_soc: ppe: add support for flow accounting Daniel Golle
2023-02-07 14:23 ` [PATCH v2 09/11] net: pcs: add driver for MediaTek SGMII PCS Daniel Golle
2023-02-10 10:50   ` Russell King (Oracle)
2023-02-07 14:23 ` [PATCH v2 10/11] net: ethernet: mtk_eth_soc: switch to external PCS driver Daniel Golle
2023-02-07 14:30   ` Daniel Golle
2023-02-07 14:24 ` [PATCH v2 11/11] net: dsa: mt7530: use " Daniel Golle
2023-02-10 10:56   ` Russell King (Oracle)
2023-02-10 12:52     ` Daniel Golle
2023-02-10 22:17     ` Daniel Golle

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=c29a3a22-cc23-35bf-c8e0-ebe1405a4d94@kernel.org \
    --to=krzk@kernel.org \
    --cc=Landen.Chao@mediatek.com \
    --cc=Mark-MC.Lee@mediatek.com \
    --cc=andrew@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=bjorn@mork.no \
    --cc=daniel@makrotopia.org \
    --cc=davem@davemloft.net \
    --cc=dqfext@gmail.com \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=john@phrozen.org \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nbd@nbd.name \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=sean.wang@mediatek.com \
    --cc=zhaojh329@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).