- We check PHY register read error correctly (timeout and NFE_PHY_ERROR), so
don't check NFE_PHY_DATA register's value with 0xffffffff or 0. At least,
some registers may have 0.
- Check NFE_PHY_ERROR bit in nfe_miibus_writereg().
- Improve debug printf
is detected:
- If DATA64_EN isn't set in CFG after a reset, don't use 64-bit data path
at all (it's been disabled by an EEPROM setting).
- Provide a hook for force-disabling the 64-bit data path.
- Otherwise, perform the "known 64-bit cards" check as done previously
(because dodgy-vendor-EEPROM-settings still applies).
- On some variations, the internal PHY is ghosted at #0 and #1. Work
around this by ignoring PHY #0 accesses unless we don't find one, and
then look for one there as a fall-back if we don't detect anything else.
- Fix access width when setting the TxDMAUrgentThresh register.
- Support MBUFTRACE.
accordingly and structure it like other NetBSD drivers so as to re-use
the original Rx buffer rather than doing a needless free/alloc cycle.
Note this happened to work previously on my Qube2 because IP, TCP, etc.
perform their own alignment checks and react accordingly. However, it's
not clear that ALL protocols do this yet, so it's better to just do the
safe thing for now.
- Fix an mbuf leak I introduced in rev 1.68 (failed to increment "cnt"
variable in txp_start(), which subsequently caused txp_tx_reclaim()
to never run).
- Use the context address pointer in the Tx descriptor to stash the
pointer to the Tx job software state in a manner like that which
is used for Rx software state.
time, and create a simple allocator for them for use by the rx reclaim
handlers. Don't create and destroy DMA maps for receoive buffers
in the interrupt handlers -- just use the maps that are created at
attach time.
number, and structure the loop in txp_start() similarly to other drivers
(e.g. ste_start() in the ste(4) driver). Similar in spirit to OpenBSD's
rev 1.126, but implemented a bit differently.
DMA addresses into a 64-bit value (and thus using 64-bit shifts
when unnecessary), just reference the address from the DMA map
directly.
- Add some missing byte-swaps.
This did not do what I thought it did. opt_diagnostic.h is only for
the unused _DIAGNOSTIC, which seems like an abortive attempt to
incrementally convert DIAGNOSTIC to an opt_*.h option rather than a
command-line option.
For sticky parameters (encoding, precision, channels, sample_rate and pause):
- AUDIO_SETINFO for nonexistent track updates sticky parameters.
- AUDIO_GETINFO for nonexistent track reads sticky parameters.
For blocksize, hiwat, lowat and {play.record}.buffer_size:
- AUDIO_SETINFO for nonexistent track does nothing.
- AUDIO_GETINFO for nonexistent track returns dummy non-zero values.
Nonexistent track is a playback track on O_RDONLY descriptor for example,
or both tracks on /dev/audioctl.
ixl(4) has not the limitation that it must not send packet when
link is down. And most of the other NIC drivers do not refer to it
when sending packets.
reviewed by knakahara@n.o, thanks.
and receives Get link status response in parallel
sc->sc_link_state_atq.iatq_fn is used in ixl_atq_done_locked()
with sc->sc_atq_lock, but it was cleared in ixl_get_link_status()
without the lock.
struct disk_sectoralign {
/* First aligned sector number. */
uint32_t dsa_firstaligned;
/* Number of sectors per aligned unit. */
uint32_t dsa_alignment;
};
- Teach wd(4) to get it from ATA.
- Teach cgd(4) to pass it through from the underlying disk.
- Teach dk(4) to pass it through with adjustments.
- Teach zpool (zfs) to take advantage of it.
=> XXX zpool doesn't seem to understand when the vdev's starting
sector is misaligned.
Missing:
- ccd(4) and raidframe(4) support -- these should support _using_
DIOCGSECTORALIGN to decide where to start putting ccd or raid
stripes on disk, and these should perhaps _implement_
DIOCGSECTORALIGN by reporting the stripe/interleave factor.
- sd(4) support -- I don't know any obvious way to get it from SCSI,
but if any SCSI wizards know better than I, please feel free to
teach sd(4) about it!
- any ld(4) attachments -- might be worth teaching the ld drivers for
nvme and various raid controllers to get the aligned sector size
There's some duplicate logic here for now. I'm doing it this way,
rather than gathering the logic into a new disklabel_sectoralign
function or something, so that this change is limited to adding a new
ioctl, without any new kernel symbols, in order to make it easy to
pull up to netbsd-9 without worrying about the module ABI.
When the number of the hardware channels becomes less than the number of
channels that sticky parameters remember, subsequent open("/dev/sound") will
fail without this treatment. This is for rev 1.43.
If a disk is backed by a physical medium other than itself, such as
cgd(4), then it passes DK_DUMP_RECURSIVE to disable the recursion
detection for dk_dump.
If, however, a device represents a physical medium on its own, such
as wd(4), then it passes 0 instead.
With this, I can now dump to dk on cgd on dk on wd.
(Technically this also allows dumping to a dk(4) on which there
happens to be a cgd(4) configured, but I'm not sure how to
distinguish that case here. So don't do that!)
- Add a comment explaining that if we were to use more than one
Rx ring / Rx Return ring, all of the Rx-related control data
would need to be in the same 4G segment.
DMA addresses. Modeled after similar usage in the bge(4) driver (the
chips supported by bge(4) are descendants of those supported by ti(4)).
- Use the 64-bit PCI DMA tag if available, otherwise we're allocating (and
using) bounce buffers needlessly.
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!)
