[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SEZPR06MB6959D1466670252F024425EB964C2@SEZPR06MB6959.apcprd06.prod.outlook.com>
Date: Fri, 16 Feb 2024 22:29:54 +0800
From: Yang Xiwen <forbidden405@...look.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Yisen Zhuang <yisen.zhuang@...wei.com>,
Salil Mehta <salil.mehta@...wei.com>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>, Yang Xiwen <forbidden405@...mail.com>,
Heiner Kallweit <hkallweit1@...il.com>, Russell King
<linux@...linux.org.uk>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 4/6] dt-bindings: net: add hisilicon-femac
On 2/16/2024 10:10 PM, Andrew Lunn wrote:
>> I've tried accessing MDIO address space and MAC controller address space in
>> u-boot with `md` and `mw` [1]. From the result, i guess the CLK_BUS is the
>> System Bus clock (AHB Bus clock), and the CLK_MAC is the clock shared by
>> both MDIO bus and MAC. The MAC has a internal clock divider to divide the
>> input clock(54MHz in common) to a configurable variable rate.
> In general, sharing a clock is not a problem. The clock API does
> reference counting. So if two consumers enable the clock, it will not
> be disabled until two consumes disable the clock. So it should not be
> an issue for both the MAC and the MDIO driver to consume the clock.
>
> However, the funny PHY reset code is going to be key here. We need to
> understand that in more detail.
I don't know about details too much, either. All the resources i have is
a brief TRM and the downstream linux kernel code[1], U-Boot code[2]. The
idea of managing all clocks and resets in MAC driver is taken from
hix5hd2_gmac.c(in the same directory).
>
> Talking about details, you commit messages need improving. The commit
> message is your chance to answer all the reviewers questions before
> they even ask them. Removing a binding was always going to need
> justification, so you needed to have that in the commit message. In
> order to review a DT bindings, having an overview of what the hardware
> actually looks like is needed. So that is something which you can add
> to the commit messages.
Thanks for your comment. Also sorry for the inconvenience I brought.
>
> Please take a look at your patches from the perspective of a reviewer,
> somebody how knows nothing about this device. What information is
> needed to understand the patches?
Will rewrite commit logs in next version.
>
> Andrew
[1]:
https://github.com/JasonFreeLab/HiSTBLinuxV100R005C00SPC050/blob/fd20f78ab02934e71474dbb1d933c6ec911b01c9/source/kernel/linux-4.4.y/drivers/net/ethernet/hieth/hieth.c#L1281
[2]:
https://github.com/JasonFreeLab/HiSTBLinuxV100R005C00SPC050/blob/fd20f78ab02934e71474dbb1d933c6ec911b01c9/source/boot/fastboot/drivers/net/hisfv300/sys.c#L50
--
Regards,
Yang Xiwen
Powered by blists - more mailing lists