* [PATCH] modify one dead link
From: Dongliang Mu @ 2018-03-20 14:54 UTC (permalink / raw)
To: corbet, yamada.masahiro, slyfox, tony.luck, bjorn.forsman,
mudongliangabcd
Cc: linux-doc, linux-kernel
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
---
Documentation/ia64/xen.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/ia64/xen.txt b/Documentation/ia64/xen.txt
index a12c74ce2773..aea4bb94aa59 100644
--- a/Documentation/ia64/xen.txt
+++ b/Documentation/ia64/xen.txt
@@ -26,7 +26,7 @@ Getting and Building Xen and Dom0
DomainU OS : RHEL5
1. Download source
- # hg clone http://xenbits.xensource.com/ext/ia64/xen-unstable.hg
+ # hg clone http://xenbits.xensource.com/ext/ia64/xen-unstable
# cd xen-unstable.hg
# hg clone http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
--
2.16.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 1/2] cpuset: Enable cpuset controller in default hierarchy
From: Waiman Long @ 2018-03-20 13:51 UTC (permalink / raw)
To: Tejun Heo
Cc: Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar, cgroups,
linux-kernel, linux-doc, kernel-team, pjt, luto, efault, torvalds,
Roman Gushchin
In-Reply-To: <20180319155937.GQ2943022@devbig577.frc2.facebook.com>
On 03/19/2018 11:59 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> This looks great. A couple nitpicks below.
>
>> + 5-3. Cpuset
>> + 5.3-1. Cpuset Interface Files
> Can we put cpuset below pid? It feels weird to break up cpu, memory
> and io as they represent the three major resources and are in a
> similar fashion.
Sure. I will move it down below pid.
>> + cpuset.effective_cpus
>> + A read-only multiple values file which exists on non-root
>> + cgroups.
>> +
>> + It lists the onlined CPUs that are actually allowed to be
>> + used by tasks within the current cgroup. It is a subset of
>> + "cpuset.cpus". Its value will be affected by CPU hotplug
>> + events.
> Can we do cpuset.cpus.availble which lists the cpus available to the
> cgroup instead of the eventual computed mask for the cgroup? That'd
> be more useful as it doesn't lose the information by and'ing what's
> available with the cgroup's mask and it's trivial to determine the
> effective from the two masks.
I don't get what you want here. cpus is the cpuset's cpus_allowed mask.
effective_cpus is the effective_cpus mask. When you say cpus available
to the cgroup, do you mean the cpu_online_mask or the list of cpus from
the parent? Or do you just want to change the name to cpus.available
instead of effective_cpus?
>> + cpuset.effective_mems
>> + A read-only multiple values file which exists on non-root
>> + cgroups.
>> +
>> + It lists the onlined memory nodes that are actually allowed
>> + to be used by tasks within the current cgroup. It is a subset
>> + of "cpuset.mems". Its value will be affected by memory nodes
>> + hotplug events.
> Ditto.
>
>> +static struct cftype dfl_files[] = {
>> + {
>> + .name = "cpus",
>> + .seq_show = cpuset_common_seq_show,
>> + .write = cpuset_write_resmask,
>> + .max_write_len = (100U + 6 * NR_CPUS),
>> + .private = FILE_CPULIST,
>> + },
> Is it missing CFTYPE_NOT_ON_ROOT? Other files too.
Right, I will set CFTYPE_NOT_ON_ROOT to "cpus" and "mems" as we are not
supposed to change them in the root. The effective_cpus and
effective_mems will be there in the root to show what are available.
Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] x86/smpboot: Make the check code more clear in prefill_possible_map()
From: Peter Zijlstra @ 2018-03-20 12:39 UTC (permalink / raw)
To: Dou Liyang
Cc: linux-kernel, x86, linux-acpi, linux-doc, tglx, mingo, corbet,
rjw, lenb, hpa
In-Reply-To: <20180320110432.28127-4-douly.fnst@cn.fujitsu.com>
On Tue, Mar 20, 2018 at 07:04:30PM +0800, Dou Liyang wrote:
> case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids, setup_max_cpus)
> case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids)
> case 3: no | yes | no | --> 1
> case 4: no | yes | yes| --> 1
> case 5: yes | no | no | --> min (num_processors, nr_cpu_ids, setup_max_cpus)
> case 6: yes | no | yes| --> min (num_processors + disabled_cpus, nr_cpu_ids)
> case 7: yes | yes | no | --> 1
> case 8: yes | yes | yes| --> 1
The case number is off by one ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
From: Peter Zijlstra @ 2018-03-20 12:37 UTC (permalink / raw)
To: Dou Liyang
Cc: linux-kernel, x86, linux-acpi, linux-doc, tglx, mingo, corbet,
rjw, lenb, hpa
In-Reply-To: <20180320110432.28127-2-douly.fnst@cn.fujitsu.com>
On Tue, Mar 20, 2018 at 07:04:28PM +0800, Dou Liyang wrote:
> + possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus.
> + This option sets possible_cpus bits in cpu_possible_map.
> + Thus keeping the numbers of bits set constant even if
> + the machine gets rebooted.
That description, esp. the last sentence, doesn't make any kind of sense
to me. What?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/5] x86/cpu_hotplug: Update the link of cpu_hotplug.rst
From: Dou Liyang @ 2018-03-20 11:04 UTC (permalink / raw)
To: linux-kernel, x86, linux-acpi, linux-doc
Cc: tglx, mingo, corbet, rjw, lenb, hpa, peterz, Dou Liyang
In-Reply-To: <20180320110432.28127-1-douly.fnst@cn.fujitsu.com>
The original cpu_hotplug.txt documents describing CPU hotplug support in
Linux kernel. it was moved in to core-api/ and renamed cpu_hotplug.rst.
Update it's link in other documents
Fixes: ff58fa7f556c ("Documentation: Update CPU hotplug and move it to core-api")
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
---
Documentation/00-INDEX | 2 --
Documentation/cputopology.txt | 10 +++++-----
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 7f3a0728ccf2..3773c67ea9e5 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -104,8 +104,6 @@ core-api/
- documentation on kernel core components.
cpu-freq/
- info on CPU frequency and voltage scaling.
-cpu-hotplug.txt
- - document describing CPU hotplug support in the Linux kernel.
cpu-load.txt
- document describing how CPU load statistics are collected.
cpuidle/
diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt
index c6e7e9196a8b..e05b0879fe91 100644
--- a/Documentation/cputopology.txt
+++ b/Documentation/cputopology.txt
@@ -117,9 +117,9 @@ source for the output is in brackets ("[]").
[NR_CPUS-1]
offline: CPUs that are not online because they have been
- HOTPLUGGED off (see cpu-hotplug.txt) or exceed the limit
- of CPUs allowed by the kernel configuration (kernel_max
- above). [~cpu_online_mask + cpus >= NR_CPUS]
+ HOTPLUGGED off (see core-api/cpu_hotplug.rst) or exceed
+ the limit of CPUs allowed by the kernel configuration
+ (kernel_max above). [~cpu_online_mask + cpus >= NR_CPUS]
online: CPUs that are online and being scheduled [cpu_online_mask]
@@ -155,5 +155,5 @@ online.)::
possible: 0-127
present: 0-3
-See cpu-hotplug.txt for the possible_cpus=NUM kernel start parameter
-as well as more information on the various cpumasks.
+See core-api/cpu_hotplug.rst for the possible_cpus=NUM kernel start
+parameter as well as more information on the various cpumasks.
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/5] x86/smpboot: Make the check code more clear in prefill_possible_map()
From: Dou Liyang @ 2018-03-20 11:04 UTC (permalink / raw)
To: linux-kernel, x86, linux-acpi, linux-doc
Cc: tglx, mingo, corbet, rjw, lenb, hpa, peterz, Dou Liyang
In-Reply-To: <20180320110432.28127-1-douly.fnst@cn.fujitsu.com>
In prefill_possible_map(), Kernel need to get the number of possible CPUs
to reset cpu_possible_map. The number is related to the options:
-nosmp, maxcpus, possible_cpus, nr_cpus
... which need to be checked.
Currentlly, the check code mixed these options together in confusion and
hard to follow.
Isolate them, and check them linearly.
No functionary change, Prepare for cutting the number of possible CPUs
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
---
Situations:
setup_possible_cpus == -1 | setup_max_cpus == 0 | CONFIG_HOTPLUG_CPU == y |
yes | yes | yes |
no | no | no |
Test cases:
Cases | the number of possible cpus
| (the same with or w/o this patch)
case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids, setup_max_cpus)
case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids)
case 3: no | yes | no | --> 1
case 4: no | yes | yes| --> 1
case 5: yes | no | no | --> min (num_processors, nr_cpu_ids, setup_max_cpus)
case 6: yes | no | yes| --> min (num_processors + disabled_cpus, nr_cpu_ids)
case 7: yes | yes | no | --> 1
case 8: yes | yes | yes| --> 1
arch/x86/kernel/smpboot.c | 31 ++++++++++++++++++-------------
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index ff99e2b6fc54..2fdda8567bf9 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1334,7 +1334,7 @@ early_param("possible_cpus", _setup_possible_cpus);
* We do this because additional CPUs waste a lot of memory.
* -AK
*/
-__init void prefill_possible_map(void)
+void __init prefill_possible_map(void)
{
int i, possible;
@@ -1356,18 +1356,22 @@ __init void prefill_possible_map(void)
num_processors = 1;
}
- i = setup_max_cpus ?: 1;
+ /* The SMP kernel could be acted as an UP kernel via nosmp/maxcpus=0 */
+ if (!setup_max_cpus) {
+ possible = 1;
+ total_cpus = num_processors + disabled_cpus;
+ goto set_cpu_possible_mask;
+ }
+
+ /* Possible CPUs could be overwrited via possible_cpus= */
if (setup_possible_cpus == -1) {
possible = num_processors;
#ifdef CONFIG_HOTPLUG_CPU
- if (setup_max_cpus)
- possible += disabled_cpus;
-#else
- if (possible > i)
- possible = i;
+ possible += disabled_cpus;
#endif
- } else
+ } else {
possible = setup_possible_cpus;
+ }
total_cpus = max_t(int, possible, num_processors + disabled_cpus);
@@ -1378,15 +1382,16 @@ __init void prefill_possible_map(void)
possible = nr_cpu_ids;
}
-#ifdef CONFIG_HOTPLUG_CPU
- if (!setup_max_cpus)
-#endif
- if (possible > i) {
+#ifndef CONFIG_HOTPLUG_CPU
+ /* Possible CPUs could be reduced via max_cpus= */
+ if (possible > setup_max_cpus) {
pr_warn("%d Processors exceeds max_cpus limit of %u\n",
possible, setup_max_cpus);
- possible = i;
+ possible = setup_max_cpus;
}
+#endif
+set_cpu_possible_mask:
nr_cpu_ids = possible;
pr_info("Allowing %d CPUs, %d hotplug CPUs\n",
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
From: Dou Liyang @ 2018-03-20 11:04 UTC (permalink / raw)
To: linux-kernel, x86, linux-acpi, linux-doc
Cc: tglx, mingo, corbet, rjw, lenb, hpa, peterz, Dou Liyang
In-Reply-To: <20180320110432.28127-1-douly.fnst@cn.fujitsu.com>
Kernel uses the possible_cpus in command line to reset the possible_cpus bits
in cpu_possible_map. It doesn't be recorded in the kernel-parameters.txt
Add its description in this document, also replace the wrong option additional_cpus
with possible_cpus in cpu-gotplug-spec.
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
---
Documentation/admin-guide/kernel-parameters.txt | 5 +++++
Documentation/x86/x86_64/cpu-hotplug-spec | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 1d1d53f85ddd..34f8a5f04e63 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2832,6 +2832,11 @@
variables need be pre-allocated for later physical cpu
hot plugging.
+ possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus.
+ This option sets possible_cpus bits in cpu_possible_map.
+ Thus keeping the numbers of bits set constant even if
+ the machine gets rebooted.
+
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
numa_balancing= [KNL,X86] Enable or disable automatic NUMA balancing.
diff --git a/Documentation/x86/x86_64/cpu-hotplug-spec b/Documentation/x86/x86_64/cpu-hotplug-spec
index 3c23e0587db3..d218bc0bdaaa 100644
--- a/Documentation/x86/x86_64/cpu-hotplug-spec
+++ b/Documentation/x86/x86_64/cpu-hotplug-spec
@@ -16,6 +16,6 @@ it should have its LAPIC Enabled bit set to 0. Linux will use the number
of disabled LAPICs to compute the maximum number of future CPUs.
In the worst case the user can overwrite this choice using a command line
-option (additional_cpus=...), but it is recommended to supply the correct
+option (possible_cpus=...), but it is recommended to supply the correct
number (or a reasonable approximation of it, with erring towards more not less)
in the MADT to avoid manual configuration.
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/5] acpi/processor: Make the acpi_duplicate_processor_id() static
From: Dou Liyang @ 2018-03-20 11:04 UTC (permalink / raw)
To: linux-kernel, x86, linux-acpi, linux-doc
Cc: tglx, mingo, corbet, rjw, lenb, hpa, peterz, Dou Liyang
In-Reply-To: <20180320110432.28127-1-douly.fnst@cn.fujitsu.com>
The acpi_duplicate_processor_id() is only called in acpi_processor_get_info(),
So move it in front of acpi_processor_get_info() and make it static.
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
---
drivers/acpi/acpi_processor.c | 62 +++++++++++++++++++++----------------------
include/linux/acpi.h | 3 ---
2 files changed, 31 insertions(+), 34 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index db5bdb59639c..03ec7690710c 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -229,6 +229,37 @@ static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
}
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
+/* The number of the unique processor IDs */
+static int nr_unique_ids __initdata;
+
+/* The number of the duplicate processor IDs */
+static int nr_duplicate_ids;
+
+/* Used to store the unique processor IDs */
+static int unique_processor_ids[] __initdata = {
+ [0 ... NR_CPUS - 1] = -1,
+};
+
+/* Used to store the duplicate processor IDs */
+static int duplicate_processor_ids[] = {
+ [0 ... NR_CPUS - 1] = -1,
+};
+
+static bool acpi_duplicate_processor_id(int proc_id)
+{
+ int i;
+
+ /*
+ * Compare the proc_id with duplicate IDs, if the proc_id is already
+ * in the duplicate IDs, return true, otherwise, return false.
+ */
+ for (i = 0; i < nr_duplicate_ids; i++) {
+ if (duplicate_processor_ids[i] == proc_id)
+ return true;
+ }
+ return false;
+}
+
static int acpi_processor_get_info(struct acpi_device *device)
{
union acpi_object object = { 0 };
@@ -579,22 +610,6 @@ static struct acpi_scan_handler processor_container_handler = {
.attach = acpi_processor_container_attach,
};
-/* The number of the unique processor IDs */
-static int nr_unique_ids __initdata;
-
-/* The number of the duplicate processor IDs */
-static int nr_duplicate_ids;
-
-/* Used to store the unique processor IDs */
-static int unique_processor_ids[] __initdata = {
- [0 ... NR_CPUS - 1] = -1,
-};
-
-/* Used to store the duplicate processor IDs */
-static int duplicate_processor_ids[] = {
- [0 ... NR_CPUS - 1] = -1,
-};
-
static void __init processor_validated_ids_update(int proc_id)
{
int i;
@@ -682,21 +697,6 @@ static void __init acpi_processor_check_duplicates(void)
NULL, NULL);
}
-bool acpi_duplicate_processor_id(int proc_id)
-{
- int i;
-
- /*
- * compare the proc_id with duplicate IDs, if the proc_id is already
- * in the duplicate IDs, return true, otherwise, return false.
- */
- for (i = 0; i < nr_duplicate_ids; i++) {
- if (duplicate_processor_ids[i] == proc_id)
- return true;
- }
- return false;
-}
-
void __init acpi_processor_init(void)
{
acpi_processor_check_duplicates();
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 968173ec2726..dd4591dc1eb3 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -285,9 +285,6 @@ static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
return phys_id == PHYS_CPUID_INVALID;
}
-/* Validate the processor object's proc_id */
-bool acpi_duplicate_processor_id(int proc_id);
-
#ifdef CONFIG_ACPI_HOTPLUG_CPU
/* Arch dependent functions for cpu hotplug support */
int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 acpi_id,
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()
From: Dou Liyang @ 2018-03-20 11:04 UTC (permalink / raw)
To: linux-kernel, x86, linux-acpi, linux-doc
Cc: tglx, mingo, corbet, rjw, lenb, hpa, peterz, Dou Liyang
In-Reply-To: <20180320110432.28127-1-douly.fnst@cn.fujitsu.com>
ACPI driver should make sure all the processor IDs in their ACPI Namespace
are unique for CPU hotplug. the driver performs a depth-first walk of the
namespace tree and calls the acpi_processor_ids_walk().
But, the acpi_processor_ids_walk() will return true if one processor is
checked, that cause the walk break after walking pass the first processor.
Repace the value with AE_OK which is the standard acpi_status value.
Fixes 8c8cb30f49b8 ("acpi/processor: Implement DEVICE operator for processor enumeration")
Signed-off-by: Dou Liyang <douly.fnst@cn.fujitsu.com>
---
drivers/acpi/acpi_processor.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 449d86d39965..db5bdb59639c 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -663,11 +663,11 @@ static acpi_status __init acpi_processor_ids_walk(acpi_handle handle,
}
processor_validated_ids_update(uid);
- return true;
+ return AE_OK;
err:
acpi_handle_info(handle, "Invalid processor object\n");
- return false;
+ return AE_OK;
}
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/5] x86/cpu_hotplug: one bug fix and four cleanup
From: Dou Liyang @ 2018-03-20 11:04 UTC (permalink / raw)
To: linux-kernel, x86, linux-acpi, linux-doc
Cc: tglx, mingo, corbet, rjw, lenb, hpa, peterz, Dou Liyang
Recently, we hoped to make the possible CPU count more accurate for
Kernel. I stuck on the issue how do I run acpi_early_init() _before_
setup_percpu() is invoked. So send these insignificant patches first.
This patchset does this things:
- two document-related work(the 1th and 2th patch),
- two cleapup work (the 3th and 5th patch)
- a bug fix for CPU hotplug(4th patch)
Dou Liyang (5):
x86/smpboot: Add the missing description of possible_cpus
x86/cpu_hotplug: Update the link of cpu_hotplug.rst
x86/smpboot: Make the check code more clear in prefill_possible_map()
acpi/processor: Fix the return value of acpi_processor_ids_walk()
acpi/processor: Make the acpi_duplicate_processor_id() static
Documentation/00-INDEX | 2 -
Documentation/admin-guide/kernel-parameters.txt | 5 ++
Documentation/cputopology.txt | 10 ++--
Documentation/x86/x86_64/cpu-hotplug-spec | 2 +-
arch/x86/kernel/smpboot.c | 31 +++++++-----
drivers/acpi/acpi_processor.c | 66 ++++++++++++-------------
include/linux/acpi.h | 3 --
7 files changed, 62 insertions(+), 57 deletions(-)
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] crypto: doc - clarify hash callbacks state machine
From: Horia Geantă @ 2018-03-20 10:29 UTC (permalink / raw)
To: Kamil Konieczny, Herbert Xu, David S. Miller, Jonathan Corbet
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, Bartlomiej Zolnierkiewicz
In-Reply-To: <d036a7ef-d900-4858-b821-05c50b2b739e@partner.samsung.com>
On 3/20/2018 10:50 AM, Kamil Konieczny wrote:
> On 20.03.2018 08:56, Horia Geantă wrote:
>> Add a note that it is perfectly legal to "abandon" a request object:
>> - call .init() and then (as many times) .update()
>> - _not_ call any of .final(), .finup() or .export() at any point in
>> future
>>
>> Link: https://lkml.kernel.org/r/20180222114741.ga27...@gondor.apana.org.au
>> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
>> ---
>> Documentation/crypto/devel-algos.rst | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
>> index 66f50d32dcec..c45c6f400dbd 100644
>> --- a/Documentation/crypto/devel-algos.rst
>> +++ b/Documentation/crypto/devel-algos.rst
>> @@ -236,6 +236,14 @@ when used from another part of the kernel.
>> |
>> '---------------> HASH2
>>
>> +Note that it is perfectly legal to "abandon" a request object:
>> +- call .init() and then (as many times) .update()
>> +- _not_ call any of .final(), .finup() or .export() at any point in future
>> +
>> +In other words implementations should mind the resource allocation and clean-up.
>> +No resources related to request objects should remain allocated after a call
> -- ^^^^^^^^^^^^
>> +to .init() or .update(), since there might be no chance to free them.
>
> is it for crypto api users or for drivers ?
>
For drivers / providers (below crypto API).
> the creator of request context is responsible for alloc and destroy,
> so why there are no chance of free ?
>
Hash request object (including request context) is allocated by the user /
client by means of ahash_request_alloc(), and later on freed using
ahash_request_free().
I don't see a problem with this.
However, besides the memory allocated for the request context, other resources
(related to the request) might be needed by the driver.
I provided an example of needing to DMA map a buffer (to load/store HW state
from/to crypto engine), and I am not happy with either solutions:
-DMA map & unmap after each .update()
-Herbert's proposal to use a convoluted DMA mapping scheme
Another example: dynamic memory allocation might be needed beyond what's
available in request context, i.e. driver might not have apriori all the
information needed to inform the tfm about required memory using
crypto_ahash_set_reqsize().
This happens due to the semantics of the crypto API, which allows the user to
initialize a request object and drop it without getting a result (final or
partial hash).
I don't see what below use case is good for, maybe just for benchmarking:
req = ahash_request_alloc();
[...]
crypto_ahash_init(req);
crypto_ahash_update(req);
ahash_request_free(req);
Horia
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 4/8] dt-bindings: Add doc for the Ingenic TCU drivers
From: Marc Zyngier @ 2018-03-20 8:52 UTC (permalink / raw)
To: Paul Cercueil, Thomas Gleixner, Jason Cooper, Lee Jones,
Daniel Lezcano, Ralf Baechle, Rob Herring, Jonathan Corbet,
Mark Rutland
Cc: James Hogan, Maarten ter Huurne, linux-clk, devicetree,
linux-kernel, linux-mips, linux-doc
In-Reply-To: <20180317232901.14129-5-paul@crapouillou.net>
On 17/03/18 23:28, Paul Cercueil wrote:
> Add documentation about how to properly use the Ingenic TCU
> (Timer/Counter Unit) drivers from devicetree.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> ---
> .../bindings/clock/ingenic,tcu-clocks.txt | 42 ++++++++++++++++
> .../bindings/interrupt-controller/ingenic,tcu.txt | 39 +++++++++++++++
> .../devicetree/bindings/mfd/ingenic,tcu.txt | 56 ++++++++++++++++++++++
> .../devicetree/bindings/timer/ingenic,tcu.txt | 41 ++++++++++++++++
> 4 files changed, 178 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ingenic,tcu.txt
>
> v4: New patch in this series. Corresponds to V2 patches 3-4-5 with
> added content.
>
> diff --git a/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> new file mode 100644
> index 000000000000..471d27078599
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> @@ -0,0 +1,42 @@
> +Ingenic SoC TCU binding
> +
> +The TCU is the Timer/Counter Unit present in all Ingenic SoCs. It features 8
> +channels, each one having its own clock, that can be started and stopped,
> +reparented, and reclocked.
> +
> +Required properties:
> +- compatible : One of:
> + * ingenic,jz4740-tcu-clocks,
> + * ingenic,jz4770-tcu-clocks,
> + * ingenic,jz4780-tcu-clocks.
> +- clocks : List of phandle & clock specifiers for clocks external to the TCU.
> + The "pclk", "rtc" and "ext" clocks should be provided.
> +- clock-names : List of name strings for the external clocks.
> +- #clock-cells: Should be 1.
> + Clock consumers specify this argument to identify a clock. The valid values
> + may be found in <dt-bindings/clock/ingenic,tcu.h>.
> +
> +Example:
> +
> +/ {
> + tcu: mfd@10002000 {
> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + tcu_clk: clocks@10 {
> + compatible = "ingenic,jz4740-tcu-clocks";
> + reg = <0x10 0xff0>;
> +
> + clocks = <&ext>, <&rtc>, <&pclk>;
> + clock-names = "ext", "rtc", "pclk";
> +
> + #clock-cells = <1>;
> + };
> + };
> +};
> +
> +For information about the top-level "ingenic,tcu" compatible node and other
> +children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> new file mode 100644
> index 000000000000..7f3af2da77cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> @@ -0,0 +1,39 @@
> +Ingenic SoCs Timer/Counter Unit Interrupt Controller
> +
> +Required properties:
> +
> +- compatible : should be "ingenic,<socname>-tcu-intc". Valid strings are:
> + * ingenic,jz4740-tcu-intc
> + * ingenic,jz4770-tcu-intc
> + * ingenic,jz4780-tcu-intc
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. The value shall be 1.
> +- interrupt-parent : phandle of the interrupt controller.
> +- interrupts : Specifies the interrupt the controller is connected to.
> +
> +Example:
> +
> +/ {
> + tcu: mfd@10002000 {
> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + tcu_irq: interrupt-controller@20 {
> + compatible = "ingenic,jz4740-tcu-intc";
> + reg = <0x20 0x20>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interrupt-parent = <&intc>;
> + interrupts = <15>;
> + };
> + };
> +};
> +
> +For information about the top-level "ingenic,tcu" compatible node and other
> +children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
> diff --git a/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
> new file mode 100644
> index 000000000000..5742c3f21550
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ingenic,tcu.txt
> @@ -0,0 +1,56 @@
> +Ingenic JZ47xx SoCs Timer/Counter Unit devicetree bindings
> +----------------------------------------------------------
> +
> +For a description of the TCU hardware and drivers, have a look at
> +Documentation/mips/ingenic-tcu.txt.
> +
> +The TCU is implemented as a parent node, whose role is to create the
> +regmap, and child nodes for the various drivers listed in the aforementioned
> +document.
You're describing the Linux driver here. Please stick to a description
of the HW.
> +
> +Required properties:
> +
> +- compatible: must be "ingenic,tcu", "simple-mfd", "syscon";
Without any provision for an SoC version? Seems bold...
> +- reg: Should be the offset/length value corresponding to the TCU registers
> +- #address-cells: Should be <1>;
> +- #size-cells: Should be <1>;
> +- ranges: Should be one range for the full TCU registers area
> +
> +Accepted children nodes:
> +- Documentation/devicetree/bindings/interrupt-controller/ingenic,tcu.txt
> +- Documentation/devicetree/bindings/clock/ingenic,tcu-clocks.txt
> +- Documentation/devicetree/bindings/timer/ingenic,tcu.txt
It is slightly confusing that you have 3 files named ingenic,tcu.txt.
How about ingenic,tcu-intc.txt and ingenic,tcu-timer.txt (amending the
binding for the timer)?
> +
> +
> +Example:
> +
> +/ {
> + tcu: mfd@10002000 {
> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + tcu_irq: interrupt-controller@20 {
> + compatible = "ingenic,jz4740-tcu-intc";
> + reg = <0x20 0x20>;
> + ...
> + };
> +
> + tcu_clk: clocks@10 {
> + compatible = "ingenic,jz4740-tcu-clocks";
> + reg = <0x10 0xff0>;
> + ...
> + };
> +
> + tcu_timer: timer@10 {
> + compatible = "ingenic,jz4740-tcu";
> + reg = <0x10 0xff0>;
> + ...
> + };
> + };
> +};
> +
> +For more information about the children node, refer to the documents listed
> +above in the "Accepted children nodes" section.
> diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.txt b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
> new file mode 100644
> index 000000000000..f910b7e96783
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.txt
> @@ -0,0 +1,41 @@
> +Ingenic JZ47xx SoCs Timer/Counter Unit driver
> +---------------------------------------------
> +
> +Required properties:
> +
> +- compatible : should be "ingenic,<socname>-tcu". Valid strings are:
> + * ingenic,jz4740-tcu
> + * ingenic,jz4770-tcu
> + * ingenic,jz4780-tcu
> +- interrupt-parent : phandle of the TCU interrupt controller.
> +- interrupts : Specifies the interrupts the controller is connected to.
> +- clocks : List of phandle & clock specifiers for the TCU clocks.
> +- clock-names : List of name strings for the TCU clocks.
> +
> +Example:
> +
> +/ {
> + tcu: mfd@10002000 {
> + compatible = "ingenic,tcu", "simple-mfd", "syscon";
> + reg = <0x10002000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x10002000 0x1000>;
> +
> + tcu_timer: timer@10 {
> + compatible = "ingenic,jz4740-tcu";
> + reg = <0x10 0xff0>;
> +
> + clocks = <&tcu_clk 0>, <&tcu_clk 1>, <&tcu_clk 2>, <&tcu_clk 3>,
> + <&tcu_clk 4>, <&tcu_clk 5>, <&tcu_clk 6>, <&tcu_clk 7>;
> + clock-names = "timer0", "timer1", "timer2", "timer3",
> + "timer4", "timer5", "timer6", "timer7";
> +
> + interrupt-parent = <&tcu_irq>;
> + interrupts = <0 1 2 3 4 5 6 7>;
> + };
> + };
> +};
> +
> +For information about the top-level "ingenic,tcu" compatible node and other
> +children nodes, see Documentation/devicetree/bindings/mfd/ingenic,tcu.txt.
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] crypto: doc - clarify hash callbacks state machine
From: Kamil Konieczny @ 2018-03-20 8:50 UTC (permalink / raw)
To: Horia Geantă, Herbert Xu, David S. Miller, Jonathan Corbet
Cc: linux-crypto, linux-kernel, linux-doc, Bartlomiej Zolnierkiewicz
In-Reply-To: <20180320075612.22719-1-horia.geanta@nxp.com>
On 20.03.2018 08:56, Horia Geantă wrote:
> Add a note that it is perfectly legal to "abandon" a request object:
> - call .init() and then (as many times) .update()
> - _not_ call any of .final(), .finup() or .export() at any point in
> future
>
> Link: https://lkml.kernel.org/r/20180222114741.GA27631@gondor.apana.org.au
> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
> ---
> Documentation/crypto/devel-algos.rst | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
> index 66f50d32dcec..c45c6f400dbd 100644
> --- a/Documentation/crypto/devel-algos.rst
> +++ b/Documentation/crypto/devel-algos.rst
> @@ -236,6 +236,14 @@ when used from another part of the kernel.
> |
> '---------------> HASH2
>
> +Note that it is perfectly legal to "abandon" a request object:
> +- call .init() and then (as many times) .update()
> +- _not_ call any of .final(), .finup() or .export() at any point in future
> +
> +In other words implementations should mind the resource allocation and clean-up.
> +No resources related to request objects should remain allocated after a call
-- ^^^^^^^^^^^^
> +to .init() or .update(), since there might be no chance to free them.
is it for crypto api users or for drivers ?
the creator of request context is responsible for alloc and destroy,
so why there are no chance of free ?
--
Best regards,
Kamil Konieczny
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] crypto: doc - clarify hash callbacks state machine
From: Horia Geantă @ 2018-03-20 7:56 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet
Cc: linux-crypto, linux-kernel, linux-doc
In-Reply-To: <20180305103945.3517-1-horia.geanta@nxp.com>
Add a note that it is perfectly legal to "abandon" a request object:
- call .init() and then (as many times) .update()
- _not_ call any of .final(), .finup() or .export() at any point in
future
Link: https://lkml.kernel.org/r/20180222114741.GA27631@gondor.apana.org.au
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
Documentation/crypto/devel-algos.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
index 66f50d32dcec..c45c6f400dbd 100644
--- a/Documentation/crypto/devel-algos.rst
+++ b/Documentation/crypto/devel-algos.rst
@@ -236,6 +236,14 @@ when used from another part of the kernel.
|
'---------------> HASH2
+Note that it is perfectly legal to "abandon" a request object:
+- call .init() and then (as many times) .update()
+- _not_ call any of .final(), .finup() or .export() at any point in future
+
+In other words implementations should mind the resource allocation and clean-up.
+No resources related to request objects should remain allocated after a call
+to .init() or .update(), since there might be no chance to free them.
+
Specifics Of Asynchronous HASH Transformation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.16.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 6/6] arm64: dts: sdm845: Add I2C controller support
From: Stephen Boyd @ 2018-03-20 7:45 UTC (permalink / raw)
To: Doug Anderson, Sagar Dharia
Cc: Karthikeyan Ramasubramanian, Jonathan Corbet, Andy Gross,
David Brown, Rob Herring, Mark Rutland, Wolfram Sang,
Greg Kroah-Hartman, linux-doc, linux-arm-msm, devicetree,
linux-i2c, linux-serial, Jiri Slaby, evgreen, acourbot,
Bjorn Andersson
In-Reply-To: <CAD=FV=Vq4Q2LvY_O-YsdyUmQOUANa0ap+U9j7PXSD3_ao6sCdQ@mail.gmail.com>
Quoting Doug Anderson (2018-03-19 16:56:27)
> On Mon, Mar 19, 2018 at 3:15 PM, Sagar Dharia <sdharia@codeaurora.org> wrote:
> >
> > Yes, we typically have a "platform(sdm845 here)-qupv3.dtsi" defining
> > most of the serial-bus instances (i2c, spi, and uart with
> > status=disabled) that we include from the common header. The boards
> > enable instances they need.
> > Will that be okay?
>
> Unless you really feel the need to put these in a separate file I'd
> just put them straight in sdm845.dtsi. Yeah, it'll get big, but
> that's OK by me. I _think_ this matches what Bjorn was suggesting on
> previous device tree patches, but CCing him just in case. I'm
> personally OK with whatever Bjorn and other folks with more Qualcomm
> history would like.
Upstream puts all SoC nodes in the SoC file. The split file by
functional area method is to avoid merge conflicts in the SoC file and
that doesn't make sense outside of the internal workflow.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: ingenic: Add DT bindings for TCU clocks
From: Mathieu Malaterre @ 2018-03-20 7:15 UTC (permalink / raw)
To: Paul Cercueil
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Lee Jones,
Daniel Lezcano, Ralf Baechle, Rob Herring, Jonathan Corbet,
Mark Rutland, James Hogan, Maarten ter Huurne, linux-clk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Linux-MIPS, linux-doc
In-Reply-To: <20180317232901.14129-3-paul@crapouillou.net>
Hi Paul,
Two things:
On Sun, Mar 18, 2018 at 12:28 AM, Paul Cercueil <paul@crapouillou.net> wrote:
> This header provides clock numbers for the ingenic,tcu
> DT binding.
I have tested the whole series on my Creator CI20 with success, using:
+ tcu@10002000 {
+ compatible = "ingenic,jz4780-tcu";
+ reg = <0x10002000 0x140>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <27 26 25>;
+ };
So:
Tested-by: Mathieu Malaterre <malat@debian.org>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> include/dt-bindings/clock/ingenic,tcu.h | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 include/dt-bindings/clock/ingenic,tcu.h
>
> v2: Use SPDX identifier for the license
> v3: No change
> v4: No change
>
> diff --git a/include/dt-bindings/clock/ingenic,tcu.h b/include/dt-bindings/clock/ingenic,tcu.h
> new file mode 100644
> index 000000000000..179815d7b3bb
> --- /dev/null
> +++ b/include/dt-bindings/clock/ingenic,tcu.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * This header provides clock numbers for the ingenic,tcu DT binding.
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
> +#define __DT_BINDINGS_CLOCK_INGENIC_TCU_H__
> +
> +#define JZ4740_CLK_TIMER0 0
> +#define JZ4740_CLK_TIMER1 1
> +#define JZ4740_CLK_TIMER2 2
> +#define JZ4740_CLK_TIMER3 3
> +#define JZ4740_CLK_TIMER4 4
> +#define JZ4740_CLK_TIMER5 5
> +#define JZ4740_CLK_TIMER6 6
> +#define JZ4740_CLK_TIMER7 7
> +#define JZ4740_CLK_WDT 8
> +#define JZ4740_CLK_LAST JZ4740_CLK_WDT
> +
> +#define JZ4770_CLK_OST 9
> +#define JZ4770_CLK_LAST JZ4770_CLK_OST
> +
When working on JZ4780 support, I always struggle to read those kind
of #define. Since this is a new patch would you mind changing
s/JZ4740/JZ47XX/ in your header ?
Thanks for your work on JZ !
> +#endif /* __DT_BINDINGS_CLOCK_INGENIC_TCU_H__ */
> --
> 2.11.0
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/1] runchecks: Generalize make C={1,2} to support multiple checkers
From: Knut Omang @ 2018-03-20 5:44 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Linux Kernel Mailing List, Mauro Carvalho Chehab, Nicolas Palix,
Linux Kbuild mailing list, Håkon Bugge,
open list:DOCUMENTATION, Jonathan Corbet, Gilles Muller,
Tom Saeger, Michal Marek, Mickaël Salaün,
Paul E. McKenney, Julia Lawall, John Haxby,
Åsmund Østvold, Matthew Wilcox,
Levin, Alexander (Sasha Levin), cocci, Andrew Morton
In-Reply-To: <1517815200.3118.383.camel@oracle.com>
On Mon, 2018-02-05 at 08:20 +0100, Knut Omang wrote:
> On Mon, 2018-02-05 at 16:03 +0900, Masahiro Yamada wrote:
Hi Masahiro,
I know these are busy times but any hope of getting forward on this?
Anything more I can do to ease the process?
Thanks for your time,
Knut
> > 2018-02-05 15:41 GMT+09:00 Knut Omang <knut.omang@oracle.com>:
> > > On Fri, 2018-01-19 at 11:14 +0100, Knut Omang wrote:
> > >> Add scripts/runchecks which has generic support for running
> > >> checker tools in a convenient and user friendly way that
> > >> the author hopes can contribute to rein in issues detected
> > >> by these tools in a manageable and convenient way.
> > >>
> > >> scripts/runchecks provides the following basic functionality:
> > >>
> > >> * Makes it possible to selectively suppress output from individual
> > >> checks on a per file or per subsystem basis.
> > >> * Unifies output and suppression input from different tools
> > >> by providing a single unified syntax and presentation for the
> > >> underlying tools in the style of "scripts/checkpatch.pl --show-types".
> > >> * Allows selective run of one, or more (or all) configured tools
> > >> for each file.
> > >>
> > >> In the Makefile system, the sparse specific setup has been replaced
> > >> by setup for runchecks.
> > >
> > > Hi all,
> > >
> > > - Anything more I can/need to do to bring this forward?
> > > - Any quiet concerns?
> > >
> > > I realize it is a subsystem crossing change,
> >
> > Is it? Only Kbuild this is related to.
>
> Ok, I see!
>
> > > and a lot going on elsewhere,
> > > nevertheless I believe this is a time saver in the slightly longer run,
> > > as it allows automation of checking, even without a "perfect"
> > > code base to begin with.
> > >
> >
> > Sorry for the delay.
>
> I understand, no problem - just was afraid it was about to get lost
> in between subsystems,
>
> > I have not been able to find time to dive into the detail yet.
> > (Actually, I tried to do that for v2 or v3, where Python code was so dirty,
> > then consumed my time to figure out what the code was trying to do)
>
> Hopefully v4 is cleaner from a Python code style point of view at least,
> but let me know if you have any particular part of the code in mind wrt
> readability. Also hopefully the docs should be of help.
>
> > I find my concern here:
> > https://lkml.org/lkml/2018/1/5/497
>
> I believe I have addressed the issues there in v4.
>
> > Anyway, I will take a look again when I find some time.
> > You do not need to take care of the detail until I request to do so.
>
> Ok, thanks a lot for your time and the quick response now!
>
> Best regards,
> Knut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy
From: Mike Galbraith @ 2018-03-20 4:25 UTC (permalink / raw)
To: Waiman Long, Tejun Heo
Cc: Peter Zijlstra, Li Zefan, Johannes Weiner, Ingo Molnar, cgroups,
linux-kernel, linux-doc, kernel-team, pjt, luto, torvalds,
Roman Gushchin
In-Reply-To: <a334a234-3e87-a9a7-9589-8476fecb4149@redhat.com>
On Mon, 2018-03-19 at 17:41 -0400, Waiman Long wrote:
> On 03/19/2018 04:49 PM, Mike Galbraith wrote:
> > On Mon, 2018-03-19 at 08:34 -0700, Tejun Heo wrote:
> >> Hello, Mike.
> >>
> >> On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote:
> >>> Under the hood v2 details are entirely up to you. My input ends at
> >>> please don't leave dynamic partitioning standing at the dock when v2
> >>> sails.
> >> So, this isn't about implementation details but about what the
> >> interface achieves - ie, what's the actual function? The only thing I
> >> can see is blocking the entity which is configuring the hierarchy from
> >> making certain configs. While that might be useful in some specific
> >> use cases, it seems to miss the bar for becoming its own kernel
> >> feature. After all, nothing prevents the same entity from clearing
> >> the exlusive bit and making the said changes.
> > Yes, privileged contexts can maliciously or stupidly step all over one
> > other no matter what you do (finite resource), but oxymoron creation
> > (CPUs simultaneously balanced and isolated) should be handled. If one
> > context can allocate a set overlapping a set another context intends to
> > or already has detached from scheduler domains, both are screwed.
> >
> > -Mike
>
> The allocations of CPUs to child cgroups should be controlled by the
> parent cgroup. It is the parent's fault if some CPUs are in both
> balanced and isolated cgroups.
>
> How about we don't allow turning off scheduling if the CPUs aren't
> exclusive from the parent's perspective? So you can't create an isolated
> cgroup if the CPUs aren't exclusive. Will this be a good enough compromise?
Sure. The kernel need only ensure its own sanity. Userspace conflicts
are more or less a non-issue. In practice, all players but one will
have been constrained or eliminated prior to any partitioning.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs
From: Zhang Rui @ 2018-03-20 3:19 UTC (permalink / raw)
To: Viresh Kumar
Cc: Eduardo Valentin, Vincent Guittot, linux-doc, linux-kernel,
linux-pm
In-Reply-To: <20180320013836.hiu6oy3smwmk35tp@vireshk-mac-ubuntu>
On 二, 2018-03-20 at 09:38 +0800, Viresh Kumar wrote:
> On 14-03-18, 13:44, Viresh Kumar wrote:
> >
> > I got those warnings as well, and I quietly ignored them :)
> >
> > I ignored the renaming part for the sake of consistency. The other
> > existing
> > routines for similar purpose are named as:
> >
> > thermal_cooling_device_type_show
> > thermal_cooling_device_max_state_show
> > thermal_cooling_device_cur_state_show
> > thermal_cooling_device_cur_state_store
> >
> > for me it made more sense to follow that naming convention. And I
> > didn't use the
> > _RO and _WO variants for the same reason.
> >
> > Now here is what I propose now:
> >
> > - You apply this patch as-is and ignore the warning.
> >
> > - I will send few patches on top of that to do:
> > - renaming of all such routines to shorter versions.
> > - Use the _RO or _WO variants of the macro everywhere.
> >
> > What do you say ?
> @Zhang: Can you please share the way you want this to get merged ?
> And if the
> above is fine with you ?
>
yes, it works for me.
I will apply the patch later today.
thanks,
rui
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs
From: Viresh Kumar @ 2018-03-20 1:38 UTC (permalink / raw)
To: Zhang Rui
Cc: Eduardo Valentin, Vincent Guittot, linux-doc, linux-kernel,
linux-pm
In-Reply-To: <20180314081426.GG15832@vireshk-i7>
On 14-03-18, 13:44, Viresh Kumar wrote:
> I got those warnings as well, and I quietly ignored them :)
>
> I ignored the renaming part for the sake of consistency. The other existing
> routines for similar purpose are named as:
>
> thermal_cooling_device_type_show
> thermal_cooling_device_max_state_show
> thermal_cooling_device_cur_state_show
> thermal_cooling_device_cur_state_store
>
> for me it made more sense to follow that naming convention. And I didn't use the
> _RO and _WO variants for the same reason.
>
> Now here is what I propose now:
>
> - You apply this patch as-is and ignore the warning.
>
> - I will send few patches on top of that to do:
> - renaming of all such routines to shorter versions.
> - Use the _RO or _WO variants of the macro everywhere.
>
> What do you say ?
@Zhang: Can you please share the way you want this to get merged ? And if the
above is fine with you ?
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 6/6] arm64: dts: sdm845: Add I2C controller support
From: Doug Anderson @ 2018-03-19 23:56 UTC (permalink / raw)
To: Sagar Dharia
Cc: Karthikeyan Ramasubramanian, Jonathan Corbet, Andy Gross,
David Brown, Rob Herring, Mark Rutland, Wolfram Sang,
Greg Kroah-Hartman, linux-doc, linux-arm-msm, devicetree,
linux-i2c, linux-serial, Jiri Slaby, evgreen, acourbot, swboyd,
Bjorn Andersson
In-Reply-To: <65fa4ff5-7f37-b6fd-e493-bec18511d334@codeaurora.org>
Hi,
On Mon, Mar 19, 2018 at 3:15 PM, Sagar Dharia <sdharia@codeaurora.org> wrote:
>>> + pinconf {
>>> + pins = "gpio55", "gpio56";
>>> + drive-strength = <2>;
>>> + bias-disable;
>>> + };
>>> + };
>>> +
>>> + qup-i2c10-sleep {
>>> + pinconf {
>>> + pins = "gpio55", "gpio56";
>>> + bias-pull-up;
>>
>> Are you sure that you want pullups enabled for sleep here? There are
>> external pulls on this line (as there are on many i2c busses) so doing
>> this will double-enable pulls. It probably won't hurt, but I'm
>> curious if there's some sort of reason here.
>>
> 1. We need the lines to remain high to avoid slaves sensing a false
> start-condition (this can happen if the SDA goes down before SCL).
> 2. Disclaimer: I'm not a HW expert, but we were told that
> tri-state/bias-disabled lines can draw more current. I will find out
> more about that.
Agreed that they need to remain high, but you've got very strong
pullups external to the SoC. Those will keep it high. You don't need
the internal ones too.
As extra evidence that the external pullups _must_ be present on your
board: you specify bias-disable in the active state. That can only
work if there are external pullups (or if there were some special
extra secret internal pullups that were part of geni). i2c is an
open-drain bus and thus there must be pullups on the bus in order to
communicate.
>>> + };
>>> + };
>>> };
>>> };
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> index 59334d9..9ef056f 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> @@ -209,6 +209,21 @@
>>> pins = "gpio4", "gpio5";
>>> };
>>> };
>>> +
>>> + qup_i2c10_default: qup-i2c10-default {
>>> + pinmux {
>>> + function = "qup10";
>>> + pins = "gpio55", "gpio56";
>>> + };
>>> + };
>>> +
>>> + qup_i2c10_sleep: qup-i2c10-sleep {
>>> + pinmux {
>>> + function = "gpio";
>>> + pins = "gpio55", "gpio56";
>>> + };
>>> + };
>>> +
>>> };
>>>
>>> timer@17c90000 {
>>> @@ -309,6 +324,20 @@
>>> interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>>> status = "disabled";
>>> };
>>> +
>>> + i2c10: i2c@a88000 {
>>
>> Seems like it might be nice to add all the i2c busses into the main
>> sdm845.dtsi file. Sure, most won't be enabled, but it seems like it
>> would avoid churn later.
>>
>> ...if you're sure you want to add only one i2c controller, subject of
>> this patch should indicate that.
>>
>
> Yes, we typically have a "platform(sdm845 here)-qupv3.dtsi" defining
> most of the serial-bus instances (i2c, spi, and uart with
> status=disabled) that we include from the common header. The boards
> enable instances they need.
> Will that be okay?
Unless you really feel the need to put these in a separate file I'd
just put them straight in sdm845.dtsi. Yeah, it'll get big, but
that's OK by me. I _think_ this matches what Bjorn was suggesting on
previous device tree patches, but CCing him just in case. I'm
personally OK with whatever Bjorn and other folks with more Qualcomm
history would like.
...but yeah, I'm asking for them all to be listed with status="disabled".
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] crypto: doc - clarify hash callbacks state machine
From: Herbert Xu @ 2018-03-19 23:33 UTC (permalink / raw)
To: Horia Geantă
Cc: David S. Miller, Jonathan Corbet, linux-crypto@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <AM3PR04MB4520497CC3D9B2B98B8E63798D40@AM3PR04MB452.eurprd04.prod.outlook.com>
On Mon, Mar 19, 2018 at 11:04:24AM +0000, Horia Geantă wrote:
>
> The only solution to avoid leaks in this case is to repeatedly DMA map & unmap
> the buffer.
> IOW, if one wants to load/save HW state in a buffer after an .update() and to
> instruct the crypto engine to do this operation, the following steps are involved:
> -gpp: DMA map the buffer, get its IOVA
> -gpp: program the crypto engine with IOVA, wait for crypto engine's signal
> -crypto engine: load HW state from buffer, perform the partial hash, save HW
> state in buffer, signal gpp
> -gpp: DMA unmap the buffer
What buffer are you talking about here? Is it the hash state?
If it's the hash state and assuming DMA mapping was slow enough
on your platform, you could solve it by maintaining a fixed set
of hash states that are rotated through the actual hash requests.
Let's say you allocate n such hash states which are always mapped,
then if there are less than n hash requests outstanding, you could
directly use the mapped hash states in the requests.
If there are more than n, then you simply copy in/copy out for each
hash operation.
The number n limits how many operations can be pending to be
processed by the hardware.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 6/6] arm64: dts: sdm845: Add I2C controller support
From: Sagar Dharia @ 2018-03-19 22:15 UTC (permalink / raw)
To: Doug Anderson, Karthikeyan Ramasubramanian
Cc: Jonathan Corbet, Andy Gross, David Brown, Rob Herring,
Mark Rutland, Wolfram Sang, Greg Kroah-Hartman, linux-doc,
linux-arm-msm, devicetree, linux-i2c, linux-serial, Jiri Slaby,
evgreen, acourbot, swboyd
In-Reply-To: <CAD=FV=Wk5apkO9ro+PkLGDS7poJgvTkDA4uSKnMXmK=GMzuMcQ@mail.gmail.com>
Hi Doug,
Thanks for reviewing the patch.
On 3/16/2018 5:54 PM, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 14, 2018 at 4:58 PM, Karthikeyan Ramasubramanian
> <kramasub@codeaurora.org> wrote:
>> Add I2C master controller support for a built-in test I2C slave.
>>
>> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
>> ---
>> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 19 +++++++++++++++++++
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 29 +++++++++++++++++++++++++++++
>> 2 files changed, 48 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> index ea3efc5..69445f1 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> @@ -27,6 +27,10 @@
>> serial@a84000 {
>> status = "okay";
>> };
>> +
>> + i2c@a88000 {
>> + status = "okay";
>
> Any idea what clock frequency is appropriate for MTP? You've got some
> pretty beefy 2.2K external pulls I think, so presumably 400 KHz is
> what you're aiming for? It would be nice to specify one so you don't
> end up the the spam in the log "Bus frequency not specified ..."
>
>
Yes, we plan to use 400Khz. We will specify it here.
>> + };
>> };
>>
>> pinctrl@3400000 {
>> @@ -50,5 +54,20 @@
>> bias-pull-down;
>> };
>> };
>> +
>> + qup-i2c10-default {
>
> nit: probably in the pinctrl section we want to sort alphabetically?
> We could try to sort by "lowest numbered pin", but IMHO alphabetical
> makes the most sense.
>
Sure.
>
>> + pinconf {
>> + pins = "gpio55", "gpio56";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> + };
>> +
>> + qup-i2c10-sleep {
>> + pinconf {
>> + pins = "gpio55", "gpio56";
>> + bias-pull-up;
>
> Are you sure that you want pullups enabled for sleep here? There are
> external pulls on this line (as there are on many i2c busses) so doing
> this will double-enable pulls. It probably won't hurt, but I'm
> curious if there's some sort of reason here.
>
1. We need the lines to remain high to avoid slaves sensing a false
start-condition (this can happen if the SDA goes down before SCL).
2. Disclaimer: I'm not a HW expert, but we were told that
tri-state/bias-disabled lines can draw more current. I will find out
more about that.
>
>> + };
>> + };
>> };
>> };
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index 59334d9..9ef056f 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -209,6 +209,21 @@
>> pins = "gpio4", "gpio5";
>> };
>> };
>> +
>> + qup_i2c10_default: qup-i2c10-default {
>> + pinmux {
>> + function = "qup10";
>> + pins = "gpio55", "gpio56";
>> + };
>> + };
>> +
>> + qup_i2c10_sleep: qup-i2c10-sleep {
>> + pinmux {
>> + function = "gpio";
>> + pins = "gpio55", "gpio56";
>> + };
>> + };
>> +
>> };
>>
>> timer@17c90000 {
>> @@ -309,6 +324,20 @@
>> interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
>> status = "disabled";
>> };
>> +
>> + i2c10: i2c@a88000 {
>
> Seems like it might be nice to add all the i2c busses into the main
> sdm845.dtsi file. Sure, most won't be enabled, but it seems like it
> would avoid churn later.
>
> ...if you're sure you want to add only one i2c controller, subject of
> this patch should indicate that.
>
Yes, we typically have a "platform(sdm845 here)-qupv3.dtsi" defining
most of the serial-bus instances (i2c, spi, and uart with
status=disabled) that we include from the common header. The boards
enable instances they need.
Will that be okay?
Thanks
Sagar
>
>> + compatible = "qcom,geni-i2c";
>> + reg = <0xa88000 0x4000>;
>> + clock-names = "se";
>> + clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
>> + pinctrl-names = "default", "sleep";
>> + pinctrl-0 = <&qup_i2c10_default>;
>> + pinctrl-1 = <&qup_i2c10_sleep>;
>> + interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>> };
>> };
>> };
>> --
>> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy
From: Waiman Long @ 2018-03-19 21:41 UTC (permalink / raw)
To: Mike Galbraith, Tejun Heo
Cc: Peter Zijlstra, Li Zefan, Johannes Weiner, Ingo Molnar, cgroups,
linux-kernel, linux-doc, kernel-team, pjt, luto, torvalds,
Roman Gushchin
In-Reply-To: <1521492550.16869.1.camel@gmx.de>
On 03/19/2018 04:49 PM, Mike Galbraith wrote:
> On Mon, 2018-03-19 at 08:34 -0700, Tejun Heo wrote:
>> Hello, Mike.
>>
>> On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote:
>>> Under the hood v2 details are entirely up to you. My input ends at
>>> please don't leave dynamic partitioning standing at the dock when v2
>>> sails.
>> So, this isn't about implementation details but about what the
>> interface achieves - ie, what's the actual function? The only thing I
>> can see is blocking the entity which is configuring the hierarchy from
>> making certain configs. While that might be useful in some specific
>> use cases, it seems to miss the bar for becoming its own kernel
>> feature. After all, nothing prevents the same entity from clearing
>> the exlusive bit and making the said changes.
> Yes, privileged contexts can maliciously or stupidly step all over one
> other no matter what you do (finite resource), but oxymoron creation
> (CPUs simultaneously balanced and isolated) should be handled. If one
> context can allocate a set overlapping a set another context intends to
> or already has detached from scheduler domains, both are screwed.
>
> -Mike
The allocations of CPUs to child cgroups should be controlled by the
parent cgroup. It is the parent's fault if some CPUs are in both
balanced and isolated cgroups.
How about we don't allow turning off scheduling if the CPUs aren't
exclusive from the parent's perspective? So you can't create an isolated
cgroup if the CPUs aren't exclusive. Will this be a good enough compromise?
Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 1/2] cpuset: Enable cpuset controller in default hierarchy
From: Tejun Heo @ 2018-03-19 15:59 UTC (permalink / raw)
To: Waiman Long
Cc: Li Zefan, Johannes Weiner, Peter Zijlstra, Ingo Molnar, cgroups,
linux-kernel, linux-doc, kernel-team, pjt, luto, efault, torvalds,
Roman Gushchin
In-Reply-To: <1521148842-15486-2-git-send-email-longman@redhat.com>
Hello, Waiman.
This looks great. A couple nitpicks below.
> + 5-3. Cpuset
> + 5.3-1. Cpuset Interface Files
Can we put cpuset below pid? It feels weird to break up cpu, memory
and io as they represent the three major resources and are in a
similar fashion.
> + cpuset.effective_cpus
> + A read-only multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the onlined CPUs that are actually allowed to be
> + used by tasks within the current cgroup. It is a subset of
> + "cpuset.cpus". Its value will be affected by CPU hotplug
> + events.
Can we do cpuset.cpus.availble which lists the cpus available to the
cgroup instead of the eventual computed mask for the cgroup? That'd
be more useful as it doesn't lose the information by and'ing what's
available with the cgroup's mask and it's trivial to determine the
effective from the two masks.
> + cpuset.effective_mems
> + A read-only multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the onlined memory nodes that are actually allowed
> + to be used by tasks within the current cgroup. It is a subset
> + of "cpuset.mems". Its value will be affected by memory nodes
> + hotplug events.
Ditto.
> +static struct cftype dfl_files[] = {
> + {
> + .name = "cpus",
> + .seq_show = cpuset_common_seq_show,
> + .write = cpuset_write_resmask,
> + .max_write_len = (100U + 6 * NR_CPUS),
> + .private = FILE_CPULIST,
> + },
Is it missing CFTYPE_NOT_ON_ROOT? Other files too.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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