error doing so. It seems an increasing number of phones have this
quirk, and we're not keeping up. There appears to be nothing bad that
happens for non-quirked phones.
Minor cleanups:
o prefer device_printf over printf
o kill devinfo stuff
o minor other preening.
need to do it at all anymore. Remove it from here. Expand
USB_ATTACH_SETUP inline now that it is one line and we're moving away
from the compat macros. Remove some bzero calls that turn out not be
be necessary.
what we print, don't print it anymore. And don't compute it anymore.
And don't malloc/free memory for it anymore. While I'm here, prefer
device_printf where appropriate.
sysctl_handle_int is not sizeof the int type you want to export.
The type must always be an int or an unsigned int.
Remove the instances where a sizeof(variable) is passed to stop
people accidently cut and pasting these examples.
In a few places this was sysctl_handle_int was being used on 64 bit
types, which would truncate the value to be exported. In these
cases use sysctl_handle_quad to export them and change the format
to Q so that sysctl(1) can still print them.
OpenBSD's if_ral.c.
I didn't make the LINKSYS4 -> CISCOLINKSYS name change, nor did I
include the RALINK RT2573 that's supported by the rum(4) driver. I
didn't merge any code changes either.
supports software encrypt/decrypt.
The nuked code itself is quite problematic, as pointed out by sam@ ---
wk->wk_keyix should be replaced by the loop count.
Tested with WEP/TKIP/CCMP/no-protection.
Approved by: sam@ (mentor)
Noticed by: Hans Petter Selasky <hselasky@c2i.net>
- For ural(4):
o Fix node leakage in ural_start(), if ural_tx_mgt() fails.
o Fix mbuf leakage in ural_tx_{mgt,data}(), if usbd_transfer() fails.
o In ural_tx_{mgt,data}(), set ural_tx_data.{m,ni} to NULL, if
usbd_transfer() fails, so they will not be freed again in ural_stop().
Approved by: sam (mentor)
use to synchornize and protect all data objects that are used for that
SIM. Drivers that are not yet MPSAFE register Giant and operate as
usual. RIght now, no drivers are MPSAFE, though a few will be changed
in the coming week as this work settles down.
The driver API has changed, so all CAM drivers will need to be recompiled.
The userland API has not changed, so tools like camcontrol do not need to
be recompiled.
obtaining and releasing shared and exclusive locks. The algorithms for
manipulating the lock cookie are very similar to that rwlocks. This patch
also adds support for exclusive locks using the same algorithm as mutexes.
A new sx_init_flags() function has been added so that optional flags can be
specified to alter a given locks behavior. The flags include SX_DUPOK,
SX_NOWITNESS, SX_NOPROFILE, and SX_QUITE which are all identical in nature
to the similar flags for mutexes.
Adaptive spinning on select locks may be enabled by enabling the
ADAPTIVE_SX kernel option. Only locks initialized with the SX_ADAPTIVESPIN
flag via sx_init_flags() will adaptively spin.
The common cases for sx_slock(), sx_sunlock(), sx_xlock(), and sx_xunlock()
are now performed inline in non-debug kernels. As a result, <sys/sx.h> now
requires <sys/lock.h> to be included prior to <sys/sx.h>.
The new kernel option SX_NOINLINE can be used to disable the aforementioned
inlining in non-debug kernels.
The size of struct sx has changed, so the kernel ABI is probably greatly
disturbed.
MFC after: 1 month
Submitted by: attilio
Tested by: kris, pjd
to a READ_CAPACITY request rather than the maximum sector (off by one
problem). This causes a huge cascade of errors as the geom tasting
code tries to read the last sector (which isn't really there in the
face of this error). automated tools that manipulate disk labels and
such also have issues.
Create a new quirk READ_CAPACITY_OFFBY1 and add a quirk for the
SanDISK ImageMate that I have that suffers from this problem (the
SDDR-31). It intercepts the READ_CAPACITY response and adjusts it
from number of sectors to max sector for devices with this quirk.
Reading the Linux source suggests that there are a host of
other devices with this issue, including iPods and some popular
cameras. I've not added quirks for them, since I don't have the
devices in front of me to test.
The patch from the PR was a little outdated w/regards to the
Vodafone vendor string.
PR: kern/106033
Submitted by: Volker Werth <volker_AT_vwsoft.com>
MFC in: 3 days
description here. The fix in the PR isn't necessary at all for memory
leaks, but we weren't setting the device description.
While I'm here, remove some of the obfuscating macros in attach.
PR: 108719
