reason (not all BIOSen have _DIS methods for all link devices for example).
This matches the behavior of attach() with respect to _DIS as well.
Submitted by: njl
handle to the PCI device_t if the ACPI device_t is already attached to a
driver. This happens on the Tablet TC1000 which for some reason includes
two PCI-ISA bridges and treats the second bridge as an ACPI system resource
device.
Reviewed by: njl (a while ago)
MFC after: 3 days
refactored it to be a generic device.
Instead of being part of the standard kernel, there is now a 'nvram' device
for i386/amd64. It is in DEFAULTS like io and mem, and can be turned off
with 'nodevice nvram'. This matches the previous behavior when it was
first committed.
the PS/2 mouse controller. Thus, when acpi_ibm(4) claimed the mouse
device, the mouse would stop working. The one ACPI dump of an R40 that
I've looked at includes an HKEY device with the proper "IBM0068" ID, so
I'm not sure how the "IBM0057" ID could have helped at all.
MFC after: 1 week
Approved by: njl
the PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs, which was broken
with the introduction of PCI domain support.
As the size of struct pci_conf_io wasn't changed with that commit,
this unfortunately requires the ABI of PCIOCGETCONF to be broken
again in order to be able to provide backwards compatibility to
the old version of that IOCTL.
Requested by: imp
Discussed with: re (kensmith)
Reviewed by: PCI maintainers (imp, jhb)
MFC after: 5 days
to kproc_xxx as they actually make whole processes.
Thos makes way for us to add REAL kthread_create() and friends
that actually make theads. it turns out that most of these
calls actually end up being moved back to the thread version
when it's added. but we need to make this cosmetic change first.
I'd LOVE to do this rename in 7.0 so that we can eventually MFC the
new kthread_xxx() calls.
codecs. Codec at address 0 seems purely digital, or perhaps an HDMI
interface. Let the driver skip it and continue scanning the codecs
starting with address 2 (Realtek ALC885).
* Due to possibilities of future similar cases, put enough logic
in hdac_scan_codecs() to force codec scanning starting from
XX address via tunable "hint.pcm.%d.codec_index".
Reported / Tested by: Toomas Pelberg <toomasp@gmx.net>
- Trivial headphone / speaker automute fixup for Fujitsu-Siemens
AMILO Si 1848 laptop.
Reported / Tested by: Ed <ed@bsd.it>
- Trivial headphone / speaker automute fixup for Fujitsu-Siemens
Lifebook S7020D laptop.
Reported / Tested by: Jaromir Dvoracek <jarek@ataxo.com>
- Some smart vendor trying to create interplanetary wormhole by
screwing pci config space during their BIOS update. The side effects
of their failure attempt includes mutilated hardware id, broken
speaker automuting and loosing the entire analog CD connectivity,
thus causing enough collateral damages to collapse the entire
universe. Move along with it.
Please exercise extra cautious when applying BIOS updates.
Reported / Tested by: Pietro Cerutti <gahr@gahr.ch>
- assembled laptop, based on the MSI-1034
(662) which is now becoming MSI-034A.
- Fix no sound issues (on headphones) for Lenovo ThinkCentre A55 due
to global automute table entry which is not applicable for
non-laptops.
Reported / Tested by: Piotr Smyrak <piotr.smyrak@heron.pl>
- Speaker mute control for HP DC7700 since the front headphone jack
does not generate any interesting unsolicited signal/response.
Reported / Tested by: tyop @ irc.freenode.net
Approved by: re (kensmith)
MFC after: 3 days
ukbd_poll to mark this keyboard instance as polling before calling
usbd_set_polling at USB level. usbd_set_polling runs softintr before
returning, stealing our input and making consequent polling getchar
kind of pointless.
This allows USB keyboards to coexist peacefully with serial console in DDB
and other contexts where polling is used.
MFC after: 1 week
properly due to the shortage of the RX buffer size. In a case of zyd
devices, up to 3 frames can be combined in an USB transaction. So, RX
buffer should be at least ((MCLBYTES + extra structs) * 3)
Submitted by: Weongyo Jeong <weongyo.jeong@gmail.com>
MFC after: 3 days
make sure to never call sched_bind() for uninitialised CPUs.
Submitted by: Constantine A. Murenin <cnst@FreeBSD.org>
Sponsored by: Google Summer of Code 2007 (GSoC2007/cnst-sensors)
Mentored by: syrinx
Tested by: many
OKed by: kensmith
which is ukbd0. Specifically, the keyboard driver structures for ukbd0
are not allocated/freed but are statically allocated via a persistent
global variable. There is some additional magic for the ukbd0 such that
if the keyboard is marked as probed in this global variable, then we
don't check to see if the device_t we are probing has an interface.
This causes a problem if an attach of ukbd0 fails without fulling clearing
the state in the global variable. Specifically, if the keyboard fails to
initialize in init_keyboard() or kbd_register(), then the keyboard will
still be marked as probed. The USB layer will then try to offer the
"generic" version of the USB keyboard device (as opposed to the
per-interface sub-devices) and the ukbd(4) driver will see that the
keyboard is marked probe and will skip the "is this a per-interface device"
check. Later in ukbd_attach() it panics because it tries to dereference
the interface pointer which is NULL.
The fix is to clear the flags in the persistent keyboard data for ukbd0
when init_keyboard() or kbd_register() fail.
MFC after: 1 week
Reviewed by: imp
- Add proper scanning support rather than letting the firmware grab the first
access point
- Overhaul state changes
- Use macros for locking and provide _locked() versions of some functions
- Increase debugging output
- Use a callout rather than the old watchdog interface
- Improve style, function names and defines
- Add WPA (TKIP) support
Based heavily on a patchset provided by Sam Leffler.
VR_STICKHW register would result in unexpected results on these
hardwares. wpaul said the following for the issue.
The vr_attach() routine unconditionally does this for all supported
chips:
/*
* Windows may put the chip in suspend mode when it
* shuts down. Be sure to kick it in the head to wake it
* up again.
*/
VR_CLRBIT(sc, VR_STICKHW, (VR_STICKHW_DS0|VR_STICKHW_DS1));
The problem is, the VR_STICKHW register is not valid on all Rhine
devices. The VT86C100A chip, which is present on the D-Link DFE-530TX
boards, doesn't support power management, and its register space is
only 128 bytes wide. The VR_STICKHW register offset falls outside this
range. This may go unnoticed in most scenarios, but if you happen to have
another PCI device in your system which is assigned the register
space immediately after that of the Rhine, the vr(4) driver will
incorrectly stomp it. In my case, the BIOS on my test board decided
to put the register space for my PRO/100 ethernet board right next
to the Rhine, and the Rhine driver ended up clobbering the IMR register
of the PRO/100 device. (Long story short: the board kept locking up on
boot. Took me the better part of the morning suss out why.)
The strictly correct thing to do would be to check the PCI config space
to make sure the device supports the power management capability and only
write to the VR_STICKHW register if it does.
Instead of inspecting chip revision numbers for the availability of
VR_STICKHW register, check the existence of power management capability
of the hardware as wpaul suggested.
Reported by: wpaul
Suggested by: wpaul
OK'ed by: jhb
SAS-enabled cards. It also makes the driver MPSAFE, eliminating some
problems that resulted from CAM becoming MPSAFE. Many thanks to 3Ware/AMCC
for continuing to support FreeBSD.
Submitted by: Manjunath Ranganathaiah
Approved by: re
voltage of 0. This can result in a divide by zero trap. Add a guard
for this case. The value of lfcap is checked in acpi_battery_bif_valid()
just before this, so it is safe.
Reportd by: sam
Approved by: re
MFC after: 3 days
of directly from acpi0. Before it would attach prior to the sysresource
devices, causing the later allocation of its memory range to fail and
print a warning like "acpi0: reservation of fed00000, 1000 (3) failed".
Use an explicit define for our probe order base value of 10.
Help from: jhb
Tested by: Abdullah Ibn Hamad Al-Marri <almarrie / gmail.com>
MFC after: 3 days
Approved by: re
with all functions supported. This is done adding usb device IDs
to the table of recognised devices (because there is no standard
'scanner' class, so no other way to recognise them), and with
a small change to the uscanner attach routine that prevents
reconfiguring the whole USB device while we are dealing only with
one of its USB interfaces.
The latter part has been suggested by Steinar Hamre in
http://www.freebsd.org/cgi/query-pr.cgi?pr=107665 , i have
only added a bit of explaination to the code.
I have personally tried this on the Epson DX-5050 and DX-6000
devices (on the US market they have different names, CX-something).
I have good reasons to think that, possibly with the mere addition
of more USB ids to the table in uscanner.c, this should work with
all Epson multifunction devices in that family (from DX-3800 to
DX-7000 - these units are in the 50-120$ price range).
More details on related topics (SANE configuration, OCR, etc.)
at http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html
Manpage updates coming soon.
Approved by: re, imp
MFC after: 3 days
