[PATCH] sched/deadline: add overrun signal and GRUB-PA in the documentation

2018-04-03 Thread Claudio Scordino 
Signed-off-by: Claudio Scordino 
CC: Juri Lelli 
CC: Luca Abeni 
CC: linux-ker...@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
 Documentation/scheduler/sched-deadline.txt | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/scheduler/sched-deadline.txt 
b/Documentation/scheduler/sched-deadline.txt
index 8ce78f8..b14e03f 100644
--- a/Documentation/scheduler/sched-deadline.txt
+++ b/Documentation/scheduler/sched-deadline.txt
@@ -49,7 +49,7 @@ CONTENTS
 2.1 Main algorithm
 --
 
- SCHED_DEADLINE uses three parameters, named "runtime", "period", and
+ SCHED_DEADLINE [18] uses three parameters, named "runtime", "period", and
  "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
  "runtime" microseconds of execution time every "period" microseconds, and
  these "runtime" microseconds are available within "deadline" microseconds
@@ -117,6 +117,10 @@ CONTENTS
  scheduling deadline = scheduling deadline + period
  remaining runtime = remaining runtime + runtime
 
+ The SCHED_FLAG_DL_OVERRUN flag in sched_attr's sched_flags field allows a task
+ to get informed about runtime overruns through the delivery of SIGXCPU
+ signals.
+
 
 2.2 Bandwidth reclaiming
 
@@ -279,6 +283,19 @@ CONTENTS
 running_bw is incremented.
 
 
+2.3 Energy-aware scheduling
+
+
+ When cpufreq's schedutil governor is selected, SCHED_DEADLINE implements the
+ GRUB-PA [19] algorithm, reducing the CPU operating frequency to the minimum
+ value that still allows to meet the deadlines. This behavior is currently
+ implemented only for ARM architectures.
+
+ A particular care must be taken in case the time needed for changing frequency
+ is of the same order of magnitude of the reservation period. In such cases,
+ setting a fixed CPU frequency results in a lower amount of deadline misses.
+
+
 3. Scheduling Real-Time Tasks
 =
 
@@ -505,6 +522,12 @@ CONTENTS
   17 - L. Abeni, G. Lipari, A. Parri, Y. Sun, Multicore CPU reclaiming: 
parallel
or sequential?. In Proceedings of the 31st Annual ACM Symposium on 
Applied
Computing, 2016.
+  18 - J. Lelli, C. Scordino, L. Abeni, D. Faggioli, Deadline scheduling in the
+   Linux kernel, Software: Practice and Experience, 46(6): 821-839, June
+   2016.
+  19 - C. Scordino, L. Abeni, J. Lelli, Energy-Aware Real-Time Scheduling in
+   the Linux Kernel, 33rd ACM/SIGAPP Symposium On Applied Computing (SAC
+   2018), Pau, France, April 2018.
 
 
 4. Bandwidth management
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 7/8] clocksource: Add a new timer-ingenic driver

2018-04-03 Thread Daniel Lezcano 
On 31/03/2018 19:46, Paul Cercueil wrote:
> Le 2018-03-31 10:10, Daniel Lezcano a écrit :
>> On 29/03/2018 16:52, Paul Cercueil wrote:
>>>
>>>
>>> Le mer. 28 mars 2018 à 18:25, Daniel Lezcano 
>>> a écrit :
 On 28/03/2018 17:15, Paul Cercueil wrote:
>  Le 2018-03-24 07:26, Daniel Lezcano a écrit :
>>  On 18/03/2018 00:29, Paul Cercueil wrote:
>>>  This driver will use the TCU (Timer Counter Unit) present on the
>>> Ingenic
>>>  JZ47xx SoCs to provide the kernel with a clocksource and timers.
>>
>>  Please provide a more detailed description about the timer.
>
>  There's a doc file for that :)

 Usually, when there is a new driver I ask for a description in the
 changelog for reference.

