Re: [PATCH 04/16] watchdog: remove ks8695 driver

2019-08-10 Thread Arnd Bergmann
On Fri, Aug 9, 2019 at 10:42 PM Guenter Roeck  wrote:
>
> On Fri, Aug 09, 2019 at 10:27:32PM +0200, Arnd Bergmann wrote:
> > The platform is getting removed, so there are no remaining
> > users of this driver.
> >
> > Signed-off-by: Arnd Bergmann 
>
> Acked-by: Guenter Roeck 
>
> Please let me know if this should be applied through the watchdog tree.
> For now I'll assume it will be applied together with the rest of the
> series.

For this series, my preference is that you apply the patches through
the subsystem tree as there are no dependencies.

Thanks,

 Arnd


[PATCH v2 2/2] hwmon: pmbus: Add Inspur Power System power supply driver

2019-08-10 Thread John Wang
Add the driver to monitor Inspur Power System power supplies
with hwmon over pmbus.

This driver adds sysfs attributes for additional power supply data,
including vendor, model, part_number, serial number,
firmware revision, hardware revision, and psu mode(active/standby).

Signed-off-by: John Wang 
---
v2:
- Fix typos in commit message
- Invert Christmas tree
- Configure device with sysfs attrs, not debugfs entries
- Fix errno in fw_version_read, ENODATA to EPROTO
- Change the print format of fw-version
- Use sysfs_streq instead of strcmp("xxx" "\n", "xxx")
- Document sysfs attributes
---
 Documentation/hwmon/inspur-ipsps1.rst |  79 +
 drivers/hwmon/pmbus/Kconfig   |   9 +
 drivers/hwmon/pmbus/Makefile  |   1 +
 drivers/hwmon/pmbus/inspur-ipsps.c| 236 ++
 4 files changed, 325 insertions(+)
 create mode 100644 Documentation/hwmon/inspur-ipsps1.rst
 create mode 100644 drivers/hwmon/pmbus/inspur-ipsps.c

diff --git a/Documentation/hwmon/inspur-ipsps1.rst 
b/Documentation/hwmon/inspur-ipsps1.rst
new file mode 100644
index ..aa19f0ccc8b0
--- /dev/null
+++ b/Documentation/hwmon/inspur-ipsps1.rst
@@ -0,0 +1,79 @@
+Kernel driver inspur-ipsps1
+===
+
+Supported chips:
+
+  * Inspur Power System power supply unit
+
+Author: John Wang 
+
+Description
+---
+
+This driver supports Inspur Power System power supplies. This driver
+is a client to the core PMBus driver.
+
+Usage Notes
+---
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+
+Sysfs entries
+-
+
+The following attributes are supported:
+
+=== ==
+curr1_input Measured input current
+curr1_label "iin"
+curr1_max   Maximum current
+curr1_max_alarm Current high alarm
+curr2_inputMeasured output current in mA.
+curr2_label"iout1"
+curr2_crit  Critical maximum current
+curr2_crit_alarmCurrent critical high alarm
+curr2_max   Maximum current
+curr2_max_alarm Current high alarm
+
+fan1_alarm Fan 1 warning.
+fan1_fault Fan 1 fault.
+fan1_input Fan 1 speed in RPM.
+
+in1_alarm  Input voltage under-voltage alarm.
+in1_input  Measured input voltage in mV.
+in1_label  "vin"
+in2_input  Measured output voltage in mV.
+in2_label  "vout1"
+in2_lcrit   Critical minimum output voltage
+in2_lcrit_alarm Output voltage critical low alarm
+in2_max Maximum output voltage
+in2_max_alarm   Output voltage high alarm
+in2_min Minimum output voltage
+in2_min_alarm   Output voltage low alarm
+
+power1_alarm   Input fault or alarm.
+power1_input   Measured input power in uW.
+power1_label   "pin"
+power1_max  Input power limit
+power2_max_alarm   Output power high alarm
+power2_max  Output power limit
+power2_input   Measured output power in uW.
+power2_label   "pout"
+
+temp[1-3]_inputMeasured temperature
+temp[1-2]_max  Maximum temperature
+temp[1-3]_max_alarmTemperature high alarm
+
+vendor  Manufacturer name
+model   Product model
+part_number Product part number
+serial_number   Product serial number
+fw_version  Firmware version
+hw_version  Hardware version
+modeWork mode. Can be set to active or
+standby, when set to standby, PSU will
+automatically switch between standby
+and redundancy mode.
+=== ==
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 30751eb9550a..c09357c26b10 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -203,4 +203,13 @@ config SENSORS_ZL6100
  This driver can also be built as a module. If so, the module will
  be called zl6100.
 
