* [PATCH 3/3] acpi: sleep: Don't offer s2idle on AMD platforms without LPS0
From: Mario Limonciello @ 2022-01-05 19:39 UTC (permalink / raw)
To: Rafael J . Wysocki, linux-acpi
Cc: Shyam-sundar.S-k, Basavaraj Natikar, Mario Limonciello,
Bjoren Dasse
In-Reply-To: <20220105193910.25678-1-mario.limonciello@amd.com>
On some OEM platforms a BIOS option is offered that will set the
sleep mode between S3 and S2idle. This option will change certain HW
behaviors. When in S2idle mode, Linux works properly. However when S3 mode
is picked but the user chooses S2idle in Linux the platform may not be
properly resumed.
To avoid users getting into this situation, don't offer s2idle on AMD
systems missing the LPS0 device either by a BIOS option or by using the
acpi "no_sleep_lps0" module parameter.
Reported-by: Bjoren Dasse <bjoern.daase@gmail.com>
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1824
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215387
Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/acpi/x86/s2idle.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index a1626737e5e0..c3d35a42ac2f 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -363,6 +363,13 @@ static int validate_dsm(acpi_handle handle, const char *uuid, int rev, guid_t *d
static bool acpi_s2idle_valid(void)
{
+ /* AMD systems must have low level firmware support */
+ if (acpi_s2idle_vendor_amd())
+#if IS_ENABLED(CONFIG_AMD_PMC)
+ return lps0_device_handle && !sleep_no_lps0;
+#else
+ return false;
+#endif
return true;
}
@@ -450,6 +457,9 @@ static int lps0_device_attach(struct acpi_device *adev,
if (!acpi_s2idle_vendor_amd())
acpi_ec_mark_gpe_for_wake();
+ /* reset these so we update valid */
+ s2idle_set_ops(&acpi_s2idle_ops_lps0);
+
return 0;
}
--
2.25.1
^ permalink raw reply related
* [PATCH 2/3] PM: sleep: Don't always assume s2idle will be enabled
From: Mario Limonciello @ 2022-01-05 19:39 UTC (permalink / raw)
To: Rafael J . Wysocki, linux-acpi
Cc: Shyam-sundar.S-k, Basavaraj Natikar, Mario Limonciello
In-Reply-To: <20220105193910.25678-1-mario.limonciello@amd.com>
Some platforms may require firmware support for s2idle to work
properly, so allow other drivers that set s2idle ops to decide whether
to offer it on a given platform.
This should be no functional change for any platform.
Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/acpi/sleep.c | 6 ++++++
drivers/acpi/x86/s2idle.c | 6 ++++++
include/linux/suspend.h | 1 +
kernel/power/suspend.c | 27 ++++++++++++++-------------
4 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index eaa47753b758..9dafdaafa5dc 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -800,12 +800,18 @@ void acpi_s2idle_end(void)
acpi_scan_lock_release();
}
+static bool acpi_s2idle_valid(void)
+{
+ return true;
+}
+
static const struct platform_s2idle_ops acpi_s2idle_ops = {
.begin = acpi_s2idle_begin,
.prepare = acpi_s2idle_prepare,
.wake = acpi_s2idle_wake,
.restore = acpi_s2idle_restore,
.end = acpi_s2idle_end,
+ .valid = acpi_s2idle_valid,
};
void __weak acpi_s2idle_setup(void)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 32ab4ba5adb9..a1626737e5e0 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -361,6 +361,11 @@ static int validate_dsm(acpi_handle handle, const char *uuid, int rev, guid_t *d
return ret;
}
+static bool acpi_s2idle_valid(void)
+{
+ return true;
+}
+
static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
.begin = acpi_s2idle_begin,
.prepare = acpi_s2idle_prepare,
@@ -369,6 +374,7 @@ static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
.restore_early = acpi_s2idle_restore_early,
.restore = acpi_s2idle_restore,
.end = acpi_s2idle_end,
+ .valid = acpi_s2idle_valid,
};
static int lps0_device_attach(struct acpi_device *adev,
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 8af13ba60c7e..51e5bdd9be23 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -195,6 +195,7 @@ struct platform_s2idle_ops {
void (*restore_early)(void);
void (*restore)(void);
void (*end)(void);
+ bool (*valid)(void);
};
#ifdef CONFIG_SUSPEND
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 597c5e65aa45..29d6f1738359 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -46,7 +46,7 @@ static const char * const mem_sleep_labels[] = {
};
const char *mem_sleep_states[PM_SUSPEND_MAX];
-suspend_state_t mem_sleep_current = PM_SUSPEND_TO_IDLE;
+suspend_state_t mem_sleep_current = PM_SUSPEND_MAX;
suspend_state_t mem_sleep_default = PM_SUSPEND_MAX;
suspend_state_t pm_suspend_target_state;
EXPORT_SYMBOL_GPL(pm_suspend_target_state);
@@ -152,6 +152,10 @@ EXPORT_SYMBOL_GPL(s2idle_wake);
static bool valid_state(suspend_state_t state)
{
+ /* PM_SUSPEND_TO_IDLE may require low-level support on some platforms */
+ if (state == PM_SUSPEND_TO_IDLE)
+ return s2idle_ops && s2idle_ops->valid && s2idle_ops->valid();
+
/*
* The PM_SUSPEND_STANDBY and PM_SUSPEND_MEM states require low-level
* support and need to be valid to the low-level implementation.
@@ -166,6 +170,13 @@ void s2idle_set_ops(const struct platform_s2idle_ops *ops)
{
lock_system_sleep();
s2idle_ops = ops;
+ if (valid_state(PM_SUSPEND_TO_IDLE)) {
+ mem_sleep_states[PM_SUSPEND_TO_IDLE] = mem_sleep_labels[PM_SUSPEND_TO_IDLE];
+ /* if supported, update to suspend to idle for default when ops set */
+ if (mem_sleep_current == PM_SUSPEND_MAX ||
+ mem_sleep_default == PM_SUSPEND_TO_IDLE)
+ mem_sleep_current = PM_SUSPEND_TO_IDLE;
+ }
unlock_system_sleep();
}
@@ -174,11 +185,6 @@ void __init pm_states_init(void)
/* "mem" and "freeze" are always present in /sys/power/state. */
pm_states[PM_SUSPEND_MEM] = pm_labels[PM_SUSPEND_MEM];
pm_states[PM_SUSPEND_TO_IDLE] = pm_labels[PM_SUSPEND_TO_IDLE];
- /*
- * Suspend-to-idle should be supported even without any suspend_ops,
- * initialize mem_sleep_states[] accordingly here.
- */
- mem_sleep_states[PM_SUSPEND_TO_IDLE] = mem_sleep_labels[PM_SUSPEND_TO_IDLE];
}
static int __init mem_sleep_default_setup(char *str)
@@ -236,11 +242,6 @@ int suspend_valid_only_mem(suspend_state_t state)
}
EXPORT_SYMBOL_GPL(suspend_valid_only_mem);
-static bool sleep_state_supported(suspend_state_t state)
-{
- return state == PM_SUSPEND_TO_IDLE || valid_state(state);
-}
-
static int platform_suspend_prepare(suspend_state_t state)
{
return state != PM_SUSPEND_TO_IDLE && suspend_ops->prepare ?
@@ -346,7 +347,7 @@ static int suspend_prepare(suspend_state_t state)
{
int error;
- if (!sleep_state_supported(state))
+ if (!valid_state(state))
return -EPERM;
pm_prepare_console();
@@ -478,7 +479,7 @@ int suspend_devices_and_enter(suspend_state_t state)
int error;
bool wakeup = false;
- if (!sleep_state_supported(state))
+ if (!valid_state(state))
return -ENOSYS;
pm_suspend_target_state = state;
--
2.25.1
^ permalink raw reply related
* [PATCH 1/3] PM: suspend: Move some structure declarations around
From: Mario Limonciello @ 2022-01-05 19:39 UTC (permalink / raw)
To: Rafael J . Wysocki, linux-acpi
Cc: Shyam-sundar.S-k, Basavaraj Natikar, Mario Limonciello
In-Reply-To: <20220105193910.25678-1-mario.limonciello@amd.com>
Future patches will modify members of these structures dependent
upon these locations. Move the structure declarations first to
make those patches easier to consume.
Reviewed-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/acpi/x86/s2idle.c | 20 ++++++++++----------
kernel/power/suspend.c | 14 +++++++-------
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 1c48358b43ba..32ab4ba5adb9 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -361,6 +361,16 @@ static int validate_dsm(acpi_handle handle, const char *uuid, int rev, guid_t *d
return ret;
}
+static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
+ .begin = acpi_s2idle_begin,
+ .prepare = acpi_s2idle_prepare,
+ .prepare_late = acpi_s2idle_prepare_late,
+ .wake = acpi_s2idle_wake,
+ .restore_early = acpi_s2idle_restore_early,
+ .restore = acpi_s2idle_restore,
+ .end = acpi_s2idle_end,
+};
+
static int lps0_device_attach(struct acpi_device *adev,
const struct acpi_device_id *not_used)
{
@@ -508,16 +518,6 @@ void acpi_s2idle_restore_early(void)
lps0_dsm_func_mask, lps0_dsm_guid);
}
-static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
- .begin = acpi_s2idle_begin,
- .prepare = acpi_s2idle_prepare,
- .prepare_late = acpi_s2idle_prepare_late,
- .wake = acpi_s2idle_wake,
- .restore_early = acpi_s2idle_restore_early,
- .restore = acpi_s2idle_restore,
- .end = acpi_s2idle_end,
-};
-
void acpi_s2idle_setup(void)
{
acpi_scan_add_handler(&lps0_handler);
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 80cc1f0f502b..597c5e65aa45 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -73,13 +73,6 @@ bool pm_suspend_default_s2idle(void)
}
EXPORT_SYMBOL_GPL(pm_suspend_default_s2idle);
-void s2idle_set_ops(const struct platform_s2idle_ops *ops)
-{
- lock_system_sleep();
- s2idle_ops = ops;
- unlock_system_sleep();
-}
-
static void s2idle_begin(void)
{
s2idle_state = S2IDLE_STATE_NONE;
@@ -169,6 +162,13 @@ static bool valid_state(suspend_state_t state)
suspend_ops->enter;
}
+void s2idle_set_ops(const struct platform_s2idle_ops *ops)
+{
+ lock_system_sleep();
+ s2idle_ops = ops;
+ unlock_system_sleep();
+}
+
void __init pm_states_init(void)
{
/* "mem" and "freeze" are always present in /sys/power/state. */
--
2.25.1
^ permalink raw reply related
* [PATCH 0/3] On AMD platforms only offer s2idle w/ proper FW
From: Mario Limonciello @ 2022-01-05 19:39 UTC (permalink / raw)
To: Rafael J . Wysocki, linux-acpi
Cc: Shyam-sundar.S-k, Basavaraj Natikar, Mario Limonciello
Currently the Linux kernel will offer s2idle regardless of whether the FADT
indicates the system should use or on X86 if the LPS0 ACPI device has been
activated.
On some non-AMD platforms s2idle can be offered even without proper
firmware support. The power consumption may be higher in these instances
but the system otherwise properly suspends and resumes.
On AMD platforms however when the FW has been configured not to offer
s2idle some different hardware initialization has occurred such that the
system won't properly resume.
This patch series changes the kernel suspend code to conditionally decide
whether to offer s2idle. When an AMD system is encountered all the
prerequisites will be checked before s2idle is offered to the user.
Mario Limonciello (3):
PM: suspend: Move some structure declarations around
PM: sleep: Don't always assume s2idle will be enabled
acpi: sleep: Don't offer s2idle on AMD platforms without LPS0
drivers/acpi/sleep.c | 6 ++++++
drivers/acpi/x86/s2idle.c | 36 ++++++++++++++++++++++++----------
include/linux/suspend.h | 1 +
kernel/power/suspend.c | 41 ++++++++++++++++++++-------------------
4 files changed, 54 insertions(+), 30 deletions(-)
--
2.25.1
^ permalink raw reply
* Re: [RFC] coredump: Do not interrupt dump for TIF_NOTIFY_SIGNAL
From: Olivier Langlois @ 2022-01-05 19:39 UTC (permalink / raw)
To: Pavel Begunkov, Eric W. Biederman, linux-kernel
Cc: linux-fsdevel, io-uring, Alexander Viro, Jens Axboe,
Oleg Nesterov, Linus Torvalds
In-Reply-To: <13250a8d-1a59-4b7b-92e4-1231d73cbdda@gmail.com>
On Fri, 2021-12-24 at 10:37 +0000, Pavel Begunkov wrote:
> On 12/24/21 01:34, Olivier Langlois wrote:
> > On Fri, 2021-10-22 at 15:13 +0100, Pavel Begunkov wrote:
> > > On 6/9/21 21:17, Eric W. Biederman wrote:
> > > In short, a task creates an io_uring worker thread, then the
> > > worker
> > > submits a task_work item to the creator task and won't die until
> > > the item is executed/cancelled. And I found that the creator task
> > > is
> > > sleeping in do_coredump() -> wait_for_completion()
> > >
> [...]
> > > A hack executing tws there helps (see diff below).
> > > Any chance anyone knows what this is and how to fix it?
> > >
> [...]
> > Pavel,
> >
> > I cannot comment on the merit of the proposed hack but my proposed
> > patch to fix the coredump truncation issue when a process using
> > io_uring core dumps that I submitted back in August is still
> > unreviewed!
>
> That's unfortunate. Not like I can help in any case, but I assumed
> it was dealt with by
>
> commit 06af8679449d4ed282df13191fc52d5ba28ec536
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date: Thu Jun 10 15:11:11 2021 -0500
>
> coredump: Limit what can interrupt coredumps
>
> Olivier Langlois has been struggling with coredumps being
> incompletely written in
> processes using io_uring.
> ...
>
It was a partial fix only. Oleg Nesterov pointed out that the fix was
not good if if the core dump was written into a pipe.
https://lore.kernel.org/io-uring/20210614141032.GA13677@redhat.com/
> > https://lore.kernel.org/lkml/1625bc89782bf83d9d8c7c63e8ffcb651ccb15
> > fa.1629655338.git.olivier@trillion01.com/
> >
> > I have been using it since then I must have generated many dozens
> > of
> > perfect core dump files with it and I have not seen a single
> > truncated
> > core dump files like I used to have prior to the patch.
> >
> > I am bringing back my patch to your attention because one nice side
> > effect of it is that it would have avoided totally the problem that
> > you
> > have encountered in coredump_wait() since it does cancel io_uring
> > resources before calling coredump_wait()!
>
> FWIW, I worked it around in io_uring back then by breaking the
> dependency.
>
Yes I have seen your work to fix the problem.
It just seems to me that there is no good reason to keep io_uring
process requests once you are generating a core dump and simply
cancelling io_uring before generating the core dump would have avoided
the problem that you have encountered plus any other similar issues yet
to come...
Greetings,
^ permalink raw reply
* Re: [PATCH v2 4/5] RISC-V: Typed CSRs in gdbserver
From: Alex Bennée @ 2022-01-05 19:34 UTC (permalink / raw)
To: Schwarz, Konrad
Cc: Palmer Dabbelt, Bin Meng, Alistair Francis, Ralf Ramsauer,
qemu-devel@nongnu.org
In-Reply-To: <58ecc207ca704277a5cf1b259b77f6b0@siemens.com>
"Schwarz, Konrad" <konrad.schwarz@siemens.com> writes:
>> -----Original Message-----
>> From: Alex Bennée <alex.bennee@linaro.org>
>
>> Konrad Schwarz <konrad.schwarz@siemens.com> writes:
>>
>
>> > static int riscv_gen_dynamic_csr_xml(CPUState *cs, int base_reg)
>> > {
>> > RISCVCPU *cpu = RISCV_CPU(cs);
>> > @@ -163,21 +167,33 @@ static int riscv_gen_dynamic_csr_xml(CPUState *cs, int base_reg)
>> > riscv_csr_predicate_fn predicate;
>> > int bitsize = 16 << env->misa_mxl_max;
>> > int i;
>> > + riscv_csr_operations *csr_op;
>> > + struct riscv_gdb_csr_tg const *csr_tg;
>> >
>> > g_string_printf(s, "<?xml version=\"1.0\"?>");
>> > g_string_append_printf(s, "<!DOCTYPE feature SYSTEM \"gdb-target.dtd\">");
>> > g_string_append_printf(s, "<feature> name=\"org.gnu.gdb.riscv.csr\">");
>>
>> With these changes does it still match the org.gnu.gdb.riscv.csr
>> register description in gdb? Previously for custom XML I've used the
>> org.qemu.ARCH.REGS form to distinguish between something GDB expects and
>> something we invented (changed since 797920b952ea).
>
> I don't expect it to match -- but why should it?
> The whole point of target descriptions is for GDBserver to inform
> GDB of the precise set and layout of pre-defined register classes.
> The class `org.gnu.gdb.riscv.csr' is known to a RISC-V capable
> GDB as the class of all CSRs; a specific RISC-V core might
> have vendor-specific CSRs, but they would still be included
> in `org.gnu.gdb.riscv.csr'.
Certainly for ARM's SVE there is special handling code in gdb to deal
with the control of the vector length. As long as GDB doesn't make any
such assumptions for RISC-V then go right ahead.
>
> Section G.5 in the GDB manual makes this clear:
> "You can add additional registers to any of the standard features --
> GDB will display them just as they were added to an
> unrecognized feature."
--
Alex Bennée
^ permalink raw reply
* Re: [PATCH 1/2] cgroup: rstat: explicitly put loop variant in while
From: Michal Koutný @ 2022-01-05 19:37 UTC (permalink / raw)
To: Wei Yang; +Cc: tj, lizefan.x, hannes, cgroups, linux-kernel
In-Reply-To: <20211225000932.7253-1-richard.weiyang@gmail.com>
On Sat, Dec 25, 2021 at 12:09:31AM +0000, Wei Yang <richard.weiyang@gmail.com> wrote:
> Instead of do while unconditionally, let's put the loop variant in
> while.
>
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> ---
> kernel/cgroup/rstat.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Makes sense,
Reviewed-by: Michal Koutný <mkoutny@suse.com>
^ permalink raw reply
* Re: [PATCH 1/2] cgroup: rstat: explicitly put loop variant in while
From: Michal Koutný @ 2022-01-05 19:37 UTC (permalink / raw)
To: Wei Yang
Cc: tj-DgEjT+Ai2ygdnm+yROfE0A, lizefan.x-EC8Uxl6Npydl57MIdRCFDg,
hannes-druUgvl0LCNAfugRpC6u6w, cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20211225000932.7253-1-richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Dec 25, 2021 at 12:09:31AM +0000, Wei Yang <richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Instead of do while unconditionally, let's put the loop variant in
> while.
>
> Signed-off-by: Wei Yang <richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> kernel/cgroup/rstat.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Makes sense,
Reviewed-by: Michal Koutný <mkoutny-IBi9RG/b67k@public.gmane.org>
^ permalink raw reply
* Re: [PATCH] Revert "clk: Detect failure to set defaults"
From: Tom Rini @ 2022-01-05 19:37 UTC (permalink / raw)
To: Marek Vasut
Cc: Sean Anderson, u-boot, Peng Fan, Simon Glass, Mark Kettenis,
lukma
In-Reply-To: <e979a578-a042-217e-1fb1-53d140f540af@denx.de>
[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]
On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
> On 1/1/22 22:41, Sean Anderson wrote:
> > Hi Marek,
>
> Hi,
>
> > Please CC clock maintainers for future patches.
>
> btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
> zero reviews/acks from clock maintainers.
>
> > On 1/1/22 1:51 PM, Marek Vasut wrote:
> > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
> > > The aforementioned patch causes massive breakage on all platforms which
> > > have 'assigned-clock' DT property in their DT which references any clock
> > > that are not supported by the platform clock driver. That can easily
> > > happen either in SPL, or because the clock driver is reduced. Currently
> > > it seems all iMX8M are affected and fail to boot altogether.
> > >
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Cc: Peng Fan <peng.fan@oss.nxp.com>
> > > Cc: Simon Glass <sjg@chromium.org>
> > > ---
> > > drivers/clk/clk-uclass.c | 6 +-----
> > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > index f2d26427543..094b1abf13c 100644
> > > --- a/drivers/clk/clk-uclass.c
> > > +++ b/drivers/clk/clk-uclass.c
> > > @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
> > > clk *clk)
> > > int clk_uclass_post_probe(struct udevice *dev)
> > > {
> > > - int ret;
> > > -
> > > /*
> > > * when a clock provider is probed. Call clk_set_defaults()
> > > * also after the device is probed. This takes care of cases
> > > * where the DT is used to setup default parents and rates
> > > * using assigned-clocks
> > > */
> > > - ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > - if (ret)
> > > - return log_ret(ret);
> > > + clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > return 0;
> > > }
> > >
> >
> > See [1] for previous discussion. For more background,
> >
> > - Device trees for i.MX are sync'd with Linux.
> > - General clock assignments may live in the clock-controller node,
>
> clock assignments can be anywhere, even in non-clock-controller nodes.
>
> > including those which U-Boot does not implement, but which Linux does.
> > It's OK to not set up these clocks, but U-Boot doesn't know that and
> > fails.
> >
> > We don't necessarily need to revert this commit, but we do need a way to
> > say "it's OK not to set the defaults, since we can function without
> > them". Tom suggested doing this in the clock driver last time. I think a
> > Kconfig or a device tree property would work, perhaps something like
> > 'u-boot,clock-defaults-optional'.
>
> We didn't need custom DT properties before, Linux doesn't need them either,
> so that approach seems wrong.
>
> If the clock driver could say "skip unimplemented clock, because I don't
> implement them and that is OK", that sounds like the right approach.
>
> Unless the 2022.01 release should be completely broken for a lot of
> platforms, I would propose we revert the clock uclass patch now and re-add
> it right after the release, so we would not roll out a completely broken
> release and would have more time to fix this properly.
It'll be no more broken than v2021.10 was for whatever platforms have
problems here, yes? Since that's what has the problematic commit.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply
* Re: remove Xen tmem leftovers
From: Konrad Rzeszutek Wilk @ 2022-01-05 19:36 UTC (permalink / raw)
To: David Hildenbrand
Cc: Juergen Gross, Christoph Hellwig, Andrew Morton, Hugh Dickins,
Seth Jennings, Dan Streetman, Vitaly Wool, Matthew Wilcox,
linux-kernel, linux-fsdevel, linux-mm
In-Reply-To: <93a8e489-5ca5-7593-5d2b-59280187e2a1@redhat.com>
On Wed, Jan 05, 2022 at 09:46:05AM +0100, David Hildenbrand wrote:
> On 05.01.22 07:08, Juergen Gross wrote:
> > On 04.01.22 15:31, David Hildenbrand wrote:
> >> On 24.12.21 07:22, Christoph Hellwig wrote:
> >>> Hi all,
> >>>
> >>> since the remove of the Xen tmem driver in 2019, the cleancache hooks are
> >>> entirely unused, as are large parts of frontswap. This series against
> >>> linux-next (with the folio changes included) removes cleancaches, and cuts
> >>> down frontswap to the bits actually used by zswap.
> >>>
> >>
> >> Just out of curiosity, why was tmem removed from Linux (or even Xen?).
> >> Do you have any information?
> >
> > tmem never made it past the "experimental" state in the Xen hypervisor.
> > Its implementation had some significant security flaws, there was no
> > maintainer left, and nobody stepped up to address those issues.
> >
> > As a result tmem was removed from Xen.
>
> Interesting, thanks for sharing. I know tmem mostly from the papers and
> thought it was an interesting approach in general. There was even papers
> about a virtio implementation, however, actual code never appeared in
> the wild :)
There is a repo of it .. I can find it if you are interested - but as
Juergen mentioned - I didn't have enough steam to finish up the security
rework so code removed.
^ permalink raw reply
* Re: [PATCH] Revert "clk: Detect failure to set defaults"
From: Marek Vasut @ 2022-01-05 19:35 UTC (permalink / raw)
To: Sean Anderson, u-boot
Cc: Peng Fan, Simon Glass, Tom Rini, Mark Kettenis, lukma
In-Reply-To: <d74407b2-8426-f0b4-86da-58ccd0a3bf1a@gmail.com>
On 1/1/22 22:41, Sean Anderson wrote:
> Hi Marek,
Hi,
> Please CC clock maintainers for future patches.
btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646
has zero reviews/acks from clock maintainers.
> On 1/1/22 1:51 PM, Marek Vasut wrote:
>> This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
>> The aforementioned patch causes massive breakage on all platforms which
>> have 'assigned-clock' DT property in their DT which references any clock
>> that are not supported by the platform clock driver. That can easily
>> happen either in SPL, or because the clock driver is reduced. Currently
>> it seems all iMX8M are affected and fail to boot altogether.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Peng Fan <peng.fan@oss.nxp.com>
>> Cc: Simon Glass <sjg@chromium.org>
>> ---
>> drivers/clk/clk-uclass.c | 6 +-----
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>> index f2d26427543..094b1abf13c 100644
>> --- a/drivers/clk/clk-uclass.c
>> +++ b/drivers/clk/clk-uclass.c
>> @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
>> clk *clk)
>> int clk_uclass_post_probe(struct udevice *dev)
>> {
>> - int ret;
>> -
>> /*
>> * when a clock provider is probed. Call clk_set_defaults()
>> * also after the device is probed. This takes care of cases
>> * where the DT is used to setup default parents and rates
>> * using assigned-clocks
>> */
>> - ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
>> - if (ret)
>> - return log_ret(ret);
>> + clk_set_defaults(dev, CLK_DEFAULTS_POST);
>> return 0;
>> }
>>
>
> See [1] for previous discussion. For more background,
>
> - Device trees for i.MX are sync'd with Linux.
> - General clock assignments may live in the clock-controller node,
clock assignments can be anywhere, even in non-clock-controller nodes.
> including those which U-Boot does not implement, but which Linux does.
> It's OK to not set up these clocks, but U-Boot doesn't know that and
> fails.
>
> We don't necessarily need to revert this commit, but we do need a way to
> say "it's OK not to set the defaults, since we can function without
> them". Tom suggested doing this in the clock driver last time. I think a
> Kconfig or a device tree property would work, perhaps something like
> 'u-boot,clock-defaults-optional'.
We didn't need custom DT properties before, Linux doesn't need them
either, so that approach seems wrong.
If the clock driver could say "skip unimplemented clock, because I don't
implement them and that is OK", that sounds like the right approach.
Unless the 2022.01 release should be completely broken for a lot of
platforms, I would propose we revert the clock uclass patch now and
re-add it right after the release, so we would not roll out a completely
broken release and would have more time to fix this properly.
^ permalink raw reply
* Re: [PATCH 2/2] cgroup/rstat: check updated_next only for root
From: Michal Koutný @ 2022-01-05 19:35 UTC (permalink / raw)
To: Wei Yang; +Cc: tj, lizefan.x, hannes, cgroups, linux-kernel
In-Reply-To: <20211225000932.7253-2-richard.weiyang@gmail.com>
On Sat, Dec 25, 2021 at 12:09:32AM +0000, Wei Yang <richard.weiyang@gmail.com> wrote:
> This means we can remove the check on ->updated_next, if we make sure
> the subtree from @root is on list, which could be done by checking
> updated_next for root.
Nice refactoring.
> @@ -96,9 +97,12 @@ static struct cgroup *cgroup_rstat_cpu_pop_updated(struct cgroup *pos,
> * We're gonna walk down to the first leaf and visit/remove it. We
> * can pick whatever unvisited node as the starting point.
> */
> - if (!pos)
> + if (!pos) {
> pos = root;
> - else
> + // return NULL if this subtree is not on-list
> + if (!cgroup_rstat_cpu(pos, cpu)->updated_next)
> + return NULL;
> + } else
+ /* return NULL if this subtree is not on-list */
Just a coding style nitpick.
The patch is otherwise
Reviewed-by: Michal Koutný <mkoutny@suse.com>
^ permalink raw reply
* Re: [PATCH 2/2] cgroup/rstat: check updated_next only for root
From: Michal Koutný @ 2022-01-05 19:35 UTC (permalink / raw)
To: Wei Yang
Cc: tj-DgEjT+Ai2ygdnm+yROfE0A, lizefan.x-EC8Uxl6Npydl57MIdRCFDg,
hannes-druUgvl0LCNAfugRpC6u6w, cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20211225000932.7253-2-richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Dec 25, 2021 at 12:09:32AM +0000, Wei Yang <richard.weiyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> This means we can remove the check on ->updated_next, if we make sure
> the subtree from @root is on list, which could be done by checking
> updated_next for root.
Nice refactoring.
> @@ -96,9 +97,12 @@ static struct cgroup *cgroup_rstat_cpu_pop_updated(struct cgroup *pos,
> * We're gonna walk down to the first leaf and visit/remove it. We
> * can pick whatever unvisited node as the starting point.
> */
> - if (!pos)
> + if (!pos) {
> pos = root;
> - else
> + // return NULL if this subtree is not on-list
> + if (!cgroup_rstat_cpu(pos, cpu)->updated_next)
> + return NULL;
> + } else
+ /* return NULL if this subtree is not on-list */
Just a coding style nitpick.
The patch is otherwise
Reviewed-by: Michal Koutný <mkoutny-IBi9RG/b67k@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v8 01/40] x86/compressed/64: detect/setup SEV/SME features earlier in boot
From: Brijesh Singh @ 2022-01-05 19:34 UTC (permalink / raw)
To: Venu Busireddy, Michael Roth
Cc: brijesh.singh, Borislav Petkov, Tom Lendacky, x86, linux-kernel,
kvm, linux-efi, platform-driver-x86, linux-coco, linux-mm,
Thomas Gleixner, Ingo Molnar, Joerg Roedel, H. Peter Anvin,
Ard Biesheuvel, Paolo Bonzini, Sean Christopherson,
Vitaly Kuznetsov, Jim Mattson, Andy Lutomirski, Dave Hansen,
Sergio Lopez, Peter Gonda, Peter Zijlstra, Srinivas Pandruvada,
David Rientjes, Dov Murik, Tobin Feldman-Fitzthum,
Vlastimil Babka, Kirill A . Shutemov, Andi Kleen,
Dr . David Alan Gilbert, tony.luck, marcorr,
sathyanarayanan.kuppuswamy
In-Reply-To: <YdNKIOg+9LAaDDF6@dt>
On 1/3/22 1:10 PM, Venu Busireddy wrote:
> On 2021-12-15 15:22:57 -0600, Michael Roth wrote:
>> On Wed, Dec 15, 2021 at 09:38:55PM +0100, Borislav Petkov wrote:
>>>
>>> But it is hard to discuss anything without patches so we can continue
>>> the topic with concrete patches. But this unification is not
>>> super-pressing so it can go ontop of the SNP pile.
>>
>> Yah, it's all theoretical at this point. Didn't mean to derail things
>> though. I mainly brought it up to suggest that Venu's original approach of
>> returning the encryption bit via a pointer argument might make it easier to
>> expand it for other purposes in the future, and that naming it for that
>> future purpose might encourage future developers to focus their efforts
>> there instead of potentially re-introducing duplicate code.
>>
>> But either way it's simple enough to rework things when we actually
>> cross that bridge. So totally fine with saving all of this as a future
>> follow-up, or picking up either of Venu's patches for now if you'd still
>> prefer.
>
> So, what is the consensus? Do you want me to submit a patch after the
> SNP changes go upstream? Or, do you want to roll in one of the patches
> that I posted earlier?
>
Will incorporate your changes in v9. And will see what others say about it.
-Brijesh
^ permalink raw reply
* [PATCH] rtc: isl1208: avoid unnecessary rc variable tests
From: Hugo Villeneuve @ 2022-01-05 19:34 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni
Cc: Hugo Villeneuve, linux-rtc, linux-kernel
From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
The rc variable doesn't need to be tested a second time when the <if> block
evaluates to false.
Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
---
drivers/rtc/rtc-isl1208.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index 182dfa605515..c7f04df5a0b6 100644
--- a/drivers/rtc/rtc-isl1208.c
+++ b/drivers/rtc/rtc-isl1208.c
@@ -880,15 +880,17 @@ isl1208_probe(struct i2c_client *client, const struct i2c_device_id *id)
if (rc)
return rc;
- if (client->irq > 0)
+ if (client->irq > 0) {
rc = isl1208_setup_irq(client, client->irq);
- if (rc)
- return rc;
+ if (rc)
+ return rc;
+ }
- if (evdet_irq > 0 && evdet_irq != client->irq)
+ if (evdet_irq > 0 && evdet_irq != client->irq) {
rc = isl1208_setup_irq(client, evdet_irq);
- if (rc)
- return rc;
+ if (rc)
+ return rc;
+ }
rc = devm_rtc_nvmem_register(isl1208->rtc, &isl1208->nvmem_config);
if (rc)
--
2.30.2
^ permalink raw reply related
* [PATCH v8 1/2] PCI: hv: Make the code arch neutral by adding arch specific interfaces
From: Sunil Muthuswamy @ 2022-01-05 19:32 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, maz, decui, tglx, mingo, bp,
hpa, lorenzo.pieralisi, robh, kw, bhelgaas, arnd
Cc: x86, linux-kernel, linux-hyperv, linux-pci, linux-arch,
Sunil Muthuswamy
In-Reply-To: <1641411156-31705-1-git-send-email-sunilmut@linux.microsoft.com>
From: Sunil Muthuswamy <sunilmut@microsoft.com>
Encapsulate arch dependencies in Hyper-V vPCI through a set of
arch-dependent interfaces. Adding these arch specific interfaces will
allow for an implementation for other architectures, such as arm64.
There are no functional changes expected from this patch.
Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
---
In v2, v3, v4, v5, v6, v7 & v8:
Changes are described in the cover letter. No changes from v4 -> v5,
v6 -> v7 or v7 -> v8.
arch/x86/include/asm/hyperv-tlfs.h | 33 ++++++++++++
arch/x86/include/asm/mshyperv.h | 7 ---
drivers/pci/controller/pci-hyperv.c | 79 ++++++++++++++++++++---------
include/asm-generic/hyperv-tlfs.h | 33 ------------
4 files changed, 87 insertions(+), 65 deletions(-)
diff --git a/arch/x86/include/asm/hyperv-tlfs.h b/arch/x86/include/asm/hyperv-tlfs.h
index 381e88122a5f..0a9407dc0859 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -602,6 +602,39 @@ enum hv_interrupt_type {
HV_X64_INTERRUPT_TYPE_MAXIMUM = 0x000A,
};
+union hv_msi_address_register {
+ u32 as_uint32;
+ struct {
+ u32 reserved1:2;
+ u32 destination_mode:1;
+ u32 redirection_hint:1;
+ u32 reserved2:8;
+ u32 destination_id:8;
+ u32 msi_base:12;
+ };
+} __packed;
+
+union hv_msi_data_register {
+ u32 as_uint32;
+ struct {
+ u32 vector:8;
+ u32 delivery_mode:3;
+ u32 reserved1:3;
+ u32 level_assert:1;
+ u32 trigger_mode:1;
+ u32 reserved2:16;
+ };
+} __packed;
+
+/* HvRetargetDeviceInterrupt hypercall */
+union hv_msi_entry {
+ u64 as_uint64;
+ struct {
+ union hv_msi_address_register address;
+ union hv_msi_data_register data;
+ } __packed;
+};
+
#include <asm-generic/hyperv-tlfs.h>
#endif
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index da3972fe5a7a..a1c3dceff8eb 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -169,13 +169,6 @@ bool hv_vcpu_is_preempted(int vcpu);
static inline void hv_apic_init(void) {}
#endif
-static inline void hv_set_msi_entry_from_desc(union hv_msi_entry *msi_entry,
- struct msi_desc *msi_desc)
-{
- msi_entry->address.as_uint32 = msi_desc->msg.address_lo;
- msi_entry->data.as_uint32 = msi_desc->msg.data;
-}
-
struct irq_domain *hv_create_pci_msi_domain(void);
int hv_map_ioapic_interrupt(int ioapic_id, bool level, int vcpu, int vector,
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index 6733cb14e775..ead7d6cb6bf1 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -43,9 +43,6 @@
#include <linux/pci-ecam.h>
#include <linux/delay.h>
#include <linux/semaphore.h>
-#include <linux/irqdomain.h>
-#include <asm/irqdomain.h>
-#include <asm/apic.h>
#include <linux/irq.h>
#include <linux/msi.h>
#include <linux/hyperv.h>
@@ -583,6 +580,42 @@ struct hv_pci_compl {
static void hv_pci_onchannelcallback(void *context);
+#ifdef CONFIG_X86
+#define DELIVERY_MODE APIC_DELIVERY_MODE_FIXED
+#define FLOW_HANDLER handle_edge_irq
+#define FLOW_NAME "edge"
+
+static int hv_pci_irqchip_init(void)
+{
+ return 0;
+}
+
+static struct irq_domain *hv_pci_get_root_domain(void)
+{
+ return x86_vector_domain;
+}
+
+static unsigned int hv_msi_get_int_vector(struct irq_data *data)
+{
+ struct irq_cfg *cfg = irqd_cfg(data);
+
+ return cfg->vector;
+}
+
+static void hv_set_msi_entry_from_desc(union hv_msi_entry *msi_entry,
+ struct msi_desc *msi_desc)
+{
+ msi_entry->address.as_uint32 = msi_desc->msg.address_lo;
+ msi_entry->data.as_uint32 = msi_desc->msg.data;
+}
+
+static int hv_msi_prepare(struct irq_domain *domain, struct device *dev,
+ int nvec, msi_alloc_info_t *info)
+{
+ return pci_msi_prepare(domain, dev, nvec, info);
+}
+#endif /* CONFIG_X86 */
+
/**
* hv_pci_generic_compl() - Invoked for a completion packet
* @context: Set up by the sender of the packet.
@@ -1191,14 +1224,6 @@ static void hv_msi_free(struct irq_domain *domain, struct msi_domain_info *info,
put_pcichild(hpdev);
}
-static int hv_set_affinity(struct irq_data *data, const struct cpumask *dest,
- bool force)
-{
- struct irq_data *parent = data->parent_data;
-
- return parent->chip->irq_set_affinity(parent, dest, force);
-}
-
static void hv_irq_mask(struct irq_data *data)
{
pci_msi_mask_irq(data);
@@ -1217,7 +1242,6 @@ static void hv_irq_mask(struct irq_data *data)
static void hv_irq_unmask(struct irq_data *data)
{
struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
- struct irq_cfg *cfg = irqd_cfg(data);
struct hv_retarget_device_interrupt *params;
struct hv_pcibus_device *hbus;
struct cpumask *dest;
@@ -1246,7 +1270,7 @@ static void hv_irq_unmask(struct irq_data *data)
(hbus->hdev->dev_instance.b[7] << 8) |
(hbus->hdev->dev_instance.b[6] & 0xf8) |
PCI_FUNC(pdev->devfn);
- params->int_target.vector = cfg->vector;
+ params->int_target.vector = hv_msi_get_int_vector(data);
/*
* Honoring apic->delivery_mode set to APIC_DELIVERY_MODE_FIXED by
@@ -1347,7 +1371,7 @@ static u32 hv_compose_msi_req_v1(
int_pkt->wslot.slot = slot;
int_pkt->int_desc.vector = vector;
int_pkt->int_desc.vector_count = 1;
- int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED;
+ int_pkt->int_desc.delivery_mode = DELIVERY_MODE;
/*
* Create MSI w/ dummy vCPU set, overwritten by subsequent retarget in
@@ -1377,7 +1401,7 @@ static u32 hv_compose_msi_req_v2(
int_pkt->wslot.slot = slot;
int_pkt->int_desc.vector = vector;
int_pkt->int_desc.vector_count = 1;
- int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED;
+ int_pkt->int_desc.delivery_mode = DELIVERY_MODE;
cpu = hv_compose_msi_req_get_cpu(affinity);
int_pkt->int_desc.processor_array[0] =
hv_cpu_number_to_vp_number(cpu);
@@ -1397,7 +1421,7 @@ static u32 hv_compose_msi_req_v3(
int_pkt->int_desc.vector = vector;
int_pkt->int_desc.reserved = 0;
int_pkt->int_desc.vector_count = 1;
- int_pkt->int_desc.delivery_mode = APIC_DELIVERY_MODE_FIXED;
+ int_pkt->int_desc.delivery_mode = DELIVERY_MODE;
cpu = hv_compose_msi_req_get_cpu(affinity);
int_pkt->int_desc.processor_array[0] =
hv_cpu_number_to_vp_number(cpu);
@@ -1419,7 +1443,6 @@ static u32 hv_compose_msi_req_v3(
*/
static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
{
- struct irq_cfg *cfg = irqd_cfg(data);
struct hv_pcibus_device *hbus;
struct vmbus_channel *channel;
struct hv_pci_dev *hpdev;
@@ -1470,7 +1493,7 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
size = hv_compose_msi_req_v1(&ctxt.int_pkts.v1,
dest,
hpdev->desc.win_slot.slot,
- cfg->vector);
+ hv_msi_get_int_vector(data));
break;
case PCI_PROTOCOL_VERSION_1_2:
@@ -1478,14 +1501,14 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2,
dest,
hpdev->desc.win_slot.slot,
- cfg->vector);
+ hv_msi_get_int_vector(data));
break;
case PCI_PROTOCOL_VERSION_1_4:
size = hv_compose_msi_req_v3(&ctxt.int_pkts.v3,
dest,
hpdev->desc.win_slot.slot,
- cfg->vector);
+ hv_msi_get_int_vector(data));
break;
default:
@@ -1594,14 +1617,14 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
static struct irq_chip hv_msi_irq_chip = {
.name = "Hyper-V PCIe MSI",
.irq_compose_msi_msg = hv_compose_msi_msg,
- .irq_set_affinity = hv_set_affinity,
+ .irq_set_affinity = irq_chip_set_affinity_parent,
.irq_ack = irq_chip_ack_parent,
.irq_mask = hv_irq_mask,
.irq_unmask = hv_irq_unmask,
};
static struct msi_domain_ops hv_msi_ops = {
- .msi_prepare = pci_msi_prepare,
+ .msi_prepare = hv_msi_prepare,
.msi_free = hv_msi_free,
};
@@ -1625,12 +1648,12 @@ static int hv_pcie_init_irq_domain(struct hv_pcibus_device *hbus)
hbus->msi_info.flags = (MSI_FLAG_USE_DEF_DOM_OPS |
MSI_FLAG_USE_DEF_CHIP_OPS | MSI_FLAG_MULTI_PCI_MSI |
MSI_FLAG_PCI_MSIX);
- hbus->msi_info.handler = handle_edge_irq;
- hbus->msi_info.handler_name = "edge";
+ hbus->msi_info.handler = FLOW_HANDLER;
+ hbus->msi_info.handler_name = FLOW_NAME;
hbus->msi_info.data = hbus;
hbus->irq_domain = pci_msi_create_irq_domain(hbus->fwnode,
&hbus->msi_info,
- x86_vector_domain);
+ hv_pci_get_root_domain());
if (!hbus->irq_domain) {
dev_err(&hbus->hdev->device,
"Failed to build an MSI IRQ domain\n");
@@ -3542,9 +3565,15 @@ static void __exit exit_hv_pci_drv(void)
static int __init init_hv_pci_drv(void)
{
+ int ret;
+
if (!hv_is_hyperv_initialized())
return -ENODEV;
+ ret = hv_pci_irqchip_init();
+ if (ret)
+ return ret;
+
/* Set the invalid domain number's bit, so it will not be used */
set_bit(HVPCI_DOM_INVALID, hvpci_dom_map);
diff --git a/include/asm-generic/hyperv-tlfs.h b/include/asm-generic/hyperv-tlfs.h
index 8ed6733d5146..8f97c2927bee 100644
--- a/include/asm-generic/hyperv-tlfs.h
+++ b/include/asm-generic/hyperv-tlfs.h
@@ -540,39 +540,6 @@ enum hv_interrupt_source {
HV_INTERRUPT_SOURCE_IOAPIC,
};
-union hv_msi_address_register {
- u32 as_uint32;
- struct {
- u32 reserved1:2;
- u32 destination_mode:1;
- u32 redirection_hint:1;
- u32 reserved2:8;
- u32 destination_id:8;
- u32 msi_base:12;
- };
-} __packed;
-
-union hv_msi_data_register {
- u32 as_uint32;
- struct {
- u32 vector:8;
- u32 delivery_mode:3;
- u32 reserved1:3;
- u32 level_assert:1;
- u32 trigger_mode:1;
- u32 reserved2:16;
- };
-} __packed;
-
-/* HvRetargetDeviceInterrupt hypercall */
-union hv_msi_entry {
- u64 as_uint64;
- struct {
- union hv_msi_address_register address;
- union hv_msi_data_register data;
- } __packed;
-};
-
union hv_ioapic_rte {
u64 as_uint64;
--
2.25.1
^ permalink raw reply related
* [PATCH v8 2/2] PCI: hv: Add arm64 Hyper-V vPCI support
From: Sunil Muthuswamy @ 2022-01-05 19:32 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, maz, decui, tglx, mingo, bp,
hpa, lorenzo.pieralisi, robh, kw, bhelgaas, arnd
Cc: x86, linux-kernel, linux-hyperv, linux-pci, linux-arch,
Sunil Muthuswamy
In-Reply-To: <1641411156-31705-1-git-send-email-sunilmut@linux.microsoft.com>
From: Sunil Muthuswamy <sunilmut@microsoft.com>
Add arm64 Hyper-V vPCI support by implementing the arch specific
interfaces. Introduce an IRQ domain and chip specific to Hyper-v vPCI that
is based on SPIs. The IRQ domain parents itself to the arch GIC IRQ domain
for basic vector management.
Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
---
In v2, v3, v4, v5, v6, v7 & v8:
Changes are described in the cover letter.
arch/arm64/include/asm/hyperv-tlfs.h | 9 +
drivers/pci/Kconfig | 2 +-
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pci-hyperv.c | 235 ++++++++++++++++++++++++++-
4 files changed, 245 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/hyperv-tlfs.h b/arch/arm64/include/asm/hyperv-tlfs.h
index 4d964a7f02ee..bc6c7ac934a1 100644
--- a/arch/arm64/include/asm/hyperv-tlfs.h
+++ b/arch/arm64/include/asm/hyperv-tlfs.h
@@ -64,6 +64,15 @@
#define HV_REGISTER_STIMER0_CONFIG 0x000B0000
#define HV_REGISTER_STIMER0_COUNT 0x000B0001
+union hv_msi_entry {
+ u64 as_uint64[2];
+ struct {
+ u64 address;
+ u32 data;
+ u32 reserved;
+ } __packed;
+};
+
#include <asm-generic/hyperv-tlfs.h>
#endif
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 43e615aa12ff..d98fafdd0f99 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -184,7 +184,7 @@ config PCI_LABEL
config PCI_HYPERV
tristate "Hyper-V PCI Frontend"
- depends on X86_64 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && SYSFS
+ depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && SYSFS
select PCI_HYPERV_INTERFACE
help
The PCI device frontend driver allows the kernel to import arbitrary
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 93b141110537..2536abcc045a 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -281,7 +281,7 @@ config PCIE_BRCMSTB
config PCI_HYPERV_INTERFACE
tristate "Hyper-V PCI Interface"
- depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
+ depends on ((X86 && X86_64) || ARM64) && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN
help
The Hyper-V PCI Interface is a helper driver allows other drivers to
have a common interface with the Hyper-V PCI frontend driver.
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index ead7d6cb6bf1..b941aa43f909 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -47,6 +47,8 @@
#include <linux/msi.h>
#include <linux/hyperv.h>
#include <linux/refcount.h>
+#include <linux/irqdomain.h>
+#include <linux/acpi.h>
#include <asm/mshyperv.h>
/*
@@ -614,7 +616,230 @@ static int hv_msi_prepare(struct irq_domain *domain, struct device *dev,
{
return pci_msi_prepare(domain, dev, nvec, info);
}
-#endif /* CONFIG_X86 */
+#elif defined(CONFIG_ARM64)
+/*
+ * SPI vectors to use for vPCI; arch SPIs range is [32, 1019], but leaving a bit
+ * of room at the start to allow for SPIs to be specified through ACPI and
+ * starting with a power of two to satisfy power of 2 multi-MSI requirement.
+ */
+#define HV_PCI_MSI_SPI_START 64
+#define HV_PCI_MSI_SPI_NR (1020 - HV_PCI_MSI_SPI_START)
+#define DELIVERY_MODE 0
+#define FLOW_HANDLER NULL
+#define FLOW_NAME NULL
+#define hv_msi_prepare NULL
+
+struct hv_pci_chip_data {
+ DECLARE_BITMAP(spi_map, HV_PCI_MSI_SPI_NR);
+ struct mutex map_lock;
+};
+
+/* Hyper-V vPCI MSI GIC IRQ domain */
+static struct irq_domain *hv_msi_gic_irq_domain;
+
+/* Hyper-V PCI MSI IRQ chip */
+static struct irq_chip hv_arm64_msi_irq_chip = {
+ .name = "MSI",
+ .irq_set_affinity = irq_chip_set_affinity_parent,
+ .irq_eoi = irq_chip_eoi_parent,
+ .irq_mask = irq_chip_mask_parent,
+ .irq_unmask = irq_chip_unmask_parent
+};
+
+static unsigned int hv_msi_get_int_vector(struct irq_data *irqd)
+{
+ return irqd->parent_data->hwirq;
+}
+
+static void hv_set_msi_entry_from_desc(union hv_msi_entry *msi_entry,
+ struct msi_desc *msi_desc)
+{
+ msi_entry->address = ((u64)msi_desc->msg.address_hi << 32) |
+ msi_desc->msg.address_lo;
+ msi_entry->data = msi_desc->msg.data;
+}
+
+/*
+ * @nr_bm_irqs: Indicates the number of IRQs that were allocated from
+ * the bitmap.
+ * @nr_dom_irqs: Indicates the number of IRQs that were allocated from
+ * the parent domain.
+ */
+static void hv_pci_vec_irq_free(struct irq_domain *domain,
+ unsigned int virq,
+ unsigned int nr_bm_irqs,
+ unsigned int nr_dom_irqs)
+{
+ struct hv_pci_chip_data *chip_data = domain->host_data;
+ struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+ int first = d->hwirq - HV_PCI_MSI_SPI_START;
+ int i;
+
+ mutex_lock(&chip_data->map_lock);
+ bitmap_release_region(chip_data->spi_map,
+ first,
+ get_count_order(nr_bm_irqs));
+ mutex_unlock(&chip_data->map_lock);
+ for (i = 0; i < nr_dom_irqs; i++) {
+ if (i)
+ d = irq_domain_get_irq_data(domain, virq + i);
+ irq_domain_reset_irq_data(d);
+ }
+
+ irq_domain_free_irqs_parent(domain, virq, nr_dom_irqs);
+}
+
+static void hv_pci_vec_irq_domain_free(struct irq_domain *domain,
+ unsigned int virq,
+ unsigned int nr_irqs)
+{
+ hv_pci_vec_irq_free(domain, virq, nr_irqs, nr_irqs);
+}
+
+static int hv_pci_vec_alloc_device_irq(struct irq_domain *domain,
+ unsigned int nr_irqs,
+ irq_hw_number_t *hwirq)
+{
+ struct hv_pci_chip_data *chip_data = domain->host_data;
+ unsigned int index;
+
+ /* Find and allocate region from the SPI bitmap */
+ mutex_lock(&chip_data->map_lock);
+ index = bitmap_find_free_region(chip_data->spi_map,
+ HV_PCI_MSI_SPI_NR,
+ get_count_order(nr_irqs));
+ mutex_unlock(&chip_data->map_lock);
+ if (index < 0)
+ return -ENOSPC;
+
+ *hwirq = index + HV_PCI_MSI_SPI_START;
+
+ return 0;
+}
+
+static int hv_pci_vec_irq_gic_domain_alloc(struct irq_domain *domain,
+ unsigned int virq,
+ irq_hw_number_t hwirq)
+{
+ struct irq_fwspec fwspec;
+ struct irq_data *d;
+ int ret;
+
+ fwspec.fwnode = domain->parent->fwnode;
+ fwspec.param_count = 2;
+ fwspec.param[0] = hwirq;
+ fwspec.param[1] = IRQ_TYPE_EDGE_RISING;
+
+ ret = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
+ if (ret)
+ return ret;
+
+ /*
+ * Since the interrupt specifier is not coming from ACPI or DT, the
+ * trigger type will need to be set explicitly. Otherwise, it will be
+ * set to whatever is in the GIC configuration.
+ */
+ d = irq_domain_get_irq_data(domain->parent, virq);
+
+ return d->chip->irq_set_type(d, IRQ_TYPE_EDGE_RISING);
+}
+
+static int hv_pci_vec_irq_domain_alloc(struct irq_domain *domain,
+ unsigned int virq, unsigned int nr_irqs,
+ void *args)
+{
+ irq_hw_number_t hwirq;
+ unsigned int i;
+ int ret;
+
+ ret = hv_pci_vec_alloc_device_irq(domain, nr_irqs, &hwirq);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < nr_irqs; i++) {
+ ret = hv_pci_vec_irq_gic_domain_alloc(domain, virq + i,
+ hwirq + i);
+ if (ret) {
+ hv_pci_vec_irq_free(domain, virq, nr_irqs, i);
+ return ret;
+ }
+
+ irq_domain_set_hwirq_and_chip(domain, virq + i,
+ hwirq + i,
+ &hv_arm64_msi_irq_chip,
+ domain->host_data);
+ pr_debug("pID:%d vID:%u\n", (int)(hwirq + i), virq + i);
+ }
+
+ return 0;
+}
+
+/*
+ * Pick the first cpu as the irq affinity that can be temporarily used for
+ * composing MSI from the hypervisor. GIC will eventually set the right
+ * affinity for the irq and the 'unmask' will retarget the interrupt to that
+ * cpu.
+ */
+static int hv_pci_vec_irq_domain_activate(struct irq_domain *domain,
+ struct irq_data *irqd, bool reserve)
+{
+ int cpu = cpumask_first(cpu_present_mask);
+
+ irq_data_update_effective_affinity(irqd, cpumask_of(cpu));
+
+ return 0;
+}
+
+static const struct irq_domain_ops hv_pci_domain_ops = {
+ .alloc = hv_pci_vec_irq_domain_alloc,
+ .free = hv_pci_vec_irq_domain_free,
+ .activate = hv_pci_vec_irq_domain_activate,
+};
+
+static int hv_pci_irqchip_init(void)
+{
+ static struct hv_pci_chip_data *chip_data;
+ struct fwnode_handle *fn = NULL;
+ int ret = -ENOMEM;
+
+ chip_data = kzalloc(sizeof(*chip_data), GFP_KERNEL);
+ if (!chip_data)
+ return ret;
+
+ mutex_init(&chip_data->map_lock);
+ fn = irq_domain_alloc_named_fwnode("hv_vpci_arm64");
+ if (!fn)
+ goto free_chip;
+
+ /*
+ * IRQ domain once enabled, should not be removed since there is no
+ * way to ensure that all the corresponding devices are also gone and
+ * no interrupts will be generated.
+ */
+ hv_msi_gic_irq_domain = acpi_irq_create_hierarchy(0, HV_PCI_MSI_SPI_NR,
+ fn, &hv_pci_domain_ops,
+ chip_data);
+
+ if (!hv_msi_gic_irq_domain) {
+ pr_err("Failed to create Hyper-V arm64 vPCI MSI IRQ domain\n");
+ goto free_chip;
+ }
+
+ return 0;
+
+free_chip:
+ kfree(chip_data);
+ if (fn)
+ irq_domain_free_fwnode(fn);
+
+ return ret;
+}
+
+static struct irq_domain *hv_pci_get_root_domain(void)
+{
+ return hv_msi_gic_irq_domain;
+}
+#endif /* CONFIG_ARM64 */
/**
* hv_pci_generic_compl() - Invoked for a completion packet
@@ -1227,6 +1452,8 @@ static void hv_msi_free(struct irq_domain *domain, struct msi_domain_info *info,
static void hv_irq_mask(struct irq_data *data)
{
pci_msi_mask_irq(data);
+ if (data->parent_data->chip->irq_mask)
+ irq_chip_mask_parent(data);
}
/**
@@ -1343,6 +1570,8 @@ static void hv_irq_unmask(struct irq_data *data)
dev_err(&hbus->hdev->device,
"%s() failed: %#llx", __func__, res);
+ if (data->parent_data->chip->irq_unmask)
+ irq_chip_unmask_parent(data);
pci_msi_unmask_irq(data);
}
@@ -1618,7 +1847,11 @@ static struct irq_chip hv_msi_irq_chip = {
.name = "Hyper-V PCIe MSI",
.irq_compose_msi_msg = hv_compose_msi_msg,
.irq_set_affinity = irq_chip_set_affinity_parent,
+#ifdef CONFIG_X86
.irq_ack = irq_chip_ack_parent,
+#elif defined(CONFIG_ARM64)
+ .irq_eoi = irq_chip_eoi_parent,
+#endif
.irq_mask = hv_irq_mask,
.irq_unmask = hv_irq_unmask,
};
--
2.25.1
^ permalink raw reply related
* [PATCH v8 0/2] PCI: hv: Hyper-V vPCI for arm64
From: Sunil Muthuswamy @ 2022-01-05 19:32 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, maz, decui, tglx, mingo, bp,
hpa, lorenzo.pieralisi, robh, kw, bhelgaas, arnd
Cc: x86, linux-kernel, linux-hyperv, linux-pci, linux-arch,
Sunil Muthuswamy
From: Sunil Muthuswamy <sunilmut@microsoft.com>
Current Hyper-V vPCI code only compiles and works for x86. There are some
hardcoded assumptions about the architectural IRQ chip and other arch
defines.
Add support for Hyper-V vPCI for arm64 by first breaking the current hard
coded dependency using a set of new interfaces and implementing those for
x86 first. That is in the first patch. The second patch adds support for
Hyper-V vPCI for arm64 by implementing the above mentioned interfaces. That
is done by introducing a Hyper-V vPCI specific MSI IRQ domain & chip for
allocating SPI vectors.
changes in v1 -> v2:
- Moved the irqchip implementation to drivers/pci as suggested
by Marc Zyngier
- Addressed Multi-MSI handling issues identified by Marc Zyngier
- Addressed lock/synchronization primitive as suggested by Marc
Zyngier
- Addressed other code feedback from Marc Zyngier
changes in v2 -> v3:
- Addressed comments from Bjorn Helgaas about patch formatting and
verbiage
- Using 'git send-email' to ensure that the patch series is correctly
threaded. Feedback by Bjorn Helgaas
- Fixed Hyper-V vPCI build break for module build, reported by Boqun Feng
changes in v3 -> v4:
- Removed the separate file for IRQ chip that was there in previous
iterations and moved the IRQ chip implementation to pci-hyperv.c.
Feedback by Michael Kelley and Marc Zyngier.
- Addressed various comments from Marc Zyngier about structuring and
layout.
- Addressed comment from Marc Zyngier about IRQ affinity and other
miscellaneous comments.
changes in v4 -> v5:
- Fixed an issue with picking the right cpu for irq affinity, identified
by Marc Zyngier.
changes in v5 -> v6:
- Minor comment updates suggested by Michael Kelley.
changes in v6 -> v7:
- Addressed feedback from Marc Zyngier about IRQ cleanup in the error path
and explicitly setting the IRQ trigger type.
- Address feedback from Bjorn Helgaas about subject line format.
changes in v7 -> v8:
- Addressed feedback from Michael Kelley about the cpu mask to use for the
initial interrupt affinity and IRQ cleanup in the error path.
Sunil Muthuswamy (2):
PCI: hv: Make the code arch neutral by adding arch specific interfaces
PCI: hv: Add arm64 Hyper-V vPCI support
arch/arm64/include/asm/hyperv-tlfs.h | 9 +
arch/x86/include/asm/hyperv-tlfs.h | 33 +++
arch/x86/include/asm/mshyperv.h | 7 -
drivers/pci/Kconfig | 2 +-
drivers/pci/controller/Kconfig | 2 +-
drivers/pci/controller/pci-hyperv.c | 312 ++++++++++++++++++++++++---
include/asm-generic/hyperv-tlfs.h | 33 ---
7 files changed, 331 insertions(+), 67 deletions(-)
base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf
--
2.25.1
^ permalink raw reply
* drivers/platform/surface/surface_aggregator_cdev.c:557 ssam_cdev_read() error: uninitialized symbol 'copied'.
From: kernel test robot @ 2022-01-05 19:32 UTC (permalink / raw)
To: kbuild
[-- Attachment #1: Type: text/plain, Size: 6001 bytes --]
CC: kbuild-all(a)lists.01.org
CC: linux-kernel(a)vger.kernel.org
TO: Maximilian Luz <luzmaximilian@gmail.com>
CC: Hans de Goede <hdegoede@redhat.com>
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: c9e6606c7fe92b50a02ce51dda82586ebdf99b48
commit: 776c53c6a448905d8b9b161805b67f82301bfe91 platform/surface: aggregator_cdev: Add support for forwarding events to user-space
date: 7 months ago
:::::: branch date: 3 days ago
:::::: commit date: 7 months ago
config: x86_64-randconfig-m001-20220105 (https://download.01.org/0day-ci/archive/20220106/202201060313.HEOxjoNk-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
smatch warnings:
drivers/platform/surface/surface_aggregator_cdev.c:557 ssam_cdev_read() error: uninitialized symbol 'copied'.
vim +/copied +557 drivers/platform/surface/surface_aggregator_cdev.c
776c53c6a44890 Maximilian Luz 2021-06-04 500
776c53c6a44890 Maximilian Luz 2021-06-04 501 static ssize_t ssam_cdev_read(struct file *file, char __user *buf, size_t count, loff_t *offs)
776c53c6a44890 Maximilian Luz 2021-06-04 502 {
776c53c6a44890 Maximilian Luz 2021-06-04 503 struct ssam_cdev_client *client = file->private_data;
776c53c6a44890 Maximilian Luz 2021-06-04 504 struct ssam_cdev *cdev = client->cdev;
776c53c6a44890 Maximilian Luz 2021-06-04 505 unsigned int copied;
776c53c6a44890 Maximilian Luz 2021-06-04 506 int status = 0;
776c53c6a44890 Maximilian Luz 2021-06-04 507
178f6ab77e617c Maximilian Luz 2020-12-21 508 if (down_read_killable(&cdev->lock))
178f6ab77e617c Maximilian Luz 2020-12-21 509 return -ERESTARTSYS;
178f6ab77e617c Maximilian Luz 2020-12-21 510
776c53c6a44890 Maximilian Luz 2021-06-04 511 /* Make sure we're not shut down. */
776c53c6a44890 Maximilian Luz 2021-06-04 512 if (test_bit(SSAM_CDEV_DEVICE_SHUTDOWN_BIT, &cdev->flags)) {
178f6ab77e617c Maximilian Luz 2020-12-21 513 up_read(&cdev->lock);
178f6ab77e617c Maximilian Luz 2020-12-21 514 return -ENODEV;
178f6ab77e617c Maximilian Luz 2020-12-21 515 }
178f6ab77e617c Maximilian Luz 2020-12-21 516
776c53c6a44890 Maximilian Luz 2021-06-04 517 do {
776c53c6a44890 Maximilian Luz 2021-06-04 518 /* Check availability, wait if necessary. */
776c53c6a44890 Maximilian Luz 2021-06-04 519 if (kfifo_is_empty(&client->buffer)) {
776c53c6a44890 Maximilian Luz 2021-06-04 520 up_read(&cdev->lock);
776c53c6a44890 Maximilian Luz 2021-06-04 521
776c53c6a44890 Maximilian Luz 2021-06-04 522 if (file->f_flags & O_NONBLOCK)
776c53c6a44890 Maximilian Luz 2021-06-04 523 return -EAGAIN;
178f6ab77e617c Maximilian Luz 2020-12-21 524
776c53c6a44890 Maximilian Luz 2021-06-04 525 status = wait_event_interruptible(client->waitq,
776c53c6a44890 Maximilian Luz 2021-06-04 526 !kfifo_is_empty(&client->buffer) ||
776c53c6a44890 Maximilian Luz 2021-06-04 527 test_bit(SSAM_CDEV_DEVICE_SHUTDOWN_BIT,
776c53c6a44890 Maximilian Luz 2021-06-04 528 &cdev->flags));
776c53c6a44890 Maximilian Luz 2021-06-04 529 if (status < 0)
776c53c6a44890 Maximilian Luz 2021-06-04 530 return status;
776c53c6a44890 Maximilian Luz 2021-06-04 531
776c53c6a44890 Maximilian Luz 2021-06-04 532 if (down_read_killable(&cdev->lock))
776c53c6a44890 Maximilian Luz 2021-06-04 533 return -ERESTARTSYS;
776c53c6a44890 Maximilian Luz 2021-06-04 534
776c53c6a44890 Maximilian Luz 2021-06-04 535 /* Need to check that we're not shut down again. */
776c53c6a44890 Maximilian Luz 2021-06-04 536 if (test_bit(SSAM_CDEV_DEVICE_SHUTDOWN_BIT, &cdev->flags)) {
776c53c6a44890 Maximilian Luz 2021-06-04 537 up_read(&cdev->lock);
776c53c6a44890 Maximilian Luz 2021-06-04 538 return -ENODEV;
776c53c6a44890 Maximilian Luz 2021-06-04 539 }
776c53c6a44890 Maximilian Luz 2021-06-04 540 }
776c53c6a44890 Maximilian Luz 2021-06-04 541
776c53c6a44890 Maximilian Luz 2021-06-04 542 /* Try to read from FIFO. */
776c53c6a44890 Maximilian Luz 2021-06-04 543 if (mutex_lock_interruptible(&client->read_lock)) {
776c53c6a44890 Maximilian Luz 2021-06-04 544 up_read(&cdev->lock);
776c53c6a44890 Maximilian Luz 2021-06-04 545 return -ERESTARTSYS;
776c53c6a44890 Maximilian Luz 2021-06-04 546 }
776c53c6a44890 Maximilian Luz 2021-06-04 547
776c53c6a44890 Maximilian Luz 2021-06-04 548 status = kfifo_to_user(&client->buffer, buf, count, &copied);
776c53c6a44890 Maximilian Luz 2021-06-04 549 mutex_unlock(&client->read_lock);
776c53c6a44890 Maximilian Luz 2021-06-04 550
776c53c6a44890 Maximilian Luz 2021-06-04 551 if (status < 0) {
178f6ab77e617c Maximilian Luz 2020-12-21 552 up_read(&cdev->lock);
178f6ab77e617c Maximilian Luz 2020-12-21 553 return status;
178f6ab77e617c Maximilian Luz 2020-12-21 554 }
178f6ab77e617c Maximilian Luz 2020-12-21 555
776c53c6a44890 Maximilian Luz 2021-06-04 556 /* We might not have gotten anything, check this here. */
776c53c6a44890 Maximilian Luz 2021-06-04 @557 if (copied == 0 && (file->f_flags & O_NONBLOCK)) {
776c53c6a44890 Maximilian Luz 2021-06-04 558 up_read(&cdev->lock);
776c53c6a44890 Maximilian Luz 2021-06-04 559 return -EAGAIN;
776c53c6a44890 Maximilian Luz 2021-06-04 560 }
776c53c6a44890 Maximilian Luz 2021-06-04 561 } while (copied == 0);
776c53c6a44890 Maximilian Luz 2021-06-04 562
776c53c6a44890 Maximilian Luz 2021-06-04 563 up_read(&cdev->lock);
776c53c6a44890 Maximilian Luz 2021-06-04 564 return copied;
776c53c6a44890 Maximilian Luz 2021-06-04 565 }
776c53c6a44890 Maximilian Luz 2021-06-04 566
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* Re: [PATCH] io_uring: remove redundant tap space
From: Jens Axboe @ 2022-01-05 19:32 UTC (permalink / raw)
To: GuoYong Zheng, asml.silence; +Cc: io-uring, linux-kernel
In-Reply-To: <1641377585-1891-1-git-send-email-zhenggy@chinatelecom.cn>
On Wed, 5 Jan 2022 18:13:05 +0800, GuoYong Zheng wrote:
> When show fdinfo, SqMask follow two tap space, Inconsistent with
> other paras, remove one.
>
>
Applied, thanks!
[1/1] io_uring: remove redundant tap space
commit: c0235652ee5194fc75926daa580817e63ceb37ab
Best regards,
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] io_uring: remove unused para
From: Jens Axboe @ 2022-01-05 19:30 UTC (permalink / raw)
To: GuoYong Zheng, asml.silence; +Cc: io-uring, linux-kernel
In-Reply-To: <1641377522-1851-1-git-send-email-zhenggy@chinatelecom.cn>
On 1/5/22 2:12 AM, GuoYong Zheng wrote:
> Para res2 is not used in __io_complete_rw, remove it.
Applied, but changed 'para' to parameter. Please just spell it out,
there's no point in being too verbose here. Also added a Fixes tag:
https://git.kernel.dk/cgit/linux-block/commit/?h=for-5.17/io_uring&id=00f6e68b8d59bf006db54e3e257684f44d26195c
Thank you!
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] block/rnbd-clt-sysfs: use default_groups in kobj_type
From: Jens Axboe @ 2022-01-05 19:28 UTC (permalink / raw)
To: linux-kernel, Greg Kroah-Hartman; +Cc: Jack Wang, Md. Haris Iqbal, linux-block
In-Reply-To: <20220104162947.1320936-1-gregkh@linuxfoundation.org>
On Tue, 4 Jan 2022 17:29:47 +0100, Greg Kroah-Hartman wrote:
> There are currently 2 ways to create a set of sysfs files for a
> kobj_type, through the default_attrs field, and the default_groups
> field. Move the rnbd controller sysfs code to use default_groups field
> which has been the preferred way since aa30f47cf666 ("kobject: Add
> support for default attribute groups to kobj_type") so that we can soon
> get rid of the obsolete default_attrs field.
>
> [...]
Applied, thanks!
[1/1] block/rnbd-clt-sysfs: use default_groups in kobj_type
commit: 050f461e28c5d13f327353d660ffad2603ce7ac1
Best regards,
--
Jens Axboe
^ permalink raw reply
* [PATCH] Drivers: hv: vmbus: Initialize request offers message for Isolation VM
From: Juan Vazquez @ 2022-01-05 19:27 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, decui, mikelley
Cc: linux-hyperv, linux-kernel
Initialize memory of request offers message to be sent to the host so
padding or uninitialized fields do not leak guest memory contents.
Signed-off-by: Juan Vazquez <juvazq@linux.microsoft.com>
---
drivers/hv/channel_mgmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 2829575fd9b7..60375879612f 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -1554,7 +1554,7 @@ int vmbus_request_offers(void)
struct vmbus_channel_msginfo *msginfo;
int ret;
- msginfo = kmalloc(sizeof(*msginfo) +
+ msginfo = kzalloc(sizeof(*msginfo) +
sizeof(struct vmbus_channel_message_header),
GFP_KERNEL);
if (!msginfo)
--
2.32.0
^ permalink raw reply related
* Re: [PATCH] drm/amdkfd: make SPDX License expression more sound
From: Felix Kuehling @ 2022-01-05 19:27 UTC (permalink / raw)
To: Lukas Bulwahn, Jonathan Kim, Alex Deucher, amd-gfx
Cc: Thomas Gleixner, Greg Kroah-Hartman, linux-spdx, linux-kernel
In-Reply-To: <20211216094503.10597-1-lukas.bulwahn@gmail.com>
Am 2021-12-16 um 4:45 a.m. schrieb Lukas Bulwahn:
> Commit b5f57384805a ("drm/amdkfd: Add sysfs bitfields and enums to uAPI")
> adds include/uapi/linux/kfd_sysfs.h with the "GPL-2.0 OR MIT WITH
> Linux-syscall-note" SPDX-License expression.
>
> The command ./scripts/spdxcheck.py warns:
>
> include/uapi/linux/kfd_sysfs.h: 1:48 Exception not valid for license MIT: Linux-syscall-note
>
> For a uapi header, the file under GPLv2 License must be combined with the
> Linux-syscall-note, but combining the MIT License with the
> Linux-syscall-note makes no sense, as the note provides an exception for
> GPL-licensed code, not for permissively licensed code.
>
> So, reorganize the SPDX expression to only combine the note with the GPL
> License condition. This makes spdxcheck happy again.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
> ---
> I am not a lawyer and I do not intend to modify the actual licensing of
> this header file. So, I really would like to have an Ack from some AMD
> developer here.
>
> Maybe also a lawyer on the linux-spdx list can check my reasoning on the
> licensing with the exception note?
>
> include/uapi/linux/kfd_sysfs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/kfd_sysfs.h b/include/uapi/linux/kfd_sysfs.h
> index e1fb78b4bf09..3e330f368917 100644
> --- a/include/uapi/linux/kfd_sysfs.h
> +++ b/include/uapi/linux/kfd_sysfs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 OR MIT WITH Linux-syscall-note */
> +/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> /*
> * Copyright 2021 Advanced Micro Devices, Inc.
> *
^ permalink raw reply
* Re: [PATCH] drm/amdkfd: make SPDX License expression more sound
From: Felix Kuehling @ 2022-01-05 19:27 UTC (permalink / raw)
To: Lukas Bulwahn, Jonathan Kim, Alex Deucher, amd-gfx
Cc: Greg Kroah-Hartman, Thomas Gleixner, linux-kernel, linux-spdx
In-Reply-To: <20211216094503.10597-1-lukas.bulwahn@gmail.com>
Am 2021-12-16 um 4:45 a.m. schrieb Lukas Bulwahn:
> Commit b5f57384805a ("drm/amdkfd: Add sysfs bitfields and enums to uAPI")
> adds include/uapi/linux/kfd_sysfs.h with the "GPL-2.0 OR MIT WITH
> Linux-syscall-note" SPDX-License expression.
>
> The command ./scripts/spdxcheck.py warns:
>
> include/uapi/linux/kfd_sysfs.h: 1:48 Exception not valid for license MIT: Linux-syscall-note
>
> For a uapi header, the file under GPLv2 License must be combined with the
> Linux-syscall-note, but combining the MIT License with the
> Linux-syscall-note makes no sense, as the note provides an exception for
> GPL-licensed code, not for permissively licensed code.
>
> So, reorganize the SPDX expression to only combine the note with the GPL
> License condition. This makes spdxcheck happy again.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
> ---
> I am not a lawyer and I do not intend to modify the actual licensing of
> this header file. So, I really would like to have an Ack from some AMD
> developer here.
>
> Maybe also a lawyer on the linux-spdx list can check my reasoning on the
> licensing with the exception note?
>
> include/uapi/linux/kfd_sysfs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/kfd_sysfs.h b/include/uapi/linux/kfd_sysfs.h
> index e1fb78b4bf09..3e330f368917 100644
> --- a/include/uapi/linux/kfd_sysfs.h
> +++ b/include/uapi/linux/kfd_sysfs.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 OR MIT WITH Linux-syscall-note */
> +/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) OR MIT */
> /*
> * Copyright 2021 Advanced Micro Devices, Inc.
> *
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.