netdev - 回覆: [PATCH net v2] net: mdio: aspeed: Add dummy read for fire control

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:
 <SEYPR06MB5134244189AF9C4F78B368229D212@SEYPR06MB5134.apcprd06.prod.outlook.com>
Date: Wed, 20 Nov 2024 05:45:31 +0000
From: Jacky Chou <jacky_chou@...eedtech.com>
To: Andrew Jeffery <andrew@...econstruct.com.au>, "andrew@...n.ch"
	<andrew@...n.ch>, "hkallweit1@...il.com" <hkallweit1@...il.com>,
	"linux@...linux.org.uk" <linux@...linux.org.uk>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"joel@....id.au" <joel@....id.au>, "f.fainelli@...il.com"
	<f.fainelli@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject:
 回覆: [PATCH net v2] net: mdio: aspeed: Add dummy read for fire control

Hi Andrew Jeffery,

Thank you for your reply.

> > When the command bus is sometimes busy, it may cause the command is
> > not arrived to MDIO controller immediately. On software, the driver
> > issues a write command to the command bus does not wait for command
> > complete and it returned back to code immediately. But a read command
> > will wait for the data back, once a read command was back indicates
> > the previous write command had arrived to controller.
> > Add a dummy read to ensure triggering mdio controller before starting
> > polling the status of mdio controller to avoid polling unexpected
> > timeout.
> 
> Why use the explicit dummy read rather than adjust the poll interval or
> duration? I still don't think that's been adequately explained given the
> hardware-clear of the fire bit on completion, which is what we're polling for.

We cannot know exactly what the timeout value of polling should be set to.
Because no one could know when the write command has arrived MDIO controller.

A dummy read can ensure the previous write command had arrived MDIO controller
Therefore, we chose to use a dummy read instead of increasing the timeout value.

Thanks,
Jacky