>>  Where is the clocksource ?
>
>  Right, there is no clocksource, just timers.
>
>>  I don't see the point of using channel idx and pwm checking here.
>>
>>  There is one clockevent, why create multiple channels ? Can't you
>> stick
>>  to the usual init routine for a timer.
>
>  So the idea is that we use all the TCU channels that won't be used
> for PWM
>  as timers. Hence the PWM checking. Why is this bad?

 It is not bad but arguable. By checking the channels used by the pwm in
 the code, you introduce an adherence between two subsystems even if it
 is just related to the DT parsing part.

 As it is not needed to have more than one timer in the time framework
 (at least with the same characteristics), the pwm channels check is
 pointless. We can assume the author of the DT file is smart enough to
 prevent conflicts and define a pwm and a timer properly instead of
 adding more code complexity.

 In addition, simplifying the code will allow you to use the timer-of
 code and reduce very significantly the init function.
>>>
>>> That's what I had in my V1 and V2, my DT node for the timer-ingenic
>>> driver
>>> had a "timers" property (e.g. "timers = <4 5>;") to select the channels
>>> that
>>> should be used as timers. Then Rob told me I shouldn't do that, and
>>> instead
>>> detect the channels that will be used for PWM.
>>>
>>
>> [ ... ]
>>
>> How do you specify the channels used for PWM ?
> 
> To detect the channels that will be used as PWM I parse the whole
> devicetree
> searching for "pwms" properties; check that the PWM handle is for our
> TCU PWM
> driver; then read the PWM number from there.
> 
> Of course it's hackish, and it only works for devicetree. I preferred the
> method with the "timers" property.

Do you have a DT portion describing that? Eg somewhere in the kernel's
git tree ?

>From what I understood, we can specify the channel for a pwm but not for
a timer, there is certainly something I'm missing.

>>>
>>>  +config INGENIC_TIMER
>>>  +    bool "Clocksource/timer using the TCU in Ingenic JZ SoCs"
>>>  +    depends on MACH_INGENIC || COMPILE_TEST
>>
>>  bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if
>> COMPILE_TEST
>>
>>  Remove the depends MACH_INGENIC.
>
>  This driver is not useful on anything else than Ingenic SoCs, why
> should I
>  remove MACH_INGENIC then?

 For COMPILE_TEST on x86.
>>>
>>> Well that's a logical OR right here, so it will work...
>>
>> Right, I missed the second part of the condition. For consistency
>> reason, we don't add a dependency on the platform. The platform will
>> select it. Look the other timer options and you will see there is no
>> MACH deps. I'm trying consolidating all these options to have same
>> format and hopefully factor them out.
> 
> I'm all for factorisation, but what I dislike with not depending on
> MACH_INGENIC, is that the driver now appears in the menuconfig for
> every arch, even if it only applies to one MIPS SoC.

Can you do the following change?

bool "Clocksource/timer using the TCU in Ingenic JZ SoCs" if COMPILE_TEST

so it will appear only when the COMPILE_TEST option is set whatever the
platform which is the purpose of this option to increase compile test
coverage.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/6] Disable instrumentation for some code

