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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <bb58ac4d0905060526h1afff3co7adbaeebde7b7f4e@mail.gmail.com>
Date:	Wed, 6 May 2009 17:56:14 +0530
From:	Upakul Barkakaty <upakul@...il.com>
To:	Lennert Buytenhek <buytenh@...tstofly.org>
Cc:	netdev@...r.kernel.org
Subject: Re: mv643xx_eth: Delay required in reading the PHY registers.

Thanks Lennert for the reply. Appreciate it.

On Wed, May 6, 2009 at 5:48 PM, Lennert Buytenhek
<buytenh@...tstofly.org> wrote:
> 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.
>



-- 
Regards,
Upakul Barkakaty
--
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