+config SENSORS_INSPUR_IPSPS
+   tristate "INSPUR Power System Power Supply"
+   help
+ If you say yes here you get hardware monitoring support for the INSPUR
+ Power System power supply.
+
+ This driver can also be built as a module. If so, the module will
+ be called inspur-ipsps.
+
 endif # PMBUS
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 2219b9300316..fde2d10cd05c 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_SENSORS_TPS53679)+= tps53679.o
 obj-$(CONFIG_SENSORS_UCD9000)  += ucd9000.o
 obj-$(CONFIG

[PATCH] Documentation/networking/af_xdp: Inhibit reference to struct socket

2019-08-10 Thread Jonathan Neuschäfer
With the recent change to auto-detect function names, Sphinx parses
socket() as a reference to the in-kernel definition of socket. It then
decides that struct socket is a good match, which was obviously not
intended in this case, because the text speaks about the syscall with
the same name.

Prevent socket() from being misinterpreted by wrapping it in ``inline
literal`` quotes.

Signed-off-by: Jonathan Neuschäfer 
---
 Documentation/networking/af_xdp.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/networking/af_xdp.rst 
b/Documentation/networking/af_xdp.rst
index eeedc2e826aa..54f179ee6c33 100644
--- a/Documentation/networking/af_xdp.rst
+++ b/Documentation/networking/af_xdp.rst
@@ -20,7 +20,7 @@ bpf_redirect_map() function. AF_XDP sockets enable the 
possibility for
 XDP programs to redirect frames to a memory buffer in a user-space
 application.

-An AF_XDP socket (XSK) is created with the normal socket()
+An AF_XDP socket (XSK) is created with the normal ``socket()``
 syscall. Associated with each XSK are two rings: the RX ring and the
 TX ring. A socket can receive packets on the RX ring and it can send
 packets on the TX ring. These rings are registered and sized with the
--
2.20.1



Re: [PATCH 04/16] watchdog: remove ks8695 driver

2019-08-10 Thread Guenter Roeck
On Sat, Aug 10, 2019 at 10:37:14AM +0200, Arnd Bergmann wrote:
> On Fri, Aug 9, 2019 at 10:42 PM Guenter Roeck  wrote:
> >
> > On Fri, Aug 09, 2019 at 10:27:32PM +0200, Arnd Bergmann wrote:
> > > The platform is getting removed, so there are no remaining
> > > users of this driver.
> > >
> > > Signed-off-by: Arnd Bergmann 
> >
> > Acked-by: Guenter Roeck 
> >
> > Please let me know if this should be applied through the watchdog tree.
> > For now I'll assume it will be applied together with the rest of the
> > series.
> 
> For this series, my preference is that you apply the patches through
> the subsystem tree as there are no dependencies.
> 
Ok, I added both patches to my tree.

Thanks,
Guenter


Re: [PATCH] Documentation/networking/af_xdp: Inhibit reference to struct socket

2019-08-10 Thread Jonathan Corbet
On Sat, 10 Aug 2019 14:17:37 +0200
Jonathan Neuschäfer  wrote:

> With the recent change to auto-detect function names, Sphinx parses
> socket() as a reference to the in-kernel definition of socket. It then
> decides that struct socket is a good match, which was obviously not
> intended in this case, because the text speaks about the syscall with
> the same name.
> 
> Prevent socket() from being misinterpreted by wrapping it in ``inline
> literal`` quotes.
> 
> Signed-off-by: Jonathan Neuschäfer 

Thanks for looking at that.  The better fix, though, would be to add
socket() to the Skipfuncs array in Documentation/sphinx/automarkup.py.
Then it will do the right thing everywhere without the need to add markup
to the RST files.

Thanks,

jon


[PATCH v3] powerpc/fadump: sysfs for fadump memory reservation

2019-08-10 Thread Sourabh Jain
Add a sys interface to allow querying the memory reserved by
fadump for saving the crash dump.

Add an ABI doc entry for new sysfs interface.
   - /sys/kernel/fadump_mem_reserved

Signed-off-by: Sourabh Jain 
---
Changelog:
v1 -> v2:
  - Added ABI doc for new sysfs interface.

v2 -> v3:
  - Updated the ABI documentation.
---

 Documentation/ABI/testing/sysfs-kernel-fadump|  6 ++
 Documentation/powerpc/firmware-assisted-dump.rst |  5 +
 arch/powerpc/kernel/fadump.c | 14 ++
 3 files changed, 25 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-kernel-fadump

diff --git a/Documentation/ABI/testing/sysfs-kernel-fadump 
b/Documentation/ABI/testing/sysfs-kernel-fadump
new file mode 100644
index ..ec034939475b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-fadump
@@ -0,0 +1,6 @@
+What:  /sys/kernel/fadump_mem_reserved
+Date:  August 2019
+Contact:   linuxppc-...@lists.ozlabs.org
+Description:   read only
+   Provide information about the amount of memory
+   reserved by fadump to save the crash dump.
diff --git a/Documentation/powerpc/firmware-assisted-dump.rst 
b/Documentation/powerpc/firmware-assisted-dump.rst
index 9ca12830a48e..a5dfb20d4dc3 100644
--- a/Documentation/powerpc/firmware-assisted-dump.rst
+++ b/Documentation/powerpc/firmware-assisted-dump.rst
@@ -222,6 +222,11 @@ Here is the list of files under kernel sysfs:
 be handled and vmcore will not be captured. This interface can be
 easily integrated with kdump service start/stop.
 
+ /sys/kernel/fadump_mem_reserved
+
+   This is used to display the memory reserved by fadump for saving the
+   crash dump.
+
  /sys/kernel/fadump_release_mem
 This file is available only when fadump is active during
 second kernel. This is used to release the reserved memory
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4eab97292cc2..cd373d1d4b82 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -1514,6 +1514,13 @@ static ssize_t fadump_enabled_show(struct kobject *kobj,
return sprintf(buf, "%d\n", fw_dump.fadump_enabled);
 }
 
+static ssize_t fadump_mem_reserved_show(struct kobject *kobj,
+   struct kobj_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, "%ld\n", fw_dump.reserve_dump_area_size);
+}
+
 static ssize_t fadump_register_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -1632,6 +1639,9 @@ static struct kobj_attribute fadump_attr = 