2018-04-03 Thread Marc Zyngier 
On 02/04/18 13:04, Abbott Liu wrote:
> From: Andrey Ryabinin 
> 
> Disable instrumentation for arch/arm/boot/compressed/*
> ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those
> code won't linkd with kernel image.
> 
> Disable kasan check in the function unwind_pop_register
> because it doesn't matter that kasan checks failed when
> unwind_pop_register read stack memory of task.
> 
> Reviewed-by: Russell King - ARM Linux 
> Reviewed-by: Florian Fainelli 
> Reviewed-by: Marc Zyngier 

Just because I replied to this patch doesn't mean you can stick my
Reviewed-by tag on it. Please drop this tag until I explicitly say that
you can add it (see Documentation/process/submitting-patches.rst,
section 11).

Same goes for patch 1.

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/6] Disable instrumentation for some code

2018-04-03 Thread Russell King - ARM Linux 
On Tue, Apr 03, 2018 at 12:30:42PM +0100, Marc Zyngier wrote:
> On 02/04/18 13:04, Abbott Liu wrote:
> > From: Andrey Ryabinin 
> > 
> > Disable instrumentation for arch/arm/boot/compressed/*
> > ,arch/arm/kvm/hyp/* and arch/arm/vdso/* because those
> > code won't linkd with kernel image.
> > 
> > Disable kasan check in the function unwind_pop_register
> > because it doesn't matter that kasan checks failed when
> > unwind_pop_register read stack memory of task.
> > 
> > Reviewed-by: Russell King - ARM Linux 
> > Reviewed-by: Florian Fainelli 
> > Reviewed-by: Marc Zyngier 
> 
> Just because I replied to this patch doesn't mean you can stick my
> Reviewed-by tag on it. Please drop this tag until I explicitly say that
> you can add it (see Documentation/process/submitting-patches.rst,
> section 11).
> 
> Same goes for patch 1.

Same goes for that reviewed-by line for me.  From my records, I never
even looked at patch 2 from the first posting, and I don't appear to
have the second posting in my mailbox (it's probably been classed as
spam by dspam.)  So these reviewed-by lines seem to be totally
misleading.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] Documentation/features: Refresh and auto-generate the arch support status files in place

2018-04-03 Thread Andrea Parri 
Signed-off-by: Andrea Parri 
---
 .../features/core/cBPF-JIT/arch-support.txt| 27 ++
 .../features/core/eBPF-JIT/arch-support.txt| 27 ++
 .../core/generic-idle-thread/arch-support.txt  |  3 ++-
 .../features/core/jump-labels/arch-support.txt |  1 +
 .../features/core/tracehook/arch-support.txt   |  1 +
 .../features/debug/KASAN/arch-support.txt  |  3 ++-
 .../debug/gcov-profile-all/arch-support.txt|  1 +
 Documentation/features/debug/kgdb/arch-support.txt |  3 ++-
 .../debug/kprobes-on-ftrace/arch-support.txt   |  1 +
 .../features/debug/kprobes/arch-support.txt|  3 ++-
 .../features/debug/kretprobes/arch-support.txt |  3 ++-
 .../features/debug/optprobes/arch-support.txt  |  3 ++-
 .../features/debug/stackprotector/arch-support.txt |  1 +
 .../features/debug/uprobes/arch-support.txt|  5 ++--
 .../debug/user-ret-profiler/arch-support.txt   |  1 +
 .../features/io/dma-api-debug/arch-support.txt |  1 +
 .../features/io/dma-contiguous/arch-support.txt|  3 ++-
 .../features/io/sg-chain/arch-support.txt  |  1 +
 .../features/lib/strncasecmp/arch-support.txt  |  1 +
 .../locking/cmpxchg-local/arch-support.txt |  3 ++-
 .../features/locking/lockdep/arch-support.txt  |  3 ++-
 .../locking/queued-rwlocks/arch-support.txt|  9 
 .../locking/queued-spinlocks/arch-support.txt  |  7 +++---
 .../locking/rwsem-optimized/arch-support.txt   |  1 +
 .../features/perf/kprobes-event/arch-support.txt   |  5 ++--
 .../features/perf/perf-regs/arch-support.txt   |  3 ++-
 .../features/perf/perf-stackdump/arch-support.txt  |  3 ++-
 .../sched/membarrier-sync-core/arch-support.txt|  1 +
 .../features/sched/numa-balancing/arch-support.txt |  5 ++--
 .../seccomp/seccomp-filter/arch-support.txt|  5 ++--
 .../time/arch-tick-broadcast/arch-support.txt  |  3 ++-
 .../features/time/clockevents/arch-support.txt |  3 ++-
 .../time/context-tracking/arch-support.txt |  1 +
 .../features/time/irq-time-acct/arch-support.txt   |  3 ++-
 .../time/modern-timekeeping/arch-support.txt   |  1 +
 .../features/time/virt-cpuacct/arch-support.txt|  1 +
 .../features/vm/ELF-ASLR/arch-support.txt  |  3 ++-
 .../features/vm/PG_uncached/arch-support.txt   |  1 +
 Documentation/features/vm/THP/arch-support.txt |  1 +
 Documentation/features/vm/TLB/arch-support.txt |  1 +
 .../features/vm/huge-vmap/arch-support.txt |  1 +
 .../features/vm/ioremap_prot/arch-support.txt  |  1 +
 .../features/vm/numa-memblock/arch-support.txt |  3 ++-
 .../features/vm/pte_special/arch-support.txt   |  1 +
 44 files changed, 127 insertions(+), 31 deletions(-)

diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt 
b/Documentation/features/core/cBPF-JIT/arch-support.txt
index 2ae2a7106e67d..6b829e27c268a 100644
--- a/Documentation/features/core/cBPF-JIT/arch-support.txt
+++ b/Documentation/features/core/cBPF-JIT/arch-support.txt
@@ -3,3 +3,30 @@
 # Kconfig:   HAVE_CBPF_JIT
 # description:   arch supports cBPF JIT optimizations
 #
+---
+| arch |status|
+---
+|   alpha: | TODO |
+| arc: | TODO |
+| arm: | TODO |
+|   arm64: | TODO |
+| c6x: | TODO |
+|   h8300: | TODO |
+| hexagon: | TODO |
+|ia64: | TODO |
+|m68k: | TODO |
+|  microblaze: | TODO |
+|mips: |  ok  |
+|   nios2: | TODO |
+|openrisc: | TODO |
+|  parisc: | TODO |
+| powerpc: |  ok  |
+|   riscv: | TODO |
+|s390: | TODO |
+|  sh: | TODO |
+|   sparc: |  ok  |
+|  um: | TODO |
+|   unicore32: | TODO |
+| x86: | TODO |
+|  xtensa: | TODO |
+---
diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt 
b/Documentation/features/core/eBPF-JIT/arch-support.txt
index c8b0b458b9cec..4a4ab34ee293a 100644
--- a/Documentation/features/core/eBPF-JIT/arch-support.txt
+++ b/Documentation/features/core/eBPF-JIT/arch-support.txt
@@ -3,3 +3,30 @@
 # Kconfig:   HAVE_EBPF_JIT
 # description:   arch supports eBPF JIT optimizations
 #
+---
+| arch |status|
+---
+|   alpha: | TODO |
+| arc: | TODO |
+| arm: |  ok  |
+|   arm64: |  ok  |
+| c6x: | TODO |
+|   h8300: | TODO |
+| hexagon: | TODO |
+|ia64: | TODO |
+|m68k: | TODO |
+|  microblaze: | TODO |
+|mips: |  ok  |
+|   nios2: | TODO |
+|openrisc: | TODO |
+|  parisc: | TODO |
+| powerpc: |  ok  |
+|   riscv: | TODO |
+|s390: |  ok  |
+|  sh: | TODO |
+|

[PATCH 2/3] Documentation/features/core: Add arch support status files for 'cBPF-JIT' and 'eBPF-JIT'

2018-04-03 Thread Andrea Parri 
Signed-off-by: Andrea Parri 
---
 .../features/core/BPF-JIT/arch-support.txt | 31 --
 .../features/core/cBPF-JIT/arch-support.txt|  5 
 .../features/core/eBPF-JIT/arch-support.txt|  5 
 3 files changed, 10 insertions(+), 31 deletions(-)
 delete mode 100644 Documentation/features/core/BPF-JIT/arch-support.txt
 create mode 100644 Documentation/features/core/cBPF-JIT/arch-support.txt
 create mode 100644 Documentation/features/core/eBPF-JIT/arch-support.txt

diff --git a/Documentation/features/core/BPF-JIT/arch-support.txt 
b/Documentation/features/core/BPF-JIT/arch-support.txt
deleted file mode 100644
index 0b96b4e1e7d4a..0
--- a/Documentation/features/core/BPF-JIT/arch-support.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-#
-# Feature name:  BPF-JIT
-# Kconfig:   HAVE_BPF_JIT
-# description:   arch supports BPF JIT optimizations
-#
----
-| arch |status|
----
-|   alpha: | TODO |
-| arc: | TODO |
-| arm: |  ok  |
-|   arm64: |  ok  |
-| c6x: | TODO |
-|   h8300: | TODO |
-| hexagon: | TODO |
-|ia64: | TODO |
-|m68k: | TODO |
-|  microblaze: | TODO |
-|mips: |  ok  |
-|   nios2: | TODO |
-|openrisc: | TODO |
-|  parisc: | TODO |
-| powerpc: |  ok  |
-|s390: |  ok  |
-|  sh: | TODO |
-|   sparc: |  ok  |
-|  um: | TODO |
-|   unicore32: | TODO |
-| x86: |  ok  |
-|  xtensa: | TODO |
----
diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt 
b/Documentation/features/core/cBPF-JIT/arch-support.txt
new file mode 100644
index 0..2ae2a7106e67d
--- /dev/null
+++ b/Documentation/features/core/cBPF-JIT/arch-support.txt
@@ -0,0 +1,5 @@
+#
+# Feature name:  cBPF-JIT
+# Kconfig:   HAVE_CBPF_JIT
+# description:   arch supports cBPF JIT optimizations
+#
diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt 
b/Documentation/features/core/eBPF-JIT/arch-support.txt
new file mode 100644
index 0..c8b0b458b9cec
--- /dev/null
+++ b/Documentation/features/core/eBPF-JIT/arch-support.txt
@@ -0,0 +1,5 @@
+#
+# Feature name:  eBPF-JIT
+# Kconfig:   HAVE_EBPF_JIT
+# description:   arch supports eBPF JIT optimizations
+#
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] Documentation/features: Add script that refreshes the arch support status files in place

2018-04-03 Thread Andrea Parri 
Suggested-by: Ingo Molnar 
Signed-off-by: Andrea Parri 
---
 Documentation/features/scripts/features-refresh.sh | 55 ++
 1 file changed, 55 insertions(+)
 create mode 100755 Documentation/features/scripts/features-refresh.sh

diff --git a/Documentation/features/scripts/features-refresh.sh 
b/Documentation/features/scripts/features-refresh.sh
new file mode 100755
index 0..ae3e9d5d3f262
--- /dev/null
+++ b/Documentation/features/scripts/features-refresh.sh
@@ -0,0 +1,55 @@
+#
+# Small script that refreshes the kernel feature support status in place.
+#
+
+for F_FILE in Documentation/features/*/*/arch-support.txt; do
+   K=$(grep "^# Kconfig:" "$F_FILE" | cut -c26-)
+   K_VALID="false" # K is 'valid' iff there exists a Kconfig file
+   # (for some arch) containing K.
+
+   for ARCH_DIR in arch/*/; do
+   K_FILES=$(find $ARCH_DIR -name "Kconfig*")
+
+   K_GREP=$(grep "$K" $K_FILES)
+   if [ ! -z "$K_GREP" ]; then
+   K_VALID="true"
+   break
+   fi
+   done
+
+   if [ "$K_VALID" = "false" ]; then
+   printf "WARNING: '%s' is not a valid Kconfig\n" "$K"
+   fi
+
+   T_FILE="$F_FILE.tmp"
+
+   grep "^#" $F_FILE > $T_FILE
+   echo "---" >> $T_FILE
+   echo "| arch |status|" >> $T_FILE
+   echo "---" >> $T_FILE
+
+   for ARCH_DIR in arch/*/; do
+   ARCH=$(echo $ARCH_DIR | sed -e 's/arch//g' | sed -e 's/\///g')
+   K_FILES=$(find $ARCH_DIR -name "Kconfig*")
+
+   K_GREP=$(grep "$K" $K_FILES)
+   if [ ! -z "$K_GREP" ]; then
+   # K is 'supported by a given arch', if there exists
+   # a Kconfig file for this arch containing K.
+   printf "|%12s: |  ok  |\n" "$ARCH" >> $T_FILE
+   else
+   # ... Otherwise: Keep the original status (if any);
+   # default to "not yet supported".
+   S=$(grep -v "^#" "$F_FILE" | grep " $ARCH:")
+   if [ ! -z "$S" ]; then
+   echo "$S" >> $T_FILE
+   else
+   printf "|%12s: | TODO |\n" "$ARCH" \
+   >> $T_FILE
+   fi
+   fi
+   done
+
+   echo "---" >> $T_FILE
+   mv $T_FILE $F_FILE
+done
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

