Introduce SPI-mode support which allows an SD card to communicate with a
host system using SPI protocol, as described in the SD Card Specification.
This feature is useful for low-end, FPGA or RISC-V research systems when a
SoC is limited in terms of peripherals available (e.g. lack of a dedicated
MMC controller in hardware). Examples of such systems include Codasip,
lowRISC and CVA6.
Project timeline:
2007: Warner first discussed SPI operational mode in his MMC presentation:
https://people.freebsd.org/~imp/bsdcan2007.pdf
2012: Patrick Kelsey engineered the support.
2025: Ruslan cleaned up, tested on Codasip X730 platform (RISC-V FPGA)
and put the patch to review.
2025: Patrick Kelsey reviewed the patch and aligned with the current MMC
code.
Reviewed by: pkelsey
Sponsored by: UKRI
Differential Revision: https://reviews.freebsd.org/D49248
- Introduce the bus_type accessor, which allows to skip card selection
and timing settings in SPI mode;
- Add MMC_CMD_IS_APP flag for commands followed by the APP command,
which is required by the upcoming MMCSPI driver.
Reviewed by: pkelsey
Sponsored by: UKRI
Differential Revision: https://reviews.freebsd.org/D49249
Replace cable type detection with connector type for more accurate media
type selection. The connector type is queried directly from the PTYS
register and provides more reliable information about the physical port
type compared to cable type.
Reviewed by: slavash
Sponsored by: NVidia networking
MFC after: 1 week
fdt_immr_* are only used by the armv7 Marvell code. Move setting the
variables there as no new code should need to set them.
Reviewed by: cognet
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49535
fdt_data_get and fdt_data_to_res don't change the value of the data
passed to them via a pointer. Add const to these pointers.
Reviewed by: emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49703
These have been replaces with fdt_foreach equivalents so are unused.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49702
As with fdt_foreach_mem_region add a function that calls a callback
for each reserved memory region in /memreserve. This allows us to
exclude this memory from the physical map in a way that is safe from
overflowing a fixed array on the stack.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49699
As with fdt_foreach_mem_region add a function that calls a callback
for each reserved memory region. This allows us to exclude this memory
from the physical map in a way that is safe from overflowing a fixed
array on the stack.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49698
This is used early in the boot to find physical memory. Previously it
needed an array of memory regions to be passed in. We keep finding
hardware where this array is too small causing the kernel to smash the
stack.
Replace with a function that takes a callback that can insert the
memory into the physical map directly.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49697
Some implementations of the virtio 9p transport are implemented on
virtio_mmio, e.g. the Arm FVP. Use the correct macro so the driver
attaches when this is the case.
Reviewed by: markj
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D49600
On arm64 we use the iommu base address as an xref. This fails when
the address has the lower 32-bits in common with another iommu as
they will share an xref.
Reviewed by: kib
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48726
This is a from scratch, minimally viable, I²C driver for QCOM's
GENI serial engine.
No QCOM documentation is available, so other FOSS device drivers
were consulted to figure things out
The driver works on T14s G6 "Snapdragon" hardware, to such a degree
that ACPI clients and HID devices work (polling mode & needs
modifications to iichid)
Differential Revision: https://reviews.freebsd.org/D49676
Reviews by: adrian
A recent change in GEOM ordering (c11b701915 -
"geom: Push GEOM sysinit ordering to after devctl" changed the GEOM init
ordering to SI_ORDER_THIRD. However, the FDT slicer / GEOM flash
slice code needs the GEOM subsystem to be initialised before it
starts loading in flash slices from FDT, and will panic because
the mutex isn't initialised.
So bump this now to SI_ORDER_FOURTH, so it occurs after the GEOM
initialisation.
Differential Revision: https://reviews.freebsd.org/D49692
Reviewed by: jhibbits
The Snapdragon X1E / Lenovo T14s device tree has 47 reserved memory
regions. The reserved region parsing doesn't boundary check and will
just end up array bounds smashing, which leads to a reboot before
any console IO is written.
Differential Revision: https://reviews.freebsd.org/D49689
Reviewed by: manu, phk
gcc_sleep_clk_src does not exist, just use sleep_clk directly.
I believe this is what feeds them anyway!
This node isn't in the Linux clock driver (drivers/clk/qcom) ipq401x
clock tree, but there are sleep_clk_src nodes in the tree in
ipq50xx, ipq54xx, ipq60xx, ipq8xxxx, ipq9xxxx, msm8xxx, etc.
Differential Revision: https://reviews.freebsd.org/D49686
The device tree renamed master -> core, so rename the fields here.
Locally tested:
* IPQ4019, ASUS RT-AC58U, USB works (enough for umass!)
Differential Revision: https://reviews.freebsd.org/D49684
Reviewed by: manu
Although the driver structure is almost supportive of multiple
chipsets, there's a lot of subtle hard coded IPQ4018 assumptions
here.
This is a partial refactor of the driver in order to have a single
qcom_gcc driver that will eventually support multiple chipsets.
* rename qcom_gcc_ipq4018 -> qcom_gcc
* remove the ipq4018 specific naming from things
* create a table to drive probe/attach, with a chipset id to
use during attach
* migrate the clock register accessors to not be ipq4018 specific
* migrate the reset register accessors to not be ipq4018 specific
Note this won't compile (yet) for an arm64 kernel because there's
a hard-coded clock tree for an earlier 64 bit MSM part in
sys/arm64/qualcomm/qcom_gcc.c . That will need to be rolled into this
driver.
Differential Revision: https://reviews.freebsd.org/D49683
This change introduces new sysctl handlers that allow the user to change
RX/TX ring sizes. As before, the default ring sizes will come from the
device (usually 1024). We also get the max/min limits from the device.
In the case min values are not provided we have statically defined
constants for the min values. Additionally, if the modify ring option is
not enabled on the device, changing ring sizes via sysctl will not be
possible. When changing ring sizes, the interface turns down
momentarily while allocating/freeing resources as necessary.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49428
This change introduces new sysctl handlers that allow the user to change
RX/TX queue counts. As before, the default queue counts will be the max
value the device can support. When chaning queue counts, the interface turns
down momentarily while allocating/freeing resources as necessary.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49427
Every tx and rx ring has its own queue-page-list (QPL) that serves as
the bounce buffer. Previously we were allocating QPLs for all queues
before the queues themselves were allocated and later associating a QPL
with a queue. This is avoidable complexity: it is much more natural for
each queue to allocate and free its own QPL.
Signed-off-by: Vee Agarwal <veethebee@google.com>
Reviewed by: markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D49426
When a device fails to attach, or a module is unloaded, we want to be
able to unregister the xref as the device goes away. While the device_t
may still be valid, it won't be providing whatever functionality the
consumer that follows the xref wants it for and thus, we should not
keep it discoverable.
[Commit message re-worded by kevans@]
Reviewed by: ian, imp
Differential Revision: https://reviews.freebsd.org/D22945
The widest value used with code is 32 bits, other values are smaller.
Reduce this down. Update printfs.
This fixes the build on i386.
Reviewed by: bapt, emast, kevans, adrian
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49634
The new code makes use of FDT/OFW types and interfaces, and obviously
fails to build on amd64. Revert to fix.
Pointy-hat-to: mhorne
This reverts commit e69623451e.
PCIe mandates a 5 second delay between when the "Attention Button" is
pressed and when the associated device is detached; this is to allow
for the button to be pressed a second time to cancel the ejection. On
some systems this 5 second delay may not be desireable; so introduce a
hw.pci.pcie_hp_detach_timeout sysctl (which can also be set as a loader
tunable) which specifies the timeout in milliseconds (default 5000).
If set to zero, the device is detached immediately.
Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49585
Found on the VisionFive v2 SBC, and similar.
Reviewed by: mhorne
Tested by: mhorne
Discussed with: sos
Differential Revision: https://reviews.freebsd.org/D45600
This is a revival of the old exynos4210 driver, with some additional
bits to configure the apple "s5l" uart (which is actually slightly
different to operate).
This hasn't been tested on anything that would hit the non-s5l path, so
banish it off to the apple/ domain until someone cares to confirm that
none of the other hardware is broken -- it may be that nobody does, but
the complexity isn't too bad: mostly the driver1 construct added to the
uart_bas that we use to avoid having a whole bunch of shims for uart
driver methods and hardcoded references to the cfg structs.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48120
and the difference between start and entry->start values at this point.
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Without the wait, mlx5e_destroy_rq() might free mbuf that is passed up
to the network stack on receive in mlx5e_poll_rx_cq().
Sponsored by: NVidia networking
MFC after: 1 week
This driver originates from OpenBSD and was ported to FreeBSD by Future
Crew LLC who kindly provided a source release.
iwx supports many recent Intel WiFi card and this driver should support running
these cards with legacy, HT and VHT rates. There are some issues remaining in
the port, but at this point wider testing is sought.
To avoid breaking deployed WiFi configurations iwx probes with a lower
priority than iwlwifi. This can be changed by blocking iwlwifi with
devmatch.
Reviewed by: adrian
Obtained from: Future Crew LLC
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D49259
whu@ cannot reproduce the assertion failure which led to these ifdefs
being added in the first place, and since they appear wrong, i.e., the
assertions ought to apply to all platforms, let's remove them.
This reverts commits 0af5a0cd27 and
6f7b1310b6.
PR: 285681
Tested by: whu
MFC after: 2 weeks
- The BUS_DMA_KEEP_PG_OFFSET flag is needed, since
storvsc_xferbuf_prepare() assumes that only the first segment may have
a non-zero offset, and that all following segments are page-sized and
-aligned.
- storvsc_xferbuf_prepare() handles 64-bit bus addresses, so avoid
unneeded bouncing on i386.
PR: 285681
Reported by: dim
Tested by: dim, whu
MFC after: 2 weeks
This call was meant to be the default case in the first place, but
somehow missed this.
Reported by: glebius
Fixes: 4021fa32d9 ("sound: Simplify pcm/feeder_mixer.c")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Lock around uses of devclass_*() and replace leftover
CTLFLAG_NEEDGIANTs with CTLFLAG_MPSAFE.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D46700
Reduce ifdefs, and add aliases for the unsigned formats.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D48009
Even though the OSS manual [1] advises against using AFMT_FLOAT, there
are applications that expect the sound driver to support it, and might
not work properly without it.
This patch adds AFMT_F32_LE|BE (as well as AFMT_FLOAT for OSS
compatibility) in sys/soundcard.h and implements AFMT_F32_LE|BE <->
AFMT_S32_LE|BE conversion functions. As a result, applications can
write/read floats to/from sound(4), but internally, because sound(4)
works with integers, we convert floating point samples to integer ones,
before doing any processing.
The reason for encoding/decoding IEEE754s manually, instead of using
fpu_kern(9), is that fpu_kern(9) is not supported by all architectures,
and also introduces significant overhead.
The IEEE754 encoding/decoding implementation has been written by Ariff
Abdullah [2].
[1] http://manuals.opensound.com/developer/AFMT_FLOAT.html
[2] https://people.freebsd.org/~ariff/utils/ieee754.c
PR: 157050, 184380, 264973, 280612, 281390
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47638
Make vchanrate and vchanformat reflect the primary channel's software
buffer's rate and format respectively. Fix previous inconsistencies.
Get rid of the initializations in vchan_create() and move them to
chn_init().
Without the feeder_rate_round check in sysctl_dev_pcm_vchanrate(), we
can set the software rate to anything between feeder_rate_min and
feeder_rate_max. If we keep the check, however, the rate is limited to
whatever the driver's min/max is, which can be a problem if, for
example, the driver supports only a single rate, in which case we won't
be able to set anything other than the driver rate.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D48961
There is a (very historical) call to pci_assign_interrupt for the
purpose of routing IRQs which may have been set up wrong by x86 BIOS
or firmware. On non-x86 systems, this is unnecessary; and on INTRNG
systems it results in a (synthetic) IRQ leak and ultimately a kernel
panic after many hotplug/unplug cycles.
Suggested by: jhb
Reviewed by: jhb
MFC after: 2 weeks
Sponsored by: Amazon
Differential Revision: https://reviews.freebsd.org/D49560
Check if CTS bit is set in the mailbox message before waiting for ACK.
Otherwise ACK will never be received causing the function to timeout. Add
a note for ixgbe_write_mbx that it should be called while holding a lock.
Fixes: 6d243d2 ("net/ixgbe/base: introduce new mailbox API")
Cc: stable@dpdk.org
Signed-off-by: Norbert Ciosek <norbertx.ciosek@intel.com>
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Obtained from: DPDK (1f119e4)
MFC after: 1 week
This is the more typical pattern for other capability register sets,
and two of these variables weren't used.
Differential Revision: https://reviews.freebsd.org/D49267
Depend on the PCI bus driver clearing PME# after resume to remove the
need for clearing PME# from DEVICE_RESUME methods.
Use pci_has_pm and pci_enable_pme.
Reviewed by: Krzysztof Galazka <krzysztof.galazka@intel.com>
Differential Revision: https://reviews.freebsd.org/D49251
pci_has_pm is a quick check that returns true if a PCI device supports
the power management capability.
pci_enable_pme can be used in DEVICE_SUSPEND driver methods to enable
PME# during suspend.
Reviewed by: Krzysztof Galazka <krzysztof.galazka@intel.com>x
Differential Revision: https://reviews.freebsd.org/D49250
The PCI power management specification requires that the OS clear any
pending PME# interrupt and generation of PME# interrupts during
"initial operating system load". Note that clearing a pending PME#
interrupt requires writing a 1 to the Read/Write-Clear PME bit in the
power management status register. To handle the boot time case, clear
PME# state in pci_read_cap() when scanning new PCI devices. This
should also cover hotplug devices.
In addition, clear this state on every PCI device after resume from
sleep in pci_resume_child before invoking the driver's DEVICE_RESUME
method.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D49222
