---snip---
FYI this bit isn't needed for FreeBSD - I think it came from either
OpenBSD or NetBSD where arc4random() wasn't available during cold
boot.
---snip---
Explained by: iedowse
Synchronise with NetBSD upto rev 1.19:
- Allow 32 chars in the saved vendor string.
- Some NetBSD-only changes.
- Some missing parts (define, variable).
ehci_pci.c:
Add vendor ids for ATI and Philips.
Add identification strings for the following:
o ALi's M5239
o AMD 8111
o ATI SB200, SB400
o Intel 6300ESB, ICH4, ICH5, ICH7
o NVIDIA nForce 2, nForce 3, nForce 4
o Philips ISP156x
ehcireg.h:
We're at the same level as rev 1.18 from NetBSD.
usb_port.h:
NetBSD/OpenBSD specific things
Obtained from: NetBSD via DragonFly
No comment from: usb@
so that devd can match on it. This field was already available to
usbd and is used by a number of usbd.conf entries, so now it is
possible to transfer those entries to devd.conf.
Submitted by: Anish Mistry
o add ic_curchan and use it uniformly for specifying the current
channel instead of overloading ic->ic_bss->ni_chan (or in some
drivers ic_ibss_chan)
o add ieee80211_scanparams structure to encapsulate scanning-related
state captured for rx frames
o move rx beacon+probe response frame handling into separate routines
o change beacon+probe response handling to treat the scan table
more like a scan cache--look for an existing entry before adding
a new one; this combined with ic_curchan use corrects handling of
stations that were previously found at a different channel
o move adhoc neighbor discovery by beacon+probe response frames to
a new ieee80211_add_neighbor routine
Reviewed by: avatar
Tested by: avatar, Michal Mertl
MFC after: 2 weeks
IFF_DRV_RUNNING, as well as the move from ifnet.if_flags to
ifnet.if_drv_flags. Device drivers are now responsible for
synchronizing access to these flags, as they are in if_drv_flags. This
helps prevent races between the network stack and device driver in
maintaining the interface flags field.
Many __FreeBSD__ and __FreeBSD_version checks maintained and continued;
some less so.
Reviewed by: pjd, bz
MFC after: 7 days
when using mice containing a tilt movement: there was a missing
usb_callout_init() for the UMS_SPUR_BUT_UP quirk code, and UMS_T
was defined to the same flag value as UMS_SPUR_BUT_UP.
Reported by: flz
MFC after: 3 days
over iteration of their multicast address lists when synchronizing the
hardware address filter with the network stack-maintained list.
Problem reported by: Ed Maste (emaste at phaedrus dot sandvine dot ca>
MFC after: 1 week
through umass(4), in order to make cdcontrol(1) to issue commands to
a USB CD driver.
The command IDs were obtained from the CAM subsystem. This was tested
on half dozen of USB CD drivers from different vendors.
Suggested by: "intron" <intron at intron dot ac>
PR: usb/83439
Reviewed by: sanpei
MFC After: 1 week
succeed. There are many printers that return status over the read
channel, and if we wait for the status to become ready, then we can't
find the status automatically. Linux doesn't wait, nor does it ever
seem to really check the status in any meaningful way... If there
really is a problem, the writes to the bulk out endpoint will still
fail (like they would if the printer was ready and then ran out of
paper or became unready).
In addition, there are a number of printers being made that emulate
the 'status' byte by returning '0' always rather than '0x18'. This
fixes the EBUSY on open timeouts on those printer as well.
Reviewed by: the defining silence on usb@
o Indent usb ids properly
o Check the return value of if_alloc()
o Call if_free() in ural_detach()
Reviewed by: silby (mentor)
Approved by: re (scottl)
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
are used onboard in most of the newer PCI-based sun4u machines
(cosmetic change as they were also already probed as generic OHCI
without this). Detect whether their intpin register is valid and
correct it if necessary, i.e. set the respective IVAR to the right
value for allocating the IRQ resource, as some of them come up
having it set to 0 (mainly those used in Blade 100 and the first
one on AX1105 boards). This fixes attaching affected controllers.
Correcting the intpin value might be better off in the PCI code
via a quirk table but on the other hand gem(4) and hem(4) also
correct it themselves and at least for the USB controller part
the intpin register is truely hardwired to 0 and can't be changed.
This means that we would have to hook up the quirk information
in a lot of places in the PCI code (i.e. whenever the value of the
intpin register is read from or written to the pci_devinfo of the
respective device) in order to do it the right way.
MFC after: 1 month
whether or not the receive pipe is stopped. This ensures that we
do not attempt to start the same transfer twice, and it allows
ucomstop() to skip the restarting of the read pipe if it was not
originally running, such as when called indirectly from ucomreadcb().
PR: kern/79420
MFC after: 1 day
This ensures that we explore EHCI busses before their companion
controllers' busses, so that ports connected to full/low speed
devices will be properly routed to the companion controllers by the
time the OHCI/UHCI exploration occurs.
found it guilty in putting the card into unusable state after UP->DOWN->UP
media status change.
Looks like some of register writes in this functions mess up PHY interface.
No visible regressions has been found after commenting this code out -
the card properly handles forceful local mode changes and auto-detects changes
made remotely (tested with Auto, 10HD, 10FD, 100HD, 100FD).
Sponsored by: PBXpress Inc.
MFC after: 3 days