__ATTR(fadump_enabled,
 static struct kobj_attribute fadump_register_attr = __ATTR(fadump_registered,
0644, fadump_register_show,
fadump_register_store);
+static struct kobj_attribute fadump_mem_reserved_attr =
+   __ATTR(fadump_mem_reserved, 0444,
+  fadump_mem_reserved_show, NULL);
 
 DEFINE_SHOW_ATTRIBUTE(fadump_region);
 
@@ -1663,6 +1673,10 @@ static void fadump_init_files(void)
printk(KERN_ERR "fadump: unable to create sysfs file"
" fadump_release_mem (%d)\n", rc);
}
+   rc = sysfs_create_file(kernel_kobj, &fadump_mem_reserved_attr.attr);
+   if (rc)
+   pr_err("unable to create sysfs file fadump_mem_reserved (%d)\n",
+  rc);
return;
 }
 
-- 
2.17.2



[PATCH v2 2/2] rcuperf: Add kfree_rcu performance Tests

2019-08-10 Thread Joel Fernandes (Google)
This test runs kfree_rcu in a loop to measure performance of the new
kfree_rcu batching functionality.

The following table shows results when booting with arguments:
rcuperf.kfree_loops=20 rcuperf.kfree_alloc_num=1000 rcuperf.kfree_rcu_test=1

In addition, rcuperf.kfree_no_batch is used to toggle the batching of
kfree_rcu()s for a test run.

rcuperf.kfree_no_batch  GPs time (seconds)
 0 (default)173215.9
 1  913314.5

Note that the results are the same for the case:
1. Patch is not applied and rcuperf.kfree_no_batch=0
2. Patch is applied and rcuperf.kfree_no_batch=1

