netdev - Re: [PATCH] r8169: read MAC address from EEPROM on init

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]

Date:	Thu, 25 Sep 2008 09:44:41 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Ivan Vecera <ivecera@...hat.com>
Cc:	Ben Hutchings <bhutchings@...arflare.com>,
	Francois Romieu <romieu@...zoreil.com>,
	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>,
	Netdev <netdev@...r.kernel.org>,
	Edward Hsu <edward_hsu@...ltek.com.tw>
Subject: Re: [PATCH] r8169: read MAC address from EEPROM on init

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

> Ben Hutchings wrote:
> > On Thu, 2008-09-25 at 11:38 +0200, Ivan Vecera wrote:
> >> Francois Romieu wrote:
> >>> Ivan Vecera <ivecera@...hat.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.
--
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