2018-04-03 Thread Andrea Parri 
In Ingo's words [1]:

  "[...]  what should be done instead is to write a script that refreshes
   all the arch-support.txt files in-place. [...]

   It's OK for the script to have various quirks for weirdly implemented
   features and exceptions: i.e. basically whenever it gets a feature wrong,
   we can just tweak the script with quirks to make it all work out of box.

   [...]  But in the end there should only be a single new script:

 Documentation/features/scripts/features-refresh.sh

   ... which operates on the arch-support.txt files and refreshes them in
   place, and which, after all the refreshes have been committed, should
   produce an empty 'git diff' result."

  "[...]  New features can then be added by basically just creating a
   header-only arch-support.txt file, such as:

 triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
 #
 # Feature name:  shiny new fubar kernel feature
 # Kconfig:   ARCH_USE_FUBAR
 # description:   arch supports the fubar feature
 #

   And running Documentation/features/scripts/features-refresh.sh would
   auto-generate the arch support matrix. [...]
 
   This way we soft- decouple the refreshing of the entries from the
   introduction of the features, while still making it all easy to keep
   sync and to extend."

This RFC presents a first attempt to implement such a feature/script, and
applies it script on top of Arnd's:

  git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
arch-removal

Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
"BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
"eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
also printed to standard output the following warnings:

  WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
  WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
  WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
  WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig

