Re: [PATCH v4 2/2] tpm: add support for nonblocking operation

[Tadeusz Struk]

On 08/10/2018 12:00 PM, James Bottomley wrote:
> On Fri, 2018-08-10 at 11:56 -0700, Tadeusz Struk wrote:
>> On 08/10/2018 11:48 AM, James Bottomley wrote:
>>> On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
 and the feedback I got from Jason was:

 "I wonder if it is worth creating this when the first file is
 opened.. Lots of systems have TPMs but few use the userspace.."

 so I changed this to allocate the WQ on first open. I think it
 makes sense, but I leave it to you to decide.
>>>
>>> If the reason is to not create a wq unless it's needed, shouldn't
>>> the condition actually be first open with flag O_NONBLOCK?
>>>
>>
>> Not really because one can do:
>>
>> int fd = open("/dev/tpm0", O_RDWR);
>> fcntl(fd, F_SETFL, O_NONBLOCK);
> 
> so move the condition to first need to queue ...
> 

That would work, even though this is not how this is usually done.
The first open looks like the sweet spot between module init
and first need to queue.
Thanks,
-- 
Tadeusz

[PATCH] iio: adc: qcom-spmi-adc5: Add ADC5_AMUX_THM[24]_100K_PU to rev2 channel list

[Matthias Kaehlcke]

