netdev - Re: [PATCH] SMSC LAN9500 USB2.0 10/100 ethernet adapter driver

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:	Mon, 8 Sep 2008 11:36:17 -0700
From:	David Brownell <david-b@...bell.net>
To:	Masakazu Mokuno <mokuno@...sony.co.jp>,
	Steve Glendinning <steve.glendinning@...c.com>
Cc:	netdev@...r.kernel.org, Ian Saturley <ian.saturley@...c.com>,
	Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH] SMSC LAN9500 USB2.0 10/100 ethernet adapter driver

On Monday 08 September 2008, Masakazu Mokuno wrote:
> > +     /* 40ms total */
> As smsc95xx_read_reg() uses the synchronous urb call and AFAIR ehci
> would defer the interrupts until 8 micro-frames by default, so I guess this
> loop would take more than 40ms?

Don't assume this always works with EHCI ... there are systems
that will use it with full speed host controllers.  And for that
matter, an increasing number of non-EHCI high speed hosts.

And on Linux, we override that slow default setting and tell
EHCI to interrupt us as soon as the transfer is done.  (There
are better interrupt mitigation schemes in place.  For example
the "usbnet" framework avoids IRQs after most packets and
the mass storage driver can read or write hundreds of KBytes
with a single IRQ.)

In general, calling udelay() in this level of USB driver should
be avoided in favor of msleep() or similar.  Spinning the CPU
will just waste power.

I suggest you cc linux-usb@...r to get more usb-aware review
of this code... 

- Dave
--
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