The ACPI namespace scanning code uses the terms master/slave when
populating the list of _DEP dependencies, but that use has no
external exposures and is not mandated by nor associated with any
external specifications.
Change the language used through-out to supplier/consumer.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
According to Hans, all device objects where the _HID returns
"INT3396" also have a _CID returning "PNP0D80", so the former
need not be present in acpi_ignore_dep_ids[] any more.
Link: https://lore.kernel.org/linux-acpi/52a2b98c-6bf3-760b-eca9-93cf05fb4877@redhat.com/
Suggested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Here's a patch updating the meaning of TAINT_CPU_OUT_OF_SPEC after
Borislav introduced changes in a7e1f67ed2 and upcoming patches in tip.
TAINT_CPU_OUT_OF_SPEC now means a bit more what it implies as the
flag isn't set just because of a CPU misconfiguration or mismatch.
Historically it was for SMP kernel oops on an officially SMP incapable
processor but now it also covers CPUs whose MSRs have been incorrectly
poked at from userspace, drivers being used on non supported
architectures, broken firmware, mismatched CPUs, ...
Update documentation and script to reflect that.
Signed-off-by: Mathieu Chouquet-Stringer <me@mathieu.digital>
Link: https://lore.kernel.org/r/20201202153244.709752-1-me@mathieu.digital
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The GT-King and GT-King-Pro boxes have an RTC chip and power cell, so enable it.
GTKING:~ # dmesg | grep rtc
[ 5.237245] meson-vrtc ff8000a8.rtc: registered as rtc1
[ 5.261869] rtc-hym8563 0-0051: registered as rtc0
[ 5.265016] rtc-hym8563 0-0051: setting system clock to 2020-11-30T09:16:54 UTC (1606727814)
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20201201062135.18241-1-christianshewitt@gmail.com
Add initial reset controller API documentation. This is mostly intended
to describe the concepts to users of the consumer API, and to tie the
kerneldoc comments we already have into the driver API documentation.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Amjad Ouled-Ameur <aouledameur@baylibre.fr>
Link: https://lore.kernel.org/r/20201201115754.1713-1-p.zabel@pengutronix.de
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Commit
26bfa5f894 ("x86, amd: Cleanup init_amd")
moved the code that remaps the TSEG region using 4k pages from
init_amd() to bsp_init_amd().
However, bsp_init_amd() is executed well before the direct mapping is
actually created:
setup_arch()
-> early_cpu_init()
-> early_identify_cpu()
-> this_cpu->c_bsp_init()
-> bsp_init_amd()
...
-> init_mem_mapping()
So the change effectively disabled the 4k remapping, because
pfn_range_is_mapped() is always false at this point.
It has been over six years since the commit, and no-one seems to have
noticed this, so just remove the code. The original code was also
incomplete, since it doesn't check how large the TSEG address range
actually is, so it might remap only part of it in any case.
Hygon has copied the incorrect version, so the code has never run on it
since the cpu support was added two years ago. Remove it from there as
well.
Committer notes:
This workaround is incomplete anyway:
1. The code must check MSRC001_0113.TValid (SMM TSeg Mask MSR) first, to
check whether the TSeg address range is enabled.
2. The code must check whether the range is not 2M aligned - if it is,
there's nothing to work around.
3. In all the BIOSes tested, the TSeg range is in a e820 reserved area
and those are not mapped anymore, after
66520ebc2d ("x86, mm: Only direct map addresses that are marked as E820_RAM")
which means, there's nothing to be worked around either.
So let's rip it out.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201127171324.1846019-1-nivedita@alum.mit.edu
Make various places which point to
Documentation/admin-guide/reporting-bugs.rst point to
Documentation/admin-guide/reporting-issues.rst instead. That document is
brand new and as of now is not completely finished. But even at this
stage it's a lot more helpful and accurate than reporting-bugs.rst.
Hence also add a note to reporting-bugs.rst, telling people they're
better off reading reporting-issues.rst instead.
reporting-bugs.rst is scheduled for removal once reporting-issues.rst
is considered ready.
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Link: https://lore.kernel.org/r/3df7c2d16de112b47bb6e6158138608e78562bf5.1607063223.git.linux@leemhuis.info
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Add a mostly finished document describing how to report issues with the
Linux kernel to its developers. It is designed to be a lot more straight
forward and easier to follow than the current text about this
(Documentation/admin-guide/reporting-bugs.rst); at the same time the new
text should be more helpful for people unfamiliar with the topic, as it
provides a lot more details, too.
The main work on the text is done, but some polishing is still needed.
The text also needs to be reviewed by more people and a few issues still
might need some discussion. To make these tasks easier, it was decided
([1]) to add this document to the kernel sources in parallel to the
existing text; the latter will be removed once this text is considered
good enough(tm).
This document is quite long and provides a lot of details, but was
carefully crafted to make sure it's can also serve people that are in a
hurry. That's mainly achieved by having a TDLR and a step-by-step guide,
which should be good enough for quite a lot of people. Everybody that
wants or need more explanations can find them in a reference section,
which describes all the needed steps in detail.
Thanks to this structure the text can work for kernel developers that
just need to look something up, experienced FLOSS contributors that are
unfamiliar with the kernel's bug reporting workflow, and users reporting
something upstream for the first time. The text is thus a bit like the
kernel itself, which works well for embedded machines, a typical desktop
PC, cloud servers, and HPC.
The document was written in the hope it will improve the quality of the
bug reports, especially those that come from people unfamiliar with how
Linux kernel development works. Sadly quite a few reports from this
group are currently of poor quality and/or get submitted to the wrong
place. Part of the problem is the old reporting-bugs document, as it
makes its essence hard to grasp; it's and also inaccurate and slightly
outdated in a few spots. Due to this quite a few valid reports are
ignored in the end, which is annoying for those that compiled them and
bad for the kernel's quality.
The document near the top points out that it's still unfinished, but
nevertheless ready for consumption. Those few areas in the text that
might need some further discussion contain a note pointing this out.
Besides lack of review from core developers there is only one major
issue left: the section 'Decode failure message' is known to be
outdated: it's waiting for someone familiar with the topic to write
something up or give at least provide some hints and pointers what to
write there.
The new document is dual-licensed under GPL-2.0+ or CC-BY-4.0. The
latter is way more liberal and makes it attractive to use this text as a
base when writing about this topic on websites or in books. This
hopefully increases the chances that such texts are accurate and stick
to official way of doing things.
[1] https://lkml.kernel.org/r/20201118172958.5b014a44@lwn.net
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/e2db808f954744b79f10937a923d9c99bdca1fca.1607063223.git.linux@leemhuis.info
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Add the full text of the CC-BY-4.0 license to the kernel tree as well as
the required tags for reference and tooling.
The license text was copied directly from the following url, but for
clarification a 'Creative Commons' was added before 'Attribution 4.0
International' in the first line:
https://creativecommons.org/licenses/by/4.0/legalcode.txt
CC-BY-4.0 is GPLv2 compatible, but when for example used for the
kernel's documentation it can easily happen that sphinx during
processing combines it with text or code from files using a more
restrictive license[1]. This bears pitfalls, hence point that risk out
and suggest to only use this license in combination with the GPLv2.
[1] https://lkml.kernel.org/r/20201201144314.GA14256@lst.de
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/7115b6c20ae3e6db0370fe4002dd586011205e1c.1607063223.git.linux@leemhuis.info
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This cleans up a few titles with extra colons, and removes the
reference to kernel 2.2. The docs don't yet cover *all* of 5.10 or
5.11, but I think they're close enough. Most entries are documented,
and have been checked against current kernels.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20201208074922.30359-1-steve@sk2.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
When the sum of the utilization of CPUs in a power domain is zero,
return the energy as 0 without doing any computations.
Acked-by: Quentin Perret <qperret@google.com>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The documentation refers to a non-existent 'struct synth_trace_state'
structure. The correct name is 'struct synth_event_trace_state'.
In other words, this patch is a mechanical substitution:
s/synth_trace_state/synth_event_trace_state/g
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Reviewed-by: Tom Zanussi <zanussi@kernel.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lore.kernel.org/r/20201104122113.322452-1-dedekind1@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This patch fixes a couple of bugs in the DA9121 driver.
One in an uninialised string I forgot to remove when changing to of_parse_cb()
The other is an index for an optional DT property which overflows
Adam Ward (2):
regulator: da9121: Remove uninitialised string variable
regulator: da9121: Fix index used for DT property
drivers/regulator/da9121-regulator.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--
1.9.1
Hi All,
Here are 2 simple fixes which are necessary to make the
cht_bsw_nau8824 machine driver work together with the
sof-audio-acpi driver.
Note that atm the sof topology files are missing a .tplg
file for this setup. Simply copying over the standard
sof-byte-codec.tplg file does the trick, but then some
mixer setting changes are necessary to fix the right
speaker/headphones channel not working; and those mixer
settings break the right channel when used with the
sst-acpi driver.
I've been trying to fix this at the tplg level so that
we do not need to change the mixer settings, but no luck
sofar. I'll post a RFC with the topology changes which
I have and we can discuss this further there.
These 2 simple fixes are necessary to make the sof-audio-acpi
driver work regardless of the topology issue.
Regards,
Hans
cz_da7219_init() does not check the return values of clk_get(),
while da7219_clk_enable() calls clk_set_rate() to dereference
the pointers.
Add checks to fix the problems.
Also, change clk_get() to devm_clk_get() to avoid data leak after
failures.
Fixes: bb24a31ed5 ("ASoC: AMD: Configure wclk and bclk of master codec")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20201204063610.513556-1-hslester96@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
At line 294 in drivers/lightnvm/pblk-write.c, function pblk_gen_run_ws is
called with actual param GFP_ATOMIC. pblk_gen_run_ws call mempool_alloc
using "GFP_ATOMIC" flag, so mempool_alloc can return null. So we need to
check the return-val of mempool_alloc to avoid null-ptr-deref bug.
Signed-off-by: tangzhenhao <tzh18@mails.tsinghua.edu.cn>
Reviewed-by: Matias Bjørling <mb@lightnvm.io>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Commit 7ecdea4a02 ("backlight: generic_bl: Remove this driver as it is
unused") removed geenric_bl driver from the tree, together with
corresponding config option.
Remove BACKLIGHT_GENERIC config item from arm64 configuration.
Fixes: 7ecdea4a02 ("backlight: generic_bl: Remove this driver as it is unused")
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: https://lore.kernel.org/r/20201201222922.3183-3-andrey.zhizhikin@leica-geosystems.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Commit 7ecdea4a02 ("backlight: generic_bl: Remove this driver as it is
unused") removed geenric_bl driver from the tree, together with
corresponding config option.
Remove BACKLIGHT_GENERIC config item from all ARM configurations.
Fixes: 7ecdea4a02 ("backlight: generic_bl: Remove this driver as it is unused")
Signed-off-by: Andrey Zhizhikin <andrey.zhizhikin@leica-geosystems.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Link: https://lore.kernel.org/r/20201201222922.3183-2-andrey.zhizhikin@leica-geosystems.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- A couple of patches that enable various i.MX audio drivers for i.MX8M.
- Enable more drivers that are useful on Librem 5 hardware.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAl/HokMUHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM6oCggAs8waHnriWnEi6pBv/vuX1GFNPsoj
EmPk505RL6akL+QiGwFl9L4/k+khuZRgUbUfgsrx1qTcpu3XyKrIfABmez1vJIXT
staufuHoOsgjJUzP+aeuyoc/PVhq1EtV/xPAjQrhIHnET5NxIJPiOg+caHnLyD71
Z9hJYy72o1S4p+FMVjB5icc9P/yZh7fZNBj3eH7x8YF0jRnePoDomykIPua+xt19
Qtz1mSg9YZF1NXXrY+TX5BP7J0byeCgicFRrV9VLIMnv2qq3oKKwqpTFjw52G4IL
dinAlOtKhuVmMprveDXVUHyzpifTaCOF7vjwA9By8sJCkJTKgz9x02KcjQ==
=LJQK
-----END PGP SIGNATURE-----
Merge tag 'imx-defconfig-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/defconfig
i.MX defconfig update for 5.11:
- A couple of patches that enable various i.MX audio drivers for i.MX8M.
- Enable more drivers that are useful on Librem 5 hardware.
* tag 'imx-defconfig-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
arm64: defconfig: Enable more Librem 5 hardware
arm64: defconfig: Enable ASRC and EASRC
arm64: defconfig: Enable additional sound drivers on i.MX8M Mini
Link: https://lore.kernel.org/r/20201202142717.9262-6-shawnguo@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This enables the Qualcomm PON and OSM L3 drivers. It then ensures that
the QCOM_SCM and Command DB drivers are built-in, now that they have
been made user selectable and tristate.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAl/FL88bHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FSgMP/3UlXphDNwFXV3i52vmm
IEbJl+jXt/sibR9g9yMZubSu0zZKIEZZL6QVPRcU+HOjW9auZz3t/jQBGC4jWVjc
QICEHtQIsWW6lpaUVd7yMANHqE9uGkqXjK1NsKyIuGjAogv1/MpN3sElLZFZ/fWT
xMZ7/YF0ENWHCbLNILODmXsaBob++pexj5r6dO/VDXi6OkNvGLsshCtU8kDOUF0p
Jyt+Iog1Xe7joyTalvLc1RTJtZrDy09aGnPJ8naC9DFz28hMuX1ka4R2XJUPziRX
3WpoEntkwNqR7Eqre6hJ8DQMcgEQswP45kd/LnlklQpehQFvKzchpElBL68cR5jC
UqGvBqqVU6bTZqpgU5vQ4d0JpBU/wWCeVuMzLgP9XOqDh5eepCBw95lLynKl1vmM
wRlEEsb42lzVj6UZp0KZEwx9m0pD1g6kVjTcqgkn744a17Quf2c3cwnnLpVYoDV7
AQaUcxfp+UxsvG5HD9sKoigZyTh+O36pUfgEAmiNYnKvuJVQCnxwo6MxKQyxz9WB
qjrqOYBQ80/sSQUXH+A+xigI10cCUtznG/icN6PO4RAF6hw2i9LIB99QbgiWg3XA
T5HWvs8v7e/R2Bj6s1u8r0PbRpxio7Cj4WY6DDMfatMAWJgHyIMff4vmBTZJGzUO
LwTb6ps/f6AtJCHpp9HUgeJ5
=slxb
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig
Qualcomm defconfig updates for 5.11
This enables the Qualcomm PON and OSM L3 drivers. It then ensures that
the QCOM_SCM and Command DB drivers are built-in, now that they have
been made user selectable and tristate.
* tag 'qcom-arm64-defconfig-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Enable Qualcomm PON driver
arm64: defconfig: Enable QCOM_SCM as builtin
arm64: defconfig: Enable Qualcomm OSM L3 driver
arm64: defconfig: Enable Qualcomm Command DB driver
Link: https://lore.kernel.org/r/20201130190124.345127-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- GPIO and I2C for J721E SD card support to be functional
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE+KKGk1TrgjIXoxo03bWEnRc2JJ0FAl/FLQcACgkQ3bWEnRc2
JJ1pDBAAparXFEaiieQ6veeQLl8CLEHE6rUwbnm15ufdBg97y6urDPE1sZbyupsj
syBy6vwVtaPiciXFdC0OHj9IR5SzncUByLaYMRDi7pPa779IgpSLeVCv8cauRq5w
RHrHuRBH+cqlPJepVdxlot9A9k1It1c/RrG4e4IyoGB1yV7iQVQPqrndA/0YnpD2
gv0YmHH+x06pqNG3Ra8+kc/LiqXJDX0M8jxePR3UXe9EH/xNIlpn1VdVcXMPgGUO
FK04YuT+DgsrZBENfY3VGmIrRqQLd36zJsgp97g7sVUNmIsrRScdLu07KL/5vCee
lLAX/4hnmeDcWu61Cs4QmoxRZwFOn0e8rguVp9KYRqB/jSf2xvtqp/rzqNVuKweI
dH1m4uP2St/wwq+cNQizfykvZOnzuCTpk79yWpk70BfXSigUpswhTyYeaTCSscu6
M3rqP2rS0WfnXlK6vDRKVPZge/jPi5aMt0tzRMEdRF7R6Y+fVfoEmmz7dZ8UuLDR
0ODoO1Wl5KP6UKcPCzGiZs2qKxbkSZN1LmHilyEnl/SDhEJXUsNe0aKbM9X7wDbG
CTiH5Mzx9sc1eVKMG6BoABVN30+UOZ/xH38jMUe71JPScZAYm4TYPTtON2ifyw46
WRRpAmtGAb0yb+u8pGXF5FYGUPBta1vZ0F9ffqCYP3hraTXR14A=
=+rdo
-----END PGP SIGNATURE-----
Merge tag 'ti-k3-config-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux into arm/defconfig
ARM64 defconfig changes for TI K3 platforms for v5.11 merge window:
- GPIO and I2C for J721E SD card support to be functional
* tag 'ti-k3-config-for-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux:
arm64: defconfig: Enable GPIO and I2C configs for TI's J721e platform
Link: https://lore.kernel.org/r/20201130174850.ni4sdyz3qp67j3sz@upstart
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
the following:
- Florian enables the ARM SCMI protocol, and the common clock, HWMON and
CPU frequency scaling drivers since those are used by ARCH_BRCMSTB
platforms
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl/Cez0ACgkQh9CWnEQH
BwSwXxAAzRgh952TV4detmqzdbdRsSSaMpeBYyNsP512b/H6ZTofKjek//aoLguG
B6i1gLPrMAIOjuzhdtZ1YJAABJ6fy3It4KHRJWthwZU2hUJv6R5/3bH28t0EhS3u
0f8w84iiPeQTnu/+WkoFf5qK7P8dxXWMFrelZKyGEHYdL7nvwbXEZxt5Qwn2qMHW
HRUlxqef7qZLj1meFeffxZplWg64C7LMUD1OOq6VPBjNPQTmcSb72Z9jkbwVHcPx
WN9+cMzWmrbiqBcPoRPaOxrP5L3FNdbVPXMy2g5NvvKPopk8twQ61Wv1mBRh97Tb
wSi7HItUDq8SdK3kHA7MKe6LMCZ9Rv+QphZ2PYUedANpAjh1Y18q6HlpwcjKN2+N
FT2/iouy6v15fQDSqjNwvWdNIwIXxM5Bj1ARih964+5ali1K3HfFVEFCXV4tPgui
9V9oEcK6Ipx3hDA9iDEUoGuyv6PBO/HmGeoZf8SKeSwgUIjiUAI97VRC8+weS0Zs
uOhkdj18nvbEnE8u5XQAk+wT1mTpT8flJoPeViIdAUaY8sbqmgsw+eqDpfijFjSd
y8LNwc2MQeRFKiWpIoweTGRMHmlrFbTrzWMuucz2BGO2gWCyiB00BaO850LrhdgP
v2UjtRaSBL4+Y1uaj3n9u/OeZQLioF7EF7EpuFJB/+eZFJhgW9o=
=8JN3
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.11/defconfig-arm64' of https://github.com/Broadcom/stblinux into arm/defconfig
This pull request contains ARM64 defconfig changes for 5.11, please pull
the following:
- Florian enables the ARM SCMI protocol, and the common clock, HWMON and
CPU frequency scaling drivers since those are used by ARCH_BRCMSTB
platforms
* tag 'arm-soc/for-5.11/defconfig-arm64' of https://github.com/Broadcom/stblinux:
arm64: defconfig: Enable ARM SCMI protocol and drivers
Link: https://lore.kernel.org/r/20201128163410.1691529-2-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
please pull the following:
- Florian enables the ARM SCMI protocol, and the common clock, HWMON and
CPU frequency scaling drivers since those are used by ARCH_BRCMSTB
platforms
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl/CeyIACgkQh9CWnEQH
BwRx0Q//W7SOKgQZ2kt5VRy/Jgz7EKY5pxW5P/VwnXIW8Ikn64bGkkatWkO53kJD
rLMkvIsF+pQKuwM5FVkN9UVeyYu6D5xSEi6RRDTML7hkN4GIqywo8IEHdXI/zKMs
60/XS+9z0PMK9iSHa7NdM7iY/1OXr5eUvS0aAHwYAQFKh4HbufYKthd7E1oWlDeZ
9K326YeEQsMTYGu/tGn9v1JF85jDbdJdXExf4uHLdweXgubKJL0dUXoqadz39xBt
HsN4w1+Zl1S1BrfuSXL5sPQj/IXSpH7d1rLYmGO6g7IhsMBIUn7wg/XAVfd8KX7Z
gMPCCg3gIn//teQHyMLEvgtQNzk2wbUj8Qg/Y0etQkoxHnoGNwZkQpy+4ByJpmDy
1Oh0OBKfBhKA7RsgOkRJkC24odYrlXyiwB6wgcljpTYCTrEfqBuRwlMPLnN/XoUL
nILp3Tro1NmP3Dn1susefSTVYETopqIS4FIDWhzJxMw6V2h4IBGN2YKghYo6JaxV
2avT/QXGS0MNyM5NZs0ACYD0T/Al6S9iXIWS5+FX/6PY4+v1NvK53i202K6L/Quf
DhOubXo+Rv0ehFLJP8hiK0pDdcmg9Wt5s2rXQsYwm5l0PGWd0Wue42SIYM2BaGLC
bpLR+ioLBRNHzeOLrnUa7RmddASA6t2k4+1opQnVfwmZCiS86sY=
=k8ev
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.11/defconfig' of https://github.com/Broadcom/stblinux into arm/defconfig
This pull request contains ARM multi_v7_defconfig changes for 5.11,
please pull the following:
- Florian enables the ARM SCMI protocol, and the common clock, HWMON and
CPU frequency scaling drivers since those are used by ARCH_BRCMSTB
platforms
* tag 'arm-soc/for-5.11/defconfig' of https://github.com/Broadcom/stblinux:
ARM: multi_v7_defconfig: Enable ARM SCMI protocol and drivers
Link: https://lore.kernel.org/r/20201128163410.1691529-1-f.fainelli@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX8IzNQAKCRDj7w1vZxhR
xRGVAQCz65FoHboWxCwXPuduSZ6sCkyRjdSzw84U7qJzrWHgVgD+MR93mv7aYM4A
x+S/Pa1sxH3awHUw8JDmT51Qt0JijgU=
=rDZm
-----END PGP SIGNATURE-----
Merge tag 'sunxi-config64-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/defconfig
One patch to enable the Allwinner I2S controller on arm64's defconfig
* tag 'sunxi-config64-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: defconfig: Enable Allwinner i2s driver
Link: https://lore.kernel.org/r/5ddf5486-a20c-467a-bc67-d5e8fbc38856.lettre@localhost
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Return -ENOTSUPP if tracing BPF program is attempted to be attached with
specified attach_btf_obj_fd pointing to non-kernel (neither vmlinux nor
module) BTF object. This scenario might be supported in the future and isn't
outright invalid, so -EINVAL isn't the most appropriate error code.
Suggested-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20201208064326.667389-1-andrii@kernel.org
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX8IzEwAKCRDj7w1vZxhR
xVV7AQDpi1at4B5ETX/Nk562XUN60Ddt2OmYeH+mBoWUkecDEAEA+/HtJT7/5Sx1
ew24utZ15sZiEQIndYx/UJrTSoZ29ws=
=EVMX
-----END PGP SIGNATURE-----
Merge tag 'sunxi-config-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/defconfig
One patch to add the Realtek PHY driver to sunxi_defconfig
* tag 'sunxi-config-for-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
ARM: configs: sunxi: enable Realtek PHY
Link: https://lore.kernel.org/r/dffb8a7e-27ea-4025-868a-caa5868eb1ef.lettre@localhost
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
In AF_XDP the socket state needs to be checked, prior touching the
members of the socket. This was not the case for the recvmsg
implementation. Fix that by moving the xsk_is_bound() call.
Fixes: 45a8668184 ("xsk: Add support for recvmsg()")
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Link: https://lore.kernel.org/bpf/20201207082008.132263-1-bjorn.topel@gmail.com
In case of having so many PID results that they don't fit into a singe page
(4096) bytes, bpftool will erroneously conclude that it got corrupted data due
to 4096 not being a multiple of struct pid_iter_entry, so the last entry will
be partially truncated. Fix this by sizing the buffer to fit exactly N entries
with no truncation in the middle of record.
Fixes: d53dee3fe0 ("tools/bpftool: Show info for processes holding BPF map/prog/link/btf FDs")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20201204232002.3589803-1-andrii@kernel.org
Commit 849f3127bb ("switch /dev/kmsg to ->write_iter()") refactored
devkmsg_write() and left over a dead assignment on the variable 'len'.
Hence, make clang-analyzer warns:
kernel/printk/printk.c:744:4: warning: Value stored to 'len' is never read
[clang-analyzer-deadcode.DeadStores]
len -= endp - line;
^
Simply remove this obsolete dead assignment here.
Link: https://lore.kernel.org/r/20201130124915.7573-1-lukas.bulwahn@gmail.com
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Fix the following sparse warnings:
drivers/platform/x86/intel_speed_select_if/isst_if_mmio.c:23:24: warning: symbol 'mmio_range_devid_0' was not declared. Should it be static?
drivers/platform/x86/intel_speed_select_if/isst_if_mmio.c:28:24: warning: symbol 'mmio_range_devid_1' was not declared. Should it be static?
Signed-off-by: Zou Wei <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1607430489-116200-1-git-send-email-zou_wei@huawei.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The only user of tlb_flush_leaf is a particularly hairy corner of the
Arm short-descriptor code, which wants a synchronous invalidation to
minimise the races inherent in trying to split a large page mapping.
This is already far enough into "here be dragons" territory that no
sensible caller should ever hit it, and thus it really doesn't need
optimising. Although using tlb_flush_walk there may technically be
more heavyweight than needed, it does the job and saves everyone else
having to carry around useless baggage.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Link: https://lore.kernel.org/r/9844ab0c5cb3da8b2f89c6c2da16941910702b41.1606324115.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Merge in IOMMU fixes for 5.10 in order to resolve conflicts against the
queue for 5.11.
* for-next/iommu/fixes:
iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs
iommu/vt-d: Don't read VCCAP register unless it exists
x86/tboot: Don't disable swiotlb when iommu is forced on
iommu: Check return of __iommu_attach_device()
arm-smmu-qcom: Ensure the qcom_scm driver has finished probing
iommu/amd: Enforce 4k mapping for certain IOMMU data structures
MAINTAINERS: Temporarily add myself to the IOMMU entry
iommu/vt-d: Fix compile error with CONFIG_PCI_ATS not set
iommu/vt-d: Avoid panic if iommu init fails in tboot system
iommu/vt-d: Cure VF irqdomain hickup
x86/platform/uv: Fix copied UV5 output archtype
x86/platform/uv: Drop last traces of uv_flush_tlb_others
Intel VT-D updates for 5.11. The main thing here is converting the code
over to the iommu-dma API, which required some improvements to the core
code to preserve existing functionality.
* for-next/iommu/vt-d:
iommu/vt-d: Avoid GFP_ATOMIC where it is not needed
iommu/vt-d: Remove set but not used variable
iommu/vt-d: Cleanup after converting to dma-iommu ops
iommu/vt-d: Convert intel iommu driver to the iommu ops
iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
iommu: Add quirk for Intel graphic devices in map_sg
iommu: Allow the dma-iommu api to use bounce buffers
iommu: Add iommu_dma_free_cpu_cached_iovas()
iommu: Handle freelists when using deferred flushing in iommu drivers
iommu/vt-d: include conditionally on CONFIG_INTEL_IOMMU_SVM
Tegra SMMU updates for 5.11: a complete redesign of the probing logic,
support for PCI devices and cleanup work.
* for-next/iommu/tegra-smmu:
iommu/tegra-smmu: Add PCI support
iommu/tegra-smmu: Rework tegra_smmu_probe_device()
iommu/tegra-smmu: Use fwspec in tegra_smmu_(de)attach_dev
iommu/tegra-smmu: Expand mutex protection range
iommu/tegra-smmu: Unwrap tegra_smmu_group_get
We checked the table size against a hardcoded number of entries, and
that number was excluding the special mocs registers at the end.
Fixes: 777a7717d6 ("drm/i915/gt: Program mocs:63 for cache eviction on gen9")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.3+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201127102540.13117-1-chris@chris-wilson.co.uk
(cherry picked from commit 444fbf5d70)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[backported and updated the Fixes sha]
More steps along the way to Shared Virtual {Addressing, Memory} support
for Arm's SMMUv3, including the addition of a helper library that can be
shared amongst other IOMMU implementations wishing to support this
feature.
* for-next/iommu/svm:
iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops
iommu/arm-smmu-v3: Implement iommu_sva_bind/unbind()
iommu/sva: Add PASID helpers
iommu/ioasid: Add ioasid references
Miscellaneous IOMMU changes for 5.11. Largely cosmetic, apart from a
change to the way in which identity-mapped domains are configured so
that the requests are now batched and can potentially use larger pages
for the mapping.
* for-next/iommu/misc:
iommu/io-pgtable-arm: Remove unused 'level' parameter from iopte_type() macro
iommu: Defer the early return in arm_(v7s/lpae)_map
iommu: Improve the performance for direct_mapping
iommu: return error code when it can't get group
iommu: Modify the description of iommu_sva_unbind_device
This patch fixes the slice count computation algorithm
for calculating the slice count based on Peak pixel rate
and the max slice width allowed on the DSC engines.
We need to ensure slice count > min slice count req
as per DP spec based on peak pixel rate and that it is
greater than min slice count based on the max slice width
advertised by DPCD. So use max of these two.
In the prev patch we were using min of these 2 causing it
to violate the max slice width limitation causing a blank
screen on 8K@60.
Fixes: d9218c8f6c ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC")
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com
(cherry picked from commit d371d6ea92)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Currently the check that the unsigned size_t variable i is >= 0
is always true because the unsigned variable will never be negative,
causing the loop to run forever. Fix this by changing the
pre-decrement check to a zero check on i followed by a decrement of i.
Addresses-Coverity: ("Unsigned compared against 0")
Fixes: bfed6708d6 ("drm/i915: use vmap in shmem_pin_map")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20201002170354.94627-1-colin.king@canonical.com
(cherry picked from commit e70956a249)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
We currently presume that the engine reset is successful, cancelling the
expired preemption timer in the process. However, engine resets can
fail, leaving the timeout still pending and we will then respond to the
timeout again next time the tasklet fires. What we want is for the
failed engine reset to be promoted to a full device reset, which is
kicked by the heartbeat once the engine stops processing events.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1168
Fixes: 3a7a92aba8 ("drm/i915/execlists: Force preemption")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v5.5+
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204151234.19729-2-chris@chris-wilson.co.uk
(cherry picked from commit d997e240ce)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Before reseting the engine, we suspend the execution of the guilty
request, so that we can continue execution with a new context while we
slowly compress the captured error state for the guilty context. However,
if the reset fails, we will promptly attempt to reset the same request
again, and discover the ongoing capture. Ignore the second attempt to
suspend and capture the same request.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1168
Fixes: 32ff621fd7 ("drm/i915/gt: Allow temporary suspension of inflight requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v5.7+
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201204151234.19729-1-chris@chris-wilson.co.uk
(cherry picked from commit b969540500)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
In the course of discovering and closing many races with context closure
and execbuf submission, since commit 61231f6bd0 ("drm/i915/gem: Check
that the context wasn't closed during setup") we started checking that
the context was not closed by another userspace thread during the execbuf
ioctl. In doing so we cancelled the inflight request (by telling it to be
skipped), but kept reporting success since we do submit a request, albeit
one that doesn't execute. As the error is known before we return from the
ioctl, we can report the error we detect immediately, rather than leave
it on the fence status. With the immediate propagation of the error, it
is easier for userspace to handle.
Fixes: 61231f6bd0 ("drm/i915/gem: Check that the context wasn't closed during setup")
Testcase: igt/gem_ctx_exec/basic-close-race
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v5.7+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201203103432.31526-1-chris@chris-wilson.co.uk
(cherry picked from commit ba38b79eae)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
There is a copy and paste bug in this code. It's supposed to check
"obj2" instead of checking "obj" a second time.
Fixes: 80f0b679d6 ("drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/8ilneOcJAjwqU4t@mwand
(cherry picked from commit 14f2d7604f)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
