For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20240503140359.259762-8-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20240503140359.259762-7-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20240503140359.259762-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20240503140359.259762-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20240503140359.259762-4-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20240503140359.259762-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For some reason a number of files included the "All rights reserved"
statement. Good old copy-paste made sure this mistake proliferated.
Remove the "All rights reserved" in all Intel-copyright to align with
internal guidance.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20240503140359.259762-2-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
bch2_fs_quota_read_inode() wasn't entirely updated to the
bch2_snapshot_tree() helper, which takes rcu lock.
Reported-by: syzbot+a3a9a61224ed3b7f0010@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Ancient versions of bcachefs produced packed formats that could
represent keys that our in memory format cannot represent;
bformat_needs_redo() has some tricky shifts to check for this sort of
overflow.
Reported-by: syzbot+594427aebfefeebe91c6@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
For forwards compatibility we have to allow unknown key types, and only
run the checks that make sense against them.
Fix a missing guard on k.k->type being known.
Reported-by: syzbot+ae4dc916da3ce51f284f@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
We were forgetting to check for jset entries that overrun the end of the
section - both in validate and to_text(); to_text() needs to be safe for
types that fail to validate.
Reported-by: syzbot+c48865e11e7e893ec4ab@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
filefrag (and potentially other utilities that call fiemap) sometimes
pass ULONG_MAX as the length. fiemap_prep clamps excessively large
lengths - but the calculation of end can overflow if it occurs before
calling fiemap_prep. When this happens, filefrag assumes it has read to
the end and exits.
Signed-off-by: Reed Riley <reed@riley.engineer>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
The bucket_gens array is a single array allocation (one byte per
bucket), and kernel allocations are still limited to INT_MAX.
Check this limit to avoid failing the bucket_gens array allocation.
Reported-by: syzbot+b29f436493184ea42e2b@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bch2_get_next_dev() and bch2_get_next_online_dev() iterate over devices,
dropping and taking refs as they go; we can't access the previous device
(for ca->dev_idx) after we've dropped our ref to it, unless we take
rcu_read_lock() first.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
bch2_dev_lookup() is supposed to take a ref on the device it returns, but
for_each_member_device() takes refs as it iterates,
for_each_member_device_rcu() does not.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Normally this is initialized in __bch2_write(), which is executed in a
loop, but the inline data path skips this.
Reported-by: syzbot+fd3ccb331eb21f05d13b@syzkaller.appspotmail.com
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Machine boards expose input device for use with userspace. Current name
in some cases is incorrect, fix it.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20240506121106.3792340-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In prph_mac_iter, ensure that all required addresses are dumped
even if a read fails. Currently, if a read fails, the region dump
is stopped, preventing the creation of prph_mac.lst.
By dumping all addresses even if a read fails, we can accurately
determine which addresses were successfully read and which were not.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Eilon Rinat <eilon.rinat@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.31fa9ce91a1c.Ia0c86f70c7a6874c15ffc6f8235aa88530208546@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
During restart mac80211 notifies the driver about the association,
(if we was associated before the restart) which causes the driver to
request statistics from the FW. This causes to an immediate exit from
EMLSR after the restart is done, when the statistics notif is handled.
(too low TPT). There is no point in requesting statistics wnyway, since
the FW just started and don't have any.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240506095953.16638dec9f7b.I093514312179bae566ad8d73ffb0355c6eee288a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The firmware has different names for this, which is confusing
as even the convention of having the firmware name in a comment
after the struct definition wasn't met here. Fix the naming,
but keep UATS in some of it since that's the BIOS name.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.b0dfe17d5f44.I8f5f5a831c7b934ce3140f838315827c018103bb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Firmware 0x2F7 assert observed in Dell platforms when using GL HW.
This issue is mitigated by setting SCU_FORCE_ACTIVE during platform
low power states.
Driver shall indicate firmware to force SCU active by setting bit 29
in context info prph scratch control flags.
This mitigation is limited to Dell platforms with GL HW only.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Reviewed-by: Ofer Kimelman <ofer.kimelman@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.3d0c56c2bb1a.I97d9da402890d2085b5698666cceffc417b6b6df@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
While doing a passive scan, the firmware will report per-channel survey
information. This information is primarily useful for hostapd when doing
an ACS (Automatic Channel Selection). Collect this information and add
it to the result set when getting the survey information.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.9287591a5999.I54a3f9f6480d3694e67eea1cb4f5853beace2780@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When requested, the firmware can return per-channel survey information
generally used for ACS (automatic channel selection). Add the API for
this, which consists of a flag and a new channel survey notification.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.1facde532676.I3864ac4bc0fecb7fd5136e85c07585ab7100234b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The move of the scan complete notification handling to the wiphy worker
introduced a race between scan complete notification and scan abort:
- The wiphy lock is held, e.g., for rfkill handling etc.
- Scan complete notification is received but not handled yet.
- Scan abort is triggered, and scan abort is sent to the FW. Once the
scan abort command is sent successfully, the flow synchronously waits
for the scan complete notification. However, as the scan complete
notification was already received but not processed yet, this hangs for
a second and continues leaving the scan status in an inconsistent
state.
- Once scan complete handling is started (when the wiphy lock is not held)
since the scan status is not an inconsistent state, a warning is issued
and the scan complete notification is not handled.
To fix this issue, switch back the scan complete notification to be
asynchronously handling, and only move the link selection logic to
a worker (which was the original reason for the move to use wiphy lock).
While at it, refactor some prints to improve debug data.
Fixes: 07bf5297d3 ("wifi: iwlwifi: mvm: Implement new link selection algorithm")
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.1f484a86324b.I63ed445a47f144546948c74ae6df85587fdb4ce3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a reading for all active EMLSR blocking reasons for testing
purposes.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.6d494a335e81.Ic0fa6a9636e3c1a3b1420e85e704a19d4a56e8d9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In iwl_mvm_rs_fw_rate_init() we have a variable cmd_id that
holds the command ID, so we can just use that instead of the
various calculations of it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240506095953.f894ede03b26.I18f03c272b1c0807767f2713f3ffbb2941c57d9b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
