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: Tue, 4 Jun 2024 11:13:50 +0200
From: Christophe ROULLIER <christophe.roullier@...s.st.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
CC: "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>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Alexandre Torgue
	<alexandre.torgue@...s.st.com>,
        Richard Cochran <richardcochran@...il.com>,
        Jose Abreu <joabreu@...opsys.com>, Liam Girdwood <lgirdwood@...il.com>,
        Mark
 Brown <broonie@...nel.org>, Marek Vasut <marex@...x.de>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 02/11] net: stmmac: dwmac-stm32: Separate out external
 clock rate validation


On 6/3/24 11:38, Russell King (Oracle) wrote:
> On Mon, Jun 03, 2024 at 11:27:48AM +0200, Christophe Roullier wrote:
>> +static int stm32mp1_validate_ethck_rate(struct plat_stmmacenet_data *plat_dat)
>> +{
>> +	struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
>> +	const u32 clk_rate = clk_get_rate(dwmac->clk_eth_ck);
>> +
>> +	switch (plat_dat->mac_interface) {
> Should these be phy_interface?

Hi,

The code is validating the clock frequency of clock that are INPUT into 
the MAC. These clock can be generated by either the PHY, or Xtal, or 
some other source, but they are still the clock which are INPUT into the 
MAC. Therefore I believe mac_interface is correct here.

> Does this clock depend on the interface
> mode used with the PHY?
>
I don't think the clock depend on the PHY mode. Look at 
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c :
"
458         plat->phy_interface = phy_mode;
459         rc = stmmac_of_get_mac_mode(np);
460         plat->mac_interface = rc < 0 ? plat->phy_interface : rc;
"
and this comment:
"
382 /**
383  * stmmac_of_get_mac_mode - retrieves the interface of the MAC
384  * @np: - device-tree node
385  * Description:
386  * Similar to `of_get_phy_mode()`, this function will retrieve (from
387  * the device-tree) the interface mode on the MAC side. This assumes
388  * that there is mode converter in-between the MAC & PHY
389  * (e.g. GMII-to-RGMII).
390  */
391 static int stmmac_of_get_mac_mode(struct device_node *np)
"
I think in the unlikely case that you would have a mode converter 
between the MAC and PHY, the clock that are validated by this code would 
still be the clock that are INPUT into the MAC, i.e. clock on the MAC 
side of the mode converter and NOT on the PHY side , and those clock 
would not depend on the PHY mode, they would depend on the MAC mode .

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