| Age | Commit message (Collapse) | Author |
|---|
|
The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
interrupt, which overrides the trigger type specified in the device
tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
to the apps processor; registering it as level-high causes the
interrupt to not fire, resulting in missed DMA completions.
Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
trigger type already configured by platform_get_irq() when it parsed
the device tree interrupts property. This makes the driver
platform-agnostic.
Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260717-qcom-bam-dma-irq-trigger-v1-1-6405eac86f00@oss.qualcomm.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Implement support for the Allwinner A733 DMA controller by defining
A733-specific register offsets, bitfield masks, and the
`sun60i_a733_dma_cfg` configuration structure.
This includes the IRQ stride, offsets, and channel counts specific to the
A733, as well as the 32G mask for high-address fields in the LLI. Add
`sun60i_a733_dma_cfg`, which ties all the refactored functionality
together for A733.
Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260826-sun60i-a733-dma-v5-5-abc5229b441e@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The `sun6i-dma` driver previously assumed a fixed number of channels
per interrupt register. For example, `sun6i_kill_tasklet` was hardcoded
to disable interrupts only for registers 0 and 1. `DMA_MAX_CHANNELS` was
also not in used previously, and the old SoCs never has more than 16
channels.
The A733 has a different interrupt structure where the number of
channels per register may differ. Add `num_channels_per_reg` to `struct
sun6i_dma_config` to make the interrupt handling logic handware-agnostic
Update `sun6i_dma_interrupt`, `sun6i_dma_start_desc`, and
`sun6i_kill_tasklet` to use this value.
Additionally, set `DMA_MAX_CHANNELS` to 16 to ensure loops over
interrupts are correctly bounded, aligning with the hardware
specifications.
Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260826-sun60i-a733-dma-v5-3-abc5229b441e@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The Allwinner A733 DMA controller supports higher addresses (up to
32G) compared to previous generations. The existing `sun6i_dma_set_addr`
function uses hardcoded logic for setting the high-address bits in the
LLI parameters.
Add `src_high_addr_mask` and `dst_high_addr_mask` to `struct
sun6i_dma_config` to handle different high-address bitfield mappings.
Update `sun6i_dma_set_addr` to use these masks via `field_prep()`,
allowing the driver to support variable address widths.
Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260826-sun60i-a733-dma-v5-2-abc5229b441e@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The `sun6i-dma` driver currently uses hardcoded logic for interrupt
handling (reading/writing interrupt enable and status registers) and
register dumping.
To support the Allwinner A733, which has a different register layout and
interrupt handling logic, add `irq_stride`, `irq_en_offset`, and
`irq_stat_offset` to `struct sun6i_dma_config`. Implement generic
`sun6i_read/write_irq_*` functions using these new configuration fields
to accommodate different hardware revisions.
Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260826-sun60i-a733-dma-v5-1-abc5229b441e@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Advertise Instant Communication (IC) support, and when it is enabled:
- Transmit the discovery beacons disregarding the role and the state,
with the configured beacon interval and the NAN attributes set by
user space.
- Accept beacons that carry a Service ID List or a Subscribe Service
ID List attribute at any time, so that they are forwarded to
mac80211.
- Process discovery beacons received during non DW slots for anchor
master tracking and synchronization.
Assisted-by: GitHubCopilot:claude-opus-5
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Reviewed-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-12-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
- Use the discovery beacon interval configured by user space instead of
always using hardcoded 100 TUs.
- Append the NAN attributes set by user space to the locally generated
ones in the discovery beacons.
Assisted-by: GitHubCopilot:claude-opus-5
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-11-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In preparation for handling more of the NAN configuration setting, do
some refactoring and cleanup:
- Extract mac80211_hwsim_nan_set_config() and call it both when NAN is
started and when the configuration changes.
- Add NAN_BEACON_ELEM_LEN instead of the hardcoded 27.
Assisted-by: GitHubCopilot:claude-opus-5
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-10-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Use the new ieee80211_is_nan_beacon() helper to identify NAN beacons
instead of open-coding the cluster ID and vendor element checks.
Assisted-by: GitHubCopilot:claude-opus-5
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20261005084458.3666739-9-ilan.peer@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Now that we've removed any use of the page array outside of paths that
are restricted to native (non-imported) objs, we can remove use of the
deprecated function and allow msm_obj->pages to be NULL for imported
dma-bufs.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Christian König <christian.koenig@amd.com>
Patchwork: https://patchwork.freedesktop.org/patch/757711/
Message-ID: <20261002152948.85308-7-robin.clark@oss.qualcomm.com>
|
|
Use msm_obj->sgt rather than msm_obj->pages to determine that a obj is
resident. The sgt is populated up-front for imported dma-bufs, so we
will never go down the get_pages() path for imported objects.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Christian König <christian.koenig@amd.com>
Patchwork: https://patchwork.freedesktop.org/patch/757710/
Message-ID: <20261002152948.85308-6-robin.clark@oss.qualcomm.com>
|
|
The remaining callers of msm_gem_pin_pages_locked() and
msm_gem_get_pages_locked() don't actually care about pages, other
than as a conduit for returning an error. So convert them to
just directly return an int instead.
And rename _get_pages_locked() to _make_resident_locked() to
better reflect it's purpose.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Christian König <christian.koenig@amd.com>
Patchwork: https://patchwork.freedesktop.org/patch/757708/
Message-ID: <20261002152948.85308-5-robin.clark@oss.qualcomm.com>
|
|
Split out a helper to check madv state, and inline what remains of
msm_gem_get_pages_locked() in get_vaddr(). The vmap path is already
disallowed on imported dma-bufs. And the rest of the callers of
msm_gem_get_pages_locked() don't actually care about the pages, they
just want to know that the obj is resident.
This gets us one step closer to not actually caring about the page
array for imported dma-bufs.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Christian König <christian.koenig@amd.com>
Patchwork: https://patchwork.freedesktop.org/patch/757704/
Message-ID: <20261002152948.85308-4-robin.clark@oss.qualcomm.com>
|
|
This was always the way it was supposed to work, and when we drop the
page array for imported dma-bufs our fault handling path will no longer
work.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Patchwork: https://patchwork.freedesktop.org/patch/757703/
Message-ID: <20261002152948.85308-3-robin.clark@oss.qualcomm.com>
|
|
Mostly we don't care about the page array, mapping/etc works in terms of
the sgt. Add a helper to prepare for allowing the page array to be NULL
for imported dma-bufs.
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Acked-by: Christian König <christian.koenig@amd.com>
Patchwork: https://patchwork.freedesktop.org/patch/757702/
Message-ID: <20261002152948.85308-2-robin.clark@oss.qualcomm.com>
|
|
Sync changes from mesa commit 81fae85847d2 ("freedreno/registers: Sync
xml changes back from kernel").
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/757953/
Message-ID: <20261003223723.400020-1-robin.clark@oss.qualcomm.com>
|
|
Only a530/a540 have a GPMU. On the other a5xx parts, reading the
0xa800-0xac60 GPMU aperture during a crashdump resets the board -- on
sda660 (a512) a GPU hang thus reboots the SoC instead of recovering.
Split the GPMU block into its own array and collect it only when a GPMU
is present.
Fixes: e20c9284c8f2 ("drm/msm/adreno: Add support for Adreno 510 GPU")
Assisted-by: LLM
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/754867/
Message-ID: <20260920-a5xx-no-gpmu-v1-1-714200254f76@oss.qualcomm.com>
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
|
|
The "buf" buffer comes from the user. We use it to store a number or
two so it doesn't need to be large. It gets passed to sscanf() in the
write functions such as carl9170_debugfs_erp_write(). Ensure that
buffer is NUL terminated.
This is debugfs so it's root only.
Fixes: 00c4da27a421 ("carl9170: firmware parser and debugfs code")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Acked-by: Jeff Johnson <jjohnson@kernel.org>
Link: https://patch.msgid.link/674270ab4aeefa1982362c0ea4132427e14f15eb.1790839793.git.error27@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The "buf" buffer is PAGE_SIZE and allocated with kzalloc(). We store a
string from the user in it and then pass it to sscanf() in the write
functions such as tsf_write_file(). The buffer is only used to store a
number so we never come close to filling up the whole PAGE_SIZE. Reserve
the last character of the page for a NUL terminator.
This is debugfs so it's root only.
Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/909ea7a88658b5e7c183bf0fda31687a91d73818.1790839793.git.error27@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The "buf" buffer is a PAGE_SIZE and allocated with kzalloc(). We store
a string from the user in it and then pass it to sscanf() in the write
functions such as shm32write__write_file(). Only a few numbers are
stored in the buffer so it never comes close to filling up the whole
PAGE_SIZE. Reserve the last character of the page for a NUL terminator.
This is debugfs so it's root only.
Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/b396713e697c7411b23a2157e2102c347ac900bc.1790839793.git.error27@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The "twt_protected" flag in the link/bss_conf information
really isn't right since this is negotiated via RSNX and
therefore cannot differ per link. Move it to be a per-STA
indication and also derive it from the new assoc request
flag since that gets used with security profile.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260930120021.844fde440b63.I80999965c70e50d756ab62833fc7f53f2481cf3d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
mac80211_hwsim accepts CCMP and GCMP keys in mac80211_hwsim_set_key()
and encrypts unicast data frames itself in mac80211_hwsim_tx(), through
ieee80211_encrypt_tx_skb(). It asks mac80211 to reserve tailroom for the
MIC, but not headroom for the CCMP or GCMP header.
Reserve the header as driver headroom.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://patch.msgid.link/20260930084729.3000295-1-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
On Ubuntu 26.10 these firmware file are missing inside the initrd when
including the brcmfmac kernel module:
```
/usr/lib/firmware/brcm/brcmfmac43436-sdio.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43456-sdio.clm_blob.zst
```
So include the clm_blob firmware file for brcmfmac43456-sdio similar to
the other firmware files.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260923203739.2560527-3-benjamin.drung@canonical.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
On Ubuntu 26.10 these firmware file are missing inside the initrd when
including the brcmfmac kernel module:
```
/usr/lib/firmware/brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43430b0-sdio.raspberrypi,model-zero-2-w.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43436-sdio.raspberrypi,model-zero-2-w.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-a-plus.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-compute-module.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,5-compute-module.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,5-model-b.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,500.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43456-sdio.raspberrypi,4-compute-module.clm_blob.zst
/usr/lib/firmware/brcm/brcmfmac43456-sdio.raspberrypi,400.clm_blob.zst
```
Commit 885f256f61f9 ("brcmfmac: Add clm_blob firmware files to modinfo")
added clm_blob firmware binaries, but did not add them for per-board
firmware binaries. So add a similar glob for the per-board firmware
binaries.
Signed-off-by: Benjamin Drung <benjamin.drung@canonical.com>
Reviewed-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260923203739.2560527-2-benjamin.drung@canonical.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Parse and configure the extsae_pwe according to the information from the
supported rate/extended support rate and RSNX IE
Parse the beacon IEs on start_ap() and set the extsae_pwe iovar.
Set sae_pwe to 2 when the RSNX IE advertises H2E, 1 when an H2E-only
membership selector is present, 0 otherwise.
The changes are tested with FW Version 7.45.286
Signed-off-by: Girish Rudrappa <girishbukkasagara.rudrappa@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260922062458.3550-1-girishbukkasagara.rudrappa@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The NVRAM comment handler searches for a newline with strchr() even
though its input is a firmware buffer with an explicit length. A comment
at the end of an unterminated buffer can make the search read past that
input.
Keep the input extent in the parser and use bounded searches for newline
and NUL. Preserve the full input length: the capped size used to
allocate the output is not a bound on the input, which may contain more
than 64KiB of comments. Leave the outer parsing limit unchanged.
The issue was found by our static-analysis tool.
Assisted-by: gpt 5
Signed-off-by: Pengpeng Hou <hppiscas@163.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260920034414.16948-1-hppiscas@163.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This reverts commit c20bba234f3e1dcd81f7a2ec21ea7bf01a4cf35f.
The standard transport drivers were okay with the patch, but the Apple
driver needs a bit of work before it can handle the state transition
requirement.
Link: https://lore.kernel.org/linux-nvme/94912d46-381d-4988-800a-6ef3b595233f@cyberchaos.dev/
Reported-by: Yureka Lilian <yureka@cyberchaos.dev>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
Since commit 416386060 ("Mark authorization completed on driver
indication during 4-way HS offload") [0] wpa_supplicant expects
NL80211_CMD_PORT_AUTHORIZED to complete the authentication when the
driver supports 4-way handshake offload.
This was apparently never tested with the upstream brcmfmac driver as it
does not report this. This broke authentication on Apple silicon devices
(BRCM4378, BRMC4387, BRMC4388) and other devices when wpa_supplicant
2.11 was released [1]. This was initially dealt with by reverting the
commit in Fedora [2] and other Linux distributions.
Instead of carrying the revert over to wpa_supplicant 2.12 add the
expected NL80211_CMD_PORT_AUTHORIZED when the connection is established.
The "Fixes:" tag is not fully accurate as this has only became an issue
after userspace changes years after the change. Since the change is
expected to be required in all active stable branches for wpa_supplicant
2.11 / 2.12 compatibility it is helpful even though
BRCMF_PROFILE_FWSUP_SAE did not exists then.
Link: https://github.com/zephyrproject-rtos/hostap/commit/41638606054a09867fe3f9a2b5523aa4678cbfa5 [0]
Link: https://lists.infradead.org/pipermail/hostap/2024-August/042893.html [1]
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2302577 [2]
Link: https://lore.kernel.org/linux-wireless/20260911065656.1269623-5-Jason.Huang2@infineon.com/ [3]
Cc: stable@vger.kernel.org
Fixes: b8a64f0e96c2 ("brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK")
Signed-off-by: Janne Grunau <j@jannau.net>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260915-brcmfmac-4way-handshake-offload-authenticated-event-v2-1-fbb9cc7ac177@jannau.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
BCM4350 devices using brcmfmac on x86/PCIe may have no platform-provided
country code map. In that case brcmf_translate_country_code() falls back to
ISO3166 codes only for chips accepted by
brmcf_use_iso3166_ccode_fallback().
BCM4350 is currently missing from that list, despite the adjacent BCM4345
and BCM4356 being present. Add BCM4350 so these devices can use the ISO3166
country code with revision 0.
Signed-off-by: Vinícius Ramon Fontanela <vfontanela@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260915174300.28363-1-vfontanela@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Some firmwares (e.g. BCM43752) do not service the D3_INFORM mailbox
handshake when idle, so the D3 ACK never arrives. If WoWL is not armed
the device is going to be powered off during system suspend and
re-probed on resume anyway (brcmf_pcie_pm_leave_D3() handles that), so
the missing ACK is harmless and must not abort the whole system suspend.
When WoWL is active the device has to stay powered with its state
preserved, so keep treating the timeout as fatal.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260915-brcmfmac-bcm43752-suspend-fix-v2-1-1bd84914998b@collabora.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
zloop_complete_rq() handles a short read from a zone's backing file by
zero-filling every bio in the request. This is correct when the entire
request is beyond the written part of the zone. When a read request
straddles the boundary between written and unwritten data, read_iter()
returns a partial byte count and zloop then zeroes the whole request
even for the partially read area with valid data.
Such an unexpected zero data read was observed with fio test script
t/zbd/test-zbd-support and its test case 69, failing with "bad magic
header 0".
Avoid the unexpected zero data read by zeroing out only the unread tail
part. When read data size cmd->ret is smaller than the request size,
call the new helper function zloop_fill_zero_rq() that walks through
each bio_vec and fills zeros from the specified start offset.
Fixes: eb0570c7df23 ("block: new zoned loop block device driver")
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Link: https://patch.msgid.link/20260916065657.62724-1-shinichiro.kawasaki@opensource.wdc.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Add a v4l2 subdevice driver for the Sony imx576 sensor.
The Sony IMX576 image sensor with an active
array size of 5760 x 4312
The following features are supported:
- Manual exposure an gain control support
- vblank/hblank control support
- Supported resolution: 5760 x 4312 30fps (SRGGB10)
Signed-off-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io>
[Sakari Ailus: Accommodate struct v4l2_subdev_client_info introduction.]
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
When a Thunderbolt device is unplugged, that switch and every switch
subsequent to it on the bus device list is `complete()`d, not just its
child devices. In the case of multiple domains, it may cause, eg, an
attempt to `complete()` the uninitialized domain 1 root switch RPM
completion on unplug of a switch from domain 0 (though ordering is not
guaranteed numerically sorted).
I initially noticed this issue on a Dell XPS9720 when the system would
seem to sporadically not wake after unplugging a Thunderbolt dock. I
tried multiple kernel versions including v7.2.7 and v7.3-rc4 to see if
that resolved the issue, but the issue persisted. Eventually I found
that I could consistently generate a kernel Oops reporting a page fault
at 0xffff_ffff_ffff_fff8 on unplug from one side of the laptop and went
bug hunting. I became suspicious of the `bus_for_each_dev()` walk that I
ultimately ended up changing. To confirm this issue, I did an eBPF trace
of `bus_for_each_dev()`, `complete_rpm()`, and `complete()` while
unplugging in a variety of situations and found that an unplug from
domain 0 tries to `complete_rpm()` domain 1's switch, whose RPM
completion is not initialized and thus is holding a null wait-list
pointer, triggering the page fault.
Here are the key sections of that eBPF trace. Note that HEAD denotes the
completion's own wait-list HEAD:
```
RESCAN_ENTER domain=0
COMPLETE rescan_domain=0 target=0-1 target_domain=0
route=0x1 parent=0-0 unplugged=1
COMPLETION done=0 head=HEAD next=HEAD prev=HEAD
BUS_WALK domain=0 start=0-1 callback=complete_rpm
CALLBACK_ENTER rescan_domain=0 dev=1-0 parent=domain1 is_switch=1
COMPLETE rescan_domain=0 target=1-0 target_domain=1
route=0x0 parent=domain1 unplugged=0
COMPLETION done=0 head=HEAD next=0 prev=0
complete+5
complete_rpm+43
bus_for_each_dev+133
icm_free_unplugged_children+250
icm_rescan_work+42
```
This patch gates the `complete()` on an additional condition - that the
Thunderbolt domain matches the domain of the device that was unplugged.
I only have a single system with multiple Thunderbolt domains - the Dell
XPS9720. I am consistently able to reproduce the Oops on that system.
Since running with this patch, I have not seen the Oops reoccur. I have
also tested it on a Thinkpad X1-Gen12, and that system boots and runs
well with it, but it only has a single Thunderbolt domain, so it does
not exercise the multi-domain failure case.
Fixes: 4f7c2e0d8765 ("thunderbolt: Make sure device runtime resume completes before taking domain lock")
Cc: stable@vger.kernel.org
Signed-off-by: Jonathan Gopel <jgopel@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Add a new MAX9296A driver that also supports MAX96714, MAX96714F,
MAX96714R, MAX96716A and MAX96792A.
Integrate it with the common Deserializer framework, while keeping
compatibility with existing usecases, avoiding code duplication, and
also enabling more features across all chips.
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Remove the MAX96714 driver. Its functionality has been moved to the
MAX9296A driver which makes use of the Maxim GMSL2/3 serializer
framework.
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Reviewed-by: Julien Massot <julien.massot@collabora.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add a new MAX96724 driver that also supports MAX96712, MAX96724F
and MAX96724R.
Integrate it with the common deserializer framework, while keeping
compatibility with existing usecases, avoiding code duplication, and
also enabling more features across all chips.
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Tested-by: Cory Keitz <ckeitz@amazon.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Remove the staging MAX96712 driver.
Its functionality has been moved to the MAX96724 driver which makes use
of the Maxim GMSL2/3 deserializer framework.
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add a new MAX96717 driver that also supports MAX9295A, MAX96717F and
MAX96793.
Integrate it with the common serializer framework, while keeping
compatibility with existing usecases, avoiding code duplication, and
also enabling more features across all chips.
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
[Sakari Ailus: Put OF dependent pinconf callbacks behind #ifdefs.]
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Remove the MAX96717 driver. Its functionality has been moved to a new
MAX96717 driver which makes use of the Maxim GMSL2/3 serializer
framework.
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Reviewed-by: Julien Massot <julien.massot@collabora.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
These drivers are meant to be used as a common framework for Maxim
GMSL2/3 deserializer.
This framework enables support for the following new features across
all the chips:
* Full Streams API support
* .get_frame_desc()
* .get_mbus_config()
* I2C ATR
* automatic GMSL link version negotiation
* automatic stream id selection
* automatic VC remapping
* automatic pixel mode / tunnel mode selection
* automatic double mode selection / data padding
* logging of internal state and chip status registers via .log_status()
* PHY modes
* serializer pinctrl
* TPG
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
These drivers are meant to be used as a common framework for Maxim
GMSL2/3 serializers.
This framework enables support for the following new features across
all the chips:
* Full Streams API support
* .get_frame_desc()
* I2C ATR
* automatic GMSL link version negotiation
* automatic stream id selection
* automatic VC remapping
* automatic pixel mode / tunnel mode selection
* automatic double mode selection / data padding
* logging of internal state and chip status registers via .log_status()
* PHY modes
* serializer pinctrl
* TPG
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
These drivers are meant to be used as a common framework for Maxim
GMSL2/3 serializers and deserializers.
This framework enables support for the following new features across
all the chips:
* Full Streams API support
* .get_frame_desc()
* .get_mbus_config()
* I2C ATR
* automatic GMSL link version negotiation
* automatic stream id selection
* automatic VC remapping
* automatic pixel mode / tunnel mode selection
* automatic double mode selection / data padding
* logging of internal state and chip status registers via .log_status()
* PHY modes
* serializer pinctrl
* TPG
Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
The attach_addr() and detach_addr() callbacks may need to reconfigure
the remote side of the bus. Maxim GMSL deserializers, for example,
disable all links but one to reach a serializer at its default address,
since all serializers power up at the same address.
Transfers on other channels of the same ATR can run concurrently with
these callbacks and fail with -EIO while the links are disabled.
Take the ATR bus lock around both callbacks, before alias_pairs_lock.
i2c_atr_replace_mapping_by_addr() already calls them under this lock,
so ATR drivers see no new constraint.
Suggested-by: Quentin Freimanis <quentin@q-lab.dev>
Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Internal sink pads will be used as routing endpoints in V4L2 [GS]_ROUTING
IOCTLs, to indicate that the stream begins in the entity. Internal sink
pads are pads that have both SINK and INTERNAL flags set.
Also prevent creating links to pads that have been flagged as internal and
initialising SOURCE pads with INTERNAL flag set.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Martin Hecht <mhecht73@gmail.com>
Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
geni_i2c_xfer() takes a runtime-PM reference with pm_runtime_get_sync()
and then returns directly if the set_rate() callback fails, leaking the
reference and keeping the controller resumed for good. Route that error
through the existing cleanup path, which drops the reference and resets
the transfer state.
Found by code review; compile-tested with arm64 defconfig plus ACPI and
W=1.
Fixes: 10e74f4c5046 ("i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms")
Assisted-by: LLM
Signed-off-by: Rahul Pon <theflyingrahul@gmail.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260930111641.1134-1-theflyingrahul@gmail.com
|
|
Add a driver for the USB3.2 PHY on the Aspeed AST2700, which is paired
with the DWC3 controller.
The PHY draws its configuration from an internal SRAM in both of the
available modes, so the driver must wait for PHY3S00_INIT_DONE before
selecting one. PHY3S00_SRAM_BYPASS selects the default design
configuration and PHY3S00_SRAM_EXT_LOAD the ROM code configuration; the
driver uses the latter.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260916-upstream_usb3phy-v4-2-812e76037d01@aspeedtech.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The two RK3576 MIPI CSI-2 DPHYs can be supported using the existing
phy-rockchip-inno-csidphy driver, but they need their own driver data:
as on RK3588 the GRF control bits live in a dedicated CSI-DPHY GRF at
offset 0x0, while each PHY instance only has an APB reset line, as on
RK3568.
Signed-off-by: Amin Gattout <amin.gattout@gmail.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://patch.msgid.link/20260915-rk3576-dphy-v2-3-b56e68b54b8c@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add support for the PCI-Express Gen4 S-PHY found in the latest
MediaTek SoCs, including MT6991, MT8196, MT8894 and variants.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260915101022.23852-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add a driver for the MIPI M-PHY found on NVIDIA Tegra264 SoCs. The
M-PHY has two lanes, each with a transmit and a receive direction,
exposed as four PHYs to the UFS host controller.
Co-developed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Link: https://patch.msgid.link/20260909-tegra264-mphy-v1-2-ce61a80dc065@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
fs3270_ioctl() initializes rc to 0 and its cmd switch has no default
branch, so an unrecognized ioctl command returns success without doing
anything. Follow the ioctl convention and reject unknown commands with
-ENOTTY.
[hca@linux.ibm.com: shortened commit description]
Signed-off-by: Shirong Zhao <shxzhaosr@163.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
