Merge ACPI device enumeration updates, ACPI power management updates
and PCI host bridge ACPI driver updates for 5.17-rc1:
- Introduce acpi_fetch_acpi_dev() as a replacement for
acpi_bus_get_device() and use it in the ACPI subsystem (Rafael
Wysocki).
- Avoid using _CID for device enumaration if _HID is missing or
invalid (Rafael Wysocki).
- Rework quirk handling during ACPI device enumeration and add some
new quirks for known broken platforms (Hans de Goede).
- Avoid unnecessary or redundant CPU cache flushing during system
PM transitions (Kirill A. Shutemov).
- Add PM debug messages related to power resources (Rafael Wysocki).
- Fix kernel-doc comment in the PCI host bridge ACPI driver (Yang Li).
* acpi-scan:
serdev: Do not instantiate serdevs on boards with known bogus DSDT entries
i2c: acpi: Do not instantiate I2C-clients on boards with known bogus DSDT entries
ACPI / x86: Add acpi_quirk_skip_[i2c_client|serdev]_enumeration() helpers
ACPI: scan: Create platform device for BCM4752 and LNV4752 ACPI nodes
ACPI: Use acpi_fetch_acpi_dev() instead of acpi_bus_get_device()
ACPI: scan: Introduce acpi_fetch_acpi_dev()
ACPI: scan: Do not add device IDs from _CID if _HID is not valid
* acpi-pm:
ACPI: PM: Remove redundant cache flushing
ACPI: PM: Avoid CPU cache flush when entering S4
* acpi-power:
ACPI: PM: Emit debug messages when enabling/disabling wakeup power
* acpi-pci:
PCI/ACPI: Fix acpi_pci_osc_control_set() kernel-doc comment
The Tactive time determines the waiting time before burst at hibern8 exit
and is determined by hardware at linkup time. However, in the case of
Samsung devices, increase host's Tactive time +100us for stability. If the
HCI's Tactive time is equal or greater than the device, +100us should be
set.
Link: https://lore.kernel.org/r/20220106213924.186263-1-hy50.seo@samsung.com
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Acked-by: Avri Altman <Avri.Altman@wdc.com>
Signed-off-by: SEO HOYOUNG <hy50.seo@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
As stated in [1], dma_set_mask() with a 64-bit mask never fails if
dev->dma_mask is non-NULL. So, if it fails, the 32 bits case will also
fail for the same reason.
Simplify code and remove some dead code accordingly.
While at it, return the error code returned by dma_set_mask_and_coherent()
instead of -1.
[1]: https://lkml.org/lkml/2021/6/7/398
Link: https://lore.kernel.org/r/958bcb2a6e86344c14f38369e8e7079615a2b0e3.1641754613.git.christophe.jaillet@wanadoo.fr
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The "data_info" struct is copied to the user. It has a 4 byte struct
hole after the last struct member so we need to memset that to avoid
copying uninitialized stack data to the user.
Fixes: b0013e037a ("ACPI: Introduce Platform Firmware Runtime Telemetry driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In [1], Christoph Hellwig has proposed to remove the wrappers in
include/linux/pci-dma-compat.h.
Some reasons why this API should be removed have been given by Julia
Lawall in [2].
When memory is allocated in kbuf_alloc_2_sgl() GFP_KERNEL can be used
because this function already uses the GFP_USER flag for some memory
allocation and not spin_lock is taken in the between.
When memory is allocated in mptctl_do_mpt_command() GFP_KERNEL can be used
because this function already uses copy_from_user() and this function can
sleep.
When memory is allocated in mptctl_hp_hostinfo() GFP_KERNEL can be used
because this function already uses mpt_config() and this function has an
explicit might_sleep().
When memory is allocated in mptctl_hp_targetinfo() GFP_KERNEL can be used
because this function already uses mpt_config() and this function has an
explicit might_sleep().
[1]: https://lore.kernel.org/kernel-janitors/20200421081257.GA131897@infradead.org/
[2]: https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
Link: https://lore.kernel.org/r/516375d6d06114484533baf03aae351306100246.1641500561.git.christophe.jaillet@wanadoo.fr
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This patch is based on one in the Xilinx kernel tree, "ASoc: xlnx: Make
buffer bytes multiple of period bytes" by Devarsh Thakkar. The same
issue exists in the mainline version of the driver. The original
patch description is as follows:
"The Xilinx Audio Formatter IP has a constraint on period
bytes to be multiple of 64. This leads to driver changing
the period size to suitable frames such that period bytes
are multiple of 64.
Now since period bytes and period size are updated but not
the buffer bytes, this may make the buffer bytes unaligned
and not multiple of period bytes.
When this happens we hear popping noise as while DMA is being
done the buffer bytes are not enough to complete DMA access
for last period of frame within the application buffer boundary.
To avoid this, align buffer bytes too as multiple of 64, and
set another constraint to always enforce number of periods as
integer. Now since, there is already a rule in alsa core
to enforce Buffer size = Number of Periods * Period Size
this automatically aligns buffer bytes as multiple of period
bytes."
Fixes: 6f6c3c36f0 ("ASoC: xlnx: add pcm formatter platform driver")
Cc: Devarsh Thakkar <devarsh.thakkar@xilinx.com>
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Link: https://lore.kernel.org/r/20220107214711.1100162-2-robert.hancock@calian.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Make digital tuning store the bandwidth in Hz in the private dev struct,
rather than the hardware-specific bandwidth property code, so that the
get_bandwidth() function returns the bandwidth in Hz, just as it already
does when using analog tuning.
Link: https://lore.kernel.org/linux-media/trinity-931c0e68-88af-46cc-91a1-986754798a4f-1641509499366@3c-app-gmx-bap68
Reported-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Commit 98c65a3dac ("media: si2157: add support for 1.7MHz and 6.1
MHz") introduced two bugs: The 6.1MHz setting was always used for any
bandwidth less than 7MHz due to missing "else" keywords, and then the
setting was not specified as decimal 10, but as hexadecimal 0x10, which
makes the tuner refuse the tune command. In sum, it is not possible to
tune to any channels of less than 7MHz bandwidth anymore.
Add the missing "else" keywords and convert all bandwidth settings to
decimal to avoid any future decimal vs. hexadecimal confusion.
Remove the use of the undefined bandwidth setting 0x0f for bandwidths
greater than 8MHz, which is also refused by the tune command, in favour
of using the default bandwidth setting 8 for any bandwidths greater than
7MHz.
Link: https://lore.kernel.org/linux-media/trinity-d0015ea1-1da5-4c7d-a75b-781fb26dc339-1641509387112@3c-app-gmx-bap68
Fixes: 98c65a3dac ("media: si2157: add support for 1.7MHz and 6.1 MHz")
Reported-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Robert Schlabbach <robert_s@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
When CONFIG_VIDEO_ATOMISP_ISP2401 is disabled, clang warns:
./drivers/staging/media/atomisp//pci/isp2400_input_system_local.h:32:40:
error: redefinition of typedef 'input_system_cfg2400_t' is a C11 feature
[-Werror,-Wtypedef-redefinition]
typedef struct input_system_cfg2400_s input_system_cfg2400_t;
^
./drivers/staging/media/atomisp//pci/input_system_local.h:22:40: note:
previous definition is here
typedef struct input_system_cfg2400_s input_system_cfg2400_t;
^
1 error generated.
input_system_cfg2400_t's typedef was copied from
isp2400_input_system_local.h to input_system_local.h, rather than moved.
Remove the one in isp2400_input_system_local.h so that there is no more
warning, which can break the build under -Werror.
Link: https://github.com/ClangBuiltLinux/linux/issues/1557
Link: https://lore.kernel.org/linux-media/20211227164243.2329724-1-nathan@kernel.org
Fixes: 4005ecee61 ("media: atomisp: shift some structs from input_system_local")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add a dedicated file vlv_sideband_reg.h for the VLV/CHV sideband
registers. The sideband registers macros are needed by the same files
that need vlv_sideband.h, so include the definitions from there.
v2: Fix copyright year (Matt)
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220110095740.166078-2-jani.nikula@intel.com
Purging can happen during swapping out, or directly invoked with the
madvise ioctl. In such cases this doesn't involve a ttm move, which
skips umapping the object.
v2(Thomas):
- add ttm_truncate helper, and just call into i915_ttm_move_notify() to
handle the unmapping step
Fixes: 213d509277 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220106174910.280616-4-matthew.auld@intel.com
(cherry picked from commit ab4911b7d4)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Ensure we call ttm_bo_unmap_virtual when releasing the pages.
Importantly this should now handle the ttm swapping case, and all other
places that already call into i915_ttm_move_notify().
v2: fix up the selftest
Fixes: cf3e3e86d7 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220106174910.280616-3-matthew.auld@intel.com
(cherry picked from commit 903e038727)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Don't attempt to fault and re-populate purged objects. By some fluke
this passes the dontneed-after-mmap IGT, but for the wrong reasons.
Fixes: cf3e3e86d7 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220106174910.280616-2-matthew.auld@intel.com
(cherry picked from commit f3cb4a2de5)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
A few more updates for v5.17, nothing hugely stand out in the few days
since the initial pull request was sent.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmHcKrQACgkQJNaLcl1U
h9CLHgf/eA8SDvjL0PzrGiNusrSKhNd0hDrDyrOGGKLjxEvauIr5WGRIgG3F9Frs
wQiyC7tJBJZ3kQ7WTkXbqY53cwO4QYDyQj9k/Knx/MouPSNcEfgHB+UWxOi8A9ON
5ySGN2PJTgqtGfBQdtQFvzNqs6kOzf83rl52ovTgvROmhJwnOV1iT2Oge5ynZeFM
jC/Dhs/DXy3V09LY2OcWAcv4/QGek7pblj5OS0/3yvFeMsjIuU3LhO+8lUptAtmw
eTbOoOXUdci5HVgSDw5O9cBlv+OS4Zk4VdXF4KvQ2Cp/Hlj3xdm2dSRyjBdYMGXb
X+L9BeJpFjEnv57zrzXcoycVjNHKCQ==
=iAwF
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.17-2' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.17
A few more updates for v5.17, nothing hugely stand out in the few days
since the initial pull request was sent.
Pull clocksource watchdog updates from Paul McKenney:
- Avoid accidental unstable marking of clocksources by rejecting
clocksource measurements where the source of the skew is the delay
reading reference clocksource itself. This change avoids many of the
current false positives caused by epic cache-thrashing workloads.
- Reduce the default clocksource_watchdog() retries to 2, thus offsetting
the increased overhead due to #1 above rereading the reference
clocksource.
Link: https://lore.kernel.org/lkml/20220105001723.GA536708@paulmck-ThinkPad-P17-Gen-1
- Fix GICv3 redistributor table reservation with RT across kexec
- Fix GICv4.1 redistributor view of the VPE table across kexec
- Add support for extra interrupts on spear-shirq
- Make obtaining some interrupts optional for the Renesas drivers
- Various cleanups and bug fixes
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAmHZitYPHG1hekBrZXJu
ZWwub3JnAAoJECPQ0LrRPXpDH4UP/3hsBH9KGWFakokvJJqXb8OS9LW2K8bEDm1B
9FaDAL6KamZVCGQmBUrzxuBSw1YSQszFZ752ozQpioEQ5IyTUcVbocxNznUOIOFc
F38f3jOS7KmjqTIMi7AM+lZPqrBH17cnMpRCorNF4CWVM+iHUUrxdYfV7AGifHyX
zpl9okkNpgdpO4gPBbPA0BBhIT+a9lmzqfFrfo+sMin6bgmk1mq3tJ4pVJV5K8KL
PXwa123eEtnr2P7JVnp+ChoECdv4QEFS0gFHw9CgE0XsKa5NjDoJsEkhl5lnNkTV
q387HGFyERsplknPzxLbF26IJQcUuJTX3PQFvuvv43ZNOqA/QI42956yIZ4KU6Er
cDWle9uj7xeHSbU48yz7wIGddpDY6abxlq4C8897itWiepR2iswW0hmEebFfDQ9n
A2imKdxZ6sUwwJ/lYiapdu6L5R9v1yx/4cmHfGyE1/FO5qKGzMOSKBJFt6eu+PdH
Lb04N+3IyhhI0REzZ/q803Gr9MsZ8SHl2x14BO6olLOvvVDn4p4QoL2mvsidpO3/
/SIKvElW9/jZSmmaW4pOchXbm6RX0cuiu2PtKk5srh7MoX2zoiRh5hsVzpCBNwxX
w5xbFCYX7s+KstG2kgnbRYrfsrgPl+6gX8M4bftYl3K9/bJ8ULSYEHAvI4emYlN2
6u89hrQL
=MDM3
-----END PGP SIGNATURE-----
Merge tag 'irqchip-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core
Pull irqchip updates from Marc Zyngier:
- Fix GICv3 redistributor table reservation with RT across kexec
- Fix GICv4.1 redistributor view of the VPE table across kexec
- Add support for extra interrupts on spear-shirq
- Make obtaining some interrupts optional for the Renesas drivers
- Various cleanups and bug fixes
Link: https://lore.kernel.org/lkml/20220108130807.4109738-1-maz@kernel.org
functional changes (Marek Szyprowski)
- Add imx8ulp compatible string for NPX TPM driver (Jacky Bai)
- Fix comma introduced by error by replacing it by the initial
semicolon on the Exynos_mct (Will Deacon)
- Add OSTM driver support on Renesas. The reset line must be
deasserted before accessing the registers. This change depends on an
external change resulting in a shared immutable branch
'reset/of-get-optional-exclusive' from
git://git.pengutronix.de/pza/linux (Biju Das)
- Make the OSTM Kconfig option visible to user in order to let him
disable it when ARM architected timers is enabled (Biju Das)
- Tag two variables on iMX sysctr _ro_afterinit (Peng Fan)
- Set the cpumask to cpu_possible_mask in order to have full benefit
of the DYNIRQ flag on iMX sysctr (Peng Fan)
- Tag __maybe_unused a variable in the Pistachio timer driver in order
to fix a warning reported by the kernel test robot (Drew Fustini)
- Add MStar MSC313e timer support and the ssd20xd-based variant, as
well as the DT bindings (Romain Perier)
- Remove the incompatible compatible string for the rk3066 (Johan
Jonker)
- Fix dts_check warnings on the cadence ttc driver by adding the power
domain bindings (Michal Simek)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGn3N4YVz0WNVyHskqDIjiipP6E8FAmHEk0EACgkQqDIjiipP
6E98zwf+PJaoWPPn8vl0rqZqy3GiHfYD/78Fi+fMqDUaN7HbtkKCgJEX074z6B71
WvN3g2DfmkDDsbJ9BR4iSBuqRjfI3r701N4QCZgu8zPB2tqjMT7Coz18jBpTC+rt
yPr5R8yrZZ3t6KduPhFbjD/15vPGO94BcKqC/UV4lL22G4PZOUuiXFMG/UR5/3O5
NmP5VqDjzKdY0tRc22aIuQm/QOQXmEPsP+XjQxkeXC8Er9Xr7QqfwJv+QTYMrvGF
4blsknsLJiW427vlYqg+iWme7mq7zxnlKJ+ugDz2pBS/E8lC32pnApW+o3HCqfP+
gmSiHvNaq2jhLTP8E8S1Gi09g6s/zQ==
=0JsC
-----END PGP SIGNATURE-----
Merge tag 'timers-v5.17-rc1' of https://git.linaro.org/people/daniel.lezcano/linux into timers/core
Pull clocksource/events updates from Daniel Lezcano:
- Refactor resource allocation on the Exynos_mct driver without
functional changes (Marek Szyprowski)
- Add imx8ulp compatible string for NPX TPM driver (Jacky Bai)
- Fix comma introduced by error by replacing it by the initial
semicolon on the Exynos_mct (Will Deacon)
- Add OSTM driver support on Renesas. The reset line must be
deasserted before accessing the registers. This change depends on an
external change resulting in a shared immutable branch
'reset/of-get-optional-exclusive' from
git://git.pengutronix.de/pza/linux (Biju Das)
- Make the OSTM Kconfig option visible to user in order to let him
disable it when ARM architected timers is enabled (Biju Das)
- Tag two variables on iMX sysctr _ro_afterinit (Peng Fan)
- Set the cpumask to cpu_possible_mask in order to have full benefit
of the DYNIRQ flag on iMX sysctr (Peng Fan)
- Tag __maybe_unused a variable in the Pistachio timer driver in order
to fix a warning reported by the kernel test robot (Drew Fustini)
- Add MStar MSC313e timer support and the ssd20xd-based variant, as
well as the DT bindings (Romain Perier)
- Remove the incompatible compatible string for the rk3066 (Johan
Jonker)
- Fix dts_check warnings on the cadence ttc driver by adding the power
domain bindings (Michal Simek)
Link: https://lore.kernel.org/lkml/e093c706-c98d-29ee-0102-78b6d41c6164@linaro.org
Fix possible memory leak in error path of storvsc_queuecommand() when
DMA mapping fails.
Signed-off-by: Juan Vazquez <juvazq@linux.microsoft.com>
Reviewed-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
Link: https://lore.kernel.org/r/20220109001758.6401-1-juvazq@linux.microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Change the nfs filesystem to support fscache's indexing rewrite and
reenable caching in nfs.
The following changes have been made:
(1) The fscache_netfs struct is no more, and there's no need to register
the filesystem as a whole.
(2) The session cookie is now an fscache_volume cookie, allocated with
fscache_acquire_volume(). That takes three parameters: a string
representing the "volume" in the index, a string naming the cache to
use (or NULL) and a u64 that conveys coherency metadata for the
volume.
For nfs, I've made it render the volume name string as:
"nfs,<ver>,<family>,<address>,<port>,<fsidH>,<fsidL>*<,param>[,<uniq>]"
(3) The fscache_cookie_def is no more and needed information is passed
directly to fscache_acquire_cookie(). The cache no longer calls back
into the filesystem, but rather metadata changes are indicated at
other times.
fscache_acquire_cookie() is passed the same keying and coherency
information as before.
(4) fscache_enable/disable_cookie() have been removed.
Call fscache_use_cookie() and fscache_unuse_cookie() when a file is
opened or closed to prevent a cache file from being culled and to keep
resources to hand that are needed to do I/O.
If a file is opened for writing, we invalidate it with
FSCACHE_INVAL_DIO_WRITE in lieu of doing writeback to the cache,
thereby making it cease caching until all currently open files are
closed. This should give the same behaviour as the uptream code.
Making the cache store local modifications isn't straightforward for
NFS, so that's left for future patches.
(5) fscache_invalidate() now needs to be given uptodate auxiliary data and
a file size. It also takes a flag to indicate if this was due to a
DIO write.
(6) Call nfs_fscache_invalidate() with FSCACHE_INVAL_DIO_WRITE on a file
to which a DIO write is made.
(7) Call fscache_note_page_release() from nfs_release_page().
(8) Use a killable wait in nfs_vm_page_mkwrite() when waiting for
PG_fscache to be cleared.
(9) The functions to read and write data to/from the cache are stubbed out
pending a conversion to use netfslib.
Changes
=======
ver #3:
- Added missing =n fallback for nfs_fscache_release_file()[1][2].
ver #2:
- Use gfpflags_allow_blocking() rather than using flag directly.
- fscache_acquire_volume() now returns errors.
- Remove NFS_INO_FSCACHE as it's no longer used.
- Need to unuse a cookie on file-release, not inode-clear.
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Co-developed-by: David Howells <dhowells@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Dave Wysochanski <dwysocha@redhat.com>
Acked-by: Jeff Layton <jlayton@kernel.org>
cc: Trond Myklebust <trond.myklebust@hammerspace.com>
cc: Anna Schumaker <anna.schumaker@netapp.com>
cc: linux-nfs@vger.kernel.org
cc: linux-cachefs@redhat.com
Link: https://lore.kernel.org/r/202112100804.nksO8K4u-lkp@intel.com/ [1]
Link: https://lore.kernel.org/r/202112100957.2oEDT20W-lkp@intel.com/ [2]
Link: https://lore.kernel.org/r/163819668938.215744.14448852181937731615.stgit@warthog.procyon.org.uk/ # v1
Link: https://lore.kernel.org/r/163906979003.143852.2601189243864854724.stgit@warthog.procyon.org.uk/ # v2
Link: https://lore.kernel.org/r/163967182112.1823006.7791504655391213379.stgit@warthog.procyon.org.uk/ # v3
Link: https://lore.kernel.org/r/164021575950.640689.12069642327533368467.stgit@warthog.procyon.org.uk/ # v4
Change the 9p filesystem to take account of the changes to fscache's
indexing rewrite and reenable caching in 9p.
The following changes have been made:
(1) The fscache_netfs struct is no more, and there's no need to register
the filesystem as a whole.
(2) The session cookie is now an fscache_volume cookie, allocated with
fscache_acquire_volume(). That takes three parameters: a string
representing the "volume" in the index, a string naming the cache to
use (or NULL) and a u64 that conveys coherency metadata for the
volume.
For 9p, I've made it render the volume name string as:
"9p,<devname>,<cachetag>"
where the cachetag is replaced by the aname if it wasn't supplied.
This probably needs rethinking a bit as the aname can have slashes in
it. It might be better to hash the cachetag and use the hash or I
could substitute commas for the slashes or something.
(3) The fscache_cookie_def is no more and needed information is passed
directly to fscache_acquire_cookie(). The cache no longer calls back
into the filesystem, but rather metadata changes are indicated at
other times.
fscache_acquire_cookie() is passed the same keying and coherency
information as before.
(4) The functions to set/reset/flush cookies are removed and
fscache_use_cookie() and fscache_unuse_cookie() are used instead.
fscache_use_cookie() is passed a flag to indicate if the cookie is
opened for writing. fscache_unuse_cookie() is passed updates for the
metadata if we changed it (ie. if the file was opened for writing).
These are called when the file is opened or closed.
(5) wait_on_page_bit[_killable]() is replaced with the specific wait
functions for the bits waited upon.
(6) I've got rid of some of the 9p-specific cache helper functions and
called things like fscache_relinquish_cookie() directly as they'll
optimise away if v9fs_inode_cookie() returns an unconditional NULL
(which will be the case if CONFIG_9P_FSCACHE=n).
(7) v9fs_vfs_setattr() is made to call fscache_resize() to change the size
of the cache object.
Notes:
(A) We should call fscache_invalidate() if we detect that the server's
copy of a file got changed by a third party, but I don't know where to
do that. We don't need to do that when allocating the cookie as we
get a check-and-invalidate when we initially bind to the cache object.
(B) The copy-to-cache-on-writeback side of things will be handled in
separate patch.
Changes
=======
ver #3:
- Canonicalise the cookie key and coherency data to make them
endianness-independent.
ver #2:
- Use gfpflags_allow_blocking() rather than using flag directly.
- fscache_acquire_volume() now returns errors.
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Jeff Layton <jlayton@kernel.org>
Tested-by: Dominique Martinet <asmadeus@codewreck.org>
cc: Eric Van Hensbergen <ericvh@gmail.com>
cc: Latchesar Ionkov <lucho@ionkov.net>
cc: v9fs-developer@lists.sourceforge.net
cc: linux-cachefs@redhat.com
Link: https://lore.kernel.org/r/163819664645.215744.1555314582005286846.stgit@warthog.procyon.org.uk/ # v1
Link: https://lore.kernel.org/r/163906975017.143852.3459573173204394039.stgit@warthog.procyon.org.uk/ # v2
Link: https://lore.kernel.org/r/163967178512.1823006.17377493641569138183.stgit@warthog.procyon.org.uk/ # v3
Link: https://lore.kernel.org/r/164021573143.640689.3977487095697717967.stgit@warthog.procyon.org.uk/ # v4
KASAN detected the following issue:
BUG: KASAN: slab-out-of-bounds in hyperv_flush_tlb_multi+0xf88/0x1060
Read of size 4 at addr ffff8880011ccbc0 by task kcompactd0/33
CPU: 1 PID: 33 Comm: kcompactd0 Not tainted 5.14.0-39.el9.x86_64+debug #1
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine,
BIOS Hyper-V UEFI Release v4.0 12/17/2019
Call Trace:
dump_stack_lvl+0x57/0x7d
print_address_description.constprop.0+0x1f/0x140
? hyperv_flush_tlb_multi+0xf88/0x1060
__kasan_report.cold+0x7f/0x11e
? hyperv_flush_tlb_multi+0xf88/0x1060
kasan_report+0x38/0x50
hyperv_flush_tlb_multi+0xf88/0x1060
flush_tlb_mm_range+0x1b1/0x200
ptep_clear_flush+0x10e/0x150
...
Allocated by task 0:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x7c/0x90
hv_common_init+0xae/0x115
hyperv_init+0x97/0x501
apic_intr_mode_init+0xb3/0x1e0
x86_late_time_init+0x92/0xa2
start_kernel+0x338/0x3eb
secondary_startup_64_no_verify+0xc2/0xcb
The buggy address belongs to the object at ffff8880011cc800
which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 960 bytes inside of
1024-byte region [ffff8880011cc800, ffff8880011ccc00)
'hyperv_flush_tlb_multi+0xf88/0x1060' points to
hv_cpu_number_to_vp_number() and '960 bytes' means we're trying to get
VP_INDEX for CPU#240. 'nr_cpus' here is exactly 240 so we're trying to
access past hv_vp_index's last element. This can (and will) happen
when 'cpus' mask is empty and cpumask_last() will return '>=nr_cpus'.
Commit ad0a6bad44 ("x86/hyperv: check cpu mask after interrupt has
been disabled") tried to deal with empty cpumask situation but
apparently didn't fully fix the issue.
'cpus' cpumask which is passed to hyperv_flush_tlb_multi() is
'mm_cpumask(mm)' (which is '&mm->cpu_bitmap'). This mask changes every
time the particular mm is scheduled/unscheduled on some CPU (see
switch_mm_irqs_off()), disabling IRQs on the CPU which is performing remote
TLB flush has zero influence on whether the particular process can get
scheduled/unscheduled on _other_ CPUs so e.g. in the case where the mm was
scheduled on one other CPU and got unscheduled during
hyperv_flush_tlb_multi()'s execution will lead to cpumask becoming empty.
It doesn't seem that there's a good way to protect 'mm_cpumask(mm)'
from changing during hyperv_flush_tlb_multi()'s execution. It would be
possible to copy it in the very beginning of the function but this is a
waste. It seems we can deal with changing cpumask just fine.
When 'cpus' cpumask changes during hyperv_flush_tlb_multi()'s
execution, there are two possible issues:
- 'Under-flushing': we will not flush TLB on a CPU which got added to
the mask while hyperv_flush_tlb_multi() was already running. This is
not a problem as this is equal to mm getting scheduled on that CPU
right after TLB flush.
- 'Over-flushing': we may flush TLB on a CPU which is already cleared
from the mask. First, extra TLB flush preserves correctness. Second,
Hyper-V's TLB flush hypercall takes 'mm->pgd' argument so Hyper-V may
avoid the flush if CR3 doesn't match.
Fix the immediate issue with cpumask_last()/hv_cpu_number_to_vp_number()
and remove the pointless cpumask_empty() check from the beginning of the
function as it really doesn't protect anything. Also, avoid the hypercall
altogether when 'flush->processor_mask' ends up being empty.
Fixes: ad0a6bad44 ("x86/hyperv: check cpu mask after interrupt has been disabled")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20220106094611.1404218-1-vkuznets@redhat.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Add a static entry in the x86 table, to detect and wait for
privacy-screen on some ChromeOS platforms.
Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
shall return EPROBE_DEFER until a platform driver actually registers the
privacy-screen: https://hansdegoede.livejournal.com/25948.html
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220107190208.95479-3-rajatja@google.com
This adds the ACPI driver for the ChromeOS privacy screen that is
present on some chromeos devices.
Note that ideally, we'd want this privacy screen driver to be probed
BEFORE the drm probe in order to avoid a drm probe deferral:
https://hansdegoede.livejournal.com/25948.html
In practise, I found that ACPI drivers are bound to their devices AFTER
the drm probe on chromebooks. So on chromebooks with privacy-screen,
this patch along with the other one in this series results in a probe
deferral of about 250ms for i915 driver. However, it did not result in
any user noticeable delay of splash screen in my personal experience.
In future if this probe deferral turns out to be an issue, we can
consider turning this ACPI driver into something that is probed
earlier than the drm drivers.
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220107190208.95479-2-rajatja@google.com
Allow a privacy screen provider to stash its private data pointer in the
drm_privacy_screen, and update the drm_privacy_screen_register() call to
accept that. Also introduce a *_get_drvdata() so that it can retrieved
back when needed.
This also touches the IBM Thinkpad platform driver, the only user of
privacy screen today, to pass NULL for now to the updated API.
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220107190208.95479-1-rajatja@google.com
Purging can happen during swapping out, or directly invoked with the
madvise ioctl. In such cases this doesn't involve a ttm move, which
skips umapping the object.
v2(Thomas):
- add ttm_truncate helper, and just call into i915_ttm_move_notify() to
handle the unmapping step
Fixes: 213d509277 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220106174910.280616-4-matthew.auld@intel.com
Ensure we call ttm_bo_unmap_virtual when releasing the pages.
Importantly this should now handle the ttm swapping case, and all other
places that already call into i915_ttm_move_notify().
v2: fix up the selftest
Fixes: cf3e3e86d7 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220106174910.280616-3-matthew.auld@intel.com
Don't attempt to fault and re-populate purged objects. By some fluke
this passes the dontneed-after-mmap IGT, but for the wrong reasons.
Fixes: cf3e3e86d7 ("drm/i915: Use ttm mmap handling for ttm bo's.")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220106174910.280616-2-matthew.auld@intel.com
Existing HPD enablement logic is not compatible with ADV7535
bridge, thus any runtime plug-in of HDMI cable is not working
on these bridge designs.
Unlike other ADV7511 family of bridges, the ADV7535 require
HPD_OVERRIDE bit to set and reset for proper handling of HPD
functionality.
Fix it.
Fixes: 8501fe4b14 ("drm: bridge: adv7511: Add support for ADV7535")
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220109172949.168167-1-jagan@amarulasolutions.com
Reviewed-by: Robert Foss <robert.foss@linaro.org>
This patch provides HDCP setting interface for userspace to dynamic
enable/disable HDCP function.
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Xin Ji <xji@analogixsemi.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220106100127.1862702-2-xji@analogixsemi.com