On a 16 CPU system with the above boot parameters, we see that the total
number of grace periods that elapse during the test drops from 9133 when
not batching to 1732 when batching (a ~427% improvement). The
kfree_rcu() flood itself slows down a bit when batching, though, as
shown. This is likely due to rcuperf threads contending with the
additional worker threads that are now running both before (the monitor)
and after (the work done to kfree()) the grace period.

Note that the active memory consumption during the kfree_rcu() flood
does increase to around 300-400MB due to the batching (from around 50MB
without batching). However, this memory consumption is relatively
constant and is just an effect of the buffering. In other words, the
system is able to keep up with the kfree_rcu() load.

Also, when running the test, please disable CONFIG_DEBUG_PREEMPT and
CONFIG_PROVE_RCU for realistic comparisons with/without batching.

Signed-off-by: Joel Fernandes (Google) 
---
 kernel/rcu/rcuperf.c | 189 +--
 1 file changed, 181 insertions(+), 8 deletions(-)

diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
index 7a6890b23c5f..70d6ac19cbff 100644
--- a/kernel/rcu/rcuperf.c
+++ b/kernel/rcu/rcuperf.c
@@ -86,6 +86,7 @@ torture_param(bool, shutdown, RCUPERF_SHUTDOWN,
  "Shutdown at end of performance tests.");
 torture_param(int, verbose, 1, "Enable verbose debugging printk()s");
 torture_param(int, writer_holdoff, 0, "Holdoff (us) between GPs, zero to 
disable");
+torture_param(int, kfree_rcu_test, 0, "Do we run a kfree_rcu perf test?");
 
 static char *perf_type = "rcu";
 module_param(perf_type, charp, 0444);
@@ -105,8 +106,8 @@ static atomic_t n_rcu_perf_writer_finished;
 static wait_queue_head_t shutdown_wq;
 static u64 t_rcu_perf_writer_started;
 static u64 t_rcu_perf_writer_finished;
-static unsigned long b_rcu_perf_writer_started;
-static unsigned long b_rcu_perf_writer_finished;
+static unsigned long b_rcu_gp_test_started;
+static unsigned long b_rcu_gp_test_finished;
 static DEFINE_PER_CPU(atomic_t, n_async_inflight);
 
 static int rcu_perf_writer_state;
@@ -379,10 +380,10 @@ rcu_perf_writer(void *arg)
if (atomic_inc_return(&n_rcu_perf_writer_started) >= nrealwriters) {
t_rcu_perf_writer_started = t;
if (gp_exp) {
-   b_rcu_perf_writer_started =
+   b_rcu_gp_test_started =
cur_ops->exp_completed() / 2;
} else {
-   b_rcu_perf_writer_started = cur_ops->get_gp_seq();
+   b_rcu_gp_test_started = cur_ops->get_gp_seq();
}
}
 
@@ -435,10 +436,10 @@ rcu_perf_writer(void *arg)
PERFOUT_STRING("Test complete");
t_rcu_perf_writer_finished = t;
if (gp_exp) {
-   b_rcu_perf_writer_finished =
+   b_rcu_gp_test_finished =
cur_ops->exp_completed() / 2;
} else {
-   b_rcu_perf_writer_finished =
+   b_rcu_gp_test_finished =
cur_ops->get_gp_seq();
}
if (shutdown) {
@@ -523,8 +524,8 @@ rcu_perf_cleanup(void)
 t_rcu_perf_writer_finished -
 t_rcu_perf_writer_started,
 ngps,
-rcuperf_seq_diff(b_rcu_perf_writer_finished,
- b_rcu_perf_writer_started));
+rcuperf_seq_diff(b_rcu_gp_test_finished,
+ b_rcu_gp_test_started));
for (i = 0; i < nrealwriters; i++) {
if (!writer_durations)
break;
@@ -592,6 +593,175 @@ rcu_perf_shutdown(void *arg)
return -EINVAL;
 }
 