Add ADC5_AMUX_THM2_100K_PU and ADC5_AMUX_THM4_100K_PU to the list of
rev2 ADC channels.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/iio/adc/qcom-spmi-adc5.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/iio/adc/qcom-spmi-adc5.c b/drivers/iio/adc/qcom-spmi-adc5.c
index a4299417f3de..1f9298a5c83d 100644
--- a/drivers/iio/adc/qcom-spmi-adc5.c
+++ b/drivers/iio/adc/qcom-spmi-adc5.c
@@ -491,8 +491,12 @@ static const struct adc5_channels 
adc5_chans_rev2[ADC5_MAX_CHANNEL] = {
SCALE_HW_CALIB_PMIC_THERM)
[ADC5_AMUX_THM1_100K_PU] = ADC5_CHAN_TEMP("amux_thm1_100k_pu", 1,
SCALE_HW_CALIB_THERM_100K_PULLUP)
+   [ADC5_AMUX_THM2_100K_PU] = ADC5_CHAN_TEMP("amux_thm2_100k_pu", 1,
+   SCALE_HW_CALIB_THERM_100K_PULLUP)
[ADC5_AMUX_THM3_100K_PU] = ADC5_CHAN_TEMP("amux_thm3_100k_pu", 1,
SCALE_HW_CALIB_THERM_100K_PULLUP)
+   [ADC5_AMUX_THM4_100K_PU] = ADC5_CHAN_TEMP("amux_thm4_100k_pu", 1,
+   SCALE_HW_CALIB_THERM_100K_PULLUP)
[ADC5_AMUX_THM5_100K_PU] = ADC5_CHAN_TEMP("amux_thm5_100k_pu", 1,
SCALE_HW_CALIB_THERM_100K_PULLUP)
[ADC5_XO_THERM_100K_PU] = ADC5_CHAN_TEMP("xo_therm_100k_pu", 1,
-- 
2.18.0.597.ga71716f1ad-goog

Warning splat on x86_32 during perf stress

[Steven Rostedt]

I sometimes trigger this splat in my tests (which cause them to fail),
but it's not always hit. Note, this is on x86_32 arch.

[ cut here ]
IRQs not enabled as expected
WARNING: CPU: 0 PID: 0 at 
/work/build/trace/nobackup/linux-test.git/kernel/time/tick-sched.c:982 
tick_nohz_idle_enter+0x44/0x8c
Modules linked in: ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 
ip6table_filter ip6_tables ipv6 crc_ccitt r8169 ppdev parport_pc parport
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.18.0-rc6-test+ #3
Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
EIP: tick_nohz_idle_enter+0x44/0x8c
Code: e8 05 00 00 00 75 26 83 b8 bc 05 00 00 00 75 1d 80 3d 81 f7 3c c1 00 75 
14 68 d6 82 11 c1 c6 05 81 f7 3c c1 01 e8 63 fb f8 ff <0f> 0b 58 fa bb 60 76 65 
c1 e8 0d 04 04 00 64 03 1d 28 c1 50 c1 8b
EAX: 001c EBX: c14803a0 ECX: 0006 EDX: 0007
perf: interrupt took too long (12533 > 12527), lowering 
kernel.perf_event_max_sample_rate to 15000
ESI: c12b8d00 EDI: 0147 EBP: c12a5f30 ESP: c12a5f28
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010292
CR0: 80050033 CR2: 080a45b0 CR3: 3075b600 CR4: 001406f0
Call Trace:
 do_idle+0x33/0x1f9
 cpu_startup_entry+0x61/0x63
 rest_init+0xb2/0xb4
 start_kernel+0x3fa/0x410
 i386_start_kernel+0x9a/0x9e
 startup_32_smp+0x164/0x168
irq event stamp: 8712154
hardirqs last  enabled at (8712153): [] 
trace_hardirqs_on_thunk+0xc/0x10
hardirqs last disabled at (8712154): [] 
trace_hardirqs_off_thunk+0xc/0x10
softirqs last  enabled at (8712148): [] __do_softirq+0x258/0x2b8
softirqs last disabled at (8712107): [] call_on_stack+0x45/0x4b
---[ end trace 7bebbaceab0fedbc ]---

This is where I think my patch:

  http://lkml.kernel.org/r/20180806214107.11062...@gandalf.local.home

would help. As I don't know if IRQs were really enabled, or if lockdep
was broken.

-- Steve

[PATCH v8 0/8] Introduce on-chip interconnect API

[Georgi Djakov]

Modern SoCs have multiple processors and various dedicated cores (video, gpu,
graphics, modem). These cores are talking to each other and can generate a
lot of data flowing through the on-chip interconnects. These interconnect
buses could form different topologies such as crossbar, point to point buses,
hierarchical buses or use the network-on-chip concept.

These buses have been sized usually to handle use cases with high data
throughput but it is not necessary all the time and consume a lot of power.
Furthermore, the priority between masters can vary depending on the running
use case like video playback or CPU intensive tasks.

Having an API to control the requirement of the system in terms of bandwidth
and QoS, so we can adapt the interconnect configuration to match those by
scaling the frequencies, setting link priority and tuning QoS parameters.
This configuration can be a static, one-time operation done at boot for some
platforms or a dynamic set of operations that happen at run-time.

This patchset introduce a new API to get the requirement and configure the
interconnect buses across the entire chipset to fit with the current demand.
The API is NOT for changing the performance of the endpoint devices, but only
the interconnect path in between them.

The API is using a consumer/provider-based model, where the providers are
the interconnect buses and the consumers could be various drivers.
The consumers request interconnect resources (path) to an endpoint and set
the desired constraints on this data flow path. The provider(s) receive
requests from consumers and aggregate these requests for all master-slave
pairs on that path. Then the providers configure each participating in the
topology node according to the requested data flow path, physical links and
constraints. The topology could be complicated and multi-tiered and is SoC
specific.

Below is a simplified diagram of a real-world SoC topology. The interconnect
providers are the NoCs.

++++
| HW Accelerator |--->|  M NoC |<---+
++++|
|  |++
 +-+  +-+  V   +--+ ||
 | DDR |  |++  | PCIe | ||
 +-+  || Slaves |  +--+ ||
   ^ ^|++ | |   C NoC|
   | |V   V ||
+--+   ++   ||   +-+
|  |-->||-->||-->| CPU |
|  |-->||<--||   +-+
| Mem NoC  |   | S NoC  |   ++
|  |<--||-+|
|  |<--||<--+ ||   ++
+--+   ++   | |+-->| Slaves |
  ^  ^^^  ^ | |++
  |  |||  | | V
+--+  |  +-+   +-+  +-+   ++   ++
| CPUs |  |  | GPU |   | DSP |  | Masters |-->|   P NoC|-->| Slaves |
+--+  |  +-+   +-+  +-+   ++   ++
  |
  +---+
  | Modem |
  +---+

TODO:
* Create icc_set_extended() to handle parameters such as latency and other
  QoS values.
* Convert from using global node identifiers to local per provider ids.
* Cache the path between the nodes instead of walking the graph on each get().
* Sync interconnect requests with the idle state of the device.

Changes since patchset v7 (https://lkml.org/lkml/2018/7/31/647)
* Addressed comments on kernel-doc and grammar. (Randy)
* Picked Reviewed-by: Evan
* Squashed consumer and provider DT bindings into single patch. (Rob)
* Cleaned-up msm8916 DT bindings docs by removing unused port ids.
* Updated documentation for the cases when NULL is returned. (Saravana)
* New patch to add myself as maintainer.

Changes since patchset v6 (https://lkml.org/lkml/2018/7/9/698)
* [patches 1,6]: Move the aggregation within the provider from the framework to
  the platform driver's set() callback, as the aggregation point could be SoC
  specific.
* [patch 1]: Include missing header, reset state only of the traversed nodes,
  move more code into path_init(), add more asserts, move misplaced mutex,
  simplify icc_link_destroy() (Evan)
* [patch 1]: Fix the order of requests to go from source to destination. (Alex)
* [patch 7]: Use better wording in the documentation. (Evan)
* [patch 6]: Reorder struct members, sort nodes alphabetically, improve naming
  of variables , add missing clk_disable_unprepare() in error paths. (Matthias)
* [patch 6]: Remove redundant NULL pointer check in msm8916 driver. (Alex)
* 

[PATCH v8 2/8] dt-bindings: Introduce interconnect binding

[Georgi Djakov]

This binding is intended to represent the relations between the interconnect
controllers (providers) and consumer device nodes. It will allow creating links
between consumers and interconnect paths (exposed by interconnect providers).

Signed-off-by: Georgi Djakov 
---
 .../bindings/interconnect/interconnect.txt| 60 +++
 1 file changed, 60 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interconnect/interconnect.txt

diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt 
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
new file mode 100644
index ..5cb7d3c8d44d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -0,0 +1,60 @@
+Interconnect Provider Device Tree Bindings
+=
+
+The purpose of this document is to define a common set of generic interconnect
+providers/consumers properties.
+
+
+= interconnect providers =
+
+The interconnect provider binding is intended to represent the interconnect
+controllers in the system. Each provider registers a set of interconnect
+nodes, which expose the interconnect related capabilities of the interconnect
+to consumer drivers. These capabilities can be throughput, latency, priority
+etc. The consumer drivers set constraints on interconnect path (or endpoints)
+depending on the use case. Interconnect providers can also be interconnect
+consumers, such as in the case where two network-on-chip fabrics interface
+directly
+
+Required properties:
+- compatible : contains the interconnect provider compatible string
+- #interconnect-cells : number of cells in a interconnect specifier needed to
+   encode the interconnect node id
+
+Example:
+
+   snoc: snoc@58 {
+   compatible = "qcom,msm8916-snoc";
+   #interconnect-cells = <1>;
+   reg = <0x58 0x14000>;
+   clock-names = "bus_clk", "bus_a_clk";
+   clocks = < RPM_SMD_SNOC_CLK>,
+< RPM_SMD_SNOC_A_CLK>;
+   };
+
+
+= interconnect consumers =
+
+The interconnect consumers are device nodes which dynamically express their
+bandwidth requirements along interconnect paths they are connected to. There
+can be multiple interconnect providers on a SoC and the consumer may consume
+multiple paths from different providers depending on use case and the
+components it has to interact with.
+
+Required properties:
+interconnects : Pairs of phandles and interconnect provider specifier to denote
+   the edge source and destination ports of the interconnect path.
+
+Optional properties:
+interconnect-names : List of interconnect path name strings sorted in the same
+order as the interconnects property. Consumers drivers 
will use
+interconnect-names to match interconnect paths with 
interconnect
+specifiers.
+
+Example:
+
+   sdhci@7864000 {
+   ...
+   interconnects = < MASTER_SDCC_1  SLAVE_EBI_CH0>;
+   interconnect-names = "ddr";
+   };

[PATCH v8 1/8] interconnect: Add generic on-chip interconnect API

[Georgi Djakov]

This patch introduces a new API to get requirements and configure the
interconnect buses across the entire chipset to fit with the current
demand.

The API is using a consumer/provider-based model, where the providers are
the interconnect buses and the consumers could be various drivers.
The consumers request interconnect resources (path) between endpoints and
set the desired constraints on this data flow path. The providers receive
requests from consumers and aggregate these requests for all master-slave
pairs on that path. Then the providers configure each participating in the
topology node according to the requested data flow path, physical links and
constraints. The topology could be complicated and multi-tiered and is SoC
specific.

Signed-off-by: Georgi Djakov 
Reviewed-by: Evan Green 
---
 Documentation/interconnect/interconnect.rst |  94 
 drivers/Kconfig |   2 +
 drivers/Makefile|   1 +
 drivers/interconnect/Kconfig|  10 +
 drivers/interconnect/Makefile   |   2 +
 drivers/interconnect/core.c | 573 
 include/linux/interconnect-provider.h   | 125 +
 include/linux/interconnect.h|  42 ++
 8 files changed, 849 insertions(+)
 create mode 100644 Documentation/interconnect/interconnect.rst
 create mode 100644 drivers/interconnect/Kconfig
 create mode 100644 drivers/interconnect/Makefile
 create mode 100644 drivers/interconnect/core.c
 create mode 100644 include/linux/interconnect-provider.h
 create mode 100644 include/linux/interconnect.h

diff --git a/Documentation/interconnect/interconnect.rst 
b/Documentation/interconnect/interconnect.rst
new file mode 100644
index ..b8107dcc4cd3
--- /dev/null
+++ b/Documentation/interconnect/interconnect.rst
@@ -0,0 +1,94 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+GENERIC SYSTEM INTERCONNECT SUBSYSTEM
+=
+
+Introduction
+
+
+This framework is designed to provide a standard kernel interface to control
+the settings of the interconnects on an SoC. These settings can be throughput,
+latency and priority between multiple interconnected devices or functional
+blocks. This can be controlled dynamically in order to save power or provide
+maximum performance.
+
+The interconnect bus is hardware with configurable parameters, which can be
+set on a data path according to the requests received from various drivers.
+An example of interconnect buses are the interconnects between various
+components or functional blocks in chipsets. There can be multiple 
interconnects
+on an SoC that can be multi-tiered.
+
+Below is a simplified diagram of a real-world SoC interconnect bus topology.
+
+::
+
+ ++++
+ | HW Accelerator |--->|  M NoC |<---+
+ ++++|
+ |  |++
+  +-+  +-+  V   +--+ ||
+  | DDR |  |++  | PCIe | ||
+  +-+  || Slaves |  +--+ ||
+^ ^|++ | |   C NoC|
+| |V   V ||
+ +--+   ++   ||   +-+
+ |  |-->||-->||-->| CPU |
+ |  |-->||<--||   +-+
+ | Mem NoC  |   | S NoC  |   ++
+ |  |<--||-+|
+ |  |<--||<--+ ||   ++
+ +--+   ++   | |+-->| Slaves |
+   ^  ^^^  ^ | |++
+   |  |||  | | V
+ +--+  |  +-+   +-+  +-+   ++   ++
+ | CPUs |  |  | GPU |   | DSP |  | Masters |-->|   P NoC|-->| Slaves |
+ +--+  |  +-+   +-+  +-+   ++   ++
+   |
+   +---+
+   | Modem |
+   +---+
+
+Terminology
+---
+
+Interconnect provider is the software definition of the interconnect hardware.
+The interconnect providers on the above diagram are M NoC, S NoC, C NoC, P NoC
+and Mem NoC.
+
+Interconnect node is the software definition of the interconnect hardware
+port. Each interconnect provider consists of multiple interconnect nodes,
+which are connected to other SoC components including other interconnect
+providers. The point on the diagram where the CPUs connect to the memory is
+called an interconnect node, which belongs to the Mem NoC interconnect 
provider.
+
+Interconnect endpoints are the 

[PATCH v8 4/8] interconnect: Add debugfs support

[Georgi Djakov]

Add a functionality to provide information about the current constraints
per each node and provider.

Signed-off-by: Georgi Djakov 
Reviewed-by: Evan Green 
---
 drivers/interconnect/core.c | 78 +
 1 file changed, 78 insertions(+)

diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 8f874d1b0a0f..288ef83c3bc0 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -6,6 +6,7 @@
  * Author: Georgi Djakov 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -17,10 +18,12 @@
 #include 
 #include 
 #include 
+#include 
 
 static DEFINE_IDR(icc_idr);
 static LIST_HEAD(icc_provider_list);
 static DEFINE_MUTEX(icc_lock);
+static struct dentry *icc_debugfs_dir;
 
 /**
  * struct icc_req - constraints that are attached to each node
@@ -49,6 +52,62 @@ struct icc_path {
struct icc_req reqs[];
 };
 
+#ifdef CONFIG_DEBUG_FS
+
+static void icc_summary_show_one(struct seq_file *s, struct icc_node *n)
+{
+   if (!n)
+   return;
+
+   seq_printf(s, "%-30s %12d %12d\n",
+  n->name, n->avg_bw, n->peak_bw);
+}
+
+static int icc_summary_show(struct seq_file *s, void *data)
+{
+   struct icc_provider *provider;
+
+   seq_puts(s, " node   avg 
peak\n");
+   seq_puts(s, 
"\n");
+
+   mutex_lock(_lock);
+
+   list_for_each_entry(provider, _provider_list, provider_list) {
+   struct icc_node *n;
+
+   list_for_each_entry(n, >nodes, node_list) {
+   struct icc_req *r;
+
+   icc_summary_show_one(s, n);
+   hlist_for_each_entry(r, >req_list, req_node) {
+   if (!r->dev)
+   continue;
+
+   seq_printf(s, "%-26s %12d %12d\n",
+  dev_name(r->dev), r->avg_bw,
+  r->peak_bw);
+   }
+   }
+   }
+
+   mutex_unlock(_lock);
+
+   return 0;
+}
+
+static int icc_summary_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, icc_summary_show, inode->i_private);
+}
+
+static const struct file_operations icc_summary_fops = {
+   .open   = icc_summary_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .release= single_release,
+};
+#endif
+
 static struct icc_node *node_find(const int id)
 {
return idr_find(_idr, id);
@@ -646,6 +705,25 @@ int icc_provider_del(struct icc_provider *provider)
 }
 EXPORT_SYMBOL_GPL(icc_provider_del);
 
+static int __init icc_init(void)
+{
+#ifdef CONFIG_DEBUG_FS
+   icc_debugfs_dir = debugfs_create_dir("interconnect", NULL);
+   debugfs_create_file("interconnect_summary", 0444,
+   icc_debugfs_dir, NULL, _summary_fops);
+#endif
+   return 0;
+}
+
+static void __exit icc_exit(void)
+{
+#ifdef CONFIG_DEBUG_FS
+   debugfs_remove_recursive(icc_debugfs_dir);
+#endif
+}
+module_init(icc_init);
+module_exit(icc_exit);
+
 MODULE_AUTHOR("Georgi Djakov 

[PATCH v8 8/8] MAINTAINERS: add a maintainer for the interconnect API

[Georgi Djakov]

Add myself as the maintainer of the interconnect API.

Signed-off-by: Georgi Djakov 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 32fbc6f732d4..ed1b534c901b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7420,6 +7420,16 @@ L:   linux-g...@vger.kernel.org
 S: Maintained
 F: drivers/gpio/gpio-intel-mid.c
 
+INTERCONNECT API
+M: Georgi Djakov 
+S: Maintained
+F: Documentation/interconnect/
+F: Documentation/devicetree/bindings/interconnect/
+F: drivers/interconnect/
+F: include/dt-bindings/interconnect/
+F: include/linux/interconnect-provider.h
+F: include/linux/interconnect.h
+
 INVENSENSE MPU-3050 GYROSCOPE DRIVER
 M: Linus Walleij 
 L: linux-...@vger.kernel.org

[PATCH v8 6/8] dt-bindings: interconnect: Document qcom,msm8916 NoC bindings

[Georgi Djakov]

Document the device-tree bindings of the Network-On-Chip interconnect
hardware found on Qualcomm msm8916 platforms.

Signed-off-by: Georgi Djakov 
Reviewed-by: Evan Green 
---
 .../bindings/interconnect/qcom-msm8916.txt| 41 
 include/dt-bindings/interconnect/qcom.h   | 98 +++
 2 files changed, 139 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
 create mode 100644 include/dt-bindings/interconnect/qcom.h

diff --git a/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt 
b/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
new file mode 100644
index ..744df51df4ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom-msm8916.txt
@@ -0,0 +1,41 @@
+Qualcomm MSM8916 Network-On-Chip interconnect driver binding
+
+
+Required properties :
+- compatible : shall contain only one of the following:
+   "qcom,msm8916-bimc"
+   "qcom,msm8916-pnoc"
+   "qcom,msm8916-snoc"
+- #interconnect-cells : should contain 1
+- reg : shall contain base register location and length
+
+Optional properties :
+clocks : list of phandles and specifiers to all interconnect bus clocks
+clock-names : clock names should include both "bus_clk" and "bus_a_clk"
+
+Examples:
+
+   snoc: snoc@58 {
+   compatible = "qcom,msm8916-snoc";
+   #interconnect-cells = <1>;
+   reg = <0x58 0x14000>;
+   clock-names = "bus_clk", "bus_a_clk";
+   clocks = < RPM_SMD_SNOC_CLK>,
+< RPM_SMD_SNOC_A_CLK>;
+   };
+   bimc: bimc@40 {
+   compatible = "qcom,msm8916-bimc";
+   #interconnect-cells = <1>;
+   reg = <0x40 0x62000>;
+   clock-names = "bus_clk", "bus_a_clk";
+   clocks = < RPM_SMD_BIMC_CLK>,
+< RPM_SMD_BIMC_A_CLK>;
+   };
+   pnoc: pnoc@50 {
+   compatible = "qcom,msm8916-pnoc";
+   #interconnect-cells = <1>;
+   reg = <0x50 0x11000>;
+   clock-names = "bus_clk", "bus_a_clk";
+   clocks = < RPM_SMD_PCNOC_CLK>,
+< RPM_SMD_PCNOC_A_CLK>;
+   };
diff --git a/include/dt-bindings/interconnect/qcom.h 
b/include/dt-bindings/interconnect/qcom.h
new file mode 100644
index ..f4d154f0afbf
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Qualcomm interconnect IDs
+ *
+ * Copyright (c) 2018, Linaro Ltd.
+ * Author: Georgi Djakov 
+ */
+
+#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_H
+#define __DT_BINDINGS_INTERCONNECT_QCOM_H
+
+#define BIMC_SNOC_MAS  0
+#define BIMC_SNOC_SLV  1
+#define MASTER_AMPSS_M02
+#define MASTER_BLSP_1  3
+#define MASTER_CRYPTO_CORE04
+#define MASTER_DEHR5
+#define MASTER_GRAPHICS_3D 6
+#define MASTER_JPEG7
+#define MASTER_LPASS   8
+#define MASTER_MDP_PORT0   9
+#define MASTER_QDSS_BAM10
+#define MASTER_QDSS_ETR11
+#define MASTER_SDCC_1  12
+#define MASTER_SDCC_2  13
+#define MASTER_SNOC_CFG14
+#define MASTER_SPDM15
+#define MASTER_TCU_0   16
+#define MASTER_TCU_1   17
+#define MASTER_USB_HS  18
+#define MASTER_VFE 19
+#define MASTER_VIDEO_P020
+#define PNOC_INT_0 21
+#define PNOC_INT_1 22
+#define PNOC_M_0   23
+#define PNOC_M_1   24
+#define PNOC_SLV_0 25
+#define PNOC_SLV_1 26
+#define PNOC_SLV_2 27
+#define PNOC_SLV_3 28
+#define PNOC_SLV_4 29
+#define PNOC_SLV_8 30
+#define PNOC_SLV_9 31
+#define PNOC_SNOC_MAS  32
+#define PNOC_SNOC_SLV  33
+#define SLAVE_AMPSS_L2 34
+#define SLAVE_BIMC_CFG 35
+#define SLAVE_BLSP_1   36
+#define SLAVE_BOOT_ROM 37
+#define SLAVE_CAMERA_CFG   38
+#define SLAVE_CATS_128 39
+#define SLAVE_CLK_CTL  40
+#define SLAVE_CRYPTO_0_CFG 41
+#define SLAVE_DEHR_CFG 42
+#define SLAVE_DISPLAY_CFG  43
+#define SLAVE_EBI_CH0  44

[PATCH v8 7/8] interconnect: qcom: Add msm8916 interconnect provider driver

[Georgi Djakov]

Add driver for the Qualcomm interconnect buses found in msm8916 based
platforms.

Signed-off-by: Georgi Djakov 
---
 drivers/interconnect/Kconfig|   5 +
 drivers/interconnect/Makefile   |   1 +
 drivers/interconnect/qcom/Kconfig   |   9 +
 drivers/interconnect/qcom/Makefile  |   2 +
 drivers/interconnect/qcom/msm8916.c | 510 
 5 files changed, 527 insertions(+)
 create mode 100644 drivers/interconnect/qcom/msm8916.c

diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index a261c7d41deb..07a8276fa35a 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -8,3 +8,8 @@ menuconfig INTERCONNECT
 
  If unsure, say no.
 
+if INTERCONNECT
+
+source "drivers/interconnect/qcom/Kconfig"
+
+endif
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 97fca2e09d24..7944cbca0527 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_INTERCONNECT) += core.o
+obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
diff --git a/drivers/interconnect/qcom/Kconfig 
b/drivers/interconnect/qcom/Kconfig
index 812e9464765a..add6d7e1e24e 100644
--- a/drivers/interconnect/qcom/Kconfig
+++ b/drivers/interconnect/qcom/Kconfig
@@ -12,3 +12,12 @@ config INTERCONNECT_QCOM_SMD_RPM
help
  This is a driver for communicating interconnect related configuration
  details with a remote processor (RPM) on Qualcomm platforms.
+
+config INTERCONNECT_QCOM_MSM8916
+   tristate "Qualcomm MSM8916 interconnect driver"
+   depends on INTERCONNECT_QCOM
+   depends on QCOM_SMD_RPM
+   select INTERCONNECT_QCOM_SMD_RPM
+   help
+ This is a driver for the Qualcomm Network-on-Chip on msm8916-based
+ platforms.
diff --git a/drivers/interconnect/qcom/Makefile 
b/drivers/interconnect/qcom/Makefile
index 5b65e4011b59..53f3380277f6 100644
--- a/drivers/interconnect/qcom/Makefile
+++ b/drivers/interconnect/qcom/Makefile
@@ -1,2 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += smd-rpm.o
+
+obj-$(CONFIG_INTERCONNECT_QCOM_MSM8916) += msm8916.o
diff --git a/drivers/interconnect/qcom/msm8916.c 
b/drivers/interconnect/qcom/msm8916.c
new file mode 100644
index ..74145f4f74f1
--- /dev/null
+++ b/drivers/interconnect/qcom/msm8916.c
@@ -0,0 +1,510 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Linaro Ltd
+ * Author: Georgi Djakov 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "smd-rpm.h"
+
+#define RPM_BUS_MASTER_REQ  0x73616d62
+#define RPM_BUS_SLAVE_REQ   0x766c7362
+
+#define to_qcom_provider(_provider) \
+   container_of(_provider, struct qcom_icc_provider, provider)
+
+enum qcom_qos_mode {
+   QCOM_QOS_MODE_BYPASS = 0,
+   QCOM_QOS_MODE_FIXED,
+   QCOM_QOS_MODE_MAX,
+};
+
+struct qcom_icc_provider {
+   struct icc_provider provider;
+   void __iomem*base;
+   struct clk  *bus_clk;
+   struct clk  *bus_a_clk;
+};
+
+#define MSM8916_MAX_LINKS  8
+
+/**
+ * struct qcom_icc_node - Qualcomm specific interconnect nodes
+ * @name: the node name used in debugfs
+ * @id: a unique node identifier
+ * @links: an array of nodes where we can go next while traversing
+ * @num_links: the total number of @links
+ * @port: the offset index into the masters QoS register space
+ * @buswidth: width of the interconnect between a node and the bus (bytes)
+ * @ap_owned: the AP CPU does the writing to QoS registers
+ * @qos_mode: QoS mode for ap_owned resources
+ * @mas_rpm_id:RPM id for devices that are bus masters
+ * @slv_rpm_id:RPM id for devices that are bus slaves
+ * @rate: current bus clock rate in Hz
+ */
+struct qcom_icc_node {
+   unsigned char *name;
+   u16 id;
+   u16 links[MSM8916_MAX_LINKS];
+   u16 num_links;
+   u16 port;
+   u16 buswidth;
+   bool ap_owned;
+   enum qcom_qos_mode qos_mode;
+   int mas_rpm_id;
+   int slv_rpm_id;
+   u64 rate;
+};
+
+struct qcom_icc_desc {
+   struct qcom_icc_node **nodes;
+   size_t num_nodes;
+};
+
+#define DEFINE_QNODE(_name, _id, _port, _buswidth, _ap_owned,  \
+   _mas_rpm_id, _slv_rpm_id, _qos_mode,\
+   _numlinks, ...) \
+   static struct qcom_icc_node _name = {   \
+   .name = #_name, \
+   .id = _id,  \
+   .port = _port,  \
+   .buswidth = _buswidth,  \
+   .ap_owned = _ap_owned,  \
+ 

Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek,

On 9 August 2018 at 21:21, Jacek Anaszewski  wrote:
> Hi Baolin,
>
> On 08/09/2018 07:48 AM, Baolin Wang wrote:
> [...]
>> +static int pattern_trig_start_pattern(struct pattern_trig_data *data,
>> +   struct led_classdev *led_cdev)
>> +{
>> + if (!data->npatterns)
>> + return 0;
>> +
>> + if (led_cdev->pattern_set) {
>> + return led_cdev->pattern_set(led_cdev, data->patterns,
>> +  data->npatterns, 
>> data->repeat);
>
> I think that it would be more flexible if software pattern fallback
> was applied in case of pattern_set failure. Otherwise, it would
> lead to the situation where LED class devices that support hardware
> blinking couldn't be applied the same set of patterns as LED class
> devices that don't implement pattern_set. The latter will always have to
> resort to using software pattern engine which will accept far greater
> amount of pattern combinations.

 Hmmm, I am not sure this is useful for hardware pattern, since the LED
 hardware can be diverse which is hard to be compatible with software
 pattern.

 For example, for our SC27XX LED, it only supports 4 hardware patterns
 setting (low time, rising time, high time and falling time) to make it
 work at breathing mode. If user provides 3 or 5 patterns values, it
 will failed to issue pattern_set(). But at this time, we don't want to
 use software pattern instead since it will be not the breathing mode
 expected by user. I don't know if there are other special LED
 hardware.
>>>
>>> Good point. So this is the issue we should dwell on, since the
>>> requested pattern effect should look similar on all devices.
>>> Of course in case of software pattern it will be often impossible
>>> to achieve the same fluency. Similarly as in case of rendering graphics
>>> with and without acceleration.
>>>
>>> In case of your device, I'd say that we'd need more complex description
>>> of breathing mode pattern. More complex than just four intervals.
>>> It should reflect all the intervals the hardware engine needs to perform
>>> to achieve the breathing effect. Can this information be inferred from
>>> the docs?
>>
>>>From our docs, it only provides registers to set the low time, rising
>> time, high time and falling time (value unit is 0.125s and max value
>> is 63 = 7.875s) to enable breathing mode. So each interval value can
>> be 1 ~ 63. But that is still hard for software pattern to simulate the
>> breathing mode performed by hardware pattern.
>
> Software fallback is not expected to show similar performance to the
> hardware engine on the whole span of the supported time range.
>
> Having min rise time value at 125ms, and given that max_brightness
> is 255, then we'd have 255 / 125 = 2.04 of brightness level rise per
> 1ms. So, the pattern for rising edge could look like (assuming we
> stop at 254):
>
> 0 1 2 1 4 1 6 1 8 1 10 1 ... 254 1

Right, maybe this can work, maybe not. Since we can met different
cases when failed to issue pattern_set(). Maybe the LED hardware
occurs some errors, in this case we should shutdown the LED, not
enable the software pattern instead, which still can not work. Maybe
driver can set NULL for pattern_set/clear interfaces to disable
hardware pattern, then next time user will perform the patterns with
software pattern mode.

For our SC27XX LED, like I said if user provides only 3 pattern values
which will failed to issue pattern_set(). But I still do not need use
software patterns to show similar performance, instead it will still
keep the last hardware pattern performance ( It did not overlap the
previous hardware pattern setting). Maybe different drivers have
different error handling, that's why I think we can leave driver to
choose the proper way to handle.

Honestly, can we keep this pattern trigger simple and easy at first?
If some drivers want to use software patterns to perform again once
their hardware patterns performed failed (IMHO our SC27XX LED do not
need), then we can add this feature, at that time we will have users
to test and optimize the feature. Maybe I am wrong:)

> Now, I'm starting to wonder if we shouldn't have specialized trigger
> for breathing patterns, that would accept brightness level change per
> time period. Pattern trigger needs more flexibility and inferring if the
> hardware can handle given series of pattern intervals would entail
> unnecessary code complexity.
>
> Such breathing trigger would require triplets comprised of
> start brightness, end brightness and a duration of the brightness
> transition.

But this is the only place we can set the hardware patterns according
to our previous discussion. Thanks.

-- 
Baolin Wang
Best Regards

Re: [PATCH v12 2/3] tracepoint: Make rcuidle tracepoint callers use SRCU

[Steven Rostedt]

On Mon, 30 Jul 2018 15:24:22 -0700
Joel Fernandes  wrote:

> From: "Joel Fernandes (Google)" 
> 
> In recent tests with IRQ on/off tracepoints, a large performance
> overhead ~10% is noticed when running hackbench. This is root caused to
> calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the
> tracepoint code. Following a long discussion on the list [1] about this,
> we concluded that srcu is a better alternative for use during rcu idle.
> Although it does involve extra barriers, its lighter than the sched-rcu
> version which has to do additional RCU calls to notify RCU idle about
> entry into RCU sections.
> 
> In this patch, we change the underlying implementation of the
> trace_*_rcuidle API to use SRCU. This has shown to improve performance
> alot for the high frequency irq enable/disable tracepoints.
> 
> Test: Tested idle and preempt/irq tracepoints.
> 
> Here are some performance numbers:
> 
> With a run of the following 30 times on a single core x86 Qemu instance
> with 1GB memory:
> hackbench -g 4 -f 2 -l 3000
> 
> Completion times in seconds. CONFIG_PROVE_LOCKING=y.
> 
> No patches (without this series)
> Mean: 3.048
> Median: 3.025
> Std Dev: 0.064
> 
> With Lockdep using irq tracepoints with RCU implementation:
> Mean: 3.451   (-11.66 %)
> Median: 3.447 (-12.22%)
> Std Dev: 0.049
> 
> With Lockdep using irq tracepoints with SRCU implementation (this series):
> Mean: 3.020   (I would consider the improvement against the "without
>  this series" case as just noise).
> Median: 3.013
> Std Dev: 0.033
> 
> [1] https://patchwork.kernel.org/patch/10344297/
> 
> [remove rcu_read_lock_sched_notrace as its the equivalent of
> preempt_disable_notrace and is unnecessary to call in tracepoint code]
> Cleaned-up-by: Peter Zijlstra 
> Acked-by: Peter Zijlstra 
> Reviewed-by: Mathieu Desnoyers 
> Signed-off-by: Joel Fernandes (Google) 
> ---
>  include/linux/tracepoint.h | 41 ++
>  kernel/tracepoint.c| 16 ++-
>  2 files changed, 48 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 19a690b559ca..6e7bc6ebfcd8 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -15,6 +15,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -33,6 +34,8 @@ struct trace_eval_map {
>  
>  #define TRACEPOINT_DEFAULT_PRIO  10
>  
> +extern struct srcu_struct tracepoint_srcu;
> +
>  extern int
>  tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data);
>  extern int
> @@ -75,10 +78,16 @@ int unregister_tracepoint_module_notifier(struct 
> notifier_block *nb)
>   * probe unregistration and the end of module exit to make sure there is no
>   * caller executing a probe when it is freed.
>   */
> +#ifdef CONFIG_TRACEPOINTS
>  static inline void tracepoint_synchronize_unregister(void)
>  {
> + synchronize_srcu(_srcu);
>   synchronize_sched();
>  }
> +#else
> +static inline void tracepoint_synchronize_unregister(void)
> +{ }
> +#endif
>  
>  #ifdef CONFIG_HAVE_SYSCALL_TRACEPOINTS
>  extern int syscall_regfunc(void);
> @@ -129,18 +138,32 @@ extern void syscall_unregfunc(void);
>   * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just
>   * "void *data", where as the DECLARE_TRACE() will pass in "void *data, 
> proto".
>   */
> -#define __DO_TRACE(tp, proto, args, cond, rcucheck)  \
> +#define __DO_TRACE(tp, proto, args, cond, rcuidle)   \
>   do {\
>   struct tracepoint_func *it_func_ptr;\
>   void *it_func;  \
>   void *__data;   \
> + int __maybe_unused idx = 0; \
>   \
>   if (!(cond))\
>   return; \
> - if (rcucheck)   \
> - rcu_irq_enter_irqson(); \
> - rcu_read_lock_sched_notrace();  \
> - it_func_ptr = rcu_dereference_sched((tp)->funcs);   \
> + \
> + /* srcu can't be used from NMI */   \
> + if (rcuidle && in_nmi())\
> + WARN_ON_ONCE(1);\
> + \
> + /* keep srcu and sched-rcu usage consistent */  \
> + preempt_disable_notrace();  \
> +  

Re: [PATCH 0/5 - V2] locks: avoid thundering-herd wake-ups

[J. Bruce Fields]

On Fri, Aug 10, 2018 at 01:17:14PM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
> 
> > On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> >> You're good at this game!
> >
> > Everybody's got to have a hobby, mine is pathological posix locking
> > cases
> >
> >> So, because a locker with the same "owner" gets a free pass, you can
> >> *never* say that any lock which conflicts with A also conflicts with B,
> >> as a lock with the same owner as B will never conflict with B, even
> >> though it conflicts with A.
> >> 
> >> I think there is still value in having the tree, but when a waiter is
> >> attached under a new blocker, we need to walk the whole tree beneath the
> >> waiter and detach/wake anything that is not blocked by the new blocker.
> >
> > If you're walking the whole tree every time then it might as well be a
> > flat list, I think?
> 
> The advantage of a tree is that it keeps over-lapping locks closer
> together.
> For it to make a difference you would need a load where lots of threads
> were locking several different small ranges, and other threads were
> locking large ranges that cover all the small ranges.

OK, I'm not sure I understand, but I'll give another look at the next
version

> I doubt this is common, but it doesn't seem as strange as other things
> I've seen in the wild.
> The other advantage, of course, is that I've already written the code,
> and I like it.
> 
> Maybe I'll do a simple-list version, then a patch to convert that to the
> clever-tree version, and we can then have something concrete to assess.

That might help, thanks.

--b.

Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Mark Brown]

On Fri, Aug 10, 2018 at 09:27:05AM -0700, Doug Anderson wrote:
> On Fri, Aug 10, 2018 at 9:13 AM, Mark Brown  wrote:
> > On Fri, Aug 10, 2018 at 08:40:17AM -0700, Doug Anderson wrote:

> >> The clock framework should be able to accomplish what you want.  If
> >> you just request the rate it will do its best to make the rate
> >> requested.  If we want to see what clock would be set before setting

> > The request could be massively off the deliverable rate - 50% or more.

> Agreed.  If the clock is massively off and that causes problems then
> someone will need to debug it and find a solution.  I'm not aware of
> us being in that case in the driver in question.

For the logic in the SPI core it's relatively common, lots of SPI
controllers are limited to something in the region of 10-12.5MHz but it's
common for devices to be able to run up to the region of 30MHz.

> >> >> 3. If you really truly need code in the SPI driver then make sure you
> >> >> include a compatible string for the SoC and have a table in the driver
> >> >> that's found with of_device_get_match_data().  AKA:

> >> It wouldn't be open-coding, it would be a different way of specifying
> >> things.  In my understanding it's always a judgement call about how
> >
> > If you're saying we need clock rate selection logic (which is what it
> > sounds like) rather than data then that seems like a problem.
> 
> We're talking past each other I think.  Maybe a concrete example helps?

...

> IMO the line marked "/* UNNEEDED */" below should be removed:

> ...
> spi-max-frequency = <5000>;  /* UNNEEDED */

This is a line in the device tree (which I agree shouldn't be there),
not code in the SPI driver?

> ...and then the driver should say "oh, I have a compatible string of
> "qcom,geni-spi-sdm845" so I know my controller's max frequency must be
> 50 MHz.  It can get that information using of_device_get_match_data().

> Hopefully that's clearer?

That's just a data table, when you talk about code in the driver
(particularly given the wider discussion of what the maximum rate might
be) it sounds rather more involved than that.


signature.asc
Description: PGP signature

Re: [RFC][PATCH] tracepoints: Free early tracepoints after RCU is initialized

[Joel Fernandes]

On Fri, Aug 10, 2018 at 9:30 AM, Steven Rostedt  wrote:
>
> From: "Steven Rostedt (VMware)" 
>
> When enabling trace events via the kernel command line, I hit this warning:
>
> WARNING: CPU: 0 PID: 13 at kernel/rcu/srcutree.c:236 
> check_init_srcu_struct+0xe/0x61
> Modules linked in:
> CPU: 0 PID: 13 Comm: watchdog/0 Not tainted 4.18.0-rc6-test+ #6
> Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
> RIP: 0010:check_init_srcu_struct+0xe/0x61
> Code: 48 c7 c6 ec 8a 65 b4 e8 ff 79 fe ff 48 89 df 31 f6 e8 f2 fa ff ff 5a
> 5b 41 5c 5d c3 0f 1f 44 00 00 83 3d 68 94 b8 01 01 75 02 <0f> 0b 48 8b 87 f0
> 0a 00 00 a8 03 74 45 55 48 89 e5 41 55 41 54 4c
> RSP: :96eb9ea03e68 EFLAGS: 00010246
> RAX: 96eb962b5b01 RBX: b4a87420 RCX: 0001
> RDX: b3107969 RSI: 96eb962b5b40 RDI: b4a87420
> RBP: 96eb9ea03eb0 R08: abbd00cd7f48 R09: 
> R10: 96eb9ea03e68 R11: b4a6eec0 R12: 96eb962b5b40
> R13: 96eb9ea03ef8 R14: b3107969 R15: b3107948
> FS:  () GS:96eb9ea0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 96eb13ab2000 CR3: 000192a1e001 CR4: 001606f0
> Call Trace:
>  
>  ? __call_srcu+0x2d/0x290
>  ? rcu_process_callbacks+0x26e/0x448
>  ? allocate_probes+0x2b/0x2b
>  call_srcu+0x13/0x15
>  rcu_free_old_probes+0x1f/0x21
>  rcu_process_callbacks+0x2ed/0x448
>  __do_softirq+0x172/0x336
>  irq_exit+0x62/0xb2
>  smp_apic_timer_interrupt+0x161/0x19e
>  apic_timer_interrupt+0xf/0x20
>  
>
> The problem is that the enabling of trace events before RCU is set up will
> cause SRCU to give this warning. To avoid this, add a list to store probes
> that need to be freed till after RCU is initialized, and then free them
> then.
>
> Link: http://lkml.kernel.org/r/20180810113554.1df28...@gandalf.local.home
>
> Fixes: e6753f23d961d ("tracepoint: Make rcuidle tracepoint callers use SRCU")
> Signed-off-by: Steven Rostedt (VMware) 

Reviewed-by: Joel Fernandes (Google) 

thanks,

 - Joel

Re: [PATCH v4 1/2] tpm: add ptr to the tpm_space struct to file_priv

[Jarkko Sakkinen]

On Tue, Aug 07, 2018 at 01:27:44PM -0700, Tadeusz Struk wrote:
> Add a ptr to struct tpm_space to the file_priv to have an easy
> access to it in the async job without the need to allocate memory.
> This also allows to consolidate of the write operations for
> the two interfaces.

I think the 2nd premise should be the priority and the first premise should
be removed as it is not needed in any possible way to justify the
change.

/Jarkko

Re: [PATCH] x86, kdump: Fix efi=noruntime NULL pointer dereference

[Mike Galbraith]

On Fri, 2018-08-10 at 18:28 +0800, Dave Young wrote:
> 
> > @@ -250,8 +253,10 @@ setup_boot_parameters(struct kimage *image, struct 
> > boot_params *params,
> >  
> >  #ifdef CONFIG_EFI
> > /* Setup EFI state */
> > -   setup_efi_state(params, params_load_addr, efi_map_offset, efi_map_sz,
> > +   ret = setup_efi_state(params, params_load_addr, efi_map_offset, 
> > efi_map_sz,
> > efi_setup_data_offset);
> > +   if (ret)
> 
> Here should check efi_enabled(EFI_BOOT) && ret

Patch with that works for me.

> In case efi boot we need the efi info set correctly,  or one need pass
> acpi_rsdp= in kernel cmdline param.
> 
> Still not sure how to allow one to workaround it by using acpi_rsdp=
> param with kexec_file_load..

Does this improve things, and plug the no boot hole?

x86, kdump: cleanup efi setup data handling a bit

1. Remove efi specific variables from bzImage64_load() other than the
one it needs, efi_map_sz, passing it and params_cmdline_sz on to efi
setup functions, giving them all they need without duplication.

2. Only allocate space for efi setup data when a 1:1 mapping is available.
Bail early with -ENODEV if not available, but is required to boot, and
acpi_rsdp= was not passed on the command line. 

3. Use the proper config dependency to isolate efi setup functions,
adding a !EFI_RUNTIME_MAP stub for setup_efi_state().

4. Change efi functions that cannot fail to void. 

Signed-off-by: Mike Galbraith 
---
 arch/x86/kernel/kexec-bzimage64.c |   99 +-
 1 file changed, 45 insertions(+), 54 deletions(-)

--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -112,35 +112,32 @@ static int setup_e820_entries(struct boo
return 0;
 }
 
-#ifdef CONFIG_EFI
-static int setup_efi_info_memmap(struct boot_params *params,
+#ifdef CONFIG_EFI_RUNTIME_MAP
+static void setup_efi_info_memmap(struct boot_params *params,
  unsigned long params_load_addr,
- unsigned int efi_map_offset,
+ unsigned int params_cmdline_sz,
  unsigned int efi_map_sz)
 {
-   void *efi_map = (void *)params + efi_map_offset;
-   unsigned long efi_map_phys_addr = params_load_addr + efi_map_offset;
+   void *efi_map = (void *)params + params_cmdline_sz;
+   unsigned long efi_map_phys_addr = params_load_addr + params_cmdline_sz;
struct efi_info *ei = >efi_info;
 
-   if (!efi_map_sz)
-   return -EINVAL;
-
efi_runtime_map_copy(efi_map, efi_map_sz);
 
ei->efi_memmap = efi_map_phys_addr & 0x;
ei->efi_memmap_hi = efi_map_phys_addr >> 32;
ei->efi_memmap_size = efi_map_sz;
-
-   return 0;
 }
 
-static int
+static void
 prepare_add_efi_setup_data(struct boot_params *params,
-  unsigned long params_load_addr,
-  unsigned int efi_setup_data_offset)
+  unsigned long params_load_addr,
+  unsigned int params_cmdline_sz,
+  unsigned int efi_map_sz)
 {
+   unsigned int data_offset = params_cmdline_sz + ALIGN(efi_map_sz, 16);
unsigned long setup_data_phys;
-   struct setup_data *sd = (void *)params + efi_setup_data_offset;
+   struct setup_data *sd = (void *)params + data_offset;
struct efi_setup_data *esd = (void *)sd + sizeof(struct setup_data);
 
esd->fw_vendor = efi.fw_vendor;
@@ -152,33 +149,20 @@ prepare_add_efi_setup_data(struct boot_p
sd->len = sizeof(struct efi_setup_data);
 
/* Add setup data */
-   setup_data_phys = params_load_addr + efi_setup_data_offset;
+   setup_data_phys = params_load_addr + data_offset;
sd->next = params->hdr.setup_data;
params->hdr.setup_data = setup_data_phys;
-
-   return 0;
 }
 
 static int
 setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
-   unsigned int efi_map_offset, unsigned int efi_map_sz,
-   unsigned int efi_setup_data_offset)
+   unsigned int params_cmdline_sz, unsigned int efi_map_sz)
 {
struct efi_info *current_ei = _params.efi_info;
struct efi_info *ei = >efi_info;
-   int ret;
-
-   if (!current_ei->efi_memmap_size)
-   return -EINVAL;
 
-   /*
-* If 1:1 mapping is not enabled, second kernel can not setup EFI
-* and use EFI run time services. User space will have to pass
-* acpi_rsdp= on kernel command line to make second kernel boot
-* without efi.
-*/
-   if (efi_enabled(EFI_OLD_MEMMAP) || !efi_enabled(EFI_RUNTIME_SERVICES))
-   return -ENODEV;
+   if (!efi_map_sz || !current_ei->efi_memmap_size)
+   return efi_map_sz ? -EINVAL : 0;
 
ei->efi_loader_signature = current_ei->efi_loader_signature;
ei->efi_systab = 

Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Trent Piepho]

On Fri, 2018-08-10 at 21:59 +0530, dk...@codeaurora.org wrote:
> 
> Here are my couple of cents:
> SPI controller maximum frequency can be lesser than or equal to Clock 
> framework's maximum
> frequency, so should not rely on the Clock framework.

But there is probably some means, via the controller's IP block input
clock, combined with the controller's IP version (from the compatible
string and a device data table), to derive the controller's max clock.

At least, AFAICT, this has been the case for all existing master
drivers.

> 
> Now the need is, how to communicate the SPI controller maximum frequency 
> to SPI core framework?
> Is it by DTSI entry or hardcoding in the SPI controller driver?
> 
> My stand is for providing the DTSI entry.
> Why because, this keeps SPI controller driver generic across the boards 
> and portable.
> Also it is not against to Device tree usage because maximum frequency
> is describing the property of the hardware.

My point is that not everything that possibly can go in the device tree
should be placed there, just because it can be.  If the master driver
can figure out its max speed, let it do that.

Re: [PATCH v3 1/5] staging: rtl8188eu: use is_multicast_ether_addr in rtw_security.c

[Michael Straube]

On 08/10/18 13:31, Dan Carpenter wrote:

No no...  I only gave it a Reviewed-by tag because I didn't want you to
resend again...  :P


Ah, sorry. So I shouldn't have added the tag?
Should I remove it again? I guess not..
How are those tags (reviewed, acked, etc.) handled normaly?
I'm a bit confused now. ;)

Michael

[PATCH] RDMA/bnxt_re: QPLIB: Add and use #define dev_fmt(fmt) "QPLIB: " fmt

[Joe Perches]

Consistently use the "QPLIB: " prefix for dev_ logging.

Miscellanea:

o Add missing newlines to avoid possible message interleaving
o Coalesce consecutive dev_ uses that emit a message header to
  avoid < 80 column lengths and mistakenly output on multiple lines
o Reflow modified lines to use 80 columns where appropriate
o Consistently use "%s: " where __func__ is output
o QPLIB: is now always output immediately after the dev_ header

Signed-off-by: Joe Perches 
---
 drivers/infiniband/hw/bnxt_re/qplib_fp.c   | 130 +++--
 drivers/infiniband/hw/bnxt_re/qplib_rcfw.c |  51 ++-
 drivers/infiniband/hw/bnxt_re/qplib_res.c  |  29 ---
 drivers/infiniband/hw/bnxt_re/qplib_sp.c   |  57 ++---
 4 files changed, 116 insertions(+), 151 deletions(-)

diff --git a/drivers/infiniband/hw/bnxt_re/qplib_fp.c 
b/drivers/infiniband/hw/bnxt_re/qplib_fp.c
index e426b990c1dd..f92605aa42b4 100644
--- a/drivers/infiniband/hw/bnxt_re/qplib_fp.c
+++ b/drivers/infiniband/hw/bnxt_re/qplib_fp.c
@@ -36,6 +36,8 @@
  * Description: Fast Path Operators
  */
 
+#define dev_fmt(fmt) "QPLIB: " fmt
+
 #include 
 #include 
 #include 
@@ -71,8 +73,7 @@ static void __bnxt_qplib_add_flush_qp(struct bnxt_qplib_qp 
*qp)
 
if (!qp->sq.flushed) {
dev_dbg(>hwq.pdev->dev,
-   "QPLIB: FP: Adding to SQ Flush list = %p",
-   qp);
+   "FP: Adding to SQ Flush list = %p\n", qp);
bnxt_qplib_cancel_phantom_processing(qp);
list_add_tail(>sq_flush, >sqf_head);
qp->sq.flushed = true;
@@ -80,8 +81,7 @@ static void __bnxt_qplib_add_flush_qp(struct bnxt_qplib_qp 
*qp)
if (!qp->srq) {
if (!qp->rq.flushed) {
dev_dbg(>hwq.pdev->dev,
-   "QPLIB: FP: Adding to RQ Flush list = %p",
-   qp);
+   "FP: Adding to RQ Flush list = %p\n", qp);
list_add_tail(>rq_flush, >rqf_head);
qp->rq.flushed = true;
}
@@ -207,7 +207,7 @@ static int bnxt_qplib_alloc_qp_hdr_buf(struct 
bnxt_qplib_res *res,
if (!qp->sq_hdr_buf) {
rc = -ENOMEM;
dev_err(>pdev->dev,
-   "QPLIB: Failed to create sq_hdr_buf");
+   "Failed to create sq_hdr_buf\n");
goto fail;
}
}
@@ -221,7 +221,7 @@ static int bnxt_qplib_alloc_qp_hdr_buf(struct 
bnxt_qplib_res *res,
if (!qp->rq_hdr_buf) {
rc = -ENOMEM;
dev_err(>pdev->dev,
-   "QPLIB: Failed to create rq_hdr_buf");
+   "Failed to create rq_hdr_buf\n");
goto fail;
}
}
@@ -277,8 +277,7 @@ static void bnxt_qplib_service_nq(unsigned long data)
num_cqne_processed++;
else
dev_warn(>pdev->dev,
-"QPLIB: cqn - type 0x%x not handled",
-type);
+"cqn - type 0x%x not handled\n", type);
spin_unlock_bh(>compl_lock);
break;
}
@@ -298,7 +297,7 @@ static void bnxt_qplib_service_nq(unsigned long data)
num_srqne_processed++;
else
dev_warn(>pdev->dev,
-"QPLIB: SRQ event 0x%x not handled",
+"SRQ event 0x%x not handled\n",
 nqsrqe->event);