(I'm sending these patches with empty commit messagges, for early feedback:
 I'll fill in these messages in subsequent versions if this makes sense...)

Cheers,
  Andrea

Andrea Parri (3):
  Documentation/features: Add script that refreshes the arch support
status files in place
  Documentation/features/core: Add arch support status files for
'cBPF-JIT' and 'eBPF-JIT'
  Documentation/features: Refresh and auto-generate the arch support
status files in place

 .../features/core/BPF-JIT/arch-support.txt | 31 
 .../features/core/cBPF-JIT/arch-support.txt| 32 +
 .../features/core/eBPF-JIT/arch-support.txt| 32 +
 .../core/generic-idle-thread/arch-support.txt  |  3 +-
 .../features/core/jump-labels/arch-support.txt |  1 +
 .../features/core/tracehook/arch-support.txt   |  1 +
 .../features/debug/KASAN/arch-support.txt  |  3 +-
 .../debug/gcov-profile-all/arch-support.txt|  1 +
 Documentation/features/debug/kgdb/arch-support.txt |  3 +-
 .../debug/kprobes-on-ftrace/arch-support.txt   |  1 +
 .../features/debug/kprobes/arch-support.txt|  3 +-
 .../features/debug/kretprobes/arch-support.txt |  3 +-
 .../features/debug/optprobes/arch-support.txt  |  3 +-
 .../features/debug/stackprotector/arch-support.txt |  1 +
 .../features/debug/uprobes/arch-support.txt|  5 +-
 .../debug/user-ret-profiler/arch-support.txt   |  1 +
 .../features/io/dma-api-debug/arch-support.txt |  1 +
 .../features/io/dma-contiguous/arch-support.txt|  3 +-
 .../features/io/sg-chain/arch-support.txt  |  1 +
 .../features/lib/strncasecmp/arch-support.txt  |  1 +
 .../locking/cmpxchg-local/arch-support.txt |  3 +-
 .../features/locking/lockdep/arch-support.txt  |  3 +-
 .../locking/queued-rwlocks/arch-support.txt|  9 ++--
 .../locking/queued-spinlocks/arch-support.txt  |  7 +--
 .../locking/rwsem-optimized/arch-support.txt   |  1 +
 .../features/perf/kprobes-event/arch-support.txt   |  5 +-
 .../features/perf/perf-regs/arch-support.txt   |  3 +-
 .../features/perf/perf-stackdump/arch-support.txt  |  3 +-
 .../sched/membarrier-sync-core/arch-support.txt|  1 +
 .../features/sched/numa-balancing/arch-support.txt |  5 +-
 Documentation/features/scripts/features-refresh.sh | 55 ++
 .../seccomp/seccomp-filter/arch-support.txt|  5 +-
 .../time/arch-tick-broadcast/arch-support.txt  |  3 +-
 .../features/time/clockevents/arch-support.txt |  3 +-
 .../time/context-tracking/arch-support.txt |  1 +
 .../features/time/irq-time-acct/arch-support.txt   |  3 +-
 .../time/modern-timekeeping/arch-support.txt   |  1 +
 .../features/time/virt-cpuacct/arch-support.txt|  1 +
 .../features/vm/ELF-ASLR/arch-support.txt  |  3 +-
 .../features/vm/PG_uncached/arch-support.txt   |  1 +
 Documentation/fea

Re: [PATCH v6 2/5] soc: qcom: Add GENI based QUP Wrapper driver

2018-04-03 Thread Evan Green 
On Fri, Mar 30, 2018 at 10:08 AM Karthikeyan Ramasubramanian <
krama...@codeaurora.org> wrote:

> This driver manages the Generic Interface (GENI) firmware based Qualcomm
> Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
> programmable module composed of multiple Serial Engines (SE) and supports
> a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This
> driver also enables managing the serial interface independent aspects of
> Serial Engines.

> Signed-off-by: Karthikeyan Ramasubramanian 
> Signed-off-by: Sagar Dharia 
> Signed-off-by: Girish Mahadevan 
> ---
>   drivers/soc/qcom/Kconfig|   9 +
>   drivers/soc/qcom/Makefile   |   1 +
>   drivers/soc/qcom/qcom-geni-se.c | 748

>   include/linux/qcom-geni-se.h| 425 +++
>   4 files changed, 1183 insertions(+)
>   create mode 100644 drivers/soc/qcom/qcom-geni-se.c
>   create mode 100644 include/linux/qcom-geni-se.h


Reviewed-by: Evan Green 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] perf: riscv: Add Document for Future Porting Guide

