netdev - Re: mv643xx_eth: Delay required in reading the PHY registers.

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090506121834.GA32010@mail.wantstofly.org>
Date:	Wed, 6 May 2009 14:18:34 +0200
From:	Lennert Buytenhek <buytenh@...tstofly.org>
To:	Upakul Barkakaty <upakul@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: mv643xx_eth: Delay required in reading the PHY registers.

On Wed, May 06, 2009 at 11:08:07AM +0530, Upakul Barkakaty wrote:

> I am using the Marvell ethernet driver[mv643xx_eth]. The function
> eth_port_read_smi_reg(), uses a delay in order to wait for the SMI
> register to become available.
> 
> Does anyone have any clue how much time it actually takes for the SMI
> register to become available? Actually I am using an older version of
> the driver which does not use the udelay functions in the loops. It
> rather has a "for" loop for putting a timeout. Now the gcc-4.3.1
> compiler optimizes out the "for" loop. So I need to replace the "for"
> loop with a delay function. Now the question is "how much delay would
> be appropriate".
> 
> Any replies in this regard would be appreciated.

You sent me the same question in private mail -- I wonder how many
other people you've sent this question to.

As I told you in private mail as well, any recent version of the driver
will wait for SMI completion by waiting for the appropriate interrupt.
If you really cannot use that option, then even though the transaction
is on the order of tens of microseconds, I would still try to go to
sleep at least for a little bit (say, msleep(10)) as SMI accesses aren't
in a critical path and not busy-waiting while sucking up CPU is more
important than getting the access done as quick as you can.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html