break;
}
@@ -306,8 +305,7 @@ static void bnxt_qplib_service_nq(unsigned long data)
break;
default:
dev_warn(>pdev->dev,
-"QPLIB: nqe with type = 0x%x not handled",
-type);
+"nqe with type = 0x%x not handled\n", type);
break;
}
raw_cons++;
@@ -396,7 +394,7 @@ int bnxt_qplib_nq_start_irq(struct bnxt_qplib_nq *nq, int 
nq_indx,
rc = irq_set_affinity_hint(nq->vector, >mask);
if (rc) {
dev_warn(>pdev->dev,
-"QPLIB: set affinity failed; vector: %d nq_idx: %d\n",
+"set affinity failed; vector: %d nq_idx: %d\n",
 nq->vector, nq_indx);
}
nq->requested = true;
@@ -443,7 +441,7 @@ int bnxt_qplib_enable_nq(struct pci_dev *pdev, struct 
bnxt_qplib_nq *nq,
rc = bnxt_qplib_nq_start_irq(nq, nq_idx, msix_vector, true);
if 

Re: [PATCH v4 1/2] tpm: add ptr to the tpm_space struct to file_priv

[Jarkko Sakkinen]

On Fri, Aug 10, 2018 at 11:05:17AM -0700, Tadeusz Struk wrote:
> On 08/10/2018 10:27 AM, Jarkko Sakkinen wrote:
> > On Tue, Aug 07, 2018 at 01:27:44PM -0700, Tadeusz Struk wrote:
> >> Add a ptr to struct tpm_space to the file_priv to have an easy
> >> access to it in the async job without the need to allocate memory.
> >> This also allows to consolidate of the write operations for
> >> the two interfaces.
> > 
> > I think the 2nd premise should be the priority and the first premise should
> > be removed as it is not needed in any possible way to justify the
> > change.
> 
> Jarkko,
> The main reason why the pointer to tpm_space struct was added to the
> file_priv was to have access to space in the async job when it is enqueued
> via the /dev/tpm interface. Currently it is only available in tpmrm_priv.
> Otherwise I would need to introduce yet another struct what would consist of
> a ptr file_priv and a ptr to tpm_space and allocate it on every enqueue.
> Much easier was to to it this way. The consolidation was only a side effect
> of this so I think the description is correct.
> Thanks,
> -- 
> Tadeusz

The less dependencies a commit has more easy it is for me pick up. Here
the consodilation is enough to accept the commit but with the current
commit message I cannot apply it without accepting the whole patch set.

/Jarkko

Re: [PATCH] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Trent Piepho]

On Thu, 2018-08-09 at 12:37 -0700, Doug Anderson wrote:
> On Thu, Aug 9, 2018 at 11:24 AM, Trent Piepho  wrote:
> > 
> I think we're in agreement but perhaps there's a miscommunication here?
> 
> I'm saying that we _shouldn't_ put the max-speed of the master in the
> device tree.  The max speed for the IP block ought to be in code
> either in the clock driver or in the SPI driver based on the
> compatible string.

Yes, totally agree.

Usually the clock framework provides a clock to the SPI IP block at
some rate, or range of rates.  Based on that clock, the SPI IP block
has a max SPI clock, and the driver can calculate it.

We do have a concept of a SPI master max clock, but it's never needed
to be specified in the DT.

Consider userspace access via spidev.  The transfer asks for 100 MHz,
but the spi master driver can not possibly program that speed into
whatever register(s) control the spi clock.  The SPI core handles that
case of limiting a transfer to the master's max.

> ...as one argument _against_ putting a max-speed for the master in the
> device tree I'm saying that we can already specify a max-speed of each
> slave in the device tree.  The max speed of the slave should take into
> account whatever factors are specific to this board including trace
> lengths, noise, etc.  If we somehow did need to get a max speed in the
> device tree it seems like we could just adjust the max speed for the
> slave to be something lower.  In other words if you know a board has
> an sdm845 on it and you know that the SPI clock on sdm845 can't go
> over 50 MHz then it would make no sense to suggest that we should run
> the SPI clock for a device at 100 MHz.

What you might do is determine the slave can run at 100 MHz, in some
cases.  The board, traces, master, etc. can do it, in some cases.  But
it's also possible to change the clocking design or settings at a
higher level, which trickles down to the SPI master IP block having a
lower clock.  This is handled by the master max speed being less then
the slave's max speed.

The master max wouldn't be in the DT, since it's probably determined at
run time based on input clock to the master.  Based on the SoC core
clock, voltage, power mode, etc.

So you might have a DT with a slave at 100 MHz, even if in some cases
the master's max is less than 100 MHz.  It's ok to depend on the master
to be the limiting factor.

Re: [PATCH v4 2/2] tpm: add support for nonblocking operation

[James Bottomley]

On Fri, 2018-08-10 at 11:56 -0700, Tadeusz Struk wrote:
> On 08/10/2018 11:48 AM, James Bottomley wrote:
> > On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
> > > and the feedback I got from Jason was:
> > > 
> > > "I wonder if it is worth creating this when the first file is
> > > opened.. Lots of systems have TPMs but few use the userspace.."
> > > 
> > > so I changed this to allocate the WQ on first open. I think it
> > > makes sense, but I leave it to you to decide.
> > 
> > If the reason is to not create a wq unless it's needed, shouldn't
> > the condition actually be first open with flag O_NONBLOCK?
> > 
> 
> Not really because one can do:
> 
> int fd = open("/dev/tpm0", O_RDWR);
> fcntl(fd, F_SETFL, O_NONBLOCK);

so move the condition to first need to queue ...

James

support editing

[Kelly]

Your photos need editing. We can do it for you.
We do editing for e-commerce photos, jewelries images and portrait photos
etc.

This will include cutout and clipping path etc , also retouching if needed.

Let;s know if you want to send photos for working.
We can do test on your photos.

Thanks,
Kelly

support editing

[Kelly]

Your photos need editing. We can do it for you.
We do editing for e-commerce photos, jewelries images and portrait photos
etc.

This will include cutout and clipping path etc , also retouching if needed.

Let;s know if you want to send photos for working.
We can do test on your photos.

Thanks,
Kelly

Re: [PATCH v3] resource: Merge resources on a node when hot-adding memory

[Oscar Salvador]

On Sat, Aug 11, 2018 at 12:25:39AM +1000, Rashmica Gupta wrote:
> On Fri, Aug 10, 2018 at 11:00 PM, Michal Hocko  wrote:
> > On Fri 10-08-18 16:55:40, Rashmica Gupta wrote:
> > [...]
> >> Most memory hotplug/hotremove seems to be block or section based, and
> >> always adds and removes memory at the same place.
> >
> > Yes and that is hard wired to the memory hotplug code. It is not easy to
> > make it work outside of section units restriction. So whatever your
> > memtrace is doing and if it relies on subsection hotplug it cannot
> > possibly work with the current code.
> >
> > I didn't get to review your patch but if it is only needed for an
> > unmerged code I would rather incline to not merge it unless it is a
> > clear win to the resource subsystem. A report from Oscar shows that this
> > is not the case though.
> >
> 
> Yup, makes sense. I'll work on it and see if I can not break things.

In __case__ we really need this patch, I think that one way to fix this is
to only call merge_node_resources() in case the node is already online.
Something like this (completely untested):

+struct resource *request_resource_and_merge(struct resource *parent,
+   struct resource *new, int nid)
+{
+   struct resource *conflict;
+
+   conflict = request_resource_conflict(parent, new);
+
+   if (conflict)
+   return conflict;
+
+#ifdef CONFIG_MEMORY_HOTREMOVE
+   /* We do not need to merge any resources on a node that is being
+* hot-added together with its memory.
+* The node will be allocated later.
+*/
+   if (node_online(nid))
+   merge_node_resources(nid, parent);
+#endif /* CONFIG_MEMORY_HOTREMOVE */

Although as Michal said, all memory-hotplug code is section-oriented, so
whatever it is that interacts with it should expect that.
Otherwise it can fail soon or later.

-- 
Oscar Salvador
SUSE L3

[PATCH] platform/x86: asus-wmi: Add keymap entry for lid flip action on Asus UX360

[Aleh Filipovich]

Add entry to WMI keymap for lid flip event on Asus UX360.

On Asus Zenbook ux360 flipping lid from/to tablet mode triggers
keyscan code 0xfa which cannot be handled and results in kernel
log message "Unknown key fa pressed".


Signed-off-by: Aleh Filipovich
---
 drivers/platform/x86/asus-nb-wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/asus-nb-wmi.c 
b/drivers/platform/x86/asus-nb-wmi.c
index 136ff2b4cce5..db2af09067db 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -496,6 +496,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
{ KE_KEY, 0xC4, { KEY_KBDILLUMUP } },
{ KE_KEY, 0xC5, { KEY_KBDILLUMDOWN } },
{ KE_IGNORE, 0xC6, },  /* Ambient Light Sensor notification */
+   { KE_KEY, 0xFA, { KEY_PROG2 } },   /* Lid flip action */
{ KE_END, 0},
 };
 
--

2.18.0

Re: BUG: Mount ignores mount options

[Andy Lutomirski]

On Fri, Aug 10, 2018 at 9:14 AM, Theodore Y. Ts'o  wrote:
> And I'm not really sure it helps the container use
> case, since the whole point is they want their "guest" to be able to
> blithely run "mount /dev/sda1 -o noxattr /mnt" and not worry about the
> fact that in some other container, someone had run "mount /dev/sda1 -o
> xattr /mnt".  But having the second mount fail because of conflicting
> mount option breaks the illusion that containers are functionally as
> rich as VM's.

If the same block device is visible, with rw access, in two different
containers, I don't see any anything good can happen.  Sure, with the
current somewhat erratic semantics of mount(2), something kind of sort
of reasonable happens if they both mount it.  But if one or both of
them try to use, say, tune2fs or fsck, it's not going to go well.  And
a situation where they mount with different options and the result
depends on the order of the mounts is just plain bad.

I see four sane ways to deal with this:

1. Don't put the block device in the container at all.  The container
manager mounts it.

2. Use seccomp or a similar mechanism to intercept and emulate the
mount request.

3. Teach the filesystem driver to do something sensible.  This will
inherently be per-fs, and probably involves some serious magic or
allowing filesystem-specific vfsmount options.

4. Introduce a concept of a special kind of fake block device that
refers to an existing superblock, doesn't allow direct read or write,
and does the right thing when mounted.  Not obviously worth the
effort.

It seems to me that the current approach mostly involves crossing our fingers.

Re: [PATCH v9 2/2] regulator: add QCOM RPMh regulator driver

[Doug Anderson]

Hi,

On Fri, Aug 10, 2018 at 9:29 AM, Mark Brown  wrote:
> On Fri, Jul 13, 2018 at 06:50:59PM -0700, David Collins wrote:
>
>> + switch (rpmh_mode) {
>
>> + default:
>> + mode = REGULATOR_MODE_INVALID;
>> + }
>
> I'm not sure why the break statements are being omitted in default
> cases, but I do find myself stopping and trying to figure it out?

Hopefully 

addresses this?

Thanks!

-Doug

Re: [PATCH 3/3] arm64: reliable stacktraces

[Josh Poimboeuf]

On Fri, Aug 10, 2018 at 06:03:11PM +0200, Torsten Duwe wrote:
> This is more an RFC in the original sense: is this basically
> the correct approach? (as I had to tweak the API a bit).
> 
> In particular the code does not detect interrupts and exception
> frames, and does not yet check whether the code address is valid.
> The latter check would also have to be omitted for the latest frame
> on other tasks' stacks. This would require some more tweaking.
> 
> unwind_frame() now reports whether we had to stop normally or due to
> an error condition; walk_stackframe() will pass that info.
> __save_stack_trace() is used for a start to check the validity of a
> frame; maybe save_stack_trace_tsk_reliable() will need its own callback.
> 
> Any comments welcome.
> 
> Signed-off-by: Torsten Duwe 

Before we do this we'll need the same analysis we did for ppc64le to
figure out if objtool is needed.

-- 
Josh

Re: [RFC] RISC-V: Fix !CONFIG_SMP compilation error

[Palmer Dabbelt]

On Fri, 10 Aug 2018 11:31:08 PDT (-0700), atish.pa...@wdc.com wrote:

On 8/6/18 4:17 PM, Atish Patra wrote:

Enabling both CONFIG_PERF_EVENTS without !CONFIG_SMP
generates following compilation error.

arch/riscv/include/asm/perf_event.h:80:2: error: expected
specifier-qualifier-list before 'irqreturn_t'

   irqreturn_t (*handle_irq)(int irq_num, void *dev);
   ^~~

Include interrupt.h in proper place to avoid compilation
error.

Signed-off-by: Atish Patra 
---
  arch/riscv/include/asm/perf_event.h | 1 +
  arch/riscv/kernel/perf_event.c  | 1 -
  2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/perf_event.h 
b/arch/riscv/include/asm/perf_event.h
index 0e638a0c..aefbfaa6 100644
--- a/arch/riscv/include/asm/perf_event.h
+++ b/arch/riscv/include/asm/perf_event.h
@@ -10,6 +10,7 @@

  #include 
  #include 
+#include 

  #define RISCV_BASE_COUNTERS   2

diff --git a/arch/riscv/kernel/perf_event.c b/arch/riscv/kernel/perf_event.c
index b0e10c4e..a243fae1 100644
--- a/arch/riscv/kernel/perf_event.c
+++ b/arch/riscv/kernel/perf_event.c
@@ -27,7 +27,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 


ping ?


Sorry about this, it got dropped.  This looks fine and fixes the bug, so I've 
gone and put it on for-next.


Thanks!

Re: [PATCH v3 1/2] RISC-V: Define sys_riscv_flush_icache when SMP=n

[Palmer Dabbelt]

On Fri, 10 Aug 2018 11:47:15 PDT (-0700), li...@roeck-us.net wrote:

On Fri, Aug 10, 2018 at 11:27:37AM -0700, Palmer Dabbelt wrote:

On Fri, 10 Aug 2018 01:38:04 PDT (-0700), Christoph Hellwig wrote:
>On Thu, Aug 09, 2018 at 03:19:51PM -0700, Palmer Dabbelt wrote:
>>This would be necessary to make non-SMP builds work, but there is
>>another error in the implementation of our syscall linkage that actually
>>just causes sys_riscv_flush_icache to never build.  I've build tested
>>this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
>>normal.
>
>Would't it make sense to use COND_SYSCALL to stub out the syscall
>for !SMP builds?

I'm not sure.  We can implement the syscall fine in !SMP, it's just that the
vDSO is expected to always eat these calls because in non-SMP mode you can
do a global fence.i by just doing a local fence.i (there's only one hart).

The original rationale behind not having the syscall in non-SMP mode was to
limit the user ABI, but on looking again that seems like it's just a bit of
extra complexity that doesn't help anything.  It's already been demonstrated


Doesn't this mean that some userspace code will only run if the kernel was
compiled for SMP ? I always thought that was unacceptable.


Well, the officially sanctioned way to obtain this functionality is via a vDSO 
call.  On non-SMP systems it will never make the system call.  As a result we 
thought we'd keep it out of the ABI, but after looking again it seems yucky to 
do so.  Here's the vDSO entry, for reference:


   ENTRY(__vdso_flush_icache)
   .cfi_startproc
   #ifdef CONFIG_SMP
   li a7, __NR_riscv_flush_icache
   ecall
   #else
   fence.i
   li a0, 0
   #endif
   ret
   .cfi_endproc
   ENDPROC(__vdso_flush_icache)

Note that glibc has a fallback to make the system call if it can't find the 
vDSO entry, but then doesn't have a secondary fallback to emit a local fence.i 
if the system call doesn't exist.  It seems easier to fix the kernel to always 
provide the syscall and just call it a bug.

Re: [PATCH] gpio: it87: Add support for IT8613

[Linus Walleij]

On Thu, Aug 9, 2018 at 12:27 AM Leonid Bloch  wrote:

> This was tested on actual hardware and found to work fine, but currently
> the official specifications of this chip could not be obtained to
> confirm the numbers.
>
> Signed-off-by: Leonid Bloch 

Patch applied.

Yours,
Linus Walleij

Re: Fwd: PROBLEM: tpm_cpg can't request region with AMD/Dell fTPM

[Jarkko Sakkinen]

On Fri, Aug 10, 2018 at 07:57:35PM +0300, Jarkko Sakkinen wrote:
> On Tue, Aug 07, 2018 at 02:43:10PM -0400, Harlan Lieberman-Berg wrote:
> > (Resending as it seems to have been spamfiltered out from the ml;
> > sorry Peter, Jarkko for the duplicate)
> 
> I came on Monday from four week leave and have been basically been
> catching up with my emails :-) I'll look into this next week with
> time.

The error message is saying that someone else has reserved the resource
(-EBUSY).

This looks odd:

e78bf000-e7bbefff : ACPI Non-volatile Storage
  e7bb6000-e7bb9fff : MSFT0101:00
  e7bba000-e7bbdfff : MSFT0101:00

Why would be TPM registers mapped inside ACPI NV?

I would *guess* that what is happening is that perhaps drivers/acpi/nvs.c
maps the address space. This looks like a firmware bug, and such that we
cannot do anything about it.

I'm having a weird issue with the ACPI tables:

$ acpixtract acpidump.txt

Intel ACPI Component Architecture
ACPI Binary Table Extraction Utility version 20180105
Copyright (c) 2000 - 2018 Intel Corporation

  DSDT -   31048 bytes written (0x7948) - dsdt.dat
  SSDT - 349 bytes written (0x015D) - ssdt1.dat
  SSDT -   18086 bytes written (0x46A6) - ssdt2.dat
  SSDT -5225 bytes written (0x1469) - ssdt3.dat
  SSDT -1082 bytes written (0x043A) - ssdt4.dat
  SSDT -1017 bytes written (0x03F9) - ssdt5.dat
  SSDT -5369 bytes written (0x14F9) - ssdt6.dat

$ iasl -d *.dat   

Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20180105
Copyright (c) 2000 - 2018 Intel Corporation

Input file dsdt.dat, Length 0x7948 (31048) bytes
Table [DSDT] is too long for file - needs: 0x815D, remaining in file: 0x7948
Could not get ACPI tables from dsdt.dat, AE_BAD_HEADER

This has not happened to me before.

/Jarkko

Re: [PATCH] regulator: qcom-rpmh: Add stylistic breaks in the default cases

[David Collins]

On 08/10/2018 01:05 PM, Douglas Anderson wrote:
> No functional change here but it can make the code more readable to
> have breaks in the "default" case even though it's the last case.
> Let's add them.
> 
> Signed-off-by: Douglas Anderson 
> ---
> 
>  drivers/regulator/qcom-rpmh-regulator.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/regulator/qcom-rpmh-regulator.c 
> b/drivers/regulator/qcom-rpmh-regulator.c
> index 9f27daebd8c8..b8434e521d72 100644
> --- a/drivers/regulator/qcom-rpmh-regulator.c
> +++ b/drivers/regulator/qcom-rpmh-regulator.c
> @@ -504,6 +504,7 @@ static unsigned int 
> rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int rpmh_mode)
>   break;
>   default:
>   mode = REGULATOR_MODE_INVALID;
> + break;
>   }
>  
>   return mode;
> @@ -537,6 +538,7 @@ rpmh_regulator_pmic4_smps_of_map_mode(unsigned int 
> rpmh_mode)
>   break;
>   default:
>   mode = REGULATOR_MODE_INVALID;
> + break;
>   }
>  
>   return mode;
> @@ -566,6 +568,7 @@ static unsigned int 
> rpmh_regulator_pmic4_bob_of_map_mode(unsigned int rpmh_mode)
>   break;
>   default:
>   mode = REGULATOR_MODE_INVALID;
> + break;
>   }
>  
>   return mode;

Reviewed-by: David Collins 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v1 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs

[vnkgutta]

On 2018-08-09 20:59, Borislav Petkov wrote:
On Wed, Aug 01, 2018 at 01:33:34PM -0700, Venkata Narendra Kumar Gutta 
wrote:

From: Channagoud Kadabi 

Add error reporting driver for SBEs and DBEs. As of now, this driver


Please write out those abbreviations.
Done, I just followed the other commits which has the same and thought 
they are understood in the community,

I'll update it in the next patch set.



supports erp for Last Level Cache Controller (LLCC). This driver takes
care of dumping registers and adding config options to enable and
disable panic when the errors happen in cache.

Co-developed-by: Venkata Narendra Kumar Gutta 


Signed-off-by: Venkata Narendra Kumar Gutta 
Signed-off-by: Channagoud Kadabi 


The proper order is:

SOB: Author
SOB: Sender/handler/...

So:

Signed-off-by: Channagoud Kadabi 
Signed-off-by: Venkata Narendra Kumar Gutta 

Ok, I'll update accordingly.




---
 MAINTAINERS  |   7 +
 drivers/edac/Kconfig |  28 +++
 drivers/edac/Makefile|   1 +
 drivers/edac/qcom_edac.c | 507 
+++

 4 files changed, 543 insertions(+)
 create mode 100644 drivers/edac/qcom_edac.c

diff --git a/MAINTAINERS b/MAINTAINERS
index f6a9b08..68b3484 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5227,6 +5227,13 @@ L:   linux-e...@vger.kernel.org
 S: Maintained
 F: drivers/edac/ti_edac.c

+EDAC-QUALCOMM
+M: Channagoud Kadabi
+M: Venkata Narendra Kumar Gutta


Space between name and email address.


+L: linux-arm-...@vger.kernel.org


Also

L:  linux-e...@vger.kernel.org

so that the EDAC ML gets CCed too.

Ok, Done



+S: Maintained
+F: drivers/edac/qcom_edac.c
+
 EDIROL UA-101/UA-1000 DRIVER
 M: Clemens Ladisch 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 57304b2..c654b0e 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -460,4 +460,32 @@ config EDAC_TI
  Support for error detection and correction on the
   TI SoCs.

+config EDAC_QCOM
+   depends on EDAC=y


Why on EDAC=y? Did you blindly copy it or is there a reason why
edac_core should be only built-in or can it be a module too?


I took it from EDAC_ALTERA example. I want to put it like EDAC_QCOM
should be dependent on EDAC. Doesn't it make any sense or we don't need 
this at all?

or do you think it's redundant?




+   tristate "QCOM EDAC Controller"
+   help
+   Support for error detection and correction on the
+   QCOM SoCs.
+
+config EDAC_QCOM_LLCC
+   depends on EDAC_QCOM=y && QCOM_LLCC
+   tristate "QCOM EDAC Controller for LLCC Cache"
+   help
+   Support for error detection and correction on the
+   QCOM LLCC cache. Report errors caught by LLCC ECC
+   mechanism.
+
+   For debugging issues having to do with stability and overall 
system
+   health, you should probably say 'Y' here.
+
+config EDAC_QCOM_LLCC_PANIC_ON_UE
+   depends on EDAC_QCOM_LLCC
+   bool "Panic on uncorrectable errors - qcom llcc"
+   help
+   Forcibly cause a kernel panic if an uncorrectable error (UE) is
+   detected. This can reduce debugging times on hardware which may 
be
+   operating at voltages or frequencies outside normal 
specification.
+
+   For production builds, you should probably say 'N' here.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 02b43a7..716096d 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_EDAC_ALTERA) += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
 obj-$(CONFIG_EDAC_TI)  += ti_edac.o
+obj-$(CONFIG_EDAC_QCOM)+= qcom_edac.o
diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
new file mode 100644
index 000..cf3e2b0
--- /dev/null
+++ b/drivers/edac/qcom_edac.c
@@ -0,0 +1,507 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "edac_mc.h"
+#include "edac_device.h"
+
+#ifdef CONFIG_EDAC_QCOM_LLCC_PANIC_ON_UE
+#define LLCC_ERP_PANIC_ON_UE1
+#else
+#define LLCC_ERP_PANIC_ON_UE0
+#endif
+
+#define EDAC_LLCC   "qcom_llcc"
+
+#define TRP_SYN_REG_CNT 6
+
+#define DRP_SYN_REG_CNT 8
+
+#define LLCC_COMMON_STATUS0 0x0003000C
+#define LLCC_LB_CNT_MASKGENMASK(31, 28)
+#define LLCC_LB_CNT_SHIFT   28
+
+/* single & Double Bit syndrome register offsets */
+#define TRP_ECC_SB_ERR_SYN0 0x0002304C
+#define TRP_ECC_DB_ERR_SYN0 0x00020370
+#define 