2018-04-03 Thread Alex Solomatnikov 
Doc fixes:


diff --git a/Documentation/riscv/pmu.txt b/Documentation/riscv/pmu.txt
index a3e930e..ae90a5e 100644
--- a/Documentation/riscv/pmu.txt
+++ b/Documentation/riscv/pmu.txt
@@ -20,7 +20,7 @@ the lack of the following general architectural
performance monitoring features:
 * Enabling/Disabling counters
   Counters are just free-running all the time in our case.
 * Interrupt caused by counter overflow
-  No such design in the spec.
+  No such feature in the spec.
 * Interrupt indicator
   It is not possible to have many interrupt ports for all counters, so an
   interrupt indicator is required for software to tell which counter has
@@ -159,14 +159,14 @@ interrupt for perf, so the details are to be
completed in the future.

 They seem symmetric but perf treats them quite differently.  For reading, there
 is a *read* interface in *struct pmu*, but it serves more than just reading.
-According to the context, the *read* function not only read the content of the
-counter (event->count), but also update the left period to the next interrupt
+According to the context, the *read* function not only reads the content of the
+counter (event->count), but also updates the left period for the next interrupt
 (event->hw.period_left).

 But the core of perf does not need direct write to counters.  Writing counters
-hides behind the abstraction of 1) *pmu->start*, literally start
counting so one
+is hidden behind the abstraction of 1) *pmu->start*, literally start
counting so one
 has to set the counter to a good value for the next interrupt; 2)
