netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Ivan Vecera <ivecera@redhat.com>
Cc: "Ben Hutchings" <bhutchings@solarflare.com>,
	"Francois Romieu" <romieu@fr.zoreil.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>,
	Netdev <netdev@vger.kernel.org>,
	"Edward Hsu" <edward_hsu@realtek.com.tw>
Subject: Re: [PATCH] r8169: read MAC address from EEPROM on init
Date: Thu, 25 Sep 2008 09:44:41 -0700	[thread overview]
Message-ID: <20080925094441.057b7723@extreme> (raw)
In-Reply-To: <48DB705A.6040301@redhat.com>

On Thu, 25 Sep 2008 13:04:58 +0200
Ivan Vecera <ivecera@redhat.com> wrote:

> Ben Hutchings wrote:
> > On Thu, 2008-09-25 at 11:38 +0200, Ivan Vecera wrote:
> >> Francois Romieu wrote:
> >>> Ivan Vecera <ivecera@redhat.com> :
> >>> [...]
> >>>> OK :-), I hope the patch below is finally the right one.
> >>> My approval ratings won't surge today.
> >>>
> >>> Is there a specific explanation for the 10 us delay ?
> >>>
> >>> Realtek's 8168 / 8169 / 8101 drivers all use a (wildly copy'pasted ?)
> >>> 10 ms delay. I would not mind a 10 ms sleep.
> >> 'pci_vpd_pci22_wait' uses 100us(10x10us delay) for reading, there is 1ms
> >> (100x10us delay) in my patch, because 100us max. delay was too little for
> >> Realtek.
> > 
> > If the maximum delay there is too short, it should be increased.  As
> > I've said before, I picked a timeout that worked for me in the absence
> > of any time limit in the PCI specification.  I thought Stephen Hemminger
> > had modified it to work for sky2 but it looks like that change was
> > blocked by quibbling about how best to poll.
> > 
> > Ben.
> Yes, I did the same for r8169. 100us total was too short so I increase
> total possible delay to 1 ms. Some net drivers use infinite loop with
> flag testing but I think it isn't good approach and 10ms hard delay is
> a little bit long.
> 
> Ivan.
> 

Worst case on Marvell chips is 20ms. So the revised code did retry after
1ms. The important thing is with my code it doesn't run under lock with irq disabled,
but uses mutex instead.

      reply	other threads:[~2008-09-25 16:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-18 13:46 [PATCH] r8169: read MAC address from EEPROM on init Ivan Vecera
2008-09-18 19:34 ` Ilpo Järvinen
2008-09-18 19:53 ` Ilpo Järvinen
2008-09-19 13:05   ` Ivan Vecera
2008-09-20 22:04     ` Ilpo Järvinen
2008-09-24  8:46       ` Ivan Vecera
2008-09-24 21:10         ` Francois Romieu
2008-09-25  9:38           ` Ivan Vecera
2008-09-25 10:24             ` Ben Hutchings
2008-09-25 11:04               ` Ivan Vecera
2008-09-25 16:44                 ` Stephen Hemminger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080925094441.057b7723@extreme \
    --to=shemminger@vyatta.com \
    --cc=bhutchings@solarflare.com \
    --cc=edward_hsu@realtek.com.tw \
    --cc=ilpo.jarvinen@helsinki.fi \
    --cc=ivecera@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=romieu@fr.zoreil.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).