Driver has a trivial helper function to convert
the pointer argument and then call the native ioctl handler.
But now we have a generic implementation for that, so we can use it.
Signed-off-by: Harshal Chaudhari <harshalchau04@gmail.com>
Link: https://lore.kernel.org/r/20201026155801.16053-1-harshalchau04@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Coccinelle suggested using PTR_ERR_OR_ZERO() and looking at the code,
we can use PTR_ERR_OR_ZERO() instead of checking IS_ERR() and then
doing 'return 0'.
Tested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Link: https://lore.kernel.org/r/20201026180026.3350-1-sudipm.mukherjee@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When built as a loadable module, coresight now causes a warning about
missing license information.
WARNING: modpost: missing MODULE_LICENSE() in drivers/hwtracing/coresight/coresight.o
Fixes: 8e264c52e1 ("coresight: core: Allow the coresight core driver to be built as a module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201026160205.3704789-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Creating debugfs files while loding the spin_lock_irqsave(xhci->lock)
creates a lock dependecy that could possibly deadlock.
Lockdep warns:
=====================================================
WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
5.10.0-rc1pdx86+ #8 Not tainted
-----------------------------------------------------
systemd-udevd/386 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
ffffffffb1a94038 (pin_fs_lock){+.+.}-{2:2}, at: simple_pin_fs+0x22/0xa0
and this task is already holding:
ffff9e7b87fbc430 (&xhci->lock){-.-.}-{2:2}, at: xhci_alloc_streams+0x5f9/0x810
which would create a new lock dependency:
(&xhci->lock){-.-.}-{2:2} -> (pin_fs_lock){+.+.}-{2:2}
Create the files a bit later after lock is released.
Fixes: 673d746836 ("usb: xhci: add debugfs support for ep with stream")
CC: Li Jun <jun.li@nxp.com>
Reported-by: Hans de Goede <hdegoede@redhat.com>
Reported-by: Mike Galbraith <efault@gmx.de>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201028203124.375344-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On some platform of AMD, S3 fails with HCE and SRE errors. To fix this,
need to disable a bit which is enable in sparse controller.
Cc: stable@vger.kernel.org #v4.19+
Signed-off-by: Sanket Goswami <Sanket.Goswami@amd.com>
Signed-off-by: Sandeep Singh <sandeep.singh@amd.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201028203124.375344-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
An incorrect sizeof() is being used, sizeof(rhub->ports) is not
correct, it should be sizeof(*rhub->ports). This bug did not
cause any issues because it just so happens the sizes are the same.
Fixes: bcaa9d5c59 ("xhci: Create new structures to store xhci port information")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201028203124.375344-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
chip->port_type and chip->pwr_opmode are enums and when GCC considers them
as unsigned, the conditions are never met.
This patch takes advantage of the ret variable and fixes the following
warnings:
drivers/usb/typec/stusb160x.c:548 stusb160x_get_fw_caps() warn: unsigned 'chip->port_type' is never less than zero.
drivers/usb/typec/stusb160x.c:570 stusb160x_get_fw_caps() warn: unsigned 'chip->pwr_opmode' is never less than zero.
Fixes: da0cb63100 ("usb: typec: add support for STUSB160x Type-C controller family")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Link: https://lore.kernel.org/r/20201028163309.12878-1-amelie.delaunay@st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When stusb160x driver is built as a module, no modalias information is
available, and it prevents the module to be loaded by udev.
Add MODULE_DEVICE_TABLE() to fix this issue.
Fixes: da0cb63100 ("usb: typec: add support for STUSB160x Type-C controller family")
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Link: https://lore.kernel.org/r/20201028151703.31195-1-amelie.delaunay@st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is deprecated, so it should not
be enabled by default.
In light of commit 4da0b2b7e6 ("efi/libstub: Re-enable command
line initrd loading for x86"), keep the default for X86.
Fixes: cf6b836648 ("efi/libstub: Make initrd file loader configurable")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201028153402.1736103-1-geert+renesas@glider.be
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Nesting container_of() causes warnings with W=2, which is
annoying if it happens in headers and fills the build log
like:
In file included from drivers/clk/qcom/clk-alpha-pll.c:6:
drivers/clk/qcom/clk-alpha-pll.c: In function 'clk_alpha_pll_hwfsm_enable':
include/linux/kernel.h:852:8: warning: declaration of '__mptr' shadows a previous local [-Wshadow]
852 | void *__mptr = (void *)(ptr); \
| ^~~~~~
drivers/clk/qcom/clk-alpha-pll.c:155:31: note: in expansion of macro 'container_of'
155 | #define to_clk_alpha_pll(_hw) container_of(to_clk_regmap(_hw), \
| ^~~~~~~~~~~~
drivers/clk/qcom/clk-regmap.h:27:28: note: in expansion of macro 'container_of'
27 | #define to_clk_regmap(_hw) container_of(_hw, struct clk_regmap, hw)
| ^~~~~~~~~~~~
drivers/clk/qcom/clk-alpha-pll.c:155:44: note: in expansion of macro 'to_clk_regmap'
155 | #define to_clk_alpha_pll(_hw) container_of(to_clk_regmap(_hw), \
| ^~~~~~~~~~~~~
drivers/clk/qcom/clk-alpha-pll.c:254:30: note: in expansion of macro 'to_clk_alpha_pll'
254 | struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
| ^~~~~~~~~~~~~~~~
include/linux/kernel.h:852:8: note: shadowed declaration is here
852 | void *__mptr = (void *)(ptr); \
| ^~~~~~
Redefine two copies of the to_clk_regmap() macro as inline functions
to avoid a lot of these.
Fixes: ea11dda9e0 ("clk: meson: add regmap clocks")
Fixes: 085d7a4554 ("clk: qcom: Add a regmap type clock struct")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20201026161411.3708639-1-arnd@kernel.org
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The Exynos clkout driver depends on board input clock (typically XXTI or
XUSBXTI), however on Exynos4 boards these clocks were modeled as part of
SoC clocks (Exynos4 clocks driver). Obviously this is not proper, but
correcting it would break DT backward compatibility.
Both drivers - clkout and Exynos4 clocks - register the clock providers
with CLK_OF_DECLARE/OF_DECLARE_1 so their order is fragile (in the
Makefile clkout is behind Exynos4 clock). It will work only if the
Exynos4 clock driver comes up before clkout.
A change in DTS adding input clock reference to Exynos4 clocks input
PLL, see reverted commit eaf2d2f689 ("ARM: dts: exynos: add input
clock to CMU in Exynos4412 Odroid"), caused probe reorder: the clkout
appeared before Exynos4 clock provider. Since clkout depends on Exynos4
clocks and does not support deferred probe, this did not work and caused
later failure of usb3503 USB hub probe which needs clkout:
[ 5.007442] usb3503 0-0008: unable to request refclk (-517)
The Exynos clkout driver is not a critical/core clock so there is
actually no problem in instantiating it later, as a regular module.
This removes specific probe ordering and adds support for probe
deferral.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Link: https://lore.kernel.org/r/20201001165646.32279-3-krzk@kernel.org
The Exynos clock output (clkout) driver uses same register address space
(Power Management Unit address space) as Exynos PMU driver and same set
of compatibles. It was modeled as clock provider instantiated with
CLK_OF_DECLARE_DRIVER().
This however brings ordering problems and lack of probe deferral,
therefore clkout driver should be converted to a regular module and
instantiated as a child of PMU driver to be able to use existing
compatibles and address space.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20201001165646.32279-2-krzk@kernel.org
Kyungmin Park maintained and contributed to some of the upstreamed
S5Pv210 and Exynos4210 machines - as described in commit 10ffa96407
("MAINTAINERS: add maintainer of Samsung Mobile Machine support").
However the entry in maintainers got slightly twisted by
commit 004bbd3c01 ("MAINTAINERS: remove non existent files") -
the directory matching pattern was changed from specific machines to
the entire S5Pv210.
Anyway since long time, all S5Pv210 maintenance is covered by the
Samsung ARM architectures maintainer entry and Krzysztof Kozlowski, so
move Kyungmin Park to the CREDITS.
There was also no activity on LKML regarding other maintained drivers:
https://lore.kernel.org/lkml/?q=f%3A%22Kyungmin+Park%22
Dear Kyungmin Park, thank you for all the effort you put in to the
upstream Samsung support.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>
Link: https://lore.kernel.org/r/20201016151528.7553-1-krzk@kernel.org
Commit e679654a70 ("bpf: Fix a rcu_sched stall issue with
bpf task/task_file iterator") tries to fix rcu stalls warning
which is caused by bpf task_file iterator when running
"bpftool prog".
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: \x097-....: (20999 ticks this GP) idle=302/1/0x4000000000000000 softirq=1508852/1508852 fqs=4913
\x09(t=21031 jiffies g=2534773 q=179750)
NMI backtrace for cpu 7
CPU: 7 PID: 184195 Comm: bpftool Kdump: loaded Tainted: G W 5.8.0-00004-g68bfc7f8c1b4 #6
Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A17 05/03/2019
Call Trace:
<IRQ>
dump_stack+0x57/0x70
nmi_cpu_backtrace.cold+0x14/0x53
? lapic_can_unplug_cpu.cold+0x39/0x39
nmi_trigger_cpumask_backtrace+0xb7/0xc7
rcu_dump_cpu_stacks+0xa2/0xd0
rcu_sched_clock_irq.cold+0x1ff/0x3d9
? tick_nohz_handler+0x100/0x100
update_process_times+0x5b/0x90
tick_sched_timer+0x5e/0xf0
__hrtimer_run_queues+0x12a/0x2a0
hrtimer_interrupt+0x10e/0x280
__sysvec_apic_timer_interrupt+0x51/0xe0
asm_call_on_stack+0xf/0x20
</IRQ>
sysvec_apic_timer_interrupt+0x6f/0x80
...
task_file_seq_next+0x52/0xa0
bpf_seq_read+0xb9/0x320
vfs_read+0x9d/0x180
ksys_read+0x5f/0xe0
do_syscall_64+0x38/0x60
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The fix is to limit the number of bpf program runs to be
one million. This fixed the program in most cases. But
we also found under heavy load, which can increase the wallclock
time for bpf_seq_read(), the warning may still be possible.
For example, calling bpf_delay() in the "while" loop of
bpf_seq_read(), which will introduce artificial delay,
the warning will show up in my qemu run.
static unsigned q;
volatile unsigned *p = &q;
volatile unsigned long long ll;
static void bpf_delay(void)
{
int i, j;
for (i = 0; i < 10000; i++)
for (j = 0; j < 10000; j++)
ll += *p;
}
There are two ways to fix this issue. One is to reduce the above
one million threshold to say 100,000 and hopefully rcu warning will
not show up any more. Another is to introduce a target feature
which enables bpf_seq_read() calling cond_resched().
This patch took second approach as the first approach may cause
more -EAGAIN failures for read() syscalls. Note that not all bpf_iter
targets can permit cond_resched() in bpf_seq_read() as some, e.g.,
netlink seq iterator, rcu read lock critical section spans through
seq_ops->next() -> seq_ops->show() -> seq_ops->next().
For the kernel code with the above hack, "bpftool p" roughly takes
38 seconds to finish on my VM with 184 bpf program runs.
Using the following command, I am able to collect the number of
context switches:
perf stat -e context-switches -- ./bpftool p >& log
Without this patch,
69 context-switches
With this patch,
75 context-switches
This patch added additional 6 context switches, roughly every 6 seconds
to reschedule, to avoid lengthy no-rescheduling which may cause the
above RCU warnings.
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20201028061054.1411116-1-yhs@fb.com
Kamil Debski has not been active on LKML since 2017:
https://lore.kernel.org/lkml/?q=f%3A%22Kamil+Debski%22
Move Kamil Debski to the CREDITS file. Thank you for the effort you put
in to the upstream Linux kernel work.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Acked-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Kamil Debski <kamil@wypas.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Link: https://lore.kernel.org/r/20201016151528.7553-1-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-12-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-11-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-10-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-9-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-8-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-7-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-5-krzk@kernel.org
Using full paths to extend or override a device tree node is error
prone. If there was a typo error, a new node will be created instead of
extending the existing node. This will lead to run-time errors that
could be hard to detect.
A mistyped label on the other hand, will cause a dtc compile error
(during build time).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-4-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-3-krzk@kernel.org
The Devicetree specification expects device node names to have a generic
name, representing the class of a device. Also the convention for node
names is to use hyphens, not underscores.
No functional changes.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201027170947.132725-2-krzk@kernel.org
The check for an error return from the call to snd_pcm_format_width
is never true as the unsigned int bitwidth can never be less than
zero. Fix this by making bitwidth an int.
Fixes: 7cb37b7bd0 ("ASoC: qcom: Add support for lpass hdmi driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20201028115112.109017-1-colin.king@canonical.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Coredump logics needs to report not only the registers of the dumping
thread, but (since 2.5.43) those of other threads getting killed.
Doing that might require extra state saved on the stack in asm glue at
kernel entry; signal delivery logics does that (we need to be able to
save sigcontext there, at the very least) and so does seccomp.
That covers all callers of do_coredump(). Secondary threads get hit with
SIGKILL and caught as soon as they reach exit_mm(), which normally happens
in signal delivery, so those are also fine most of the time. Unfortunately,
it is possible to end up with secondary zapped when it has already entered
exit(2) (or, worse yet, is oopsing). In those cases we reach exit_mm()
when mm->core_state is already set, but the stack contents is not what
we would have in signal delivery.
At least on two architectures (alpha and m68k) it leads to infoleaks - we
end up with a chunk of kernel stack written into coredump, with the contents
consisting of normal C stack frames of the call chain leading to exit_mm()
instead of the expected copy of userland registers. In case of alpha we
leak 312 bytes of stack. Other architectures (including the regset-using
ones) might have similar problems - the normal user of regsets is ptrace
and the state of tracee at the time of such calls is special in the same
way signal delivery is.
Note that had the zapper gotten to the exiting thread slightly later,
it wouldn't have been included into coredump anyway - we skip the threads
that have already cleared their ->mm. So let's pretend that zapper always
loses the race. IOW, have exit_mm() only insert into the dumper list if
we'd gotten there from handling a fatal signal[*]
As the result, the callers of do_exit() that have *not* gone through get_signal()
are not seen by coredump logics as secondary threads. Which excludes voluntary
exit()/oopsen/traps/etc. The dumper thread itself is unaffected by that,
so seccomp is fine.
[*] originally I intended to add a new flag in tsk->flags, but ebiederman pointed
out that PF_SIGNALED is already doing just what we need.
Cc: stable@vger.kernel.org
Fixes: d89f3847def4 ("[PATCH] thread-aware coredumps, 2.5.43-C3")
History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The media tree Kconfig has changed recently, and a lot of modules were
built unintentionally, like the dvb frontends and encoders.
Resync the defconfig to build the sama5 drivers and tested sensors.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201016075109.287506-1-eugen.hristev@microchip.com
exynos_core_restart() is called by secondary CPU boot procedure, used by
CPU hotplug and coupled CPU idle. Replace of_machine_is_compatible() call
with a simple SoC revision check.
of_machine_is_compatible() function performs a dozen of string comparisons
during the full device tree walk, while soc_is_exynos3250() is a simple
integer check on SoC revision variable. This change also fixes the
following warning:
=============================
WARNING: suspicious RCU usage
5.10.0-rc1-00001-g6f65599d1f4f-dirty #1800 Not tainted
-----------------------------
./include/trace/events/lock.h:37 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-rc1-00001-g6f65599d1f4f-dirty #1800
Hardware name: Samsung Exynos (Flattened Device Tree)
[<c0111514>] (unwind_backtrace) from [<c010ceb8>] (show_stack+0x10/0x14)
[<c010ceb8>] (show_stack) from [<c0b1d8dc>] (dump_stack+0xb4/0xd4)
[<c0b1d8dc>] (dump_stack) from [<c0194acc>] (lock_acquire+0x418/0x584)
[<c0194acc>] (lock_acquire) from [<c0b29e58>] (_raw_spin_lock_irqsave+0x4c/0x60)
[<c0b29e58>] (_raw_spin_lock_irqsave) from [<c0897af4>] (of_device_is_compatible+0x1c/0x4c)
[<c0897af4>] (of_device_is_compatible) from [<c01216d8>] (exynos_core_restart+0x14/0xb0)
[<c01216d8>] (exynos_core_restart) from [<c0120a78>] (exynos_cpu0_enter_aftr+0x1d0/0x1dc)
[<c0120a78>] (exynos_cpu0_enter_aftr) from [<c08575b0>] (exynos_enter_coupled_lowpower+0x44/0x74)
[<c08575b0>] (exynos_enter_coupled_lowpower) from [<c085477c>] (cpuidle_enter_state+0x178/0x660)
[<c085477c>] (cpuidle_enter_state) from [<c08572dc>] (cpuidle_enter_state_coupled+0x35c/0x378)
[<c08572dc>] (cpuidle_enter_state_coupled) from [<c0854cc8>] (cpuidle_enter+0x50/0x54)
[<c0854cc8>] (cpuidle_enter) from [<c0164854>] (do_idle+0x224/0x2a4)
[<c0164854>] (do_idle) from [<c0164c88>] (cpu_startup_entry+0x18/0x1c)
[<c0164c88>] (cpu_startup_entry) from [<c1100fa0>] (start_kernel+0x640/0x67c)
[<c1100fa0>] (start_kernel) from [<00000000>] (0x0)
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20201027201716.15745-1-m.szyprowski@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
If the 15-bit APIC ID support is present in emulated MSI then there's no
need for the pseudo-remapping support.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201024213535.443185-34-dwmw2@infradead.org
Some hypervisors can allow the guest to use the Extended Destination ID
field in the MSI address to address up to 32768 CPUs.
This applies to all downstream devices which generate MSI cycles,
including HPET, I/O-APIC and PCI MSI.
HPET and PCI MSI use the same __irq_msi_compose_msg() function, while
I/O-APIC generates its own and had support for the extended bits added in
a previous commit.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201024213535.443185-33-dwmw2@infradead.org
Bits 63-48 of the I/OAPIC Redirection Table Entry map directly to bits 19-4
of the address used in the resulting MSI cycle.
Historically, the x86 MSI format only used the top 8 of those 16 bits as
the destination APIC ID, and the "Extended Destination ID" in the lower 8
bits was unused.
With interrupt remapping, the lowest bit of the Extended Destination ID
(bit 48 of RTE, bit 4 of MSI address) is now used to indicate a remappable
format MSI.
A hypervisor can use the other 7 bits of the Extended Destination ID to
permit guests to address up to 15 bits of APIC IDs, thus allowing 32768
vCPUs before having to expose a vIOMMU and interrupt remapping to the
guest.
No behavioural change in this patch, since nothing yet permits APIC IDs
above 255 to be used with the non-IR I/OAPIC domain.
[ tglx: Converted it to the cleaned up entry/msi_msg format and added
commentry ]
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201024213535.443185-32-dwmw2@infradead.org
Now that the old get_irq_domain() method has gone, consolidate on just the
map_XXX_to_iommu() functions.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20201024213535.443185-31-dwmw2@infradead.org