inside the IRQ
-it should set the counter with the same reason.
+it should set the counter to the same reasonable value.

 Reading is not a problem in RISC-V but writing would need some effort, since
 counters are not allowed to be written by S-mode.
@@ -190,37 +190,37 @@ Three states (event->hw.state) are defined:
 A normal flow of these state transitions are as follows:

 * A user launches a perf event, resulting in calling to *event_init*.
-* When being context-switched in, *add* is called by the perf core, with flag
-  PERF_EF_START, which mean that the event should be started after it is added.
-  In this stage, an general event is binded to a physical counter, if any.
+* When being context-switched in, *add* is called by the perf core, with a flag
+  PERF_EF_START, which means that the event should be started after
it is added.
+  At this stage, a general event is bound to a physical counter, if any.
   The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE,
because it is now
   stopped, and the (software) event count does not need updating.
 ** *start* is then called, and the counter is enabled.
-   With flag PERF_EF_RELOAD, it write the counter to an appropriate
value (check
-   previous section for detail).
-   No writing is made if the flag does not contain PERF_EF_RELOAD.
-   The state now is reset to none, because it is neither stopped nor update
-   (the counting already starts)
-* When being context-switched out, *del* is called.  It then checkout all the
-  events in the PMU and call *stop* to update their counts.
+   With flag PERF_EF_RELOAD, it writes an appropriate value to the
counter (check
+   the previous section for details).
+   Nothing is written if the flag does not contain PERF_EF_RELOAD.
+   The state now is reset to none, because it is neither stopped nor updated
+   (the counting already started)
+* When being context-switched out, *del* is called.  It then checks out all the
+  events in the PMU and calls *stop* to update their counts.
 ** *stop* is called by *del*