Re: [PATCH v1 2/4] drivers: soc: Add support to register LLCC EDAC driver

[vnkgutta]

On 2018-08-10 10:21, Evan Green wrote:

On Wed, Aug 1, 2018 at 1:33 PM Venkata Narendra Kumar Gutta
 wrote:


Cache error reporting controller is to detect and report single
and double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.

Signed-off-by: Venkata Narendra Kumar Gutta 
---
 drivers/soc/qcom/llcc-slice.c  | 18 --
 include/linux/soc/qcom/llcc-qcom.h |  2 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/llcc-slice.c 
b/drivers/soc/qcom/llcc-slice.c

index a63640d..09c8bb0 100644
--- a/drivers/soc/qcom/llcc-slice.c
+++ b/drivers/soc/qcom/llcc-slice.c
@@ -224,7 +224,7 @@ static int qcom_llcc_cfg_program(struct 
platform_device *pdev)

u32 attr0_val;
u32 max_cap_cacheline;
u32 sz;
-   int ret;
+   int ret = 0;
const struct llcc_slice_config *llcc_table;
struct llcc_slice_desc desc;

@@ -282,6 +282,7 @@ int qcom_llcc_probe(struct platform_device *pdev,
struct resource *llcc_banks_res, *llcc_bcast_res;
void __iomem *llcc_banks_base, *llcc_bcast_base;
int ret, i;
+   struct platform_device *llcc_edac;

drv_data = devm_kzalloc(dev, sizeof(*drv_data), GFP_KERNEL);
if (!drv_data)
@@ -341,6 +342,19 @@ int qcom_llcc_probe(struct platform_device *pdev,
mutex_init(_data->lock);
platform_set_drvdata(pdev, drv_data);

-   return qcom_llcc_cfg_program(pdev);
+   ret = qcom_llcc_cfg_program(pdev);
+   if (ret)
+   return ret;
+
+   drv_data->ecc_irq = platform_get_irq(pdev, 0);
+   if (drv_data->ecc_irq >= 0) {


This condition will always be true for u32. See below...

That's true. I missed that.



+   llcc_edac = platform_device_register_data(>dev,
+   "qcom_llcc_edac", -1, 
drv_data,

+   sizeof(*drv_data));
+   if (IS_ERR(llcc_edac))
+   dev_err(dev, "Failed to register llcc edac 
driver\n");

+   }
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(qcom_llcc_probe);
diff --git a/include/linux/soc/qcom/llcc-qcom.h 
b/include/linux/soc/qcom/llcc-qcom.h

index c681e79..1a3bc25 100644
--- a/include/linux/soc/qcom/llcc-qcom.h
+++ b/include/linux/soc/qcom/llcc-qcom.h
@@ -78,6 +78,7 @@ struct llcc_slice_config {
  * @num_banks: Number of llcc banks
  * @bitmap: Bit map to track the active slice ids
  * @offsets: Pointer to the bank offsets array
+ * @ecc_irq: interrupt for llcc cache error detection and reporting
  */
 struct llcc_drv_data {
struct regmap *regmap;
@@ -89,6 +90,7 @@ struct llcc_drv_data {
u32 num_banks;
unsigned long *bitmap;
u32 *offsets;
+   u32 ecc_irq;


The return type for platform_get_irq is int, so this should probably
be int, or "unsigned", but then you'd need to fix your logic above.
I think we should keep that as int. I'll check on which one I'm supposed 
to use here and update in the next version.



 };

 #if IS_ENABLED(CONFIG_QCOM_LLCC)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,

a Linux Foundation Collaborative Project

Re: [PATCH v4 2/2] tpm: add support for nonblocking operation

[Tadeusz Struk]

On 08/10/2018 11:48 AM, James Bottomley wrote:
> On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
>> and the feedback I got from Jason was:
>>
>> "I wonder if it is worth creating this when the first file is
>> opened.. Lots of systems have TPMs but few use the userspace.."
>>
>> so I changed this to allocate the WQ on first open. I think it makes
>> sense, but I leave it to you to decide.
> 
> If the reason is to not create a wq unless it's needed, shouldn't the
> condition actually be first open with flag O_NONBLOCK?
> 

Not really because one can do:

int fd = open("/dev/tpm0", O_RDWR);
fcntl(fd, F_SETFL, O_NONBLOCK);

-- 
Tadeusz

Re: [PATCH v4 5/6] iio:adxl372: Add sampling frequency support

[Marcus Folkesson]

Hi Stefan,

On Mon, Aug 06, 2018 at 03:04:46PM +0300, Stefan Popa wrote:
> This patch adds the option for the user to select the sampling frequency.
> Also, the user can read the available frequencies and read the currently
> set frequency via the read_raw function. The frequency can be set via the
> write_raw function.
> 
> When the frequency is set, the bandwidth is also checked and ensured
> that it is constrained to at most half of the sampling frequency. Also, the
> activity and inactivity timers have to be updated because they depend on
> the selected ODR.
> 
> Signed-off-by: Stefan Popa 
> ---
>  drivers/iio/accel/adxl372.c | 74 
> -
>  1 file changed, 73 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index 623c32d..d991d1c 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -223,7 +223,8 @@ static const struct adxl372_axis_lookup 
> adxl372_axis_lookup_table[] = {
>   .modified = 1,  \
>   .channel2 = IIO_MOD_##axis, \
>   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
> - .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
>   .scan_index = index,\
>   .scan_type = {  \
>   .sign = 's',\
> @@ -311,6 +312,19 @@ static int adxl372_set_odr(struct adxl372_state *st,
>   return ret;
>  }
>  
> +static int adxl372_find_closest_match(const int *array,
> +   unsigned int size, int val)
> +{
> + int i;
> +
> + for (i = 0; i < size; i++) {
> + if (val <= array[i])
> + return i;
> + }
> +
> + return size - 1;
> +}

Hum, would find_closest() work for this?
See include/linux/util_macros.h

> +
>  static int adxl372_set_bandwidth(struct adxl372_state *st,
>enum adxl372_bandwidth bw)
>  {
> @@ -631,6 +645,51 @@ static int adxl372_read_raw(struct iio_dev *indio_dev,
>   *val = 0;
>   *val2 = ADXL372_USCALE;
>   return IIO_VAL_INT_PLUS_MICRO;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *val = adxl372_samp_freq_tbl[st->odr];
> + return IIO_VAL_INT;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int adxl372_write_raw(struct iio_dev *indio_dev,
> +  struct iio_chan_spec const *chan,
> +  int val, int val2, long info)
> +{
> + struct adxl372_state *st = iio_priv(indio_dev);
> + int odr_index, ret;
> +

Is it worth to make sure that val2 is zero here?

> + switch (info) {
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + odr_index = adxl372_find_closest_match(adxl372_samp_freq_tbl,
> + ARRAY_SIZE(adxl372_samp_freq_tbl),
> + val);
> + ret = adxl372_set_odr(st, odr_index);
> + if (ret < 0)
> + return ret;
> + /*
> +  * The timer period depends on the ODR selected.
> +  * At 3200 Hz and below, it is 6.6 ms; at 6400 Hz, it is 3.3 ms
> +  */
> + ret = adxl372_set_activity_time_ms(st, st->act_time_ms);
> + if (ret < 0)
> + return ret;
> + /*
> +  * The timer period depends on the ODR selected.
> +  * At 3200 Hz and below, it is 26 ms; at 6400 Hz, it is 13 ms
> +  */
> + ret = adxl372_set_inactivity_time_ms(st, st->inact_time_ms);
> + if (ret < 0)
> + return ret;
> + /*
> +  * The maximum bandwidth is constrained to at most half of
> +  * the ODR to ensure that the Nyquist criteria is not violated
> +  */
> + if (st->bw > odr_index)
> + ret = adxl372_set_bandwidth(st, odr_index);
> +
> + return ret;
>   default:
>   return -EINVAL;
>   }
> @@ -763,8 +822,21 @@ static const struct iio_trigger_ops adxl372_trigger_ops 
> = {
>   .set_trigger_state = adxl372_dready_trig_set_state,
>  };
>  
> +static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("400 800 1600 3200 6400");
> +
> +static struct attribute *adxl372_attributes[] = {
> + _const_attr_sampling_frequency_available.dev_attr.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group adxl372_attrs_group = {
> + .attrs = adxl372_attributes,
> +};
> +
>  static const struct iio_info adxl372_info = {
> + .attrs = _attrs_group,
>   .read_raw = 

Re: [PATCH v8 3/6] Uprobes: Support SDT markers having reference count (semaphore)

[Steven Rostedt]

On Thu, 9 Aug 2018 16:38:28 +0200
Oleg Nesterov  wrote:

> I need to read this (hopefully final) version carefully. I'll try to do
> this before next Monday.
> 

Monday may be the opening of the merge window (more likely Sunday). Do
you think this is good enough for pushing it in this late in the game,
or do you think we should wait another cycle?

-- Steve

Our Company Beijing Shougang Company Ltd., based in China is in search of a competent individual or firm that will be responsible in handling funds as our ''Representative Manager'' in the United Stat

[Beijing Shougang Company Ltd]

Note: It is a part time job that won't interrupt your present work or business. 

Looking forward to your response. 

Best Regards, 
Liu Nianzu
HR(Representative Manager)
Beijing Shougang Company Ltd. 
No 15,Pingguoyuan Road,Shijingshan District,Beijing
Website: www.sggf.com.cn

[PATCH] regulator: qcom-rpmh: Add stylistic breaks in the default cases

[Douglas Anderson]

No functional change here but it can make the code more readable to
have breaks in the "default" case even though it's the last case.
Let's add them.

Signed-off-by: Douglas Anderson 
---

 drivers/regulator/qcom-rpmh-regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/qcom-rpmh-regulator.c 
b/drivers/regulator/qcom-rpmh-regulator.c
index 9f27daebd8c8..b8434e521d72 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -504,6 +504,7 @@ static unsigned int 
rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int rpmh_mode)
break;
default:
mode = REGULATOR_MODE_INVALID;
+   break;
}
 
return mode;
@@ -537,6 +538,7 @@ rpmh_regulator_pmic4_smps_of_map_mode(unsigned int 
rpmh_mode)
break;
default:
mode = REGULATOR_MODE_INVALID;
+   break;
}
 
return mode;
@@ -566,6 +568,7 @@ static unsigned int 
rpmh_regulator_pmic4_bob_of_map_mode(unsigned int rpmh_mode)
break;
default:
mode = REGULATOR_MODE_INVALID;
+   break;
}
 
return mode;
-- 
2.18.0.597.ga71716f1ad-goog

[PATCH v2] coccicheck: return proper error code on fail

[efremov]

From: Denis Efremov 

If coccicheck fails, it should return an error code distinct from zero
to signal about an internal problem. Current code instead of exiting with
the tool's error code returns the error code of 'echo "coccicheck failed"'
which is almost always equals to zero, thus failing the original intention
of alerting about a problem. This patch fixes the code.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Denis Efremov 
---
 scripts/coccicheck | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/coccicheck b/scripts/coccicheck
index 9fedca611b7f..e04d328210ac 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -128,9 +128,10 @@ run_cmd_parmap() {
fi
echo $@ >>$DEBUG_FILE
$@ 2>>$DEBUG_FILE
-   if [[ $? -ne 0 ]]; then
+   err=$?
+   if [[ $err -ne 0 ]]; then
echo "coccicheck failed"
-   exit $?
+   exit $err
fi
 }
 
-- 
2.17.1

Re: [RFC v7 PATCH 1/4] mm: refactor do_munmap() to extract the common part

[Yang Shi]

On 8/10/18 10:41 AM, Matthew Wilcox wrote:

On Fri, Aug 10, 2018 at 07:36:00AM +0800, Yang Shi wrote:

+static inline bool addr_ok(unsigned long start, size_t len)

Maybe munmap_range_ok()?  Otherwise some of the conditions here don't make
sense for such a generic sounding function.


I don't know. I think the argument is about munmap_ prefix should be used.




  {
-   unsigned long end;
-   struct vm_area_struct *vma, *prev, *last;
-
if ((offset_in_page(start)) || start > TASK_SIZE || len > 
TASK_SIZE-start)
-   return -EINVAL;
+   return false;
  
-	len = PAGE_ALIGN(len);

-   if (len == 0)
-   return -EINVAL;
+   if (PAGE_ALIGN(len) == 0)
+   return false;
+
+   return true;
+}
+
+/*
+ * munmap_lookup_vma: find the first overlap vma and split overlap vmas.
+ * @mm: mm_struct
+ * @start: start address
+ * @end: end address
+ *
+ * returns the pointer to vma, NULL or err ptr when spilt_vma returns error.

kernel-doc prefers:

  * Return: %NULL if no VMA overlaps this range.  An ERR_PTR if an
  * overlapping VMA could not be split.  Otherwise a pointer to the first
  * VMA which overlaps the range.


Ok, will fix it.




+ */
+static struct vm_area_struct *munmap_lookup_vma(struct mm_struct *mm,
+   unsigned long start, unsigned long end)
+{
+   struct vm_area_struct *vma, *prev, *last;
  
  	/* Find the first overlapping VMA */

vma = find_vma(mm, start);
if (!vma)
-   return 0;
-   prev = vma->vm_prev;
-   /* we have  start < vma->vm_end  */
+   return NULL;
  
+	/* we have  start < vma->vm_end  */

Can you remove the duplicate spaces here?


Sure

Thanks,
Yang

Re: [PATCH] coccicheck: return proper error code on check fail

[Himanshu Jha]

On Fri, Aug 10, 2018 at 05:45:46PM +0300, Denis Efremov wrote:
> My mistake. Initially, I thought that this line signals about errors
> in the code, but now I see that this is about the tool's internal
> error. However, this doesn't change the fact that coccicheck returns
> the improper error code.
> 
> I will reformulate the commit message and send the v2 patch with the
> same diff. Thank you for clarifying things.

I would also request to use the latest source from 
https://github.com/coccinelle/coccinelle

Because some distribution supplied coccinelle packages are
obsolete and likely more prone to be disfunctional.

For instance: https://systeme.lip6.fr/pipermail/cocci/2017-December/004799.html

Thanks.
-- 
Himanshu Jha
Undergraduate Student
Department of Electronics & Communication
Guru Tegh Bahadur Institute of Technology

[tip:x86/pti] x86/mm/pti: Move user W+X check into pti_finalize()

[tip-bot for Joerg Roedel]

Commit-ID:  d878efce73fe86db34ddb2013260adf571a701a7
Gitweb: https://git.kernel.org/tip/d878efce73fe86db34ddb2013260adf571a701a7
Author: Joerg Roedel 
AuthorDate: Wed, 8 Aug 2018 13:16:40 +0200
Committer:  Thomas Gleixner 
CommitDate: Fri, 10 Aug 2018 21:12:45 +0200

x86/mm/pti: Move user W+X check into pti_finalize()

The user page-table gets the updated kernel mappings in pti_finalize(),
which runs after the RO+X permissions got applied to the kernel page-table
in mark_readonly().

But with CONFIG_DEBUG_WX enabled, the user page-table is already checked in
mark_readonly() for insecure mappings.  This causes false-positive
warnings, because the user page-table did not get the updated mappings yet.

Move the W+X check for the user page-table into pti_finalize() after it
updated all required mappings.

[ tglx: Folded !NX supported fix ]

Signed-off-by: Joerg Roedel 
Signed-off-by: Thomas Gleixner 
Cc: "H . Peter Anvin" 
Cc: linux...@kvack.org
Cc: Linus Torvalds 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Peter Zijlstra 
Cc: Borislav Petkov 
Cc: Jiri Kosina 
Cc: Boris Ostrovsky 
Cc: Brian Gerst 
Cc: David Laight 
Cc: Denys Vlasenko 
Cc: Eduardo Valentin 
Cc: Greg KH 
Cc: Will Deacon 
Cc: aligu...@amazon.com
Cc: daniel.gr...@iaik.tugraz.at
Cc: hu...@google.com
Cc: keesc...@google.com
Cc: Andrea Arcangeli 
Cc: Waiman Long 
Cc: Pavel Machek 
Cc: "David H . Gutteridge" 
Cc: j...@8bytes.org
Link: https://lkml.kernel.org/r/1533727000-9172-1-git-send-email-j...@8bytes.org
---
 arch/x86/include/asm/pgtable.h | 7 +--
 arch/x86/mm/dump_pagetables.c  | 6 +++---
 arch/x86/mm/pti.c  | 2 ++
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index e39088cb59ab..a1cb3339da8d 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -30,11 +30,14 @@ int __init __early_make_pgtable(unsigned long address, 
pmdval_t pmd);
 void ptdump_walk_pgd_level(struct seq_file *m, pgd_t *pgd);
 void ptdump_walk_pgd_level_debugfs(struct seq_file *m, pgd_t *pgd, bool user);
 void ptdump_walk_pgd_level_checkwx(void);
+void ptdump_walk_user_pgd_level_checkwx(void);
 
 #ifdef CONFIG_DEBUG_WX
-#define debug_checkwx() ptdump_walk_pgd_level_checkwx()
+#define debug_checkwx()ptdump_walk_pgd_level_checkwx()
+#define debug_checkwx_user()   ptdump_walk_user_pgd_level_checkwx()
 #else
-#define debug_checkwx() do { } while (0)
+#define debug_checkwx()do { } while (0)
+#define debug_checkwx_user()   do { } while (0)
 #endif
 
 /*
diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index ccd92c4da57c..a12afff146d1 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -569,12 +569,13 @@ void ptdump_walk_pgd_level_debugfs(struct seq_file *m, 
pgd_t *pgd, bool user)
 }
 EXPORT_SYMBOL_GPL(ptdump_walk_pgd_level_debugfs);
 
-static void ptdump_walk_user_pgd_level_checkwx(void)
+void ptdump_walk_user_pgd_level_checkwx(void)
 {
 #ifdef CONFIG_PAGE_TABLE_ISOLATION
pgd_t *pgd = INIT_PGD;
 
-   if (!static_cpu_has(X86_FEATURE_PTI))
+   if (!(__supported_pte_mask & _PAGE_NX) ||
+   !static_cpu_has(X86_FEATURE_PTI))
return;
 
pr_info("x86/mm: Checking user space page tables\n");
@@ -586,7 +587,6 @@ static void ptdump_walk_user_pgd_level_checkwx(void)
 void ptdump_walk_pgd_level_checkwx(void)
 {
ptdump_walk_pgd_level_core(NULL, NULL, true, false);
-   ptdump_walk_user_pgd_level_checkwx();
 }
 
 static int __init pt_dump_init(void)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 1dc5c683e7a5..d58b4aba9510 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -646,4 +646,6 @@ void pti_finalize(void)
 */
pti_clone_entry_text();
pti_clone_kernel_text();
+
+   debug_checkwx_user();
 }

Re: [PATCH 1/2] phy: qcom-qmp: Quiet -EPROBE_DEFER from qcom_qmp_phy_probe()

[Doug Anderson]

Kishon,

On Mon, May 14, 2018 at 3:42 PM, Douglas Anderson  wrote:
> The -EPROBE_DEFER virus demands special case code to avoid printing
> error messages when the error is only -EPROBE_DEFER.  Spread the virus
> to a new host: qcom_qmp_phy_probe().  Specifically handle when our
> regulators might not be ready yet.
>
> Signed-off-by: Douglas Anderson 
> ---
>
>  drivers/phy/qualcomm/phy-qcom-qmp.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

I'm curious what you think of this patch and the next one.  Is it
something you'd apply or are you not interested?  Either way is fine
(it's just log spam) but I thought I'd check.  Thanks!  :)


-Doug

Details des Kreditantrags

[Adams John]

Hallo
  Diese Adams-Darlehen sind wir hier, um Darlehen an diejenigen, die
finanzielle Schwierigkeiten haben. Brauchen Sie einen Kredit, um die
Rechnungen zu bezahlen? Oder möchten Sie ein Unternehmen gründen,
haben aber nicht die Hauptstadt zur Hand? Wenn Sie finanzielle
Unterstützung benötigen, um ihren finanziellen Status zu verbessern,
indem Sie das Finanzgeschäft oder die Familie bestimmen. Mach dir
keine Sorgen mehr, denn wir sind hier, um sicherzustellen, dass wir
dir helfen können, deine finanzielle Instabilität zu lösen und dich
finanziell stabil zu machen. Wir bieten Notfallkredite an
Einzelpersonen und Familien. Einschließlich Organisationen und
Unternehmen. Kontaktieren Sie uns jetzt für Ihr Darlehen zu einem
Zinssatz ab 2% per E-Mail; adamsjohnloanf...@hotmail.com


Details des Kreditantrags

Kreditnehmer Vollständige Namen: ..
Adresse: .
Besetzung: 
Geschlecht: ..
Jahre ..
Telefonnummer: ...
Monatliches Einkommen: .
Land: ...
Stadt ...
Darlehen Zweck ...
Notwendige Menge .
Darlehensdauer ...
Haben Sie einen Kredit beantragt vor: .
Sprichst du Englisch .
Ich hoffe diese Form zu kennen.

Vielen Dank

Re: [PATCH v2] coccicheck: return proper error code on fail

[Julia Lawall]

On Fri, 10 Aug 2018, efre...@linux.com wrote:

> From: Denis Efremov 
>
> If coccicheck fails, it should return an error code distinct from zero
> to signal about an internal problem. Current code instead of exiting with
> the tool's error code returns the error code of 'echo "coccicheck failed"'
> which is almost always equals to zero, thus failing the original intention
> of alerting about a problem. This patch fixes the code.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Denis Efremov 

OK, I get it now.  Thanks.

Acked-by: Julia Lawall 

> ---
>  scripts/coccicheck | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/coccicheck b/scripts/coccicheck
> index 9fedca611b7f..e04d328210ac 100755
> --- a/scripts/coccicheck
> +++ b/scripts/coccicheck
> @@ -128,9 +128,10 @@ run_cmd_parmap() {
>   fi
>   echo $@ >>$DEBUG_FILE
>   $@ 2>>$DEBUG_FILE
> - if [[ $? -ne 0 ]]; then
> + err=$?
> + if [[ $err -ne 0 ]]; then
>   echo "coccicheck failed"
> - exit $?
> + exit $err
>   fi
>  }
>
> --
> 2.17.1
>
>

Re: [PATCH] pinctrl: uniphier: drop meaningless pin from SD1 pin-mux of Pro4

[Linus Walleij]

On Tue, Aug 7, 2018 at 4:50 AM Masahiro Yamada
 wrote:

> The pin 327 was supposed to be used as a voltage control line for the
> SD card regulator, but the SD card port1 does not support UHS-I.  It
> only supports 3.3V signaling, hence this pin is pointless.
>
> Just a note about the background.  At first, hardware engineers tried
> to implement the UHS for this port.  Then, they needed to shrink the
> silicon die size, and gave up the UHS, but forgot to remove the pin
> assignment.
>
> Signed-off-by: Masahiro Yamada 

This patch does not apply against my devel branch for v4.19.

Please rebase and resend.

Yours,
Linus Walleij

[PATCH 0/3] arm64: dts: sdm845: Add RPMh-regulators and usb

[Douglas Anderson]

This series adds device tree nodes for the RPMh regulators and USB.
These patches are based on patches in various downstream kernels from
Manu Gautam, David Collins, and Vivek Gautam.

This series was tested on SDM845-MTP (with no-AC firmware) atop Andy
Gross's current "for-next" branch at commit 76b9e7f947f1 ("Merge tag
'qcom-defconfig-for-4.19' into all-for-4.19") with some extra patches:

>From mainline:
- 87ed1405ef09 ("nvmem: Don't let a NULL cell_id for nvmem_cell_get() crash us")

>From clk-next:
- 9c7e47025a6b ("clk: qcom: clk-rpmh: Add QCOM RPMh clock driver")

>From regulator/for-next:
- 46fc033eba42 ("regulator: add QCOM RPMh regulator driver")
- 0db021f7a273 ("regulator: dt-bindings: add QCOM RPMh regulator bindings")

>From Will Deacon's tree (for-joerg/arm-smmu/updates):
- d1e20222d537 ("iommu/arm-smmu: Error out only if not enough context 
interrupts")

>From the mailing list (needs to be spun but works OK):
- dts: arm64/sdm845: Add node for arm,mmu-500
  https://lore.kernel.org/patchwork/patch/964814/

As you can see from the above all the dependencies except the addition
of the MMU node have landed so this series should be about ready to
land too.

If anyone would like to see the tree I used for test, it can be found
at:
  
https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/refs/sandbox/dianders/180810-agross-usbv2


Changes in v2:
- Use "0x784000" for qfprom rather than "0x78" as per docs.
- Add calibration for 2nd USB port too
- LDO14 initial mode is LPM and shouldn't be always on (Vivek G)
- LDO25 should have min voltage of 3.3V

Douglas Anderson (2):
  arm64: dts: qcom: sdm845-mtp: Add RPMh VRM/XOB regulators
  arm64: dts: qcom: sdm845-mtp: Add nodes for USB

Manu Gautam (1):
  arm64: dts: qcom: sdm845: Add USB-related nodes

 arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 506 
 arch/arm64/boot/dts/qcom/sdm845.dtsi| 196 +
 2 files changed, 702 insertions(+)

-- 
2.18.0.597.ga71716f1ad-goog

Re: [PATCH 3/3] mm/memory_hotplug: Cleanup unregister_mem_sect_under_nodes

[Andrew Morton]

On Fri, 10 Aug 2018 17:29:31 +0200 osalva...@techadventures.net wrote:

> From: Oscar Salvador 
> 
> With the assumption that the relationship between
> memory_block <-> node is 1:1, we can refactor this function a bit.
> 
> This assumption is being taken from register_mem_sect_under_node()
> code.
> 
> register_mem_sect_under_node() takes the mem_blk's nid, and compares it
> to the pfn's nid we are checking.
> If they match, we go ahead and link both objects.
> Once done, we just return.
> 
> So, the relationship between memory_block <-> node seems to stand.
> 
> Currently, unregister_mem_sect_under_nodes() defines a nodemask_t
> which is being checked in the loop to see if we have already unliked certain 
> node.

"unlinked a certain node"

> But since a memory_block can only belong to a node, we can drop the nodemask

"to a single node"?

> and the check within the loop.
> 
> If we find a match between the mem_block->nid and the nid of the
> pfn we are checking, we unlink the objects and return, as unlink the objects

"unlinking"

> once is enough.
> 
> --- a/drivers/base/node.c
> +++ b/drivers/base/node.c
> @@ -448,35 +448,27 @@ int register_mem_sect_under_node(struct memory_block 
> *mem_blk, void *arg)
>   return 0;
>  }
>  
> -/* unregister memory section under all nodes that it spans */
> +/* unregister memory section from the node it belongs to */
>  int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
>   unsigned long phys_index)
>  {
> - NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
>   unsigned long pfn, sect_start_pfn, sect_end_pfn;
> -
> - if (!unlinked_nodes)
> - return -ENOMEM;
> - nodes_clear(*unlinked_nodes);
> + int nid = mem_blk->nid;
>  
>   sect_start_pfn = section_nr_to_pfn(phys_index);
>   sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
>   for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
> - int nid;
> + int page_nid = get_nid_for_pfn(pfn);
>  
> - nid = get_nid_for_pfn(pfn);
> - if (nid < 0)
> - continue;
> - if (!node_online(nid))
> - continue;
> - if (node_test_and_set(nid, *unlinked_nodes))
> - continue;
> - sysfs_remove_link(_devices[nid]->dev.kobj,
> -  kobject_name(_blk->dev.kobj));
> - sysfs_remove_link(_blk->dev.kobj,
> -  kobject_name(_devices[nid]->dev.kobj));
> + if (page_nid >= 0 && page_nid == nid) {
> + sysfs_remove_link(_devices[nid]->dev.kobj,
> +  kobject_name(_blk->dev.kobj));
> + sysfs_remove_link(_blk->dev.kobj,
> +  kobject_name(_devices[nid]->dev.kobj));
> + break;
> + }
>   }
> - NODEMASK_FREE(unlinked_nodes);
> +
>   return 0;
>  }

I guess so.  But the node_online() check was silently removed?

[PATCH v3] checkpatch: DT bindings should be a separate patch

[Rob Herring]

Devicetree bindings should be their own patch as documented in
Documentation/devicetree/bindings/submitting-patches.txt section I.1.
This is because bindings are logically independent from a driver
implementation, they have a different maintainer (even though they often
are applied via the same tree), and it makes for a cleaner history in
the DT only tree created with git-filter-branch.

Cc: Andy Whitcroft 
Cc: Joe Perches 
Signed-off-by: Rob Herring 
---
 scripts/checkpatch.pl | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a9c05506e325..fa9b50d6f3d4 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2236,6 +2236,7 @@ sub process {
our $clean = 1;
my $signoff = 0;
my $is_patch = 0;
+   my $is_binding_patch = -1;
my $in_header_lines = $file ? 0 : 1;
my $in_commit_log = 0;  #Scanning lines before patch
my $has_commit_log = 0; #Encountered lines before patch
@@ -2485,6 +2486,19 @@ sub process {
$check = $check_orig;
}
$checklicenseline = 1;
+
+   if ($realfile !~ /^MAINTAINERS/) {
+   my $last_binding_patch = $is_binding_patch;
+
+   $is_binding_patch = () = $realfile =~ 
m@^(?:Documentation/devicetree/|include/dt-bindings/)@;
+
+   if (($last_binding_patch != -1) &&
+   ($last_binding_patch ^ $is_binding_patch)) {
+   WARN("DT_SPLIT_BINDING_PATCH",
+"DT binding docs and includes 
should be a separate patch. See: 
Documentation/devicetree/bindings/submitting-patches.txt\n");
+   }
+   }
+
next;
}
 
-- 
2.17.1

[PATCH 0/5] Miscellaneous fixes/enhancements

[kys]

From: "K. Y. Srinivasan" 

Miscellaneous fixes/enhancements.

K. Y. Srinivasan (1):
  Tools: hv: Fix a bug in the key delete code

Michael Kelley (1):
  Drivers: hv: vmbus: Fix synic per-cpu context initialization

Stephen Hemminger (3):
  vmbus: add driver_override support
  uio_hv_generic: increase size of receive and send buffers
  uio_hv_generic: drop #ifdef DEBUG

 Documentation/ABI/testing/sysfs-bus-vmbus |  21 
 drivers/hv/hv.c   |  15 ++-
 drivers/hv/vmbus_drv.c| 115 ++
 drivers/uio/uio_hv_generic.c  |   7 +-
 include/linux/hyperv.h|   1 +
 tools/hv/hv_kvp_daemon.c  |   2 +-
 6 files changed, 134 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-vmbus

-- 
2.18.0

[PATCH 5/5] Drivers: hv: vmbus: Fix synic per-cpu context initialization

[kys]

From: Michael Kelley 

If hv_synic_alloc() errors out, the state of the per-cpu context
for some CPUs is unknown since the zero'ing is done as each
CPU is iterated over.  In such case, hv_synic_cleanup() may try to
free memory based on uninitialized values.  Fix this by zero'ing
the per-cpu context for all CPUs before doing any memory
allocations that might fail.

Signed-off-by: Michael Kelley 
Reported-by: Dan Carpenter 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/hv.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 748a1c4172a6..332d7c34be5c 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -189,6 +189,17 @@ static void hv_init_clockevent_device(struct 
clock_event_device *dev, int cpu)
 int hv_synic_alloc(void)
 {
int cpu;
+   struct hv_per_cpu_context *hv_cpu;
+
+   /*
+* First, zero all per-cpu memory areas so hv_synic_free() can
+* detect what memory has been allocated and cleanup properly
+* after any failures.
+*/
+   for_each_present_cpu(cpu) {
+   hv_cpu = per_cpu_ptr(hv_context.cpu_context, cpu);
+   memset(hv_cpu, 0, sizeof(*hv_cpu));
+   }
 
hv_context.hv_numa_map = kcalloc(nr_node_ids, sizeof(struct cpumask),
 GFP_KERNEL);
@@ -198,10 +209,8 @@ int hv_synic_alloc(void)
}
 
for_each_present_cpu(cpu) {
-   struct hv_per_cpu_context *hv_cpu
-   = per_cpu_ptr(hv_context.cpu_context, cpu);
+   hv_cpu = per_cpu_ptr(hv_context.cpu_context, cpu);
 
-   memset(hv_cpu, 0, sizeof(*hv_cpu));
tasklet_init(_cpu->msg_dpc,
 vmbus_on_msg_dpc, (unsigned long) hv_cpu);
 
-- 
2.18.0

[PATCH 1/5] Tools: hv: Fix a bug in the key delete code

[kys]

From: "K. Y. Srinivasan" 

Fix a bug in the key delete code - the num_records range
from 0 to num_records-1.

Signed-off-by: K. Y. Srinivasan 
Reported-by: David Binderman 
Cc: 
---
 tools/hv/hv_kvp_daemon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index dbf6e8bd98ba..bbb2a8ef367c 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -286,7 +286,7 @@ static int kvp_key_delete(int pool, const __u8 *key, int 
key_size)
 * Found a match; just move the remaining
 * entries up.
 */
-   if (i == num_records) {
+   if (i == (num_records - 1)) {
kvp_file_info[pool].num_records--;
kvp_update_file(pool);
return 0;
-- 
2.18.0

[PATCH 4/5] uio_hv_generic: drop #ifdef DEBUG

[kys]

From: Stephen Hemminger 

DEBUG is leftover from the development phase, remove it.

Signed-off-by: Stephen Hemminger 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/uio/uio_hv_generic.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c
index 35678d08d9d8..ab0c0e7e8a44 100644
--- a/drivers/uio/uio_hv_generic.c
+++ b/drivers/uio/uio_hv_generic.c
@@ -19,7 +19,6 @@
  * # echo -n "ed963694-e847-4b2a-85af-bc9cfc11d6f3" \
  *> /sys/bus/vmbus/drivers/uio_hv_generic/bind
  */
-#define DEBUG 1
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
-- 
2.18.0

[PATCH 3/5] uio_hv_generic: increase size of receive and send buffers

[kys]

From: Stephen Hemminger 

When using DPDK there is significant performance boost by using
the largest possible send and receive buffer area.

Unfortunately, with UIO model there is not a good way to configure
this at run time. But it is okay to have a bigger buffer available
even if application only decides to use a smaller piece of it.

Signed-off-by: Stephen Hemminger 
Signed-off-by: K. Y. Srinivasan 
---
 drivers/uio/uio_hv_generic.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c
index c690d100adcd..35678d08d9d8 100644
--- a/drivers/uio/uio_hv_generic.c
+++ b/drivers/uio/uio_hv_generic.c
@@ -35,13 +35,13 @@
 
 #include "../hv/hyperv_vmbus.h"
 
-#define DRIVER_VERSION "0.02.0"
+#define DRIVER_VERSION "0.02.1"
 #define DRIVER_AUTHOR  "Stephen Hemminger "
 #define DRIVER_DESC"Generic UIO driver for VMBus devices"
 
 #define HV_RING_SIZE512/* pages */
-#define SEND_BUFFER_SIZE (15 * 1024 * 1024)
-#define RECV_BUFFER_SIZE (15 * 1024 * 1024)
+#define SEND_BUFFER_SIZE (16 * 1024 * 1024)
+#define RECV_BUFFER_SIZE (31 * 1024 * 1024)
 
 /*
  * List of resources to be mapped to user space
-- 
2.18.0

Re: [RFC] RISC-V: Fix !CONFIG_SMP compilation error

[Atish Patra]

On 8/6/18 4:17 PM, Atish Patra wrote:

Enabling both CONFIG_PERF_EVENTS without !CONFIG_SMP
generates following compilation error.

arch/riscv/include/asm/perf_event.h:80:2: error: expected
specifier-qualifier-list before 'irqreturn_t'

   irqreturn_t (*handle_irq)(int irq_num, void *dev);
   ^~~

Include interrupt.h in proper place to avoid compilation
error.

Signed-off-by: Atish Patra 
---
  arch/riscv/include/asm/perf_event.h | 1 +
  arch/riscv/kernel/perf_event.c  | 1 -
  2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/perf_event.h 
b/arch/riscv/include/asm/perf_event.h
index 0e638a0c..aefbfaa6 100644
--- a/arch/riscv/include/asm/perf_event.h
+++ b/arch/riscv/include/asm/perf_event.h
@@ -10,6 +10,7 @@
  
  #include 

  #include 
+#include 
  
  #define RISCV_BASE_COUNTERS	2
  
diff --git a/arch/riscv/kernel/perf_event.c b/arch/riscv/kernel/perf_event.c

index b0e10c4e..a243fae1 100644
--- a/arch/riscv/kernel/perf_event.c
+++ b/arch/riscv/kernel/perf_event.c
@@ -27,7 +27,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 


ping ?

Regards,
Atish

Re: [PATCH v4 2/2] tpm: add support for nonblocking operation

[James Bottomley]

On Fri, 2018-08-10 at 11:21 -0700, Tadeusz Struk wrote:
> and the feedback I got from Jason was:
> 
> "I wonder if it is worth creating this when the first file is
> opened.. Lots of systems have TPMs but few use the userspace.."
> 
> so I changed this to allocate the WQ on first open. I think it makes
> sense, but I leave it to you to decide.

If the reason is to not create a wq unless it's needed, shouldn't the
condition actually be first open with flag O_NONBLOCK?

James

Re: [PATCH v3 1/2] RISC-V: Define sys_riscv_flush_icache when SMP=n

[Guenter Roeck]

On Fri, Aug 10, 2018 at 11:27:37AM -0700, Palmer Dabbelt wrote:
> On Fri, 10 Aug 2018 01:38:04 PDT (-0700), Christoph Hellwig wrote:
> >On Thu, Aug 09, 2018 at 03:19:51PM -0700, Palmer Dabbelt wrote:
> >>This would be necessary to make non-SMP builds work, but there is
> >>another error in the implementation of our syscall linkage that actually
> >>just causes sys_riscv_flush_icache to never build.  I've build tested
> >>this on allnoconfig and allnoconfig+SMP=y, as well as defconfig like
> >>normal.
> >
> >Would't it make sense to use COND_SYSCALL to stub out the syscall
> >for !SMP builds?
> 
> I'm not sure.  We can implement the syscall fine in !SMP, it's just that the
> vDSO is expected to always eat these calls because in non-SMP mode you can
> do a global fence.i by just doing a local fence.i (there's only one hart).
> 
> The original rationale behind not having the syscall in non-SMP mode was to
> limit the user ABI, but on looking again that seems like it's just a bit of
> extra complexity that doesn't help anything.  It's already been demonstrated

Doesn't this mean that some userspace code will only run if the kernel was
compiled for SMP ? I always thought that was unacceptable.

Guenter

> that nothing is checking the error because it's been silently slipping past
> userspace for six months, so the extra complexity seems like it'll just
> cause someone else to have to chase the bug in the future.
> 
> But I'm really OK either way.  Is there a precedent for what to do here?

Re: [PATCH v3 1/5] staging: rtl8188eu: use is_multicast_ether_addr in rtw_security.c

[Dan Carpenter]

On Fri, Aug 10, 2018 at 08:21:23PM +0200, Michael Straube wrote:
> On 08/10/18 13:31, Dan Carpenter wrote:
> > No no...  I only gave it a Reviewed-by tag because I didn't want you to
> > resend again...  :P
> 
> Ah, sorry. So I shouldn't have added the tag?
> Should I remove it again? I guess not..
> How are those tags (reviewed, acked, etc.) handled normaly?
> I'm a bit confused now. ;)

Greg adds it.

regards,
dan carpenter

Re: [PATCH RFC 1/7] perf/core, x86: Add PERF_SAMPLE_PAGE_SIZE

[Stephane Eranian]

On Fri, Aug 10, 2018 at 6:37 AM  wrote:
>
> From: Kan Liang 
>
> Current perf can report both virtual address and physical address, but
> it doesn't report page size. Users have no idea how large the utilized
> page is. They cannot promote/demote large pages to optimize memory use.
>
> Add a new sample type for page size.
>
> Current perf already has a facility to collect data virtual address.
> A function, to retrieve page size by full page-table walk of a given
> virtual address, is introduced for x86. Other architectures can
> implement their own functions later separately.
> The function must be IRQ-safe. For x86, disabling IRQs over the walk is
> sufficient to prevent any tear down of the page tables.
>
> The new sample type requires collecting the virtual address. The
> virtual address will not be output unless SAMPLE_ADDR is applied.
>
I welcome this feature, been wanting it for some time now. There is
simply not enough support in /proc/PID/maps or smaps to get this
information. This is important to improve code and data layouts.

I would like to see the following changes to your proposal:
   - call it PERF_SAMPLE_DATA_PAGE_SIZE

That would allow two things:
   1 - not tied to PERF_SAMPLE_ADDR
   2 - Allow PERF_SAMPLE_CODE_PAGE_SIZE to be added

In some measurements, you may just care about the distribution of accesses
across page sizes. No need to use double the buffer space to save the address
you will not use.

Layout is important for code as well, in fact, that's what most people
want first.
Having a CODE_PAGE_SIZE is therefore useful. I am happy adding it on top on your
proposal. Note that PERF_SAMPLE_CODE_PAGE_SIZE would not have to be tied
to PEBS unlike DATA_PAGE_SIZE.

Thanks.

> Although only a few bits are needed to indicate the page size, a u64
> type is still claimed for page_size. Because struct perf_sample_data
> requires cacheline_aligned.
>
> Signed-off-by: Kan Liang 
> ---
>  arch/x86/events/core.c  | 25 +
>  arch/x86/events/intel/ds.c  |  2 +-
>  arch/x86/events/perf_event.h|  2 +-
>  include/linux/perf_event.h  |  1 +
>  include/uapi/linux/perf_event.h | 13 -
>  kernel/events/core.c| 15 +++
>  6 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 5f4829f..719e527 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2573,3 +2573,28 @@ void perf_get_x86_pmu_capability(struct 
> x86_pmu_capability *cap)
> cap->events_mask_len= x86_pmu.events_mask_len;
>  }
>  EXPORT_SYMBOL_GPL(perf_get_x86_pmu_capability);
> +
> +u64 perf_get_page_size(u64 virt)
> +{
> +   unsigned long flags;
> +   unsigned int level;
> +   pte_t *pte;
> +
> +   if (!virt)
> +   return 0;
> +
> +   /*
> +* Interrupts are disabled, so it prevents any tear down
> +* of the page tables.
> +* See the comment near struct mmu_table_batch.
> +*/
> +   local_irq_save(flags);
> +   if (virt >= TASK_SIZE)
> +   pte = lookup_address(virt, );
> +   else
> +   pte = lookup_address_in_pgd(pgd_offset(current->mm, virt),
> +   virt, );
> +   local_irq_restore(flags);
> +
> +   return (u64)level;
> +}
> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index b7b01d7..a3e56c7 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -1274,7 +1274,7 @@ static void setup_pebs_sample_data(struct perf_event 
> *event,
> }
>
>
> -   if ((sample_type & (PERF_SAMPLE_ADDR | PERF_SAMPLE_PHYS_ADDR)) &&
> +   if ((sample_type & (PERF_SAMPLE_ADDR | PERF_SAMPLE_PHYS_ADDR | 
> PERF_SAMPLE_PAGE_SIZE)) &&
> x86_pmu.intel_cap.pebs_format >= 1)
> data->addr = pebs->dla;
>
> diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
> index 1562863..affcd26 100644
> --- a/arch/x86/events/perf_event.h
> +++ b/arch/x86/events/perf_event.h
> @@ -94,7 +94,7 @@ struct amd_nb {
> PERF_SAMPLE_DATA_SRC | PERF_SAMPLE_IDENTIFIER | \
> PERF_SAMPLE_TRANSACTION | PERF_SAMPLE_PHYS_ADDR | \
> PERF_SAMPLE_REGS_INTR | PERF_SAMPLE_REGS_USER | \
> -   PERF_SAMPLE_PERIOD)
> +   PERF_SAMPLE_PERIOD | PERF_SAMPLE_PAGE_SIZE)
>
>  #define PEBS_REGS \
> (PERF_REG_X86_AX | \
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 53c500f..9d13745 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -937,6 +937,7 @@ struct perf_sample_data {
> u64 stack_user_size;
>
> u64 phys_addr;
> +   u64 page_size;
>  } cacheline_aligned;
>
>  /* default value for data source */
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 

[Regression] libata: sata_down_spd_limit should return if driver has not recorded sstatus speed

[Joseph Salisbury]

Hi David,

A kernel bug report was opened against Ubuntu [0].  This bug is a
regression introduced in v4.15-rc4.  The following commit was identified
as the cause of the regression:

    2dc0b46b5ea3 ("libata: sata_down_spd_limit should return if
driver has not recorded sstatus speed")

I was hoping to get your feedback, since you are the patch author.  Do
you think gathering any additional data will help diagnose this issue,
or would it be best to submit a revert request?


Thanks,

Joe

http://pad.lv/1783906

Re: [PATCH 1/3] pinctrl: madera: Set is_generic

[Linus Walleij]

On Tue, Aug 7, 2018 at 11:32 AM Richard Fitzgerald
 wrote:

> We are using the generic pin configuration interface so
> we can set is_generic.
>
> Signed-off-by: Richard Fitzgerald 

Acked-by: Linus Walleij 
For these patches.

This is not yet in my tree, but I can apply this and the others
after -rc1 (probably the easiest).

Yours,
Linus Walleij

[PATCH 1/3] arm64: dts: qcom: sdm845: Add USB-related nodes

[Douglas Anderson]

From: Manu Gautam 

This adds nodes for USB and related PHYs.

Signed-off-by: Manu Gautam 
[dianders: reworked quite a bit]
Signed-off-by: Douglas Anderson 
---

Changes in v2:
- Use "0x784000" for qfprom rather than "0x78" as per docs.
- Add calibration for 2nd USB port too

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 196 +++
 1 file changed, 196 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index ae57c065780c..f13d8c2fb4a5 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -249,6 +250,23 @@
#power-domain-cells = <1>;
};
 
+   qfprom@784000 {
+   compatible = "qcom,qfprom";
+   reg = <0x78 0x8ff>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   qusb2p_hstx_trim: hstx-trim-primary@1eb {
+   reg = <0x1eb 0x1>;
+   bits = <1 4>;
+   };
+
+   qusb2s_hstx_trim: hstx-trim-secondary@1eb {
+   reg = <0x1eb 0x2>;
+   bits = <6 4>;
+   };
+   };
+
qupv3_id_0: geniqup@8c {
compatible = "qcom,geni-se-qup";
reg = <0x8c 0x6000>;
@@ -962,6 +980,184 @@
};
};
 
+   usb_1_hsphy: phy@88e2000 {
+   compatible = "qcom,sdm845-qusb2-phy";
+   reg = <0x88e2000 0x400>;
+   status = "disabled";
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+< RPMH_CXO_CLK>;
+   clock-names = "cfg_ahb", "ref";
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+
+   nvmem-cells = <_hstx_trim>;
+   };
+
+   usb_2_hsphy: phy@88e3000 {
+   compatible = "qcom,sdm845-qusb2-phy";
+   reg = <0x88e3000 0x400>;
+   status = "disabled";
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+< RPMH_CXO_CLK>;
+   clock-names = "cfg_ahb", "ref";
+
+   resets = < GCC_QUSB2PHY_SEC_BCR>;
+
+   nvmem-cells = <_hstx_trim>;
+   };
+
+   usb_1_qmpphy: phy@88e9000 {
+   compatible = "qcom,sdm845-qmp-usb3-phy";
+   reg = <0x88e9000 0x18c>,
+ <0x88e8000 0x10>;
+   reg-names = "reg-base", "dp_com";
+   status = "disabled";
+   #clock-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   clocks = < GCC_USB3_PRIM_PHY_AUX_CLK>,
+< GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+< GCC_USB3_PRIM_CLKREF_CLK>,
+< GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref", "com_aux";
+
+   resets = < GCC_USB3_DP_PHY_PRIM_BCR>,
+< GCC_USB3_PHY_PRIM_BCR>;
+   reset-names = "phy", "common";
+
+   usb_1_ssphy: lane@88e9200 {
+   reg = <0x88e9200 0x128>,
+ <0x88e9400 0x200>,
+ <0x88e9c00 0x218>,
+ <0x88e9a00 0x100>;
+   #phy-cells = <0>;
+   clocks = < GCC_USB3_PRIM_PHY_PIPE_CLK>;
+   clock-names = "pipe0";
+   clock-output-names = "usb3_phy_pipe_clk_src";
+   };
+   };
+
+   usb_2_qmpphy: phy@88eb000 {
+   compatible = "qcom,sdm845-qmp-usb3-uni-phy";
+   reg = <0x88eb000 0x18c>;
+   status = "disabled";
+   #clock-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   clocks = < GCC_USB3_SEC_PHY_AUX_CLK>,
+< GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+< GCC_USB3_SEC_CLKREF_CLK>,
+< GCC_USB3_SEC_PHY_COM_AUX_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref", "com_aux";
+

[PATCH 2/3] arm64: dts: qcom: sdm845-mtp: Add RPMh VRM/XOB regulators

[Douglas Anderson]

Add regulator devices for PMIC regulators managed via VRM and XOB
RPMh accelerators.

A few notes here:
- Regulators are added directly to the board file.  While it's true
  that this will mean a bunch of copy/pasting for other boards that
  are very similar to MTP, this is probably the right call since
  boards could make changes to the way these regulators are hooked up
  and trying to find a way to avoid duplication will result in some
  confusing node overrides.
- Regulators are always given labels based on the schematic.  If there
  is more than one logical name on the schematic for the same rail the
  all of these secondary names are also listed and should be referred
  to as appropriate.
- Regulators all default to HPM mode with the assumption that if a
  rail is being provided to a driver that doesn't specify the needed
  current that we'll at least be correct.

NOTE: This patch is loosely based on one originally shared to me by
David Collins.

Signed-off-by: Douglas Anderson 
---

Changes in v2:
- LDO14 initial mode is LPM and shouldn't be always on (Vivek G)
- LDO25 should have min voltage of 3.3V

 arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 445 
 1 file changed, 445 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 13b50dff440f..839ef9125bf4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -7,6 +7,7 @@
 
 /dts-v1/;
 
+#include 
 #include "sdm845.dtsi"
 
 / {
@@ -20,6 +21,450 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   vph_pwr: vph-pwr-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vph_pwr";
+   regulator-min-microvolt = <370>;
+   regulator-max-microvolt = <370>;
+   };
+
+   /*
+* Apparently RPMh does not provide support for PM8998 S4 because it
+* is always-on; model it as a fixed regulator.
+*/
+   vreg_s4a_1p8: pm8998-smps4 {
+   compatible = "regulator-fixed";
+   regulator-name = "vreg_s4a_1p8";
+
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+_rsc {
+   pm8998-rpmh-regulators {
+   compatible = "qcom,pm8998-rpmh-regulators";
+   qcom,pmic-id = "a";
+
+   vdd-s1-supply = <_pwr>;
+   vdd-s2-supply = <_pwr>;
+   vdd-s3-supply = <_pwr>;
+   vdd-s4-supply = <_pwr>;
+   vdd-s5-supply = <_pwr>;
+   vdd-s6-supply = <_pwr>;
+   vdd-s7-supply = <_pwr>;
+   vdd-s8-supply = <_pwr>;
+   vdd-s9-supply = <_pwr>;
+   vdd-s10-supply = <_pwr>;
+   vdd-s11-supply = <_pwr>;
+   vdd-s12-supply = <_pwr>;
+   vdd-s13-supply = <_pwr>;
+   vdd-l1-l27-supply = <_s7a_1p025>;
+   vdd-l2-l8-l17-supply = <_s3a_1p35>;
+   vdd-l3-l11-supply = <_s7a_1p025>;
+   vdd-l4-l5-supply = <_s7a_1p025>;
+   vdd-l6-supply = <_pwr>;
+   vdd-l7-l12-l14-l15-supply = <_s5a_2p04>;
+   vdd-l9-supply = <_bob>;
+   vdd-l10-l23-l25-supply = <_bob>;
+   vdd-l13-l19-l21-supply = <_bob>;
+   vdd-l16-l28-supply = <_bob>;
+   vdd-l18-l22-supply = <_bob>;
+   vdd-l20-l24-supply = <_bob>;
+   vdd-l26-supply = <_s3a_1p35>;
+   vin-lvs-1-2-supply = <_s4a_1p8>;
+
+   vreg_s2a_1p125: smps2 {
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   };
+
+   vreg_s3a_1p35: smps3 {
+   regulator-min-microvolt = <1352000>;
+   regulator-max-microvolt = <1352000>;
+   };
+
+   vreg_s5a_2p04: smps5 {
+   regulator-min-microvolt = <1904000>;
+   regulator-max-microvolt = <204>;
+   };
+
+   vreg_s7a_1p025: smps7 {
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <1028000>;
+   };
+
+   vdd_qusb_hs0:
+   vdda_hp_pcie_core:
+   vdda_mipi_csi0_0p9:
+   vdda_mipi_csi1_0p9:
+   vdda_mipi_csi2_0p9:
+   vdda_mipi_dsi0_pll:
+   vdda_mipi_dsi1_pll:
+   vdda_qlink_lv:
+   vdda_qlink_lv_ck:
+   vdda_qrefs_0p875:
+   vdda_pcie_core:
+   vdda_pll_cc_ebi01:
+   vdda_pll_cc_ebi23:
+   vdda_sp_sensor:
+   vdda_ufs1_core:
+   vdda_ufs2_core:
+   

[PATCH v1] dd: Invoke one probe retry cycle after some initcall levels

[Rishabh Bhatnagar]

Drivers that are registered at an initcall level may have to
wait until late_init before the probe deferral mechanism can
retry their probe functions. It is possible that their
dependencies were resolved much earlier, in some cases even
before the next initcall level. Invoke one probe retry cycle
at every _sync initcall level after subsys initcall, allowing
these drivers to be probed earlier.

Signed-off-by: Vikram Mulukutla 
Signed-off-by: Rishabh Bhatnagar 
---

To give an example many Qualcomm drivers are dependent on the regulator and 
bus driver. Both the regulator and bus driver are probed in the 
subsys_initcall level. Now the probe of bus driver requires regulator to be 
working. If the probe of bus driver happens before regulator, then bus 
driver's probe will be deferred and all other device's probes which depend 
on bus driver will also be deferred. 
The impact of this problem is reduced if we have this patch.

Changes since v0:
* Remove arch_initcall_sync(deferred_probe_initcall) from patch. This is not
  really needed as none of the devices are re-probed in arch_initcall_sync
  level.

 drivers/base/dd.c | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 1435d72..9aa41aa 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -224,23 +224,43 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
 }
 
+static void enable_trigger_defer_cycle(void)
+{
+   driver_deferred_probe_enable = true;
+   driver_deferred_probe_trigger();
+   /*
+* Sort as many dependencies as possible before the next initcall
+* level
+*/
+   flush_work(_probe_work);
+}
+
 /**
  * deferred_probe_initcall() - Enable probing of deferred devices
  *
  * We don't want to get in the way when the bulk of drivers are getting probed.
  * Instead, this initcall makes sure that deferred probing is delayed until
- * late_initcall time.
+ * all the registered initcall functions at a particular level are completed.
+ * This function is invoked at every *_initcall_sync level.
  */
 static int deferred_probe_initcall(void)
 {
-   driver_deferred_probe_enable = true;
-   driver_deferred_probe_trigger();
-   /* Sort as many dependencies as possible before exiting initcalls */
-   flush_work(_probe_work);
+   enable_trigger_defer_cycle();
+   driver_deferred_probe_enable = false;
+   return 0;
+}
+subsys_initcall_sync(deferred_probe_initcall);
+fs_initcall_sync(deferred_probe_initcall);
+device_initcall_sync(deferred_probe_initcall);
+
+static int deferred_probe_enable_fn(void)
+{
+   /* Enable deferred probing for all time */
+   enable_trigger_defer_cycle();
initcalls_done = true;
return 0;
 }
-late_initcall(deferred_probe_initcall);
+late_initcall(deferred_probe_enable_fn);
 
 /**
  * device_is_bound() - Check if device is bound to a driver
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 3/3] arm64: dts: qcom: sdm845-mtp: Add nodes for USB

[Douglas Anderson]

Set the various nodes to "okay" and hook up the regulators.

NOTE: For now the main USB port (the one that goes out the Type C
connector) is forced to host.  Eventually someone will need to get the
Type C detection hooked up and get this all integrated with the
PMI8998 PMIC.  The reason for forcing to "host" in the meantime is
that this will leave us with one "host" and one "peripheral" port.

In order for host mode this to work, we assume that the bootloader
left things configured enough for us.  Apparently the magic for that
is is to do these writes on pmi8998:
- pm_comm_write_byte(2, 0x1153, 0x2C, 0);
- pm_comm_write_byte(2, 0x1152, 0x07, 0);
- pm_comm_write_byte(2, 0x1140, 0x00, 0);
- pm_comm_write_byte(2, 0x1140, 0x01, 0);

Signed-off-by: Douglas Anderson 
---

Changes in v2: None

 arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 61 +
 1 file changed, 61 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 839ef9125bf4..eb9400bf2cbf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -480,6 +480,67 @@
status = "okay";
 };
 
+_1 {
+   status = "okay";
+};
+
+_1_dwc3 {
+   /* Until we have Type C hooked up we'll force this as host. */
+   dr_mode = "host";
+};
+
+_1_hsphy {
+   status = "okay";
+
+   vdd-supply = <_usb1_ss_core>;
+   vdda-pll-supply = <_qusb_hs0_1p8>;
+   vdda-phy-dpdm-supply = <_qusb_hs0_3p1>;
+
+   qcom,imp-res-offset-value = <8>;
+   qcom,hstx-trim-value = ;
+   qcom,preemphasis-level = ;
+   qcom,preemphasis-width = ;
+};
+
+_1_qmpphy {
+   status = "okay";
+
+   vdda-phy-supply = <_usb1_ss_1p2>;
+   vdda-pll-supply = <_usb1_ss_core>;
+};
+
+_2 {
+   status = "okay";
+};
+
+_2_dwc3 {
+   /*
+* Though the USB block on SDM845 can support host, there's no vbus
+* signal for this port on MTP.  Thus (unless you have a non-compliant
+* hub that works without vbus) the only sensible thing is to force
+* peripheral mode.
+*/
+   dr_mode = "peripheral";
+};
+
+_2_hsphy {
+   status = "okay";
+
+   vdd-supply = <_usb2_ss_core>;
+   vdda-pll-supply = <_qusb_hs0_1p8>;
+   vdda-phy-dpdm-supply = <_qusb_hs0_3p1>;
+
+   qcom,imp-res-offset-value = <8>;
+   qcom,hstx-trim-value = ;
+};
+
+_2_qmpphy {
+   status = "okay";
+
+   vdda-phy-supply = <_usb2_ss_1p2>;
+   vdda-pll-supply = <_usb2_ss_core>;
+};
+
 /* PINCTRL - additions to nodes defined in sdm845.dtsi */
 
 _i2c10_default {
-- 
2.18.0.597.ga71716f1ad-goog

[PATCH] perf tools: arm-spe: Fix uninitialized record error variable

[Kim Phillips]

The auxtrace init variable 'err' was not being initialized, leading
perf to abort early in an SPE record command when there was no explicit
error, rather only based whatever memory contents were on the stack.
Initialize it explicitly on getting an SPE successfully, the same way
cs-etm does.

Signed-off-by: Kim Phillips 
---
Hi Arnaldo, please apply to perf/urgent / stable series if at all
possible.  Thank you.

 tools/perf/arch/arm64/util/arm-spe.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/arch/arm64/util/arm-spe.c 
b/tools/perf/arch/arm64/util/arm-spe.c
index 1120e39c1b00..5ccfce87e693 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -194,6 +194,7 @@ struct auxtrace_record *arm_spe_recording_init(int *err,
sper->itr.read_finish = arm_spe_read_finish;
sper->itr.alignment = 0;
 
+   *err = 0;
return >itr;
 }
 
-- 
2.17.1

Re: [PATCH v1 3/4] drivers: edac: Add EDAC driver support for QCOM SoCs

[vnkgutta]

On 2018-08-10 10:23, Evan Green wrote:

On Wed, Aug 1, 2018 at 1:34 PM Venkata Narendra Kumar Gutta
 wrote:


From: Channagoud Kadabi 

Add error reporting driver for SBEs and DBEs. As of now, this driver
supports erp for Last Level Cache Controller (LLCC). This driver takes
care of dumping registers and adding config options to enable and
disable panic when the errors happen in cache.

Co-developed-by: Venkata Narendra Kumar Gutta 


Signed-off-by: Venkata Narendra Kumar Gutta 
Signed-off-by: Channagoud Kadabi 
---
 MAINTAINERS  |   7 +
 drivers/edac/Kconfig |  28 +++
 drivers/edac/Makefile|   1 +
 drivers/edac/qcom_edac.c | 507 
+++

 4 files changed, 543 insertions(+)
 create mode 100644 drivers/edac/qcom_edac.c


...

diff --git a/drivers/edac/qcom_edac.c b/drivers/edac/qcom_edac.c
new file mode 100644
index 000..cf3e2b0
--- /dev/null
+++ b/drivers/edac/qcom_edac.c
@@ -0,0 +1,507 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 


Please alphabetize these includes, and remove any unneeded ones.
Ok, I'll update it in the next version. I didn't know that it's 
mandatory to have in alphabetic order.
Is it recommended or a strict rule that we have includes in alphabetize 
order?



+#include "edac_mc.h"
+#include "edac_device.h"
+
+#ifdef CONFIG_EDAC_QCOM_LLCC_PANIC_ON_UE
+#define LLCC_ERP_PANIC_ON_UE1
+#else
+#define LLCC_ERP_PANIC_ON_UE0
+#endif
+
+#define EDAC_LLCC   "qcom_llcc"
+
+#define TRP_SYN_REG_CNT 6
+
+#define DRP_SYN_REG_CNT 8
+
+#define LLCC_COMMON_STATUS0 0x0003000C
+#define LLCC_LB_CNT_MASKGENMASK(31, 28)
+#define LLCC_LB_CNT_SHIFT   28
+
+/* single & Double Bit syndrome register offsets */
+#define TRP_ECC_SB_ERR_SYN0 0x0002304C
+#define TRP_ECC_DB_ERR_SYN0 0x00020370
+#define DRP_ECC_SB_ERR_SYN0 0x0004204C
+#define DRP_ECC_DB_ERR_SYN0 0x00042070
+
+/* Error register offsets */
+#define TRP_ECC_ERROR_STATUS1   0x00020348
+#define TRP_ECC_ERROR_STATUS0   0x00020344
+#define DRP_ECC_ERROR_STATUS1   0x00042048
+#define DRP_ECC_ERROR_STATUS0   0x00042044
+
+/* TRP, DRP interrupt register offsets */
+#define DRP_INTERRUPT_STATUS0x00041000
+#define TRP_INTERRUPT_0_STATUS  0x00020480
+#define DRP_INTERRUPT_CLEAR 0x00041008
+#define DRP_ECC_ERROR_CNTR_CLEAR0x00040004
+#define TRP_INTERRUPT_0_CLEAR   0x00020484
+#define TRP_ECC_ERROR_CNTR_CLEAR0x00020440
+
+/* Mask and shift macros */
+#define ECC_DB_ERR_COUNT_MASK   GENMASK(4, 0)
+#define ECC_DB_ERR_WAYS_MASKGENMASK(31, 16)
+#define ECC_DB_ERR_WAYS_SHIFT   BIT(4)
+
+#define ECC_SB_ERR_COUNT_MASK   GENMASK(23, 16)
+#define ECC_SB_ERR_COUNT_SHIFT  BIT(4)
+#define ECC_SB_ERR_WAYS_MASKGENMASK(15, 0)
+
+#define SB_ECC_ERRORBIT(0)
+#define DB_ECC_ERRORBIT(1)
+
+#define DRP_TRP_INT_CLEAR   GENMASK(1, 0)
+#define DRP_TRP_CNT_CLEAR   GENMASK(1, 0)
+
+/* Config registers offsets*/
+#define DRP_ECC_ERROR_CFG   0x0004
+
+/* TRP, DRP interrupt register offsets */
+#define CMN_INTERRUPT_0_ENABLE  0x0003001C
+#define CMN_INTERRUPT_2_ENABLE  0x0003003C
+#define TRP_INTERRUPT_0_ENABLE  0x00020488
+#define DRP_INTERRUPT_ENABLE0x0004100C
+
+#define SB_ERROR_THRESHOLD  0x1
+#define SB_ERROR_THRESHOLD_SHIFT24
+#define SB_DB_TRP_INTERRUPT_ENABLE  0x3
+#define TRP0_INTERRUPT_ENABLE   0x1
+#define DRP0_INTERRUPT_ENABLE   BIT(6)
+#define SB_DB_DRP_INTERRUPT_ENABLE  0x3
+
+
+enum {
+   LLCC_DRAM_CE = 0,
+   LLCC_DRAM_UE,
+   LLCC_TRAM_CE,
+   LLCC_TRAM_UE,
+};
+
+struct errors_edac {
+   const char *msg;
+   void (*func)(struct edac_device_ctl_info *edev_ctl,
+   int inst_nr, int block_nr, const char 
*msg);

+};
+
+static const struct errors_edac errors[] = {
+   {"LLCC Data RAM correctable Error", edac_device_handle_ce},
+   {"LLCC Data RAM uncorrectable Error", edac_device_handle_ue},
+   {"LLCC Tag RAM correctable Error", edac_device_handle_ce},
+   {"LLCC Tag RAM uncorrectable Error", edac_device_handle_ue},
+};
+
+static int qcom_llcc_core_setup(struct regmap *llcc_bcast_regmap)
+{
+   u32 sb_err_threshold;
+   int ret;
+
+   /* Enable TRP in instance 2 of common interrupt enable 
register */
+   ret = regmap_update_bits(llcc_bcast_regmap, 
CMN_INTERRUPT_2_ENABLE,

+TRP0_INTERRUPT_ENABLE,
+TRP0_INTERRUPT_ENABLE);
+   if (ret)
+

Re: [PATCH v4 1/6] iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer

[Marcus Folkesson]

Hi Stefan,


On Mon, Aug 06, 2018 at 03:04:42PM +0300, Stefan Popa wrote:
> This patch adds basic support for Analog Devices ADXL372 SPI-Bus
> Three-Axis Digital Accelerometer.
> 
> The device is probed and configured the with some initial default
> values. With this basic driver, it is possible to read raw acceleration
> data.
> 
> Datasheet:
> http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL372.pdf
> 
> Signed-off-by: Stefan Popa 
> ---
>  MAINTAINERS |   6 +
>  drivers/iio/accel/Kconfig   |  11 +
>  drivers/iio/accel/Makefile  |   1 +
>  drivers/iio/accel/adxl372.c | 525 
> 
>  4 files changed, 543 insertions(+)
>  create mode 100644 drivers/iio/accel/adxl372.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 60b1028..2ba47bb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -543,6 +543,12 @@ W:   
> http://ez.analog.com/community/linux-device-drivers
>  S:   Supported
>  F:   drivers/input/misc/adxl34x.c
>  
> +ADXL372 THREE-AXIS DIGITAL ACCELEROMETER DRIVER
> +M:   Stefan Popa 
> +W:   http://ez.analog.com/community/linux-device-drivers
> +S:   Supported
> +F:   drivers/iio/accel/adxl372.c
> +
>  AF9013 MEDIA DRIVER
>  M:   Antti Palosaari 
>  L:   linux-me...@vger.kernel.org
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 62ae7e5..1b496ef 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -60,6 +60,17 @@ config ADXL345_SPI
> will be called adxl345_spi and you will also get adxl345_core
> for the core module.
>  
> +config ADXL372
> + tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver"
> + depends on SPI
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> +   Say yes here to add support for the Analog Devices ADXL372 triaxial
> +   acceleration sensor.
> +   To compile this driver as a module, choose M here: the
> +   module will be called adxl372.
> +
>  config BMA180
>   tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
>   depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 636d4d1..5758ffc 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_ADIS16209) += adis16209.o
>  obj-$(CONFIG_ADXL345) += adxl345_core.o
>  obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
>  obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> +obj-$(CONFIG_ADXL372) += adxl372.o
>  obj-$(CONFIG_BMA180) += bma180.o
>  obj-$(CONFIG_BMA220) += bma220_spi.o
>  obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> new file mode 100644
> index 000..db9ecd2
> --- /dev/null
> +++ b/drivers/iio/accel/adxl372.c
> @@ -0,0 +1,525 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * ADXL372 3-Axis Digital Accelerometer SPI driver
> + *
> + * Copyright 2018 Analog Devices Inc.
> + */

Please make the SPDX-identifier and MODULE_LICENCE match here as well.

Either 
SPDX-License-Identifier: GPL-2.0+
MODULE_LICENSE("GPL")

or

SPDX-License-Identifier: GPL-2.0
MODULE_LICENSE("GPL v2")

Thanks!
Marcus Folkesson


signature.asc
Description: PGP signature

[PATCH] EDAC, amd64: Add Family 17h Model 11h support.

[Michael Jin]

Add support for ECC error decoding for F17h M11h (Great Horned Owl) processors.

Signed-off-by: Michael Jin 
---
 drivers/edac/amd64_edac.c | 14 ++
 drivers/edac/amd64_edac.h |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 18aeabb1d5ee..de077c1f5ae3 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2200,6 +2200,15 @@ static struct amd64_family_type family_types[] = {
.dbam_to_cs = f17_base_addr_to_cs_size,
}
},
+   [F17_M11H_CPUS] = {
+   .ctl_name = "F17h_M11h",
+   .f0_id = PCI_DEVICE_ID_AMD_17H_M11H_DF_F0,
+   .f6_id = PCI_DEVICE_ID_AMD_17H_M11H_DF_F6,
+   .ops = {
+   .early_channel_count= f17_early_channel_count,
+   .dbam_to_cs = f17_base_addr_to_cs_size,
+   }
+   },
 };
 
 /*
@@ -3188,6 +3197,11 @@ static struct amd64_family_type *per_family_init(struct 
amd64_pvt *pvt)
break;
 
case 0x17:
+   if (pvt->model == 0x11) {
+   fam_type = _types[F17_M11H_CPUS];
+   pvt->ops = _types[F17_M11H_CPUS].ops;
+   break;
+   }
fam_type= _types[F17_CPUS];
pvt->ops= _types[F17_CPUS].ops;
break;
diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
index 1d4b74e9a037..e50226cd53c6 100644
--- a/drivers/edac/amd64_edac.h
+++ b/drivers/edac/amd64_edac.h
@@ -115,6 +115,8 @@
 #define PCI_DEVICE_ID_AMD_16H_M30H_NB_F2 0x1582
 #define PCI_DEVICE_ID_AMD_17H_DF_F00x1460
 #define PCI_DEVICE_ID_AMD_17H_DF_F60x1466
+#define PCI_DEVICE_ID_AMD_17H_M11H_DF_F0 0x15e8
+#define PCI_DEVICE_ID_AMD_17H_M11H_DF_F6 0x15ee
 
 /*
  * Function 1 - Address Map
@@ -281,6 +283,7 @@ enum amd_families {
F16_CPUS,
F16_M30H_CPUS,
F17_CPUS,
+   F17_M11H_CPUS,
NUM_FAMILIES,
 };
 
-- 
2.14.3 (Apple Git-98)

Re: [PATCH 03/11] dt-bindings: interrupt-controller: RISC-V PLIC documentation

[Palmer Dabbelt]

On Fri, 10 Aug 2018 09:57:03 PDT (-0700), robh...@kernel.org wrote:

On Thu, Aug 9, 2018 at 12:29 AM Palmer Dabbelt  wrote:


On Wed, 08 Aug 2018 16:32:07 PDT (-0700), robh...@kernel.org wrote:
> On Wed, Aug 8, 2018 at 1:38 PM Palmer Dabbelt  wrote:
>>
>> On Wed, 08 Aug 2018 07:16:14 PDT (-0700), robh...@kernel.org wrote:
>> > On Tue, Aug 7, 2018 at 8:17 PM Palmer Dabbelt  wrote:
>> >>
>> >> On Mon, 06 Aug 2018 13:59:48 PDT (-0700), robh...@kernel.org wrote:
>> >> > On Thu, Aug 2, 2018 at 4:08 PM Atish Patra  wrote:
>> >> >>
>> >> >> On 8/2/18 4:50 AM, Christoph Hellwig wrote:
>> >> >> > From: Palmer Dabbelt 
>> >> >> >
>> >> >> > This patch adds documentation for the platform-level interrupt
>> >> >> > controller (PLIC) found in all RISC-V systems.  This interrupt
>> >> >> > controller routes interrupts from all the devices in the system to 
each
>> >> >> > hart-local interrupt controller.
>> >> >> >
>> >> >> > Note: the DTS bindings for the PLIC aren't set in stone yet, as we 
might
>> >> >> > want to change how we're specifying holes in the hart list.
>> >> >> >
>> >> >> > Signed-off-by: Palmer Dabbelt 
>> >> >> > [hch: various fixes and updates]
>> >> >> > Signed-off-by: Christoph Hellwig 
>> >> >> > ---
>> >> >> >   .../interrupt-controller/sifive,plic0.txt | 57 
+++
>> >> >> >   1 file changed, 57 insertions(+)
>> >> >> >   create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
>> >> >> >
>> >> >> > diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt 
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
>> >> >> > new file mode 100644
>> >> >> > index ..c756cd208a93
>> >> >> > --- /dev/null
>> >> >> > +++ 
b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic0.txt
>> >> >> > @@ -0,0 +1,57 @@
>> >> >> > +SiFive Platform-Level Interrupt Controller (PLIC)
>> >> >> > +-
>> >> >> > +
>> >> >> > +SiFive SOCs include an implementation of the Platform-Level 
Interrupt Controller
>> >> >> > +(PLIC) high-level specification in the RISC-V Privileged 
Architecture
>> >> >> > +specification.  The PLIC connects all external interrupts in the 
system to all
>> >> >> > +hart contexts in the system, via the external interrupt source in 
each hart.
>> >> >> > +
>> >> >> > +A hart context is a privilege mode in a hardware execution thread.  
For example,
>> >> >> > +in an 4 core system with 2-way SMT, you have 8 harts and probably 
at least two
>> >> >> > +privilege modes per hart; machine mode and supervisor mode.
>> >> >> > +
>> >> >> > +Each interrupt can be enabled on per-context basis. Any context can 
claim
>> >> >> > +a pending enabled interrupt and then release it once it has been 
handled.
>> >> >> > +
>> >> >> > +Each interrupt has a configurable priority. Higher priority 
interrupts are
>> >> >> > +serviced first. Each context can specify a priority threshold. 
Interrupts
>> >> >> > +with priority below this threshold will not cause the PLIC to raise 
its
>> >> >> > +interrupt line leading to the context.
>> >> >> > +
>> >> >> > +While the PLIC supports both edge-triggered and level-triggered 
interrupts,
>> >> >> > +interrupt handlers are oblivious to this distinction and therefore 
it is not
>> >> >> > +specified in the PLIC device-tree binding.
>> >> >> > +
>> >> >> > +While the RISC-V ISA doesn't specify a memory layout for the PLIC, 
the
>> >> >> > +"sifive,plic0" device is a concrete implementation of the PLIC that 
contains a
>> >> >> > +specific memory layout, which is documented in chapter 8 of the 
SiFive U5
>> >> >> > +Coreplex Series Manual 
.
>> >> >> > +
>> >> >> > +Required properties:
>> >> >> > +- compatible : "sifive,plic0"
>> >>
>> >> I think there was a thread bouncing around somewhere where decided to 
pick the
>> >> official name of the compatible string to be "sifive,plic-1.0".  The idea 
here
>> >> is that the PLIC is compatible across all of SiFive's current 
implementations,
>> >> but there's some limitations in the memory map that will probably cause 
us to
>> >> spin a version 2 at some point so we want major version number.  The minor
>> >> number is just in case we find some errata in the PLIC.
>> >
>> > Is 1.0 an actual version number corresponding to an exact, revision
>> > controlled version of the IP or just something you made up? Looks like
>> > the latter to me and I'm not a fan of s/w folks making up version
>> > numbers for h/w. Standard naming convention is ,-
>> > unless you have good reason to deviate (IP for FPGAs where version
>> > numbers are exposed to customers is one example).
>>
>> The hardware versioning scheme calls it "riscv,plic0", which is what we were
>> originally using.  This PLIC isn't actually defined as a RISC-V spec, so we
>> wanted to change it to a "sifive,*" name instead.  Since we were going to
>> change the 

[PATCH] clk: qcom: Add Global Clock controller (GCC) driver for SDM660

[Craig Tatlor]

Add support for the global clock controller found on SDM660
based devices. This should allow most non-multimedia device
drivers to probe and control their clocks.
Based on CAF implementation.

Signed-off-by: Craig Tatlor 
---
 .../devicetree/bindings/clock/qcom,gcc.txt|1 +
 drivers/clk/qcom/Kconfig  |9 +
 drivers/clk/qcom/Makefile |1 +
 drivers/clk/qcom/gcc-sdm660.c | 2479 +
 include/dt-bindings/clock/qcom,gcc-sdm660.h   |  159 ++
 5 files changed, 2649 insertions(+)
 create mode 100644 drivers/clk/qcom/gcc-sdm660.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm660.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 664ea1fd6c76..e498ad2e8db8 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -19,6 +19,7 @@ Required properties :
"qcom,gcc-msm8996"
"qcom,gcc-msm8998"
"qcom,gcc-mdm9615"
+   "qcom,gcc-sdm660"
"qcom,gcc-sdm845"
 
 - reg : shall contain base register location and length
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 9c3480dcc38a..c4bda6d24c1f 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -226,6 +226,15 @@ config MSM_GCC_8998
  Say Y if you want to use peripheral devices such as UART, SPI,
  i2c, USB, UFS, SD/eMMC, PCIe, etc.
 
+config SDM_GCC_660
+   tristate "SDM660 Global Clock Controller"
+   select QCOM_GDSC
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the global clock controller on SDM660 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ i2C, USB, UFS, SDDC, PCIe, etc.
+
 config SDM_GCC_845
tristate "SDM845 Global Clock Controller"
select QCOM_GDSC
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 762c01137c2f..6e37d30d7c02 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_QCOM_A53PLL) += a53-pll.o
 obj-$(CONFIG_QCOM_CLK_APCS_MSM8916) += apcs-msm8916.o
 obj-$(CONFIG_QCOM_CLK_RPM) += clk-rpm.o
 obj-$(CONFIG_QCOM_CLK_SMD_RPM) += clk-smd-rpm.o
+obj-$(CONFIG_SDM_GCC_660) += gcc-sdm660.o
 obj-$(CONFIG_SDM_GCC_845) += gcc-sdm845.o
 obj-$(CONFIG_SDM_VIDEOCC_845) += videocc-sdm845.o
 obj-$(CONFIG_SPMI_PMIC_CLKDIV) += clk-spmi-pmic-div.o
diff --git a/drivers/clk/qcom/gcc-sdm660.c b/drivers/clk/qcom/gcc-sdm660.c
new file mode 100644
index ..bdb445aa4baa
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sdm660.c
@@ -0,0 +1,2479 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2016-2017, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2018, Craig Tatlor.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-alpha-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "reset.h"
+#include "gdsc.h"
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+enum {
+   P_XO,
+   P_SLEEP_CLK,
+   P_GPLL0,
+   P_GPLL1,
+   P_GPLL4,
+   P_GPLL0_EARLY_DIV,
+   P_GPLL1_EARLY_DIV,
+};
+
+static const struct parent_map gcc_parent_map_xo_gpll0_gpll0_early_div[] = {
+   { P_XO, 0 },
+   { P_GPLL0, 1 },
+   { P_GPLL0_EARLY_DIV, 6 },
+};
+
+static const char * const gcc_parent_names_xo_gpll0_gpll0_early_div[] = {
+   "xo",
+   "gpll0",
+   "gpll0_early_div",
+};
+
+static const struct parent_map gcc_parent_map_xo_gpll0[] = {
+   { P_XO, 0 },
+   { P_GPLL0, 1 },
+};
+
+static const char * const gcc_parent_names_xo_gpll0[] = {
+   "xo",
+   "gpll0",
+};
+
+static const struct parent_map 
gcc_parent_map_xo_gpll0_sleep_clk_gpll0_early_div[] = {
+   { P_XO, 0 },
+   { P_GPLL0, 1 },
+   { P_SLEEP_CLK, 5 },
+   { P_GPLL0_EARLY_DIV, 6 },
+};
+
+static const char * const 
gcc_parent_names_xo_gpll0_sleep_clk_gpll0_early_div[] = {
+   "xo",
+   "gpll0",
+   "sleep_clk",
+   "gpll0_early_div",
+};
+
+static const struct parent_map gcc_parent_map_xo_sleep_clk[] = {
+   { P_XO, 0 },
+   { P_SLEEP_CLK, 5 },
+};
+
+static const char * const gcc_parent_names_xo_sleep_clk[] = {
+   "xo",
+   "sleep_clk",
+};
+
+static const struct parent_map gcc_parent_map_xo_gpll4[] = {
+   { P_XO, 0 },
+   { P_GPLL4, 5 },
+};
+
+static const char * const gcc_parent_names_xo_gpll4[] = {
+   "xo",
+   "gpll4",
+};
+
+static const struct parent_map 
gcc_parent_map_xo_gpll0_gpll0_early_div_gpll1_gpll4_gpll1_early_div[] = {
+   { P_XO, 0 },
+   { P_GPLL0, 1 },
+   { P_GPLL0_EARLY_DIV, 3 },
+   { P_GPLL1, 4 },
+   { P_GPLL4, 5 },

Re: [PATCH] pinctrl: samsung: Remove duplicated "wakeup" in printk

[Linus Walleij]

On Mon, Aug 6, 2018 at 6:33 PM Krzysztof Kozlowski  wrote:

> Double "wakeup" appears in printed message.
>
> Signed-off-by: Krzysztof Kozlowski 

Patch applied.

Yours,
Linus Walleij

[PATCH 2/5] vmbus: add driver_override support

[kys]

From: Stephen Hemminger 

Add support for overriding the default driver for a VMBus device
in the same way that it can be done for PCI devices. This patch
adds the /sys/bus/vmbus/devices/.../driver_override file
and the logic for matching.

This is used by driverctl tool to do driver override.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fdriverctl%2Fdriverctldata=02%7C01%7Ckys%40microsoft.com%7C42e803feb2c544ef6ea908d5fd538878%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636693457619960040sdata=kEyYHRIjNZCk%2B37moCSqbrZL426YccNQrsWpENcrZdw%3Dreserved=0

Signed-off-by: Stephen Hemminger 
Signed-off-by: K. Y. Srinivasan 
---
 Documentation/ABI/testing/sysfs-bus-vmbus |  21 
 drivers/hv/vmbus_drv.c| 115 ++
 include/linux/hyperv.h|   1 +
 3 files changed, 118 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-vmbus

diff --git a/Documentation/ABI/testing/sysfs-bus-vmbus 
b/Documentation/ABI/testing/sysfs-bus-vmbus
new file mode 100644
index ..91e6c065973c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-vmbus
@@ -0,0 +1,21 @@
+What:  /sys/bus/vmbus/devices/.../driver_override
+Date:  August 2019
+Contact:   Stephen Hemminger 
+Description:
+   This file allows the driver for a device to be specified which
+   will override standard static and dynamic ID matching.  When
+   specified, only a driver with a name matching the value written
+   to driver_override will have an opportunity to bind to the
+   device.  The override is specified by writing a string to the
+   driver_override file (echo uio_hv_generic > driver_override) and
+   may be cleared with an empty string (echo > driver_override).
+   This returns the device to standard matching rules binding.
+   Writing to driver_override does not automatically unbind the
+   device from its current driver or make any attempt to
+   automatically load the specified driver.  If no driver with a
+   matching name is currently loaded in the kernel, the device
+   will not bind to any driver.  This also allows devices to
+   opt-out of driver binding using a driver_override name such as
+   "none".  Only a single driver may be specified in the override,
+   there is no support for parsing delimiters.
+
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index b1b548a21f91..e6d8fdac6d8b 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -498,6 +498,54 @@ static ssize_t device_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(device);
 
+static ssize_t driver_override_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct hv_device *hv_dev = device_to_hv_device(dev);
+   char *driver_override, *old, *cp;
+
+   /* We need to keep extra room for a newline */
+   if (count >= (PAGE_SIZE - 1))
+   return -EINVAL;
+
+   driver_override = kstrndup(buf, count, GFP_KERNEL);
+   if (!driver_override)
+   return -ENOMEM;
+
+   cp = strchr(driver_override, '\n');
+   if (cp)
+   *cp = '\0';
+
+   device_lock(dev);
+   old = hv_dev->driver_override;
+   if (strlen(driver_override)) {
+   hv_dev->driver_override = driver_override;
+   } else {
+   kfree(driver_override);
+   hv_dev->driver_override = NULL;
+   }
+   device_unlock(dev);
+
+   kfree(old);
+
+   return count;
+}
+
+static ssize_t driver_override_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct hv_device *hv_dev = device_to_hv_device(dev);
+   ssize_t len;
+
+   device_lock(dev);
+   len = snprintf(buf, PAGE_SIZE, "%s\n", hv_dev->driver_override);
+   device_unlock(dev);
+
+   return len;
+}
+static DEVICE_ATTR_RW(driver_override);
+
 /* Set up per device attributes in /sys/bus/vmbus/devices/ */
 static struct attribute *vmbus_dev_attrs[] = {
_attr_id.attr,
@@ -528,6 +576,7 @@ static struct attribute *vmbus_dev_attrs[] = {
_attr_channel_vp_mapping.attr,
_attr_vendor.attr,
_attr_device.attr,
+   _attr_driver_override.attr,
NULL,
 };
 ATTRIBUTE_GROUPS(vmbus_dev);
@@ -563,17 +612,26 @@ static inline bool is_null_guid(const uuid_le *guid)
return true;
 }
 
-/*
- * Return a matching hv_vmbus_device_id pointer.
- * If there is no match, return NULL.
- */
-static const struct hv_vmbus_device_id *hv_vmbus_get_id(struct hv_driver *drv,
-   const uuid_le *guid)
+static const struct hv_vmbus_device_id *

Re: [PATCH v3] checkpatch: DT bindings should be a separate patch

[Joe Perches]

On Fri, 2018-08-10 at 16:50 -0600, Rob Herring wrote:
> Devicetree bindings should be their own patch as documented in
> Documentation/devicetree/bindings/submitting-patches.txt section I.1.
> This is because bindings are logically independent from a driver
> implementation, they have a different maintainer (even though they often
> are applied via the same tree), and it makes for a cleaner history in
> the DT only tree created with git-filter-branch.

Thanks Rob.
Acked-by: Joe Perches 

Re: [PATCH v3 7/7] firmware: coreboot: Request table region for exclusive access

[Stephen Boyd]

Quoting Stephen Boyd (2018-08-09 19:54:27)
> What's with the top posting? ;-)
> 
> Quoting Julius Werner (2018-08-09 16:44:43)
> > Actually, looking at what IO_STRICT_DEVMEM really does, would it
> > really prevent userspace accesses to these areas? Because it seems
> > that it only prevents accesses to areas marked as IORESOURCE_BUSY, and
> > while I can't fully follow how the kernel assigns that, comments
> > suggest that this is only set when "Driver has marked this resource
> > busy".
> 
> Requesting the memory region as is done in this patch marks it as busy.
> 
> > 
> > So after you make the change to the other patch where we immediately
> > unmap the coreboot table again at the end of the probe() function,
> > shouldn't it become available to userspace again even with
> > IO_STRICT_DEVMEM set?
> 
> Yes, if we unmap the region immediately after devices are populated then
> this whole point is moot with the assumption that this code isn't
> running at the same time as the cbmem utility. I've done this already
> and it is working on arm. I still need to build/boot/test on an x86
> platform which I should be able to do tomorrow.
> 

I tried my latest version of the patches (unplubished so far) and those
work on x86 with cbmem. So things look good and we don't need to keep
the mapping around.

general protection fault in finish_task_switch (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:8c8399e0a3fb Add linux-next specific files for 20180806
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c6b8e240
kernel config:  https://syzkaller.appspot.com/x/.config?x=1b6bc1781e49e93e
dashboard link: https://syzkaller.appspot.com/bug?extid=1f56df64bfb3c29dde6f
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1f56df64bfb3c29dd...@syzkaller.appspotmail.com

kasan: CONFIG_KASAN_INLINE enabled
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
 vmwrite_error+0x4c/0x60 arch/x86/kvm/vmx.c:2201
CPU: 0 PID: 9256 Comm: syz-executor2 Not tainted 4.18.0-rc8-next-20180806+  
#32

 __vmcs_writel arch/x86/kvm/vmx.c:2211 [inline]
 vmcs_writel arch/x86/kvm/vmx.c:2251 [inline]
 vmx_vcpu_load+0xcdb/0xfe0 arch/x86/kvm/vmx.c:2917
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:__fire_sched_in_preempt_notifiers kernel/sched/core.c:2481  
[inline]

RIP: 0010:fire_sched_in_preempt_notifiers kernel/sched/core.c:2487 [inline]
RIP: 0010:finish_task_switch+0x538/0x870 kernel/sched/core.c:2679
Code: 89 e1 48 c1 e9 03 42 80 3c 39 00 0f 85 ab 01 00 00 4d 8b 24 24 4d 85  
e4 0f 84 e3 fc ff ff 49 8d 7c 24 10 48 89 f9 48 c1 e9 03 <42> 80 3c 39 00  
74 a5 e8 1c e8 67 00 eb 9e 80 3d 80 e4 31 07 00 0f

RSP: 0018:8801977a7980 EFLAGS: 00010a06
RAX:  RBX: 8801db02ca40 RCX: 1bd5a022
RDX: 0004 RSI: 810edd32 RDI: dead0110
RBP: 8801977a7a68 R08: 88019386a080 R09: fbfff1107d28
R10: fbfff1107d28 R11: 0003 R12: dead0100
 kvm_arch_vcpu_load+0x22b/0x940 arch/x86/kvm/x86.c:3081
R13: 88019549c240 R14:  R15: dc00
FS:  7fd2dc8cf700() GS:8801db00() knlGS:
 kvm_sched_in+0x82/0xa0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3975
CS:  0010 DS:  ES:  CR0: 80050033
 __fire_sched_in_preempt_notifiers kernel/sched/core.c:2481 [inline]
 fire_sched_in_preempt_notifiers kernel/sched/core.c:2487 [inline]
 finish_task_switch+0x50d/0x870 kernel/sched/core.c:2679
CR2: 001b2fb21000 CR3: 000190863000 CR4: 001426f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 context_switch kernel/sched/core.c:2826 [inline]
 __schedule+0x884/0x1ec0 kernel/sched/core.c:3471
 context_switch kernel/sched/core.c:2826 [inline]
 __schedule+0x884/0x1ec0 kernel/sched/core.c:3471
 preempt_schedule_common+0x22/0x60 kernel/sched/core.c:3595
 schedule+0xfb/0x450 kernel/sched/core.c:3515
 _cond_resched+0x1d/0x30 kernel/sched/core.c:4961
 __mutex_lock_common kernel/locking/mutex.c:908 [inline]
 __mutex_lock+0x13d/0x1700 kernel/locking/mutex.c:1073
 exit_to_usermode_loop+0x22f/0x380 arch/x86/entry/common.c:152
 prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
 do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x456cb9
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00

RSP: 002b:7fd2dc8cecf8 EFLAGS: 0246
 ORIG_RAX: 00ca
RAX: 0001 RBX: 00930148 RCX: 00456cb9
RDX: 0016 RSI: 0001 RDI: 0093014c
RBP: 00930140 R08:  R09: 
 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
R10:  R11: 0246 R12: 0093014c
R13: 7ffd09c12e5f R14: 7fd2dc8cf9c0 R15: 0001
 arch_jump_label_transform+0x1b/0x40 arch/x86/kernel/jump_label.c:112
Modules linked in:
 __jump_label_update+0x16e/0x1a0 kernel/jump_label.c:375
 jump_label_update+0x151/0x2e0 kernel/jump_label.c:760
Dumping ftrace buffer:
 static_key_slow_inc_cpuslocked+0x341/0x430 kernel/jump_label.c:110
   (ftrace buffer empty)
---[ end trace de1ac742ecfe90a2 ]---
RIP: 0010:__fire_sched_in_preempt_notifiers kernel/sched/core.c:2481  
[inline]

RIP: 0010:fire_sched_in_preempt_notifiers kernel/sched/core.c:2487 [inline]
RIP: 0010:finish_task_switch+0x538/0x870 kernel/sched/core.c:2679
Code: 89 e1 48 c1 e9 03 42 80 3c 39 00 0f 85 ab 01 00 00 4d 8b 24 24 4d 85  
e4 0f 84 e3 fc ff ff 49 8d 7c 24 10 48 89 f9 48 c1 e9 03 <42> 80 3c 39 00  
74 a5 e8 1c e8 67 00 eb 9e 80 

Re: [PATCH RESEND RFC 1/4] drivers: pinctrl: qcom: add wakeup capability to GPIO

[Stephen Boyd]

Quoting Marc Zyngier (2018-08-10 00:45:12)
> On Thu, 09 Aug 2018 18:30:53 +0100,
> Stephen Boyd  wrote:
> > 
> > Quoting Marc Zyngier (2018-08-07 23:26:32)
> > > 
> > > Level interrupts should be taken care of without doing anything, by the
> > > very nature of being a level signal.
> > 
> > Right. I suspect we'll still need to configure the PDC to actually wake
> > up on the level triggered signal though so PDC needs to be told to
> > unmask the line.
> 
> Surely this can be done at suspend time with the PDC driver tracking
> the interrupts that are configured as a wake-up source (although it
> needs to track an interrupt that is logically connected to the TLMM,
> which sucks).

The PDC also needs to be configured for wakeups from deep CPU idle
states where the GIC and TLMM are powered down. Lina, can you confirm
this?

Hooking system suspend in that case won't work. Is your hope that we can
avoid using hierarchical irqdomains here entirely?

[PATCH 3/3] mm/memory_hotplug: Cleanup unregister_mem_sect_under_nodes

[osalvador]

From: Oscar Salvador 

With the assumption that the relationship between
memory_block <-> node is 1:1, we can refactor this function a bit.

This assumption is being taken from register_mem_sect_under_node()
code.

register_mem_sect_under_node() takes the mem_blk's nid, and compares it
to the pfn's nid we are checking.
If they match, we go ahead and link both objects.
Once done, we just return.

So, the relationship between memory_block <-> node seems to stand.

Currently, unregister_mem_sect_under_nodes() defines a nodemask_t
which is being checked in the loop to see if we have already unliked certain 
node.
But since a memory_block can only belong to a node, we can drop the nodemask
and the check within the loop.

If we find a match between the mem_block->nid and the nid of the
pfn we are checking, we unlink the objects and return, as unlink the objects
once is enough.

Signed-off-by: Oscar Salvador 
---
 drivers/base/node.c | 30 +++---
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index dd3bdab230b2..0657ed70bddd 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -448,35 +448,27 @@ int register_mem_sect_under_node(struct memory_block 
*mem_blk, void *arg)
return 0;
 }
 
-/* unregister memory section under all nodes that it spans */
+/* unregister memory section from the node it belongs to */
 int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
unsigned long phys_index)
 {
-   NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
unsigned long pfn, sect_start_pfn, sect_end_pfn;
-
-   if (!unlinked_nodes)
-   return -ENOMEM;
-   nodes_clear(*unlinked_nodes);
+   int nid = mem_blk->nid;
 
sect_start_pfn = section_nr_to_pfn(phys_index);
sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn <= sect_end_pfn; pfn++) {
-   int nid;
+   int page_nid = get_nid_for_pfn(pfn);
 
-   nid = get_nid_for_pfn(pfn);
-   if (nid < 0)
-   continue;
-   if (!node_online(nid))
-   continue;
-   if (node_test_and_set(nid, *unlinked_nodes))
-   continue;
-   sysfs_remove_link(_devices[nid]->dev.kobj,
-kobject_name(_blk->dev.kobj));
-   sysfs_remove_link(_blk->dev.kobj,
-kobject_name(_devices[nid]->dev.kobj));
+   if (page_nid >= 0 && page_nid == nid) {
+   sysfs_remove_link(_devices[nid]->dev.kobj,
+kobject_name(_blk->dev.kobj));
+   sysfs_remove_link(_blk->dev.kobj,
+kobject_name(_devices[nid]->dev.kobj));
+   break;
+   }
}
-   NODEMASK_FREE(unlinked_nodes);
+
return 0;
 }
 
-- 
2.13.6

[PATCH 2/3] mm/memory_hotplug: Drop unneeded check from unregister_mem_sect_under_nodes

[osalvador]

From: Oscar Salvador 

Before calling to unregister_mem_sect_under_nodes(),
remove_memory_section() already checks if we got a valid
memory_block.

No need to check that again in unregister_mem_sect_under_nodes().

Signed-off-by: Oscar Salvador 
---
 drivers/base/node.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/base/node.c b/drivers/base/node.c
index 1ac4c36e13bb..dd3bdab230b2 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -455,10 +455,6 @@ int unregister_mem_sect_under_nodes(struct memory_block 
*mem_blk,
NODEMASK_ALLOC(nodemask_t, unlinked_nodes, GFP_KERNEL);
unsigned long pfn, sect_start_pfn, sect_end_pfn;
 
-   if (!mem_blk) {
-   NODEMASK_FREE(unlinked_nodes);
-   return -EFAULT;
-   }
if (!unlinked_nodes)
return -ENOMEM;
nodes_clear(*unlinked_nodes);
-- 
2.13.6

[PATCH 1/3] mm/memory_hotplug: Drop unused args from remove_memory_section

[osalvador]

From: Oscar Salvador 

unregister_memory_section() calls remove_memory_section()
with three arguments:

* node_id
* section
* phys_device

Neither node_id nor phys_device are used.
Let us drop them from the function.

Signed-off-by: Oscar Salvador 
---
 drivers/base/memory.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index c8a1cb0b6136..2c622a9a7490 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -752,8 +752,7 @@ unregister_memory(struct memory_block *memory)
device_unregister(>dev);
 }
 
-static int remove_memory_section(unsigned long node_id,
-  struct mem_section *section, int phys_device)
+static int remove_memory_section(struct mem_section *section)
 {
struct memory_block *mem;
 
@@ -785,7 +784,7 @@ int unregister_memory_section(struct mem_section *section)
if (!present_section(section))
return -EINVAL;
 
-   return remove_memory_section(0, section, 0);
+   return remove_memory_section(section);
 }
 #endif /* CONFIG_MEMORY_HOTREMOVE */
 
-- 
2.13.6

[PATCH 0/3] Refactor/cleanup for remove_memory_section/unregister_mem_sect_under_nodes

[osalvador]

From: Oscar Salvador 

This patchset is about cleaning up/refactoring a few functions
from the memory-hotplug code.

The first and the second patch are pretty straightforward, as they
only remove unused arguments/checks.
The third one change the layout of the unregister_mem_sect_under_nodes a bit.

Oscar Salvador (3):
  mm/memory_hotplug: Drop unused args from remove_memory_section
  mm/memory_hotplug: Drop unneeded check from
unregister_mem_sect_under_nodes
  mm/memory_hotplug: Cleanup unregister_mem_sect_under_nodes

 drivers/base/memory.c |  5 ++---
 drivers/base/node.c   | 34 +++---
 2 files changed, 13 insertions(+), 26 deletions(-)

-- 
2.13.6

[PATCH 0/4] Add support to register platform service IRQ

[Bharat Kumar Gogada]

Some platforms have dedicated IRQ lines for PCIe services like
AER/PME etc. The root complex on these platform will use these seperate
IRQ lines to report AER/PME etc., interrupts and will not generate
MSI/MSI-X/INTx interrupts for these services.
These patches will add new method for these kind of platforms
to register the platform IRQ number with respective PCIe services.

Bharat Kumar Gogada (4):
  PCI: Add setup_platform_service_irq hook to struct pci_host_bridge
  PCI: Add pci_check_platform_service_irqs
  PCI/portdrv: Check platform supported service IRQ's
  PCI: xilinx-nwl: Add method to setup_platform_service_irq hook

 drivers/pci/controller/pcie-xilinx-nwl.c |   16 
 drivers/pci/pcie/portdrv_core.c  |   19 +--
 include/linux/pci.h  |   25 +
 3 files changed, 58 insertions(+), 2 deletions(-)

[PATCH 1/4] PCI: Add setup_platform_service_irq hook to struct pci_host_bridge

[Bharat Kumar Gogada]

Add setup_platform_service_irq hook to struct pci_host_bridge.
Some platforms have dedicated interrupt line from root complex to
interrupt controller for PCIe services like AER/PME etc.
This hook is to register platform IRQ's to PCIe port services.

Signed-off-by: Bharat Kumar Gogada 
---
 include/linux/pci.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index 340029b..c28f575 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -470,6 +470,7 @@ struct pci_host_bridge {
u8 (*swizzle_irq)(struct pci_dev *, u8 *); /* Platform IRQ swizzler */
int (*map_irq)(const struct pci_dev *, u8, u8);
void (*release_fn)(struct pci_host_bridge *);
+   int (*setup_platform_service_irq)(struct pci_host_bridge *, int *, int);
void*release_data;
struct msi_controller *msi;
unsigned intignore_reset_delay:1;   /* For entire hierarchy */
-- 
1.7.1

[PATCH 4/4] PCI: xilinx-nwl: Add method to setup_platform_service_irq hook

[Bharat Kumar Gogada]

Add nwl_setup_service_irqs hook to setup_platform_service_irq IRQs to
register platform provided IRQ number to kernel AER service.

Signed-off-by: Bharat Kumar Gogada 
---
 drivers/pci/controller/pcie-xilinx-nwl.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c 
b/drivers/pci/controller/pcie-xilinx-nwl.c
index fb32840..285647b 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "../pci.h"
+#include "../pcie/portdrv.h"
 
 /* Bridge core config registers */
 #define BRCFG_PCIE_RX0 0x
@@ -819,6 +820,20 @@ static int nwl_pcie_parse_dt(struct nwl_pcie *pcie,
return 0;
 }
 
+int nwl_setup_service_irqs(struct pci_host_bridge *bridge, int *irqs,
+  int plat_mask)
+{
+   struct nwl_pcie *pcie;
+
+   pcie = pci_host_bridge_priv(bridge);
+   if (plat_mask & PCIE_PORT_SERVICE_AER) {
+   irqs[PCIE_PORT_SERVICE_AER_SHIFT] = pcie->irq_misc;
+   plat_mask &= ~(1 << PCIE_PORT_SERVICE_AER_SHIFT);
+   }
+
+   return plat_mask;
+}
+
 static const struct of_device_id nwl_pcie_of_match[] = {
{ .compatible = "xlnx,nwl-pcie-2.11", },
{}
@@ -880,6 +895,7 @@ static int nwl_pcie_probe(struct platform_device *pdev)
bridge->ops = _pcie_ops;
bridge->map_irq = of_irq_parse_and_map_pci;
bridge->swizzle_irq = pci_common_swizzle;
+   bridge->setup_platform_service_irq = nwl_setup_service_irqs;
 
if (IS_ENABLED(CONFIG_PCI_MSI)) {
err = nwl_pcie_enable_msi(pcie);
-- 
1.7.1

[PATCH 3/4] PCI/portdrv: Check platform supported service IRQ's

[Bharat Kumar Gogada]

Platforms may have dedicated IRQ lines for PCIe services like
AER/PME etc., check for such IRQ lines.
Check mask and fill legacy irq line for services other than
platform supported service IRQ number.

Signed-off-by: Bharat Kumar Gogada 
---
 drivers/pci/pcie/portdrv_core.c |   19 +--
 1 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e0261ad..a7d024c 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -166,6 +166,19 @@ static int pcie_init_service_irqs(struct pci_dev *dev, int 
*irqs, int mask)
irqs[i] = -1;
 
/*
+* Some platforms have dedicated interrupt line from root complex to
+* interrupt controller for PCIe services like AER/PME etc., check
+* if platform registered with any such IRQ.
+*/
+   if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) {
+   int plat_mask;
+
+   plat_mask = pci_check_platform_service_irqs(dev, irqs, mask);
+   if (plat_mask > 0)
+   mask = mask & plat_mask;
+   }
+
+   /*
 * If we support PME but can't use MSI/MSI-X for it, we have to
 * fall back to INTx or other interrupts, e.g., a system shared
 * interrupt.
@@ -183,8 +196,10 @@ static int pcie_init_service_irqs(struct pci_dev *dev, int 
*irqs, int mask)
if (ret < 0)
return -ENODEV;
 
-   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
-   irqs[i] = pci_irq_vector(dev, 0);
+   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
+   if (mask & (1 << i))
+   irqs[i] = pci_irq_vector(dev, 0);
+   }
 
return 0;
 }
-- 
1.7.1

[PATCH 2/4] PCI: Add pci_check_platform_service_irqs

[Bharat Kumar Gogada]

Adding method pci_check_platform_service_irqs to check if platform
has registered method to proivde dedicated IRQ lines for PCIe services
like AER/PME etc.

Signed-off-by: Bharat Kumar Gogada 
---
 include/linux/pci.h |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/include/linux/pci.h b/include/linux/pci.h
index c28f575..8eb6470 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2271,6 +2271,30 @@ static inline bool pci_ari_enabled(struct pci_bus *bus)
 }
 
 /**
+ * pci_check_platform_service_irqs - check platform service irq's
+ * @pdev: PCI Express device to check
+ * @irqs: Array of irqs to populate
+ * @mask: Bitmask of capabilities
+ *
+ * Return value: Bitmask after clearing platform supported service
+ * bits
+ */
+static inline int pci_check_platform_service_irqs(struct pci_dev *dev,
+ int *irqs, int mask)
+{
+   struct pci_host_bridge *bridge;
+
+   if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
+   return -EINVAL;
+
+   bridge = pci_find_host_bridge(dev->bus);
+   if (bridge && bridge->setup_platform_service_irq)
+   return bridge->setup_platform_service_irq(bridge, irqs, mask);
+   else
+   return -EINVAL;
+}
+
+/**
  * pci_is_thunderbolt_attached - whether device is on a Thunderbolt daisy chain
  * @pdev: PCI device to check
  *
-- 
1.7.1

Re: [PATCH v8 04/22] s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.

[Tony Krowiak]

On 08/10/2018 04:49 AM, Cornelia Huck wrote:

On Thu, 9 Aug 2018 12:06:56 -0400
Tony Krowiak  wrote:


On 08/09/2018 05:17 AM, Harald Freudenberger wrote:

On 09.08.2018 11:06, Cornelia Huck wrote:

On Wed,  8 Aug 2018 10:44:14 -0400
Tony Krowiak  wrote:
  

From: Harald Freudenberger 

Move all the inline functions from the ap bus header
file ap_asm.h into the in-kernel api header file
arch/s390/include/asm/ap.h so that KVM can make use
of all the low level AP functions.

Signed-off-by: Harald Freudenberger 
Signed-off-by: Christian Borntraeger 

You should add your own s-o-b if you are sending on patches written by
others (even if it does not matter in the end, when they are merged
through a different path anyway.)
  

---
   arch/s390/include/asm/ap.h |  284 

   drivers/s390/crypto/ap_asm.h   |  261 
   drivers/s390/crypto/ap_bus.c   |   21 +---
   drivers/s390/crypto/ap_bus.h   |1 +
   drivers/s390/crypto/ap_card.c  |1 -
   drivers/s390/crypto/ap_queue.c |1 -
   6 files changed, 259 insertions(+), 310 deletions(-)
   delete mode 100644 drivers/s390/crypto/ap_asm.h

diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
index c1bedb4..046e044 100644
--- a/arch/s390/include/asm/ap.h
+++ b/arch/s390/include/asm/ap.h
@@ -47,6 +47,50 @@ struct ap_queue_status {
   };
   
   /**

+ * ap_intructions_available() - Test if AP instructions are available.
+ *
+ * Returns 0 if the AP instructions are installed.

Stumbled over this when I was looking at the usage in patch 7: if I see
a function called '_available' return 0, I'd assume that whatever the
function tests for is *not* available.

Rather call this function ap_instructions_check_availability() (and
keep the return code convention), or switch this to return 0 if not
available and !0 if available?

Good catch, Cony you are right. I'll fix this to return 1 if AP instructions
are available and 0 if not. However, this patch will come via Martin's pipe
to the Linus Torwald kernel sources.

Is your intent to simply indicate whether the AP instructions are
available or
not; or is the intention to indicate whether the AP instructions are
available
and if not, they why? In the former, then I agree that a boolean should be
returned; however, if the case is the latter, then what you have is fine but
maybe the function name should be changed as Connie suggests.

So, can this actually fail for any reason other than "instructions not
installed"? Even if it did, the end result is that the instructions are
not usable -- I don't think the "why" would be interesting at that
point.


The only case I can think of is if something is hosed and it causes an
exception. In that case, should we proceed?




+ */
+static inline int ap_instructions_available(void)
+{
+   register unsigned long reg0 asm ("0") = AP_MKQID(0, 0);
+   register unsigned long reg1 asm ("1") = -ENODEV;
+   register unsigned long reg2 asm ("2");
+
+   asm volatile(
+   "   .long 0xb2af\n"   /* PQAP(TAPQ) */
+   "0: la%0,0\n"
+   "1:\n"
+   EX_TABLE(0b, 1b)
+   : "+d" (reg1), "=d" (reg2)
+   : "d" (reg0)
+   : "cc");
+   return reg1;
+}

[PATCH 2/3] arm64: implement live patching

[Torsten Duwe]

Based on ftrace with regs, do the usual thing. Also allocate a
task flag for whatever consistency handling is implemented.
Watch out for interactions with the graph tracer.
This code has been compile-tested, but has not yet seen any
heavy livepatching.

Signed-off-by: Torsten Duwe 

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 28c8c03..31df287 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -117,6 +117,7 @@ config ARM64
select HAVE_GENERIC_DMA_COHERENT
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_IRQ_TIME_ACCOUNTING
+   select HAVE_LIVEPATCH
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP if NUMA
select HAVE_NMI
@@ -1343,4 +1344,6 @@ if CRYPTO
 source "arch/arm64/crypto/Kconfig"
 endif
 
+source "kernel/livepatch/Kconfig"
+
 source "lib/Kconfig"
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -76,6 +76,7 @@ void arch_release_task_struct(struct tas
 #define TIF_FOREIGN_FPSTATE3   /* CPU's FP state is not current's */
 #define TIF_UPROBE 4   /* uprobe breakpoint or singlestep */
 #define TIF_FSCHECK5   /* Check FS is USER_DS on return */
+#define TIF_PATCH_PENDING  6
 #define TIF_NOHZ   7
 #define TIF_SYSCALL_TRACE  8
 #define TIF_SYSCALL_AUDIT  9
@@ -94,6 +95,7 @@ void arch_release_task_struct(struct tas
 #define _TIF_NEED_RESCHED  (1 << TIF_NEED_RESCHED)
 #define _TIF_NOTIFY_RESUME (1 << TIF_NOTIFY_RESUME)
 #define _TIF_FOREIGN_FPSTATE   (1 << TIF_FOREIGN_FPSTATE)
+#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
 #define _TIF_NOHZ  (1 << TIF_NOHZ)
 #define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
 #define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
@@ -106,7 +108,8 @@ void arch_release_task_struct(struct tas
 
 #define _TIF_WORK_MASK (_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
 _TIF_NOTIFY_RESUME | _TIF_FOREIGN_FPSTATE | \
-_TIF_UPROBE | _TIF_FSCHECK)
+_TIF_UPROBE | _TIF_FSCHECK | \
+_TIF_PATCH_PENDING)
 
 #define _TIF_SYSCALL_WORK  (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
 _TIF_SYSCALL_TRACEPOINT | _TIF_SECCOMP | \
diff --git a/arch/arm64/include/asm/livepatch.h 
b/arch/arm64/include/asm/livepatch.h
new file mode 100644
index 000..6b9a3d1
--- /dev/null
+++ b/arch/arm64/include/asm/livepatch.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * livepatch.h - arm64-specific Kernel Live Patching Core
+ *
+ * Copyright (C) 2016 SUSE
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+#ifndef _ASM_ARM64_LIVEPATCH_H
+#define _ASM_ARM64_LIVEPATCH_H
+
+#include 
+#include 
+
+#ifdef CONFIG_LIVEPATCH
+static inline int klp_check_compiler_support(void)
+{
+   return 0;
+}
+
+static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+   regs->pc = ip;
+}
+#endif /* CONFIG_LIVEPATCH */
+
+#endif /* _ASM_ARM64_LIVEPATCH_H */
diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index cdb5866..cf640e8 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -195,6 +195,9 @@ ENTRY(ftrace_caller)
str x9, [sp, #S_LR]
/* The program counter just after the ftrace call site */
str lr, [sp, #S_PC]
+#if defined(CONFIG_LIVEPATCH) && defined(CONFIG_FUNCTION_GRAPH_TRACER)
+   mov x19,lr  /* remember old return address */
+#endif
/* The stack pointer as it was on ftrace_caller entry... */
add x29, sp, #S_FRAME_SIZE+16   /* ...is also our new FP */
str x29, [sp, #S_SP]
@@ -210,6 +213,16 @@ ftrace_call:
 
bl  ftrace_stub
 
+#if defined(CONFIG_LIVEPATCH) && defined(CONFIG_FUNCTION_GRAPH_TRACER)
+   /* Is the trace function a live patcher an has messed with
+* the return address?
+   */
+   ldr x9, [sp, #S_PC]
+   cmp x9, x19 /* compare with the value we remembered */
+   /* to not call graph tracer's "call" mechanism twice! */
+   b.neftrace_regs_return
+#endif
+
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
.global ftrace_graph_call
 ftrace_graph_call: // 

[PATCH 3/3] arm64: reliable stacktraces

[Torsten Duwe]

This is more an RFC in the original sense: is this basically
the correct approach? (as I had to tweak the API a bit).

In particular the code does not detect interrupts and exception
frames, and does not yet check whether the code address is valid.
The latter check would also have to be omitted for the latest frame
on other tasks' stacks. This would require some more tweaking.

unwind_frame() now reports whether we had to stop normally or due to
an error condition; walk_stackframe() will pass that info.
__save_stack_trace() is used for a start to check the validity of a
frame; maybe save_stack_trace_tsk_reliable() will need its own callback.

Any comments welcome.

Signed-off-by: Torsten Duwe 

--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -127,8 +127,9 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
-   select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
+   select HAVE_REGS_AND_STACK_ACCESS_API
+   select HAVE_RELIABLE_STACKTRACE
select HAVE_STACKPROTECTOR
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES
--- a/arch/arm64/include/asm/stacktrace.h
+++ b/arch/arm64/include/asm/stacktrace.h
@@ -33,7 +33,7 @@ struct stackframe {
 };
 
 extern int unwind_frame(struct task_struct *tsk, struct stackframe *frame);
-extern void walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
+extern int walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
int (*fn)(struct stackframe *, void *), void *data);
 extern void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk);
 
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index d5718a060672..fe0dd4745ff3 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -81,23 +81,27 @@ int notrace unwind_frame(struct task_struct *tsk, struct 
stackframe *frame)
 * both are NULL.
 */
if (!frame->fp && !frame->pc)
-   return -EINVAL;
+   return 1;
 
return 0;
 }
 
-void notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
+int notrace walk_stackframe(struct task_struct *tsk, struct stackframe *frame,
 int (*fn)(struct stackframe *, void *), void *data)
 {
while (1) {
int ret;
 
-   if (fn(frame, data))
-   break;
+   ret = fn(frame, data);
+   if (ret)
+   return ret;
ret = unwind_frame(tsk, frame);
if (ret < 0)
+   return ret;
+   if (ret > 0)
break;
}
+   return 0;
 }
 
 #ifdef CONFIG_STACKTRACE
@@ -145,14 +149,15 @@ void save_stack_trace_regs(struct pt_regs *regs, struct 
stack_trace *trace)
trace->entries[trace->nr_entries++] = ULONG_MAX;
 }
 
-static noinline void __save_stack_trace(struct task_struct *tsk,
+static noinline int __save_stack_trace(struct task_struct *tsk,
struct stack_trace *trace, unsigned int nosched)
 {
struct stack_trace_data data;
struct stackframe frame;
+   int ret;
 
if (!try_get_task_stack(tsk))
-   return;
+   return -EBUSY;
 
data.trace = trace;
data.skip = trace->skip;
@@ -171,11 +176,12 @@ static noinline void __save_stack_trace(struct 
task_struct *tsk,
frame.graph = tsk->curr_ret_stack;
 #endif
 
-   walk_stackframe(tsk, , save_trace, );
+   ret = walk_stackframe(tsk, , save_trace, );
if (trace->nr_entries < trace->max_entries)
trace->entries[trace->nr_entries++] = ULONG_MAX;
 
put_task_stack(tsk);
+   return ret;
 }
 EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
 
@@ -190,4 +196,12 @@ void save_stack_trace(struct stack_trace *trace)
 }
 
 EXPORT_SYMBOL_GPL(save_stack_trace);
+
+int save_stack_trace_tsk_reliable(struct task_struct *tsk,
+ struct stack_trace *trace)
+{
+   return __save_stack_trace(tsk, trace, 1);
+}
+EXPORT_SYMBOL_GPL(save_stack_trace_tsk_reliable);
+
 #endif

[PATCH v2] checkpatch: DT bindings should be a separate patch

[Rob Herring]

Devicetree bindings should be their own patch as documented in
Documentation/devicetree/bindings/submitting-patches.txt section I.1.
This is because bindings are logically independent from a driver
implementation, they have a different maintainer (even though they often
are applied via the same tree), and it makes for a cleaner history in
the DT only tree created with git-filter-branch.

Cc: Andy Whitcroft 
Cc: Joe Perches 
Signed-off-by: Rob Herring 
---
v2:
- Add doc pointer to warning
- Simplify logic

Joe, this makes $is_binding_patch an empty value when the regex doesn't 
match rather than 0 which would be more logical IMO. It seems to work 
fine, but I'm not sure if there's a better way to do it.

 scripts/checkpatch.pl | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index a9c05506e325..f9aba4bc41ce 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2236,6 +2236,7 @@ sub process {
our $clean = 1;
my $signoff = 0;
my $is_patch = 0;
+   my $is_binding_patch = -1;
my $in_header_lines = $file ? 0 : 1;
my $in_commit_log = 0;  #Scanning lines before patch
my $has_commit_log = 0; #Encountered lines before patch
@@ -2485,6 +2486,19 @@ sub process {
$check = $check_orig;
}
$checklicenseline = 1;
+
+   if ($realfile !~ /^MAINTAINERS/) {
+   my $last_binding_patch = $is_binding_patch;
+
+   $is_binding_patch = ($realfile =~ 
m@^(?:Documentation/devicetree/|include/dt-bindings/)@);
+
+   if (($last_binding_patch != -1) &&
+   ($last_binding_patch ^ $is_binding_patch)) {
+   WARN("DT_SPLIT_BINDING_PATCH",
+"DT binding docs and includes 
should be a separate patch. See: 
Documentation/devicetree/bindings/submitting-patches.txt");
+   }
+   }
+
next;
}
 
-- 
2.17.1

Re: [RFC] serial: sc16is7xx: Use DT sub-nodes for UART ports

[Rob Herring]

On Fri, Aug 10, 2018 at 11:45 AM Andreas Färber  wrote:
>
> Am 10.08.2018 um 19:34 schrieb Rob Herring:
> > On Sun, Aug 5, 2018 at 5:27 PM Andreas Färber  wrote:
> >>
> >> This is to allow using serdev.
> >>
> >> Signed-off-by: Andreas Färber 
> >> ---
> >>  drivers/tty/serial/sc16is7xx.c | 25 +
> >>  1 file changed, 25 insertions(+)
> >>
> >> diff --git a/drivers/tty/serial/sc16is7xx.c 
> >> b/drivers/tty/serial/sc16is7xx.c
> >> index 243c96025053..ad7267274f65 100644
> >> --- a/drivers/tty/serial/sc16is7xx.c
> >> +++ b/drivers/tty/serial/sc16is7xx.c
> >> @@ -1213,9 +1213,31 @@ static int sc16is7xx_probe(struct device *dev,
> >> SC16IS7XX_IOCONTROL_SRESET_BIT);
> >>
> >> for (i = 0; i < devtype->nr_uart; ++i) {
> >> +#ifdef CONFIG_OF
> >> +   struct device_node *np;
> >> +   struct platform_device *pdev;
> >> +   char name[6] = "uartx";
> >> +#endif
> >> +
> >> s->p[i].line= i;
> >> /* Initialize port data */
> >> +#ifdef CONFIG_OF
> >> +   name[4] = '0' + i;
> >> +   np = of_get_child_by_name(dev->of_node, name);
> >> +   if (IS_ERR(np)) {
> >> +   ret = PTR_ERR(np);
> >> +   goto out_ports;
> >> +   }
> >> +   pdev = of_platform_device_create(np, NULL, dev);
> >
> > Ideally, you would use of_platform_default_populate here. I think
> > you'd have to add a compatible to the child nodes, but that wouldn't
> > be a bad thing. I could envision that the child nodes ultimately
> > become their own driver utilizing the standard 8250 driver and a
> > compatible string would be needed in that case.
>
> Separate compatibles would mean separate drivers.

No. Having a compatible doesn't mean you have to have a driver.

> Unlike your DUART example this is not an MMIO device that we can easily
> split but a SPI slave (well, regmap due to some I2C models).

A SPI slave could provide a regmap, right?

> I don't see how separate drivers could work, given that the whole
> spi_device has a single interrupt for all functions of this device.

A shared interrupt or a parent driver that creates an irqchip like MFD
drivers often do.

>
> That left me with this ugly but working construct.

In any case, I'm was suggesting that you do any of this now. I just
want the binding to be designed to work either way.

> Is the uartX naming correct, or should it be serialX?

Ah, yes. Should be serial@... I'm fine if both the parent and child
are named serial@...

Rob

Re: [PATCH] coccicheck: return proper error code on check fail

[Denis Efremov]

> Do you mean that there is an error in the behavior of coccicheck or that 
> coccicheck finds an error in the source code?

An error in the source code.

Here is an example of how the patch changes the behavior of 'make
coccicheck' (my comments after the ###):
Current behavior:
$ make M=mymodule coccicheck
mymodule/file1.c:97:4-14: ERROR: Assignment of bool to non-0/1 constant
mymodule/file2.c:104:4-19: ERROR: Assignment of bool to non-0/1 constant
mymodule/file2.c:577:1-15: code aligned with following code on line 583
mymodule/file3.c:439:5-10: Unneeded variable: "error". Return "0" on line 449
mymodule/file4.c:451:5-7: Unneeded variable: "rc". Return "0" on line 455
mymodule/file5.c:433:5-8: Unneeded variable: "ret". Return "0" on line 607
mymodule/file6.c:433:5-10: Unneeded variable: "error". Return "0" on line 440
mymodule/file7.c:774:2-3: Unneeded semicolon
coccicheck failed ### <-- Check failed
$ echo $?
0 ### <-- But error code signals that everthing is OK

After this patch:
$ make M=mymodule coccicheck
...
coccicheck failed
make: *** [Makefile:1636: coccicheck] Error 2
$ echo $?
2 ### <-- The patch changes error code

Why does this matter?
1) Because it's clear from the source code that the original intention
was to return an error code of checking command, not the "echo
'coccicheck failed'" command.
2) Automated testing systems (CI, for example) rely on the return code.

Re: [PATCH] coccicheck: return proper error code on check fail

[Denis Efremov]

My mistake. Initially, I thought that this line signals about errors
in the code, but now I see that this is about the tool's internal
error. However, this doesn't change the fact that coccicheck returns
the improper error code.

I will reformulate the commit message and send the v2 patch with the
same diff. Thank you for clarifying things.

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Lorenzo Pieralisi]

On Fri, Aug 10, 2018 at 11:11:55AM +, Leonard Crestez wrote:

[...]

> This needs further clarification: without the reset patch this will
> hang on imx7 suspend/resume but this is the current behavior anyway.
> 
> Both patches are required for imx7 pci suspend and including them out
> of order shouldn't break unrelated functionality.
> 
> So it should actually be fine to just include the pci changes now,
> right?

It is a bit late for v4.19 but before considering that, this series
is actually a set of fixes, correct ? If that's the case I think
Shawn can send them upstream for a v4.19-rc*, I can ACK them if that
sounds reasonable.

Patch (2) subject must make clear you are actually fixing a problem if
we choose this course of action.

Lorenzo

Re: mmotm 2018-08-09-20-10 uploaded (mtd/nand/raw/atmel/)

[Randy Dunlap]

On 08/09/2018 08:11 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-08-09-20-10 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.

on i386:

ERROR: "of_gen_pool_get" [drivers/mtd/nand/raw/atmel/atmel-nand-controller.ko] 
undefined!
ERROR: "gen_pool_dma_alloc" 
[drivers/mtd/nand/raw/atmel/atmel-nand-controller.ko] undefined!
ERROR: "gen_pool_free" [drivers/mtd/nand/raw/atmel/atmel-nand-controller.ko] 
undefined!


Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.18.0-rc8-mm1 Kernel Configuration
#

#
# Compiler: gcc (SUSE Linux) 4.8.5
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=40805
CONFIG_CLANG_VERSION=0
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_BZIP2=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_SIM=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_CPU_ISOLATION=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_EXPERT=y
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_BOOST is not set
CONFIG_RCU_NOCB_CPU=y
# CONFIG_IKCONFIG is not set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
# CONFIG_CGROUPS is not set
# CONFIG_NAMESPACES is not set
CONFIG_CHECKPOINT_RESTORE=y
# CONFIG_SCHED_AUTOGROUP is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
# CONFIG_SYSFS_SYSCALL is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
# CONFIG_PRINTK is not set
CONFIG_BUG=y
# CONFIG_PCSPKR_PLATFORM is not set
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
# CONFIG_TIMERFD is not set
CONFIG_EVENTFD=y
# CONFIG_SHMEM is not set
CONFIG_AIO=y
# CONFIG_ADVISE_SYSCALLS is not set
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_USERFAULTFD=y
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_RSEQ=y
# CONFIG_DEBUG_RSEQ is not set
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
# CONFIG_PC104 is not set

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
CONFIG_SLAB_MERGE_DEFAULT=y
CONFIG_SYSTEM_DATA_VERIFICATION=y
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8

Applied "regulator: dt-bindings: add QCOM RPMh regulator bindings" to the regulator tree

[Mark Brown]

The patch

   regulator: dt-bindings: add QCOM RPMh regulator bindings

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 0db021f7a2731cc559f0c5beb19ff3f677ff8626 Mon Sep 17 00:00:00 2001
From: David Collins 
Date: Fri, 13 Jul 2018 18:50:58 -0700
Subject: [PATCH] regulator: dt-bindings: add QCOM RPMh regulator bindings

Introduce bindings for RPMh regulator devices found on some
Qualcomm Technlogies, Inc. SoCs.  These devices allow a given
processor within the SoC to make PMIC regulator requests which
are aggregated within the RPMh hardware block along with requests
from other processors in the SoC to determine the final PMIC
regulator hardware state.

Signed-off-by: David Collins 
Reviewed-by: Rob Herring 
Reviewed-by: Douglas Anderson 
Signed-off-by: Mark Brown 
---
 .../regulator/qcom,rpmh-regulator.txt | 160 ++
 .../regulator/qcom,rpmh-regulator.h   |  36 
 2 files changed, 196 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
 create mode 100644 include/dt-bindings/regulator/qcom,rpmh-regulator.h

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt 
b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
new file mode 100644
index ..7ef2dbe48e8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -0,0 +1,160 @@
+Qualcomm Technologies, Inc. RPMh Regulators
+
+rpmh-regulator devices support PMIC regulator management via the Voltage
+Regulator Manager (VRM) and Oscillator Buffer (XOB) RPMh accelerators.  The 
APPS
+processor communicates with these hardware blocks via a Resource State
+Coordinator (RSC) using command packets.  The VRM allows changing three
+parameters for a given regulator: enable state, output voltage, and operating
+mode.  The XOB allows changing only a single parameter for a given regulator:
+its enable state.  Despite its name, the XOB is capable of controlling the
+enable state of any PMIC peripheral.  It is used for clock buffers, low-voltage
+switches, and LDO/SMPS regulators which have a fixed voltage and mode.
+
+===
+Required Node Structure
+===
+
+RPMh regulators must be described in two levels of device nodes.  The first
+level describes the PMIC containing the regulators and must reside within an
+RPMh device node.  The second level describes each regulator within the PMIC
+which is to be used on the board.  Each of these regulators maps to a single
+RPMh resource.
+
+The names used for regulator nodes must match those supported by a given PMIC.
+Supported regulator node names:
+   PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
+   PMI8998:bob
+   PM8005: smps1 - smps4
+
+
+First Level Nodes - PMIC
+
+
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: Must be one of: "qcom,pm8998-rpmh-regulators",
+   "qcom,pmi8998-rpmh-regulators" or
+   "qcom,pm8005-rpmh-regulators".
+
+- qcom,pmic-id
+   Usage:  required
+   Value type: 
+   Definition: RPMh resource name suffix used for the regulators found on
+   this PMIC.  Typical values: "a", "b", "c", "d", "e", "f".
+
+- vdd-s1-supply
+- vdd-s2-supply
+- vdd-s3-supply
+- vdd-s4-supply
+   Usage:  optional (PM8998 and PM8005 only)
+   Value type: 
+   Definition: phandle of the parent supply regulator of one or more of the
+   regulators for this PMIC.
+
+- vdd-s5-supply
+- vdd-s6-supply
+- vdd-s7-supply
+- vdd-s8-supply
+- vdd-s9-supply
+- vdd-s10-supply
+- vdd-s11-supply
+- vdd-s12-supply
+- vdd-s13-supply
+- vdd-l1-l27-supply
+- vdd-l2-l8-l17-supply
+- vdd-l3-l11-supply
+- vdd-l4-l5-supply
+- vdd-l6-supply
+- vdd-l7-l12-l14-l15-supply
+- vdd-l9-supply
+- vdd-l10-l23-l25-supply
+- vdd-l13-l19-l21-supply
+- vdd-l16-l28-supply
+- vdd-l18-l22-supply
+- vdd-l20-l24-supply
+- vdd-l26-supply
+- vin-lvs-1-2-supply
+   Usage:  optional (PM8998 only)
+   Value type: 
+