| Age | Commit message (Collapse) | Author |
|---|
|
There are no users of omap_tw4030_pdata in the mainline kernel so
remove support for it from the driver.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Link: https://patch.msgid.link/20260724233432.31325-1-dmitry.torokhov@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SINEGAIN2_REG case in cali_reg_update() references t->sin_gn[]
rather than t->sin_gn2[], causing the second pilot tone gain
calibration to be programmed with the wrong register address.
These are distinct fields in struct fct_param_address and are
populated from separate firmware parameters by the parser in
tas2781-fmwlib.c.
Fixes: 84d6a465f211 ("ASoC: tas2781: Support dsp firmware Alpha and Beta seaies")
Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260720081616.631413-1-wangdich9700@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Charles Keepax <ckeepax@opensource.cirrus.com> says:
Currently there exists a couple races that can result in the DAPM graph
coming up in a state that doesn't match the hardware with respect to
SDCA jack detection. This series fixes these up by adding a component
level fixup_controls helper into the asoc core and shuffling around the
IRQ requests from the SDCA side.
The core creates DAPM widgets/routes quite a long time before
it creates the associated ALSA control, and the jack detection
IRQ is currently registered in component probe. At the time of
component probe, the DAPM widgets exist, shortly after this the
DAPM routes are added. At the time the DAPM routes are added the
register value for the control is checked and the appropriate path
is connected. The existing handling in the SDCA jack IRQ handles
the case the control doesn't exist and updates the registers
directly, which works until the DAPM routes are added. After the
routes are added the DAPM graph has already set connected on a
particular DAPM path, which will not be updated until an IRQ is
received when the control is present. Thus those updates are
usually not reflected in the resulting DAPM graph which can lead
to the audio path being erroneously powered on/off.
Link: https://patch.msgid.link/20260721143636.361814-1-ckeepax@opensource.cirrus.com
|
|
Now that the IRQs are always registered after all the ALSA
controls are created it is possible to search for the control
at the point the IRQ is requested. Move the control search out
of the IRQ handler and do it at IRQ request time.
This also fixes a potential issue when the card was torn down
and reprobed without destroying the codec device, the kctl
pointer stored by the IRQ handler would not be updated to the
new control on the second probe.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260721143636.361814-8-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently there are some race conditions around the boot of SDCA
jack detection. The core creates DAPM widgets/routes quite a
long time before it creates the associated ALSA control, and
the jack detection IRQ is currently registered in component
probe. At the time of component probe, the DAPM widgets exist,
shortly after this the DAPM routes are added. At the time the DAPM
routes are added the register value for the control is checked
and the appropriate path is connected. The existing handling
in the SDCA jack IRQ handles the case the control doesn't exist
and updates the registers directly, which works until the DAPM
routes are added. After the routes are added the DAPM graph has
already set connected on a particular DAPM path, which will not
be updated until an IRQ is received when the control is present.
Thus those updates are usually not reflected in the resulting
DAPM graph which can lead to the audio path being erroneously
powered on/off.
Switch to the new fixup_controls callback to register the
IRQs, this is guaranteed to run after all the controls have
been created. Which means we can avoid the aforementioned race
condition and as a bonus no longer need to concern ourselves
with a case where the IRQ handler runs and the ALSA control
is unavailable.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260721143636.361814-7-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
A card level fixup_controls callback was added in:
commit df4d27b19b89 ("ASoC: Introduce 'fixup_controls' card method")
This allowed the machine driver to take actions after all the
card controls have been added. However, there are times when a
codec driver would also want to do things like obtain references
to controls for later use, which require all the controls to be
present. Add a component level fixup_controls callback, echoing
the card level option.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260721143636.361814-6-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, the IRQ data (attached Entity/Control/etc) is populated
as the IRQ is requested. However, this can cause issues as
occasionally the setup process wants to access specifics of
an IRQ before the IRQ is actually enabled. To facilitate this
cache all the IRQ data during sdca_irq_populate_early() and make
sdca_irq_populate() simply request the outstanding IRQs. This
also has the advantage that sdca_irq_populate() can now just
iterate through the IRQ array which is much smaller/faster than
going through every Entity in the Function for Controls.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260721143636.361814-5-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
To provide greater flexibility on when the IRQs are requested for
client drivers don't use devm for the primary IRQ request/cleanup
helper functions.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260721143636.361814-4-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SDCA IRQs are split into two groups, those registered at bus probe
time (basically just FDL) and those registered at component time.
There currently exists only a single cleanup function, if the FDL IRQ
is freed at component time, then nothing would re-register it if the
component is probed again. But the IRQs depending on a component need
to be freed if the card is destroyed so they can't use stale
components.
Split the clean up into two functions one for the component level and
one for the bus level.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260721143636.361814-3-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Make it more clear sdca_irq_allocate() uses devm allocations by adding
it into the name.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260721143636.361814-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Replace open-coded resource handling with devm helpers:
- spi_alloc_host -> devm_spi_alloc_host
- of_address_to_resource + ioremap + request_mem_region
-> devm_platform_ioremap_resource
- request_irq -> devm_request_irq
- remove now-unused mapbase/mapsize fields from struct ppc4xx_spi
- move of_node_put(opbnp) earlier to simplify error paths
- delete the entire error-unwinding goto chain
Move devm_platform_ioremap_resource() and platform_get_irq() up in order
to avoid doing work if -EPROBE_DEFER is returned.
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260720003043.1536358-1-rosenp@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The controller is allocated with the non-managed spi_alloc_host() while
the interrupt is registered with devm_request_irq(). During removal,
spi_bitbang_stop() only unregisters the controller; the subsequent
spi_controller_put() then frees the controller together with its
embedded driver-private devdata, which is the IRQ handler's dev_id. The
devm_request_irq() release action (free_irq()), which drains the
handler, does not run until after .remove() returns. A late or latched
interrupt can therefore reach tiny_spi_irq() and dereference
already-freed memory (e.g. hw->base).
Switch to devm_spi_alloc_host() so that the devres LIFO order releases
the controller only after free_irq() has drained the handler, and drop
the now-redundant spi_controller_put() from .remove(). The probe error
path is simplified to direct returns.
This issue was found by an in-house static analysis tool.
Fixes: ce792580ea2c ("spi: add OpenCores tiny SPI driver")
Assisted-by: Codex:gpt-5.6
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Link: https://patch.msgid.link/20260719010014.3163356-1-fanwu01@zju.edu.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For a HCI_VENDOR_PKT frame, hci_recv_frame() does not accept it and
will kfree_skb() it directly.
But btmrvl_sdio_card_to_host() is still calling hci_recv_frame() for
the frame.
Fix by freeing it with kfree_skb() directly.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Simplify btintel_classify_pkt_type() by using hci_acl_handle() instead of:
__u16 handle = __le16_to_cpu(hci_acl_hdr(skb)->handle);
... hci_handle(handle) ...
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Simplify btusb_recv_bulk() by using hci_acl_dlen() instead of:
__le16 dlen = hci_acl_hdr(skb)->dlen;
... __le16_to_cpu(dlen) ...
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Simplify hci_recv_frame() by using hci_acl_handle() instead of:
__u16 handle = __le16_to_cpu(hci_acl_hdr(skb)->handle);
... hci_handle(handle) ...
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Introduce both helpers for ACL packet since:
both core and transport drivers extract the handle and data length
from its header in several places.
Both will be used later.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Add btusb_prepare_reset() to do cleanup before a reset, and
apply it to btusb_mtk_reset() as well.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Both helpers currently take struct btusb_data *, which is private to
btusb.c, as parameter type as below:
int btusb_recv_event(struct btusb_data *data, struct sk_buff *skb)
int btusb_recv_acl(struct btusb_data *data, struct sk_buff *skb)
To allow vendor USB-transport-specific source files to share them as
well, change the type to struct hci_dev *.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Introduce hci_devcd_state_name() to describe the devcoredump state by a
string name instead of a plain number, for several reasons:
1) Applying it in coredump.c makes the devcoredump state in log messages
more readable than a plain number.
2) Transport drivers may need to show the devcoredump state name too.
3) In future, the universal state name could be notified to userspace
via uevent, allowing a universal application (e.g. a daemon) to be
developed to save the coredump, which is otherwise discarded by the
device coredump core after 5 minutes (DEVCD_TIMEOUT); see
nxp_coredump_notify().
Also drop a trailing space from two bt_dev_dbg() format strings while
applying it in coredump.c.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
btintel_diagnostics() accesses tlv->val[0] without first validating
that the diagnostics VSE is long enough to contain that field, so
may cause reading data beyond the received frame.
Fix by validating the length before access.
Fixes: af395330abed ("Bluetooth: btintel: Add Intel devcoredump support")
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
|
|
Mahua has a different QREF topology from Glymur. Override the TCSR
compatible to qcom,mahua-tcsr in mahua.dtsi, and wire up the required
LDO supplies on the CRD board.
Unlike the other PCIe controllers, PCIe5 PHY on Mahua gets its refclk
from the CXO0 pad directly and requires no QREF clkref_en voting. Hence,
point its ref clock at RPMH_CXO_CLK.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260721-tcsr_qre_0721-v10-7-d2fa68c63b78@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The TCSR clkref_en clocks gate the QREF block which provides reference
clocks to the PCIe PHYs. Wire up the LDO supplies required by the QREF
and refgen blocks on the CRD board.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260721-tcsr_qre_0721-v10-6-d2fa68c63b78@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Some SPI-NAND devices with large OOB areas require a stronger ECC
configuration than the default one provided through firmware
description. For example, Macronix devices with a 256-byte OOB area
report that 4-bit ECC is insufficient and trigger:
nand: WARNING: the ECC used on your system is too weak compared
to the one required by the NAND chip
The QPIC SPI-NAND controller supports both 4-bit and 8-bit BCH ECC
modes. When a device exposes an OOB area of at least 128 bytes, there
is sufficient space to accommodate 8-bit ECC without exceeding the OOB
layout constraints.
Automatically increase the ECC strength to 8 bits when the detected OOB
size is 128 bytes or larger and the current configuration requests a
weaker ECC level. This avoids ECC capability mismatches on devices that
require stronger error correction and improves reliability.
Signed-off-by: Md Sadre Alam <md.alam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-8bitecc-v1-1-6eef4bcc3a14@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Document Nord SA8797P QUP GENI SPI controller, which is compatible with
SA8255P controller.
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260714120226.1788391-1-shengchao.guo@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com> says:
This series add support for sound card on Qualcomm Hawi boards.
Link: https://patch.msgid.link/20260713180907.874954-1-prasad.kumpatla@oss.qualcomm.com
|
|
Add compatible for sound card on Qualcomm Hawi platform.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713180907.874954-3-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add bindings for Hawi sound card, which is compatible with
the existing SM8450.
Signed-off-by: Prasad Kumpatla <prasad.kumpatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713180907.874954-2-prasad.kumpatla@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
ublk_ctrl_add_dev() memcpy()s the userspace ublksrv_ctrl_dev_info into
ub->dev_info and then fixes up the fields the driver owns, but misses
->state and ->ublksrv_pid.
A device added with ->state = UBLK_S_DEV_LIVE passes the
"->state != UBLK_S_DEV_DEAD" test that ublk_stop_dev_unlocked() uses as its
proxy for "a disk is attached", while ->ub_disk is still NULL, so DEL_DEV
right after ADD_DEV oopses in del_gendisk(). UBLK_S_DEV_QUIESCED plus
UBLK_F_USER_RECOVERY dies one step earlier, in ublk_force_abort_dev(). A
poisoned ->state also gets START_USER_RECOVERY and the char device
read/write path onto a device that was never started, and wedges START_DEV
at -EEXIST. A poisoned ->ublksrv_pid just makes GET_DEV_INFO report an
unrelated task as the ublk server.
Reset both after the memcpy(), as ublk_detach_disk() does. Userspace only
ever reads these back, so correcting them silently breaks nothing.
ADD_DEV has copied ->state in unsanitized since ublk was merged, but back
then it was harmless: the gendisk was allocated during ADD_DEV, and both
teardown and the START_DEV -EEXIST check keyed off disk_live() rather than
->state. The oops became reachable once the disk allocation moved to
START_DEV and those checks switched to ->state.
Fixes: 6d9e6dfdf3b2 ("ublk: defer disk allocation")
Cc: stable@vger.kernel.org
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Caleb Sander Mateos <csander@purestorage.com>
Link: https://patch.msgid.link/20260726145025.1507383-1-tom.leiming@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
atmel_asoc_wm8904_dt_init() will be updated when Card capsuling.
To makes its review easy, use dev in this function and reduce
un-related diff.
No functional change, but is preparation for cleanup driver.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/878q75jfny.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The MCU firmware copies the rsc table to a fixed address (0x1FFF8000) at
startup. However, this address is occupied by variables used in the MCU
firmware, so copying the rsc table there corrupts those variables.
Move the rsc-table reserved memory region from 0x1FFF8000 to 0x20000000
to avoid the conflict. The M33 firmware linker script has been updated
accordingly to place the rpmsg resource table at 0x20000000 (DTCM
m_rsc_tbl region).
Signed-off-by: Biwen Li <biwen.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add remoteproc nodes for the two Cortex-M7 cores (CM7-0, CM7-1) and
the Cortex-M33S core, along with their respective reserved memory
regions for firmware, virtio device vrings, resource tables and
shared DMA pools. Enable the MU11, MU13 and MU15 mailbox units used
for inter-processor communication with each remote processor.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add remoteproc CM7 node and reserved memory regions to enable the
Cortex-M7 remote processor. The reserved memory includes firmware
memory, virtio device vring buffers and a resource table for
inter-processor communication via the MU7 mailbox.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Add remoteproc CM7 node and reserved memory regions to enable the
Cortex-M7 remote processor. The reserved memory includes firmware
memory, virtio device vring buffers, a resource table and a shared
DMA pool for inter-processor communication via the MU7 mailbox.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Enable LPUART4 and configure its pin multiplexing to expose the UART
interface on the Symphony expansion header.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
When calling into arch code to make the underlying memory private, i.e. to
assign memory to the VM in SNP's RMP table, assign/convert *exactly* the
range of memory that can be mapped into the guest for the current page
fault, instead of aggressively converting/assigning the entire folio. For
SNP, the mapping size in the stage-2 page tables (Nested Page Tables, NPT)
must be at least the size of the corresponding RMP entry, e.g. assigning a
2MiB mapping in the RMP when it can only be mapped at 4KiB granualarity
will ultimate result in another page fault (#NPF for SNP) to "smash" the
RMP down to the correct mapping size.
Assigning the entire folio was necessary back when guest_memfd tracked
preparedness, which was done on a per-folio basis. At the time, it made
sense to do per-folio tracking/preparation, because tracking per-folio
meant guest_memfd didn't need to add a separate data structure to track
that information, and doing per-folio tracking only works if the entire
folio is prepared (or not).
Now that guest_memfd no longer does preparation tracking (see commit
8622ef05709f ("KVM: guest_memfd: Remove preparation tracking")), in favor
having SNP query the RMP, per-folio preparation, i.e. per-folio conversions
to private, doesn't make any sense.
*If* SNP allowed the RMP size to be greater than the NPT size, then
per-folio conversion could theoretically provide marginal value, as it
would allow KVM to assign a hugepage in the RMP even if it can only be
mapped into the NPT with a smaller page, e.g. because of memslot alignment.
The documentation of that reasoning would be something like this:
/*
* If the memory is private from KVM's perspective, and hardware tracks
* VM-assigned private memory in a dedicated data structure, i.e. not
* in the stage-2 page tables, then call into arch code to assign the
* entire folio to the guest. Assigning the entire folio, e.g. instead
* of only the memory being mapped into the guest, allows KVM to assign
* an entire hugepage of memory in the out-of-band structure even if
* KVM can only map a smaller page size into the MMU, e.g. because the
* gmem hugepage is spread across multiple memslots.
*/
But even *if* a future SNP implementation supported that behavior, the
value added would be dubious, as having a huge folio that is fully private,
but can only be mapped at a smaller granularity, would be rare. E.g. maybe
for memory at the top of lower DRAM that has holes for non-RAM assets?
So, convert/assign exactly what guest_memfd allows the caller to map to
simplify the guest_memfd code and provide a (super) minor performance
optimization for SNP. E.g. once hugepage support comes along, guest_memfd
will only need a single flow to compute "how much memory can be assigned
and at what size".
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://patch.msgid.link/20260723210811.72720-10-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Tweak the guest_memfd make_private() hook to explicitly pass the number of
pages to align with the signature of the make_shared() hook, and because
the existing code is outright broken if a guest_memfd folio is comprised of
more than one page (which can't happen, yet). The SNP code *tries* to
create a corresponding huge entry, but if the RMP must use 4KiB entries for
whatever reason, KVM will only convert the first pfn, and not the entire
range of pfns that will be mapped into the guest.
Alternatively, @max_order could simply be repurposed as _the_ @order, but
that will fall apart when in-place conversion comes along, at which point
KVM will need to deal with conversions that aren't bound 1:1 to a folio.
I.e. the number of pages to convert may not be exactly a power-of-2 (and
folios don't strictly guarantee power-of-2 pages anyways).
WARN in the SNP code if the number of pages to prepare is anything other
than '1', i.e. if guest_memfd is trying to prepare/convert more than a
single 4KiB page, as sev_gmem_prepare() doesn't actually handle conversion
greater than order-0 folios.
Opportunistically swap the ordering of @pfn and @gfn params for
kvm_x86_ops.gmem_make_private() to match kvm_arch_gmem_make_private().
Fixes: b85524314a3d ("KVM: guest_memfd: delay kvm_gmem_prepare_folio() until the memory is passed to the guest")
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://patch.msgid.link/20260723210811.72720-9-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Rework guest_memfd's prepare() hook into a more accurate make_private(),
and rework its Kconfig from PREPARE to a more generic CONVERT. This will
allow x86 to share (pun intended) a kvm_x86_ops.gmem_make_shared() hook
between the "convert to shared" and "reclaim" flows, which are one and the
same for SNP.
No functional change intended.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20260723210811.72720-8-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
When getting a guest_memfd pfn, prepare the folio, i.e. convert its pages
to private, if and only if the page is actually private. The misnamed
prepare() hook exists specifically to allow x86's SNP to assign pages to
the owning VM in the RMP when mapping private memory into a guest.
Guarding the call will allow renaming the prepare() hook to better reflect
its role, without creating a semantic mess, and will become a hard
requirement once in-place conversion is supported, i.e. when CoCo VMs
support SHARED guest_memfd pages.
For all intents, no functional change intended (the sole arch hook is a nop
for SHARED memory).
Suggested-by: Michael Roth <michael.roth@amd.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
[sean: rewrite changelog to fit the context]
Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Link: https://patch.msgid.link/20260723210811.72720-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Add helpers to check if a given page in a guest_memfd instance is PRIVATE
versus SHARED, and use the "is shared" helper instead of an open-coded
equivalent in the user pagefault handler. In addition to the immediate
usage, providing an "is private" helper will allow cleaning up the so
called prepare() code, and eventually will be heavily used once in-place
conversion support comes along.
No functional change intended.
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20260723210811.72720-6-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Drop guest_memfd's ratelimited printk to log "preparation" failures, as KVM
SNP already logs more precise messages in all error paths, and whether or
not failure to convert the pfn to private is "unexpected", i.e. warrants
logging, is firmly an architecture specific detail.
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20260723210811.72720-5-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Rename kvm_x86_ops's gmem_invalidate() hook to gmem_make_shared(), as the
hook doesn't invalidate anything, and so that KVM doesn't need to add yet
another vendor callback to support "convert to shared" once in-place
conversion comes along.
Opportunistically wrap the ops declarations with a GMEM_RECLAIM guard so
that attempting to wire up a .gmem_make_shared() hook without selecting
CONFIG_HAVE_KVM_ARCH_GMEM_RECLAIM will result in a build failure.
No functional change intended.
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20260723210811.72720-4-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Rename guest_memfd's invalidate() hook to reclaim() and isolate it via its
own RECLAIM Kconfig, as the hook is called when a folio is freed, which is
far too late and lacks sufficient information for KVM to actually
invalidate its usage of the memory. E.g. SNP uses the hook to convert
memory back to SHARED so that it can be safely accessed by the host, there
is no invalidation of guest mappings anywhere. Isolating the hook will
also allow pKVM on arm64 to opt-in to reclaim() without also having to
differentiate between reclaim and conversions to shared for active VMs.
Keep guest_memfd's trampoline, even though it would be trivial to wire up
.free_folio() directly to an arch callback, to avoid bleeding guest_memfd
internals into arch code (specifically, avoid referencing folios in arch
code).
Leave the kvm_x86_ops hook as-is for the moment, as "reclaim" on SNP is
the same as convert-to-shared, i.e. using a different name for the x86 hook
will allow reusing it for in-place conversion.
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Link: https://patch.msgid.link/20260723210811.72720-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
.invalidate()
Pass the number of pages to "invalidate", i.e. reclaim, instead of the end
pfn, as a first step towards aligning the function prototypes between the
de facto "to private" and "to shared" arch hooks. Eventually, the goal
is to end up with kvm_gmem_arch_make_{private,shared}(), and in both cases,
providing the number of pages makes the call sites slightly nicer, and also
avoids any confusion over whether the end pfn is inclusive or exclusive.
Opportunistically rename "start" to "pfn", again to align with the expected
signature of make_private() (which needs to pass a starting gfn as well, at
which point the "start" becomes noise).
No functional change intended.
Cc: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Link: https://patch.msgid.link/20260723210811.72720-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
|
|
Since the commit mentioned down below, it looks like we've been triggering
this WARN_ON():
[ 31.477009] ------------[ cut here ]------------
[ 31.477012] [PLANE:66:curs-0] pixel format with alpha exposed but
blend mode not setup
[ 31.477014] WARNING: drivers/gpu/drm/drm_mode_config.c:872 at
drm_mode_config_validate+0x38c/0x4c0, CPU#1: modprobe/1264
[ 31.477125] CPU: 1 UID: 0 PID: 1264 Comm: modprobe Not tainted
7.2.0-rc2Lyude-Test+ #1 PREEMPT(lazy)
[ 31.477129] Hardware name: Micro-Star International Co., Ltd.
MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.M4 05/10/2023
[ 31.477132] RIP: 0010:drm_mode_config_validate+0x394/0x4c0
[ 31.477136] Code: 41 3b 9e 80 00 00 00 73 bd 49 8b 46 78 8b 3c 98 e8
c1 3d ff ff 80 78 14 00 74 e1 48 8d 3d 64 e6 e7 01 49 8b 56 18 41 8b 76
50 <67> 48 0f b9 3a 49 8b 46 08 4c 8d 70 f8 49 39 c5 75 97 8b 95 b8 02
[ 31.477139] RSP: 0018:ffffd48e053bb7f8 EFLAGS: 00010202
[ 31.477143] RAX: ffffffffaf1da9c0 RBX: 0000000000000000 RCX: 0000000000000034
[ 31.477145] RDX: ffff8cd883c1feb0 RSI: 0000000000000042 RDI: ffffffffb069f840
[ 31.477148] RBP: ffff8cd88ea3d800 R08: 0000000034325241 R09: ffff8cd88ea3dac0
[ 31.477150] R10: fffffaf5c4043600 R11: ffff8cd88004f600 R12: 0000000000000001
[ 31.477152] R13: ffff8cd88ea3da90 R14: ffff8cd88b9ec038 R15: ffff8cd88ea3dab0
[ 31.477154] FS: 00007fb934898780(0000) GS:ffff8cd9f3a6a000(0000) knlGS:0000000000000000
[ 31.477157] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 31.477160] CR2: 0000555efff79520 CR3: 0000000122cd5000 CR4: 00000000003506f0
[ 31.477162] Call Trace:
[ 31.477165] <TASK>
[ 31.477168] ? nouveau_hwmon_init+0x2d6/0x330 [nouveau]
[ 31.477346] drm_dev_register+0x19d/0x270
[ 31.477352] nouveau_drm_device_init+0x17a/0x230 [nouveau]
[ 31.477523] nouveau_drm_probe+0x13d/0x1e0 [nouveau]
[ 31.477690] local_pci_probe+0x3e/0x90
[ 31.477697] pci_call_probe+0x59/0x190
[ 31.477702] ? srso_return_thunk+0x5/0x5f
[ 31.477706] ? pci_match_device+0x15a/0x180
[ 31.477710] ? pci_assign_irq+0x2d/0x160
[ 31.477714] pci_device_probe+0x95/0x160
[ 31.477719] call_driver_probe+0x26/0x100
[ 31.477724] ? driver_sysfs_add+0x59/0xd0
[ 31.477738] really_probe+0xcc/0x2c0
[ 31.477743] ? srso_return_thunk+0x5/0x5f
[ 31.477749] __driver_probe_device+0x85/0x170
[ 31.477754] driver_probe_device+0x1f/0x90
[ 31.477760] ? __pfx___driver_attach+0x10/0x10
[ 31.477766] __driver_attach+0xcb/0x210
[ 31.477772] bus_for_each_dev+0x85/0xd0
[ 31.477779] bus_add_driver+0x13e/0x220
[ 31.477786] ? __pfx_init_module+0x10/0x10 [nouveau]
[ 31.477979] driver_register+0x75/0xe0
[ 31.477984] ? srso_return_thunk+0x5/0x5f
[ 31.477990] nouveau_drm_init+0x8b/0xff0 [nouveau]
[ 31.478192] do_one_initcall+0x5d/0x300
[ 31.478204] do_init_module+0x86/0x290
[ 31.478212] init_module_from_file+0xd8/0x140
[ 31.478223] idempotent_init_module+0x114/0x310
[ 31.478233] __x64_sys_finit_module+0x71/0xe0
[ 31.478238] do_syscall_64+0xe2/0x630
[ 31.478252] ? srso_return_thunk+0x5/0x5f
[ 31.478257] ? vfs_read+0x165/0x390
[ 31.478267] ? srso_return_thunk+0x5/0x5f
[ 31.478271] ? srso_return_thunk+0x5/0x5f
[ 31.478276] ? switch_fpu_return+0x52/0xe0
[ 31.478282] ? srso_return_thunk+0x5/0x5f
[ 31.478286] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90
[ 31.478292] ? srso_return_thunk+0x5/0x5f
[ 31.478296] ? do_syscall_64+0x11f/0x630
[ 31.478301] ? srso_return_thunk+0x5/0x5f
[ 31.478305] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90
[ 31.478310] ? srso_return_thunk+0x5/0x5f
[ 31.478314] ? do_syscall_64+0x11f/0x630
[ 31.478320] ? srso_return_thunk+0x5/0x5f
[ 31.478324] ? arch_exit_to_user_mode_prepare.isra.0+0x7e/0x90
[ 31.478329] ? srso_return_thunk+0x5/0x5f
[ 31.478334] ? srso_return_thunk+0x5/0x5f
[ 31.478338] ? do_syscall_64+0x99/0x630
[ 31.478343] ? exc_page_fault+0x82/0x1c0
[ 31.478350] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 31.478355] RIP: 0033:0x7fb93410030d
[ 31.478372] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 5a 0f 00 f7 d8 64 89 01 48
[ 31.478375] RSP: 002b:00007ffc587ce738 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 31.478381] RAX: ffffffffffffffda RBX: 0000562f5fb3da60 RCX: 00007fb93410030d
[ 31.478385] RDX: 0000000000000000 RSI: 0000562f5fb40590 RDI: 000000000000000d
[ 31.478388] RBP: 00007ffc587ce7d0 R08: 0000000000000000 R09: 0000000000000000
[ 31.478391] R10: 0000000000000000 R11: 0000000000000246 R12: 0000562f5fb40590
[ 31.478394] R13: 0000000000040000 R14: 0000562f5fb3db80 R15: 0000000000000009
[ 31.478404] </TASK>
[ 31.478407] ---[ end trace 0000000000000000 ]---
Fix it by making sure we unconditionally call
drm_plane_create_blend_mode_property for all types of wndws, including
those (such as cursors) without a blend_set function.
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260720215058.398210-4-lyude@redhat.com
|
|
While we don't currently read-in the hardware state of planes, now that
we're about to start exposing blend properties for all planes that can
support alpha channels: We need to make sure that the initial atomic state
for a wndw always starts off with a supported value in pixel_blend_mode.
The easiest way to do this is to introduce a nv50_wndw_default_state()
function, and use it in nv50_display_read_hw_state() - and use that
function to enforce a valid value for pixel_blend_mode during driver
startup.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Link: https://patch.msgid.link/20260720215058.398210-3-lyude@redhat.com
|
|
At the moment, we currently (incorrectly) only expose a blend property on
the plane if we have a nv50_wndw_func->blend_set function for the given
wndw type. But we need to expose a blend property for all types of planes
that can display color formats with an alpha channel.
Prepare for doing this by introducing a way of looking up the supported
blend modes for a type of wndw by introducing .blend_modes, which describes
all possible blending modes nouveau currently supports for a type of wndw.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Fixes: 860e748bddcc ("drm: ensure blend mode supported if pixel format with alpha exposed")
Link: https://patch.msgid.link/20260720215058.398210-2-lyude@redhat.com
|
|
Fixes:
[ 0.182121] WARNING: CPU: 0 PID: 1 at drivers/nvmem/brcm_nvram.c:85 brcm_nvram_probe+0x400/0x480
[ 0.182159] Unexpected (big) NVRAM size: 1056112 B
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://lore.kernel.org/r/20260628231049.1248899-1-rosenp@gmail.com
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
|
|
Rename the board model from "NXP i.MX8ULP EVK9" to "NXP i.MX8ULP 9x9
EVK" to follow the i.MX naming convention where the die size (9x9 mm)
is used instead of an opaque board revision suffix.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
|
Change to use standard drive strength and slow slew rate on
PTE14-17, 22, 23, otherwise the overshoot of ENET is too high.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
|
