step in making this driver more attachment neutral. Others plan on
adding acpi front ends.
Still need to cleanup the MI part of the driver because it isn't as
bus independent as it could be.
- In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags
used for shared memory allocations with a lowaddr of 0x3E7FFFFF.
This forces the buffers to be mapped to physical/bus addresses within
the first 1GB of physical memory. It seems that at least one card
(Linksys Instant Wireless PCI V2.7) depends on this behavior. I
don't know if this is a hardware restriction, or if the NDIS
driver for this card is truncating the addresses itself, but using
physical/bus addresses beyong the 1GB limit causes initialization
failures.
- Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in
if_ndis.c to test whether the device has been initialized rather
than checking for the presence of the IFF_UP flag in if_flags.
While debugging the previous problem, I noticed that bringing
up the device would always produce failures from ndis_setmulti().
It turns out that the following steps now occur during device
initialization:
- IFF_UP flag is set in if_flags
- ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle)
- ifp->if_ioctl() called with SIOCADDMULTI
- ifp->if_ioctl() called with SIOCADDMULTI (again)
- ifp->if_ioctl() called with SIOCADDMULTI (yet again)
- ifp->if_ioctl() called with SIOCSIFFLAGS
Setting the receive filter and multicast filters can only be done
when the underlying NDIS driver has been initialized, which is done
by ifp->if_init(). However, we don't call ifp->if_init() until
ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been
set. It appears that now, the network stack tries to add multicast
addresses to interface's filter before those steps occur. Normally,
ndis_setmulti() would trap this condition by checking for the IFF_UP
flag, but the network code has in fact set this flag already, so
ndis_setmulti() is fooled into thinking the interface has been
initialized when it really hasn't.
It turns out this is usually harmless because the ifp->if_init()
routine (in this case ndis_init()) will set up the multicast
filter when it initializes the hardware anyway, and the underlying
routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC
haven't been initialized yet, but you end up spurious error messages
on the console all the time.
Something tells me this new behavior isn't really correct. I think
the intention was to fix it so that ifp->if_init() is only called
once when we ifconfig an interface up, but the end result seems a
little bogus: the change of the IFF_UP flag should be propagated
down to the driver before calling any other ioctl() that might actually
require the hardware to be up and running.
device is open. This allows certain old and rather special dual
floppy controllers to work on both channels, as long as you only
have one open at a time.
this more accurately reflects what the underlying hardware of most
acpi machines that don't have children pci busses.
We still need a better way to get this information from acpi/hardware.
- Remove recursive locking situations. Remove the MTX_RECURSE bit.
- Take the lock for any routine which is not called from within if_vr.c
itself; this includes entry points called by newbus, ifnet, callout,
ifmedia, and polling subsystems.
- Remove spl references from the code added to miibus callbacks in rev 1.60.
- Add the INTR_MPSAFE bit.
- Tidy up some assignments; locks are not needed for taking the address
of something at a known offset, for example.
- Tested on the machine this was committed from.
Tested on: UP only, !debug.mpsafenet && debug.mpsafenet
Reviewed by: rwatson
Put some braces around the busy-wait loop in vr_rxeoc() to make the
no-op semicolon more obvious.
No functional changes.
Running on the machine I am committing from without problems.
Reviewed by: jmallett
header pointer and then casting it to the ecdt pointer. This fixes the
-O2 build. I'm unsure what changed recently to reveal this error since
this code has been unchanged for months.
following drivers: bfe(4), em(4), fxp(4), lnc(4), tun(4), de(4) rl(4),
sis(4) and xl(4)
More patches are pending on: http://peoples.freebsd.org/~mlaier/ Please take
a look and tell me if "your" driver is missing, so I can fix this.
Tested-by: many
No-objection: -current, -net
rev. 1.68, author: mycroft
Ignore a port error that happens to come in at the same time as a
connect status change. Some root hubs seem to report both.
Obtained from: NetBSD
bus interfaces. These interfaces use the FTDI chipset with different
Vendor and Product IDs.
Add two additional baud rate enumerations. The vehicle bus interfaces
use a baud rate of 2000000. Also add 3000000 as it is the other FTDI
baud divisor special case.
I've commited a slightly different patch from that provided in the PR as
I changed the matching code a bit yesterday.
Submitted by: Mike Durian <durian at shadetreesoftware.com>
PR: kern/67357
operations when the refcount doesn't protect the opens and closes. Fix
this, and don't actually let a time out happen: now ugen(4) devices do
not get freed out from under the programs with them open.
instead of a mutex so we do not unblock it in msleep(). If we do this,
another event could occur, resetting the status register since reads
reset it. While I'm here, remove the backoff approach. Instead, sleep
in 10 ms chunks for up to the configured timeout using either DELAY (if
we aren't booted yet) or tsleep.
Help from: dillon
Tested by: Andrew Thompson andy AT fud.org.nz
Unify the code to disable GPEs with the enable code. Shutdown is handled
the same way. ACPI now does all wake/sleep prep for child devices so
now they no longer need to call external functions in the suspend/resume
path. Add the flags to non-ACPI busses (i.e., pci).
This brings us into line with the standard, which requires power resources
be enabled when wake is enabled for a given device. Move the dereferencing
code into its own function, +acpi_pwr_dereference_resource().
code that was never really used. Print a message when disabling ACPI via
a quirk. Allow the user to override the blacklist decision by setting
hint.acpi.0.disabled="0". Add missing AcpiTerminate() calls; they are
needed to clean up if bailing out after AcpiInitializeSubsystem().
PCI native addressing. That means that if the HW says that using "real"
addresses instead of the hardwired legacy compat ones is allowed, we will
use them.
namespace. This is to allow decoupling of attachments from ACPI where they
need some functionality when ACPI is present but do not want to require ACPI
to always be loaded.
Add Intel Pro100Lan56 card.
Also integrate changes from Carlos Velasco. Only attch if we're a
network device (to filter out the serial devices). Also, increment
vpmatch if we match to conform to the pccard match function api.
Use bus space rather than direct inb/outb. Minor style changes while
I'm here. Extremely preliminary support for siliconix ethernet cards
(but more work is required).
The hack for setting the bus has been moved down into the cbb driver.
I've been running without this hack in my tree for so long I had
forgotten that I'd removed it :-). Please let me know if this causes
difficulty for your laptop.
starting value. This is more pedantically correct (since the handle
isn't always identical to the start of the resource) and also doesn't
access the innards of struct resource direct (which I forbid in my
tree). We need to do this for all resource types, not just ioport.
Reviewed by: njl
uhid.c (1.61), author: jdolecek
add support for USB_GET_DEVICEINFO and USB_GET_STRING_DESC ioctls,
with same meaning as for ugen(4)
usbdi_util.h (1.29), usb_quirks.c (1.50), uhid.c (1.62),
ugen.c (1.68), usb_subr.c (1.114) author: mycroft
Yes, some devices return incorrect lengths in their string
descriptors. Rather than losing, do what Windows does: just
request the maximum size, and allow a shorter response. Obsoletes
the need for UQ_NO_STRINGS, and therefore these "quirks" are removed.
usb_subr.c (1.116), author: mycroft
In the "seemed like a good idea until I found the fatal flaw"
department... Attempting to read a maximum-size string descriptor
causes my kue device to go completely apeshit. So, go back to the
original method, but allow the device to return a shorter string than
it claimed.
Obtained from: NetBSD
copies.
No current line disciplines have a dynamically changing hotchar, and
expecting to receive anything sensible during a change in ldisc is
insane so no locking of the hotchar field is necessary.
ohci.c (1.147), author: mycroft
Failure to properly mask off UE_DIR_IN from the endpoint address
was causing OHCI_ED_FORMAT_ISO and EHCI_QH_HRECL to get set
spuriously, causing rather interesting lossage.
Suddenly I get MUCH better performance with ehci...
ohci.c (1.148), author: mycroft
Adjust a couple of comments to make it clear WTF is going on.
Obtained from: NetBSD
ehci.c (1.55), ehcireg.h (1.16); author: mycroft
Set the data toggle correctly, and use EHCI_QTD_DTC. This fixes
problems with my ALi-based drive enclosure (it works now, rather
than failing to attach). Also seems to work with a GL811-based
enclosure and an ASUS enclosure with a CD-RW, on both Intel and
NEC controllers.
Note: The ALi enclosure is currently very SLOW, due to some issue
with taking too long to notice that the QTD is complete. This
requires more investigation.
ehci.c (1.56); author: mycroft
Failure to properly mask off UE_DIR_IN from the endpoint address
was causing OHCI_ED_FORMAT_ISO and EHCI_QH_HRECL to get set
spuriously, causing rather interesting lossage.
Suddenly I get MUCH better performance with ehci...
ehci.c (1.58); author: mycroft
Fix a stupid bug in ehci_check_intr() that caused use to try to
complete a transaction that was still running. Now ehci can
handle multiple devices being active at once.
ehci.c (1.59); author: enami
As the ehci_idone() now uses the variable `epipe'
unconditionally, always declare it (in other words, make this
file compile w/o EHCI_DEBUG).
ehci.c (1.60); author: mycroft
Remove comment about the data toggle being borked.
ehci.c (1.61); author: mycroft
Update comment.
ehci.c (1.62); author: mycroft
Adjust a couple of comments to make it clear WTF is going on.
ehci.c (1.63); author: mycroft
Fix an error in a debug printf().
ehci.c (1.64), ehcireg.h (1.17); author: mycroft
Further cleanup of toggle handling. Now that we use EHCI_QH_DTC,
we don't need to fiddle with the TOGGLE bit in the overlay
descriptor, so minimize how much we fuss with it.
Obtained from: NetBSD
Thanks to Sam for importing tags in a way that allowed this to be done.
Submitted by: Gleb Smirnoff <glebius@cell.sick.ru>
Also allow the sr and ar drivers to create netgraph versions of their modules.
Document the change to the ksocket node.
are currently all bad BIOS revisions that will never be able to support
ACPI. They were derived by examining which BIOS's are blacklisted by other
operating systems. Other types of quirks will be possible here as well.
Ultra2 users may want to set OFWCONS_POLL_HZ to a value of '20'.
I have left default value at '4' as higher values can consume a more
than is acceptable amount of CPU, and we don't have a consensus yet
what is an optimal value.
Submitted by: Pyun YongHyeon <yongari@kt-is.co.kr>
smp_rendezvous() to ensure we run on the BSP. This reverts rev 1.128.
Add a comment indicating that MI code should be the one that runs all
shutdown functions on the BSP with the APs halted. This should work
around problems in power off while waiting for the MI code to be improved.
actually used. For most ACPI devices this means deferring the call
until bus_alloc_resource().
- Add a function acpi_config_intr() to call BUS_CONFIG_INTR() for an
ACPI IRQ resource using the trigger mode and polarity information
stored in the ACPI resource object.
- Add a function acpi_lookup_irq_resource() to lookup the ACPI IRQ
resource that corresponds to a specified rid and new-bus resource.
- Have the ACPI PCI bridge driver call BUS_CONFIG_INTR() on interrupts
that it routes through link devices.
- Remove needactivate variable from acpi_alloc_resource() by changing the
function not modify the flags variable but just mask off RF_ACTIVE when
calling rman_reserve_resource().
Reviewed by: njl (1, an earlier version)
device associated with any PCI devices that are enumerated in the ACPI
tree when adding children to an ACPI PCI bus and remove the duplicate
ACPI-only device_t and replace the device_t associated with the handle with
the ACPI and PCI aware device_t.
Several changes:
* Implement read for ulpt.
* If the device is not opened for reading, occasionally drain any
data the printer might have (but don't hammer the printer with reads).
* Lower the buffer size to one page.
The driver seems to work with more printers now.
Obtained from: NetBSD
the GEOM topology.
There are still issues with not detaching from cam correctly such that
upon a device detach there's an invalid pointer dereference from the
later call to cam_rescan().
that are on a CISS bus to be exported up to CAM and made available as normal
devices. This will typically add one or two buses to CAM, which will be
numbered starting at 32 to allow room for CISS proxy buses. Also, the CISS
firmware usually hides disk devices, but these can also be exposed as 'pass'
devices if you set the hw.ciss.expose_hidden_physical tunable.
Sponsored by: Tape Laboratories, Inc.
MFC After: 3 days
least the pci device unloadable
- Use ttymalloc() rather than a plain malloc to allocate the
rp->rp_tty ttys. This is now required due to the recent locking
changes to ttys and prevents a panic due to locking an unitialized
t_mtx.
- Allow the pci driver to be unloaded. This involved moving
the call rp_releaseresource() to the end of rp_pcireleaseresource(),
since rp_pcireleaseresource() uses ctlp->dev, which is freed
by rp_releaseresource().
- Allow the generic part of the driver to be unattached by providing
a hook to cancel timeouts.
Glanced at by: obrien
The big lines are:
NODEV -> NULL
NOUDEV -> NODEV
udev_t -> dev_t
udev2dev() -> findcdev()
Various minor adjustments including handling of userland access to kernel
space struct cdev etc.
timeout values in the CAM CCBs. Divide by 1000 to get values in seconds
which are what ata(4) timeouts internally use.
This does lose granularity, though, and small values can now round down
to zero. It's probably worth making all ata(4) timeouts in terms of
hz/ticks/milliseconds/something.