+/*
+ * kfree_rcu performance tests: Start a kfree_rcu loop on all CPUs for number
+ * of iterations and measure total time and number of GP for all iterations to 
complete.
+ */
+
+torture_param(int, kfree_nthreads, -1, "Nu

[PATCH v2 1/2] rcu/tree: Add basic support for kfree_rcu batching

2019-08-10 Thread Joel Fernandes (Google)
Recently a discussion about stability and performance of a system
involving a high rate of kfree_rcu() calls surfaced on the list [1]
which led to another discussion how to prepare for this situation.

This patch adds basic batching support for kfree_rcu(). It is "basic"
because we do none of the slab management, dynamic allocation, code
moving or any of the other things, some of which previous attempts did
[2]. These fancier improvements can be follow-up patches and there are
several ideas being discussed in those regards.

Torture tests follow in the next patch and show improvements of around
400% in reduction of number of  grace periods on a 16 CPU system. More
details and test data are in that patch.

This is an effort to start simple, and build up from there. In the
future, an extension to use kfree_bulk and possibly per-slab batching
could be done to further improve performance due to cache-locality and
slab-specific bulk free optimizations.

There is an implication with rcu_barrier() with this patch. Since the
kfree_rcu() calls can be batched, and may not be handed yet to the RCU
machinery in fact, the monitor may not have even run yet to do the
queue_rcu_work(), there seems no easy way of implementing rcu_barrier()
to wait for those kfree_rcu()s that are already made. So this means a
kfree_rcu() followed by an rcu_barrier() does not imply that memory will
be freed once rcu_barrier() returns.

Another implication is higher active memory usage (although not
run-away..) until the kfree_rcu() flooding ends, in comparison to
without batching. More details about this are in the second patch which
adds an rcuperf test.

Finally, in the future we should get rid of kfree_rcu special casing
within RCU such as in rcu_do_batch and switch everything to just
batching. Currently we don't do that since timer subsystem is not yet up
and we cannot schedule the kfree_rcu() monitor as the timer subsystem's
lock are not initialized. That would also mean getting rid of
kfree_call_rcu_nobatch() entirely.

[1] http://lore.kernel.org/lkml/20190723035725-mutt-send-email-...@kernel.org
[2] https://lkml.org/lkml/2017/12/19/824

Cc: Rao Shoaib 
Cc: max.byungchul.p...@gmail.com
Cc: byungchul.p...@lge.com
Cc: kernel-t...@android.com
Cc: kernel-t...@lge.com
Co-developed-by: Byungchul Park 
Signed-off-by: Byungchul Park 
Signed-off-by: Joel Fernandes (Google) 

---
RFC v1-> PATCH v2: Removed limits on the ->head list, just let it grow.
   Dropped KFREE_MAX_JIFFIES to HZ/50 from HZ/20 to reduce OOM 
occurrence.
   Removed sleeps in rcuperf test, just using cond_resched()in 
loop.
   Better code comments ;)

 .../admin-guide/kernel-parameters.txt |  17 ++
 include/linux/rcutiny.h   |   5 +
 include/linux/rcutree.h   |   1 +
 kernel/rcu/tree.c | 213 +-
 4 files changed, 230 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 7ccd158b3894..a9156ca5de24 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3895,6 +3895,23 @@
test until boot completes in order to avoid
interference.
 
+   rcuperf.kfree_rcu_test= [KNL]
+   Set to measure performance of kfree_rcu() flooding.
+
+   rcuperf.kfree_nthreads= [KNL]
+   The number of threads running loops of kfree_rcu().
+
+   rcuperf.kfree_alloc_num= [KNL]
+   Number of allocations and frees done in an iteration.
+
+   rcuperf.kfree_loops= [KNL]
+   Number of loops doing rcuperf.kfree_alloc_num number
+   of allocations and frees.
+
+   rcuperf.kfree_no_batch= [KNL]
+   Use the non-batching (slower) version of kfree_rcu.
+   This is useful for comparing with the batched version.
+
rcuperf.nreaders= [KNL]
Set number of RCU readers.  The value -1 selects
N, where N is the number of CPUs.  A value
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 8e727f57d814..383f2481750f 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -39,6 +39,11 @@ static inline void kfree_call_rcu(struct rcu_head *head, 
rcu_callback_t func)
call_rcu(head, func);
 }
 
+static inline void kfree_call_rcu_nobatch(struct rcu_head *head, 
rcu_callback_t func)
+{
+   call_rcu(head, func);
+}
+
 void rcu_qs(void);
 
 static inline void rcu_softirq_qs(void)
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 735601ac27d3..7e38b39ec634 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -34,6 +34,7 @@ static inline void rcu_virt_note_context_switch(int cpu)
 
 void synchronize_rcu_expedited(v