summaryrefslogtreecommitdiffstats
path: root/sys/dev
Commit message (Collapse)AuthorAgeFilesLines
* Merge amd64 and i386 bus.h and move the resulting header to x86. Replacetijl2010-12-207-17/+13
| | | | | | | | | the original amd64 and i386 headers with stubs. Rename (AMD64|I386)_BUS_SPACE_* to X86_BUS_SPACE_* everywhere. Reviewed by: imp (previous version), jhb Approved by: kib (mentor)
* Don't whine about child drivers calling pci_enable_busmaster(). That isjhb2010-12-201-4/+0
| | | | | | perfectly normal. MFC after: 1 week
* Fix a bug introduced in r216518. The ndis_subsys field holds the PCItijl2010-12-191-7/+19
| | | | | | | subdevice ID in addition to the subvendor ID. Reported by: Paul B Mahol 'onemda gmail com' Approved by: kib (mentor)
* Fix panic trying to use monitor mode. The iwn_cmd() calls issued bybschmidt2010-12-191-0/+2
| | | | | | | | iwn_config() want to msleep() on the mutex. PR: kern/138427 Submitted by: Henry Hu <henry.hu.sh at gmail.com> MFC after: 3 days
* Add support for JMicron JMC251/JMC261 Gigabit/Fast ethernetyongari2010-12-185-36/+403
| | | | | | | | | | | | | | | | | | | | controller with Card Read Host Controller. These controllers are multi-function devices and have the same ethernet core of JMC250/JMC260. Starting from REVFM 5(chip full mask revision) controllers have the following features. o eFuse support o PCD(Packet Completion Deferring) o More advanced PHY power saving Because these controllers started to use eFuse, station address modified by driver is permanent as if it was written to EEPROM. If you have to change station address please save your controller default address to safe place before reprogramming it. There is no way to restore factory default station address. Many thanks to JMicron for continuing to support FreeBSD. HW donated by: JMicron
* Use system defined PCIR_EXPRESS_DEVICE_CTL instead of using magicyongari2010-12-181-1/+1
| | | | number.
* Make sure whether driver allocated resource before releasing it.yongari2010-12-181-2/+4
|
* Fix a regression introduced in r213893. FPGA version requires PHYyongari2010-12-181-2/+3
| | | | probing so allow PHY probing on all possible addresses.
* Consistently put a tab character between #define and the macro name.yongari2010-12-181-14/+14
|
* Add 2 missing bus_dmamap_sync() calls. Those fix random 'scan timeout',bschmidt2010-12-181-0/+6
| | | | | | | | 'could not set power mode', 'device config failed' and other errors due reading invalid memory. Obtained from: OpenBSD MFC after: 3 days
* Fix association on 5GHz channels. The device is initially configured usingbschmidt2010-12-181-0/+3
| | | | | | | | a 2GHz channel with appropriate flags set to sc->config. Due to not zeroing sc->config for auth/assoc those flags are still set while trying to connect on a 5GHz channel. MFC after: 3 days
* Fix a panic while disabling the RF kill button, caller of thebschmidt2010-12-181-2/+0
| | | | | | | wpi_rfkill_resume() function will take care of the lock. PR: kern/144898 MFC after: 3 days
* No need to zero the softc. It's allocated with M_ZERO.tijl2010-12-181-27/+3
| | | | | | | | | | | | | | | Use pci_enable_busmaster instead of setting PCIM_CMD_BUSMASTEREN directly. There's no need to set PCIM_CMD_MEMEN. The bit is set when a SYS_RES_MEMORY resource is activated. Remove redundant pci_* function calls from suspend/resume methods. The bus driver already saves and restores the PCI configuration. Write 1 byte instead of 4 when setting the HIFN_TRDY_TIMEOUT register. It is only 1 byte according to the specification. Reviewed by: jhb Approved by: kib (mentor)
* Use convenience functions where possible instead of accessing the PCItijl2010-12-185-45/+5
| | | | | | | | | | | | | configuration registers directly. Remove pci_enable_io calls where they are redundant. The PCI bus driver will set the right bits when the corresponding bus resource is activated. Remove redundant pci_* function calls from suspend/resume methods. The bus driver already saves and restores the PCI configuration. Reviewed by: jhb Approved by: kib (mentor)
* Add Exar octal PCI UART.emaste2010-12-181-0/+6
| | | | | Submitted by: Mark Johnston Obtained from: Sandvine Incorporated
* Implement and use a single optimized function for unholding a set of pages.alc2010-12-174-18/+4
| | | | Reviewed by: kib@
* small cleanup of acpi battery status setting and checkingavg2010-12-174-4/+23
| | | | | | | | | | | | | This is based on the patch submitted by Yuri Skripachov. Overview of the changes: - clarify double-use of some ACPI_BATT_STAT_* definitions - clean up undefined/extended status bits returned by _BST - warn about charging+discharging bits being set at the same time PR: kern/124744 Submitted by: Yuri Skripachov <y.skripachov@gmail.com> Tested by: Yuri Skripachov <y.skripachov@gmail.com> MFC after: 2 weeks
* - If the atkbdc device is assigned an IRQ resource by ACPI or the PnPBIOS,jhb2010-12-163-14/+55
| | | | | | | | | | allow the child atkbd device to reuse that IRQ resource instead of reallocating the same IRQ from the parent bus inside the atkbd driver. - Don't allocate a shared IRQ for the atkbd driver. For AT keyboard devices on an ISA bus the IRQ is not shareable. Instead, the bus driver should mark the IRQ shareable if the bus supports shared IRQs. - Don't identify child devices until after the atkbdc device itself has attached.
* - When moving the IRQ resource from the psmcpnp device to the psm device,jhb2010-12-161-15/+5
| | | | | | | delete the IRQ resource from the psmcpnp device completely. - Don't allocate the IRQ resource shared. It is not a shareable interrupt on ISA. The bus driver can set RF_SHAREABLE if the IRQ is actually shareable on a non-ISA bus.
* Small style fixes:jhb2010-12-161-14/+12
| | | | | | | | | - Avoid side-effect assignments in if statements when possible. - Don't use ! to check for NULL pointers, explicitly check against NULL. - Explicitly check error return values against 0. - Don't use INTR_MPSAFE for interrupt handlers with only filters as it is meaningless. - Remove unneeded function casts.
* Spelling fix.jhb2010-12-161-1/+1
|
* Use bus_alloc_resource_any() instead of bus_alloc_resource(). Besides beingjhb2010-12-162-16/+14
| | | | | | | cleaner, this fixes problems where the code was using ~0 instead of ~0ul for the upper bound on "any" resources. MFC after: 1 month
* Merge ACPICA 20101209.jkim2010-12-153-11/+27
|
* Stop lying about supporting cpu_est_clockrate() when TSC is invariant. Thisjkim2010-12-141-0/+11
| | | | | | | | | function always returned the nominal frequency instead of current frequency because we use RDTSC instruction to calculate difference in CPU ticks, which is supposedly constant for the case. Now we support cpu_get_nominal_mhz() for the case, instead. Note it should be just enough for most usage cases because cpu_est_clockrate() is often times abused to find maximum frequency of the processor.
* Remove unecessary and clearly wrong usage of atomic(9).yongari2010-12-141-5/+3
| | | | Reported by: avg
* acpi_fujitsu: update for P8010avg2010-12-111-1/+54
| | | | | | PR: kern/121102 Submitted by: Anish Mistry <amistry@am-productions.biz> MFC after: 3 weeks
* fix atomic_set_xxx misuse in drmavg2010-12-111-1/+1
| | | | | | | It seems that atomic_set_xxx and atomic_store_xxx were confused. Reviewed by: jhb MFC after: 3 weeks
* fix incorrect use of atomic_set_xxx in cxgbavg2010-12-111-1/+1
| | | | | | | | | | There is no need to use an atomic operation at structure initialization time. Note that the file changed is not connected to the build at this time. Reviewed by: jhb (general issue) Approved by: np MFC after: 2 weeks
* Fix setting LUN numbers in the mps(4) driver.ken2010-12-111-3/+39
| | | | | | | | | | Prior to this change, the addressing method wasn't getting set, and so the LUN field could be set incorrectly in some instances. This fix should allow for LUN numbers up to 16777215 (and return an error for anything larger, which wouldn't fit into the flat addressing model). Submitted by: scottl (in part)
* Implement more of __ibsta: END and SRQI status bits (taken out of thejoerg2010-12-101-0/+8
| | | | | | uPD7210 IRQ status). MFC after: 1 week
* Fix an event handling bug with the mps(4) driver.ken2010-12-102-11/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug manifested itself after repeated device arrivals and departures. The root of the problem was that the last entry in the reply array wasn't initialized/allocated. So every time we got around to that event, we had a bogus address. There were a couple more problems with the code that are also fixed: - The reply mechanism was being treated as sequential (indexed by sc->replycurindex) even though the spec says that the driver should use the ReplyFrameAddress field of the post queue descriptor to figure out where the reply is. There is no guarantee that the reply descriptors will be used in sequential order. - The second word of the reply post queue descriptor wasn't being checked in mps_intr_locked() to make sure that it wasn't 0xffffffff. So the driver could potentially come across a partially DMAed descriptor. - The number of replies allocated was one less than the actual size of the queue. Instead, it was the size of the number of replies that can be used at one time. (Which is one less than the size of the queue.) mps.c: When initializing the entries in the reply free queue, make sure we initialize the full number that we tell the chip we have (sc->fqdepth), not the number that can be used at any one time (sc->num_replies). When allocating replies, make sure we allocate the number of replies that we've told the chip exist, not just the number that can be used simultaneously. Use the ReplyFrameAddress field of the post queue descriptor to figure out which reply is being referenced. This is what the spec says to do, and the spec doesn't guarantee that the replies will be used in order. Put a check in to verify that the reply address passed back from the card is valid. (Panic if it isn't, we'll panic when we try to deference the reply pointer in any case.) In mps_intr_locked(), verify that the second word of the post queue descriptor is not 0xffffffff in addition to verifying that the unused flag is not set, so we can make sure we didn't get a partially DMAed descriptor. Remove references to sc->replycurindex, it isn't needed now. mpsvar.h: Remove replycurindex from the softc, it isn't needed now. Reviewed by: scottl
* Remove unecessary and clearly wrong usage of atomic(9).yongari2010-12-102-11/+9
| | | | Reported by: avg, jhb, attilio
* On the Xserve G5 we find the LM75 instead of the DS1775. The coreandreast2010-12-101-2/+3
| | | | | | | | | | | | functionality is the same, a difference is that the DS1775 has a better precision than the LM75. But we do not use it in our setup. Make the LM75 work the same as the DS1775. Fix a typo in device_set_desc. Tested by: Paul Mather <paul at gromit dlib vt edu> Approved by: nwhitehorn (mentor)
* Use SYS_RES_IOPORT instead of PCIM_CMD_PORTEN when calling pci_enable_io.tijl2010-12-101-1/+1
| | | | Approved by: kib (mentor)
* Fix __retval vs. retval confusion: retval is meant to store the (userland)joerg2010-12-101-1/+1
| | | | | | | | | | | pointer where data is to be returned by ibask() (currently unimplemented), while __retval holds the value returned by the libgpib ibfoo() functions. The confusion resulted in the ibfoo() functions returning an uninitialized value except in situations where the GPIB activity has been terminated abnormally. MFC after: 3 days
* Add IDs of HighPoint RocketRAID 62x cards (Marvell 88SE9128 chips).mav2010-12-081-0/+4
| | | | | | PR: kern/152926 Submitted by: Mike Tancsa <mike@sentex.net> MFC after: 1 week
* Use convenience macro for minimum and maximum value capping whenattilio2010-12-082-15/+19
| | | | | | | | | re-arming the watchdog timeout. Sponsored by: Sandvine Incorporated Submitted by: Mark Johnston <mjohnston at sandvine dot com> Reviewed by: des MFC after: 10 days
* r184610 changed the way how TX frames are handled on AX88178 andyongari2010-12-081-42/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AX88772 controllers. ASIX added a new feature for AX88178/AX88772 controllers which allows combining multiple TX frames into a single big frame. This was to overcome one of USB limitation where it can't generate more than 8k interrupts/sec which in turn means USB ethernet controllers can not send more than 8k packets per second. Using ASIX's feature greatly enhanced TX performance(more than 3~4 times) compared to 7.x driver. However it seems r184610 removed boundary checking for buffered frames which in turn caused instability issues under certain conditions. In addition, using ASIX's feature triggered another issue which made USB controller hang under certain conditions. Restarting ethernet controller didn't help under this hang condition and unplugging and replugging the controller was the only solution. I believe there is a silicon bug in TX frame combining feature on AX88178/AX88772 controllers. To address these issues, reintroduce the boundary checking for both AX88178 and AX88772 after copying a frame to USB buffer and do not use ASIX's multiple frame combining feature. Instead, use USB controller's multi-frame transmit capability to enhance TX performance as suggested by Hans[1]. This should fix a long standing axe(4) instability issues reported on AX88772 and AX88178 controllers. While I'm here remove unnecessary TX frame length check since upper stack always guarantee the size of a frame to be less than MCLBYTES. Special thanks to Derrick Brashear who tried numerous patches during last 4 months and waited real fix with patience. Without this enthusiastic support, patience and H/W donation I couldn't fix it since I was not able to trigger the issue on my box. Suggested by: hselasky [1] Tested by: Derrick Brashear (shadow <> gmail dot com> H/W donated by: Derrick Brashear (shadow <> gmail dot com> PR: usb/140883
* Introduces IFF_CANTCONFIG interface flag to point that the interfaceweongyo2010-12-071-0/+1
| | | | | | | | | isn't configurable in a meaningful way. This is for ifconfig(8) or other tools not to change code whenever IFT_USB-like interfaces are registered at the interface list. Reviewed by: brooks No objections: gavin, jkim
* Add a comment to clarify that some BIOSes may clear the hw watchdogemaste2010-12-071-2/+3
| | | | | | indicator bit, preventing us from reporting in that case. X-MFC-with: r215868
* Use proper resource ID's for HPET IRQ resources. This mostly consists ofjhb2010-12-071-1/+19
| | | | | | | | looking to see if there is an existing IRQ resource for a given IRQ provided by the BIOS and using that RID if so. Otherwise, allocate a new RID for the new IRQ. Reviewed by: mav (a while ago)
* Re-add a status check which sneaked out during r214804.hselasky2010-12-071-0/+4
| | | | | | | | This change can fix some USB error messages showing up during bootup. MFC after: 3 days Approved by: thompsa (mentor)
* Set correct maximum I/O length. We can only handle I/O of up tocperciva2010-12-061-1/+1
| | | | | | max_request_segments * PAGE_SIZE if the I/O is page-aligned; the largest I/O we can guarantee will work is PAGE_SIZE less than that. This unbreaks 'diskinfo -t'.
* Fix scanning after loosing a connection. The firmware assumes that as longbschmidt2010-12-061-2/+19
| | | | | | | | | | | | | | as an association ID is set any scan is supposed to be a background scan. This implies that the firmware will switch back to the associated channel after a certain threshold, though, we are not notified about that. We currently catch this case by a timer which will reset the firmware after a 'scan timeout', though, upper layers are not notified about that and will simply hang until manual intervention. Fix this by resetting the firmware's knowledge about any association on RUN -> ASSOC and !INIT -> SCAN transitions. Tested by: Zhihao Yuan <lichray at gmail.com> MFC after: 1 week
* Fixes for monitor mode:bschmidt2010-12-061-4/+3
| | | | | | | | | | | | | | - Do not call iwn_calib_reset() for monitor mode. We do not want to query information and do runtime calibration while in monitor mode. Poking the firmware with adjustments for calibration results in firmware asserts. This could happened on RUN -> RUN transition only. - Adjust blink rate for monitor mode. It's supposed to not freak out and turn off after a while. - While here, remove one useless assignment of calib.state, it gets overwritten later in the function. Submitted by: Brandon Gooch <jamesbrandongooch at gmail.com> MFC after: 1 week
* When masking direct and processor devices during an inquiry, properlyjhb2010-12-061-1/+2
| | | | | | | preserve the upper bits of the first data byte. Reviewed by: scottl MFC after: 1 week
* When masking direct and processor devices during an inquiry, properlyjhb2010-12-061-4/+4
| | | | | | | | | | | preserve the upper bits of the first data byte. While here, shorten a few nearby lines. PR: kern/152768 Reported by: Sascha Wildner saw of online.de Reviewed by: scottl MFC after: 1 week
* Fix double ;;kevlo2010-12-064-5/+5
|
* For 6000 series and newer devices the DC calibration results are nobschmidt2010-12-052-9/+29
| | | | | | | | longer requested of the boot firmware. Instead of sending those results to the runtime firmware the firmware is told to do the DC calibration itself. MFC after: 1 week
* Correct build error.jfv2010-12-041-1/+0
|
OpenPOWER on IntegriCloud