* Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
From: Iurii Zaikin @ 2019-07-08 23:34 UTC (permalink / raw)
To: Brendan Higgins
Cc: Luis Chamberlain, Frank Rowand, Greg KH, Josh Poimboeuf,
Kees Cook, Kieran Bingham, Peter Zijlstra, Rob Herring,
Stephen Boyd, shuah, Theodore Ts'o, Masahiro Yamada,
devicetree, dri-devel, kunit-dev, open list:DOCUMENTATION,
linux-fsdevel, linux-kbuild, Linux Kernel Mailing List,
open list:KERNEL SELFTEST FRAMEWORK, linux-nvdimm, linux-um,
Sasha Levin, Bird, Timothy, Amir Goldstein, Dan Carpenter,
Daniel Vetter, Jeff Dike, Joel Stanley, Julia Lawall,
Kevin Hilman, Knut Omang, Logan Gunthorpe, Michael Ellerman,
Petr Mladek, Randy Dunlap, Richard Weinberger, David Rientjes,
Steven Rostedt, wfg
In-Reply-To: <CAAXuY3q1==RvAiw+gw5kfFJmjdR9JEUnnxou4Sv0POd88aD41w@mail.gmail.com>
> On Mon, Jul 8, 2019 at 4:16 PM Brendan Higgins <brendanhiggins@google.com> wrote:
>>
>> CC'ing Iurii Zaikin
>>
>> On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>> >
>> > On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote:
>> > > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section.
>> > >
>> > > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
>> > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> > > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
>> > > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>> >
>> > Come to think of it, I'd welcome Iurii to be added as a maintainer,
>> > with the hope Iurii would be up to review only the kunit changes. Of
>> > course if Iurii would be up to also help review future proc changes,
>> > even better. 3 pair of eyeballs is better than 2 pairs.
>>
>> What do you think, Iurii?
I'm in.
^ permalink raw reply
* Re: [PATCH v6 18/18] MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
From: Brendan Higgins @ 2019-07-08 23:15 UTC (permalink / raw)
To: Luis Chamberlain, Iurii Zaikin
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Peter Zijlstra, Rob Herring, Stephen Boyd, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190705204810.GE19023@42.do-not-panic.com>
CC'ing Iurii Zaikin
On Fri, Jul 5, 2019 at 1:48 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Wed, Jul 03, 2019 at 05:36:15PM -0700, Brendan Higgins wrote:
> > Add entry for the new proc sysctl KUnit test to the PROC SYSCTL section.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>
> Come to think of it, I'd welcome Iurii to be added as a maintainer,
> with the hope Iurii would be up to review only the kunit changes. Of
> course if Iurii would be up to also help review future proc changes,
> even better. 3 pair of eyeballs is better than 2 pairs.
What do you think, Iurii?
^ permalink raw reply
* [PATCH v4 2/8] of/platform: Add functional dependency link from DT bindings
From: Saravana Kannan @ 2019-07-08 22:56 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Greg Kroah-Hartman, Rafael J. Wysocki,
Frank Rowand, Jonathan Corbet
Cc: Saravana Kannan, devicetree, linux-kernel, David Collins,
kernel-team, linux-doc
In-Reply-To: <20190708225624.119973-1-saravanak@google.com>
Add device-links after the devices are created (but before they are
probed) by looking at common DT bindings like clocks and
interconnects.
Automatically adding device-links for functional dependencies at the
framework level provides the following benefits:
- Optimizes device probe order and avoids the useless work of
attempting probes of devices that will not probe successfully
(because their suppliers aren't present or haven't probed yet).
For example, in a commonly available mobile SoC, registering just
one consumer device's driver at an initcall level earlier than the
supplier device's driver causes 11 failed probe attempts before the
consumer device probes successfully. This was with a kernel with all
the drivers statically compiled in. This problem gets a lot worse if
all the drivers are loaded as modules without direct symbol
dependencies.
- Supplier devices like clock providers, interconnect providers, etc
need to keep the resources they provide active and at a particular
state(s) during boot up even if their current set of consumers don't
request the resource to be active. This is because the rest of the
consumers might not have probed yet and turning off the resource
before all the consumers have probed could lead to a hang or
undesired user experience.
Some frameworks (Eg: regulator) handle this today by turning off
"unused" resources at late_initcall_sync and hoping all the devices
have probed by then. This is not a valid assumption for systems with
loadable modules. Other frameworks (Eg: clock) just don't handle
this due to the lack of a clear signal for when they can turn off
resources. This leads to downstream hacks to handle cases like this
that can easily be solved in the upstream kernel.
By linking devices before they are probed, we give suppliers a clear
count of the number of dependent consumers. Once all of the
consumers are active, the suppliers can turn off the unused
resources without making assumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the link when they probe.
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
.../admin-guide/kernel-parameters.txt | 5 ++
drivers/of/platform.c | 57 +++++++++++++++++++
2 files changed, 62 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 138f6664b2e2..109b4310844f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3141,6 +3141,11 @@
This can be set from sysctl after boot.
See Documentation/sysctl/vm.txt for details.
+ of_devlink [KNL] Make device links from common DT bindings. Useful
+ for optimizing probe order and making sure resources
+ aren't turned off before the consumer devices have
+ probed.
+
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
See Documentation/debugging-via-ohci1394.txt for more
info.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 04ad312fd85b..0930f9f89571 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -509,6 +509,62 @@ int of_platform_default_populate(struct device_node *root,
}
EXPORT_SYMBOL_GPL(of_platform_default_populate);
+static int of_link_binding(struct device *dev,
+ const char *binding, const char *cell)
+{
+ struct of_phandle_args sup_args;
+ struct platform_device *sup_dev;
+ unsigned int i = 0, links = 0;
+ u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
+
+ while (!of_parse_phandle_with_args(dev->of_node, binding, cell, i,
+ &sup_args)) {
+ i++;
+ sup_dev = of_find_device_by_node(sup_args.np);
+ of_node_put(sup_args.np);
+ if (!sup_dev)
+ continue;
+ if (device_link_add(dev, &sup_dev->dev, dl_flags))
+ links++;
+ put_device(&sup_dev->dev);
+ }
+ if (links < i)
+ return -ENODEV;
+ return 0;
+}
+
+static bool of_devlink;
+core_param(of_devlink, of_devlink, bool, 0);
+
+/*
+ * List of bindings and their cell names (use NULL if no cell names) from which
+ * device links need to be created.
+ */
+static const char * const link_bindings[] = {
+ "clocks", "#clock-cells",
+ "interconnects", "#interconnect-cells",
+};
+
+static int of_link_to_suppliers(struct device *dev)
+{
+ unsigned int i = 0;
+ bool done = true;
+
+ if (!of_devlink)
+ return 0;
+ if (unlikely(!dev->of_node))
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(link_bindings) / 2; i++)
+ if (of_link_binding(dev, link_bindings[i * 2],
+ link_bindings[i * 2 + 1]))
+ done = false;
+
+ if (!done)
+ return -ENODEV;
+ return 0;
+}
+
#ifndef CONFIG_PPC
static const struct of_device_id reserved_mem_matches[] = {
{ .compatible = "qcom,rmtfs-mem" },
@@ -524,6 +580,7 @@ static int __init of_platform_default_populate_init(void)
if (!of_have_populated_dt())
return -ENODEV;
+ platform_bus_type.add_links = of_link_to_suppliers;
/*
* Handle certain compatibles explicitly, since we don't want to create
* platform_devices for every node in /reserved-memory with a
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [v1 5/5] arm64, kexec: reserve kexeckernel region
From: Pavel Tatashin @ 2019-07-08 21:15 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-doc, linux-arm-kernel
In-Reply-To: <20190708211528.12392-1-pasha.tatashin@soleen.com>
kexeckernel= is used to reserve memory for normal kexec kernel for
faster reboot.
Rename reserve_crashkernel() to reserve_crash_or_kexec_kernel(), and
generalize it by adding an argument that specifies what is reserved:
"crashkernel=" for crash kernel region
"kexeckernel=" for normal kexec region
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
.../admin-guide/kernel-parameters.txt | 10 +--
arch/arm64/kernel/setup.c | 5 ++
arch/arm64/mm/init.c | 83 ++++++++++++-------
3 files changed, 63 insertions(+), 35 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0f5ce665c7f5..a18222c1fbee 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -740,11 +740,11 @@
or memory reserved is below 4G.
kexeckernel=size[KMG][@offset[KMG]]
- [KNL] Using kexec, Linux can reboot to a new kernel.
- This parameter reserves the physical memory region
- [offset, offset + size] for that kernel. If '@offset' is
- omitted, then a suitable offset is selected
- automatically.
+ [KNL, ARM64] Using kexec, Linux can reboot to a new
+ kernel. This parameter reserves the physical memory
+ region [offset, offset + size] for that kernel. If
+ '@offset' is omitted, then a suitable offset is
+ selected automatically.
cryptomgr.notests
[KNL] Disable crypto self-tests
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 7e541f947b4c..9f308fa103c5 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -235,6 +235,11 @@ static void __init request_standard_resources(void)
if (crashk_res.end && crashk_res.start >= res->start &&
crashk_res.end <= res->end)
request_resource(res, &crashk_res);
+
+ /* Userspace will find "Kexec kernel" region in /proc/iomem. */
+ if (kexeck_res.end && kexeck_res.start >= res->start &&
+ kexeck_res.end <= res->end)
+ request_resource(res, &kexeck_res);
#endif
}
}
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f3c795278def..dfef39f72faf 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -54,61 +54,83 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
#ifdef CONFIG_KEXEC_CORE
/*
- * reserve_crashkernel() - reserves memory for crash kernel
+ * reserve_crash_or_kexec_kernel() - reserves memory for crash kernel or
+ * for normal kexec kernel.
*
- * This function reserves memory area given in "crashkernel=" kernel command
- * line parameter. The memory reserved is used by dump capture kernel when
- * primary kernel is crashing.
+ * This function reserves memory area given in "crashkernel=" or "kexeckenel="
+ * kernel command line parameter. The memory reserved is used by dump capture
+ * kernel when primary kernel is crashing, or to load new kexec kernel for
+ * faster reboot without relocation.
*/
-static void __init reserve_crashkernel(void)
+static void __init reserve_crash_or_kexec_kernel(char *cmd)
{
- unsigned long long crash_base, crash_size;
+ unsigned long long base, size;
+ struct resource *res;
+ char s[16];
int ret;
- ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
- &crash_size, &crash_base);
- /* no crashkernel= or invalid value specified */
- if (ret || !crash_size)
+ /* cmd must be either: "crashkernel=" or "kexeckernel=" */
+ if (!strcmp(cmd, "crashkernel=")) {
+ res = &crashk_res;
+ } else if (!strcmp(cmd, "kexeckernel=")) {
+ res = &kexeck_res;
+ } else {
+ pr_err("%s: invalid cmd %s\n", __func__, cmd);
+ return;
+ }
+
+ /* remove trailing '=' for a nicer printfs */
+ strcpy(s, cmd);
+ s[strlen(s) - 1] = '\0';
+
+ ret = parse_crash_or_kexec_kernel(boot_command_line,
+ memblock_phys_mem_size(),
+ &size, &base, cmd, NULL);
+ /* no specified command or invalid value specified */
+ if (ret || !size)
return;
- crash_size = PAGE_ALIGN(crash_size);
+ size = PAGE_ALIGN(size);
- if (crash_base == 0) {
+ if (base == 0) {
/* Current arm64 boot protocol requires 2MB alignment */
- crash_base = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT,
- crash_size, SZ_2M);
- if (crash_base == 0) {
- pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
- crash_size);
+ base = memblock_find_in_range(0, ARCH_LOW_ADDRESS_LIMIT,
+ size, SZ_2M);
+ if (base == 0) {
+ pr_warn("cannot allocate %s (size:0x%llx)\n",
+ s, size);
return;
}
} else {
/* User specifies base address explicitly. */
- if (!memblock_is_region_memory(crash_base, crash_size)) {
- pr_warn("cannot reserve crashkernel: region is not memory\n");
+ if (!memblock_is_region_memory(base, size)) {
+ pr_warn("cannot reserve %s: region is not memory\n",
+ s);
return;
}
- if (memblock_is_region_reserved(crash_base, crash_size)) {
- pr_warn("cannot reserve crashkernel: region overlaps reserved memory\n");
+ if (memblock_is_region_reserved(base, size)) {
+ pr_warn("cannot reserve %s: region overlaps reserved memory\n",
+ s);
return;
}
- if (!IS_ALIGNED(crash_base, SZ_2M)) {
- pr_warn("cannot reserve crashkernel: base address is not 2MB aligned\n");
+ if (!IS_ALIGNED(base, SZ_2M)) {
+ pr_warn("cannot reserve %s: base address is not 2MB aligned\n",
+ s);
return;
}
}
- memblock_reserve(crash_base, crash_size);
+ memblock_reserve(base, size);
- pr_info("crashkernel reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
- crash_base, crash_base + crash_size, crash_size >> 20);
+ pr_info("%s reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
+ s, base, base + size, size >> 20);
- crashk_res.start = crash_base;
- crashk_res.end = crash_base + crash_size - 1;
+ res->start = base;
+ res->end = base + size - 1;
}
#else
-static void __init reserve_crashkernel(void)
+static void __init reserve_crash_or_kexec_kernel(char *cmd)
{
}
#endif /* CONFIG_KEXEC_CORE */
@@ -411,7 +433,8 @@ void __init arm64_memblock_init(void)
else
arm64_dma_phys_limit = PHYS_MASK + 1;
- reserve_crashkernel();
+ reserve_crash_or_kexec_kernel("crashkernel=");
+ reserve_crash_or_kexec_kernel("kexeckernel=");
reserve_elfcorehdr();
--
2.22.0
^ permalink raw reply related
* [v1 4/5] kexec: use reserved memory for normal kexec reboot
From: Pavel Tatashin @ 2019-07-08 21:15 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-doc, linux-arm-kernel
In-Reply-To: <20190708211528.12392-1-pasha.tatashin@soleen.com>
If memory was reserved for the given segment use it directly instead of
allocating on per-page bases. This will avoid relocating this segment to
final destination when machine is rebooted.
This is done on a per segment bases because user might decide to always
load kernel segments at the given address (i.e. non-relocatable kernel),
but load initramfs at reserved address, and thus save reboot time on
copying initramfs if it is large, and reduces reboot performance.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
kernel/kexec_core.c | 39 ++++++++++++++++++++++++++-------------
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 932feadbeb3a..2a8d8746e0a1 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -154,6 +154,18 @@ static struct page *kimage_alloc_page(struct kimage *image,
gfp_t gfp_mask,
unsigned long dest);
+/* Check whether this segment is fully within the resource */
+static bool segment_is_reserved(struct kexec_segment *seg, struct resource *res)
+{
+ unsigned long mstart = seg->mem;
+ unsigned long mend = mstart + seg->memsz - 1;
+
+ if (mstart < phys_to_boot_phys(res->start) ||
+ mend > phys_to_boot_phys(res->end))
+ return false;
+ return true;
+}
+
int sanity_check_segment_list(struct kimage *image)
{
int i;
@@ -246,13 +258,9 @@ int sanity_check_segment_list(struct kimage *image)
if (image->type == KEXEC_TYPE_CRASH) {
for (i = 0; i < nr_segments; i++) {
- unsigned long mstart, mend;
-
- mstart = image->segment[i].mem;
- mend = mstart + image->segment[i].memsz - 1;
/* Ensure we are within the crash kernel limits */
- if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
- (mend > phys_to_boot_phys(crashk_res.end)))
+ if (!segment_is_reserved(&image->segment[i],
+ &crashk_res))
return -EADDRNOTAVAIL;
}
}
@@ -848,12 +856,13 @@ static int kimage_load_normal_segment(struct kimage *image,
return result;
}
-static int kimage_load_crash_segment(struct kimage *image,
- struct kexec_segment *segment)
+static int kimage_load_crash_or_reserved_segment(struct kimage *image,
+ struct kexec_segment *segment)
{
- /* For crash dumps kernels we simply copy the data from
- * user space to it's destination.
- * We do things a page at a time for the sake of kmap.
+ /*
+ * For crash dumps and kexec-reserved kernels we simply copy the data
+ * from user space to it's destination. We do things a page at a time
+ * for the sake of kmap.
*/
unsigned long maddr;
size_t ubytes, mbytes;
@@ -923,10 +932,14 @@ int kimage_load_segment(struct kimage *image,
switch (image->type) {
case KEXEC_TYPE_DEFAULT:
- result = kimage_load_normal_segment(image, segment);
+ if (segment_is_reserved(segment, &kexeck_res))
+ result = kimage_load_crash_or_reserved_segment(image,
+ segment);
+ else
+ result = kimage_load_normal_segment(image, segment);
break;
case KEXEC_TYPE_CRASH:
- result = kimage_load_crash_segment(image, segment);
+ result = kimage_load_crash_or_reserved_segment(image, segment);
break;
}
--
2.22.0
^ permalink raw reply related
* [v1 3/5] kexec: export common crashkernel/kexeckernel parser
From: Pavel Tatashin @ 2019-07-08 21:15 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-doc, linux-arm-kernel
In-Reply-To: <20190708211528.12392-1-pasha.tatashin@soleen.com>
To reserve memory for normal kexec reboot, the new parameter:
kexeckernel=size[KMG][@offset[KMG]] is used. Its syntax is the
same as craskernel=, therefore they can use the same function to
parse parameter settings.
Rename: __parse_crashkernel() to parse_crash_or_kexec_kernel(), and
make it public.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
.../admin-guide/kernel-parameters.txt | 7 +++++
include/linux/crash_core.h | 6 +++++
kernel/crash_core.c | 27 ++++++++++---------
3 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 5c7a0f5b0a2f..0f5ce665c7f5 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -739,6 +739,13 @@
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
+ kexeckernel=size[KMG][@offset[KMG]]
+ [KNL] Using kexec, Linux can reboot to a new kernel.
+ This parameter reserves the physical memory region
+ [offset, offset + size] for that kernel. If '@offset' is
+ omitted, then a suitable offset is selected
+ automatically.
+
cryptomgr.notests
[KNL] Disable crypto self-tests
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 525510a9f965..e90789ff0bec 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -74,5 +74,11 @@ int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
unsigned long long *crash_size, unsigned long long *crash_base);
+int parse_crash_or_kexec_kernel(char *cmdline,
+ unsigned long long system_ram,
+ unsigned long long *crash_size,
+ unsigned long long *crash_base,
+ const char *name,
+ const char *suffix);
#endif /* LINUX_CRASH_CORE_H */
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 9f1557b98468..11e0f9837a32 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -224,12 +224,12 @@ static __init char *get_last_crashkernel(char *cmdline,
return ck_cmdline;
}
-static int __init __parse_crashkernel(char *cmdline,
- unsigned long long system_ram,
- unsigned long long *crash_size,
- unsigned long long *crash_base,
- const char *name,
- const char *suffix)
+int __init parse_crash_or_kexec_kernel(char *cmdline,
+ unsigned long long system_ram,
+ unsigned long long *crash_size,
+ unsigned long long *crash_base,
+ const char *name,
+ const char *suffix)
{
char *first_colon, *first_space;
char *ck_cmdline;
@@ -270,8 +270,9 @@ int __init parse_crashkernel(char *cmdline,
unsigned long long *crash_size,
unsigned long long *crash_base)
{
- return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
- "crashkernel=", NULL);
+ return parse_crash_or_kexec_kernel(cmdline, system_ram, crash_size,
+ crash_base, "crashkernel=",
+ NULL);
}
int __init parse_crashkernel_high(char *cmdline,
@@ -279,8 +280,9 @@ int __init parse_crashkernel_high(char *cmdline,
unsigned long long *crash_size,
unsigned long long *crash_base)
{
- return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
- "crashkernel=", suffix_tbl[SUFFIX_HIGH]);
+ return parse_crash_or_kexec_kernel(cmdline, system_ram, crash_size,
+ crash_base, "crashkernel=",
+ suffix_tbl[SUFFIX_HIGH]);
}
int __init parse_crashkernel_low(char *cmdline,
@@ -288,8 +290,9 @@ int __init parse_crashkernel_low(char *cmdline,
unsigned long long *crash_size,
unsigned long long *crash_base)
{
- return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
- "crashkernel=", suffix_tbl[SUFFIX_LOW]);
+ return parse_crash_or_kexec_kernel(cmdline, system_ram, crash_size,
+ crash_base, "crashkernel=",
+ suffix_tbl[SUFFIX_LOW]);
}
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
--
2.22.0
^ permalink raw reply related
* [v1 2/5] kexec: add resource for normal kexec region
From: Pavel Tatashin @ 2019-07-08 21:15 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-doc, linux-arm-kernel
In-Reply-To: <20190708211528.12392-1-pasha.tatashin@soleen.com>
crashk_res resource is used to reserve memory for crash kernel. There is
also, however, a benefit to reserve memory for normal kernel to speed up
reboot performance. This is because during regular kexec reboot, kernel
performs relocations to the final destination of the loaded segments, and
the relocation might take a long time especially if initramfs is big.
Therefore, similarly to crashk_res, add kexeck_res that will be used to
reserve memory for normal kexec kernel.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
---
include/linux/ioport.h | 1 +
include/linux/kexec.h | 6 ++++--
kernel/kexec_core.c | 9 +++++++++
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index da0ebaec25f0..3b18a3c112f3 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -133,6 +133,7 @@ enum {
IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
IORES_DESC_DEVICE_PRIVATE_MEMORY = 6,
IORES_DESC_DEVICE_PUBLIC_MEMORY = 7,
+ IORES_DESC_KEXEC_KERNEL = 8,
};
/* helpers to define resources */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index b9b1bc5f9669..4c1121b385fb 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -303,12 +303,14 @@ extern int kexec_load_disabled;
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
-/* Location of a reserved region to hold the crash kernel.
- */
+/* Location of a reserved region to hold the crash kernel. */
extern struct resource crashk_res;
extern struct resource crashk_low_res;
extern note_buf_t __percpu *crash_notes;
+/* Location of a reserved region to hold normal kexec kernel. */
+extern struct resource kexeck_res;
+
/* flag to track if kexec reboot is in progress */
extern bool kexec_in_progress;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 2c5b72863b7b..932feadbeb3a 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -70,6 +70,15 @@ struct resource crashk_low_res = {
.desc = IORES_DESC_CRASH_KERNEL
};
+/* Location of the reserved area for the normal kexec kernel */
+struct resource kexeck_res = {
+ .name = "Kexec kernel",
+ .start = 0,
+ .end = 0,
+ .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
+ .desc = IORES_DESC_KEXEC_KERNEL
+};
+
int kexec_should_crash(struct task_struct *p)
{
/*
--
2.22.0
^ permalink raw reply related
* [v1 1/5] kexec: quiet down kexec reboot
From: Pavel Tatashin @ 2019-07-08 21:15 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-doc, linux-arm-kernel
In-Reply-To: <20190708211528.12392-1-pasha.tatashin@soleen.com>
Here is a regular kexec command sequence and output:
=====
$ kexec --reuse-cmdline -i --load Image
$ kexec -e
[ 161.342002] kexec_core: Starting new kernel
Welcome to Buildroot
buildroot login:
=====
Even when "quiet" kernel parameter is specified, "kexec_core: Starting
new kernel" is printed.
This message has KERN_EMERG level, but there is no emergency, it is a
normal kexec operation, so quiet it down to appropriate KERN_NOTICE.
Machines that have slow console baud rate benefit from less output.
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
---
kernel/kexec_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index d5870723b8ad..2c5b72863b7b 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1169,7 +1169,7 @@ int kernel_kexec(void)
* CPU hotplug again; so re-enable it here.
*/
cpu_hotplug_enable();
- pr_emerg("Starting new kernel\n");
+ pr_notice("Starting new kernel\n");
machine_shutdown();
}
--
2.22.0
^ permalink raw reply related
* [v1 0/5] allow to reserve memory for normal kexec kernel
From: Pavel Tatashin @ 2019-07-08 21:15 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-doc, linux-arm-kernel
Currently, it is only allowed to reserve memory for crash kernel, because
it is a requirement in order to be able to boot into crash kernel without
touching memory of crashed kernel is to have memory reserved.
The second benefit for having memory reserved for kexec kernel is
that it does not require a relocation after segments are loaded into
memory.
If kexec functionality is used for a fast system update, with a minimal
downtime, the relocation of kernel + initramfs might take a significant
portion of reboot.
In fact, on the machine that we are using, that has ARM64 processor
it takes 0.35s to relocate during kexec, thus taking 52% of kernel reboot
time:
kernel shutdown 0.03s
relocation 0.35s
kernel startup 0.29s
Image: 13M and initramfs is 24M. If initramfs increases, the relocation
time increases proportionally.
While, it is possible to add 'kexeckernel=' parameters support to other
architectures by modifying reserve_crashkernel(), in this series this is
done for arm64 only.
Pavel Tatashin (5):
kexec: quiet down kexec reboot
kexec: add resource for normal kexec region
kexec: export common crashkernel/kexeckernel parser
kexec: use reserved memory for normal kexec reboot
arm64, kexec: reserve kexeckernel region
.../admin-guide/kernel-parameters.txt | 7 ++
arch/arm64/kernel/setup.c | 5 ++
arch/arm64/mm/init.c | 83 ++++++++++++-------
include/linux/crash_core.h | 6 ++
include/linux/ioport.h | 1 +
include/linux/kexec.h | 6 +-
kernel/crash_core.c | 27 +++---
kernel/kexec_core.c | 50 +++++++----
8 files changed, 127 insertions(+), 58 deletions(-)
--
2.22.0
^ permalink raw reply
* [PATCH] Documentation: gpio: fix function links in the HTML docs
From: Jeremy Cline @ 2019-07-08 21:11 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet
Cc: linux-gpio, linux-doc, linux-kernel, Jeremy Cline
The shorthand [_data] and [devm_] cause the HTML documentation to not
link to the function documentation properly. This expands the references
to the complete function names with the exception of
devm_gpiochip_remove() which was dropped by commit 48207d7595d2 ("gpio:
drop devm_gpiochip_remove()").
Signed-off-by: Jeremy Cline <jcline@redhat.com>
---
Documentation/driver-api/gpio/driver.rst | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
index 1ce7fcd0f989..d4197ea3dafb 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -69,9 +69,9 @@ driver code:
The code implementing a gpio_chip should support multiple instances of the
controller, preferably using the driver model. That code will configure each
-gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
-Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
-when it is unavoidable.
+gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
+devm_gpiochip_add_data(). Removing a GPIO controller should be rare; use
+gpiochip_remove() when it is unavoidable.
Often a gpio_chip is part of an instance-specific structure with states not
exposed by the GPIO interfaces, such as addressing, power management, and more.
@@ -418,11 +418,11 @@ symbol:
If there is a need to exclude certain GPIO lines from the IRQ domain handled by
these helpers, we can set .irq.need_valid_mask of the gpiochip before
-[devm_]gpiochip_add_data() is called. This allocates an .irq.valid_mask with as
-many bits set as there are GPIO lines in the chip, each bit representing line
-0..n-1. Drivers can exclude GPIO lines by clearing bits from this mask. The mask
-must be filled in before gpiochip_irqchip_add() or gpiochip_irqchip_add_nested()
-is called.
+devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
+.irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
+bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
+from this mask. The mask must be filled in before gpiochip_irqchip_add() or
+gpiochip_irqchip_add_nested() is called.
To use the helpers please keep the following in mind:
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] tpm: Document UEFI event log quirks
From: Matthew Garrett @ 2019-07-08 20:43 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Linux Kernel Mailing List, linux-integrity, linux-doc,
Thiébaud Weksteen, Jonathan Corbet
In-Reply-To: <20190703161109.22935-1-jarkko.sakkinen@linux.intel.com>
On Wed, Jul 3, 2019 at 9:11 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
> +Before calling ExitBootServices() Linux EFI stub copies the event log to
> +a custom configuration table defined by the stub itself. Unfortanely,
> +the events generated by ExitBootServices() do end up to the table.
"Unfortunately, the events generated by ExitBootServices() occur after
this and don't end up in the table"?
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-07-08 20:40 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Peter Zijlstra, Rob Herring, Stephen Boyd, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <CAFd5g45cF9rYc8YupnCgd=7xz_yW+_TMp_L+cSFUBW7d9njnVQ@mail.gmail.com>
On Mon, Jul 8, 2019 at 11:08 AM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> On Fri, Jul 5, 2019 at 1:15 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> >
> > On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> > > Add core facilities for defining unit tests; this provides a common way
> > > to define test cases, functions that execute code which is under test
> > > and determine whether the code under test behaves as expected; this also
> > > provides a way to group together related test cases in test suites (here
> > > we call them test_modules).
> > >
> > > Just define test cases and how to execute them for now; setting
> > > expectations on code will be defined later.
> > >
> > > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> >
> > Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> >
> > But a nitpick below, I think that can be fixed later with a follow up
> > patch.
> >
> > > +/**
> > > + * struct kunit - represents a running instance of a test.
> > > + * @priv: for user to store arbitrary data. Commonly used to pass data created
> > > + * in the init function (see &struct kunit_suite).
> > > + *
> > > + * Used to store information about the current context under which the test is
> > > + * running. Most of this data is private and should only be accessed indirectly
> > > + * via public functions; the one exception is @priv which can be used by the
> > > + * test writer to store arbitrary data.
> > > + *
> > > + * A brief note on locking:
> > > + *
> > > + * First off, we need to lock because in certain cases a user may want to use an
> > > + * expectation in a thread other than the thread that the test case is running
> > > + * in.
> >
> > This as a prefix to the struct without a lock seems odd. It would be
> > clearer I think if you'd explain here what locking mechanism we decided
> > to use and why it suffices today.
>
> Whoops, sorry this should have been in the next patch. Will fix.
Err..no, this shouldn't be here at all. Sorry about that. I just need
to rewrite the comment.
> > > +/**
> > > + * suite_test() - used to register a &struct kunit_suite with KUnit.
> >
> > You mean kunit_test_suite()?
>
> Yep, sorry about that. Will fix.
>
> > > + * @suite: a statically allocated &struct kunit_suite.
> > > + *
> > > + * Registers @suite with the test framework. See &struct kunit_suite for more
> > > + * information.
> > > + *
> > > + * NOTE: Currently KUnit tests are all run as late_initcalls; this means that
> > > + * they cannot test anything where tests must run at a different init phase. One
> > > + * significant restriction resulting from this is that KUnit cannot reliably
> > > + * test anything that is initialize in the late_init phase.
> > initialize prior to the late init phase.
> >
> >
> > That is, this is useless to test things running early.
>
> Yeah, I can add that phrasing in.
>
> > > + *
> > > + * TODO(brendanhiggins@google.com): Don't run all KUnit tests as late_initcalls.
> > > + * I have some future work planned to dispatch all KUnit tests from the same
> > > + * place, and at the very least to do so after everything else is definitely
> > > + * initialized.
> >
> > TODOs are odd to be adding to documentation, this is just not common
> > place practice. The NOTE should suffice for you.
>
> Because it is a kernel doc? Would you usually make a separate
> non-kernel doc comment for a TODO? I guess that makes sense.
>
> Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] Documentation: virtual: Add toctree hooks
From: Luke Nowakowski-Krijger @ 2019-07-08 20:28 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-kernel-mentees, pbonzini, rkrcmar, kvm, linux-doc,
linux-kernel
In-Reply-To: <20190708135404.3eeed68f@lwn.net>
On Mon, Jul 08, 2019 at 01:54:04PM -0600, Jonathan Corbet wrote:
> On Sat, 6 Jul 2019 14:38:13 -0700
> Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> wrote:
>
> At this point in the patch series, the above-mentioned RST files don't
> exist. So if somebody tries to build the docs here, the build will fail.
> I suspect that it's pretty rare for people to use bisection with docs
> builds, but it's still proper practice to ensure that things work at every
> step in your series. So the above entries should be added in the patches
> that convert the files.
>
Yes, agreed. It should be at the end of the series.
> Also, vcpu-requests.txt is never touched in this patch series, which
> suggests that you didn't build the docs even at the end of it.
>
In the staging tree I was doing work out of I saw a vcpu-requests.rst
file so thought I could add it "while I'm here".
You're right. I should only add the files I am converting.
> Thanks,
>
> jon
Thanks again,
- Luke
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: kvm: Convert cpuid.txt to .rst
From: Jonathan Corbet @ 2019-07-08 20:20 UTC (permalink / raw)
To: Luke Nowakowski-Krijger
Cc: linux-kernel-mentees, pbonzini, rkrcmar, kvm, linux-doc,
linux-kernel
In-Reply-To: <20190708201510.GA13296@luke-XPS-13>
On Mon, 8 Jul 2019 13:15:10 -0700
Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> wrote:
> > > +:Author: Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
> >
> > I rather suspect that email address doesn't work these days.
> >
>
> No I guess it wont :). We would still keep this correct?
There's nothing good that will come from keeping a broken email address
there. You could either:
- Just take the address out, or
- Track Glauber down and get a newer address; you could ask him about the
licensing while you're at it :)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v1 1/2] Documentation/filesystems: add binderfs
From: Jonathan Corbet @ 2019-07-08 20:16 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Christian Brauner, linux-doc, linux-kernel
In-Reply-To: <20190702175729.GF1729@bombadil.infradead.org>
On Tue, 2 Jul 2019 10:57:29 -0700
Matthew Wilcox <willy@infradead.org> wrote:
> I think you added it in the wrong place.
>
> From 8167b80c950834da09a9204b6236f238197c197b Mon Sep 17 00:00:00 2001
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> Date: Tue, 2 Jul 2019 13:54:38 -0400
> Subject: [PATCH] docs: Move binderfs to admin-guide
>
> The documentation is more appropriate for the administrator than for
> the internal kernel API section it is currently in.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Fine...applied...
jon
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: kvm: Convert cpuid.txt to .rst
From: Luke Nowakowski-Krijger @ 2019-07-08 20:15 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-kernel-mentees, pbonzini, rkrcmar, kvm, linux-doc,
linux-kernel
In-Reply-To: <20190708140022.5fa9d01f@lwn.net>
On Mon, Jul 08, 2019 at 02:00:22PM -0600, Jonathan Corbet wrote:
> On Sat, 6 Jul 2019 14:38:14 -0700
> Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> wrote:
>
> > From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
> >
> > Convert cpuid.txt to .rst format to be parsable by sphinx.
> >
> > Change format and spacing to make function definitions and return values
> > much more clear. Also added a table that is parsable by sphinx and makes
> > the information much more clean.
> >
> > Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
> > ---
> > Documentation/virtual/kvm/cpuid.rst | 99 +++++++++++++++++++++++++++++
> > Documentation/virtual/kvm/cpuid.txt | 83 ------------------------
> > 2 files changed, 99 insertions(+), 83 deletions(-)
> > create mode 100644 Documentation/virtual/kvm/cpuid.rst
> > delete mode 100644 Documentation/virtual/kvm/cpuid.txt
> >
> > diff --git a/Documentation/virtual/kvm/cpuid.rst b/Documentation/virtual/kvm/cpuid.rst
> > new file mode 100644
> > index 000000000000..1a03336a500e
> > --- /dev/null
> > +++ b/Documentation/virtual/kvm/cpuid.rst
> > @@ -0,0 +1,99 @@
> > +.. SPDX-License-Identifier: GPL-2.0
>
> Do you know that this is the appropriate license for this file? If so, you
> should say how you know that. I appreciate that you thought to add the
> SPDX line, but we have to be sure that it actually matches the intent of
> the creator of this file.
>
I do not know what the authors intent was. You are right. This is not my
work after all. Ill remove it in the next version.
> > +==============
> > +KVM CPUID bits
> > +==============
> > +
> > +:Author: Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
>
> I rather suspect that email address doesn't work these days.
>
No I guess it wont :). We would still keep this correct?
> > +A guest running on a kvm host, can check some of its features using
> > +cpuid. This is not always guaranteed to work, since userspace can
> > +mask-out some, or even all KVM-related cpuid features before launching
> > +a guest.
> > +
> > +KVM cpuid functions are:
> > +
> > +function: **KVM_CPUID_SIGNATURE (0x40000000)**
>
> I wouldn't add the **markup** here, it doesn't really help.
>
My intent was to make the "function" part more readable immediately
because otherwise it sort of looks like a wall of text. I might have
gotten a little too fancy here though.
> > +
> > +returns::
> > +
> > + eax = 0x40000001
> > + ebx = 0x4b4d564b
> > + ecx = 0x564b4d56
> > + edx = 0x4d
> > +
> > +Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM".
> > +The value in eax corresponds to the maximum cpuid function present in this leaf,
> > +and will be updated if more functions are added in the future.
> > +Note also that old hosts set eax value to 0x0. This should
> > +be interpreted as if the value was 0x40000001.
> > +This function queries the presence of KVM cpuid leafs.
> > +
> > +function: **define KVM_CPUID_FEATURES (0x40000001)**
> > +
> > +returns::
> > +
> > + ebx, ecx
> > + eax = an OR'ed group of (1 << flag)
> > +
> > +where ``flag`` is defined as below:
> > +
> > ++--------------------------------+------------+---------------------------------+
> > +| flag | value | meaning |
> > ++================================+============+=================================+
> > +| KVM_FEATURE_CLOCKSOURCE | 0 | kvmclock available at msrs |
> > +| | | 0x11 and 0x12 |
>
> You might consider using the
>
> ======= ===== ======
> simpler table format
> ======= ===== ======
>
> here, it might be a bit easier to read and maintain.
>
Understood.
> Thanks,
>
> jon
Thanks for the review,
- Luke
^ permalink raw reply
* Re: [PATCH] Documentation: coresight: covert txt to rst
From: Jonathan Corbet @ 2019-07-08 20:09 UTC (permalink / raw)
To: Phong Tran
Cc: mathieu.poirier, suzuki.poulose, skhan, mchehab, linux-arm-kernel,
linux-doc, linux-kernel, linux-kernel-mentees
In-Reply-To: <20190705204512.15444-1-tranmanphong@gmail.com>
On Sat, 6 Jul 2019 03:45:12 +0700
Phong Tran <tranmanphong@gmail.com> wrote:
> change the format file and adpate the text style
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> ---
> .../trace/{coresight.txt => coresight.rst} | 296 ++++++++++++---------
> Documentation/trace/index.rst | 1 +
> 2 files changed, 167 insertions(+), 130 deletions(-)
> rename Documentation/trace/{coresight.txt => coresight.rst} (59%)
>
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
> similarity index 59%
> rename from Documentation/trace/coresight.txt
> rename to Documentation/trace/coresight.rst
> index efbc832146e7..bea24e70cfba 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.rst
> @@ -1,5 +1,6 @@
> - Coresight - HW Assisted Tracing on ARM
> - ======================================
> +======================================
> +Coresight - HW Assisted Tracing on ARM
> +======================================
>
> Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> Date: September 11th, 2014
> @@ -26,7 +27,7 @@ implementation, either storing the compressed stream in a memory buffer or
> creating an interface to the outside world where data can be transferred to a
> host without fear of filling up the onboard coresight memory buffer.
>
> -At typical coresight system would look like this:
> +At typical coresight system would look like this::
>
> *****************************************************************
> **************************** AMBA AXI ****************************===||
> @@ -95,6 +96,7 @@ Acronyms and Classification
>
> Acronyms:
>
> +======== =============================================================
> PTM: Program Trace Macrocell
> ETM: Embedded Trace Macrocell
> STM: System trace Macrocell
> @@ -104,6 +106,7 @@ TPIU: Trace Port Interface Unit
> TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
> TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
> CTI: Cross Trigger Interface
> +======== =============================================================
A minor nit, but since you're making a table out of this, you don't need
the colons in the first column.
> Classification:
>
> @@ -118,7 +121,7 @@ Misc:
>
>
> Device Tree Bindings
> -----------------------
> +--------------------
>
> See Documentation/devicetree/bindings/arm/coresight.txt for details.
>
> @@ -133,57 +136,63 @@ The coresight framework provides a central point to represent, configure and
> manage coresight devices on a platform. Any coresight compliant device can
> register with the framework for as long as they use the right APIs:
>
> -struct coresight_device *coresight_register(struct coresight_desc *desc);
> -void coresight_unregister(struct coresight_device *csdev);
> +.. c:function:: struct coresight_device *coresight_register(struct coresight_desc *desc);
> +.. c:function:: void coresight_unregister(struct coresight_device *csdev);
>
> -The registering function is taking a "struct coresight_device *csdev" and
> +The registering function is taking a :code:`struct coresight_device *csdev` and
As a general rule, we would rather see less markup in the text files than
you are applying here. Just present the prototypes in a literal block
here. (Even better would be a nice kerneldoc comment in the source that
could be pulled in, but that's more work). I wouldn't use :code: anywhere,
really.
As well as addressing Mathieu's comments, could you pass through and cut
the markup down to the bare minimum?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2] kbuild: get rid of misleading $(AS) from documents
From: Jonathan Corbet @ 2019-07-08 20:02 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Sam Ravnborg, linux-doc, linux-kernel, Michal Marek
In-Reply-To: <20190706162508.8529-1-yamada.masahiro@socionext.com>
On Sun, 7 Jul 2019 01:25:08 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> The assembler files in the kernel are *.S instead of *.s, so they must
> be preprocessed. Since 'as' of GNU binutils is not able to preprocess,
> we always use $(CC) as an assembler driver.
>
> $(AS) is almost unused in Kbuild. As of writing, there is just one place
> that directly invokes $(AS).
>
> $ git grep -e '$(AS)' -e '${AS}' -e '$AS' -e '$(AS:' -e '${AS:' -- :^Documentation
> drivers/net/wan/Makefile: AS68K = $(AS)
>
> The documentation about *_AFLAGS* sounds like the flags were passed
> to $(AS). This is somewhat misleading.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Would you like me to send this up through the docs tree?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 2/3] Documentation: kvm: Convert cpuid.txt to .rst
From: Jonathan Corbet @ 2019-07-08 20:00 UTC (permalink / raw)
To: Luke Nowakowski-Krijger
Cc: linux-kernel-mentees, pbonzini, rkrcmar, kvm, linux-doc,
linux-kernel
In-Reply-To: <e8cd24f40cdd23ed116679f4c3cfcf8849879bb4.1562448500.git.lnowakow@eng.ucsd.edu>
On Sat, 6 Jul 2019 14:38:14 -0700
Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> wrote:
> From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
>
> Convert cpuid.txt to .rst format to be parsable by sphinx.
>
> Change format and spacing to make function definitions and return values
> much more clear. Also added a table that is parsable by sphinx and makes
> the information much more clean.
>
> Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
> ---
> Documentation/virtual/kvm/cpuid.rst | 99 +++++++++++++++++++++++++++++
> Documentation/virtual/kvm/cpuid.txt | 83 ------------------------
> 2 files changed, 99 insertions(+), 83 deletions(-)
> create mode 100644 Documentation/virtual/kvm/cpuid.rst
> delete mode 100644 Documentation/virtual/kvm/cpuid.txt
>
> diff --git a/Documentation/virtual/kvm/cpuid.rst b/Documentation/virtual/kvm/cpuid.rst
> new file mode 100644
> index 000000000000..1a03336a500e
> --- /dev/null
> +++ b/Documentation/virtual/kvm/cpuid.rst
> @@ -0,0 +1,99 @@
> +.. SPDX-License-Identifier: GPL-2.0
Do you know that this is the appropriate license for this file? If so, you
should say how you know that. I appreciate that you thought to add the
SPDX line, but we have to be sure that it actually matches the intent of
the creator of this file.
> +==============
> +KVM CPUID bits
> +==============
> +
> +:Author: Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
I rather suspect that email address doesn't work these days.
> +A guest running on a kvm host, can check some of its features using
> +cpuid. This is not always guaranteed to work, since userspace can
> +mask-out some, or even all KVM-related cpuid features before launching
> +a guest.
> +
> +KVM cpuid functions are:
> +
> +function: **KVM_CPUID_SIGNATURE (0x40000000)**
I wouldn't add the **markup** here, it doesn't really help.
> +
> +returns::
> +
> + eax = 0x40000001
> + ebx = 0x4b4d564b
> + ecx = 0x564b4d56
> + edx = 0x4d
> +
> +Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM".
> +The value in eax corresponds to the maximum cpuid function present in this leaf,
> +and will be updated if more functions are added in the future.
> +Note also that old hosts set eax value to 0x0. This should
> +be interpreted as if the value was 0x40000001.
> +This function queries the presence of KVM cpuid leafs.
> +
> +function: **define KVM_CPUID_FEATURES (0x40000001)**
> +
> +returns::
> +
> + ebx, ecx
> + eax = an OR'ed group of (1 << flag)
> +
> +where ``flag`` is defined as below:
> +
> ++--------------------------------+------------+---------------------------------+
> +| flag | value | meaning |
> ++================================+============+=================================+
> +| KVM_FEATURE_CLOCKSOURCE | 0 | kvmclock available at msrs |
> +| | | 0x11 and 0x12 |
You might consider using the
======= ===== ======
simpler table format
======= ===== ======
here, it might be a bit easier to read and maintain.
Thanks,
jon
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Christoph Hellwig @ 2019-07-08 20:00 UTC (permalink / raw)
To: Sheriff Esseson
Cc: skhan, darrick.wong, linux-xfs, corbet, linux-doc, linux-kernel,
linux-kernel-mentees
In-Reply-To: <20190705131446.GA10045@localhost>
The subjet line seems to be a bit messed up.
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Doc : fs : move xfs.txt to admin-guide
From: Matthew Wilcox @ 2019-07-08 19:59 UTC (permalink / raw)
To: Sheriff Esseson
Cc: linux-kernel-mentees, darrick.wong, linux-xfs, corbet, linux-doc
In-Reply-To: <20190705193329.GA20933@localhost>
On Fri, Jul 05, 2019 at 08:41:48PM +0100, Sheriff Esseson wrote:
> On Fri, Jul 05, 2019 at 12:04:12PM -0700, Matthew Wilcox wrote:
> > On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> > > As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
> > > options when setting up an XFS. This makes it appropriate to be placed under
> > > the admin-guide tree.
> > >
> > > Thus, move xfs.txt to admin-guide and fix broken references.
> >
> > What happened to the conversion to xfs.rst?
>
> Okay, I was thinking placing the file properly should come first before the
> conversion.
But if you move it, then rename it, you have to change all these places
again. The minimal conversion you did the first time was quite a nice diff
to read.
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Documentation: filesystems: Convert jfs.txt to reStructedText format.
From: Matthew Wilcox @ 2019-07-08 19:57 UTC (permalink / raw)
To: Shobhit Kukreti
Cc: Jonathan Corbet, skhan, linux-kernel-mentees, linux-doc,
linux-kernel
In-Reply-To: <20190706232236.GA24717@t-1000>
On Sat, Jul 06, 2019 at 04:22:39PM -0700, Shobhit Kukreti wrote:
> +++ b/Documentation/filesystems/index.rst
> @@ -41,3 +41,4 @@ Documentation for individual filesystem types can be found here.
> :maxdepth: 2
>
> binderfs.rst
> + jfs
This is the wrong place for this file. See earlier conversation with
Sheriff Esseson, and the patch from me to move binderfs.
> diff --git a/Documentation/filesystems/jfs.rst b/Documentation/filesystems/jfs.rst
> new file mode 100644
> index 0000000..bfb6110
> --- /dev/null
> +++ b/Documentation/filesystems/jfs.rst
Why is git not detecting this as (mostly) a rename?
^ permalink raw reply
* Re: [PATCH 1/3] Documentation: virtual: Add toctree hooks
From: Jonathan Corbet @ 2019-07-08 19:54 UTC (permalink / raw)
To: Luke Nowakowski-Krijger
Cc: linux-kernel-mentees, pbonzini, rkrcmar, kvm, linux-doc,
linux-kernel
In-Reply-To: <ef1edb15bd6a6ef87abf4fef7636cd9213450e3c.1562448500.git.lnowakow@eng.ucsd.edu>
On Sat, 6 Jul 2019 14:38:13 -0700
Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> wrote:
> From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
>
> Added toctree hooks for indexing. Hooks added only for newly added files
> or already existing files.
>
> The hook for the top of the tree will be added in a later patch series
> when a few more substantial changes have been added.
>
> Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
> ---
> Documentation/virtual/index.rst | 18 ++++++++++++++++++
> Documentation/virtual/kvm/index.rst | 12 ++++++++++++
> 2 files changed, 30 insertions(+)
> create mode 100644 Documentation/virtual/index.rst
> create mode 100644 Documentation/virtual/kvm/index.rst
>
> diff --git a/Documentation/virtual/index.rst b/Documentation/virtual/index.rst
> new file mode 100644
> index 000000000000..19c9fa2266f4
> --- /dev/null
> +++ b/Documentation/virtual/index.rst
> @@ -0,0 +1,18 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===========================
> +Linux Virtual Documentation
> +===========================
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + kvm/index
> + paravirt_ops
> +
> +.. only:: html and subproject
> +
> + Indices
> + =======
> +
> + * :ref:`genindex`
> diff --git a/Documentation/virtual/kvm/index.rst b/Documentation/virtual/kvm/index.rst
> new file mode 100644
> index 000000000000..ada224a511fe
> --- /dev/null
> +++ b/Documentation/virtual/kvm/index.rst
> @@ -0,0 +1,12 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===
> +KVM
> +===
> +
> +.. toctree::
> + :maxdepth: 2
> +
> + amd-memory-encryption
> + cpuid
> + vcpu-requests
At this point in the patch series, the above-mentioned RST files don't
exist. So if somebody tries to build the docs here, the build will fail.
I suspect that it's pretty rare for people to use bisection with docs
builds, but it's still proper practice to ensure that things work at every
step in your series. So the above entries should be added in the patches
that convert the files.
Also, vcpu-requests.txt is never touched in this patch series, which
suggests that you didn't build the docs even at the end of it.
Thanks,
jon
^ permalink raw reply
* Re: [Linux-kernel-mentees] [PATCH] Documentation: filesystems: Convert jfs.txt to reStructedText format.
From: Jonathan Corbet @ 2019-07-08 19:47 UTC (permalink / raw)
To: Shobhit Kukreti; +Cc: skhan, linux-kernel-mentees, linux-doc, linux-kernel
In-Reply-To: <20190706232236.GA24717@t-1000>
On Sat, 6 Jul 2019 16:22:39 -0700
Shobhit Kukreti <shobhitkukreti@gmail.com> wrote:
> This converts the plain text documentation of jfs.txt to reStructuredText format.
> Added to documentation build process and verified with make htmldocs
>
> Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
Thanks for working to make the kernel documentation better. That said, I
do have a request...
> ---
> Documentation/filesystems/index.rst | 1 +
> Documentation/filesystems/jfs.rst | 74 +++++++++++++++++++++++++++++++++++++
> Documentation/filesystems/jfs.txt | 52 --------------------------
> 3 files changed, 75 insertions(+), 52 deletions(-)
> create mode 100644 Documentation/filesystems/jfs.rst
> delete mode 100644 Documentation/filesystems/jfs.txt
>
> diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
> index 1131c34..d700330 100644
> --- a/Documentation/filesystems/index.rst
> +++ b/Documentation/filesystems/index.rst
> @@ -41,3 +41,4 @@ Documentation for individual filesystem types can be found here.
> :maxdepth: 2
>
> binderfs.rst
> + jfs
> diff --git a/Documentation/filesystems/jfs.rst b/Documentation/filesystems/jfs.rst
> new file mode 100644
> index 0000000..bfb6110
> --- /dev/null
> +++ b/Documentation/filesystems/jfs.rst
> @@ -0,0 +1,74 @@
> +===========================================
> +IBM's Journaled File System (JFS) for Linux
> +===========================================
> +
> +JFS Homepage: http://jfs.sourceforge.net/
> +
> +Following Mount Options are Supported
> +
> +(*) == default
> + .. tabularcolumns:: |p{1.3cm}|p{1.3cm}|p{8.0cm}|
> +
> +.. cssclass:: longtable
> +
> +.. flat-table::
> + :header-rows: 0
> + :stub-columns: 0
Please don't use flat-table unless you really need to. It makes the
documents harder to read in plain-text form, which is something we want to
avoid whenever possible. A simple definition list seems more appropriate
for this information.
(I should really update the documentation to discourage use of flat-table).
Note that the merge window is open, so expect me to be even slower than
usual to respond to things for the next couple of weeks.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v6 01/18] kunit: test: add KUnit test runner core
From: Brendan Higgins @ 2019-07-08 18:12 UTC (permalink / raw)
To: Luis Chamberlain
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Peter Zijlstra, Rob Herring, Stephen Boyd, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190705202051.GB19023@42.do-not-panic.com>
On Fri, Jul 5, 2019 at 1:20 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
>
> On Wed, Jul 03, 2019 at 05:35:58PM -0700, Brendan Higgins wrote:
> > +struct kunit {
> > + void *priv;
> > +
> > + /* private: internal use only. */
> > + const char *name; /* Read only after initialization! */
> > + bool success; /* Read only after test_case finishes! */
> > +};
>
> No lock attribute above.
>
> > +void kunit_init_test(struct kunit *test, const char *name)
> > +{
> > + spin_lock_init(&test->lock);
> > + test->name = name;
> > + test->success = true;
> > +}
>
> And yet here you initialize a spin lock... This won't compile. Seems
> you forgot to remove this line. So I guess a re-spin is better.
Oh crap, sorry about that. You can't compile these patches until the
kbuild patch. I will fix this and make sure I didn't make any similar
mistakes on these early patches.
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox