[ Upstream commit 219481a8f9 ]
Make SMB2 not print out an error when an oplock break is received for an
unknown handle, similar to SMB1. The debug message which is printed for
these unknown handles may also be misleading, so fix that too.
The SMB2 lease break path is not affected by this patch.
Without this, a program which writes to a file from one thread, and
opens, reads, and writes the same file from another thread triggers the
below errors several times a minute when run against a Samba server
configured with "smb2 leases = no".
CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2
00000000: 424d53fe 00000040 00000000 00000012 .SMB@...........
00000010: 00000001 00000000 ffffffff ffffffff ................
00000020: 00000000 00000000 00000000 00000000 ................
00000030: 00000000 00000000 00000000 00000000 ................
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cee8f4f6fc ]
RHBZ: 1933527
Under SMB1 + POSIX, if an inode is reused on a server after we have read and
cached a part of a file, when we then open the new file with the
re-cycled inode there is a chance that we may serve the old data out of cache
to the application.
This only happens for SMB1 (deprecated) and when posix are used.
The simplest solution to avoid this race is to force a revalidate
on smb1-posix open.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f2a419cf49 ]
The sleep warning happens at early boot right at secondary CPU
activation bootup:
smp: Bringing up secondary CPUs ...
BUG: sleeping function called from invalid context at mm/page_alloc.c:4942
in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.12.0-rc2-00007-g79e228d0b611-dirty #99
..
Call Trace:
show_stack+0x90/0xc0
dump_stack+0x150/0x1c0
___might_sleep+0x1c0/0x2a0
__might_sleep+0xa0/0x160
__alloc_pages_nodemask+0x1a0/0x600
alloc_page_interleave+0x30/0x1c0
alloc_pages_current+0x2c0/0x340
__get_free_pages+0x30/0xa0
ia64_mca_cpu_init+0x2d0/0x3a0
cpu_init+0x8b0/0x1440
start_secondary+0x60/0x700
start_ap+0x750/0x780
Fixed BSP b0 value from CPU 1
As I understand interrupts are not enabled yet and system has a lot of
memory. There is little chance to sleep and switch to GFP_ATOMIC should
be a no-op.
Link: https://lkml.kernel.org/r/20210315085045.204414-1-slyfox@gentoo.org
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f51d7bf1db ]
Current calculation for diff of TMR_ADD register value may have
64-bit overflow in this code line, when long type scaled_ppm is
large.
adj *= scaled_ppm;
This patch is to resolve it by using mul_u64_u64_div_u64().
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d1635448f1 ]
Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
programmed in the Tiger Lake GBE controller is not large enough to allow
the platform to enter Package C10, which in turn prevents the platform from
achieving its low power target during suspend-to-idle. Ignore the GBE LTR
value on Tiger Lake. LTR ignore functionality is currently performed solely
by a debugfs write call. Split out the LTR code into its own function that
can be called by both the debugfs writer and by this work around.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Sasha Neftin <sasha.neftin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5116784039 ]
The GD_NEED_PART_SCAN is set by bdev_check_media_change to initiate
a partition scan while removing a block device. It should be cleared
after blk_drop_paritions because blk_drop_paritions could return
-EBUSY and then the consequence __blkdev_get has no chance to do
delete_partition if GD_NEED_PART_SCAN already cleared.
It causes some problems on some card readers. Ex. Realtek card
reader 0bda:0328 and 0bda:0158. The device node of the partition
will not disappear after the memory card removed. Thus the user
applications can not update the device mapping correctly.
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920874
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210323085219.24428-1-chris.chiu@canonical.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9fcb51c14d ]
The new Ubuntu GCC packages turn on -fcf-protection globally,
which causes a build failure in the x86 realmode code:
cc1: error: ‘-fcf-protection’ is not compatible with this target
Turn it off explicitly on compilers that understand this option.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210323124846.1584944-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 627dc55c27 ]
DPU runtime resume will request for a min vote on the AXI bus as
it is a necessary step before turning ON the AXI clock.
The change does below
1) Move the icc path set before requesting runtime get_sync.
2) remove the dependency of hw catalog for min ib vote
as it is initialized at a later point.
Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7011d72588 ]
The "First Fault Register" (FFR) is an SVE register that mimics a
predicate register, but clears bits when a load or store fails to handle
an element of a vector. The supposed usage scenario is to initialise
this register (using SETFFR), then *read* it later on to learn about
elements that failed to load or store. Explicit writes to this register
using the WRFFR instruction are only supposed to *restore* values
previously read from the register (for context-switching only).
As the manual describes, this register holds only certain values, it:
"... contains a monotonic predicate value, in which starting from bit 0
there are zero or more 1 bits, followed only by 0 bits in any remaining
bit positions."
Any other value is UNPREDICTABLE and is not supposed to be "restored"
into the register.
The SVE test currently tries to write a signature pattern into the
register, which is *not* a canonical FFR value. Apparently the existing
setups treat UNPREDICTABLE as "read-as-written", but a new
implementation actually only stores canonical values. As a consequence,
the sve-test fails immediately when comparing the FFR value:
-----------
# ./sve-test
Vector length: 128 bits
PID: 207
Mismatch: PID=207, iteration=0, reg=48
Expected [cf00]
Got [0f00]
Aborted
-----------
Fix this by only populating the FFR with proper canonical values.
Effectively the requirement described above limits us to 17 unique
values over 16 bits worth of FFR, so we condense our signature down to 4
bits (2 bits from the PID, 2 bits from the generation) and generate the
canonical pattern from it. Any bits describing elements above the
minimum 128 bit are set to 0.
This aligns the FFR usage to the architecture and fixes the test on
microarchitectures implementing FFR in a more restricted way.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviwed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210319120128.29452-1-andre.przywara@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3d677f12ea ]
On many recent ThinkPad laptops, there's a new LED next to the ESC key,
that indicates the FnLock status.
When the Fn+ESC combo is pressed, FnLock is toggled, which causes the
Media Key functionality to change, making it so that the media keys
either perform their media key function, or function as an F-key by
default. The Fn key can be used the access the alternate function at any
time.
With the current linux kernel, the LED doens't change state if you press
the Fn+ESC key combo. However, the media key functionality *does*
change. This is annoying, since the LED will stay on if it was on during
bootup, and it makes it hard to keep track what the current state of the
FnLock is.
This patch calls an ACPI function, that gets the current media key
state, when the Fn+ESC key combo is pressed. Through testing it was
discovered that this function causes the LED to update correctly to
reflect the current state when this function is called.
The relevant ACPI calls are the following:
\_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled.
\_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it.
Relevant discussion:
https://bugzilla.kernel.org/show_bug.cgi?id=207841https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015
Signed-off-by: Esteve Varela Colominas <esteve.varela@gmail.com>
Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b4afd4b90a ]
We use ipa_cmd_header_valid() to ensure certain values we will
program into hardware are within range, well in advance of when we
actually program them. This way we avoid having to check for errors
when we actually program the hardware.
Unfortunately the dev_err() call for a bad offset value does not
supply the arguments to match the format specifiers properly.
Fix this.
There was also supposed to be a check to ensure the size to be
programmed fits in the field that holds it. Add this missing check.
Rearrange the way we ensure the header table fits in overall IPA
memory range.
Finally, update ipa_cmd_table_valid() so the format of messages
printed for errors matches what's done in ipa_cmd_header_valid().
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 86fe2c19ee ]
If the flowtable has been previously removed in this batch, skip the
hook overlap checks. This fixes spurious EEXIST errors when removing and
adding the flowtable in the same batch.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7ad48d27a2 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't lose the kernel traces leading up to this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4a9d36b061 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and friends.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9daaf31307 ]
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value
directly, but the same value was also being specified in the
dsi_pll_regs struct pll_lockdet_rate variable: let's use it!
Based on 362cadf34b ("drm/msm/dsi_pll_10nm: Fix variable usage for
pll_lockdet_rate")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7421b1a4d1 ]
The first argument to namedtuple() should match the name of the type,
which wasn't the case for KconfigEntryBase.
Fixing this is enough to make mypy show no python typing errors again.
Fixes 97752c39bd ("kunit: kunit_tool: Allow .kunitconfig to disable config items")
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Daniel Latypov <dlatypov@google.com>
Acked-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0571a753cb ]
pxa168_eth_remove() firstly calls unregister_netdev(),
then cancels a timeout work. unregister_netdev() shuts down a device
interface and removes it from the kernel tables. If the timeout occurs
in parallel, the timeout work (pxa168_eth_tx_timeout_task) performs stop
and open of the device. It may lead to an inconsistent state and memory
leaks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Pavel Andrianov <andrianov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a7b5d7c496 ]
We currently get thefollowing on driver unbind if a reset is configured
and asserted:
WARNING: CPU: 0 PID: 993 at drivers/reset/core.c:432 reset_control_assert
...
(reset_control_assert) from [<c0fecda8>] (sysc_remove+0x190/0x1e4)
(sysc_remove) from [<c0a2bb58>] (platform_remove+0x24/0x3c)
(platform_remove) from [<c0a292fc>] (__device_release_driver+0x154/0x214)
(__device_release_driver) from [<c0a2a210>] (device_driver_detach+0x3c/0x8c)
(device_driver_detach) from [<c0a27d64>] (unbind_store+0x60/0xd4)
(unbind_store) from [<c0546bec>] (kernfs_fop_write_iter+0x10c/0x1cc)
Let's fix it by checking the reset status.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9bbce32a20 ]
Without DT aliases, the numbering of mmc interfaces is unpredictable.
Adding them makes it possible to refer to devices consistently. The
popular suggestion to use UUIDs obviously doesn't work with a blank
device fresh from the factory.
See commit fa2d0aa969 ("mmc: core: Allow setting slot index via
device tree alias") for more discussion.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt,
port->pps_data.max_volt, port->pps_data.max_curr even before
port partner accepts the requests. This leaves incorrect values
in current_limit and supply_voltage that get exported by
"tcpm-source-psy-". Solving this problem by caching the request
values in req_min_volt, req_max_volt, req_max_curr, req_out_volt,
req_op_curr. min_volt, max_volt, max_curr gets updated once the
partner accepts the request. current_limit, supply_voltage gets updated
once local port's tcpm enters SNK_TRANSITION_SINK when the accepted
current_limit and supply_voltage is enforced.
Fixes: f2a8aa053c ("typec: tcpm: Represent source supply through power_supply")
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e3a0720224https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9e6d899cec1c8e3c62d68bd0e2ba90c662a2403c
Update KMI with most 4/9 changes (one more coming)
Leaf changes summary: 576 artifacts changed
Changed leaf types summary: 9 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 554 Changed, 7 Added functions
Removed/Changed/Added variables summary: 0 Removed, 4 Changed, 2 Added variables
7 Added functions:
[A] 'function ieee802154_hw* ieee802154_alloc_hw(size_t, const ieee802154_ops*)'
[A] 'function void ieee802154_free_hw(ieee802154_hw*)'
[A] 'function int ieee802154_register_hw(ieee802154_hw*)'
[A] 'function void ieee802154_rx_irqsafe(ieee802154_hw*, sk_buff*, u8)'
[A] 'function void ieee802154_unregister_hw(ieee802154_hw*)'
[A] 'function void ieee802154_wake_queue(ieee802154_hw*)'
[A] 'function void ieee802154_xmit_complete(ieee802154_hw*, sk_buff*, bool)'
554 functions with some sub-type change:
[C] 'function int ___pskb_trim(sk_buff*, unsigned int)' at skbuff.c:1928:1 has some sub-type changes:
CRC (modversions) changed from 0x750d7278 to 0x81d5292f
[C] 'function sk_buff* __alloc_skb(unsigned int, gfp_t, int, int)' at skbuff.c:182:1 has some sub-type changes:
CRC (modversions) changed from 0x35ad9f50 to 0xc662eb3c
[C] 'function sk_buff* __cfg80211_alloc_event_skb(wiphy*, wireless_dev*, nl80211_commands, nl80211_attrs, unsigned int, int, int, gfp_t)' at nl80211.c:10274:1 has some sub-type changes:
CRC (modversions) changed from 0x8515ad95 to 0x55be0cb8
... 551 omitted; 554 symbols have only CRC changes
2 Added variables:
[A] 'tracepoint __tracepoint_android_rvh_cpu_cgroup_online'
[A] 'tracepoint __tracepoint_android_rvh_replace_next_task_fair'
4 Changed variables:
[C] 'net init_net' was changed at net_namespace.c:47:1:
CRC (modversions) changed from 0xae43d102 to 0x75836cf9
[C] 'pid_namespace init_pid_ns' was changed at pid.c:75:1:
CRC (modversions) changed from 0xbf931239 to 0x30fc5784
[C] 'const dev_pm_ops snd_soc_pm_ops' was changed at soc-core.c:2028:1:
CRC (modversions) changed from 0x785e2782 to 0xab291a76
... 1 omitted; 4 symbols have only CRC changes
'struct bpf_prog_aux at bpf.h:757:1' changed:
type size changed from 5120 to 5056 (in bits)
1 data member deletion:
'bpf_tramp_prog_type trampoline_prog_type', at offset 1024 (in bits) at bpf.h:783:1
there are data member changes:
29 ('hlist_node tramp_hlist' .. 'bpf_prog_stats* stats') offsets changed (by -64 bits)
while looking at anonymous data member 'union {work_struct work; callback_head rcu;}':
the internal name of that anonymous data member changed from:
__anonymous_union__27
to:
__anonymous_union__28
This is usually due to an anonymous member type being added or removed from the containing type
and offset changed from 4864 to 4800 (in bits) (by -64 bits)
2740 impacted interfaces
'struct bpf_trampoline at bpf.h:586:1' changed:
type size changed from 3008 to 1280 (in bits)
1 data member deletion:
'bpf_ksym ksym', at offset 1280 (in bits) at bpf.h:610:1
there are data member changes:
type 'void*' of 'bpf_trampoline::image' changed:
pointer type changed from: 'void*' to: 'bpf_tramp_image*'
and name of 'bpf_trampoline::image' changed to 'bpf_trampoline::cur_image' at bpf.h:624:1
2740 impacted interfaces
'struct io_pgtable_ops at io-pgtable.h:150:1' changed:
type size changed from 256 to 384 (in bits)
2 data member insertions:
'int (io_pgtable_ops*, unsigned long int, typedef phys_addr_t, typedef size_t, typedef size_t, int, typedef gfp_t, size_t*)* map_pages', at offset 64 (in bits) at io-pgtable.h:155:1
'typedef size_t (io_pgtable_ops*, unsigned long int, typedef size_t, typedef size_t, iommu_iotlb_gather*)* unmap_pages', at offset 256 (in bits) at io-pgtable.h:163:1
there are data member changes:
2 ('int (io_pgtable_ops*, unsigned long int, scatterlist*, unsigned int, int, typedef gfp_t, size_t*)* map_sg' .. 'typedef size_t (io_pgtable_ops*, unsigned long int, typedef size_t, iommu_iotlb_gather*)* unmap') offsets changed (by +64 bits)
'typedef phys_addr_t (io_pgtable_ops*, unsigned long int)* iova_to_phys' offset changed (by +128 bits)
2 impacted interfaces
'struct iommu_ops at iommu.h:248:1' changed:
type size changed from 2688 to 2816 (in bits)
2 data member insertions:
'int (iommu_domain*, unsigned long int, typedef phys_addr_t, typedef size_t, typedef size_t, int, typedef gfp_t, size_t*)* map_pages', at offset 384 (in bits) at iommu.h:262:1
'typedef size_t (iommu_domain*, unsigned long int, typedef size_t, typedef size_t, iommu_iotlb_gather*)* unmap_pages', at offset 576 (in bits) at iommu.h:270:1
there are data member changes:
2 ('int (iommu_domain*, unsigned long int, scatterlist*, unsigned int, int, typedef gfp_t, size_t*)* map_sg' .. 'typedef size_t (iommu_domain*, unsigned long int, typedef size_t, iommu_iotlb_gather*)* unmap') offsets changed (by +64 bits)
34 ('void (iommu_domain*)* flush_iotlb_all' .. 'module* owner') offsets changed (by +128 bits)
2740 impacted interfaces
'struct net_device at netdevice.h:1891:1' changed:
type size hasn't changed
2 data member insertions:
'netdev_ml_priv_type ml_priv_type', at offset 9792 (in bits) at netdevice.h:2151:1
'union {pcpu_lstats* lstats; pcpu_sw_netstats* tstats; pcpu_dstats* dstats;}', at offset 9856 (in bits) at netdevice.h:2153:1
there are data member changes:
anonymous data member union {void* ml_priv; pcpu_lstats* lstats; pcpu_sw_netstats* tstats; pcpu_dstats* dstats;} at offset 9728 (in bits) became data member 'void* ml_priv'
26 ('device dev' .. 'u64 android_kabi_reserved8') offsets changed (by +128 bits)
2740 impacted interfaces
'struct phy_device at phy.h:539:1' changed:
type size changed from 11008 to 11072 (in bits)
1 data member insertion:
'int port', at offset 8416 (in bits) at phy.h:581:1
there are data member changes:
5 ('int pause' .. 'u8 master_slave_state') offsets changed (by +32 bits)
22 ('unsigned long int supported[2]' .. 'void (net_device*)* adjust_link') offsets changed (by +64 bits)
2740 impacted interfaces
'struct rtnl_link_ops at rtnetlink.h:59:1' changed:
type size hasn't changed
1 data member insertion:
'bool netns_refund', at offset 320 (in bits) at rtnetlink.h:68:1
there are data member changes:
'unsigned int maxtype' offset changed (by +32 bits)
2740 impacted interfaces
'struct ufs_hba at ufshcd.h:708:1' changed:
type size changed from 32448 to 33344 (in bits)
1 data member insertion:
'dentry* debugfs_root', at offset 33280 (in bits) at ufshcd.h:837:1
there are data member changes:
type 'struct ufs_stats' of 'ufs_hba::ufs_stats' changed:
type size changed from 11072 to 11904 (in bits)
12 data member deletions:
'ufs_err_reg_hist dl_err', at offset 1088 (in bits) at ufshcd.h:450:1
'ufs_err_reg_hist nl_err', at offset 1920 (in bits) at ufshcd.h:451:1
'ufs_err_reg_hist tl_err', at offset 2752 (in bits) at ufshcd.h:452:1
'ufs_err_reg_hist dme_err', at offset 3584 (in bits) at ufshcd.h:453:1
'ufs_err_reg_hist auto_hibern8_err', at offset 4416 (in bits) at ufshcd.h:456:1
'ufs_err_reg_hist fatal_err', at offset 5248 (in bits) at ufshcd.h:457:1
'ufs_err_reg_hist link_startup_err', at offset 6080 (in bits) at ufshcd.h:458:1
'ufs_err_reg_hist resume_err', at offset 6912 (in bits) at ufshcd.h:459:1
'ufs_err_reg_hist suspend_err', at offset 7744 (in bits) at ufshcd.h:460:1
'ufs_err_reg_hist dev_reset', at offset 8576 (in bits) at ufshcd.h:463:1
'ufs_err_reg_hist host_reset', at offset 9408 (in bits) at ufshcd.h:464:1
'ufs_err_reg_hist task_abort', at offset 10240 (in bits) at ufshcd.h:465:1
there are data member changes:
type 'struct ufs_err_reg_hist' of 'ufs_stats::pa_err' changed:
entity changed from 'struct ufs_err_reg_hist' to 'ufs_event_hist[13]'
type size changed from 832 to 11648 (in bits)
and name of 'ufs_stats::pa_err' changed to 'ufs_stats::event' at ufshcd.h:459:1
16 impacted interfaces
33 ('bool force_reset' .. 'blk_keyslot_manager ksm') offsets changed (by +832 bits)
16 impacted interfaces
'struct ufs_stats at ufshcd.h:441:1' changed:
details were reported earlier
Bug: 184983567
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I9e1533bae92343335000a50b79a2acae02cc9c3e
Implement the map_pages() callback for the ARM SMMU driver
to allow calls from iommu_map to map multiple pages of
the same size in one call. Also, remove the map() callback
for the ARM SMMU driver, as it will no longer be used.
Bug: 178537788
Change-Id: Ie35bd1842da60e4b63b0acad37a6cd095dcfea9d
Link: https://lore.kernel.org/linux-iommu/20210408171402.12607-1-isaacm@codeaurora.org/T/#t
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Suggested-by: Will Deacon <will@kernel.org>
Implement the unmap_pages() callback for the ARM SMMU driver
to allow calls from iommu_unmap to unmap multiple pages of
the same size in one call. Also, remove the unmap() callback
for the SMMU driver, as it will no longer be used.
Bug: 178537788
Change-Id: I4b53f9bb61fb089b658c6f07e0363327c3582be1
Link: https://lore.kernel.org/linux-iommu/20210408171402.12607-1-isaacm@codeaurora.org/T/#t
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Suggested-by: Will Deacon <will@kernel.org>
The 'addr_merge' parameter to iommu_pgsize() is a fabricated address
intended to describe the alignment requirements to consider when
choosing an appropriate page size. On the iommu_map() path, this address
is the logical OR of the virtual and physical addresses.
Subsequent improvements to iommu_pgsize() will need to check the
alignment of the virtual and physical components of 'addr_merge'
independently, so pass them in as separate parameters and reconstruct
'addr_merge' locally.
No functional change.
Bug: 178537788
Change-Id: I7126a39e79c47a517676aaa40f3f0e4c0b70b73d
Link: https://lore.kernel.org/linux-iommu/20210408171402.12607-1-isaacm@codeaurora.org/T/#t
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can
call into the io-pgtable code, to map a physically contiguous
rnage of pages of the same size.
For IOMMU drivers that do not specify a map_pages() callback,
the existing logic of mapping memory one page block at a time
will be used.
Bug: 178537788
Change-Id: I907b346558dcc4127a9769c66940e324aaa48d3e
Link: https://lore.kernel.org/linux-iommu/20210408171402.12607-1-isaacm@codeaurora.org/T/#t
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Suggested-by: Will Deacon <will@kernel.org>
Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
Mapping memory into io-pgtables follows the same semantics
that unmapping memory used to follow (i.e. a buffer will be
mapped one page block per call to the io-pgtable code). This
means that it can be optimized in the same way that unmapping
memory was, so add a map_pages() callback to the io-pgtable
ops structure, so that a range of pages of the same size
can be mapped within the same call.
Bug: 178537788
Change-Id: I5f2a86f21216f26b2cc2f70904c2968467c5363a
Link: https://lore.kernel.org/linux-iommu/20210408171402.12607-1-isaacm@codeaurora.org/T/#t
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Suggested-by: Will Deacon <will@kernel.org>
Add a callback for IOMMU drivers to provide a path for the
IOMMU framework to call into an IOMMU driver, which can call
into the io-pgtable code, to unmap a virtually contiguous
range of pages of the same size.
For IOMMU drivers that do not specify an unmap_pages() callback,
the existing logic of unmapping memory one page block at a time
will be used.
Bug: 178537788
Change-Id: Ifdc3e1e0bf1c5f9b98d9c9c0f40ca6967e87f68c
Link: https://lore.kernel.org/linux-iommu/20210408171402.12607-1-isaacm@codeaurora.org/T/#t
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