and the perf core with flag PERF_EF_UPDATE, and it often shares the same
subroutine as *read* with the same logic.
The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, again.

-** Life cycles of these two pairs: *add* and *del* are called repeatedly as
+** Life cycle of these two pairs: *add* and *del* are called repeatedly as
   tasks switch in-and-out; *start* and *stop* is also called when the perf core
   needs a quick stop-and-start, for instance, when the interrupt
period is being
   adjusted.

-Current implementation is sufficient for now and can be easily extend to
+Current implementation is sufficient for now and can be easily
extended with new
 features in the future.

 A. Related Structures
 -

-* struct pmu: include/linux/perf_events.h
-* struct riscv_pmu: arch/riscv/include/asm/perf_events.h
+* struct pmu: include/linux/perf_event.h
+* struct riscv_pmu: arch/riscv/include/asm/perf_event.h

   Both structures are designed to be read-only.

@@ -231,13 +231,13 @@ perf's internal state machine (check
kernel/events/core.c for details).
   *struct riscv_pmu* defines PMU-specific parameters.  The naming follows the
 convention of all other architectures.

-* struct perf_event: include/linux/perf_events.h
+* struct perf_event: include/linux/perf_event.h
 * struct hw_perf_event

   The generic structure that represents perf events, and

Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

2018-04-03 Thread Ingo Molnar 

* Andrea Parri  wrote:

> In Ingo's words [1]:
> 
>   "[...]  what should be done instead is to write a script that refreshes
>all the arch-support.txt files in-place. [...]
> 
>It's OK for the script to have various quirks for weirdly implemented
>features and exceptions: i.e. basically whenever it gets a feature wrong,
>we can just tweak the script with quirks to make it all work out of box.
> 
>[...]  But in the end there should only be a single new script:
> 
>  Documentation/features/scripts/features-refresh.sh
> 
>... which operates on the arch-support.txt files and refreshes them in
>place, and which, after all the refreshes have been committed, should
>produce an empty 'git diff' result."
> 
>   "[...]  New features can then be added by basically just creating a
>header-only arch-support.txt file, such as:
> 
>  triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
>  #
>  # Feature name:  shiny new fubar kernel feature
>  # Kconfig:   ARCH_USE_FUBAR
>  # description:   arch supports the fubar feature
>  #
> 
>And running Documentation/features/scripts/features-refresh.sh would
>auto-generate the arch support matrix. [...]
>  
>This way we soft- decouple the refreshing of the entries from the
>introduction of the features, while still making it all easy to keep
>sync and to extend."
> 
> This RFC presents a first attempt to implement such a feature/script, and
> applies it script on top of Arnd's:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> arch-removal
> 
> Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
> "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> "eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
> also printed to standard output the following warnings:
> 
>   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
>   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
>   WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
>   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> 
> (I'm sending these patches with empty commit messagges, for early feedback:
>  I'll fill in these messages in subsequent versions if this makes sense...)
> 
> Cheers,
>   Andrea
> 
> Andrea Parri (3):
>   Documentation/features: Add script that refreshes the arch support status 
> files in place
>   Documentation/features/core: Add arch support status files for 'cBPF-JIT' 
> and 'eBPF-JIT'
>   Documentation/features: Refresh and auto-generate the arch support status 
> files in place

Ok, this series is really impressive at its RFC stage already!

Beyond fixing those warnings, I'd also suggest another change: please make the 
new BPF features patch the last one, so that the 'refresh' patch shows how much 
original bit-rot we gathered recently.

The 'new features' patch should then also include the result of also running 
the 
script, i.e. a single patch adding the base fields and the generated parts as 
well. That will be the usual development flow anyway - people won't do two-part 
patches just to show which bits are by hand and which are auto-generated.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html