Currently both the wmi_bcn_tmpl_cmd and wmi_prb_tmpl_cmd structs
define:
u8 data[1];
Per the guidance in [1] both instances of this should be flexible
arrays. However during conversion it was discovered that neither of
these structs are actually used, so just remove them.
No functional changes, compile tested only.
[1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231213-wmi_host_mem_chunks_flexarray-v1-4-92922d92fa2c@quicinc.com
Currently struct wmi_pdev_chanlist_update_event defines:
struct wmi_channel channel_list[1];
Per the guidance in [1] this should be a flexible array. However
during conversion it was discovered that this struct is not used, so
just remove the entire struct.
No functional changes, compile tested only.
[1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231213-wmi_host_mem_chunks_flexarray-v1-3-92922d92fa2c@quicinc.com
Currently ath10k defines the following struct:
struct wmi_start_scan_tlvs {
u8 tlvs[0];
} __packed;
Per the guidance in [1] this should be a flexible array. However, a
direct replace to u8 tlvs[] results in the compilation error:
flexible array member in a struct with no named members
This is because C99 6.7.2.1 (16) requires that a structure containing
a flexible array member must have more than one named member.
So rather than defining a separate struct wmi_start_scan_tlvs which
contains the flexible tlvs[] array, just define the tlvs[] array where
struct wmi_start_scan_tlvs is being used.
No functional changes, compile tested only.
[1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231213-wmi_host_mem_chunks_flexarray-v1-2-92922d92fa2c@quicinc.com
Currently struct wmi_host_mem_chunks defines:
struct host_memory_chunk items[1];
Per the guidance in [1] this should be a flexible array. However there
is a documented requirement:
some fw revisions require at least 1 chunk regardless of count
To satisfy this requirement, follow the guidance from [2] and wrap the
array in a union which contains both the flexible array and a single
instance of the underlying struct. Since the footprint of the struct
is unchanged, no additional driver changes are required.
No functional changes, compile tested only.
[1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays
[2] https://lore.kernel.org/linux-wireless/202308301529.AC90A9EF98@keescook/
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231213-wmi_host_mem_chunks_flexarray-v1-1-92922d92fa2c@quicinc.com
In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal
strength should be used in comparison against RSSI when
selecting first LNA as the main one. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231117093056.873834-11-u.kleine-koenig@pengutronix.de
The rate macros are for AR9002 and not correct for AR9003.
The AGC 3 macros are unused and have incorrect values, at least for
QCN5502, where AR_AGC3_BASE should be 0x2de00.
This change does not appear to affect the final binary.
Signed-off-by: Wenli Looi <wlooi@ucalgary.ca>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20230629231625.951744-3-wlooi@ucalgary.ca
Since 'ath11k_wmi_tlv_parse_alloc()' always operates on
'skb->data, skb->len' tuple, it may be simplified to pass
the only 'skb' argument instead (which also implies
refactoring of 'ath11k_pull_bcn_tx_status_ev()' and
'ath11k_pull_chan_info_ev()' in the same way). Compile
tested only.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231214161117.75145-1-dmantipov@yandex.ru
We should check whether the WMI_TLV_TAG_STRUCT_MGMT_TX_COMPL_EVENT tlv is
present before accessing it, otherwise a null pointer deference error will
occur.
Fixes: dc405152bb ("ath10k: handle mgmt tx completion event")
Signed-off-by: Xingyuan Mo <hdthky0@gmail.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://msgid.link/20231208043433.271449-1-hdthky0@gmail.com
__bio_for_each_segment assumes that the first struct bio_vec argument
doesn't change - it calls "bio_advance_iter_single((bio), &(iter),
(bvl).bv_len)" to advance the iterator. Unfortunately, the dm-integrity
code changes the bio_vec with "bv.bv_len -= pos". When this code path
is taken, the iterator would be out of sync and dm-integrity would
report errors. This happens if the machine is out of memory and
"kmalloc" fails.
Fix this bug by making a copy of "bv" and changing the copy instead.
Fixes: 7eada909bf ("dm: add integrity target")
Cc: stable@vger.kernel.org # v4.12+
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
After commit db5e653d7c ("md: delay choosing sync action to
md_start_sync()"), md_start_sync() will hold 'reconfig_mutex', however,
in order to make sure event_work is done, __md_stop() will flush
workqueue with reconfig_mutex grabbed, hence if sync_work is still
pending, deadlock will be triggered.
Fortunately, former pacthes to fix stopping sync_thread already make sure
all sync_work is done already, hence such deadlock is not possible
anymore. However, in order not to cause confusions for people by this
implicit dependency, delay flushing event_work to dm-raid where
'reconfig_mutex' is not held, and add some comments to emphasize that
the workqueue can't be flushed with 'reconfig_mutex'.
Fixes: db5e653d7c ("md: delay choosing sync action to md_start_sync()")
Depends-on: f52f5c71f3 ("md: fix stopping sync thread")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Jiri Olsa says:
====================
bpf: Add check for negative uprobe multi offset
hi,
adding the check for negative offset for uprobe multi link.
v2 changes:
- add more failure checks [Alan]
- move the offset retrieval/check up in the loop to be done earlier [Song]
thanks,
jirka
---
====================
Link: https://lore.kernel.org/r/20231217215538.3361991-1-jolsa@kernel.org
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
We fail to create uprobe if we pass negative offset. Add more tests
validating kernel-side error checking code.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Song Liu <song@kernel.org>
Link: https://lore.kernel.org/bpf/20231217215538.3361991-3-jolsa@kernel.org
Currently the __uprobe_register will return 0 (success) when called with
negative offset. The reason is that the call to register_for_each_vma and
then build_map_info won't return error for negative offset. They just won't
do anything - no matching vma is found so there's no registered breakpoint
for the uprobe.
I don't think we can change the behaviour of __uprobe_register and fail
for negative uprobe offset, because apps might depend on that already.
But I think we can still make the change and check for it on bpf multi
link syscall level.
Also moving the __get_user call and check for the offsets to the top of
loop, to fail early without extra __get_user calls for ref_ctr_offset
and cookie arrays.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Song Liu <song@kernel.org>
Link: https://lore.kernel.org/bpf/20231217215538.3361991-2-jolsa@kernel.org
These models use 2xCS35L41amps with HDA using SPI and I2C.
Models use internal and external boost.
All models require DSD support to be added inside
cs35l41_hda_property.c
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20231218151221.388745-8-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These models use 2xCS35L41amps with HDA using SPI and I2C.
Models use internal and external boost.
All models require DSD support to be added inside
cs35l41_hda_property.c
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20231218151221.388745-6-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These models use 2xCS35L41amps with HDA using SPI and I2C.
All models use Internal Boost.
Some models also use Realtek Speakers in conjunction with
CS35L41.
All models require DSD support to be added inside
cs35l41_hda_property.c
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20231218151221.388745-4-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This make use of the CS35L41 HDA Property framework, which supports
laptops which do not have the _DSD properties in their ACPI.
Add configuration table to be able to use a generic function which allows
laptops to be supported just by adding an entry into the table.
Use configuration table function for existing system 103C89C6.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20231218151221.388745-2-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 6624e780a5 ("ice: split ice_vsi_setup into smaller
functions") has refactored a bunch of code involved in PFR. In this
process, TC queue number adjustment for XDP was lost. Bring it back.
Lack of such adjustment causes interface to go into no-carrier after a
reset, if XDP program is attached, with the following message:
ice 0000:b1:00.0: Failed to set LAN Tx queue context, error: -22
ice 0000:b1:00.0 ens801f0np0: Failed to open VSI 0x0006 on switch 0x0001
ice 0000:b1:00.0: enable VSI failed, err -22, VSI index 0, type ICE_VSI_PF
ice 0000:b1:00.0: PF VSI rebuild failed: -22
ice 0000:b1:00.0: Rebuild failed, unload and reload driver
Fixes: 6624e780a5 ("ice: split ice_vsi_setup into smaller functions")
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Chandan Kumar Rout <chandanx.rout@intel.com> (A Contingent Worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Previously, the ice driver had support for using a handler for bonding
netdev events to ensure that conflicting features were not allowed to be
activated at the same time. While this was still in place, additional
support was added to specifically support SRIOV and LAG together. These
both utilized the netdev event handler, but the SRIOV and LAG feature was
behind a capabilities feature check to make sure the current NVM has
support.
The exclusion part of the event handler should be removed since there are
users who have custom made solutions that depend on the non-exclusion of
features.
Wrap the creation/registration and cleanup of the event handler and
associated structs in the probe flow with a feature check so that the
only systems that support the full implementation of LAG features will
initialize support. This will leave other systems unhindered with
functionality as it existed before any LAG code was added.
Fixes: bb52f42ace ("ice: Add driver support for firmware changes for LAG")
Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
When there is bpf_list_head or bpf_rb_root field in map value, the free
of map btf and the free of map value may run concurrently and there may
be use-after-free problem, so add two test cases to demonstrate it. And
the use-after-free problem can been easily reproduced by using bpf_next
tree and a KASAN-enabled kernel.
The first test case tests the racing between the free of map btf and the
free of array map. It constructs the racing by releasing the array map in
the end after other ref-counter of map btf has been released. To delay
the free of array map and make it be invoked after btf_free_rcu() is
invoked, it stresses system_unbound_wq by closing multiple percpu array
maps before it closes the array map.
The second case tests the racing between the free of map btf and the
free of inner map. Beside using the similar method as the first one
does, it uses bpf_map_delete_elem() to delete the inner map and to defer
the release of inner map after one RCU grace period.
The reason for using two skeletons is to prevent the release of outer
map and inner map in map_in_map_btf.c interfering the release of bpf
map in normal_map_btf.c.
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/bpf/20231216035510.4030605-1-houtao@huaweicloud.com
* kvm-arm64/fgt-rework: (30 commits)
: .
: Fine Grain Trapping update, courtesy of Fuad Tabba.
:
: From the cover letter:
:
: "This patch series has fixes, updates, and code for validating
: fine grain trap register masks, as well as some fixes to feature
: trapping in pKVM.
:
: New fine grain trap (FGT) bits have been defined in the latest
: Arm Architecture System Registers xml specification (DDI0601 and
: DDI0602 2023-09) [1], so the code is updated to reflect them.
: Moreover, some of the already-defined masks overlap with RES0,
: which this series fixes.
:
: It also adds FGT register masks that weren't defined earlier,
: handling of HAFGRTR_EL2 in nested virt, as well as build time
: validation that the bits of the various masks are all accounted
: for and without overlap."
:
: This branch also drags the arm64/for-next/sysregs branch,
: which is a dependency on this work.
: .
KVM: arm64: Trap external trace for protected VMs
KVM: arm64: Mark PAuth as a restricted feature for protected VMs
KVM: arm64: Fix which features are marked as allowed for protected VMs
KVM: arm64: Macros for setting/clearing FGT bits
KVM: arm64: Define FGT nMASK bits relative to other fields
KVM: arm64: Use generated FGT RES0 bits instead of specifying them
KVM: arm64: Add build validation for FGT trap mask values
KVM: arm64: Update and fix FGT register masks
KVM: arm64: Handle HAFGRTR_EL2 trapping in nested virt
KVM: arm64: Add bit masks for HAFGRTR_EL2
KVM: arm64: Add missing HFGITR_EL2 FGT entries to nested virt
KVM: arm64: Add missing HFGxTR_EL2 FGT entries to nested virt
KVM: arm64: Explicitly trap unsupported HFGxTR_EL2 features
arm64/sysreg: Add missing system instruction definitions for FGT
arm64/sysreg: Add missing system register definitions for FGT
arm64/sysreg: Add missing ExtTrcBuff field definition to ID_AA64DFR0_EL1
arm64/sysreg: Add missing Pauth_LR field definitions to ID_AA64ISAR1_EL1
arm64/sysreg: Add new system registers for GCS
arm64/sysreg: Add definition for FPMR
arm64/sysreg: Update HCRX_EL2 definition for DDI0601 2023-09
...
Signed-off-by: Marc Zyngier <maz@kernel.org>
* kvm-arm64/lpa2:
: .
: Support FEAT_LPA2 at EL2 S1 and S2, courtesy of Ryan Roberts
:
: From the cover letter:
:
: "This adds support for FEAT_LPA2 to KVM for both hypervisor stage 1 (for the
: nvhe/protected modes) and the vm stage 2 translation tables (for all modes).
: FEAT_LPA2 enables 52 bit PAs and VAs for 4KB and 16KB granules (note this is
: already supported for 64KB granules via the FEAT_LPA and FEAT_LVA extensions)."
: .
KVM: arm64: Use helpers to classify exception types reported via ESR
KVM: selftests: arm64: Support P52V48 4K and 16K guest_modes
KVM: selftests: arm64: Determine max ipa size per-page size
KVM: arm64: Allow guests with >48-bit IPA size on FEAT_LPA2 systems
KVM: arm64: Support up to 5 levels of translation in kvm_pgtable
KVM: arm64: Convert translation level parameter to s8
KVM: arm64: Use LPA2 page-tables for stage2 and hyp stage1
KVM: arm64: Add new (V)TCR_EL2 field definitions for FEAT_LPA2
arm64: Add ARM64_HAS_LPA2 CPU capability
arm64/mm: Add FEAT_LPA2 specific ID_AA64MMFR0.TGRAN[2]
arm64/mm: Update tlb invalidation routines for FEAT_LPA2
arm64/mm: Add lpa2_is_enabled() kvm_lpa2_is_enabled() stubs
arm64/mm: Modify range-based tlbi to decrement scale
Signed-off-by: Marc Zyngier <maz@kernel.org>
When creating new VSIs, they are assigned into an aggregator node in the
scheduler tree. Information about which aggregator node a VSI is assigned
into is maintained by the vsi->agg_node structure. In ice_vsi_decfg(), this
information is being destroyed, by overwriting the valid flag and the
agg_id field to zero.
For VF VSIs, this breaks the aggregator node configuration replay, which
depends on this information. This results in VFs being inserted into the
default aggregator node. The resulting configuration will have unexpected
Tx bandwidth sharing behavior.
This was broken by commit 6624e780a5 ("ice: split ice_vsi_setup into
smaller functions"), which added the block to reset the agg_node data.
The vsi->agg_node structure is not managed by the scheduler code, but is
instead a wrapper around an aggregator node ID that is tracked at the VSI
layer. Its been around for a long time, and its primary purpose was for
handling VFs. The SR-IOV VF reset flow does not make use of the standard VSI
rebuild/replay logic, and uses vsi->agg_node as part of its handling to
rebuild the aggregator node configuration.
The logic for aggregator nodes stretches back to early ice driver code from
commit b126bd6bcd ("ice: create scheduler aggregator node config and move
VSIs")
The logic in ice_vsi_decfg() which trashes the ice_agg_node data is clearly
wrong. It destroys information that is necessary for handling VF reset,. It
is also not the correct way to actually remove a VSI from an aggregator
node. For that, we need to implement logic in the scheduler code. Further,
non-VF VSIs properly replay their aggregator configuration using existing
scheduler replay logic.
To fix the VF replay logic, remove this broken aggregator node cleanup
logic. This is the simplest way to immediately fix this.
This ensures that VFs will have proper aggregate configuration after a
reset. This is especially important since VFs often perform resets as part
of their reconfiguration flows. Without fixing this, VFs will be placed in
the default aggregator node and Tx bandwidth will not be shared in the
expected and configured manner.
Fixes: 6624e780a5 ("ice: split ice_vsi_setup into smaller functions")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Even if BLK_CGROUP is enabled, it does not work for passthrough io.
So skip setting up blkg for passthrough bio.
Reduced processing gives ~5% hike in peak-performance workload.
Signed-off-by: Kundan Kumar <kundan.kumar@samsung.com>
Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Link: https://lore.kernel.org/r/20231218152722.1768-1-joshi.k@samsung.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
For aux reads, the value `msg->size` indicates the size of the buffer
provided by `msg->buffer`. We should never in any circumstances write
more bytes to the buffer since it may overflow the buffer.
In the ti-sn65dsi86 driver there is one code path that reads the
transfer length from hardware. Even though it's never been seen to be
a problem, we should make extra sure that the hardware isn't
increasing the length since doing so would cause us to overrun the
buffer.
Fixes: 982f589bde ("drm/bridge: ti-sn65dsi86: Update reply on aux failures")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.2.I7b83c0f31aeedc6b1dc98c7c741d3e1f94f040f8@changeid
While testing, I happened to notice a random crash that looked like:
Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: drm_dp_dpcd_probe+0x120/0x120
Analysis of drm_dp_dpcd_probe() shows that we pass in a 1-byte buffer
(allocated on the stack) to the aux->transfer() function. Presumably
if the aux->transfer() writes more than one byte to this buffer then
we're in a bad shape.
Dropping into kgdb, I noticed that "aux->transfer" pointed at
ps8640_aux_transfer().
Reading through ps8640_aux_transfer(), I can see that there are cases
where it could write more bytes to msg->buffer than were specified by
msg->size. This could happen if the hardware reported back something
bogus to us. Let's fix this so we never write more than msg->size
bytes. We'll still read all the bytes from the hardware just in case
the hardware requires it since the aux transfer data comes through an
auto-incrementing register.
NOTE: I have no actual way to reproduce this issue but it seems likely
this is what was happening in the crash I looked at.
Fixes: 13afcdd727 ("drm/bridge: parade-ps8640: Add support for AUX channel")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231214123752.v3.1.I9d1afcaad76a3e2c0ca046dc4adbc2b632c22eda@changeid
On older devices (before unified image!) we can end up calling
stop_device from an rfkill interrupt. However, in stop_device
we attempt to synchronize IRQs, which then of course deadlocks.
Avoid this by checking the context, if running from the IRQ
thread then don't synchronize. This wouldn't be correct on a
new device since RSS is supported, but older devices only have
a single interrupt/queue.
Fixes: 37fb29bd1f ("wifi: iwlwifi: pcie: synchronize IRQs before NAPI")
Reviewed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/20231215111335.59aab00baed7.Iadfe154d6248e7f9dfd69522e5429dbbd72925d7@changeid
These panels are used by Mediatek MT8173 Chromebooks, and they used to
work with the downstream v4.19 kernel without any specified delay.
Back in the v4.19 kernel, they used the "little white lie" approach,
which is making the devicetree claim a specific panel's compatible
string for many different panels. That was a common solution before the
generic edp-panel driver.
After we uprevved the device to a newer kernel and used the edp-panel
driver, we saw multiple devices reporting warnings of using an unknown
panel and falling back to the conservative timings, which means that
they turn on/off much more slowly than they should. We tried to fill in
the timings for those panels, but we failed to find all the data sheets
for them.
Therefore, instead of having them use the default conservative timings,
update them with less-conservative timings from other panels of the same
vendor. The panels should still work under those timings, and we can
save some delays and suppress the warnings.
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231214152817.2766280-4-treapking@chromium.org
Add the support of powered_on_to_enable delay as the minimum time that
needs to have passed between the panel powered on and enable may begin.
This delay is seen in BOE panels as the minimum delay of T3+T4+T5+T6+T8
in the eDP timing diagrams.
Signed-off-by: Pin-yen Lin <treapking@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231214152817.2766280-2-treapking@chromium.org
There's nothing wrong with this commit, but this is dead code now
that nothing triggers a CB_GETATTR callback. It can be re-introduced
once the issues with handling conflicting GETATTRs are resolved.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
For some reason, the wait_on_bit() in nfsd4_deleg_getattr_conflict()
is waiting forever, preventing a clean server shutdown. The
requesting client might also hang waiting for a reply to the
conflicting GETATTR.
Invoking wait_on_bit() in an nfsd thread context is a hazard. The
correct fix is to replace this wait_on_bit() call site with a
mechanism that defers the conflicting GETATTR until the CB_GETATTR
completes or is known to have failed.
That will require some surgery and extended testing and it's late
in the v6.7-rc cycle, so I'm reverting now in favor of trying again
in a subsequent kernel release.
This is my fault: I should have recognized the ramifications of
calling wait_on_bit() in here before accepting this patch.
Thanks to Dai Ngo <dai.ngo@oracle.com> for diagnosing the issue.
Reported-by: Wolfgang Walter <linux-nfs@stwm.de>
Closes: https://lore.kernel.org/linux-nfs/e3d43ecdad554fbdcaa7181833834f78@stwm.de/
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
