I don't know if the reset is required or not. I tested some media
transitions without the reset and it worked. It might be OK to remove
but Linux does it only in et1011c_config_aneg(). So move the reset to
etphy_service(,,MII_MEDIACHG)'s autonego case. This change is also
required for future locking changes.
Even without extended W mode, sp_w can be 2. This causes
"invalid extended w mode N" warning messages.
Restrict extended W mode conditional for hardwares with extended W
support.
Tested with Synaptics 6.2 device on Panasonic CF-Y8, however it does
not work with X.
to be same with ixl_hmc_pack_txq[]
This has no functionality impact because the position on memory
is defined in ixl_hmc_pack_txq[].
pointed out and reviewed by knakahara@n.o., thanks
such as link up and down
And added kpreempt_disable and kpreempt_enable around
workqueue_enqueue to call it in non-WQ_PERCPU thread context.
pointed out and reviewed by knakahara@n.o., thanks.
- Change the lock on uvm_object, vm_amap and vm_anon to be a RW lock.
- Break v_interlock and vmobjlock apart. v_interlock remains a mutex.
- Do partial PV list locking in the x86 pmap. Others to follow later.
This code path is used both for xfers that are new, and xfers that
are being done piece by piece and are partway done. For the latter
case, skip usbd_xfer_schedule_timeout so we schedule it only once per
xfer.
to the number of channels supported by the hardware or less, if the hardware
supports multi channels.
- On monaural or stereo hardware, userland apps can always set 1ch or 2ch.
The kernel (audio layer) can convert mono-stereo each other.
- On 3ch (2.1ch) hardware, for example, userland apps can set 1, 2, or 3ch,
but not 4ch or more.
This allows userland apps to know actual number of channels supported by
the hardware in the same way as before.
PR kern/54973.
- Call usbd_xfer_schedule_timeout so we actually do time out.
- Don't call usbd_xfer_trycomplete until all the data have been
transferred -- it commits to completion, not timeout.
- Use xfer->ux_status != USBD_IN_PROGRESS to test whether, after a
partial write, an xfer has been interrupted or timed out and need
not be continued.
- Remove wrong assertion.
This ensures that pending xfers on the default pipe will be aborted
before we wait for children, which, in the case of scsibus -> sd,
means waiting for pending xfers to complete -- xfers that may never
complete if something is wedged.
- Make sure ux_status is set to USBD_IN_PROGRESS when started.
Otherwise, if it is still in flight when we abort the pipe,
usbd_ar_pipe will skip calling upm_abort.
- Initialize ux_status under the lock; in principle a completion
interrupt (or a delay) could race with the initialization.
- KASSERT that the xfer is in progress when we're about to complete
it.
Candidate fix for PR kern/54963 for other HCI drivers than uhci.
ok nick
ok phone
(This is the change that nick evidently MEANT to ok when he ok'd the
previous one!)
Why?
- Avoid completing a root intr xfer multiple times in races.
- Avoid potential use-after-free in poll_hub callouts (uhci, ahci).
How?
- Use sc->sc_intr_xfer or equivalent to store only a pending xfer
that has not yet completed -- whether successfully, by timeout, or
by synchronous abort. When any of those happens, set it to null
under the lock, so the xfer is completed only once.
- For hci drivers that use a callout to poll the root hub (uhci, ahci):
. Pass the softc pointer, not the xfer, to the callout, so the
callout is not even tempted to use xfer after free -- if the
callout fires, but the xfer is synchronously aborted before the
callout can do anything, the xfer might be freed by the time the
callout starts to examine it.
. Teach the callout to do nothing if it is callout_pending after it
has fired. This way:
1. completion or synchronous abort can just callout_stop
2. start can just callout_schedule
If the callout had already fired before (1), and doesn't acquire
the bus lock until after (2), it may be tempted to abort the new
root intr xfer just after submission, which would be wrong -- so
instead we just have the callout do nothing if it notices it has
been rescheduled, since it will fire again after the appropriate
time has elapsed.
New API for HCI drivers to synchronize hardware completion
interrupts, synchronous aborts, and asynchronous timeouts:
- When submitting an xfer to hardware, call
usbd_xfer_schedule_timeout(xfer).
- On HCI completion interrupt for xfer completion:
if (!usbd_xfer_trycomplete(xfer))
return; /* timed out or aborted, ignore it */
- In upm_abort methods, call usbd_xfer_abort(xfer).
For HCI drivers that use this API (not needed in drivers that don't,
or for xfers like root intr xfers that don't use it):
- New ubm_abortx method serves role of former *hci_abort_xfer, but
without any logic for wrangling timeouts/callouts/tasks -- caller
in usbd_xfer_abort has already handled them.
- New ubm_dying method, returns true if the device is in the process
of detaching, used by the timeout logic.
Converted and tested:
- ehci
- ohci
Converted and compile-tested:
- ahci (XXX did this ever work?)
- dwc2
- motg (XXX missing usbd_xfer_schedule_timeout in motg_*_start?)
- uhci
- xhci
Not changed:
- slhci (sys/dev/ic/sl811hs.c) -- doesn't use a separate per-xfer
callout for timeouts (XXX but maybe should?)
- ugenhc (sys/rump/dev/lib/libugenhc/ugenhc.c) -- doesn't manage its
own transfer timeouts
- vhci -- times transfers out only on detach; could be adapted easily
if we wanted to use the xfer->ux_callout
This is complicated because:
1. There are three ways that an xfer can be completed:
(a) hardware interrupt completes xfer
(b) software decision aborts xfer with USBD_CANCELLED
(c) timeout aborts xfer with USBD_TIMEOUT
2. The timeout abort can't be done in callout because ehci_sync_hc,
called unconditionally by ehci_abort_xfer to wait until the device
has finished using any references to the xfer, may sleep. So we
have to schedule a callout that, when run, will schedule a usb_task.
3. The hardware completion interrupt can't sleep waiting for a callout
or task to finish -- can't use callout_halt or usb_rem_task_wait.
So the callout and usb_task must be able to run _after_ the hardware
completion interrupt, and recognize that they're late to the party.
(Note, though, that usbd_free_xfer does wait for the callout and
task to complete, so there's no danger they may use themselves after
free.)
4. The xfer may resubmitted -- and the timeout may be rescheduled --
immediately after the hardware completion interrupt, _while_ the
callout and/or usb_task may still be scheduled. Specifically, we
may have the following sequence of events:
(a) hardware completion interrupt
(b) callout or usb_task fires
(c) driver resubmits xfer
(d) callout or usb_task acquires lock and looks around dazed and
bewildered at the firehose of events like reading the news in 2019
The mechanism for sorting this out is that we have two bits of state:
- xfer->ux_timeout_set informs the driver, when submitting an xfer and
setting up its timeout, whether either the callout or usb_task is
already scheduled or not.
- xfer->ux_timeout_reset informs the callout or usb_task whether it
should reschedule the callout, because the xfer got resubmitted, or
not.
These are needed because:
- The host controller interrupt cannot wait for the callout or task
to finish running.
- Nothing in the USBD API as is waits for the callout or task to
finish running.
- Callers expect to be able to resubmit USB xfers from xfer callbacks
without waiting for anything to finish running.
The variable ux_timeout_set can be used by a host controller to
decide on submission whether to schedule the callout or to ask an
already-scheduled callout or already-queued task to reschedule the
callout, by setting the variable ux_timeout_reset to true.
When the callout or task runs and sees that ux_timeout_reset is true,
rather than queue the task or abort the xfer, it can instead just
schedule the callout anew.
Usable only for negative diagnostic assertions:
KASSERT(!usb_task_pending(dev, task))
If you can think of a better name for this than !usb_task_pending,
I'm all ears.
it is however many devices the underlying ATA bus can have (eg. 1 for SATA),
so initialize the scsipi chan_ntargets from the ATA ch_ndrives.
this fixes a memory read overrun detected by KASAN.
discussed with mlelstv@ and jdolecek@
> aic7xxx(4): Fix unintended sign extension in ahd_inq()
>
> ahd_inb() returns type uint8_t. The shift left by untyped 24 implicitly
> promotes the result to type (signed) int. Then the binary OR with uint64_t
> values sign-extends the integer. If bit 31 of the read value happened to be
> set, the 64-bit result would have all upper 32 bits set to 1 due to OR.
> This is clearly not intended.
>
> Reported by: Coverity
> CID: 980473 (old one!)
may block on memory allocation, and so it cannot be safely done from
a softint nor can it be done while holding a spin lock. Fix this by
using a workqueue rather than a softint, and hold the IFNET_LOCK
across the entire handler, and the CORE_LOCK only across the code that
needs to serialize access to the hardware state.
- Use ifmedia_fini().
Tested in a variety of devices by msaitoh@. (Thanks!)
At this point it is highly unlikely this 1999 device still has users,
but it still comes up in the context of maxv's USB-fuzzing (and any device
could pretend to be a urio(4)), so it's best to get rid of it.
Renamed all major entries to obsolete, as was done in previous removals.
This still requires an update to sanitizers, but they're located in
"external", perhaps it should be first committed upstream?
Proposed on tech-kern a month ago.
Sometimes they get desynchronized, but we know the last packet is a
17-byte packet, so if we get one early then stop here.
Tested by macallan on an iBook and a PowerBook. This code path
shouldn't break anything on MacBooks because they have different
total numbers of sensors so this branch won't be reached.
Set hw.wm*.txrx_workqueue=1 to use workqueue instead of softint.
The default value of hw.wm*.txrx_workqueue is 0, that is, use softint
as before.
ok by msaitoh@n.o.
- Rockchip uses a different SDIO int bit, so take this into consideration
- Avoid unnecessary resets and always wait for resets to complete
- kpause instead of delay while holding spinlock
- Do not attempt autostop for SD_IO_RW_EXTENDED commands
- Allow for sub-blklen byte counts for single block transfers
Discussed on tech-kern:
https://mail-index.NetBSD.org/tech-kern/2020/01/13/msg025938.html
This was never (intentionally) enabled by default, and the design has
some shortcomings. You can get mostly the same results with ktrace,
as in usr.bin/make/filemon/filemon_ktrace.c which is now used instead
of filemon for make's meta mode.
If applications require higher performance than ktrace, or nesting
that ktrace doesn't support, we might consider adding something back
into the vfs system calls themselves, without hijacking the syscall
table. (Might want a more reliable output format too, e.g. one that
can handle newlines in file names.)
- Track the 64-bit range capability of prefetchable and non-prefetchable
memory separately. Probe the extent maps provided by the caller to
initialize these values. Without this, we never get 64-bit range
capablity on the root bus, and thus are never able to forward it along
to downstream busses.
- Always prefer allocating space for a 64-bit memory BAR > 4GB. We will
fall back on a 32-bit range if no space above 4GB is available.
- Constrain allocation of 32-bit memory BARs (including expansion ROM BARs)
to be below 4GB, even if the window has a larger range available.
- When allocating non-prefetchable memory space for a PCI-PCI bridge, ensure
it falls below 4GB, since a bridge cannot forward a 64-bit non-prefetchable
range.
- Account for expansion ROMs as non-prefetchable memory rather than
prefetchable memory; expansion ROMs have 32-bit BARs, and if a device
with an expansion ROM is downstream of a brige, a 32-bit prefetchable
range might not be available.
Tested by jmcneill@ on an Arm Neoverse N1 SDP, where the previous
code failed to configure all devices correctly.
NCQ on (some) drives. Enable this quirk for ATI (AMD) SB600/SB700
controllers. Alternate fix for kern/54790 and kern/54855.
ok jdolecek@, tested on my SB700 chipset and tsutsui's SB600 chipset.
The N1 SDP has a few bugs that we need to work around:
- PCIe root port config space lives in a non-standard location.
- Access to PCIe config space of devices that do not exist results in
an sync SError. Firmware creates a "known devices" table at a fixed
physical address that we use to filter PCI conf access to only known
devices.
This change splits the Arm ACPI PCI quirks into separate files for each
host controller, and allows per-segment quirks to be applied.
These changes exposed some bugs in the MI ACPI layer related to
multi-segment support. The MI ACPI PCI code was using a shared PCI
chipset tag to access devices, and these accesses can happen before our
PCI host bridge drivers are attached! The global chipset tag is now gone,
and an MD callback can provide a custom tag on a per-segment basis.
This is a driver for a "nonsense machine" made by the art group Maywa-Denki
in 2008. It was disabled by default.
Unfortunately even so it draws development attention (flaws found in the
code, MP-ification needs) and it is best not to continue to maintain this
driver.
Proposed without objections on tech-kern.
- Move some definitions from if_stgereg.h to if_stge.c again because those are
not chip (registers or descriptors) definitions.
- Use proplib to pass information that loading DSP code is required when
PHY reset.
r214849 | jkim | 2010-11-05 13:24:26 -0700 (Fri, 05 Nov 2010) | 2 lines
Add a forgotten change from the previous commit.
r214848 | jkim | 2010-11-05 12:50:09 -0700 (Fri, 05 Nov 2010) | 13 lines
Fix a use-after-free bug for extended IRQ resource[1]. When _PRS buffer is
copied as a template for _SRS, a string pointer for descriptor name is also
copied and it becomes stale as soon as it gets de-allocated[2]. Now _CRS is
used as a template for _SRS as ACPI specification suggests if it is usable.
The template from _PRS is still utilized but only when _CRS is not available
or broken. To avoid use-after-free the problem in this case, however, only
mandatory fields are copied, optional data is removed, and structure length
is adjusted accordingly.
Reported by: hps[1]
Analyzed by: avg[2]
Tested by: hps
This also fixes reading past the end of a structure as detected by KASAN.
- Pass an additional argument to gttwsi_wait() to indicate what's
going on, and report that, along with the error code from
cv_timedwait(), if a timeout occurs.
- In gttwsi_send_stop(), if we don't get the expected NRS status,
report which status we *did* get when a timeout occurs.
- Garbage-collect the obsolete GTTWSI_ALLWINNER option; it hasn't been
needed since FDT'ization of the Allwinner support code.
- Redefine thw "TWSI_*" register definitions to clearly call out:
-> The Marvell flavor of the offsets
-> The Allwinner flavor of the offsets
...and make the regular definitions indices into a register map.
- Pass the appropriate register map from the front-end to the core.
- Remove the customer register read/write callbacks -- they are no longer
needed now that each front-end passes an appropriate register map to
the core.
- It makes FIOASYNC code in mixer_ioctl() symmetric.
- For readability, mixer_async_{add,remove}() should take pid argument
though pid is always curproc.
cleared because it is also cleared inside the loop.
Not clearing it could trigger DNAs on VMEXITs, because STTS/CLTS are still
here as part of debugging since my FPU overhaul.
"model") property to set the cpu model (in userland aka sysctl hw.model).
When attaching the first cpu, do not overwrite a cpu model if it already
had been set.
for debugging
- nomsix(boolean)
- disable msix support
- stats_interval(signed integer)
- change interval for collecting statistic counters
- nqps_limit(signed integer)
- limitation for the number of queue pairs
- {tx,rx}_ndescs(unsigned integer)
- the number of discriptors in txqueue or rxqueue
audioclose() freed audio_file_t structure, but only audiobellclose
didn't pass there. I change that all of freeing audio_file_t is done
by each *_close().
Ported from DragonFlyBSD, but this target had originally existed in
Linux kernel. See below for details.
https://www.kernel.org/doc/Documentation/device-mapper/delay.txt
Due to "tick" in hz(9) not working (which results in dmdlthread spinning
forever in _submit_queue() without dp extracted from delayed list
and queued into submit list), this hasn't been hooked to dm.kmod yet.
taken-from: DragonFlyBSD
properties (similar to what the "dsrtc" driver does), and provide
DT compat strings corresponding to those models. Allow config flags
to specify the model for non-FDT platforms (also like "dsrtc").
