ehci functions. We can't assume that there will only be one ehci per device.
The existing code could not deal with:
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x10) at pci1 dev 0 function 0 not configured
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x20) at pci1 dev 0 function 1 not configured
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x10) at pci1 dev 0 function 2 not configured
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x20) at pci1 dev 0 function 3 not configured
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x10) at pci1 dev 0 function 4 not configured
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x20) at pci1 dev 0 function 5 not configured
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x10) at pci1 dev 0 function 6 not configured
Netmos MCS9990 Quad USB 2.0 Port (USB serial bus, interface 0x20) at pci1 dev 0 function 7 not configured
if the total sectors reported (via disklabel or otherwise) is smaller
than 2^32, but numBlocksHi is set, zero it out instead.
tested by myself and christos, should fix reports of weirdness seen.
From FreeBSD, via OpenBSD, with some minor adaptations.
No comments, no objections on tech-kern@.
The driver was tested on a Dell M710. Access was kindly provided by
Uwe Toenjes, whom I thank for this.
See also http://mail-index.netbsd.org/tech-kern/2010/12/01/msg009478.html
The macros for PAGE_SIZE were fixed with the previous patch (if_bnxreg.h
splitting, rev 1.11).
From OpenBSD. Their commit log reads:
bnx(4) is a bit special. The chip itself is capable of swapping endianess
so there is no need for htoleXX calls. The only thing needed is the correct
layout of the DMA-ed structures. Additionally it uses PAGE_SIZE but assumed
that it is always 4k. Fix the macros that failed to respect that so that it
works on 8k PAGE_SIZE systems. This makes bnx(4) work on sparc64.
- if_bnxreg.h: general register values, flags... for bnx(4), that can
be included in other drivers
- if_bnxvar.h: PCI or device specific code (device state data, debug
macros etc.), which should remain private to bnx(4)
No comments, no objections on current-users@.
See discussion:
http://mail-index.netbsd.org/current-users/2010/12/01/msg014926.html
whether the properties actually exist.
When setting new limit values, don't complain/ignore about duplicate
values if the associated flag bits (indicating that the limit is valid)
are not set.
These two fixes together should fix a problem reported in private Email
by njoly@ a couple months ago. Issue replicated and solution tested
using my recent swsensor pseudo-device running inside qemu world!
sector disks..) from my tech-kern post:
the following patch let's me access both 512 byte and 4K
sector disks at the same time, as long as they are in
separate raids. the existing rf code assumes/enforces
this part, i just made it support other sets concurrently.
the main change is moving the parity bitmap to the sector
after the component label sector(s), instead of being
immediately after the label, which meant it was on the same
sector as the label for >1024 byte devices.
i'm a little annoyed at having to add a 2nd call to
getdisksize() to enable auto-configure to work, but i
don't see another way that wasn't much uglier.
1. On ISO-keyboard the keycodes for the key left of '1' and right of Shift
are swapped.
2. Find the Apple FN key in the report descriptor and do the translations
needed, before passing the keycodes to wscons.
3. Those keyboards only have the left Alt key. AltGr is missing. So it is
emulated when holding down FN together with Alt.
(a) This should be removed once C-states are supported.
(b) As there seems to be no reliable way to detect whether C1E is present,
the quirk blindly assumes that C1E is used on families 10h and 11h.
