Age | Commit message (Collapse) | Author |
|
for-6.14/block
Pull NVMe updates from Keith:
"nvme updates for Linux 6.14
- Target support for PCI-Endpoint transport (Damien)
- TCP IO queue spreading fixes (Sagi, Chaitanya)
- Target handling for "limited retry" flags (Guixen)
- Poll type fix (Yongsoo)
- Xarray storage error handling (Keisuke)
- Host memory buffer free size fix on error (Francis)"
* tag 'nvme-6.14-2025-01-12' of git://git.infradead.org/nvme: (25 commits)
nvme-pci: use correct size to free the hmb buffer
nvme: Add error path for xa_store in nvme_init_effects
nvme-pci: fix comment typo
Documentation: Document the NVMe PCI endpoint target driver
nvmet: New NVMe PCI endpoint function target driver
nvmet: Implement arbitration feature support
nvmet: Implement interrupt config feature support
nvmet: Implement interrupt coalescing feature support
nvmet: Implement host identifier set feature support
nvmet: Introduce get/set_feature controller operations
nvmet: Do not require SGL for PCI target controller commands
nvmet: Add support for I/O queue management admin commands
nvmet: Introduce nvmet_sq_create() and nvmet_cq_create()
nvmet: Introduce nvmet_req_transfer_len()
nvmet: Improve nvmet_alloc_ctrl() interface and implementation
nvme: Add PCI transport type
nvmet: Add drvdata field to struct nvmet_ctrl
nvmet: Introduce nvmet_get_cmd_effects_admin()
nvmet: Export nvmet_update_cc() and nvmet_cc_xxx() helpers
nvmet: Add vendor_id and subsys_vendor_id subsystem attributes
...
|
|
This is becoming the link_id. Since this makes no difference on non-MLD
devices, just rename to link_id for all the APIs that use the common
structure.
Starting from command 9, feed the link_id to the firmware instead of the
mac id.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241227095718.f1155e713201.I753900d10e82f339cf9679ed403027d38dc1fd58@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The statistics are not synchronized with the time that we enter EMLSR.
This means that we can receive the statistic notification just after
having cleared the counters, causing us to immediately exit EMLSR again.
Fix this by checking that most of the time for the window has passed. If
that is not the case, ignore this window and wait for the next
notification.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241227095718.0eb0f2044535.Ic2af92737ccfc873f3b6c228704238ebb9f983ca@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Due to the firmware allocating the BAID, we can only install
the data structure after the BAID is valid from the firmware's
point of view. As a result, the firmware can start sending
frame release notifications to the driver immediately. This
isn't supposed to happen by protocol, since the peer STA is
not expected to use the blockack session until the AddBA has
a response. However, firmware doesn't know that, our RX path
can't know when it was, so simply don't WARN in this case but
only have a debug message.
Since the BAID comes from firmware, also use IWL_FW_CHECK()
instead of a warning for the validity check.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241227095718.4360f2b9e185.I447f9a5fc6dfdc78ec238200338e2da040ee7e61@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of differentiating only sync/async, differentiate
the type of error, and document that only reset handshake
timeout (IWL_ERR_TYPE_RESET_HS_TIMEOUT) needs sync handling.
The special sync handling is somewhat temporary, the idea
is to later split the nic_error() method into error dump,
synchronizing the dump, and SW reset methods, and the type
is mostly in order to unify command queue full handling
into that new architecture as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241227095718.aed9c9e4fac0.I2288042bec4728a75b61cb7f6ded5214bfa3ce85@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Move TSO segment logic from mvm to the iwlwifi level, as this code is
not opmode-dependent and can be shared with the mld driver.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Link: https://patch.msgid.link/20250102163748.56efefb9566e.Ib7188572f18afb31840d193a348c17c9b292c7af@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
dump UHB canada is enabled or not based on firmware capability.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.dfd6b8893322.I196393dc3c9c28882f90b43a821a2d76a5c9a046@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
extend TAS table support to revision 2 for getting UHB canada
enablement from BIOS and send to firmware via TAS_CONFIG cmd
based on firmware capability. While on it fixed kernel-doc for
struct iwl_tas_config_cmd_v4.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.0b1d92ad59b8.Ib80f8514a64fc2800a2a20131e730c2bd9c4c4af@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Use IWL_FW_CHECK() for BAR notification size validation, improving
diagnostics with a clear error message on failure.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.913d5d476929.I8cd62f45bacc088c309b0152fc392dc2579e82e0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for new device-ids 0x2730 and 0x272F.
Signed-off-by: Somashekhar(Som) <somashekhar.puttagangaiah@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20241226174257.6a0db60436e7.I50a66544dde6c88acd9abe4b31badab96ef04cfc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
0x88 is not a regular firmware crash but a PREG NMI which means that we
access a place we're not supposed to.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.596dfc97f6b1.Iec765d5fe12ac74c6ee0035e9cb62b98c11639cb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Validate the BAR frame release size before using its fields to avoid
potential invalid memory access.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.72161a6c07c3.I4887bad2355213b201fca2da1836c9a3203ab42d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Commit 6b3e87cc0ca5 ("iwlwifi: Add support for LARI_CONFIG_CHANGE_CMD
cmd v9")
added a few bits to iwl_lari_config_change_cmd::oem_unii4_allow_bitmap
if the FW has LARI version >= 9.
But we also need to send those bits for version 8 if the FW is capable
of this feature (indicated with capability bits)
Add the FW capability bit, and set the additional bits in the cmd when
the version is 8 and the FW capability bit is set.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20241226174257.dc5836f84514.I1e38f94465a36731034c94b9811de10cb6ee5921@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
versions < 12
Commit ef7ddf4e2f94 ("iwlwifi: Add support for LARI_CONFIG_CHANGE_CMD v12")
added a few bits to iwl_lari_config_change_cmd::chan_state_active_bitmap
if the FW has LARI version >= 12.
But we also need to send those bits for version 8-11 if the FW is capable
of this feature (indicated with capability bits)
Add the FW capability bit, and set the additional bits in the cmd when
the version is 8 and the FW capability bit is set.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20241226174257.672651ad849c.I67a00d9544c48ad964f8e998ebe8c168071c3d01@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Start supporting API version 95 for new devices.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.d5b73c1e9e17.I121e155b0c1fdfb7fbac934bb2f84fe0e1d13ba0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We only logged an error in the fast resume path. However, as the
hardware is being restarted it makes sense to log an error to make it
easier to understand what is happening.
Add a new error message into the normal resume path and update the
error in the fast resume path to match.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.df1e451d4928.Ibe286bc010ad7fecebba5650097e16ed22a654e4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Enhance the documentation for the enum iwl_nvm_channel_flags to
provide better clarity for NVM_CHANNEL_IBSS and NVM_CHANNEL_ACTIVE flags
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.d4018e62b2bd.Ie20fe3408bcc358078e3e5bf38edeb6b951c9a40@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This is not MVM specific.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20241226174257.9b35dfce796b.Ie61e17a488f6a34bcbe814dd89a138fe1f55585c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently driver requests periodic statistics after entering EMLSR.
This means that when not in EMLSR, link selection decisions will be
done based on old statistics, from the association time.
Request periodic statistics already at association instead,
Signed-off-by: Somashekhar(Som) <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20241226174257.4ca59fe0e060.Ic46280aad4dc7087a7d6d0773b86c255133cb7d6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
As the session protection command will be used in mld, it shouldn't
be associated by name to mvm
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Link: https://patch.msgid.link/20241226174257.0cd9ae2499b6.If228310b0578e5da88ccb28ff8dceb56e1c61b27@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Now it neither sets the ret argument or return something else than
false.
Cleanup this function to be void and to not receive the ret argument.
This also allows to get rid of the sta_in_fw parameter in
iwl_mvm_mld_free_sta_link.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20241224192322.ecebfa16c62c.Ia1cc352b871593be4f51cb3db98f9eedd5267857@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently, the sequence goes like this (among others):
1. flush all stations (including the AP ones) -> this will tell the
drivers to remove the stations
2. notify the driver the vif is not associated.
Which means that in between 1 and 2, the state is that the vif is
associated, but there is no AP station, which makes no sense, and may be
problematic for some drivers (for example iwlwifi)
Change the sequence to:
1. flush the TDLS stations
2. move the AP station to IEEE80211_STA_NONE
3. notify the driver about the vif being unassociated
4. flush the AP station
In order to not break other drivers, add a vif flag to indicate whether
the driver wants to new sequence or not. If the flag is not set, then
things will be done in the old sequence.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20241224192322.996ad1be6cb3.I7815d33415aa1d65c0120b54be7a15a45388f807@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
in iwl_mvm_sta_del we call iwl_mvm_sec_key_remove_ap with link id 0,
when it might actually be something else, causing us to skip all
the keys.
Since the call to iwl_mvm_sec_key_remove_ap was mostly skipped (because
for STA mode we are not removing the ap sta immediately, but later when
the vif is set to unassocicated),
this was fine.
The other call to iwl_mvm_sec_key_remove_ap, when we actually do remove the
ap sta, was called with the right link id. So the bug didn't happen so far.
Now that mac80211 is going to change such that we can immediately
remove the ap sta, the call to iwl_mvm_sec_key_remove_ap with link id 0
will not be skipped, so no key will be removed, and then when
mac80211 eventually tells us to remove that keys, we no longer have the
sta ids for them.
Simply pass the right link id to iwl_mvm_sec_key_remove_ap.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20241224192322.db7a5f551492.I79fe16a14fa0bb20751ba2526c3195fef39ef772@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This code is only relevant for older devices, that are not supporting
mld, so shouldn't be in iwl_mvm_sta_del, which is common to both pre-mld
and mld.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20241224192322.a665d16a3857.I840b00a7b38f3967ec5e75ff6a85e756f4d82437@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The inverse value is stored in the table, make the documentation match the code.
Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Acked-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/2008554.usQuhbGJ8B@devpool47.emlix.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Restrict the check for the number of pages handled during an ODP page
fault to direct mkeys.
Perform the check right after handling the page fault and don't
propagate the number of handled pages to callers.
Indirect mkeys and their associated direct mkeys can have different
start addresses. As a result, the calculation of the number of pages to
handle for an indirect mkey may not match the actual page fault
handling done on the direct mkey.
For example:
A 4K sized page fault on a KSM mkey that has a start address that is not
aligned to a page will result a calculation that assumes the number of
pages required to handle are 2.
While the underlying MTT might be aligned will require fetching only a
single page.
Thus, do the calculation and compare number of pages handled only per
direct mkey.
Fixes: db570d7deafb ("IB/mlx5: Add ODP support to MW")
Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
Reviewed-by: Artemy Kovalyov <artemyko@nvidia.com>
Link: https://patch.msgid.link/86c483d9e75ce8fe14e9ff85b62df72b779f8ab1.1736187990.git.leon@kernel.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
In multi-channel scenarios, the granted channel must be aborted before
station remove. Otherwise, the firmware will be put into a wrong state,
resulting in have chance to make subsequence scan no APs.
With this patch, the granted channel will be always aborted before
station remove.
Signed-off-by: Quan Zhou <quan.zhou@mediatek.com>
Reviewed-by: Sean Wang <sean.wang@mediatek.com>
Tested-by: David Ruth <druth@chromium.org>
Reviewed-by: David Ruth <druth@chromium.org>
Link: https://patch.msgid.link/1ac1ae779db86d4012199a24ea2ca74050ed4af6.1721300411.git.quan.zhou@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Wireshark and iwlwifi use zero-based NSS reporting, adjust
mt76 to do the same.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Link: https://patch.msgid.link/20240909211238.3237111-2-greearb@candelatech.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
This duplicates what the 7925 driver is doing, wireshark seems to
at least mostly decode it as expected.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Link: https://patch.msgid.link/20240909211238.3237111-1-greearb@candelatech.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
commit c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop
period") changes the behavior of mt7915_bss_info_changed() in mesh mode
when enable_beacon becomes false: it calls mt7915_mcu_add_bss_info(...,
false) and mt7915_mcu_add_sta(..., false) while the previous code
didn't. These sends mcu commands that apparently confuse the firmware.
This breaks scanning while in mesh mode on AsiaRF MT7916 DBDC-based cards:
scanning works but no mesh frames get sent afterwards and the firmware
seems to be hosed. It breaks on MT7916 DBDC but not on MT7915 DBDC.
Fixes: c4f075582304 ("wifi: mt76: mt7915: fix command timeout in AP stop period")
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Link: https://patch.msgid.link/20240927085350.4594-1-nicolas.cavallari@green-communications.fr
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
To ensure code clarity and prevent potential errors, it's advisable
to employ the ';' as a statement separator, except when ',' are
intentionally used for specific purposes.
Signed-off-by: Shen Lichuan <shenlichuan@vivo.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20240911034243.31596-1-shenlichuan@vivo.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
This comparison should be >= instead of > to prevent an out of bounds
read and write.
Fixes: 9679ca7326e5 ("wifi: mt76: mt7925: fix a potential array-index-out-of-bounds issue for clc")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/84bf5dd2-2fe3-4410-a7af-ae841e41082a@stanley.mountain
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The maximum command quota of the firmware may be exceeded because the
command to retrieve the quota setting has not been taken into account.
This patch considers not only the quota usage of the command retrieving
quota settings but also limits the total quota usage.
Signed-off-by: Leon Yen <leon.yen@mediatek.com>
Signed-off-by: Ming Yen Hsieh <mingyen.hsieh@mediatek.com>
Link: https://patch.msgid.link/20240916060157.10157-1-mingyen.hsieh@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Regist the NL80211_IFTYPE_P2P_DEVICE to support p2p device
for mt792x chips
Signed-off-by: Hao Zhang <hao.zhang.mediatek@gmail.com>
Signed-off-by: allan.wang <allan.wang@mediatek.com>
Signed-off-by: Ming Yen Hsieh <MingYen.Hsieh@mediatek.com>
Link: https://patch.msgid.link/20240919081713.23787-1-mingyen.hsieh@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Some of the variants do not support background radar, so add a helper
to report background radar capability.
Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/20240926032440.15978-3-shayne.chen@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Current varaints supported:
- mt7996 chipset: tri-band, 4+4+4 NSS, eFEM
- mt7992 chipset: dual-band, 4+4 NSS, eFEM
This patch adds support for the following variants:
- mt7996 chipset:
- tri-band, 4+4+4 NSS, iFEM
- tri-band, 2+3+3 NSS, eFEM
- tri-band, 2+3+3 NSS, iFEM
- mt7992 chipset:
- dual-band, 4+4 NSS, iFEM
- dual-band, 4+4 NSS, with band0 iFEM and band1 eFEM
- dual-band, 2+3 NSS, eFEM
- dual-band, 2+3 NSS, iFEM
Co-developed-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/20240926032440.15978-2-shayne.chen@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Support passing customized buffer pointer and length to
mt7996_mcu_get_eeprom().
This is the preparation for adding more variants support which needs to
prefetch FEM module from efuse, and also fixes potential OOB issue when
reading the last efuse block.
Co-developed-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: StanleyYP Wang <StanleyYP.Wang@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Tested-by: Daniel Golle <daniel@makrotopia.org>
Link: https://patch.msgid.link/20240926032440.15978-1-shayne.chen@mediatek.com
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Use U32 to get value from ACPI and explicitly cast to U16.
Fixes: 5282e45ccbfa ("HID: intel-thc-hid: intel-quicki2c: Add THC QuickI2C ACPI interfaces")
Signed-off-by: Even Xu <even.xu@intel.com>
Link: https://patch.msgid.link/20250113085047.2100403-1-even.xu@intel.com
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
Return -ENOMEM if the allocation fails. Don't return success.
Fixes: 4228966def88 ("HID: intel-thc-hid: intel-thc: Add THC I2C config interfaces")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/eb4ea363-c3b7-4988-9ff5-5ed74bf47620@stanley.mountain
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
|
|
Extend HDMI connector output format tests to verify its registration
succeeds only when the presence of YUV420 in the supported formats
matches the state of ycbcr_420_allowed flag.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241224-bridge-conn-fmt-prio-v4-4-a9ceb5671379@collabora.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
Ensure HDMI connector initialization fails when the presence of
HDMI_COLORSPACE_YUV420 in the given supported_formats bitmask doesn't
match the value of drm_connector->ycbcr_420_allowed.
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241224-bridge-conn-fmt-prio-v4-3-a9ceb5671379@collabora.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
The case of having an HDMI bridge in the pipeline which advertises
YUV420 capability via its ->supported_formats and a non-HDMI one that
didn't enable ->ycbcr_420_allowed, is incorrectly handled because
supported_formats is passed as is to the helper initializing the HDMI
connector.
Ensure HDMI_COLORSPACE_YUV420 is removed from the bitmask passed to
drmm_connector_hdmi_init() when connector's ->ycbcr_420_allowed flag
ends up not being set.
Fixes: 3ced1c687512 ("drm/display: bridge_connector: handle ycbcr_420_allowed")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241224-bridge-conn-fmt-prio-v4-2-a9ceb5671379@collabora.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
Bridges having DRM_BRIDGE_OP_HDMI set in their ->ops are supposed to
rely on the ->supported_formats bitmask to advertise the permitted
colorspaces, including HDMI_COLORSPACE_YUV420.
However, a new flag ->ycbcr_420_allowed has been recently introduced,
which brings the necessity to require redundant and potentially
inconsistent information to be provided on HDMI bridges initialization.
Adjust ->ycbcr_420_allowed for HDMI bridges according to
->supported_formats, right before adding them to the global bridge list.
This keeps the initialization process straightforward and unambiguous,
thereby preventing any further confusion.
Fixes: 3ced1c687512 ("drm/display: bridge_connector: handle ycbcr_420_allowed")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241224-bridge-conn-fmt-prio-v4-1-a9ceb5671379@collabora.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
|
|
Set the gpiochip request and free ops to the generic implementations.
This way a user can provide a gpio-ranges property defined for a pinmux,
easing muxing of gpio functions. Provided that the pin controller
implementents the pinmux op .gpio_request_enable(), pins will
automatically be muxed to their GPIO function when requested.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Acked-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20250107201621.12467-1-sander@svanheule.net
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
struct altera_gpio_chip::mapped_irq is only used in the driver's probe
function. So it's enough if mapped_irq is a local variable, and can be
dropped from driver data.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250109090802.3763275-2-u.kleine-koenig@baylibre.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
GPIO input, output, and interrupts have been tested on a MPC8314E board.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250102-mpc83xx-v1-13-86f78ba2a7af@posteo.net
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
With the recent rework of the PCI power control code, the workaround for
the wlan-enable GPIO - where we don't set a default (low) state in the
power sequencing driver, but instead request the pin as-is - should no
longer be needed but some platforms still fail to probe the WLAN
controller. This is caused by the Qcom PCIe controller and needs a
workaround in the controller driver so add a FIXME to eventually remove
the hack from this driver once this is done.
Link: https://lore.kernel.org/r/20250102121530.26993-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
|
|
Remove hard-coded strings by using the str_enabled_disabled() helper
function.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://lore.kernel.org/r/20250112100655.55741-2-thorsten.blum@linux.dev
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
|
|
If zram_meta_alloc failed early, it frees allocated zram->table without
setting it NULL. Which will potentially cause zram_meta_free to access
the table if user reset an failed and uninitialized device.
Link: https://lkml.kernel.org/r/20250107065446.86928-1-ryncsn@gmail.com
Fixes: 74363ec674cb ("zram: fix uninitialized ZRAM not releasing backing device")
Signed-off-by: Kairui Song <kasong@tencent.com>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
|
|
drm-next
Updates for v6.14
MDSS:
- properly described UBWC registers
- added SM6150 (aka QCS615) support
MDP4:
- several small fixes
DPU:
- added SM6150 (aka QCS615) support
- enabled wide planes if virtual planes are enabled (by using two SSPPs for a single plane)
- fixed modes filtering for platforms w/o 3DMux
- fixed DSPP DSPP_2 / _3 links on several platforms
- corrected DSPP definitions on SDM670
- added CWB hardware blocks support
- added VBIF to DPU snapshots
- dropped struct dpu_rm_requirements
DP:
- reworked DP audio support
DSI:
- added SM6150 (aka QCS615) support
GPU:
- Print GMU core fw version
- GMU bandwidth voting for a740 and a750
- Expose uche trap base via uapi
- UAPI error reporting
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsutUu4ff6OpXNXxqf1xaV0rV6oV23VXNRiF0_OEfe72Q@mail.gmail.com
|