netdev - Re: [PATCH 4/6] dt-bindings: net: add hisilicon-femac

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 16 Feb 2024 15:10:34 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Yang Xiwen <forbidden405@...look.com>
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

> 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.

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.

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?

       Andrew