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]
Message-ID: <3deb4ac9-558b-4ce5-912c-aa07797d2eda@lunn.ch>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