Re: [Xen-devel] [RFC PATCH 00/16] xenhost support

[Ankur Arora]

On 2019-06-07 9:21 a.m., Juergen Gross wrote:

On 07.06.19 17:22, Joao Martins wrote:

On 6/7/19 3:51 PM, Juergen Gross wrote:

On 09.05.19 19:25, Ankur Arora wrote:

Hi all,

This is an RFC for xenhost support, outlined here by Juergen here:
https://lkml.org/lkml/2019/4/8/67.


First: thanks for all the effort you've put into this series!


The high level idea is to provide an abstraction of the Xen
communication interface, as a xenhost_t.

xenhost_t expose ops for communication between the guest and Xen
(hypercall, cpuid, shared_info/vcpu_info, evtchn, grant-table and on 
top

of those, xenbus, ballooning), and these can differ based on the kind
of underlying Xen: regular, local, and nested.


I'm not sure we need to abstract away hypercalls and cpuid. I believe in
case of nested Xen all contacts to the L0 hypervisor should be done via
the L1 hypervisor. So we might need to issue some kind of passthrough
hypercall when e.g. granting a page to L0 dom0, but this should be
handled via the grant abstraction (events should be similar).

Just to be clear: By "kind of passthrough hypercall" you mean (e.g. 
for every
access/modify of grant table frames) you would proxy hypercall to L0 
Xen via L1 Xen?


It might be possible to spare some hypercalls by directly writing to
grant frames mapped into L1 dom0, but in general you are right.

Wouldn't we still need map/unmap_grant_ref?
AFAICS, both the xenhost_direct and the xenhost_indirect cases should be
very similar (apart from the need to proxy in the indirect case.)

Ankur




Juergen

___
Xen-devel mailing list
xen-de...@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v1 0/9] Introduce Bandwidth OPPs & interconnect devfreq driver

[Bjorn Andersson]

On Fri 07 Jun 21:43 PDT 2019, Saravana Kannan wrote:

> I replied[1] to this patch series[2] and described how I think interconnect
> bandwidth voting should be captured in DT and how it should work.
> 
> So sending out a patch series implementing that. This patch series does the
> following:
> - Adds Bandwidth OPP table support (this adds device freq to bandwidth
>   mapping for free)
> - Adds a devfreq library for interconnect paths
> 

Please provide a driver that uses this devfreq library, without it this
its impossible to gauge the usefulness of your approach.

> Interconnects and interconnect paths quantify they performance levels in
> terms of bandwidth. So similar to how we have frequency based OPP tables
> in DT and in the OPP framework, this patch series adds bandwidth OPP
> table support in the OPP framework and in DT.
> 
> To simplify voting for interconnects, this patch series adds helper
> functions to create devfreq devices out of interconnect paths. This
> allows drivers to add a single line of code to add interconnect voting
> capability.
> 
> To add devfreq device for the "gpu-mem" interconnect path:
> icc_create_devfreq(dev, "gpu-mem");
> 
> With the future addition of a "passive_bandwidth" devfreq governor,
> device frequency to interconnect bandwidth mapping would come for free.
> 
> If the feedback on this patch series is positive, I'll then add the
> devfreq passive_bandwidth governor (or something similar) to v2 of this
> patch series.
> 
> So with the DT bindings added in this patch series, the DT for a GPU
> that does bandwidth voting from GPU to Cache and GPU to DDR would look
> something like this:
> 
> gpu_cache_opp_table: gpu_cache_opp_table {
>   compatible = "operating-points-v2";
> 
>   gpu_cache_3000: opp-3000 {
>   opp-peak-KBps = <3000>;
>   opp-avg-KBps = <1000>;
>   };
>   gpu_cache_6000: opp-6000 {
>   opp-peak-KBps = <6000>;
>   opp-avg-KBps = <2000>;
>   };
>   gpu_cache_9000: opp-9000 {
>   opp-peak-KBps = <9000>;
>   opp-avg-KBps = <9000>;
>   };
> };
> 
> gpu_ddr_opp_table: gpu_ddr_opp_table {
>   compatible = "operating-points-v2";
> 
>   gpu_ddr_1525: opp-1525 {
>   opp-peak-KBps = <1525>;
>   opp-avg-KBps = <452>;
>   };
>   gpu_ddr_3051: opp-3051 {
>   opp-peak-KBps = <3051>;
>   opp-avg-KBps = <915>;
>   };
>   gpu_ddr_7500: opp-7500 {
>   opp-peak-KBps = <7500>;
>   opp-avg-KBps = <3000>;
>   };
> };
> 
> gpu_opp_table: gpu_opp_table {
>   compatible = "operating-points-v2";
>   opp-shared;
> 
>   opp-2 {
>   opp-hz = /bits/ 64 <2>;
>   required-opps = <_cache_3000>, <_ddr_1525>;

I still don't see the benefit of the indirection, over just spelling out
the bandwidth values here.

Regards,
Bjorn

>   };
>   opp-4 {
>   opp-hz = /bits/ 64 <4>;
>   required-opps = <_cache_6000>, <_ddr_3051>;
>   };
> };
> 
> gpu@7864000 {
>   ...
>   operating-points-v2 = <_opp_table>, <_cache_opp_table>, 
> <_ddr_opp_table>;
>   interconnects = < MASTER_GPU_1  SLAVE_SYSTEL_CACHE>,
>   < MASTER_GPU_1  SLAVE_DDR>;
>   interconnect-names = "gpu-cache", "gpu-mem";
>   interconnect-opp-table = <_cache_opp_table>, <_ddr_opp_table>
> };
> 
> Cheers,
> Saravana
> 
> [1] - 
> https://lore.kernel.org/lkml/20190601021228.210574-1-sarava...@google.com/
> [2] - 
> https://lore.kernel.org/lkml/20190423132823.7915-1-georgi.dja...@linaro.org/ 
> 
> Saravana Kannan (9):
>   dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings
>   OPP: Add support for bandwidth OPP tables
>   OPP: Add helper function for bandwidth OPP tables
>   OPP: Add API to find an OPP table from its DT node
>   dt-bindings: interconnect: Add interconnect-opp-table property
>   interconnect: Add OPP table support for interconnects
>   OPP: Add function to look up required OPP's for a given OPP
>   OPP: Allow copying OPPs tables between devices
>   interconnect: Add devfreq support
> 
>  .../bindings/interconnect/interconnect.txt|   8 +
>  Documentation/devicetree/bindings/opp/opp.txt |  15 +-
>  drivers/interconnect/Makefile |   2 +-
>  drivers/interconnect/core.c   |  27 +++-
>  drivers/interconnect/icc-devfreq.c| 144 ++
>  drivers/opp/core.c| 109 +
>  drivers/opp/of.c  |  75 +++--
>  drivers/opp/opp.h |   4 +-
>  include/linux/interconnect.h  |  17 +++
>  include/linux/pm_opp.h|  41 +
>  10 files changed, 426 insertions(+), 16 deletions(-)
>  create mode 100644 drivers/interconnect/icc-devfreq.c
> 
> -- 
> 2.22.0.rc2.383.gf4fbbf30c2-goog
> 

Re: [RFC PATCH 00/16] xenhost support

[Ankur Arora]

On 2019-06-07 7:51 a.m., Juergen Gross wrote:

On 09.05.19 19:25, Ankur Arora wrote:

Hi all,

This is an RFC for xenhost support, outlined here by Juergen here:
https://lkml.org/lkml/2019/4/8/67.


First: thanks for all the effort you've put into this series!


The high level idea is to provide an abstraction of the Xen
communication interface, as a xenhost_t.

xenhost_t expose ops for communication between the guest and Xen
(hypercall, cpuid, shared_info/vcpu_info, evtchn, grant-table and on top
of those, xenbus, ballooning), and these can differ based on the kind
of underlying Xen: regular, local, and nested.


I'm not sure we need to abstract away hypercalls and cpuid. I believe in
case of nested Xen all contacts to the L0 hypervisor should be done via
the L1 hypervisor. So we might need to issue some kind of passthrough

Yes, that does make sense. This also allows the L1 hypervisor to
control which hypercalls can be nested.
As for cpuid, what about nested feature discovery such as in
gnttab_need_v2()?
(Though for this particular case, the hypercall should be fine.)


hypercall when e.g. granting a page to L0 dom0, but this should be
handled via the grant abstraction (events should be similar).

So IMO we should drop patches 2-5.

For 3-5, I'd like to prune them to provide a limited hypercall
registration ability -- this is meant to be used for the
xenhost_r0/xenhost_local case.

Ankur




(Since this abstraction is largely about guest -- xenhost communication,
no ops are needed for timer, clock, sched, memory (MMU, P2M), VCPU mgmt.
etc.)

Xenhost use-cases:

Regular-Xen: the standard Xen interface presented to a guest,
specifically for comunication between Lx-guest and Lx-Xen.

Local-Xen: a Xen like interface which runs in the same address space as
the guest (dom0). This, can act as the default xenhost.

The major ways it differs from a regular Xen interface is in presenting
a different hypercall interface (call instead of a syscall/vmcall), and
in an inability to do grant-mappings: since local-Xen exists in the same
address space as Xen, there's no way for it to cheaply change the
physical page that a GFN maps to (assuming no P2M tables.)

Nested-Xen: this channel is to Xen, one level removed: from L1-guest to
L0-Xen. The use case is that we want L0-dom0-backends to talk to
L1-dom0-frontend drivers which can then present PV devices which can
in-turn be used by the L1-dom0-backend drivers as raw underlying devices.
The interfaces themselves, broadly remain similar.

Note: L0-Xen, L1-Xen represent Xen running at that nesting level
and L0-guest, L1-guest represent guests that are children of Xen
at that nesting level. Lx, represents any level.

Patches 1-7,
   "x86/xen: add xenhost_t interface"
   "x86/xen: cpuid support in xenhost_t"
   "x86/xen: make hypercall_page generic"
   "x86/xen: hypercall support for xenhost_t"
   "x86/xen: add feature support in xenhost_t"
   "x86/xen: add shared_info support to xenhost_t"
   "x86/xen: make vcpu_info part of xenhost_t"
abstract out interfaces that setup 
hypercalls/cpuid/shared_info/vcpu_info etc.


Patch 8, "x86/xen: irq/upcall handling with multiple xenhosts"
sets up the upcall and pv_irq ops based on vcpu_info.

Patch 9, "xen/evtchn: support evtchn in xenhost_t" adds xenhost based
evtchn support for evtchn_2l.

Patches 10 and 16, "xen/balloon: support ballooning in xenhost_t" and
"xen/grant-table: host_addr fixup in mapping on xenhost_r0"
implement support from GNTTABOP_map_grant_ref for xenhosts of type
xenhost_r0 (xenhost local.)

Patch 12, "xen/xenbus: support xenbus frontend/backend with xenhost_t"
makes xenbus so that both its frontend and backend can be bootstrapped
separately via separate xenhosts.

Remaining patches, 11, 13, 14, 15:
   "xen/grant-table: make grant-table xenhost aware"
   "drivers/xen: gnttab, evtchn, xenbus API changes"
   "xen/blk: gnttab, evtchn, xenbus API changes"
   "xen/net: gnttab, evtchn, xenbus API changes"
are mostly mechanical changes for APIs that now take xenhost_t *
as parameter.

The code itself is RFC quality, and is mostly meant to get feedback 
before

proceeding further. Also note that the FIFO logic and some Xen drivers
(input, pciback, scsi etc) are mostly unchanged, so will not build.


Please take a look.



Juergen

[PATCH v2] ipc/mqueue: Only perform resource calculation if user valid

[Kees Cook]

Andreas Christoforou reported:

UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow:
9 * 2305843009213693951 cannot be represented in type 'long int'
...
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x11b/0x1fe lib/dump_stack.c:113
 ubsan_epilogue+0xe/0x81 lib/ubsan.c:159
 handle_overflow+0x193/0x218 lib/ubsan.c:190
 mqueue_evict_inode+0x8e7/0xa10 ipc/mqueue.c:414
 evict+0x472/0x8c0 fs/inode.c:558
 iput_final fs/inode.c:1547 [inline]
 iput+0x51d/0x8c0 fs/inode.c:1573
 mqueue_get_inode+0x8eb/0x1070 ipc/mqueue.c:320
 mqueue_create_attr+0x198/0x440 ipc/mqueue.c:459
 vfs_mkobj+0x39e/0x580 fs/namei.c:2892
 prepare_open ipc/mqueue.c:731 [inline]
 do_mq_open+0x6da/0x8e0 ipc/mqueue.c:771
...

Which could be triggered by:

struct mq_attr attr = {
.mq_flags = 0,
.mq_maxmsg = 9,
.mq_msgsize = 0x1fff,
.mq_curmsgs = 0,
};

if (mq_open("/testing", 0x40, 3, ) == (mqd_t) -1)
perror("mq_open");

mqueue_get_inode() was correctly rejecting the giant mq_msgsize,
and preparing to return -EINVAL. During the cleanup, it calls
mqueue_evict_inode() which performed resource usage tracking math for
updating "user", before checking if there was a valid "user" at all
(which would indicate that the calculations would be sane). Instead,
delay this check to after seeing a valid "user".

The overflow was real, but the results went unused, so while the flaw
is harmless, it's noisy for kernel fuzzers, so just fix it by moving
the calculation under the non-NULL "user" where it actually gets used.

Reported-by: Andreas Christoforou 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: "Eric W. Biederman" 
Signed-off-by: Kees Cook 
---
v2: update commit log based on Al's feedback
---
 ipc/mqueue.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/ipc/mqueue.c b/ipc/mqueue.c
index 216cad1ff0d0..65c351564ad0 100644
--- a/ipc/mqueue.c
+++ b/ipc/mqueue.c
@@ -438,7 +438,6 @@ static void mqueue_evict_inode(struct inode *inode)
 {
struct mqueue_inode_info *info;
struct user_struct *user;
-   unsigned long mq_bytes, mq_treesize;
struct ipc_namespace *ipc_ns;
struct msg_msg *msg, *nmsg;
LIST_HEAD(tmp_msg);
@@ -461,16 +460,18 @@ static void mqueue_evict_inode(struct inode *inode)
free_msg(msg);
}
 
-   /* Total amount of bytes accounted for the mqueue */
-   mq_treesize = info->attr.mq_maxmsg * sizeof(struct msg_msg) +
-   min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) *
-   sizeof(struct posix_msg_tree_node);
-
-   mq_bytes = mq_treesize + (info->attr.mq_maxmsg *
- info->attr.mq_msgsize);
-
user = info->user;
if (user) {
+   unsigned long mq_bytes, mq_treesize;
+
+   /* Total amount of bytes accounted for the mqueue */
+   mq_treesize = info->attr.mq_maxmsg * sizeof(struct msg_msg) +
+   min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) *
+   sizeof(struct posix_msg_tree_node);
+
+   mq_bytes = mq_treesize + (info->attr.mq_maxmsg *
+ info->attr.mq_msgsize);
+
spin_lock(_lock);
user->mq_bytes -= mq_bytes;
/*
-- 
2.17.1


-- 
Kees Cook

[PATCH v3 2/3] scsi: ufs-qcom: Implement device_reset vops

[Bjorn Andersson]

The UFS_RESET pin on Qualcomm SoCs are controlled by TLMM and exposed
through the GPIO framework. Acquire the device-reset GPIO and use this
to implement the device_reset vops, to allow resetting the attached
memory.

Based on downstream support implemented by Subhash Jadavani
.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Moved implementation to Qualcomm driver

 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt |  2 ++
 drivers/scsi/ufs/ufs-qcom.c   | 32 +++
 drivers/scsi/ufs/ufs-qcom.h   |  4 +++
 3 files changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index a74720486ee2..d562d8b4919c 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -54,6 +54,8 @@ Optional properties:
  PHY reset from the UFS controller.
 - resets: reset node register
 - reset-names   : describe reset node register, the "rst" corresponds to 
reset the whole UFS IP.
+- device-reset-gpios   : A phandle and gpio specifier denoting the GPIO 
connected
+ to the RESET pin of the UFS memory device.
 
 Note: If above properties are not defined it can be assumed that the supply
 regulators or clocks are always on.
diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index ea7219407309..efaf57ba618a 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "ufshcd.h"
@@ -1141,6 +1142,15 @@ static int ufs_qcom_init(struct ufs_hba *hba)
goto out_variant_clear;
}
 
+   host->device_reset = devm_gpiod_get_optional(dev, "device-reset",
+GPIOD_OUT_HIGH);
+   if (IS_ERR(host->device_reset)) {
+   err = PTR_ERR(host->device_reset);
+   if (err != -EPROBE_DEFER)
+   dev_err(dev, "failed to acquire reset gpio: %d\n", err);
+   goto out_variant_clear;
+   }
+
err = ufs_qcom_bus_register(host);
if (err)
goto out_variant_clear;
@@ -1546,6 +1556,27 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
usleep_range(1000, 1100);
 }
 
+/**
+ * ufs_qcom_device_reset() - toggle the (optional) device reset line
+ * @hba: per-adapter instance
+ *
+ * Toggles the (optional) reset line to reset the attached device.
+ */
+static void ufs_qcom_device_reset(struct ufs_hba *hba)
+{
+   struct ufs_qcom_host *host = ufshcd_get_variant(hba);
+
+   /*
+* The UFS device shall detect reset pulses of 1us, sleep for 10us to
+* be on the safe side.
+*/
+   gpiod_set_value_cansleep(host->device_reset, 1);
+   usleep_range(10, 15);
+
+   gpiod_set_value_cansleep(host->device_reset, 0);
+   usleep_range(10, 15);
+}
+
 /**
  * struct ufs_hba_qcom_vops - UFS QCOM specific variant operations
  *
@@ -1566,6 +1597,7 @@ static struct ufs_hba_variant_ops ufs_hba_qcom_vops = {
.suspend= ufs_qcom_suspend,
.resume = ufs_qcom_resume,
.dbg_register_dump  = ufs_qcom_dump_dbg_regs,
+   .device_reset   = ufs_qcom_device_reset,
 };
 
 /**
diff --git a/drivers/scsi/ufs/ufs-qcom.h b/drivers/scsi/ufs/ufs-qcom.h
index 68a880185752..b96ffb6804e4 100644
--- a/drivers/scsi/ufs/ufs-qcom.h
+++ b/drivers/scsi/ufs/ufs-qcom.h
@@ -204,6 +204,8 @@ struct ufs_qcom_testbus {
u8 select_minor;
 };
 
+struct gpio_desc;
+
 struct ufs_qcom_host {
/*
 * Set this capability if host controller supports the QUniPro mode
@@ -241,6 +243,8 @@ struct ufs_qcom_host {
struct ufs_qcom_testbus testbus;
 
struct reset_controller_dev rcdev;
+
+   struct gpio_desc *device_reset;
 };
 
 static inline u32
-- 
2.18.0

[PATCH v3 0/3] Qualcomm UFS device reset support

[Bjorn Andersson]

This series adds a new ufs vops to allow platform specific methods for
resetting an attached UFS device, then implements this for the Qualcomm driver.

Bjorn Andersson (3):
  scsi: ufs: Introduce vops for resetting device
  scsi: ufs-qcom: Implement device_reset vops
  arm64: dts: qcom: sdm845-mtp: Specify UFS device-reset GPIO

 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt |  2 ++
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts   |  2 ++
 drivers/scsi/ufs/ufs-qcom.c   | 32 +++
 drivers/scsi/ufs/ufs-qcom.h   |  4 +++
 drivers/scsi/ufs/ufshcd.c |  6 
 drivers/scsi/ufs/ufshcd.h |  8 +
 6 files changed, 54 insertions(+)

-- 
2.18.0

[PATCH v3 1/3] scsi: ufs: Introduce vops for resetting device

[Bjorn Andersson]

Some UFS memory devices needs their reset line toggled in order to get
them into a good state for initialization. Provide a new vops to allow
the platform driver to implement this operation.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New patch, to allow moving implementation to platform driver

 drivers/scsi/ufs/ufshcd.c | 6 ++
 drivers/scsi/ufs/ufshcd.h | 8 
 2 files changed, 14 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 04d3686511c8..ee895a625456 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6191,6 +6191,9 @@ static int ufshcd_reset_and_restore(struct ufs_hba *hba)
int retries = MAX_HOST_RESET_RETRIES;
 
do {
+   /* Reset the attached device */
+   ufshcd_vops_device_reset(hba);
+
err = ufshcd_host_reset_and_restore(hba);
} while (err && --retries);
 
@@ -8322,6 +8325,9 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
goto exit_gating;
}
 
+   /* Reset the attached device */
+   ufshcd_vops_device_reset(hba);
+
/* Host controller enable */
err = ufshcd_hba_enable(hba);
if (err) {
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 994d73d03207..cd8139052ed6 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -298,6 +298,7 @@ struct ufs_pwr_mode_info {
  * @resume: called during host controller PM callback
  * @dbg_register_dump: used to dump controller debug information
  * @phy_initialization: used to initialize phys
+ * @device_reset: called to issue a reset pulse on the UFS device
  */
 struct ufs_hba_variant_ops {
const char *name;
@@ -326,6 +327,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
+   void(*device_reset)(struct ufs_hba *);
 };
 
 /* clock gating state  */
@@ -1045,6 +1047,12 @@ static inline void ufshcd_vops_dbg_register_dump(struct 
ufs_hba *hba)
hba->vops->dbg_register_dump(hba);
 }
 
+static inline void ufshcd_vops_device_reset(struct ufs_hba *hba)
+{
+   if (hba->vops && hba->vops->device_reset)
+   hba->vops->device_reset(hba);
+}
+
 extern struct ufs_pm_lvl_states ufs_pm_lvl_states[];
 
 /*
-- 
2.18.0

[PATCH v3 3/3] arm64: dts: qcom: sdm845-mtp: Specify UFS device-reset GPIO

[Bjorn Andersson]

Specify the UFS device-reset gpio, so that the controller will issue a
reset of the UFS device.

Reviewed-by: Linus Walleij 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

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

diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts 
b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 80189807b4e5..441045847e9f 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -467,6 +467,8 @@
 _mem_hc {
status = "okay";
 
+   device-reset-gpios = < 150 GPIO_ACTIVE_LOW>;
+
vcc-supply = <_l20a_2p95>;
vcc-max-microamp = <60>;
 };
-- 
2.18.0

Re: [RFC PATCH 06/16] x86/xen: add shared_info support to xenhost_t

[Ankur Arora]

On 2019-06-07 8:08 a.m., Juergen Gross wrote:

On 09.05.19 19:25, Ankur Arora wrote:

HYPERVISOR_shared_info is used for irq/evtchn communication between the
guest and the host. Abstract out the setup/reset in xenhost_t such that
nested configurations can use both xenhosts simultaneously.


I have mixed feelings about this patch. Most of the shared_info stuff we
don't need for the nested case. In the end only the event channels might
be interesting, but we obviously want them not for all vcpus of the L1
hypervisor, but for those of the current guest.

Agreed about the mixed feelings part. shared_info does feel far too
heavy to drag along just for the event-channel state.
Infact, on thinking a bit more, a better abstraction for nested
event-channels would have been as an extension to the primary
xenhost's event-channel bits.
(The nested upcalls also go via the primary xenhost in patch-8.)

Ankur



So I think just drop that patch for now. We can dig it out later in case > 
nesting wants it again.


Juergen

Targeted Individuals Get Fired from Employment/Jobs Frequently or All the Time

[Turritopsis Dohrnii Teo En Ming]

Subject/Topic: Targeted Individuals Get Fired from Employment/Jobs
Frequently or All the Time

8th JUNE 2019 Saturday Singapore Time

There are (perhaps) millions of Targeted Individuals in (perhaps)
every country all over the world.

According to accounts and experiences shared by many Targeted
Individuals all over the world, it is INEVITABLE for Targeted
Individuals to get fired from employment/jobs frequently or all the
time. Getting fired from employment/jobs frequently or all the time is
part and parcel of the targeting program. You should expect it.

As at 8th June 2019 Saturday Singapore Time, Mr. Turritopsis Dohrnii
Teo En Ming is 41 years old.

Mr. Turritopsis Dohrnii Teo En Ming is a TARGETED INDIVIDUAL (TI) in Singapore.

-BEGIN EMAIL SIGNATURE-

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link: 
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html



Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic
Qualifications as at 14 Feb 2019

[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-END EMAIL SIGNATURE-

Msg **

[schoolint]

Dear friend,
With all due respect, my name is barr. Amboline Hills,personal attorney to late 
Engineer J.B. I am contacting you on behalf of my deceased client who is a 
national of your country who  was assassinated  in 2013 with his wife and their 
only child.Since the funds was left in open beneficiary status and there is 
noliving relative to claim the funds,i am contacting you to stand as the 
beneficiary/next of kin to his deposit (nine  Million four hundred thousand 
United States Dollars ) which he made with a bank here before his sudden death. 
After successful transfer of funds to your account,we shall share it 50/50%.
Contact me on my private email (  amboline.hi...@gmail.com  )for more details.
Yours sincerely
Barr.Amboline Hills

[PATCH v1 6/9] interconnect: Add OPP table support for interconnects

[Saravana Kannan]

Interconnect paths can have different performance points. Now that OPP
framework supports bandwidth OPP tables, add OPP table support for
interconnects.

Devices can use the interconnect-opp-table DT property to specify OPP
tables for interconnect paths. And the driver can obtain the OPP table for
an interconnect path by calling icc_get_opp_table().

Signed-off-by: Saravana Kannan 
---
 drivers/interconnect/core.c  | 27 ++-
 include/linux/interconnect.h |  7 +++
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 871eb4bc4efc..881bac80bc1e 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -47,6 +47,7 @@ struct icc_req {
  */
 struct icc_path {
size_t num_nodes;
+   struct opp_table *opp_table;
struct icc_req reqs[];
 };
 
@@ -313,7 +314,7 @@ struct icc_path *of_icc_get(struct device *dev, const char 
*name)
 {
struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
struct icc_node *src_node, *dst_node;
-   struct device_node *np = NULL;
+   struct device_node *np = NULL, *opp_node;
struct of_phandle_args src_args, dst_args;
int idx = 0;
int ret;
@@ -381,10 +382,34 @@ struct icc_path *of_icc_get(struct device *dev, const 
char *name)
dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
mutex_unlock(_lock);
 
+   opp_node = of_parse_phandle(np, "interconnect-opp-table", idx);
+   if (opp_node) {
+   path->opp_table = dev_pm_opp_of_find_table_from_node(opp_node);
+   of_node_put(opp_node);
+   }
+
+
return path;
 }
 EXPORT_SYMBOL_GPL(of_icc_get);
 
+/**
+ * icc_get_opp_table() - Get the OPP table that corresponds to a path
+ * @path: reference to the path returned by icc_get()
+ *
+ * This function will return the OPP table that corresponds to a path handle.
+ * If the interconnect API is disabled, NULL is returned and the consumer
+ * drivers will still build. Drivers are free to handle this specifically, but
+ * they don't have to.
+ *
+ * Return: opp_table pointer on success. NULL is returned when the API is
+ * disabled or the OPP table is missing.
+ */
+struct opp_table *icc_get_opp_table(struct icc_path *path)
+{
+   return path->opp_table;
+}
+
 /**
  * icc_set_bw() - set bandwidth constraints on an interconnect path
  * @path: reference to the path returned by icc_get()
diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
index dc25864755ba..0c0bc55f0e89 100644
--- a/include/linux/interconnect.h
+++ b/include/linux/interconnect.h
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 /* macros for converting to icc units */
 #define Bps_to_icc(x)  ((x) / 1000)
@@ -28,6 +29,7 @@ struct device;
 struct icc_path *icc_get(struct device *dev, const int src_id,
 const int dst_id);
 struct icc_path *of_icc_get(struct device *dev, const char *name);
+struct opp_table *icc_get_opp_table(struct icc_path *path);
 void icc_put(struct icc_path *path);
 int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
 
@@ -49,6 +51,11 @@ static inline void icc_put(struct icc_path *path)
 {
 }
 
+static inline struct opp_table *icc_get_opp_table(struct icc_path *path)
+{
+   return NULL;
+}
+
 static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
 {
return 0;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v1 3/9] OPP: Add helper function for bandwidth OPP tables

[Saravana Kannan]

The frequency OPP tables have helper functions to search for entries in the
table based on frequency and get the frequency values for a given (or
suspend) OPP entry.

Add similar helper functions for bandwidth OPP tables to search for entries
in the table based on peak bandwidth and to get the peak and average
bandwidth for a given (or suspend) OPP entry.

Signed-off-by: Saravana Kannan 
---
 drivers/opp/core.c | 51 ++
 include/linux/pm_opp.h | 19 
 2 files changed, 70 insertions(+)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0e7703fe733f..89a2ece88480 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -130,6 +130,29 @@ unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq);
 
+/**
+ * dev_pm_opp_get_bw() - Gets the bandwidth corresponding to an available opp
+ * @opp:   opp for which frequency has to be returned for
+ * @avg_bw:Pointer where the corresponding average bandwidth is stored.
+ * Can be NULL.
+ *
+ * Return: Peak bandwidth in KBps corresponding to the opp, else
+ * return 0
+ */
+unsigned long dev_pm_opp_get_bw(struct dev_pm_opp *opp, unsigned long *avg_bw)
+{
+   if (IS_ERR_OR_NULL(opp) || !opp->available) {
+   pr_err("%s: Invalid parameters\n", __func__);
+   return 0;
+   }
+
+   if (avg_bw)
+   avg_bw = opp->avg_bw;
+
+   return opp->rate;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_bw);
+
 /**
  * dev_pm_opp_get_level() - Gets the level corresponding to an available opp
  * @opp:   opp for which level value has to be returned for
@@ -302,6 +325,34 @@ unsigned long dev_pm_opp_get_suspend_opp_freq(struct 
device *dev)
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_get_suspend_opp_freq);
 
+/**
+ * dev_pm_opp_get_suspend_opp_bw() - Get peak bandwidth of suspend opp in KBps
+ * @dev:   device for which we do this operation
+ * @avg_bw:Pointer where the corresponding average bandwidth is stored.
+ * Can be NULL.
+ *
+ * Return: This function returns the peak bandwidth of the OPP marked as
+ * suspend_opp if one is available, else returns 0;
+ */
+unsigned long dev_pm_opp_get_suspend_opp_bw(struct device *dev,
+   unsigned long avg_bw)
+{
+   struct opp_table *opp_table;
+   unsigned long peak_bw = 0;
+
+   opp_table = _find_opp_table(dev);
+   if (IS_ERR(opp_table))
+   return 0;
+
+   if (opp_table->suspend_opp && opp_table->suspend_opp->available)
+   peak_bw = dev_pm_opp_get_bw(opp_table->suspend_opp, avg_bw);
+
+   dev_pm_opp_put_opp_table(opp_table);
+
+   return peak_bw;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_suspend_opp_bw);
+
 int _get_opp_count(struct opp_table *opp_table)
 {
struct dev_pm_opp *opp;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index b150fe97ce5a..7f040cc20daf 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -85,6 +85,7 @@ void dev_pm_opp_put_opp_table(struct opp_table *opp_table);
 unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp);
 
 unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp);
+unsigned long dev_pm_opp_get_bw(struct dev_pm_opp *opp, unsigned long *avg_bw);
 
 unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp);
 
@@ -95,6 +96,8 @@ unsigned long dev_pm_opp_get_max_clock_latency(struct device 
*dev);
 unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev);
 unsigned long dev_pm_opp_get_max_transition_latency(struct device *dev);
 unsigned long dev_pm_opp_get_suspend_opp_freq(struct device *dev);
+unsigned long dev_pm_opp_get_suspend_opp_bw(struct device *dev,
+   unsigned long avg_bw);
 
 struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
  unsigned long freq,
@@ -161,6 +164,11 @@ static inline unsigned long dev_pm_opp_get_freq(struct 
dev_pm_opp *opp)
 {
return 0;
 }
+static inline unsigned long dev_pm_opp_get_bw(struct dev_pm_opp *opp,
+ unsigned long avg_bw)
+{
+   return 0;
+}
 
 static inline unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp)
 {
@@ -197,6 +205,12 @@ static inline unsigned long 
dev_pm_opp_get_suspend_opp_freq(struct device *dev)
return 0;
 }
 
+static inline unsigned long dev_pm_opp_get_suspend_opp_bw(struct device *dev,
+ unsigned long avg_bw)
+{
+   return 0;
+}
+
 static inline struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
unsigned long freq, bool available)
 {
@@ -332,6 +346,11 @@ static inline void dev_pm_opp_cpumask_remove_table(const 
struct cpumask *cpumask
 
 #endif /* CONFIG_PM_OPP */
 
+#define dev_pm_opp_find_peak_bw_exact  dev_pm_opp_find_freq_exact
+#define 

[PATCH v1 5/9] dt-bindings: interconnect: Add interconnect-opp-table property

[Saravana Kannan]

Add support for listing bandwidth OPP tables for each interconnect path
listed using the interconnects property.

Signed-off-by: Saravana Kannan 
---
 .../devicetree/bindings/interconnect/interconnect.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt 
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 6f5d23a605b7..fc5b75b76a2c 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -55,10 +55,18 @@ interconnect-names : List of interconnect path name strings 
sorted in the same
 * dma-mem: Path from the device to the main memory of
the system
 
+interconnect-opp-table: List of phandles to OPP tables (bandwidth OPP tables)
+   that specify the OPPs for the interconnect paths listed
+   in the interconnects property. This property can only
+   point to OPP tables that belong to the device and are
+   listed in the device's operating-points-v2 property.
+
 Example:
 
sdhci@7864000 {
+   operating-points-v2 = <_opp_table>, <_mem_opp_table>;
...
interconnects = < MASTER_SDCC_1  SLAVE_EBI_CH0>;
interconnect-names = "sdhc-mem";
+   interconnect-opp-table = <_mem_opp_table>;
};
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v1 8/9] OPP: Allow copying OPPs tables between devices

[Saravana Kannan]

Some hardware devices might create multiple children devices to manage
different components of the hardware. In these cases, it might be necessary
for the original hardware device to copy specific OPP tables to a specific
the new child device. Add dev_pm_opp_add_opp_table() to do that.

Signed-off-by: Saravana Kannan 
---
 drivers/opp/core.c | 8 
 include/linux/pm_opp.h | 7 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index d96d5746eb47..9d49aee2c3ef 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -943,6 +943,14 @@ struct opp_device *_add_opp_dev(const struct device *dev,
return opp_dev;
 }
 
+int dev_pm_opp_add_opp_table(struct device *dev, struct opp_table *opp_table)
+{
+   if (!dev || !opp_table)
+   return -EINVAL;
+
+   return _add_opp_dev(dev, opp_table) ? 0 : -ENOMEM;
+}
+
 static struct opp_table *_allocate_opp_table(struct device *dev, int index)
 {
struct opp_table *opp_table;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 13381dc3dd39..31acc617fda3 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -81,6 +81,7 @@ struct dev_pm_set_opp_data {
 struct opp_table *dev_pm_opp_get_opp_table(struct device *dev);
 struct opp_table *dev_pm_opp_get_opp_table_indexed(struct device *dev, int 
index);
 void dev_pm_opp_put_opp_table(struct opp_table *opp_table);
+int dev_pm_opp_add_opp_table(struct device *dev, struct opp_table *opp_table);
 
 unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp);
 
@@ -158,6 +159,12 @@ static inline struct opp_table 
*dev_pm_opp_get_opp_table_indexed(struct device *
 
 static inline void dev_pm_opp_put_opp_table(struct opp_table *opp_table) {}
 
+static int dev_pm_opp_add_opp_table(struct device *dev,
+   struct opp_table *opp_table)
+{
+   return -ENOTSUPP;
+}
+
 static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
 {
return 0;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v1 2/9] OPP: Add support for bandwidth OPP tables

[Saravana Kannan]

Not all devices quantify their performance points in terms of frequency.
Devices like interconnects quantify their performance points in terms of
bandwidth. We need a way to represent these bandwidth levels in OPP. So,
add support for parsing bandwidth OPPs from DT.

Signed-off-by: Saravana Kannan 
---
 drivers/opp/of.c  | 34 --
 drivers/opp/opp.h |  4 +++-
 2 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index c10c782d15aa..54fa70ed2adc 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -552,6 +552,35 @@ void dev_pm_opp_of_remove_table(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
 
+static int _read_opp_key(struct dev_pm_opp *new_opp, struct device_node *np)
+{
+   int ret;
+   u64 rate;
+   u32 bw;
+
+   ret = of_property_read_u64(np, "opp-hz", );
+   if (!ret) {
+   /*
+* Rate is defined as an unsigned long in clk API, and so
+* casting explicitly to its type. Must be fixed once rate is 64
+* bit guaranteed in clk API.
+*/
+   new_opp->rate = (unsigned long)rate;
+   return 0;
+   }
+
+   ret = of_property_read_u32(np, "opp-peak-KBps", );
+   if (ret)
+   return ret;
+   new_opp->rate = (unsigned long) 
+
+   ret = of_property_read_u32(np, "opp-avg-KBps", );
+   if (!ret)
+   new_opp->avg_bw = (unsigned long) 
+
+   return 0;
+}
+
 /**
  * _opp_add_static_v2() - Allocate static OPPs (As per 'v2' DT bindings)
  * @opp_table: OPP table
@@ -589,11 +618,12 @@ static struct dev_pm_opp *_opp_add_static_v2(struct 
opp_table *opp_table,
if (!new_opp)
return ERR_PTR(-ENOMEM);
 
-   ret = of_property_read_u64(np, "opp-hz", );
+   ret = _read_opp_key(new_opp, np);
if (ret < 0) {
/* "opp-hz" is optional for devices like power domains. */
if (!opp_table->is_genpd) {
-   dev_err(dev, "%s: opp-hz not found\n", __func__);
+   dev_err(dev, "%s: opp-hz or opp-peak-bw not found\n",
+   __func__);
goto free_opp;
}
 
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index 569b3525aa67..ead2cdafe957 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -59,7 +59,8 @@ extern struct list_head opp_tables;
  * @turbo: true if turbo (boost) OPP
  * @suspend:   true if suspend OPP
  * @pstate: Device's power domain's performance state.
- * @rate:  Frequency in hertz
+ * @rate:  Frequency in hertz OR Peak bandwidth in kilobytes per second
+ * @avg_bw:Average bandwidth in kilobytes per second
  * @level: Performance level
  * @supplies:  Power supplies voltage/current values
  * @clock_latency_ns: Latency (in nanoseconds) of switching to this OPP's
@@ -81,6 +82,7 @@ struct dev_pm_opp {
bool suspend;
unsigned int pstate;
unsigned long rate;
+   unsigned long avg_bw;
unsigned int level;
 
struct dev_pm_opp_supply *supplies;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v1 9/9] interconnect: Add devfreq support

[Saravana Kannan]

Add a icc_create_devfreq() and icc_remove_devfreq() to create and remove
devfreq devices for interconnect paths. A driver can create/remove devfreq
devices for the interconnects needed for its device by calling these APIs.
This would allow various devfreq governors to work with interconnect paths
and the device driver itself doesn't have to actively manage the bandwidth
votes for the interconnects.

Signed-off-by: Saravana Kannan 
---
 drivers/interconnect/Makefile  |   2 +-
 drivers/interconnect/icc-devfreq.c | 145 +
 include/linux/interconnect.h   |  11 +++
 3 files changed, 157 insertions(+), 1 deletion(-)
 create mode 100644 drivers/interconnect/icc-devfreq.c

diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 28f2ab0824d5..ddfb65b7fa55 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 
-icc-core-objs  := core.o
+icc-core-objs  := core.o icc-devfreq.o
 
 obj-$(CONFIG_INTERCONNECT) += icc-core.o
 obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
diff --git a/drivers/interconnect/icc-devfreq.c 
b/drivers/interconnect/icc-devfreq.c
new file mode 100644
index ..f88b267d281e
--- /dev/null
+++ b/drivers/interconnect/icc-devfreq.c
@@ -0,0 +1,145 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * A devfreq device driver for interconnect paths
+ *
+ * Copyright (C) 2019 Google, Inc
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct icc_devfreq {
+   struct device icc_dev;
+   struct icc_path *path;
+   struct devfreq_dev_profile dp;
+   struct devfreq *df;
+   unsigned long peak_bw;
+   unsigned long avg_bw;
+};
+
+static int icc_target(struct device *dev, unsigned long *freq,
+   u32 flags)
+{
+   struct icc_devfreq *d = dev_get_drvdata(dev);
+   struct dev_pm_opp *opp;
+   unsigned long peak_bw, avg_bw;
+
+   opp = devfreq_recommended_opp(dev, _bw, flags);
+   if (IS_ERR(opp)) {
+   dev_err(dev, "Failed to find opp for %lu KHz\n", *freq);
+   return PTR_ERR(opp);
+   }
+   peak_bw = dev_pm_opp_get_bw(opp, _bw);
+   dev_pm_opp_put(opp);
+
+   if (!icc_set_bw(d->path, avg_bw, peak_bw)) {
+   *freq = peak_bw;
+   d->peak_bw = peak_bw;
+   d->avg_bw = avg_bw;
+   }
+
+   return 0;
+}
+
+static int icc_get_dev_status(struct device *dev,
+   struct devfreq_dev_status *stat)
+{
+   struct icc_devfreq *d = dev_get_drvdata(dev);
+
+   stat->current_frequency = d->peak_bw;
+   return 0;
+}
+
+#define icc_dev_to_data(DEV)   container_of((DEV), struct icc_devfreq, icc_dev)
+static void icc_dev_release(struct device *dev)
+{
+   struct icc_devfreq *d = icc_dev_to_data(dev);
+
+   kfree(d);
+}
+
+struct icc_devfreq *icc_create_devfreq(struct device *dev, char *name)
+{
+   struct icc_devfreq *d;
+   struct icc_path *path;
+   struct opp_table *opp_table;
+   struct dev_pm_opp *opp;
+   unsigned long peak_bw = U32_MAX, avg_bw = U32_MAX;
+   int err;
+
+   if (!name)
+   return ERR_PTR(-EINVAL);
+
+   path = of_icc_get(dev, name);
+   if (IS_ERR(path))
+   return (void *) path;
+
+   opp_table = icc_get_opp_table(path);
+   if (!opp_table) {
+   err = -EINVAL;
+   goto out_path;
+   }
+
+   d = kzalloc(sizeof(*d), GFP_KERNEL);
+   if (!d) {
+   err = -ENOMEM;
+   goto out_path;
+   }
+   d->path = path;
+
+   d->icc_dev.parent = dev;
+   d->icc_dev.release = icc_dev_release;
+   dev_set_name(>icc_dev, "%s-icc-%s", dev_name(dev), name);
+   err = device_register(>icc_dev);
+   if (err) {
+   put_device(>icc_dev);
+   goto out_path;
+   }
+
+   dev_pm_opp_add_opp_table(>icc_dev, opp_table);
+   opp = dev_pm_opp_find_peak_bw_floor(dev, _bw);
+   peak_bw = dev_pm_opp_get_bw(opp, _bw);
+   dev_pm_opp_put(opp);
+
+   if (!icc_set_bw(d->path, avg_bw, peak_bw)) {
+   d->peak_bw = peak_bw;
+   d->avg_bw = avg_bw;
+   }
+
+   d->dp.initial_freq = peak_bw;
+   d->dp.polling_ms = 0;
+   d->dp.target = icc_target;
+   d->dp.get_dev_status = icc_get_dev_status;
+   d->df = devm_devfreq_add_device(>icc_dev,
+   >dp,
+   "performance",
+   NULL);
+   if (IS_ERR(d->df)) {
+   err = PTR_ERR(d->df);
+   goto out_dev;
+   }
+
+   return d;
+out_dev:
+   put_device(>icc_dev);
+out_path:
+   icc_put(path);
+   return ERR_PTR(err);
+}

[PATCH v1 7/9] OPP: Add function to look up required OPP's for a given OPP

[Saravana Kannan]

Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.

Signed-off-by: Saravana Kannan 
---
 drivers/opp/core.c | 50 ++
 include/linux/pm_opp.h | 11 ++
 2 files changed, 61 insertions(+)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 89a2ece88480..d96d5746eb47 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1881,6 +1881,56 @@ void dev_pm_opp_put_genpd_virt_dev(struct opp_table 
*opp_table,
dev_err(virt_dev, "Failed to find required device entry\n");
 }
 
+/**
+ * dev_pm_opp_xlate_opp() - Find required OPP for src_table OPP.
+ * @src_table: OPP table which has dst_table as one of its required OPP table.
+ * @dst_table: Required OPP table of the src_table.
+ * @pstate: OPP of the src_table.
+ *
+ * This function returns the OPP (present in @dst_table) pointed out by the
+ * "required-opps" property of the OPP (present in @src_table).
+ *
+ * Return: destination table OPP on success, otherwise NULL on errors.
+ */
+struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
+   struct opp_table *dst_table,
+   struct dev_pm_opp *src_opp)
+{
+   struct dev_pm_opp *opp, *dest_opp = NULL;
+   int i;
+
+   if (!src_table || !dst_table || !src_opp)
+   return NULL;
+
+   for (i = 0; i < src_table->required_opp_count; i++) {
+   if (src_table->required_opp_tables[i]->np == dst_table->np)
+   break;
+   }
+
+   if (unlikely(i == src_table->required_opp_count)) {
+   pr_err("%s: Couldn't find matching OPP table (%p: %p)\n",
+  __func__, src_table, dst_table);
+   return NULL;
+   }
+
+   mutex_lock(_table->lock);
+
+   list_for_each_entry(opp, _table->opp_list, node) {
+   if (opp == src_opp) {
+   dest_opp = opp->required_opps[i];
+   goto unlock;
+   }
+   }
+
+   pr_err("%s: Couldn't find matching OPP (%p: %p)\n", __func__, src_table,
+  dst_table);
+
+unlock:
+   mutex_unlock(_table->lock);
+
+   return dest_opp;
+}
+
 /**
  * dev_pm_opp_xlate_performance_state() - Find required OPP's pstate for 
src_table.
  * @src_table: OPP table which has dst_table as one of its required OPP table.
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 3f30ce55e8eb..13381dc3dd39 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -137,6 +137,9 @@ void dev_pm_opp_unregister_set_opp_helper(struct opp_table 
*opp_table);
 struct opp_table *dev_pm_opp_set_genpd_virt_dev(struct device *dev, struct 
device *virt_dev, int index);
 void dev_pm_opp_put_genpd_virt_dev(struct opp_table *opp_table, struct device 
*virt_dev);
 int dev_pm_opp_xlate_performance_state(struct opp_table *src_table, struct 
opp_table *dst_table, unsigned int pstate);
+struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
+   struct opp_table *dst_table,
+   struct dev_pm_opp *src_opp);
 int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq);
 int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, const struct cpumask 
*cpumask);
 int dev_pm_opp_get_sharing_cpus(struct device *cpu_dev, struct cpumask 
*cpumask);
@@ -321,6 +324,14 @@ static inline int 
dev_pm_opp_xlate_performance_state(struct opp_table *src_table
return -ENOTSUPP;
 }
 
+static inline struct dev_pm_opp *dev_pm_opp_xlate_opp(
+   struct opp_table *src_table,
+   struct opp_table *dst_table,
+   struct dev_pm_opp *src_opp)
+{
+   return NULL;
+}
+
 static inline int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
 {
return -ENOTSUPP;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v1 0/9] Introduce Bandwidth OPPs & interconnect devfreq driver

[Saravana Kannan]

I replied[1] to this patch series[2] and described how I think interconnect
bandwidth voting should be captured in DT and how it should work.

So sending out a patch series implementing that. This patch series does the
following:
- Adds Bandwidth OPP table support (this adds device freq to bandwidth
  mapping for free)
- Adds a devfreq library for interconnect paths

Interconnects and interconnect paths quantify they performance levels in
terms of bandwidth. So similar to how we have frequency based OPP tables
in DT and in the OPP framework, this patch series adds bandwidth OPP
table support in the OPP framework and in DT.

To simplify voting for interconnects, this patch series adds helper
functions to create devfreq devices out of interconnect paths. This
allows drivers to add a single line of code to add interconnect voting
capability.

To add devfreq device for the "gpu-mem" interconnect path:
icc_create_devfreq(dev, "gpu-mem");

With the future addition of a "passive_bandwidth" devfreq governor,
device frequency to interconnect bandwidth mapping would come for free.

If the feedback on this patch series is positive, I'll then add the
devfreq passive_bandwidth governor (or something similar) to v2 of this
patch series.

So with the DT bindings added in this patch series, the DT for a GPU
that does bandwidth voting from GPU to Cache and GPU to DDR would look
something like this:

gpu_cache_opp_table: gpu_cache_opp_table {
compatible = "operating-points-v2";

gpu_cache_3000: opp-3000 {
opp-peak-KBps = <3000>;
opp-avg-KBps = <1000>;
};
gpu_cache_6000: opp-6000 {
opp-peak-KBps = <6000>;
opp-avg-KBps = <2000>;
};
gpu_cache_9000: opp-9000 {
opp-peak-KBps = <9000>;
opp-avg-KBps = <9000>;
};
};

gpu_ddr_opp_table: gpu_ddr_opp_table {
compatible = "operating-points-v2";

gpu_ddr_1525: opp-1525 {
opp-peak-KBps = <1525>;
opp-avg-KBps = <452>;
};
gpu_ddr_3051: opp-3051 {
opp-peak-KBps = <3051>;
opp-avg-KBps = <915>;
};
gpu_ddr_7500: opp-7500 {
opp-peak-KBps = <7500>;
opp-avg-KBps = <3000>;
};
};

gpu_opp_table: gpu_opp_table {
compatible = "operating-points-v2";
opp-shared;

opp-2 {
opp-hz = /bits/ 64 <2>;
required-opps = <_cache_3000>, <_ddr_1525>;
};
opp-4 {
opp-hz = /bits/ 64 <4>;
required-opps = <_cache_6000>, <_ddr_3051>;
};
};

gpu@7864000 {
...
operating-points-v2 = <_opp_table>, <_cache_opp_table>, 
<_ddr_opp_table>;
interconnects = < MASTER_GPU_1  SLAVE_SYSTEL_CACHE>,
< MASTER_GPU_1  SLAVE_DDR>;
interconnect-names = "gpu-cache", "gpu-mem";
interconnect-opp-table = <_cache_opp_table>, <_ddr_opp_table>
};

Cheers,
Saravana

[1] - https://lore.kernel.org/lkml/20190601021228.210574-1-sarava...@google.com/
[2] - 
https://lore.kernel.org/lkml/20190423132823.7915-1-georgi.dja...@linaro.org/ 

Saravana Kannan (9):
  dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings
  OPP: Add support for bandwidth OPP tables
  OPP: Add helper function for bandwidth OPP tables
  OPP: Add API to find an OPP table from its DT node
  dt-bindings: interconnect: Add interconnect-opp-table property
  interconnect: Add OPP table support for interconnects
  OPP: Add function to look up required OPP's for a given OPP
  OPP: Allow copying OPPs tables between devices
  interconnect: Add devfreq support

 .../bindings/interconnect/interconnect.txt|   8 +
 Documentation/devicetree/bindings/opp/opp.txt |  15 +-
 drivers/interconnect/Makefile |   2 +-
 drivers/interconnect/core.c   |  27 +++-
 drivers/interconnect/icc-devfreq.c| 144 ++
 drivers/opp/core.c| 109 +
 drivers/opp/of.c  |  75 +++--
 drivers/opp/opp.h |   4 +-
 include/linux/interconnect.h  |  17 +++
 include/linux/pm_opp.h|  41 +
 10 files changed, 426 insertions(+), 16 deletions(-)
 create mode 100644 drivers/interconnect/icc-devfreq.c

-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v1 1/9] dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings

[Saravana Kannan]

Interconnects often quantify their performance points in terms of
bandwidth. So, add opp-peak-KBps (required) and opp-avg-KBps (optional) to
allow specifying Bandwidth OPP tables in DT.

opp-peak-KBps is a required property that replace opp-hz for Bandwidth OPP
tables.

opp-avg-KBps is an optional property that can be used in Bandwidth OPP
tables.

Signed-off-by: Saravana Kannan 
---
 Documentation/devicetree/bindings/opp/opp.txt | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
b/Documentation/devicetree/bindings/opp/opp.txt
index 76b6c79604a5..c869e87caa2a 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -83,9 +83,14 @@ properties.
 
 Required properties:
 - opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. This is a
-  required property for all device nodes but devices like power domains. The
-  power domain nodes must have another (implementation dependent) property 
which
-  uniquely identifies the OPP nodes.
+  required property for all device nodes but for devices like power domains or
+  bandwidth opp tables. The power domain nodes must have another 
(implementation
+  dependent) property which uniquely identifies the OPP nodes. The interconnect
+  opps are required to have the opp-peak-bw property.
+
+- opp-peak-KBps: Peak bandwidth in kilobytes per second, expressed as a 32-bit
+  big-endian integer. This is a required property for all devices that don't
+  have opp-hz. For example, bandwidth OPP tables for interconnect paths.
 
 Optional properties:
 - opp-microvolt: voltage in micro Volts.
@@ -132,6 +137,10 @@ Optional properties:
 - opp-level: A value representing the performance level of the device,
   expressed as a 32-bit integer.
 
+- opp-avg-KBps: Average bandwidth in kilobytes per second, expressed as a
+  32-bit big-endian integer. This property is only meaningful in OPP tables
+  where opp-peak-KBps is present.
+
 - clock-latency-ns: Specifies the maximum possible transition latency (in
   nanoseconds) for switching to this OPP from any other OPP.
 
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v1 4/9] OPP: Add API to find an OPP table from its DT node

[Saravana Kannan]

This allows finding a device's OPP table (when it has multiple) from a
phandle to the OPP table in DT.

Signed-off-by: Saravana Kannan 
---
 drivers/opp/of.c   | 42 ++
 include/linux/pm_opp.h |  7 +++
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 54fa70ed2adc..34c51905f56d 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -42,14 +42,9 @@ struct device_node *dev_pm_opp_of_get_opp_desc_node(struct 
device *dev)
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_of_get_opp_desc_node);
 
-struct opp_table *_managed_opp(struct device *dev, int index)
+struct opp_table *_find_opp_table_from_node(struct device_node *np)
 {
struct opp_table *opp_table, *managed_table = NULL;
-   struct device_node *np;
-
-   np = _opp_of_get_opp_desc_node(dev->of_node, index);
-   if (!np)
-   return NULL;
 
list_for_each_entry(opp_table, _tables, node) {
if (opp_table->np == np) {
@@ -69,11 +64,42 @@ struct opp_table *_managed_opp(struct device *dev, int 
index)
}
}
 
-   of_node_put(np);
-
return managed_table;
 }
 
+/**
+ * dev_pm_opp_of_find_table_from_node() - Find OPP table from its DT node
+ * @np: DT node used for finding the OPP table
+ *
+ * Return: OPP table corresponding to the DT node, else NULL on failure.
+ *
+ * The caller needs to put the node with of_node_put() after using it.
+ */
+struct opp_table *dev_pm_opp_of_find_table_from_node(struct device_node *np)
+{
+   struct opp_table *opp_table;
+
+   mutex_lock(_table_lock);
+   opp_table = _find_opp_table_from_node(np);
+   mutex_unlock(_table_lock);
+   return opp_table;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_find_table_from_node);
+
+struct opp_table *_managed_opp(struct device *dev, int index)
+{
+   struct device_node *np;
+   struct opp_table *opp_table;
+
+   np = _opp_of_get_opp_desc_node(dev->of_node, index);
+   if (!np)
+   return NULL;
+
+   opp_table = _find_opp_table_from_node(np);
+   of_node_put(np);
+   return opp_table;
+}
+
 /* The caller must call dev_pm_opp_put() after the OPP is used */
 static struct dev_pm_opp *_find_opp_of_np(struct opp_table *opp_table,
  struct device_node *opp_np)
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 7f040cc20daf..3f30ce55e8eb 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -359,6 +359,7 @@ int dev_pm_opp_of_cpumask_add_table(const struct cpumask 
*cpumask);
 void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask);
 int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask 
*cpumask);
 struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
+struct opp_table *dev_pm_opp_of_find_table_from_node(struct device_node *np);
 struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
 int of_get_required_opp_performance_state(struct device_node *np, int index);
 void dev_pm_opp_of_register_em(struct cpumask *cpus);
@@ -396,6 +397,12 @@ static inline struct device_node 
*dev_pm_opp_of_get_opp_desc_node(struct device
return NULL;
 }
 
+static inline struct opp_table *dev_pm_opp_of_find_table_from_node(
+   struct device_node *np)
+{
+   return NULL;
+}
+
 static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp 
*opp)
 {
return NULL;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

Re: [PATCH v11 0/3] remain and optimize memblock_next_valid_pfn on arm and arm64

[Hanjun Guo]

Hi Ard, Will,

This week we were trying to debug an issue of time consuming in mem_init(),
and leading to this similar solution form Jia He, so I would like to bring this
thread back, please see my detail test result below.

On 2018/9/7 22:44, Will Deacon wrote:
> On Thu, Sep 06, 2018 at 01:24:22PM +0200, Ard Biesheuvel wrote:
>> On 22 August 2018 at 05:07, Jia He  wrote:
>>> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
>>> where possible") optimized the loop in memmap_init_zone(). But it causes
>>> possible panic bug. So Daniel Vacek reverted it later.
>>>
>>> But as suggested by Daniel Vacek, it is fine to using memblock to skip
>>> gaps and finding next valid frame with CONFIG_HAVE_ARCH_PFN_VALID.
>>>
>>> More from what Daniel said:
>>> "On arm and arm64, memblock is used by default. But generic version of
>>> pfn_valid() is based on mem sections and memblock_next_valid_pfn() does
>>> not always return the next valid one but skips more resulting in some
>>> valid frames to be skipped (as if they were invalid). And that's why
>>> kernel was eventually crashing on some !arm machines."
>>>
>>> About the performance consideration:
>>> As said by James in b92df1de5,
>>> "I have tested this patch on a virtual model of a Samurai CPU with a
>>> sparse memory map.  The kernel boot time drops from 109 to 62 seconds."
>>> Thus it would be better if we remain memblock_next_valid_pfn on arm/arm64.
>>>
>>> Besides we can remain memblock_next_valid_pfn, there is still some room
>>> for improvement. After this set, I can see the time overhead of memmap_init
>>> is reduced from 27956us to 13537us in my armv8a server(QDF2400 with 96G
>>> memory, pagesize 64k). I believe arm server will benefit more if memory is
>>> larger than TBs
>>>
>>
>> OK so we can summarize the benefits of this series as follows:
>> - boot time on a virtual model of a Samurai CPU drops from 109 to 62 seconds
>> - boot time on a QDF2400 arm64 server with 96 GB of RAM drops by ~15
>> *milliseconds*
>>
>> Google was not very helpful in figuring out what a Samurai CPU is and
>> why we should care about the boot time of Linux running on a virtual
>> model of it, and the 15 ms speedup is not that compelling either.

Testing this patch set on top of Kunpeng 920 based ARM64 server, with
384G memory in total, we got the time consuming below

 without this patch set  with this patch set
mem_init()13310ms  1415ms

So we got about 8x speedup on this machine, which is very impressive.

The time consuming is related the memory DIMM size and where to locate those
memory DIMMs in the slots. In above case, we are using 16G memory DIMM.
We also tested 1T memory with 64G size for each memory DIMM on another ARM64
machine, the time consuming reduced from 20s to 2s (I think it's related to
firmware implementations).

>>
>> Apologies to Jia that it took 11 revisions to reach this conclusion,
>> but in /my/ opinion, tweaking the fragile memblock/pfn handling code
>> for this reason is totally unjustified, and we're better off
>> disregarding these patches.

Indeed this patch set has a bug, For exampe, if we have 3 regions which
is [a, b] [c, d] [e, f] if address of pfn is bigger than the end address of
last region, we will increase early_region_idx to count of region, which is
out of bound of the regions. Fixed by patch below,

 mm/memblock.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 8279295..8283bf0 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1252,13 +1252,17 @@ unsigned long __init_memblock 
memblock_next_valid_pfn(unsigned long pfn)
if (pfn >= start_pfn && pfn < end_pfn)
return pfn;

-   early_region_idx++;
+   /* try slow path */
+   if (++early_region_idx == type->cnt)
+   goto slow_path;
+
next_start_pfn = PFN_DOWN(regions[early_region_idx].base);

if (pfn >= end_pfn && pfn <= next_start_pfn)
return next_start_pfn;
}

+slow_path:
/* slow path, do the binary searching */
do {
mid = (right + left) / 2;

As the really impressive speedup on our ARM64 server system, could you 
reconsider
this patch set for merge? if you want more data I'm willing to clarify and give
more test.

Thanks
Hanjun

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Benjamin Herrenschmidt]

> Please try the attached patch. I'm not really pleased with it and I will 
> continue to determine why the fallback to a 30-bit mask fails, but at least 
> this 
> one works for me.

Your patch only makes sense if the device is indeed capable of
addressing 31-bits.

So either the driver is buggy and asks for a too small mask in which
case your patch is ok, or it's not and you're just going to cause all
sort of interesting random problems including possible memory
corruption.

Cheers,
Ben.

Re: [PATCH 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list

[Bjorn Andersson]

On Fri 07 Jun 16:02 PDT 2019, Linus Walleij wrote:

> On Wed, Jun 5, 2019 at 1:43 PM Lee Jones  wrote:
> 
> > When booting MSM based platforms with Device Tree or some ACPI
> > implementations, it is possible to provide a list of reserved pins
> > via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
> > However some ACPI tables are not populated with this information,
> > thus it has to come from a knowledgable device driver instead.
> >
> > Here we provide the MSM common driver with additional support to
> > parse this informtion and correctly populate the widely used
> > 'valid_mask'.
> >
> > Signed-off-by: Lee Jones 
> 
> Exactly how we should use of the API, so if Björn can supply an
> ACK to patches 3 and 4 I'm happy to apply them.
> 
> Björn?
> 

I'm waiting for a version that does not specify the reserved_gpios for
struct msm_pinctrl_soc_data sdm845_pinctrl {}, as this would override
the ability of getting these from DT.

I haven't seen such revision yet, will review it once I find it.

Regards,
Bjorn

Re: [PATCH 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list

[Bjorn Andersson]

On Wed 05 Jun 04:42 PDT 2019, Lee Jones wrote:

> When booting MSM based platforms with Device Tree or some ACPI
> implementations, it is possible to provide a list of reserved pins
> via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
> However some ACPI tables are not populated with this information,
> thus it has to come from a knowledgable device driver instead.
> 
> Here we provide the MSM common driver with additional support to
> parse this informtion and correctly populate the widely used
> 'valid_mask'.
> 
> Signed-off-by: Lee Jones 
> ---
>  drivers/pinctrl/qcom/pinctrl-msm.c | 18 ++
>  drivers/pinctrl/qcom/pinctrl-msm.h |  1 +
>  2 files changed, 19 insertions(+)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index ee8119879c4c..3ac740b36508 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -607,8 +607,23 @@ static int msm_gpio_init_valid_mask(struct gpio_chip 
> *chip)
>   int ret;
>   unsigned int len, i;
>   unsigned int max_gpios = pctrl->soc->ngpios;
> + const int *reserved = pctrl->soc->reserved_gpios;
>   u16 *tmp;
>  
> + /* Driver provided reserved list overrides DT and ACPI */
> + if (reserved) {
> + bitmap_fill(chip->valid_mask, max_gpios);
> + for (i = 0; reserved[i] >= 0; i++) {
> + if (i >= max_gpios || reserved[i] >= max_gpios) {

reserved is a list of GPIOs to reserve, I don't see a reason to check
if that list is longer than the number of GPIOs (i.e. the first half of
the condition).

It wouldn't make sense to be, but there's no logical issue with it and I
had to read the conditional a few extra times to be sure what was going
on.


Apart from that you have my

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> + dev_err(pctrl->dev, "invalid list of reserved 
> GPIOs\n");
> + return -EINVAL;
> + }
> + clear_bit(reserved[i], chip->valid_mask);
> + }
> +
> + return 0;
> + }
> +
>   /* The number of GPIOs in the ACPI tables */
>   len = ret = device_property_read_u16_array(pctrl->dev, "gpios", NULL,
>  0);
> @@ -964,6 +979,9 @@ static void msm_gpio_irq_handler(struct irq_desc *desc)
>  
>  static bool msm_gpio_needs_valid_mask(struct msm_pinctrl *pctrl)
>  {
> + if (pctrl->soc->reserved_gpios)
> + return true;
> +
>   return device_property_read_u16_array(pctrl->dev, "gpios", NULL, 0) > 0;
>  }
>  
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h 
> b/drivers/pinctrl/qcom/pinctrl-msm.h
> index c12048e54a6f..23b93ae92269 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.h
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.h
> @@ -121,6 +121,7 @@ struct msm_pinctrl_soc_data {
>   bool pull_no_keeper;
>   const char *const *tiles;
>   unsigned int ntiles;
> + const int *reserved_gpios;
>  };
>  
>  extern const struct dev_pm_ops msm_pinctrl_dev_pm_ops;
> -- 
> 2.17.1
> 

Re: [v2 PATCH] mm: thp: fix false negative of shmem vma's THP eligibility

[Hugh Dickins]

On Wed, 24 Apr 2019, Yang Shi wrote:

> The commit 7635d9cbe832 ("mm, thp, proc: report THP eligibility for each
> vma") introduced THPeligible bit for processes' smaps. But, when checking
> the eligibility for shmem vma, __transparent_hugepage_enabled() is
> called to override the result from shmem_huge_enabled().  It may result
> in the anonymous vma's THP flag override shmem's.  For example, running a
> simple test which create THP for shmem, but with anonymous THP disabled,
> when reading the process's smaps, it may show:
> 
> 7fc92ec0-7fc92f00 rw-s  00:14 27764 /dev/shm/test
> Size:   4096 kB
> ...
> [snip]
> ...
> ShmemPmdMapped: 4096 kB
> ...
> [snip]
> ...
> THPeligible:0
> 
> And, /proc/meminfo does show THP allocated and PMD mapped too:
> 
> ShmemHugePages: 4096 kB
> ShmemPmdMapped: 4096 kB
> 
> This doesn't make too much sense.  The anonymous THP flag should not
> intervene shmem THP.  Calling shmem_huge_enabled() with checking
> MMF_DISABLE_THP sounds good enough.  And, we could skip stack and
> dax vma check since we already checked if the vma is shmem already.
> 
> Fixes: 7635d9cbe832 ("mm, thp, proc: report THP eligibility for each vma")
> Cc: Michal Hocko 
> Cc: Vlastimil Babka 
> Cc: David Rientjes 
> Cc: Kirill A. Shutemov 
> Signed-off-by: Yang Shi 
> ---
> v2: Check VM_NOHUGEPAGE per Michal Hocko
> 
>  mm/huge_memory.c | 4 ++--
>  mm/shmem.c   | 3 +++
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 165ea46..5881e82 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -67,8 +67,8 @@ bool transparent_hugepage_enabled(struct vm_area_struct 
> *vma)
>  {
>   if (vma_is_anonymous(vma))
>   return __transparent_hugepage_enabled(vma);
> - if (vma_is_shmem(vma) && shmem_huge_enabled(vma))
> - return __transparent_hugepage_enabled(vma);
> + if (vma_is_shmem(vma))
> + return shmem_huge_enabled(vma);
>  
>   return false;
>  }
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 2275a0f..6f09a31 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -3873,6 +3873,9 @@ bool shmem_huge_enabled(struct vm_area_struct *vma)
>   loff_t i_size;
>   pgoff_t off;
>  
> + if ((vma->vm_flags & VM_NOHUGEPAGE) ||
> + test_bit(MMF_DISABLE_THP, >vm_mm->flags))
> + return false;

Yes, that is correct; and correctly placed. But a little more is needed:
see how mm/memory.c's transhuge_vma_suitable() will only allow a pmd to
be used instead of a pte if the vma offset and size permit. smaps should
not report a shmem vma as THPeligible if its offset or size prevent it.

And I see that should also be fixed on anon vmas: at present smaps
reports even a 4kB anon vma as THPeligible, which is not right.
Maybe a test like transhuge_vma_suitable() can be added into
transparent_hugepage_enabled(), to handle anon and shmem together.
I say "like transhuge_vma_suitable()", because that function needs
an address, which here you don't have.

The anon offset situation is interesting: usually anon vm_pgoff is
initialized to fit with its vm_start, so the anon offset check passes;
but I wonder what happens after mremap to a different address - does
transhuge_vma_suitable() then prevent the use of pmds where they could
actually be used? Not a Number#1 priority to investigate or fix here!
but a curiosity someone might want to look into.

>   if (shmem_huge == SHMEM_HUGE_FORCE)
>   return true;
>   if (shmem_huge == SHMEM_HUGE_DENY)
> -- 
> 1.8.3.1


Even with your changes
ShmemPmdMapped: 4096 kB
THPeligible:0
will easily be seen: THPeligible reflects whether a huge page can be
allocated and mapped by pmd in that vma; but if something else already
allocated the huge page earlier, it will be mapped by pmd in this vma
if offset and size allow, whatever THPeligible says. We could change
transhuge_vma_suitable() to force ptes in that case, but it would be
a silly change, just to make what smaps shows easier to explain.

Hugh

Re: [RFC net-next 2/2] net: stmmac: Convert to phylink

[Florian Fainelli]

On 6/6/2019 4:26 AM, Jose Abreu wrote:
> Convert stmmac driver to phylink.
> 
> Signed-off-by: Jose Abreu 
> Cc: Joao Pinto 
> Cc: David S. Miller 
> Cc: Giuseppe Cavallaro 
> Cc: Alexandre Torgue 
> Cc: Russell King 
> Cc: Andrew Lunn 
> Cc: Florian Fainelli 
> Cc: Heiner Kallweit 
> ---
[snip]

 interface);
> - }
> + if (node) {
> + ret = phylink_of_phy_connect(priv->phylink, node, 0);
> + } else {
> + int addr = priv->plat->phy_addr;
> + struct phy_device *phydev;
>  
> - if (IS_ERR_OR_NULL(phydev)) {
> - netdev_err(priv->dev, "Could not attach to PHY\n");
> - if (!phydev)
> + phydev = mdiobus_get_phy(priv->mii, addr);
> + if (!phydev) {
> + netdev_err(priv->dev, "no phy at addr %d\n", addr);
>   return -ENODEV;
> + }

I am not exactly sure removing this is strictly equivalent here, but the
diff makes it hard to review.

For the sake of reviewing the code, could you structure the patches like
you did with an intermediate step being:

- prepare for PHYLINK (patch #1)
- add support for PHYLINK (parts of this patch) but without plugging it
into the probe/connect path just yet
- get rid of all PHYLIB related code (parts of this patch), which would
be a new patch #3

AFAIR, there are several cases that stmmac supports today:

- fixed PHY (covered by PHYLINK)
- PHY designated via phy-handle (covered by PHYLINK)
- PHY address via platform data (not covered by PHYLINK unless we add
support for that), with no Device Tree node
- when a MDIO bus Device Tree node is present, register the stmmac MDIO
bus (which you don't change).

I believe I have convinced myself that the third case is covered with
the change above :)

This looks great, thanks!
-- 
Florian

Re: [PATCH v2 3/3] regulator: lp87565: Add 4-phase lp87561 regulator support

[keerthy]

On 5/28/2019 6:57 PM, Mark Brown wrote:

On Tue, May 28, 2019 at 03:23:41PM +0530, Keerthy wrote:

On 22/05/19 9:05 PM, Mark Brown wrote:

On Thu, May 16, 2019 at 10:02:18AM +0530, Keerthy wrote:



Acked-by: Mark Brown 



This patch will come via the mfd branch?


I'd expect so, IIRC it had a build dependency on the earlier patches in
the series so if that doesn't happen I'll need to merge the relevant MFD
commits.


Mark,

mfd patches are on linux-next already. Hope you can pull this one now 
that dependencies are met.


- Keerthy

Re: [RFC RESEND PATCH v2 1/4] dt-bindings: gpio: davinci: Add k3 am654 compatible

[keerthy]

On 6/8/2019 4:09 AM, Linus Walleij wrote:

On Thu, Jun 6, 2019 at 11:55 AM Keerthy  wrote:


The patch adds k3 am654 compatible, specific properties and
an example.

Signed-off-by: Keerthy 


Patch applied with the three others, so now all
GPIO changes are in tree.

Please funnel all the DTS changes through ARM SoC.


Thank you Linus!

Tero,

Could you pull the dts changes on top of intr dts patches.

Regards,
Keerthy


Yours,
Linus Walleij

Re: [PATCH] arm64: dts: msm8996: fix PSCI entry-latency-us

[Bjorn Andersson]

On Tue 04 Jun 05:29 PDT 2019, Niklas Cassel wrote:

> The current entry-latency-us is too short.
> The proper way to convert between the device tree properties
> from the vendor tree to the upstream PSCI device tree properties is:
> 
> entry-latency-us = qcom,time-overhead - qcom,latency-us
> 
> which gives
> 
> entry-latency-us = 210 - 80 = 130
> 
> Fixes: f6aee7af59b6 ("arm64: dts: qcom: msm8996: Add PSCI cpuidle low power 
> states")
> Signed-off-by: Niklas Cassel 

Thanks Niklas

Applied,
Bjorn

> ---
>  arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index b7cf2a17dcb5..e8c03b5c8990 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -174,7 +174,7 @@
>   compatible = "arm,idle-state";
>   idle-state-name = "standalone-power-collapse";
>   arm,psci-suspend-param = <0x0004>;
> - entry-latency-us = <40>;
> + entry-latency-us = <130>;
>   exit-latency-us = <80>;
>   min-residency-us = <300>;
>   };
> -- 
> 2.21.0
> 

Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support

[Bjorn Andersson]

On Wed 05 Jun 10:16 PDT 2019, Sricharan R wrote:

> Add initial device tree support for the Qualcomm IPQ6018 SoC and
> CP01 evaluation board.
> 
> Signed-off-by: Sricharan R 
> Signed-off-by: Abhishek Sahu 

Please fix the order of these (or add a Co-developed-by).

> ---
>  arch/arm64/boot/dts/qcom/Makefile|   1 +
>  arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts |  35 
>  arch/arm64/boot/dts/qcom/ipq6018.dtsi| 231 
> +++
>  3 files changed, 267 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/ipq6018.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
> b/arch/arm64/boot/dts/qcom/Makefile
> index 21d548f..ac22dbb 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -2,6 +2,7 @@
>  dtb-$(CONFIG_ARCH_QCOM)  += apq8016-sbc.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += apq8096-db820c.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += ipq8074-hk01.dtb
> +dtb-$(CONFIG_ARCH_QCOM)  += ipq6018-cp01-c1.dtb

Sort order.

>  dtb-$(CONFIG_ARCH_QCOM)  += msm8916-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += msm8992-bullhead-rev-101.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += msm8994-angler-rev-101.dtb
> diff --git a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts 
> b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
> new file mode 100644
> index 000..ac7cb22
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * IPQ6018 CP01 board device tree source
> + *
> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include "ipq6018.dtsi"
> +
> +/ {
> + #address-cells = <0x2>;
> + #size-cells = <0x2>;

This is a count, write it in base 10..

> + model = "Qualcomm Technologies, Inc. IPQ6018/AP-CP01-C1";
> + compatible = "qcom,ipq6018-cp01", "qcom,ipq6018";
> + interrupt-parent = <>;

Changing #address-cells, #size-cells and interrupt-parent will break the
dtsi, so I think you should specify them there.

> +};
> +
> + {

Please sort your nodes based on address, then node name, then label.

> + uart_pins: uart_pins {
> + mux {
> + pins = "gpio44", "gpio45";
> + function = "blsp2_uart";
> + drive-strength = <8>;
> + bias-pull-down;
> + };
> + };
> +};
> +
> +_uart3 {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + status = "ok";
> +};
> diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi 
> b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> new file mode 100644
> index 000..79cccdd
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
> @@ -0,0 +1,231 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * IPQ6018 SoC device tree source
> + *
> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. IPQ6018";
> + compatible = "qcom,ipq6018";

No need for model and compatible in the dtsi, these should always be
specified by the including file.

> +
> + chosen {
> + bootargs = "console=ttyMSM0,115200,n8 rw init=/init";

Do you really need console? Can't you use stdout-path?

And there's no need to specify init=/init.

> + bootargs-append = " swiotlb=1 clk_ignore_unused";

I'm hoping that you will work on removing the need for
clk_ignore_unused.

> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + tz:tz@4850 {

Space after :

> + no-map;
> + reg = <0x0 0x4850 0x0 0x0020>;

I would prefer to have the reg first in these nodes, then the region's
properties.

> + };
> + };
> +
> + soc: soc {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + ranges = <0 0 0 0x>;
> + dma-ranges;
> + compatible = "simple-bus";
> +
> + intc: interrupt-controller@b00 {

As described above, please sort your nodes based on address, node name
and lastly label name.

> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <0x3>;
> + reg = <0xb00 0x1000>, <0xb002000 0x1000>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>,
> +   IRQ_TYPE_LEVEL_LOW)>;
> + };
> +
> + timer@b12 {
> + #address-cells = <1>;
> +   

Re: [PATCH 3/6] clk: qcom: Add DT bindings for ipq6018 gcc clock controller

[Bjorn Andersson]

On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:

> Add the compatible strings and the include file for ipq6018
> gcc clock controller.
> 
> Signed-off-by: Sricharan R 
> Signed-off-by: anusha 
> Signed-off-by: Abhishek Sahu 

Please fix your s-o-b chain.

> ---
>  .../devicetree/bindings/clock/qcom,gcc.txt |   1 +
>  include/dt-bindings/clock/qcom,gcc-ipq6018.h   | 405 
> +
>  2 files changed, 406 insertions(+)
>  create mode 100644 include/dt-bindings/clock/qcom,gcc-ipq6018.h
> 
> diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
> b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
> index 8661c3c..40bb3de 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
> +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
> @@ -9,6 +9,7 @@ Required properties :
>   "qcom,gcc-ipq8064"
>   "qcom,gcc-ipq4019"
>   "qcom,gcc-ipq8074"
> + "qcom,gcc-ipq6018"

And please maintain sort order.

Regards,
Bjorn

>   "qcom,gcc-msm8660"
>   "qcom,gcc-msm8916"
>   "qcom,gcc-msm8960"
> diff --git a/include/dt-bindings/clock/qcom,gcc-ipq6018.h 
> b/include/dt-bindings/clock/qcom,gcc-ipq6018.h
> new file mode 100644
> index 000..b8aec10
> --- /dev/null
> +++ b/include/dt-bindings/clock/qcom,gcc-ipq6018.h
> @@ -0,0 +1,405 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef _DT_BINDINGS_CLOCK_IPQ_GCC_6018_H
> +#define _DT_BINDINGS_CLOCK_IPQ_GCC_6018_H
> +
> +#define GPLL00
> +#define UBI32_PLL1
> +#define GPLL62
> +#define GPLL43
> +#define PCNOC_BFDCD_CLK_SRC  4
> +#define GPLL25
> +#define NSS_CRYPTO_PLL   6
> +#define NSS_PPE_CLK_SRC  7
> +#define GCC_XO_CLK_SRC   8
> +#define NSS_CE_CLK_SRC   9
> +#define GCC_SLEEP_CLK_SRC10
> +#define APSS_AHB_CLK_SRC 11
> +#define NSS_PORT5_RX_CLK_SRC 12
> +#define NSS_PORT5_TX_CLK_SRC 13
> +#define PCIE0_AXI_CLK_SRC14
> +#define USB0_MASTER_CLK_SRC  15
> +#define APSS_AHB_POSTDIV_CLK_SRC 16
> +#define NSS_PORT1_RX_CLK_SRC 17
> +#define NSS_PORT1_TX_CLK_SRC 18
> +#define NSS_PORT2_RX_CLK_SRC 19
> +#define NSS_PORT2_TX_CLK_SRC 20
> +#define NSS_PORT3_RX_CLK_SRC 21
> +#define NSS_PORT3_TX_CLK_SRC 22
> +#define NSS_PORT4_RX_CLK_SRC 23
> +#define NSS_PORT4_TX_CLK_SRC 24
> +#define NSS_PORT5_RX_DIV_CLK_SRC 25
> +#define NSS_PORT5_TX_DIV_CLK_SRC 26
> +#define APSS_AXI_CLK_SRC 27
> +#define NSS_CRYPTO_CLK_SRC   28
> +#define NSS_PORT1_RX_DIV_CLK_SRC 29
> +#define NSS_PORT1_TX_DIV_CLK_SRC 30
> +#define NSS_PORT2_RX_DIV_CLK_SRC 31
> +#define NSS_PORT2_TX_DIV_CLK_SRC 32
> +#define NSS_PORT3_RX_DIV_CLK_SRC 33
> +#define NSS_PORT3_TX_DIV_CLK_SRC 34
> +#define NSS_PORT4_RX_DIV_CLK_SRC 35
> +#define NSS_PORT4_TX_DIV_CLK_SRC 36
> +#define NSS_UBI0_CLK_SRC 37
> +#define BLSP1_QUP1_I2C_APPS_CLK_SRC  38
> +#define BLSP1_QUP1_SPI_APPS_CLK_SRC  39
> +#define BLSP1_QUP2_I2C_APPS_CLK_SRC  40
> +#define BLSP1_QUP2_SPI_APPS_CLK_SRC  41
> +#define BLSP1_QUP3_I2C_APPS_CLK_SRC  42
> +#define BLSP1_QUP3_SPI_APPS_CLK_SRC  43
> +#define BLSP1_QUP4_I2C_APPS_CLK_SRC  44
> +#define BLSP1_QUP4_SPI_APPS_CLK_SRC  45
> +#define BLSP1_QUP5_I2C_APPS_CLK_SRC  46
> +#define BLSP1_QUP5_SPI_APPS_CLK_SRC  47
> +#define BLSP1_QUP6_I2C_APPS_CLK_SRC  48
> +#define BLSP1_QUP6_SPI_APPS_CLK_SRC  49
> +#define BLSP1_UART1_APPS_CLK_SRC 50
> +#define BLSP1_UART2_APPS_CLK_SRC 51
> +#define BLSP1_UART3_APPS_CLK_SRC 52
> +#define BLSP1_UART4_APPS_CLK_SRC 53
> +#define BLSP1_UART5_APPS_CLK_SRC 54
> +#define BLSP1_UART6_APPS_CLK_SRC 55
> +#define CRYPTO_CLK_SRC   56
> +#define NSS_UBI0_DIV_CLK_SRC 57
> +#define PCIE0_AUX_CLK_SRC58
> +#define PCIE0_PIPE_CLK_SRC   59
> +#define SDCC1_APPS_CLK_SRC   60
> +#define USB0_AUX_CLK_SRC 61
> +#define USB0_MOCK_UTMI_CLK_SRC   62
> +#define USB0_PIPE_CLK_SRC63
> 

Re: [PATCH 6/6] arm64: defconfig: Enable qcom ipq6018 clock and pinctrl

[Bjorn Andersson]

On Wed 05 Jun 10:16 PDT 2019, Sricharan R wrote:

> These configs are required for booting kernel in qcom
> ipq6018 boards.
> 
> Signed-off-by: Sricharan R 

Reviewed-by: Bjorn Andersson 

> ---
>  arch/arm64/configs/defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 4d58351..abf64ee 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -373,6 +373,7 @@ CONFIG_PINCTRL_MAX77620=y
>  CONFIG_PINCTRL_IMX8MQ=y
>  CONFIG_PINCTRL_IMX8QXP=y
>  CONFIG_PINCTRL_IPQ8074=y
> +CONFIG_PINCTRL_IPQ6018=y
>  CONFIG_PINCTRL_MSM8916=y
>  CONFIG_PINCTRL_MSM8994=y
>  CONFIG_PINCTRL_MSM8996=y
> @@ -646,6 +647,7 @@ CONFIG_COMMON_CLK_QCOM=y
>  CONFIG_QCOM_CLK_SMD_RPM=y
>  CONFIG_QCOM_CLK_RPMH=y
>  CONFIG_IPQ_GCC_8074=y
> +CONFIG_IPQ_GCC_6018=y
>  CONFIG_MSM_GCC_8916=y
>  CONFIG_MSM_GCC_8994=y
>  CONFIG_MSM_MMCC_8996=y
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
> Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH 4/6] clk: qcom: Add ipq6018 Global Clock Controller support

[Bjorn Andersson]

On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:

> This patch adds support for the global clock controller found on
> the ipq6018 based devices.
> 
> Signed-off-by: Sricharan R 
> Signed-off-by: anusha 
> Signed-off-by: Abhishek Sahu 

Please fix your s-o-b chain, as described in my reply to 1/8..

> ---
>  drivers/clk/qcom/Kconfig   |9 +
>  drivers/clk/qcom/Makefile  |1 +
>  drivers/clk/qcom/gcc-ipq6018.c | 5267 
> 
>  3 files changed, 5277 insertions(+)
>  create mode 100644 drivers/clk/qcom/gcc-ipq6018.c
> 
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index e1ff83c..e5fb091 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -120,6 +120,15 @@ config IPQ_GCC_8074
> i2c, USB, SD/eMMC, etc. Select this for the root clock
> of ipq8074.
>  
> +config IPQ_GCC_6018

Please maintain sort order.

> + tristate "IPQ6018 Global Clock Controller"
> + depends on COMMON_CLK_QCOM
> + help
> +   Support for global clock controller on ipq6018 devices.
> +   Say Y if you want to use peripheral devices such as UART, SPI,
> +   i2c, USB, SD/eMMC, etc. Select this for the root clock
> +   of ipq6018.
> +
>  config MSM_GCC_8660
>   tristate "MSM8660 Global Clock Controller"
>   help
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index f0768fb..025137d 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -22,6 +22,7 @@ obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
>  obj-$(CONFIG_IPQ_GCC_4019) += gcc-ipq4019.o
>  obj-$(CONFIG_IPQ_GCC_806X) += gcc-ipq806x.o
>  obj-$(CONFIG_IPQ_GCC_8074) += gcc-ipq8074.o
> +obj-$(CONFIG_IPQ_GCC_6018) += gcc-ipq6018.o

Ditto.

>  obj-$(CONFIG_IPQ_LCC_806X) += lcc-ipq806x.o
>  obj-$(CONFIG_MDM_GCC_9615) += gcc-mdm9615.o
>  obj-$(CONFIG_MDM_LCC_9615) += lcc-mdm9615.o
> diff --git a/drivers/clk/qcom/gcc-ipq6018.c b/drivers/clk/qcom/gcc-ipq6018.c
[..]
> +static int gcc_ipq6018_probe(struct platform_device *pdev)
> +{
> + return qcom_cc_probe(pdev, _ipq6018_desc);
> +}
> +
> +static int gcc_ipq6018_remove(struct platform_device *pdev)
> +{
> + return 0;

Just omit .remove from the gcc_ipq6018_driver instead of providing a
dummy function.

> +}
> +
> +static struct platform_driver gcc_ipq6018_driver = {
> + .probe = gcc_ipq6018_probe,
> + .remove = gcc_ipq6018_remove,
> + .driver = {
> + .name   = "qcom,gcc-ipq6018",
> + .owner  = THIS_MODULE,

Don't specify .owner in platform drivers.

[..]
> +MODULE_DESCRIPTION("Qualcomm Technologies, Inc. GCC IPQ6018 Driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:gcc-ipq6018");

This modalias won't be used.

Regards,
Bjorn

Re: [PATCH 2/6] dt-bindings: qcom: Add ipq6018 bindings

[Bjorn Andersson]

On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:

> Signed-off-by: Sricharan R 
> Signed-off-by: speriaka 
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml 
> b/Documentation/devicetree/bindings/arm/qcom.yaml
> index f6316ab..7b19028 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -36,6 +36,7 @@ description: |
>   mdm9615
>   ipq8074
>   sdm845
> + ipq6018

It would be nice if these lists where sorted, but as that's not the
case, please sort it wrt the other ipq at least.

Regards,
Bjorn

>  
>The 'board' element must be one of the following strings:
>  
> @@ -45,6 +46,7 @@ description: |
>   mtp
>   sbc
>   hk01
> + cp01-c1
>  
>The 'soc_version' and 'board_version' elements take the form of 
> v.
>where the minor number may be omitted when it's zero, i.e.  v1.0 is the 
> same
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
> Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH 1/6] pinctrl: qcom: Add ipq6018 pinctrl driver

[Bjorn Andersson]

On Wed 05 Jun 10:15 PDT 2019, Sricharan R wrote:

> Add initial pinctrl driver to support pin configuration with
> pinctrl framework for ipq6018.
> 
> Signed-off-by: Sricharan R 
> Signed-off-by: Rajkumar Ayyasamy 
> Signed-off-by: speriaka 

These should start with the author, then followed by each person that
handled the patch on its way to the list - so your name should probably
be last.  If you have more than one author add Co-developed-by, in
addition to the Signed-off-by.

And please spell our speriaka's first and last name.

[..]
> diff --git 
> a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.txt
[..]
> +- #gpio-cells:
> + Usage: required
> + Value type: 
> + Definition: must be 2. Specifying the pin number and flags, as defined
> + in 

You're missing the required "gpio-ranges" property.

> +
[..]
> +- function:
> + Usage: required
> + Value type: 
> + Definition: Specify the alternative function to be configured for the
> + specified pins. Functions are only valid for gpio pins.
> + Valid values are:
> + adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, atest_char, atest_char0,

Please indent these.

[..]

The rest should be in a separate patch from the binding.

> diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
[..]
> +enum ipq6018_functions {
[..]
> + msm_mux_NA,

I like when these are sorted, and if you make the last entry msm_mux__
the msm_pingroup array becomes easier to read.

> +};
[..]
> +static const struct msm_function ipq6018_functions[] = {
[..]
> + FUNCTION(gcc_tlmm),

As above, please sort these.

> +};
> +
> +static const struct msm_pingroup ipq6018_groups[] = {
> + PINGROUP(0, qpic_pad, wci20, qdss_traceclk_b, NA, burn0, NA, NA, NA,
> +  NA),

Please ignore the 80-char and skip the line breaks.

> + PINGROUP(1, qpic_pad, mac12, qdss_tracectl_b, NA, burn1, NA, NA, NA,
> +  NA),
> + PINGROUP(2, qpic_pad, wci20, qdss_tracedata_b, NA, NA, NA, NA, NA, NA),
> + PINGROUP(3, qpic_pad, mac01, qdss_tracedata_b, NA, NA, NA, NA, NA, NA),
> + PINGROUP(4, qpic_pad, mac01, qdss_tracedata_b, NA, NA, NA, NA, NA, NA),
> + PINGROUP(5, qpic_pad4, mac21, qdss_tracedata_b, NA, NA, NA, NA, NA, NA),

Is there a reason to keep qpic_padN as separate functions from qpic_pad?

[..]
> +static struct platform_driver ipq6018_pinctrl_driver = {
> + .driver = {
> + .name = "ipq6018-pinctrl",
> + .owner = THIS_MODULE,

.owner is populated automagically by platform_driver_register, so please
omit this.

> + .of_match_table = ipq6018_pinctrl_of_match,
> + },
> + .probe = ipq6018_pinctrl_probe,
> + .remove = msm_pinctrl_remove,
> +};

Regards,
Bjorn

Re: [RFC] printk/sysrq: Don't play with console_loglevel

[Tetsuo Handa]

On 2019/06/08 2:09, Pavel Machek wrote:
> On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
>> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
 You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit 
 printk
 context information. But doesn't such attempt resemble 
 find_printk_buffer() ?
>>>
>>> Adding KERN_UNSUPPRESSED to all printks down the op_p->handler()
>>> line is hardly possible. At the same time I'd really prefer not
>>> to have buffering for sysrq.
>>
>> I don't think it is hardly possible. And I really prefer having
>> deferred printing for SysRq.
> 
> Well, magic SysRq was meant for situation where system is in weird/broken 
> state.
> "Give me backtrace where it is hung", etc. Direct printing is more likely to 
> work
> in that cases.

Magic SysRq from keyboard is for situation where system is in weird/broken 
state.

But I want to use Magic SysRq from /proc for situation where system is not 
fatally
weird/broken state. I have trouble getting SysRq-t from /proc when something bad
happened (e.g. some health check process did not return for 60 seconds). Since
/proc/pid/wchan shows only 1 line, it is useless for understanding why that 
process
got stuck. If direct printing is enforced, "echo t > /proc/sysrq-trigger" might 
take
many minutes. If direct printing is not enforced, "echo t > /proc/sysrq-trigger"
should complete within less than one second. If syslog is working (which is 
almost
equivalent to being able to write to /proc/sysrq-trigger), the latter is more 
helpful
for taking snapshots for multiple times (e.g. 5 times with 10 seconds interval) 
in
order to understand why that process got stuck. That's why I added

  At first I though that we also want to apply temporary
  manipulation of console loglevel for SysRq to the body lines, for showing
  only the header line is hardly helpful. But I realized that we should not
  force showing the body lines because some users might be triggering SysRq
  from /proc and reading via syslog rather than via console output. Users
  who need to read via console output should be able to manipulate console
  loglevel by triggering SysRq from console.

part in 
https://lkml.kernel.org/r/c265f674-e293-332b-a037-895025354...@i-love.sakura.ne.jp
 .

A snapshot which was taken within less than one second and a snapshot which was 
taken
across more than many minutes, which one likely shows more accurate "snapshot" ?
I know we need to take a snapshot like vmcore if we need a perfect snapshot 
which
was taken with CPUs stopped. But in enterprise systems where it is difficult to
do "echo c > /proc/sysrq-trigger" in order to take a perfect snapshot, snapshots
which can be taken without destroying the VM comes in handy. There are 
situations
where something went wrong but still able to operate.

Also, regarding Magic SysRq from keyboard case, my intent is to allow SysRq
to just store the messages to printk() buffer, in order to avoid stalls and
take better snapshots for multiple times. And my intent of

  And I really prefer having deferred printing for SysRq.

is "we can let some other SysRq command (e.g. SysRq-h) to write to consoles in 
printk() buffer,
when printk() buffer filled by SysRq-t did not get written to consoles 
automatically".
We can implement it by introducing "printk() which uses global printk() buffer 
but
do not try to write to consoles" and "passing context information which tells 
whether
printk() messages should be written to consoles synchronously". An example is 
shown below.

 drivers/tty/sysrq.c|  3 +++
 include/linux/printk.h | 15 
 include/linux/sched.h  |  1 +
 kernel/printk/printk.c | 62 +-
 mm/oom_kill.c  |  3 +++
 mm/page_alloc.c|  3 +++
 6 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 18cb58e52e9b..135acbe5c389 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -543,6 +543,7 @@ void __handle_sysrq(int key, bool check_mask)
 */
orig_log_level = get_local_loglevel();
set_local_loglevel(CONSOLE_LOGLEVEL_DEFAULT);
+   enable_deferred_output();
 
 op_p = __sysrq_get_key_op(key);
 if (op_p) {
@@ -576,10 +577,12 @@ void __handle_sysrq(int key, bool check_mask)
pr_cont("\n");
set_local_loglevel(orig_log_level);
}
+   disable_deferred_output();
rcu_read_unlock();
rcu_sysrq_end();
 
suppress_printk = orig_suppress_printk;
+   trigger_deferred_output();
 }
 
 void handle_sysrq(int key)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 78b357a1b109..18392376932b 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -196,6 +196,9 @@ extern void printk_safe_flush(void);
 extern void printk_safe_flush_on_panic(void);
 int get_local_loglevel(void);
 void set_local_loglevel(int level);
+void enable_deferred_output(void);

Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support

[Sricharan R]

Hi Sudeep,

On 6/5/2019 11:04 PM, Sudeep Holla wrote:
> On Wed, Jun 05, 2019 at 10:58:57PM +0530, Sricharan R wrote:
>> Add initial device tree support for the Qualcomm IPQ6018 SoC and
>> CP01 evaluation board.
>>
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Abhishek Sahu 
>> ---
>>  arch/arm64/boot/dts/qcom/Makefile|   1 +
>>  arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts |  35 
>>  arch/arm64/boot/dts/qcom/ipq6018.dtsi| 231 
>> +++
>>  3 files changed, 267 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
>>  create mode 100644 arch/arm64/boot/dts/qcom/ipq6018.dtsi
>>
> 
> [...]
> 
>> +
>> +CPU3: cpu@3 {
>> +device_type = "cpu";
>> +compatible = "arm,cortex-a53";
>> +enable-method = "psci";
>> +reg = <0x3>;
>> +next-level-cache = <_0>;
>> +};
>> +
>> +L2_0: l2-cache {
>> +compatible = "cache";
>> +cache-level = <0x2>;
>> +};
>> +};
>> +
>> +pmuv8: pmu {
>> +compatible = "arm,armv8-pmuv3";
> 
> We know these are Cortex-A53s, why not update these accordingly ?
> 

Ok, will change this.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support

[Sricharan R]

Hi Marc,

On 6/5/2019 10:56 PM, Marc Zyngier wrote:
> On 05/06/2019 18:16, Sricharan R wrote:
>> Add initial device tree support for the Qualcomm IPQ6018 SoC and
>> CP01 evaluation board.
>>
>> Signed-off-by: Sricharan R 
>> Signed-off-by: Abhishek Sahu 
>> ---
>>  arch/arm64/boot/dts/qcom/Makefile|   1 +
>>  arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts |  35 
>>  arch/arm64/boot/dts/qcom/ipq6018.dtsi| 231 
>> +++
>>  3 files changed, 267 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
>>  create mode 100644 arch/arm64/boot/dts/qcom/ipq6018.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
>> b/arch/arm64/boot/dts/qcom/Makefile
>> index 21d548f..ac22dbb 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -2,6 +2,7 @@
>>  dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb
>>  dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
>>  dtb-$(CONFIG_ARCH_QCOM) += ipq8074-hk01.dtb
>> +dtb-$(CONFIG_ARCH_QCOM) += ipq6018-cp01-c1.dtb
>>  dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
>>  dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
>>  dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts 
>> b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
>> new file mode 100644
>> index 000..ac7cb22
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
>> @@ -0,0 +1,35 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * IPQ6018 CP01 board device tree source
>> + *
>> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "ipq6018.dtsi"
>> +
>> +/ {
>> +#address-cells = <0x2>;
>> +#size-cells = <0x2>;
>> +model = "Qualcomm Technologies, Inc. IPQ6018/AP-CP01-C1";
>> +compatible = "qcom,ipq6018-cp01", "qcom,ipq6018";
>> +interrupt-parent = <>;
>> +};
>> +
>> + {
>> +uart_pins: uart_pins {
>> +mux {
>> +pins = "gpio44", "gpio45";
>> +function = "blsp2_uart";
>> +drive-strength = <8>;
>> +bias-pull-down;
>> +};
>> +};
>> +};
>> +
>> +_uart3 {
>> +pinctrl-0 = <_pins>;
>> +pinctrl-names = "default";
>> +status = "ok";
>> +};
>> diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi 
>> b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
>> new file mode 100644
>> index 000..79cccdd
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
>> @@ -0,0 +1,231 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * IPQ6018 SoC device tree source
>> + *
>> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +#include 
>> +#include 
>> +
>> +/ {
>> +model = "Qualcomm Technologies, Inc. IPQ6018";
>> +compatible = "qcom,ipq6018";
>> +
>> +chosen {
>> +bootargs = "console=ttyMSM0,115200,n8 rw init=/init";
>> +bootargs-append = " swiotlb=1 clk_ignore_unused";
>> +};
>> +
>> +reserved-memory {
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges;
>> +
>> +tz:tz@4850 {
>> +no-map;
>> +reg = <0x0 0x4850 0x0 0x0020>;
>> +};
>> +};
>> +
>> +soc: soc {
>> +#address-cells = <0x1>;
>> +#size-cells = <0x1>;
>> +ranges = <0 0 0 0x>;
>> +dma-ranges;
>> +compatible = "simple-bus";
>> +
>> +intc: interrupt-controller@b00 {
>> +compatible = "qcom,msm-qgic2";
>> +interrupt-controller;
>> +#interrupt-cells = <0x3>;
>> +reg = <0xb00 0x1000>, <0xb002000 0x1000>;
> 
> Where are the rest of the GICv2 MMIO regions, such as GICV and GICH? And
> the maintenance interrupt?
> 
  GICH - 0xB001000 -- 0xB002000
  GICV - 0xB004000 -- 0xB005000
  Will add this and the PPI as well.

Regards,
 Sricharan

>> +};
>> +
>> +timer {
>> +compatible = "arm,armv8-timer";
>> +interrupts = > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>,
>> + > IRQ_TYPE_LEVEL_LOW)>;
> 
> The fact that you expose the EL2 timer interrupt would tend to confirm
> the idea that this system supports virtualization... Hence my questions
> above.
> 
> Thanks,
> 
>   M.
> 

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [tip:x86/urgent] x86/mm/KASLR: Compute the size of the vmemmap section properly

[Baoquan He]

On 06/07/19 at 02:16pm, tip-bot for Baoquan He wrote:
> Commit-ID:  00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Gitweb: 
> https://git.kernel.org/tip/00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Author: Baoquan He 
> AuthorDate: Thu, 23 May 2019 10:57:44 +0800
> Committer:  Borislav Petkov 
> CommitDate: Fri, 7 Jun 2019 23:12:13 +0200
> 
> x86/mm/KASLR: Compute the size of the vmemmap section properly
> 
> The size of the vmemmap section is hardcoded to 1 TB to support the
> maximum amount of system RAM in 4-level paging mode - 64 TB.
> 
> However, 1 TB is not enough for vmemmap in 5-level paging mode. Assuming
> the size of struct page is 64 Bytes, to support 4 PB system RAM in 5-level,
> 64 TB of vmemmap area is needed:
> 
>   4 * 1000^5 PB / 4096 bytes page size * 64 bytes per page struct / 1000^4 TB 
> = 62.5 TB.

Thanks for picking this, Boris.

Here, 4PB = 4*2^50 = 4*1024^5, the vmemmap should be 64 TB, am I right?

> 
> This hardcoding may cause vmemmap to corrupt the following
> cpu_entry_area section, if KASLR puts vmemmap very close to it and the
> actual vmemmap size is bigger than 1 TB.

[GIT PULL] Kselftest second fixes update for Linux 5.2-rc4

[Shuah Khan]

Hi Linus,

Please pull the following second Kselftest fixes update for
Linux 5.2 rc4.

This Kselftest second fixes update for Linux 5.2-rc4 consists of a
single fix for vm test build failure regression when it is built by
itself.

I found this while I was sanity checking the first fixes update for
Linux 5.2. Would like to get this into rc4.

diff is attached.

thanks,
-- Shuah



The following changes since commit bc2cce3f2ebcae02aa4bb29e3436bf75ee674c32:

  selftests: vm: install test_vmalloc.sh for run_vmtests (2019-05-30 
08:32:57 -0600)


are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest 
tags/linux-kselftest-5.2-rc4-2


for you to fetch changes up to e2e88325f4bcaea51f454723971f7b5ee0e1aa80:

  selftests: vm: Fix test build failure when built by itself 
(2019-06-05 16:05:40 -0600)



linux-kselftest-5.2-rc4-2

This Kselftest second fixes update for Linux 5.2-rc4 consists of a single
fix for vm test build failure regression when it is built by itself.


Shuah Khan (1):
  selftests: vm: Fix test build failure when built by itself

 tools/testing/selftests/vm/Makefile | 4 
 1 file changed, 4 deletions(-)

diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
index 05306c58ff9f..9534dc2bc929 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -1,10 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 # Makefile for vm selftests
 
-ifndef OUTPUT
-  OUTPUT := $(shell pwd)
-endif
-
 CFLAGS = -Wall -I ../../../../usr/include $(EXTRA_CFLAGS)
 LDLIBS = -lrt
 TEST_GEN_FILES = compaction_test

Hello?

[Daniel Gnon]

-- 
Hello ?

My name is Daniel Gnon

I sent you this letter a month ago but I'm not sure if you have it, there
is something I would like to discuss with you below is my personal email
for more details
Email  danielgno...@gmail.com

iMX6 5.2-rc3 boot failure due to "PCI: imx6: Allow asynchronous probing"

[Robert Hancock]

I am seeing a boot failure on our iMX6D-based embedded platform running
v5.2-rc3. It seems to stall for about 20 seconds after "random: crng
init done" and then panic with a bunch of RCU stall and soft-lockup
errors. It seems like something is hanging up in the iMX6 PCIe driver.
Boot log is below.

Suspecting the following patch, I reverted it locally and it seems to
resolve the issue. (Well it gets into userspace at least; it later
oopses in the ksz switch driver, appears unrelated..)

commit 1b8df7aa78748ddafc6f3b16a6328a3c500087b3
Author: Lucas Stach 
Date:   Thu Apr 4 18:45:17 2019 +0200

PCI: imx6: Allow asynchronous probing

Establishing a PCIe link can take a while; allow asynchronous probing so
that link establishment can happen in the background while other devices
are being probed.

Signed-off-by: Lucas Stach 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Fabio Estevam 

I would say either that patch needs a fix or it should be reverted for now.

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.2.0-rc3
(hanc...@sed.rfc1918.192.168.sedsystems.ca) (gcc version 8.3.0
(Buildroot 2019.02.1-00510-gcc60ea2)) #1 SMP PREEMPT Fri Jun 7 17:44:38
CST 2019
[0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7),
cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] OF: fdt: Machine model: SED Systems xxx
[0.00] printk: bootconsole [earlycon0] enabled
[0.00] Memory policy: Data cache writealloc
[0.00] cma: Reserved 64 MiB at 0x3c00
[0.00] percpu: Embedded 16 pages/cpu s36364 r8192 d20980 u65536
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 260608
[0.00] Kernel command line: console=ttymxc0,115200 earlyprintk
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Memory: 940708K/1048576K available (6144K kernel code,
304K rwdata, 2036K rodata, 1024K init, 377K bss, 42332K reserved, 65536K
cma-reserved, 262144K highmem)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[0.00] rcu: Preemptible hierarchical RCU implementation.
[0.00] rcu: RCU event tracing is enabled.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.00]  Tasks RCU enabled.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay
is 100 jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.00] L2C-310 errata 752271 769419 enabled
[0.00] L2C-310 enabling early BRESP for Cortex-A9
[0.00] L2C-310 full line of zeros enabled for Cortex-A9
[0.00] L2C-310 ID prefetch enabled, offset 16 lines
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.00] L2C-310 cache controller enabled, 16 ways, 1024 kB
[0.00] L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76470001
[0.00] random: get_random_bytes called from
start_kernel+0x2ac/0x434 with crng_init=0
[0.00] Switching to timer-based delay loop, resolution 333ns
[0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps
every 715827882841ns
[0.008211] clocksource: mxc_timer1: mask: 0x max_cycles:
0x, max_idle_ns: 637086815595 ns
[0.019178] Console: colour dummy device 80x30
[0.023670] Calibrating delay loop (skipped), value calculated using
timer frequency.. 6.00 BogoMIPS (lpj=3000)
[0.033799] pid_max: default: 32768 minimum: 301
[0.038557] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.045211] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
bytes)
[0.052846] *** VALIDATE proc ***
[0.056285] *** VALIDATE cgroup1 ***
[0.059886] *** VALIDATE cgroup2 ***
[0.063483] CPU: Testing write buffer coherency: ok
[0.068401] CPU0: Spectre v2: using BPIALL workaround
[0.073698] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.085424] Setting up static identity map for 0x1010 - 0x10100060
[0.093365] rcu: Hierarchical SRCU implementation.
[0.103365] smp: Bringing up secondary CPUs ...
[0.115623] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.115630] CPU1: Spectre v2: using BPIALL workaround
[0.126488] smp: Brought up 1 node, 2 CPUs
[0.130636] SMP: Total of 2 processors activated (12.00 BogoMIPS).
[0.136846] CPU: All CPU(s) started in SVC mode.
[0.142366] devtmpfs: initialized
[0.153902] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[0.161920] clocksource: jiffies: mask: 0x max_cycles:
0x, max_idle_ns: 1911260446275000 ns
[0.171715] futex hash table entries: 512 (order: 3, 32768 bytes)
[0.181088] pinctrl 

Re: [PATCH 2/2] edac: add support for Amazon's Annapurna Labs EDAC

[Benjamin Herrenschmidt]

On Fri, 2019-06-07 at 16:11 +0100, James Morse wrote:
> I'm coming at this from somewhere else. This stuff has to be considered all 
> the way
> through the system. Just because each component supports error detection, 
> doesn't mean you
> aren't going to get silent corruption. Likewise if another platform picks up 
> two piecemeal
> edac drivers for hardware it happens to have in common with yours, it doesn't 
> mean we're
> counting all the errors. This stuff has to be viewed for the whole platform.

Sure but you don't solve that problem by having a magic myplatform.c
overseer. And even if you do, it can perfectly access the individual IP
block drivers, finding them via phandles in the DT for example etc...
without having to make those individual drivers dependent on some over
arching machine wide probing mechanism.

> But this doesn't give you a device you can bind a driver to, to kick this 
> stuff off.
> This (I assume) is why you added a dummy 'edac_l1_l2' node, that just probes 
> the driver.
> The hardware is to do with the CPU and caches, 'edac_l1'_l2' doesn't 
> correspond to any
> distinct part of the soc.
> 
> The request is to use the machine compatible, not a dummy node. This wraps up 
> the firmware
> properties too, and any other platform property we don't know about today.
> 
> Once you have this, you don't really need the cpu/cache integration 
> annotations, and your
> future memory-controller support can be picked up as part of the platform 
> driver.
> If you have otherwise identical platforms with different memory controllers, 
> OF gives you
> the API to match the node in the DT.

Dummy nodes are pefectly fine, and has been from the early days of Open
Firmware. That said, these aren't so much dummy as a way to expose the
control path to the caches. The DT isn't perfect in its structure and
the way caches and CPUs are represented makes it difficult to represent
arbitrary control path to them without extra nodes, which is thus what
people do.

Cheers,
Ben.

Dear Friend,

[Mrs Alice Johnson]

--
Dear Friend,


I am Mrs Alice Johnson.am sending you this brief letter to solicit your
partnership to transfer $18.5 million US Dollars.I shall send you more
information and procedures when I receive positive response from you.
please send me a message in my Email box (mrsalicejohns...@gmail.com)
as i wait to hear from you.


Best regard
Mrs Alice Johnson
--

Re: [PATCH 2/2] edac: add support for Amazon's Annapurna Labs EDAC

[Benjamin Herrenschmidt]

On Thu, 2019-06-06 at 11:33 +0100, James Morse wrote:

> > Disagree. The various drivers don't depend on each other.
> > I think we should keep the drivers separated as they are distinct and 
> > independent IP blocks.
> 
> But they don't exist in isolation, they both depend on the 
> integration-choices/firmware
> that makes up your platform.

What do you mean ? They are exposing counters from independent IP
blocks. They are independent drivers. You argument could be use to
claim the entire SoC depends on "integration choices / firmware" ... I
don't get it.

> Other platforms may have exactly the same IP blocks, configured differently, 
> or with
> different features enabled in firmware.

Sure, like every other IP block on the planet. That has never been a
good reason to bring back the ugly spectre of myboard.c file...

>  This means we can't just probe the driver based on
> the presence of the IP block, we need to know the integration choices and 
> firmware
> settings match what the driver requires.

Such as ? I mean none of that differs between these EDAC drivers and
any other IP block, and we still probe them individually.

> (Case in point, that A57 ECC support is optional, another A57 may not have it)

So what ? That belongs in the DT.

> Descriptions of what firmware did don't really belong in the DT. Its not a 
> hardware property.

Since when ? I'm tired of people coming up over and over about that
complete fallacy that the DT should for some obscure religious reason
be strictly limited to "HW properties". ACPI isn't. The old Open
Firmware which I used as a basis for creating the FDT wasn't.

It is perfectly legitimate for the DT to contain configuration
information and firmware choices.

What's not OK is to stick there things that are essentially specific to
the Linux driver implementation but that isn't what we are talking
about here.

> This is why its better to probe this stuff based on the 
> machine-compatible/platform-name,
> not the presence of the IP block in the DT.

No. No no no no. This is bringing back the days of having board files
etc... this is wrong.

Those IP blocks don't need any SW coordination at runtime. The drivers
don't share data nor communicate with each other. There is absolultely
no reason to go down that path.

> Will either of your separate drivers ever run alone? If they're probed from 
> the same
> machine-compatible this won't happen.

They should be probed independently from independent DT nodes, what's
the problem you are trying to fix here ?

> How does your memory controller report errors? Does it send back some data 
> with an invalid
> checksum, or a specific poison/invalid flag? Will the cache report this as a 
> cache error
> too, if its an extra signal, does the cache know what it is?

That's ok, you get the error from both sides, power has done it that
way for ever. It's not always possible to correlate anyways and it's
certainly not the job of the EDAC drivers to try.

> All these are integration choices between the two IP blocks, done as separate 
> drivers we
> don't have anywhere to store that information.

We do, it's called the DT.

>  Even if you don't care about this, making
> them separate drivers should only be done to make them usable on other 
> platforms, where
> these choices may have been different.

That wouldn't make the drivers unusable on other platforms at all.

Cheers,
Ben.

Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal

[Dave Chinner]

On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote:
> On Fri, Jun 07, 2019 at 01:04:26PM +0200, Jan Kara wrote:
> > On Thu 06-06-19 15:03:30, Ira Weiny wrote:
> > > On Thu, Jun 06, 2019 at 12:42:03PM +0200, Jan Kara wrote:
> > > > On Wed 05-06-19 18:45:33, ira.we...@intel.com wrote:
> > > > > From: Ira Weiny 
> > > > 
> > > > So I'd like to actually mandate that you *must* hold the file lease 
> > > > until
> > > > you unpin all pages in the given range (not just that you have an 
> > > > option to
> > > > hold a lease). And I believe the kernel should actually enforce this. 
> > > > That
> > > > way we maintain a sane state that if someone uses a physical location of
> > > > logical file offset on disk, he has a layout lease. Also once this is 
> > > > done,
> > > > sysadmin has a reasonably easy way to discover run-away RDMA application
> > > > and kill it if he wishes so.
> > > 
> > > Fair enough.
> > > 
> > > I was kind of heading that direction but had not thought this far 
> > > forward.  I
> > > was exploring how to have a lease remain on the file even after a "lease
> > > break".  But that is incompatible with the current semantics of a "layout"
> > > lease (as currently defined in the kernel).  [In the end I wanted to get 
> > > an RFC
> > > out to see what people think of this idea so I did not look at keeping the
> > > lease.]
> > > 
> > > Also hitch is that currently a lease is forcefully broken after
> > > /lease-break-time.  To do what you suggest I think we would need a 
> > > new
> > > lease type with the semantics you describe.
> > 
> > I'd do what Dave suggested - add flag to mark lease as unbreakable by
> > truncate and teach file locking core to handle that. There actually is
> > support for locks that are not broken after given timeout so there
> > shouldn't be too many changes need.
> >  
> > > Previously I had thought this would be a good idea (for other reasons).  
> > > But
> > > what does everyone think about using a "longterm lease" similar to [1] 
> > > which
> > > has the semantics you proppose?  In [1] I was not sure "longterm" was a 
> > > good
> > > name but with your proposal I think it makes more sense.
> > 
> > As I wrote elsewhere in this thread I think FL_LAYOUT name still makes
> > sense and I'd add there FL_UNBREAKABLE to mark unusal behavior with
> > truncate.
> 
> Ok I want to make sure I understand what you and Dave are suggesting.
> 
> Are you suggesting that we have something like this from user space?
> 
>   fcntl(fd, F_SETLEASE, F_LAYOUT | F_UNBREAKABLE);

Rather than "unbreakable", perhaps a clearer description of the
policy it entails is "exclusive"?

i.e. what we are talking about here is an exclusive lease that
prevents other processes from changing the layout. i.e. the
mechanism used to guarantee a lease is exclusive is that the layout
becomes "unbreakable" at the filesystem level, but the policy we are
actually presenting to uses is "exclusive access"...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

kprobe: kernel panic in 4.19.47

[Francesco Ruggeri]

I see the following kernel panic in 4.19.47 as soon as I hit a kprobe.
In this case it happened right after

# cd /sys/kernel/debug/tracing/
# echo >trace
# echo 'p rollback_registered_many' >kprobe_events 
# echo 1 >events/kprobes/enable 
# ip netns add dummy
# ip netns del dummy

but I have also seen it with other functions, or when I used kernel modules
to install kprobes.
I bisected to 

8715ce033e [ "x86/modules: Avoid breaking W^X while loading modules" ]

in 4.19.47 (upstream commit f2c65fb322 in v5.2-rc1).

Thanks,
Francesco

[  151.067082] kernel tried to execute NX-protected page - exploit attempt? 
(uid: 0)
[  151.074631] BUG: unable to handle kernel paging request at a000f000
[  151.081661] PGD 200a067 P4D 200a067 PUD 200b063 PMD 1038324067 PTE 
80101cb73161
[  151.089396] Oops: 0011 [#1] SMP
[  151.092603] CPU: 12 PID: 1831 Comm: kworker/u64:1 Kdump: loaded Not tainted 
4.19.47-12345018.AroraKernel419.fc18.x86_64 #1
[  151.103696] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.0 06/28/2013
[  151.110298] Workqueue: netns cleanup_net
[  151.114297] RIP: 0010:0xa000f000
[  151.118286] Code: Bad RIP value.
[  151.121562] RSP: 0018:c90007947d60 EFLAGS: 00010206
[  151.126835] RAX: 88901cbf8070 RBX: c90007947d88 RCX: 88901cbf8070
[  151.134033] RDX: c90007947d88 RSI: c90007947d88 RDI: c90007947d88
[  151.141226] RBP: c90007947d78 R08: 0001 R09: 00020cc0
[  151.148429] R10: c900063ebe08 R11: 00026cdc R12: c90007947d88
[  151.155630] R13: c90007947e38 R14: 88901cbc8110 R15: c90007947e10
[  151.162817] FS:  () GS:88a03f90() 
knlGS:
[  151.170964] CS:  0010 DS:  ES:  CR0: 80050033
[  151.176986] CR2: a000efd6 CR3: 02009006 CR4: 000606e0
[  151.184403] Call Trace:
[  151.187150]  ? rollback_registered_many+0x5/0x3bc
[  151.192123]  ? unregister_netdevice_many+0x1a/0x79
[  151.197177]  default_device_exit_batch+0x137/0x15f
[  151.202231]  ? __wake_up_sync+0x12/0x12
[  151.206345]  ops_exit_list+0x29/0x53
[  151.210181]  cleanup_net+0x189/0x240
[  151.214030]  process_one_work+0x174/0x280
[  151.218319]  ? rescuer_thread+0x277/0x277
[  151.222610]  worker_thread+0x1b5/0x264
[  151.226639]  ? rescuer_thread+0x277/0x277
[  151.230922]  kthread+0xf5/0xfa
[  151.234239]  ? kthread_cancel_delayed_work_sync+0x15/0x15
[  151.239906]  ret_from_fork+0x1f/0x30
[  151.243751] Modules linked in: ipt_MASQUERADE nf_conntrack_netlink 
iptable_filter xt_addrtype xt_conntrack br_netfilter bridge stp llc macvlan sg 
coretemp x86_pkg_temp_thermal ip6table_filter ip6_tables ghash_clmulni_intel 
pcbc bonding aesni_intel kvm_intel aes_x86_64 crypto_simd kvm igb cryptd 
irqbypass glue_helper iTCO_wdt ioatdma iTCO_vendor_support hwmon joydev 
i2c_i801 i2c_algo_bit ipmi_si i2c_core pcc_cpufreq lpc_ich mfd_core 
ipmi_msghandler fuse dca pcspkr xt_multiport iptable_nat nf_nat_ipv4 ip_tables 
nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 x_tables tun loop 8021q 
raid456 async_raid6_recov async_memcpy libcrc32c async_pq async_xor xor 
async_tx raid6_pq raid1 raid0 isci libsas ehci_pci crc32c_intel ehci_hcd 
scsi_transport_sas wmi autofs4
[  151.312827] CR2: a000f000

Re: kprobe: kernel panic in 4.19.47

[Nadav Amit]

There are a couple of patches that were mistakenly not included in 4.19.47.

https://lore.kernel.org/stable/20190606131558.GJ29739@sasha-vm/

Sorry for that and thanks for reporting.

Regards,
Nadav

> On Jun 7, 2019, at 4:54 PM, Francesco Ruggeri  wrote:
> 
> I see the following kernel panic in 4.19.47 as soon as I hit a kprobe.
> In this case it happened right after
> 
> # cd /sys/kernel/debug/tracing/
> # echo >trace
> # echo 'p rollback_registered_many' >kprobe_events 
> # echo 1 >events/kprobes/enable 
> # ip netns add dummy
> # ip netns del dummy
> 
> but I have also seen it with other functions, or when I used kernel modules
> to install kprobes.
> I bisected to 
> 
> 8715ce033e [ "x86/modules: Avoid breaking W^X while loading modules" ]
> 
> in 4.19.47 (upstream commit f2c65fb322 in v5.2-rc1).
> 
> Thanks,
> Francesco
> 
> [  151.067082] kernel tried to execute NX-protected page - exploit attempt? 
> (uid: 0)
> [  151.074631] BUG: unable to handle kernel paging request at a000f000
> [  151.081661] PGD 200a067 P4D 200a067 PUD 200b063 PMD 1038324067 PTE 
> 80101cb73161
> [  151.089396] Oops: 0011 [#1] SMP
> [  151.092603] CPU: 12 PID: 1831 Comm: kworker/u64:1 Kdump: loaded Not 
> tainted 4.19.47-12345018.AroraKernel419.fc18.x86_64 #1
> [  151.103696] Hardware name: Supermicro X9DRT/X9DRT, BIOS 3.0 06/28/2013
> [  151.110298] Workqueue: netns cleanup_net
> [  151.114297] RIP: 0010:0xa000f000
> [  151.118286] Code: Bad RIP value.
> [  151.121562] RSP: 0018:c90007947d60 EFLAGS: 00010206
> [  151.126835] RAX: 88901cbf8070 RBX: c90007947d88 RCX: 
> 88901cbf8070
> [  151.134033] RDX: c90007947d88 RSI: c90007947d88 RDI: 
> c90007947d88
> [  151.141226] RBP: c90007947d78 R08: 0001 R09: 
> 00020cc0
> [  151.148429] R10: c900063ebe08 R11: 00026cdc R12: 
> c90007947d88
> [  151.155630] R13: c90007947e38 R14: 88901cbc8110 R15: 
> c90007947e10
> [  151.162817] FS:  () GS:88a03f90() 
> knlGS:
> [  151.170964] CS:  0010 DS:  ES:  CR0: 80050033
> [  151.176986] CR2: a000efd6 CR3: 02009006 CR4: 
> 000606e0
> [  151.184403] Call Trace:
> [  151.187150]  ? rollback_registered_many+0x5/0x3bc
> [  151.192123]  ? unregister_netdevice_many+0x1a/0x79
> [  151.197177]  default_device_exit_batch+0x137/0x15f
> [  151.202231]  ? __wake_up_sync+0x12/0x12
> [  151.206345]  ops_exit_list+0x29/0x53
> [  151.210181]  cleanup_net+0x189/0x240
> [  151.214030]  process_one_work+0x174/0x280
> [  151.218319]  ? rescuer_thread+0x277/0x277
> [  151.222610]  worker_thread+0x1b5/0x264
> [  151.226639]  ? rescuer_thread+0x277/0x277
> [  151.230922]  kthread+0xf5/0xfa
> [  151.234239]  ? kthread_cancel_delayed_work_sync+0x15/0x15
> [  151.239906]  ret_from_fork+0x1f/0x30
> [  151.243751] Modules linked in: ipt_MASQUERADE nf_conntrack_netlink 
> iptable_filter xt_addrtype xt_conntrack br_netfilter bridge stp llc macvlan 
> sg coretemp x86_pkg_temp_thermal ip6table_filter ip6_tables 
> ghash_clmulni_intel pcbc bonding aesni_intel kvm_intel aes_x86_64 crypto_simd 
> kvm igb cryptd irqbypass glue_helper iTCO_wdt ioatdma iTCO_vendor_support 
> hwmon joydev i2c_i801 i2c_algo_bit ipmi_si i2c_core pcc_cpufreq lpc_ich 
> mfd_core ipmi_msghandler fuse dca pcspkr xt_multiport iptable_nat nf_nat_ipv4 
> ip_tables nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 x_tables tun loop 
> 8021q raid456 async_raid6_recov async_memcpy libcrc32c async_pq async_xor xor 
> async_tx raid6_pq raid1 raid0 isci libsas ehci_pci crc32c_intel ehci_hcd 
> scsi_transport_sas wmi autofs4
> [  151.312827] CR2: a000f000

Re: [PATCH v2] platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime

[Ezequiel Garcia]

Hi Enric,

On Fri, 2019-06-07 at 22:51 +0200, Enric Balletbo Serra wrote:
> Hi,
> 
> Missatge de Guenter Roeck  del dia dv., 7 de juny
> 2019 a les 22:11:
> > On Fri, Jun 7, 2019 at 12:27 PM Nick Crews  wrote:
> > > Hi!
> > > 
> > > On Fri, Jun 7, 2019 at 12:03 PM Ezequiel Garcia  
> > > wrote:
> > > > On Fri, 2019-06-07 at 12:27 +0200, Enric Balletbo i Serra wrote:
> > > > > On many boards, communication between the kernel and the Embedded
> > > > > Controller happens over an LPC bus. In these cases, the kernel config
> > > > > CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a
> > > > > Microchip Embedded Controller (MEC) that is different from the regular
> > > > > EC. On these devices, the same LPC bus is used, but the protocol is
> > > > > a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel
> > > > > config is enabled. Currently, the kernel decides at compile-time 
> > > > > whether
> > > > > or not to use the MEC variant, and, when that kernel option is 
> > > > > selected
> > > > > it breaks the other boards. We would like a kind of runtime detection 
> > > > > to
> > > > > avoid this.
> > > > > 
> > > > > This patch adds that detection mechanism by probing the protocol at
> > > > > runtime, first we assume that a MEC variant is connected, and if the
> > > > > protocol fails it fallbacks to the regular EC. This adds a bit of
> > > > > overload because we try to read twice on those LPC boards that doesn't
> > > > > contain a MEC variant, but is a better solution than having to select 
> > > > > the
> > > > > EC variant at compile-time.
> > > > > 
> > > > > While here also fix the alignment in Kconfig file for this config 
> > > > > option
> > > > > replacing the spaces by tabs.
> > > > > 
> > > > > Signed-off-by: Enric Balletbo i Serra 
> > > > > ---
> > > > > Hi,
> > > > > 
> > > > > This is the second attempt to solve the issue to be able to select at
> > > > > runtime the CrOS MEC variant. My first thought was check for a device
> > > > > ID,
> > > > > the MEC1322 has a register that contains the device ID, however I am 
> > > > > not
> > > > > sure if we can read that register from the host without modifying the
> > > > > firmware. Also, I am not sure if the MEC1322 is the only device used
> > > > > that supports that LPC protocol variant, so I ended with a more easy
> > > > > solution, check if the protocol fails or not. Some background on this
> > > > > issue can be found [1] and [2]
> > > > > 
> > > > > The patch has been tested on:
> > > > >  - Acer Chromebook R11 (Cyan - MEC variant)
> > > > >  - Pixel Chromebook 2015 (Samus - non-MEC variant)
> > > > >  - Dell Chromebook 11 (Wolf - non-MEC variant)
> > > > >  - Toshiba Chromebook (Leon - non-MEC variant)
> > > > > 
> > > > > Nick, could you test the patch for Wilco?
> > > > > 
> > > > > Best regards,
> > > > >  Enric
> > > > > 
> > > > > [1] https://bugs.chromium.org/p/chromium/issues/detail?id=932626
> > > > > [2] 
> > > > > https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1474254
> > > > > 
> > > > > Changes in v2:
> > > > > - Remove global bool to indicate the kind of variant as suggested by 
> > > > > Ezequiel.
> > > > > - Create an internal operations struct to allow different variants.
> > > > > 
> > > > >  drivers/platform/chrome/Kconfig   | 29 +++--
> > > > >  drivers/platform/chrome/Makefile  |  3 +-
> > > > >  drivers/platform/chrome/cros_ec_lpc.c | 76 
> > > > > ---
> > > > >  drivers/platform/chrome/cros_ec_lpc_reg.c | 39 +++-
> > > > >  drivers/platform/chrome/cros_ec_lpc_reg.h | 26 
> > > > >  drivers/platform/chrome/wilco_ec/Kconfig  |  2 +-
> > > > >  6 files changed, 98 insertions(+), 77 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/platform/chrome/Kconfig 
> > > > > b/drivers/platform/chrome/Kconfig
> > > > > index 2826f7136f65..453e69733842 100644
> > > > > --- a/drivers/platform/chrome/Kconfig
> > > > > +++ b/drivers/platform/chrome/Kconfig
> > > > > @@ -83,28 +83,17 @@ config CROS_EC_SPI
> > > > > 'pre-amble' bytes before the response actually starts.
> > > > > 
> > > > >  config CROS_EC_LPC
> > > > > -tristate "ChromeOS Embedded Controller (LPC)"
> > > > > -depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST)
> > > > > -help
> > > > > -  If you say Y here, you get support for talking to the 
> > > > > ChromeOS EC
> > > > > -  over an LPC bus. This uses a simple byte-level protocol 
> > > > > with a
> > > > > -  checksum. This is used for userspace access only. The 
> > > > > kernel
> > > > > -  typically has its own communication methods.
> > > > > -
> > > > > -  To compile this driver as a module, choose M here: the
> > > > > -  module will be called cros_ec_lpc.
> > > > > -
> > > > > -config CROS_EC_LPC_MEC
> > > > > - bool "ChromeOS Embedded Controller LPC Microchip EC (MEC) 
> > > > > variant"

[PATCH] lib/genalloc.c: Avoid de-referencing NULL pool

[Florian Fainelli]

With architectures allowing the kernel to be placed almost arbitrarily
in memory (e.g.: ARM64), it is possible to have the kernel resides at
physical addresses above 4GB, resulting in neither the default CMA area,
nor the atomic pool from successfully allocating. This does not prevent
specific peripherals from working though, one example is XHCI, which
still operates correctly.

Trouble comes when the XHCI driver gets suspended and resumed, since we
can now trigger the following NPD:

[   12.664170] usb usb1: root hub lost power or was reset
[   12.669387] usb usb2: root hub lost power or was reset
[   12.674662] Unable to handle kernel NULL pointer dereference at virtual 
address 0008
[   12.682896] pgd = ffc1365a7000
[   12.686386] [0008] *pgd=00013653, *pud=00013653, 
*pmd=
[   12.694897] Internal error: Oops: 9606 [#1] SMP
[   12.699843] Modules linked in:
[   12.702980] CPU: 0 PID: 1499 Comm: pml Not tainted 4.9.135-1.13pre #51
[   12.709577] Hardware name: BCM97268DV (DT)
[   12.713736] task: ffc136bb6540 task.stack: ffc1366cc000
[   12.719740] PC is at addr_in_gen_pool+0x4/0x48
[   12.724253] LR is at __dma_free+0x64/0xbc
[   12.728325] pc : [] lr : [] pstate: 
6145
[   12.735825] sp : ffc1366cf990
[   12.739196] x29: ffc1366cf990 x28: ffc1366cc000
[   12.744608] x27:  x26: ffc13a8568c8
[   12.750020] x25:  x24: ff80098f9000
[   12.755433] x23: 00013a5ff000 x22: ff8009c57000
[   12.760844] x21: ffc13a856810 x20: 
[   12.766255] x19: 1000 x18: 000a
[   12.771667] x17: 007f917553e0 x16: 1002
[   12.777078] x15: 000a36cb x14: ff80898feb77
[   12.782490] x13:  x12: 0030
[   12.787899] x11: fffe x10: ff80098feb7f
[   12.793311] x9 : 05f5e0ff x8 : 65776f702074736f
[   12.798723] x7 : 6c2062756820746f x6 : ff80098febb1
[   12.804134] x5 : ff800809797c x4 : 
[   12.809545] x3 : 00013a5ff000 x2 : 0fff
[   12.814955] x1 : ff8009c57000 x0 : 
[   12.820363]
[   12.821907] Process pml (pid: 1499, stack limit = 0xffc1366cc020)
[   12.828421] Stack: (0xffc1366cf990 to 0xffc1366d)
[   12.834240] f980:   ffc1366cf9e0 
ff80086004d0
[   12.842186] f9a0: ffc13ab08238 0010 ff80097c2218 
ffc13a856810
[   12.850131] f9c0: ff8009c57000 00013a5ff000 0008 
00013a5ff000
[   12.858076] f9e0: ffc1366cfa50 ff80085f9250 ffc13ab08238 
0004
[   12.866021] fa00: ffc13ab08000 ff80097b6000 ffc13ab08130 
0001
[   12.873966] fa20: 0008 ffc13a8568c8  
ffc1366cc000
[   12.881911] fa40: ffc13ab08130 0001 ffc1366cfa90 
ff80085e3de8
[   12.889856] fa60: ffc13ab08238  ffc136b75b00 

[   12.897801] fa80: 0010 ff80089ccb92 ffc1366cfac0 
ff80084ad040
[   12.905746] faa0: ffc13a856810  ff80084ad004 
ff80084b91a8
[   12.913691] fac0: ffc1366cfae0 ff80084b91b4 ffc13a856810 
ff80080db5cc
[   12.921636] fae0: ffc1366cfb20 ff80084b96bc ffc13a856810 
0010
[   12.929581] fb00: ffc13a856870  ffc13a856810 
ff800984d2b8
[   12.937526] fb20: ffc1366cfb50 ff80084baa70 ff8009932ad0 
ff800984d260
[   12.945471] fb40: 0010 0002eff0a065 ffc1366cfbb0 
ff80084bafbc
[   12.953415] fb60: 0010 0003 ff80098fe000 

[   12.961360] fb80: ff80097b6000 ff80097b6dc8 ff80098c12b8 
ff80098c12f8
[   12.969306] fba0: ff8008842000 ff80097b6dc8 ffc1366cfbd0 
ff80080e0d88
[   12.977251] fbc0: fffb ff80080e10bc ffc1366cfc60 
ff80080e16a8
[   12.985196] fbe0:  0003 ff80097b6000 
ff80098fe9f0
[   12.993140] fc00: ff80097d4000 ff8008983802 0123 
0040
[   13.001085] fc20: ff8008842000 ffc1366cc000 ff80089803c2 

[   13.009029] fc40:   ffc1366cfc60 
00040987
[   13.016974] fc60: ffc1366cfcc0 ff80080dfd08 0003 
0004
[   13.024919] fc80: 0003 ff80098fea08 ffc136577ec0 
ff80089803c2
[   13.032864] fca0: 0123 0001 00050002 
00040987
[   13.040809] fcc0: ffc1366cfd00 ff80083a89d4 0004 
ffc136577ec0
[   13.048754] fce0: ffc136610cc0 ffea ffc1366cfeb0 
ffc136610cd8
[   13.056700] fd00: ffc1366cfd10 ff800822a614 ffc1366cfd40 
ff80082295d4
[   13.064645] fd20: 0004 ffc136577ec0 

Re: [PATCH] ubifs: Add support for zstd compression.

[Emil Lenngren]

Hi,

Den fre 7 juni 2019 kl 22:49 skrev Richard Weinberger :
>
> - Ursprüngliche Mail -
> > Von: "Emil Lenngren" 
> > An: "richard" 
> > CC: "linux-mtd" , "Sebastian Andrzej 
> > Siewior" , "linux-kernel"
> > , "Michele Dionisio" 
> > 
> > Gesendet: Freitag, 7. Juni 2019 22:27:09
> > Betreff: Re: [PATCH] ubifs: Add support for zstd compression.
> >> So I'm not sure what is the best choice for the default filesystem.
> >
> > My idea was at the end, i.e. it will only be used when LZO and ZLIB
> > are not selected to be included for UBIFS, for example when someone
> > compiles a minimal kernel who knows exactly which compression
> > algorithms will be used on that system.
>
> BTW: you can always select the compressor using the compr= mount option.
> Also for the default filesystem.

Yep that's what I'm using while I'm testing.

> Putting it at the end does not harm but IMHO the use is little.
> But for the sake of completes, I agree with you. Can you send a follow-up
> patch?

Ok

>
> > I did a single test today and compared lzo and zstd and on that test
> > lzo had faster decompression speed but resulted in larger space. I'll
> > do more tests later.
>
> Can you please share more details? I'm interested what CPU this was.

ARM Cortex-A7. The kernel is compiled with gcc 7.3.1. Next week I'll
test some more.
I have a question about how the decompression is done while reading.
When a large file is read from the filesystem (assuming not in any
cache), is it the case that first a chunk is read from flash, that
chunk is then decompressed, later next chunk is read from flash, that
one is then decompressed and so on, or can the decompression be done
in parallel while reading the next chunk from flash?

/Emil

Re: [RFC PATCH v3 13/16] sched: Add core wide task selection and scheduling.

[Pawan Gupta]

On Wed, May 29, 2019 at 08:36:49PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra 
> 
> Instead of only selecting a local task, select a task for all SMT
> siblings for every reschedule on the core (irrespective which logical
> CPU does the reschedule).
> 
> NOTE: there is still potential for siblings rivalry.
> NOTE: this is far too complicated; but thus far I've failed to
>   simplify it further.

Looks like there are still some race conditions while bringing cpu
online/offline. I am seeing an easy to reproduce panic when turning SMT on/off
in a loop with core scheduling ON. I dont see the panic with core scheduling
OFF.

Steps to reproduce:

mkdir /sys/fs/cgroup/cpu/group1
mkdir /sys/fs/cgroup/cpu/group2
echo 1 > /sys/fs/cgroup/cpu/group1/cpu.tag
echo 1 > /sys/fs/cgroup/cpu/group2/cpu.tag

echo $$ > /sys/fs/cgroup/cpu/group1/tasks

while [ 1 ];  do
echo on  > /sys/devices/system/cpu/smt/control
echo off > /sys/devices/system/cpu/smt/control
done

Panic logs:
[  274.629437] BUG: unable to handle kernel NULL pointer dereference at
0024
[  274.630366] #PF error: [normal kernel read fault]
[  274.630933] PGD 80003e52c067 P4D 80003e52c067 PUD 0
[  274.631613] Oops:  [#1] SMP PTI
[  274.632016] CPU: 0 PID: 1470 Comm: bash Tainted: GW
5.1.4+ #33
[  274.632854] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29
04/01/2014
[  274.634248] RIP: 0010:__schedule+0x9d4/0x1350
[  274.634699] Code: da 0f 83 21 04 00 00 48 8b 35 70 f3 ab 00 48 c7 c7
51 1c a8 81 e8 4c 4e 6b ff 49 8b 85 b8 0b 00 00 48 85 c0 0f 84 2f 09 00
01
[  274.636648] RSP: 0018:c98f3ca8 EFLAGS: 00010046
[  274.637197] RAX:  RBX: 0001 RCX:
0040
[  274.637941] RDX:  RSI:  RDI:
82544890
[  274.638691] RBP: c98f3d40 R08: 04c7 R09:
0030
[  274.639449] R10: 0001 R11: c98f3b28 R12:
88803d2d0e80
[  274.640172] R13: 88803eaa0a40 R14: 88803ea20a40 R15:
88803d2d0e80
[  274.640915] FS:  () GS:88803ea0(0063)
knlGS:f7f8b780
[  274.641755] CS:  0010 DS: 002b ES: 002b CR0: 80050033
[  274.642355] CR2: 0024 CR3: 3c01a005 CR4:
00360ef0
[  274.643135] DR0:  DR1:  DR2:

[  274.643995] DR3:  DR6: fffe0ff0 DR7:
0400
[  274.645023] Call Trace:
[  274.645336]  schedule+0x28/0x70
[  274.645621]  native_cpu_up+0x271/0x6d0
[  274.645959]  ? cpus_read_trylock+0x40/0x40
[  274.646324]  bringup_cpu+0x2d/0xe0
[  274.646631]  cpuhp_invoke_callback+0x94/0x550
[  274.647032]  ? ring_buffer_record_is_set_on+0x10/0x10
[  274.647478]  _cpu_up+0xa9/0x140
[  274.647763]  store_smt_control+0x1cb/0x260
[  274.648132]  kernfs_fop_write+0x108/0x190
[  274.648498]  vfs_write+0xa5/0x1a0
[  274.648794]  ksys_write+0x57/0xd0
[  274.649100]  do_fast_syscall_32+0x92/0x220
[  274.649468]  entry_SYSENTER_compat+0x7c/0x8e


NULL pointer exception is triggered when sibling is offline during core task
pick in pick_next_task() leaving rq_i->core_pick = NULL and if sibling comes
online before the "Reschedule siblings" block in the same function it causes
panic in is_idle_task(rq_i->core_pick).

Traces for the scenario:
[ 274.599567] bash-1470 0d... 273921815us : __schedule: cpu(0) is online during 
core_pick 
[ 274.600339] bash-1470 0d... 273921816us : __schedule: cpu(1) is offline 
during core_pick 
[ 274.601106] bash-1470 0d... 273921816us : __schedule: picked: bash/1470 
88803cb9c000 
[ 274.602106] bash-1470 0d... 273921816us : __schedule: cpu(0) is online.. 
during Reschedule siblings 
[ 274.603219] bash-1470 0d... 273921816us : __schedule: cpu(1) is online.. 
during Reschedule siblings 
[ 274.604333] -0 1d... 273921816us : start_secondary: cpu(1) is online 
now 
[ 274.605239] bash-1470 0d... 273922148us : __schedule: rq_i->core_pick on 
cpu(1) is NULL

I am not able to reproduce the panic after the below change. Not sure if this
is the right fix. Maybe we don't have to allow cpus to go online/offline while
pick_next_task() is executing.

-- 8< ---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 90655c9ad937..b230b095772a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3874,7 +3874,7 @@ next_class:;
for_each_cpu(i, smt_mask) {
struct rq *rq_i = cpu_rq(i);
 
-   if (cpu_is_offline(i))
+   if (cpu_is_offline(i) || !rq_i->core_pick)
continue;
 
WARN_ON_ONCE(!rq_i->core_pick);

Re: [PATCH bpf v2] xdp: fix hang while unregistering device bound to xdp socket

[Jakub Kicinski]

On Fri,  7 Jun 2019 20:31:43 +0300, Ilya Maximets wrote:
> +static int xsk_notifier(struct notifier_block *this,
> + unsigned long msg, void *ptr)
> +{
> + struct sock *sk;
> + struct net_device *dev = netdev_notifier_info_to_dev(ptr);
> + struct net *net = dev_net(dev);
> + int i, unregister_count = 0;

Please order the var declaration lines longest to shortest.
(reverse christmas tree)

> + mutex_lock(>xdp.lock);
> + sk_for_each(sk, >xdp.list) {
> + struct xdp_sock *xs = xdp_sk(sk);
> +
> + mutex_lock(>mutex);
> + switch (msg) {
> + case NETDEV_UNREGISTER:

You should probably check the msg type earlier and not take all the
locks and iterate for other types..

Re: [PATCH] RISC-V: defconfig: enable clocks, serial console

[Kevin Hilman]

Palmer,

Kevin Hilman  writes:

> Enable PRCI clock driver and serial console by default, so the default
> upstream defconfig is bootable to a serial console.
>
> Signed-off-by: Kevin Hilman 

If possible, this would be great to have for v5.2-rc so we have a
bootable upstream defconfig ready for kernelCI as soon as the DT series
lands.

Kevin

Re: [PATCH v2] pinctrl: tb10x: Use flexible-array member and struct_size() helper

[Linus Walleij]

On Fri, Jun 7, 2019 at 1:11 AM Gustavo A. R. Silva
 wrote:

> Update the code to use a flexible array member instead of a pointer in
> structure tb10x_pinctrl and use the struct_size() helper:
>
> struct tb10x_pinctrl {
> ...
> struct tb10x_of_pinfunc pinfuncs[];
> };
>
> Also, make use of the struct_size() helper instead of an open-coded
> version in order to avoid any potential type mistakes.
>
> So, replace the following form:
>
> sizeof(struct tb10x_pinctrl) + of_get_child_count(of_node) * sizeof(struct 
> tb10x_of_pinfunc)
>
> with:
>
> struct_size(state, pinfuncs, of_get_child_count(of_node))
>
> This code was detected with the help of Coccinelle.
>
> Reviewed-by: Kees Cook 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> Changes in v2:
>  - Update changelog text.
>  - Add Kees' Reviewed-by tag.

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v4 0/6] MSM8998 Multimedia Clock Controller

[Stephen Boyd]

Quoting Jeffrey Hugo (2019-06-07 14:31:13)
> On Fri, Jun 7, 2019 at 2:38 PM Stephen Boyd  wrote:
> >
> > Quoting Jeffrey Hugo (2019-05-21 07:52:28)
> > > On 5/21/2019 8:44 AM, Jeffrey Hugo wrote:
> > > > The multimedia clock controller (mmcc) is the main clock controller for
> > > > the multimedia subsystem and is required to enable things like display 
> > > > and
> > > > camera.
> > >
> > > Stephen, I think this series is good to go, and I have display/gpu stuff
> > > I'm polishing that will depend on this.  Would you kindly pickup patches
> > > 1, 3, 4, and 5 for 5.3?  I can work with Bjorn to pick up patches 2 and 6.
> > >
> >
> > If I apply patch 3 won't it break boot until patch 2 is also in the
> > tree? That seems to imply that I'll break bisection, and we have
> > kernelci boot testing clk-next so this will probably set off alarms
> > somewhere.
> 
> Yes, it'll break boot.  Maybe you and Bjorn can make a deal?  (more below)
> 
> Doesn't look like kernelci is running tests on 8998 anymore, so maybe
> no one will complain?  As far as I am aware, Marc, Lee, Bjorn, and I
> are the only ones whom care about 8998 presently, and I think we are
> all good with a temporary breakage in order to get this basic
> functionality in since the platform isn't really well supported yet.

Ok.

> 
> >
> > I thought we had some code that got removed that was going to make the
> > transition "seamless" in the sense that it would search the tree for an
> > RPM clk controller and then not add the XO fixed factor clk somehow.
> > See commit 54823af9cd52 ("clk: qcom: Always add factor clock for xo
> > clocks") for the code that we removed. So ideally we do something like
> > this too, but now we search for a property on the calling node to see if
> > the XO clk is there?
> >
> 
> Trying to remember back a bit.
> 
> I don't think its possible.  Maybe I'm wrong.  I didn't see a solution
> to the below:
> 
> How does GCC know the following?
> -RPMCC is compiled in the build (I guess this can be assumed)

This is the IS_ENABLED part.

> -RPMCC has probed
> -RPMCC is not and will not be providing XO

Presumably if it's enabled then it will be providing XO at some point in
the future. I'm not suggesting the probe defer logic is removed, just
that we don't get into a state where clk tree has merged all the patches
for clk driver side and that then relies on DT to provide the clk but it
doesn't do that.

So the idea is to check if RPM is compiled in and also check the GCC DT
node for the clocks property having the xo clk there. Then we assume
that we have the clk patches in place for the RPM clk driver to provide
that clk and we skip inserting the fake clk that RPM is going to
provide.

This is also a "general" solution to GCC not depending on or selecting
the RPM clk driver. It may be better to just have a select statement in
GCC Kconfig so that we can't enable the GCC driver without also enabling
the RPM driver if it's an essential dependency to the clk tree working.
But if we do this design then we can make the clk tree keep working
regardless of RPM being there or not, which may be a good thing.

[PATCH v5 00/13] Allwinner A64/H6 IR support

[Clément Péron]

Hi,

A64 IR support series[1] pointed out that an A31 bindings should be
introduced.

This series introduce the A31 compatible bindings, then switch it on
the already existing board.

Finally introduce A64 and H6 support.

I have reenable the other H6 boards IR support as Ondrej solve the issue.

Regards,
Clément

[1] https://lore.kernel.org/patchwork/patch/1031390/#1221464
[2] https://lkml.org/lkml/2019/5/27/321
[3] https://patchwork.kernel.org/patch/10975563/

Changes since v4:
 - Reuse defines for RXSTA bits definition

Changes since v3:
 - Reenable IR for other H6 boards
 - Add RXSTA bits definition
 - Add Sean Young's "Acked-by" tags

Changes since v2:
 - Disable IR for other H6 boards
 - Split DTS patch for H3/H5
 - Introduce IR quirks

Clément Péron (11):
  dt-bindings: media: sunxi-ir: Add A31 compatible
  media: rc: Introduce sunxi_ir_quirks
  media: rc: sunxi: Add A31 compatible
  media: rc: sunxi: Add RXSTA bits definition
  ARM: dts: sunxi: Prefer A31 bindings for IR
  ARM: dts: sunxi: Prefer A31 bindings for IR
  dt-bindings: media: sunxi-ir: Add A64 compatible
  dt-bindings: media: sunxi-ir: Add H6 compatible
  arm64: dts: allwinner: h6: Add IR receiver node
  arm64: dts: allwinner: h6: Enable IR on H6 boards
  arm64: defconfig: Enable IR SUNXI option

Igors Makejevs (1):
  arm64: dts: allwinner: a64: Add IR node

Jernej Skrabec (1):
  arm64: dts: allwinner: a64: Enable IR on Orange Pi Win

 .../devicetree/bindings/media/sunxi-ir.txt| 11 ++-
 arch/arm/boot/dts/sun6i-a31.dtsi  |  2 +-
 arch/arm/boot/dts/sun8i-a83t.dtsi |  2 +-
 arch/arm/boot/dts/sun9i-a80.dtsi  |  2 +-
 arch/arm/boot/dts/sunxi-h3-h5.dtsi|  2 +-
 .../dts/allwinner/sun50i-a64-orangepi-win.dts |  4 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 18 
 .../dts/allwinner/sun50i-h6-beelink-gs1.dts   |  4 +
 .../dts/allwinner/sun50i-h6-orangepi.dtsi |  4 +
 .../boot/dts/allwinner/sun50i-h6-pine-h64.dts |  4 +
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi  | 19 
 arch/arm64/configs/defconfig  |  1 +
 drivers/media/rc/sunxi-cir.c  | 88 ++-
 13 files changed, 135 insertions(+), 26 deletions(-)

-- 
2.20.1

[PATCH v5 03/13] media: rc: sunxi: Add A31 compatible

[Clément Péron]

Allwiner A31 has a different memory mapping so add the compatible
we will need it later.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
Acked-by: Maxime Ripard 
---
 drivers/media/rc/sunxi-cir.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index d02dcb6fd0a5..0504ebfc831f 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -343,6 +343,11 @@ static const struct sunxi_ir_quirks sun5i_a13_ir_quirks = {
.fifo_size = 64,
 };
 
+static const struct sunxi_ir_quirks sun6i_a31_ir_quirks = {
+   .has_reset = true,
+   .fifo_size = 64,
+};
+
 static const struct of_device_id sunxi_ir_match[] = {
{
.compatible = "allwinner,sun4i-a10-ir",
@@ -352,6 +357,10 @@ static const struct of_device_id sunxi_ir_match[] = {
.compatible = "allwinner,sun5i-a13-ir",
.data = _a13_ir_quirks,
},
+   {
+   .compatible = "allwinner,sun6i-a31-ir",
+   .data = _a31_ir_quirks,
+   },
{}
 };
 MODULE_DEVICE_TABLE(of, sunxi_ir_match);
-- 
2.20.1

[PATCH v5 13/13] arm64: defconfig: Enable IR SUNXI option

[Clément Péron]

Enable CONFIG_IR_SUNXI option for ARM64, so that Allwinner A64/H6 SoCs
can use their IR receiver controller.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4d583514258c..5128029100d2 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -460,6 +460,7 @@ CONFIG_RC_CORE=m
 CONFIG_RC_DECODERS=y
 CONFIG_RC_DEVICES=y
 CONFIG_IR_MESON=m
+CONFIG_IR_SUNXI=m
 CONFIG_MEDIA_SUPPORT=m
 CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
-- 
2.20.1

[PATCH v5 10/13] dt-bindings: media: sunxi-ir: Add H6 compatible

[Clément Péron]

There are some minor differences between A31 or A64 with H6 IR peripheral.

But A31 IR driver is compatible with H6.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 Documentation/devicetree/bindings/media/sunxi-ir.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 1dd287a4ab3a..81eaf95fb764 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -6,6 +6,7 @@ Required properties:
"allwinner,sun5i-a13-ir"
"allwinner,sun6i-a31-ir"
"allwinner,sun50i-a64-ir", "allwinner,sun6i-a31-ir"
+   "allwinner,sun50i-h6-ir", "allwinner,sun6i-a31-ir"
 - clocks   : list of clock specifiers, corresponding to
  entries in clock-names property;
 - clock-names  : should contain "apb" and "ir" entries;
-- 
2.20.1

[PATCH v5 11/13] arm64: dts: allwinner: h6: Add IR receiver node

[Clément Péron]

Allwinner H6 IR is similar to A31 and can use same driver.

Add support for it.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 16c5c3d0fd81..649cbdfe452e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -647,6 +647,25 @@
pins = "PL0", "PL1";
function = "s_i2c";
};
+
+   r_ir_rx_pin: r-ir-rx-pin {
+   pins = "PL9";
+   function = "s_cir_rx";
+   };
+   };
+
+   r_ir: ir@704 {
+   compatible = "allwinner,sun50i-h6-ir",
+"allwinner,sun6i-a31-ir";
+   reg = <0x0704 0x400>;
+   interrupts = ;
+   clocks = <_ccu CLK_R_APB1_IR>,
+<_ccu CLK_IR>;
+   clock-names = "apb", "ir";
+   resets = <_ccu RST_R_APB1_IR>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_ir_rx_pin>;
+   status = "disabled";
};
 
r_i2c: i2c@7081400 {
-- 
2.20.1

[PATCH v5 06/13] ARM: dts: sunxi: Prefer A31 bindings for IR

[Clément Péron]

Since A31, memory mapping of the IR driver has changed.

Prefer the A31 bindings instead of A13.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 arch/arm/boot/dts/sunxi-h3-h5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index 84977d4eb97a..f0f5ba349c1b 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -822,7 +822,7 @@
};
 
ir: ir@1f02000 {
-   compatible = "allwinner,sun5i-a13-ir";
+   compatible = "allwinner,sun6i-a31-ir";
clocks = <_ccu CLK_APB0_IR>, <_ccu CLK_IR>;
clock-names = "apb", "ir";
resets = <_ccu RST_APB0_IR>;
-- 
2.20.1

[PATCH v5 12/13] arm64: dts: allwinner: h6: Enable IR on H6 boards

[Clément Péron]

Beelink GS1, OrangePi H6 boards and Pine H64 have an IR receiver.

Enable it in their device-tree.

Signed-off-by: Clément Péron 
---
 arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 4 
 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi   | 4 
 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts| 4 
 3 files changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 0dc33c90dd60..680dc29cb089 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -232,6 +232,10 @@
};
 };
 
+_ir {
+   status = "okay";
+};
+
 _pio {
/*
 * PL0 and PL1 are used for PMIC I2C
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
index 62e27948a3fa..ec9b6a578e3f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
@@ -189,6 +189,10 @@
};
 };
 
+_ir {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_ph_pins>;
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index 4802902e128f..ae12ee4fcc77 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -247,6 +247,10 @@
};
 };
 
+_ir {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_ph_pins>;
-- 
2.20.1

[PATCH v5 04/13] media: rc: sunxi: Add RXSTA bits definition

[Clément Péron]

We are using RXINT bits definition when looking at RXSTA register.

These bits are equal but it's not really proper.

Introduce the RXSTA bits and use them to have coherency.

Signed-off-by: Clément Péron 
---
 drivers/media/rc/sunxi-cir.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 0504ebfc831f..5690d0bd51bc 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -48,11 +48,11 @@
 
 /* Rx Interrupt Enable */
 #define SUNXI_IR_RXINT_REG0x2C
-/* Rx FIFO Overflow */
+/* Rx FIFO Overflow Interrupt Enable */
 #define REG_RXINT_ROI_EN   BIT(0)
-/* Rx Packet End */
+/* Rx Packet End Interrupt Enable */
 #define REG_RXINT_RPEI_EN  BIT(1)
-/* Rx FIFO Data Available */
+/* Rx FIFO Data Available Interrupt Enable */
 #define REG_RXINT_RAI_EN   BIT(4)
 
 /* Rx FIFO available byte level */
@@ -60,6 +60,12 @@
 
 /* Rx Interrupt Status */
 #define SUNXI_IR_RXSTA_REG0x30
+/* Rx FIFO Overflow */
+#define REG_RXSTA_ROI  REG_RXINT_ROI_EN
+/* Rx Packet End */
+#define REG_RXSTA_RPE  REG_RXINT_RPEI_EN
+/* Rx FIFO Data Available */
+#define REG_RXSTA_RA   REG_RXINT_RAI_EN
 /* RX FIFO Get Available Counter */
 #define REG_RXSTA_GET_AC(val) (((val) >> 8) & (ir->fifo_size * 2 - 1))
 /* Clear all interrupt status value */
@@ -119,7 +125,7 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* clean all pending statuses */
writel(status | REG_RXSTA_CLEARALL, ir->base + SUNXI_IR_RXSTA_REG);
 
-   if (status & (REG_RXINT_RAI_EN | REG_RXINT_RPEI_EN)) {
+   if (status & (REG_RXSTA_RA | REG_RXSTA_RPE)) {
/* How many messages in fifo */
rc  = REG_RXSTA_GET_AC(status);
/* Sanity check */
@@ -135,9 +141,9 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
}
}
 
-   if (status & REG_RXINT_ROI_EN) {
+   if (status & REG_RXSTA_ROI) {
ir_raw_event_reset(ir->rc);
-   } else if (status & REG_RXINT_RPEI_EN) {
+   } else if (status & REG_RXSTA_RPE) {
ir_raw_event_set_idle(ir->rc, true);
ir_raw_event_handle(ir->rc);
}
-- 
2.20.1

[PATCH v5 09/13] arm64: dts: allwinner: a64: Enable IR on Orange Pi Win

[Clément Péron]

From: Jernej Skrabec 

OrangePi Win board contains IR receiver. Enable it.

Signed-off-by: Jernej Skrabec 
Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
index 510f661229dc..e05191b71adf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-orangepi-win.dts
@@ -180,6 +180,10 @@
status = "okay";
 };
 
+_ir {
+   status = "okay";
+};
+
 _rsb {
status = "okay";
 
-- 
2.20.1

[PATCH v5 05/13] ARM: dts: sunxi: Prefer A31 bindings for IR

[Clément Péron]

Since A31, memory mapping of the IR driver has changed.

Prefer the A31 bindings instead of A13.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 arch/arm/boot/dts/sun6i-a31.dtsi  | 2 +-
 arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
 arch/arm/boot/dts/sun9i-a80.dtsi  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index c04efad81bbc..110622b30796 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -1351,7 +1351,7 @@
};
 
ir: ir@1f02000 {
-   compatible = "allwinner,sun5i-a13-ir";
+   compatible = "allwinner,sun6i-a31-ir";
clocks = <_gates 1>, <_clk>;
clock-names = "apb", "ir";
resets = <_rst 1>;
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 392b0cabbf0d..8d603f3309f2 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -1067,7 +1067,7 @@
 
r_cir: ir@1f02000 {
compatible = "allwinner,sun8i-a83t-ir",
-   "allwinner,sun5i-a13-ir";
+   "allwinner,sun6i-a31-ir";
clocks = <_ccu CLK_APB0_IR>, <_ccu CLK_IR>;
clock-names = "apb", "ir";
resets = <_ccu RST_APB0_IR>;
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index 0c1eec9000e3..310cd972ee5b 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -1167,7 +1167,7 @@
};
 
r_ir: ir@8002000 {
-   compatible = "allwinner,sun5i-a13-ir";
+   compatible = "allwinner,sun6i-a31-ir";
interrupts = ;
pinctrl-names = "default";
pinctrl-0 = <_ir_pins>;
-- 
2.20.1

[PATCH v5 08/13] arm64: dts: allwinner: a64: Add IR node

[Clément Péron]

From: Igors Makejevs 

IR peripheral is completely compatible with A31 one.

Signed-off-by: Igors Makejevs 
Signed-off-by: Jernej Skrabec 
Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 8c5b521e6389..b22b0aa89515 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -1072,6 +1072,19 @@
#size-cells = <0>;
};
 
+   r_ir: ir@1f02000 {
+   compatible = "allwinner,sun50i-a64-ir",
+"allwinner,sun6i-a31-ir";
+   reg = <0x01f02000 0x400>;
+   clocks = <_ccu CLK_APB0_IR>, <_ccu CLK_IR>;
+   clock-names = "apb", "ir";
+   resets = <_ccu RST_APB0_IR>;
+   interrupts = ;
+   pinctrl-names = "default";
+   pinctrl-0 = <_ir_rx_pin>;
+   status = "disabled";
+   };
+
r_pwm: pwm@1f03800 {
compatible = "allwinner,sun50i-a64-pwm",
 "allwinner,sun5i-a13-pwm";
@@ -1099,6 +1112,11 @@
function = "s_i2c";
};
 
+   r_ir_rx_pin: r-ir-rx-pin {
+   pins = "PL11";
+   function = "s_cir_rx";
+   };
+
r_pwm_pin: r-pwm-pin {
pins = "PL10";
function = "s_pwm";
-- 
2.20.1

[PATCH v5 01/13] dt-bindings: media: sunxi-ir: Add A31 compatible

[Clément Péron]

Allwinner A31 has introduced a new memory mapping and a
reset line.

The difference in memory mapping are :

- In the configure register there is a new sample bit
  and Allwinner has introduced the active threshold feature.

- In the status register a new STAT bit is present.

Note: CGPO and DRQ_EN bits are removed on A31 but present on A13
and on new SoCs like A64/H6.
This is actually not an issue as these bits are togglable and new
SoCs have a dedicated bindings.

Introduce this bindings to make a difference since this generation.
And declare the reset line required since A31.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
Acked-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/media/sunxi-ir.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 278098987edb..2e59a32a7e33 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -1,16 +1,21 @@
 Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
 
 Required properties:
-- compatible   : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
+- compatible   :
+   "allwinner,sun4i-a10-ir"
+   "allwinner,sun5i-a13-ir"
+   "allwinner,sun6i-a31-ir"
 - clocks   : list of clock specifiers, corresponding to
  entries in clock-names property;
 - clock-names  : should contain "apb" and "ir" entries;
 - interrupts   : should contain IR IRQ number;
 - reg  : should contain IO map address for IR.
 
+Required properties since A31:
+- resets   : phandle + reset specifier pair
+
 Optional properties:
 - linux,rc-map-name: see rc.txt file in the same directory.
-- resets : phandle + reset specifier pair
 - clock-frequency  : IR Receiver clock frequency, in Hertz. Defaults to 8 MHz
 if missing.
 
-- 
2.20.1

[PATCH v5 02/13] media: rc: Introduce sunxi_ir_quirks

[Clément Péron]

This driver is used in various Allwinner SoC with different configuration.

Introduce a quirks struct to know the fifo size and if a reset is required.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
Acked-by: Maxime Ripard 
---
 drivers/media/rc/sunxi-cir.c | 61 +++-
 1 file changed, 47 insertions(+), 14 deletions(-)

diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 307e44714ea0..d02dcb6fd0a5 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -81,6 +81,17 @@
 /* Time after which device stops sending data in ms */
 #define SUNXI_IR_TIMEOUT  120
 
+/**
+ * struct sunxi_ir_quirks - Differences between SoC variants.
+ *
+ * @has_reset: SoC needs reset deasserted.
+ * @fifo_size: size of the fifo.
+ */
+struct sunxi_ir_quirks {
+   boolhas_reset;
+   int fifo_size;
+};
+
 struct sunxi_ir {
spinlock_t  ir_lock;
struct rc_dev   *rc;
@@ -143,6 +154,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
 
struct device *dev = >dev;
struct device_node *dn = dev->of_node;
+   const struct sunxi_ir_quirks *quirks;
struct resource *res;
struct sunxi_ir *ir;
u32 b_clk_freq = SUNXI_IR_BASE_CLK;
@@ -151,12 +163,15 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (!ir)
return -ENOMEM;
 
+   quirks = of_device_get_match_data(>dev);
+   if (quirks == NULL) {
+   dev_err(>dev, "Failed to determine the quirks to use\n");
+   return -ENODEV;
+   }
+
spin_lock_init(>ir_lock);
 
-   if (of_device_is_compatible(dn, "allwinner,sun5i-a13-ir"))
-   ir->fifo_size = 64;
-   else
-   ir->fifo_size = 16;
+   ir->fifo_size = quirks->fifo_size;
 
/* Clock */
ir->apb_clk = devm_clk_get(dev, "apb");
@@ -173,13 +188,15 @@ static int sunxi_ir_probe(struct platform_device *pdev)
/* Base clock frequency (optional) */
of_property_read_u32(dn, "clock-frequency", _clk_freq);
 
-   /* Reset (optional) */
-   ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
-   if (IS_ERR(ir->rst))
-   return PTR_ERR(ir->rst);
-   ret = reset_control_deassert(ir->rst);
-   if (ret)
-   return ret;
+   /* Reset */
+   if (quirks->has_reset) {
+   ir->rst = devm_reset_control_get_exclusive(dev, NULL);
+   if (IS_ERR(ir->rst))
+   return PTR_ERR(ir->rst);
+   ret = reset_control_deassert(ir->rst);
+   if (ret)
+   return ret;
+   }
 
ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
@@ -316,10 +333,26 @@ static int sunxi_ir_remove(struct platform_device *pdev)
return 0;
 }
 
+static const struct sunxi_ir_quirks sun4i_a10_ir_quirks = {
+   .has_reset = false,
+   .fifo_size = 16,
+};
+
+static const struct sunxi_ir_quirks sun5i_a13_ir_quirks = {
+   .has_reset = false,
+   .fifo_size = 64,
+};
+
 static const struct of_device_id sunxi_ir_match[] = {
-   { .compatible = "allwinner,sun4i-a10-ir", },
-   { .compatible = "allwinner,sun5i-a13-ir", },
-   {},
+   {
+   .compatible = "allwinner,sun4i-a10-ir",
+   .data = _a10_ir_quirks,
+   },
+   {
+   .compatible = "allwinner,sun5i-a13-ir",
+   .data = _a13_ir_quirks,
+   },
+   {}
 };
 MODULE_DEVICE_TABLE(of, sunxi_ir_match);
 
-- 
2.20.1

[PATCH v5 07/13] dt-bindings: media: sunxi-ir: Add A64 compatible

[Clément Péron]

There are some minor differences between A31 and A64 driver.

But A31 IR driver is compatible with A64.

Signed-off-by: Clément Péron 
Acked-by: Sean Young 
---
 Documentation/devicetree/bindings/media/sunxi-ir.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt 
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 2e59a32a7e33..1dd287a4ab3a 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -5,6 +5,7 @@ Required properties:
"allwinner,sun4i-a10-ir"
"allwinner,sun5i-a13-ir"
"allwinner,sun6i-a31-ir"
+   "allwinner,sun50i-a64-ir", "allwinner,sun6i-a31-ir"
 - clocks   : list of clock specifiers, corresponding to
  entries in clock-names property;
 - clock-names  : should contain "apb" and "ir" entries;
-- 
2.20.1

Re: [PATCH 0/6] Add minimal boot support for IPQ6018

[Linus Walleij]

On Wed, Jun 5, 2019 at 7:16 PM Sricharan R  wrote:

> The IPQ6018 is Qualcomm’s 802.11ax SoC for Routers,
> Gateways and Access Points.
>
> This series adds minimal board boot support for ipq6018-cp01
> board.
>
> Sricharan R (6):
>   pinctrl: qcom: Add ipq6018 pinctrl driver
>   dt-bindings: qcom: Add ipq6018 bindings

I'm happy to merge these two if I can get a review from
Bjorn Andersson on them.

Yours,
Linus Walleij

Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel

[Adam Borowski]

On Fri, Jun 07, 2019 at 07:20:46PM +, Nick Terrell wrote:
> We'd love to get this mainlined as well!
> 
> We're using these patches internally as well. We're seeing an improvement on 
> an
> Intel Atom N3710, where boot time is reduced by one second over using an xz
> compressed kernel. It looks like Ubuntu just switched to a lz4 compressed 
> kernel,
> but zstd is likely a better trade off, because it compresses much better and 
> still has
> excellent decompression speed.
> 
> Since its been nearly a year since I sent these out, I will take some time to 
> rebase
> and retest the patches in case anything changed, and then then resend the 
> patches
> in the next weeks.

Hi!
After the ping, I intended to resend the patch-set (with removals included)
after I return from miniDebconf Hamburg, but you 1. are the author of the
non-trivial part, 2. you have a better test machinery, and 3. I have a
deeply seated preference for effort to be done by people who are not me.

A rebased and working version is at 
https://github.com/kilobyte/linux/tree/nobz2-v3
but there are no real improvements beyond rebases, a typo fix, and Paul Burton's
ACK for mips.

There's an unaddressed comment by Ingo Molnar
https://lore.kernel.org/lkml/20181112042200.ga96...@gmail.com/
for your part of the code.

So what do you suggest?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!

Re: [PATCH] ASoC: Intel: sst: fix kmalloc call with wrong flags

[Pierre-Louis Bossart]

On 6/7/19 5:19 PM, Alex Levin wrote:

When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset,
kmem_cache_alloc_trace is called.

In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball
slab_alloc, which will call slab_pre_alloc_hook which might_sleep_if.

The context in which it is called in this case, the
intel_sst_interrupt_mrfld, calling a sleeping kmalloc generates a BUG():


Thanks for reporting this and suggesting a fix.

I just checked and all our test configs have CONFIG_SLOB unset and 
CONFIG_TRACING=y, but I don't recall having seen this. Could you share 
your config so that we can see if we are missing something?




Fixes: 972b0d456e64 ("ASoC: Intel: remove GFP_ATOMIC, use GFP_KERNEL")

[   20.250671] BUG: sleeping function called from invalid context at 
mm/slab.h:422
[   20.250683] in_atomic(): 1, irqs_disabled(): 1, pid: 1791, name: 
Chrome_IOThread
[   20.250690] CPU: 0 PID: 1791 Comm: Chrome_IOThread Tainted: GW   
  4.19.43 #61
[   20.250693] Hardware name: GOOGLE Kefka, BIOS Google_Kefka.7287.337.0 
03/02/2017
[   20.250697] Call Trace:
[   20.250704]  
[   20.250716]  dump_stack+0x7e/0xc3
[   20.250725]  ___might_sleep+0x12a/0x140
[   20.250731]  kmem_cache_alloc_trace+0x53/0x1c5
[   20.250736]  ? update_cfs_rq_load_avg+0x17e/0x1aa
[   20.250740]  ? cpu_load_update+0x6c/0xc2
[   20.250746]  sst_create_ipc_msg+0x2d/0x88
[   20.250752]  intel_sst_interrupt_mrfld+0x12a/0x22c
[   20.250758]  __handle_irq_event_percpu+0x133/0x228
[   20.250764]  handle_irq_event_percpu+0x35/0x7a
[   20.250768]  handle_irq_event+0x36/0x55
[   20.250773]  handle_fasteoi_irq+0xab/0x16c
[   20.250779]  handle_irq+0xd9/0x11e
[   20.250785]  do_IRQ+0x54/0xe0
[   20.250791]  common_interrupt+0xf/0xf
[   20.250795]  
[   20.250800] RIP: 0010:__lru_cache_add+0x4e/0xad
[   20.250806] Code: 00 01 48 c7 c7 b8 df 01 00 65 48 03 3c 25 28 f1 00 00 48 8b 48 
08 48 89 ca 48 ff ca f6 c1 01 48 0f 44 d0 f0 ff 42 34 0f b6 0f <89> ca fe c2 88 
17 48 89 44 cf 08 80 fa 0f 74 0e 48 8b 08 66 85 c9
[   20.250809] RSP: :a568810bfd98 EFLAGS: 0202 ORIG_RAX: 
ffd6
[   20.250814] RAX: d3b904eb1940 RBX: d3b904eb1940 RCX: 0004
[   20.250817] RDX: d3b904eb1940 RSI: a10ee5c47450 RDI: a10efba1dfb8
[   20.250821] RBP: a568810bfda8 R08: a10ef9c741c1 R09: dead0100
[   20.250824] R10:  R11:  R12: a10ee8d52a40
[   20.250827] R13: a10ee8d52000 R14: a10ee5c47450 R15: 80013ac65067
[   20.250835]  lru_cache_add_active_or_unevictable+0x4e/0xb8
[   20.250841]  handle_mm_fault+0xd98/0x10c4
[   20.250848]  __do_page_fault+0x235/0x42d
[   20.250853]  ? page_fault+0x8/0x30
[   20.250858]  do_page_fault+0x3d/0x17a
[   20.250862]  ? page_fault+0x8/0x30
[   20.250866]  page_fault+0x1e/0x30
[   20.250872] RIP: 0033:0x7962fdea9304
[   20.250875] Code: 0f 11 4c 17 f0 c3 48 3b 15 f1 26 31 00 0f 83 e2 00 00 00 48 39 
f7 72 0f 74 12 4c 8d 0c 16 4c 39 cf 0f 82 63 01 00 00 48 89 d1  a4 c3 80 fa 
08 73 12 80 fa 04 73 1e 80 fa 01 77 26 72 05 0f b6
[   20.250879] RSP: 002b:7962f4db5468 EFLAGS: 00010206
[   20.250883] RAX: 3c8cc9d47008 RBX:  RCX: 1b48
[   20.250886] RDX: 2b40 RSI: 3c8cc9551000 RDI: 3c8cc9d48000
[   20.250890] RBP: 7962f4db5820 R08:  R09: 3c8cc9552b48
[   20.250893] R10: 562dd1064d30 R11: 3c8cc825b908 R12: 3c8cc966d3c0
[   20.250896] R13: 3c8cc9e280c0 R14:  R15: 

Signed-off-by: Alex Levin 
---

  sound/soc/intel/atom/sst/sst_pvt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/intel/atom/sst/sst_pvt.c 
b/sound/soc/intel/atom/sst/sst_pvt.c
index 00a37a09dc9b..dba0ca07ebf9 100644
--- a/sound/soc/intel/atom/sst/sst_pvt.c
+++ b/sound/soc/intel/atom/sst/sst_pvt.c
@@ -166,11 +166,11 @@ int sst_create_ipc_msg(struct ipc_post **arg, bool large)
  {
struct ipc_post *msg;
  
-	msg = kzalloc(sizeof(*msg), GFP_KERNEL);

+   msg = kzalloc(sizeof(*msg), GFP_ATOMIC);
if (!msg)
return -ENOMEM;
if (large) {
-   msg->mailbox_data = kzalloc(SST_MAILBOX_SIZE, GFP_KERNEL);
+   msg->mailbox_data = kzalloc(SST_MAILBOX_SIZE, GFP_ATOMIC);
if (!msg->mailbox_data) {
kfree(msg);
return -ENOMEM;

Re: [PATCH 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list

[Linus Walleij]

On Wed, Jun 5, 2019 at 1:43 PM Lee Jones  wrote:

> When booting MSM based platforms with Device Tree or some ACPI
> implementations, it is possible to provide a list of reserved pins
> via the 'gpio-reserved-ranges' and 'gpios' properties respectively.
> However some ACPI tables are not populated with this information,
> thus it has to come from a knowledgable device driver instead.
>
> Here we provide the MSM common driver with additional support to
> parse this informtion and correctly populate the widely used
> 'valid_mask'.
>
> Signed-off-by: Lee Jones 

Exactly how we should use of the API, so if Björn can supply an
ACK to patches 3 and 4 I'm happy to apply them.

Björn?

Yours,
Linus Walleij

Re: [PATCH v2 0/3] arm64: dts: meson-g12a: mmc updates

[Kevin Hilman]

Neil Armstrong  writes:

> This patchset :
> - adds the SDIO controller node using the dram-access-quirk
> - adds SDCard, eMMC & SDIO support to X96
> - Add SDIO support to SEI510

Queued for v5.3,

Thanks,

Kevin

Re: [PATCH v2] phy: meson-g12a-usb3-pcie: disable locking for cr_regmap

[Kevin Hilman]

Neil Armstrong  writes:

> Locking is not needed for the phy_g12a_usb3_pcie_cr_bus_read/write() and
> currently it causes the following BUG because of the usage of the
> regmap_read_poll_timeout() running in spinlock_irq, configured by regmap 
> fast_io.
>
> Simply disable locking in the cr_regmap config since it's only used from the
> PHY init callback function.
>
> BUG: sleeping function called from invalid context at 
> drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c:85
> in_atomic(): 1, irqs_disabled(): 128, pid: 60, name: kworker/3:1
> [snip]
> Workqueue: events deferred_probe_work_func
> Call trace:
>  dump_backtrace+0x0/0x190
>  show_stack+0x14/0x20
>  dump_stack+0x90/0xb4
>  ___might_sleep+0xec/0x110
>  __might_sleep+0x50/0x88
>  phy_g12a_usb3_pcie_cr_bus_addr.isra.0+0x80/0x1a8
>  phy_g12a_usb3_pcie_cr_bus_read+0x34/0x1d8
>  _regmap_read+0x60/0xe0
>  _regmap_update_bits+0xc4/0x110
>  regmap_update_bits_base+0x60/0x90
>  phy_g12a_usb3_pcie_init+0xdc/0x210
>  phy_init+0x74/0xd0
>  dwc3_meson_g12a_probe+0x2cc/0x4d0
>  platform_drv_probe+0x50/0xa0
>  really_probe+0x20c/0x3b8
>  driver_probe_device+0x68/0x150
>  __device_attach_driver+0xa8/0x170
>  bus_for_each_drv+0x64/0xc8
>  __device_attach+0xd8/0x158
>  device_initial_probe+0x10/0x18
>  bus_probe_device+0x90/0x98
>  deferred_probe_work_func+0x94/0xe8
>  process_one_work+0x1e0/0x338
>  worker_thread+0x230/0x458
>  kthread+0x134/0x138
>  ret_from_fork+0x10/0x1c
>
> Fixes: 36077e16c050 ("phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY 
> Driver")
> Signed-off-by: Neil Armstrong 

Tested-by: Kevin Hilman 

Re: [PATCH] media: platform: ao-cec-g12a: remove spin_lock_irqsave() locking in meson_ao_cec_g12a_read/write

[Kevin Hilman]

Neil Armstrong  writes:

> Since locking is handled by regmap, the spin_lock_irqsave() in the
> meson_ao_cec_g12a_read/write() regmap callbacks is not needed.
>
> Fixes: b7778c46683c ("media: platform: meson: Add Amlogic Meson G12A AO CEC 
> Controller driver")
> Signed-off-by: Neil Armstrong 

Tested-by: Kevin Hilman 

Re: [PATCH] media: pvrusb2: fix null-ptr-deref in class_unregister()

[isely]

Acked-By: Mike Isely 

On Wed, 5 Jun 2019, Kefeng Wang wrote:

> The class_ptr will be NULL if pvr2_sysfs_class_create() fails
> in pvr_init(), when call pvr2_sysfs_class_destroy(), it will
> lead to null-ptr-deref, fix it.
> 
> Reported-by: Hulk Robot 
> Signed-off-by: Kefeng Wang 
> ---
>  drivers/media/usb/pvrusb2/pvrusb2-sysfs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c 
> b/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c
> index 7bc6d090358e..b6c6b314fadc 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-sysfs.c
> @@ -802,7 +802,8 @@ struct pvr2_sysfs_class *pvr2_sysfs_class_create(void)
>  void pvr2_sysfs_class_destroy(struct pvr2_sysfs_class *clp)
>  {
>   pvr2_sysfs_trace("Unregistering pvr2_sysfs_class id=%p", clp);
> - class_unregister(>class);
> + if (clp)
> + class_unregister(>class);
>  }
>  
>  
> 

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8

[RFC/RFT PATCH v2] ASoC: fsl_esai: Revert "ETDR and TX0~5 registers are non volatile"

[Nicolin Chen]

Commit 8973112aa41b ("ASoC: fsl_esai: ETDR and TX0~5 registers are
non volatile") removed TX data registers from the volatile_reg list
and appended default values for them. However, being data registers
of TX, they should not have been removed from the list because they
should not be cached -- see the following reason.

When doing regcache_sync(), this operation might accidentally write
some dirty data to these registers, in case that cached data happen
to be different from the default ones, which might also result in a
channel shift or swap situation, since the number of write-via-sync
operations at ETDR would very unlikely match the channel number.

So this patch reverts the original commit to keep TX data registers
in volatile_reg list in order to prevent them from being written by
regcache_sync().

Note: this revert is not a complete revert as it keeps those macros
of registers remaining in the default value list while the original
commit also changed other entries in the list. And this patch isn't
very necessary to Cc stable tree since there has been always a FIFO
reset operation around the regcache_sync() call, even prior to this
reverted commit.

Signed-off-by: Nicolin Chen 
Cc: Shengjiu Wang 
---
Hi Mark,
In case there's no objection against the patch, I'd still like to
wait for a Tested-by from NXP folks before submitting it. Thanks!

Changelog
v1->v2
 * Fixed subject by following subsystem format.
 * Revised commit message to emphasize the real issue.

 sound/soc/fsl/fsl_esai.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index 10d2210c91ef..8f0a86335f73 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -652,16 +652,9 @@ static const struct snd_soc_component_driver 
fsl_esai_component = {
 };
 
 static const struct reg_default fsl_esai_reg_defaults[] = {
-   {REG_ESAI_ETDR,  0x},
{REG_ESAI_ECR,   0x},
{REG_ESAI_TFCR,  0x},
{REG_ESAI_RFCR,  0x},
-   {REG_ESAI_TX0,   0x},
-   {REG_ESAI_TX1,   0x},
-   {REG_ESAI_TX2,   0x},
-   {REG_ESAI_TX3,   0x},
-   {REG_ESAI_TX4,   0x},
-   {REG_ESAI_TX5,   0x},
{REG_ESAI_TSR,   0x},
{REG_ESAI_SAICR, 0x},
{REG_ESAI_TCR,   0x},
@@ -711,10 +704,17 @@ static bool fsl_esai_readable_reg(struct device *dev, 
unsigned int reg)
 static bool fsl_esai_volatile_reg(struct device *dev, unsigned int reg)
 {
switch (reg) {
+   case REG_ESAI_ETDR:
case REG_ESAI_ERDR:
case REG_ESAI_ESR:
case REG_ESAI_TFSR:
case REG_ESAI_RFSR:
+   case REG_ESAI_TX0:
+   case REG_ESAI_TX1:
+   case REG_ESAI_TX2:
+   case REG_ESAI_TX3:
+   case REG_ESAI_TX4:
+   case REG_ESAI_TX5:
case REG_ESAI_RX0:
case REG_ESAI_RX1:
case REG_ESAI_RX2:
-- 
2.17.1

Re: [RFC RESEND PATCH v2 1/4] dt-bindings: gpio: davinci: Add k3 am654 compatible

[Linus Walleij]

On Thu, Jun 6, 2019 at 11:55 AM Keerthy  wrote:

> The patch adds k3 am654 compatible, specific properties and
> an example.
>
> Signed-off-by: Keerthy 

Patch applied with the three others, so now all
GPIO changes are in tree.

Please funnel all the DTS changes through ARM SoC.

Yours,
Linus Walleij

[PATCH v3 2/5] mmc: core: API for temporarily disabling auto-retuning due to errors

[Douglas Anderson]

Normally when the MMC core sees an "-EILSEQ" error returned by a host
controller then it will trigger a retuning of the card.  This is
generally a good idea.

However, if a command is expected to sometimes cause transfer errors
then these transfer errors shouldn't cause a re-tuning.  This
re-tuning will be a needless waste of time.  One example case where a
transfer is expected to cause errors is when transitioning between
idle (sometimes referred to as "sleep" in Broadcom code) and active
state on certain Broadcom WiFi cards.  Specifically if the card was
already transitioning between states when the command was sent it
could cause an error on the SDIO bus.

Let's add an API that the SDIO card drivers can call that will
temporarily disable the auto-tuning functionality.  Then we can add a
call to this in the Broadcom WiFi driver and any other driver that
might have similar needs.

NOTE: this makes the assumption that the card is already tuned well
enough that it's OK to disable the auto-retuning during one of these
error-prone situations.  Presumably the driver code performing the
error-prone transfer knows how to recover / retry from errors.  ...and
after we can get back to a state where transfers are no longer
error-prone then we can enable the auto-retuning again.  If we truly
find ourselves in a case where the card needs to be retuned sometimes
to handle one of these error-prone transfers then we can always try a
few transfers first without auto-retuning and then re-try with
auto-retuning if the first few fail.

Without this change on rk3288-veyron-minnie I periodically see this in
the logs of a machine just sitting there idle:
  dwmmc_rockchip ff0d.dwmmc: Successfully tuned phase to XYZ

Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Douglas Anderson 
---
Note that are are a whole boatload of different ways that we could
provide an API for the Broadcom WiFi SDIO driver.  This patch
illustrates one way but if maintainers feel strongly that this is too
ugly and have a better idea then I can give it a shot too.  From a
purist point of view I kinda felt that the "expect errors" really
belonged as part of the mmc_request structure, but getting it into
there meant changing a whole pile of core SD/MMC APIs.  Simply adding
it to the host seemed to match the current style better and was a less
intrusive change.

Changes in v3:
- Took out the spinlock since I believe this is all in one context.

Changes in v2:
- Updated commit message to clarify based on discussion of v1.

 drivers/mmc/core/core.c  | 19 +--
 include/linux/mmc/core.h |  2 ++
 include/linux/mmc/host.h |  1 +
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 6db36dc870b5..bc109ec49406 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -144,8 +144,9 @@ void mmc_request_done(struct mmc_host *host, struct 
mmc_request *mrq)
int err = cmd->error;
 
/* Flag re-tuning needed on CRC errors */
-   if ((cmd->opcode != MMC_SEND_TUNING_BLOCK &&
-   cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200) &&
+   if (cmd->opcode != MMC_SEND_TUNING_BLOCK &&
+   cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200 &&
+   !host->expect_errors &&
(err == -EILSEQ || (mrq->sbc && mrq->sbc->error == -EILSEQ) ||
(mrq->data && mrq->data->error == -EILSEQ) ||
(mrq->stop && mrq->stop->error == -EILSEQ)))
@@ -2163,6 +2164,20 @@ int mmc_sw_reset(struct mmc_host *host)
 }
 EXPORT_SYMBOL(mmc_sw_reset);
 
+void mmc_expect_errors_begin(struct mmc_host *host)
+{
+   WARN_ON(host->expect_errors);
+   host->expect_errors = true;
+}
+EXPORT_SYMBOL_GPL(mmc_expect_errors_begin);
+
+void mmc_expect_errors_end(struct mmc_host *host)
+{
+   WARN_ON(!host->expect_errors);
+   host->expect_errors = false;
+}
+EXPORT_SYMBOL_GPL(mmc_expect_errors_end);
+
 static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq)
 {
host->f_init = freq;
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 134a6483347a..02a13abf0cda 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -178,6 +178,8 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct 
mmc_command *cmd,
 
 int mmc_hw_reset(struct mmc_host *host);
 int mmc_sw_reset(struct mmc_host *host);
+void mmc_expect_errors_begin(struct mmc_host *host);
+void mmc_expect_errors_end(struct mmc_host *host);
 void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card);
 
 #endif /* LINUX_MMC_CORE_H */
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 43d0f0c496f6..8d553fb8c834 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -398,6 +398,7 @@ struct mmc_host {
unsigned intretune_now:1;   /* do re-tuning at next req */
unsigned intretune_paused:1; /* re-tuning is temporarily 

Re: [PATCH v2 2/3] gpio: davinci: Add new compatible for K3 AM654 SoCs

[Linus Walleij]

On Thu, Jun 6, 2019 at 9:49 AM Bartosz Golaszewski  wrote:
> śr., 5 cze 2019 o 17:12 Keerthy  napisał(a):

> > >>   static const struct of_device_id davinci_gpio_ids[] = {
> > >>  { .compatible = "ti,keystone-gpio", keystone_gpio_get_irq_chip},
> > >> +   { .compatible = "ti,am654-gpio", keystone_gpio_get_irq_chip},
> > >
> > > Please add a patch adding this compatible to the binding document as well.
> >
> > https://patchwork.kernel.org/patch/10976445/
> >
> > Posted but did not add you in Cc. Sorry about that.
>
> I don't see it on GPIO patchwork either. Please resend it as part of
> this series.

I see the whole other series got resent as RFC, I'll just apply these
three and the binding patch so we don't have to pingpong these
patches too much around :)

Yours,
Linus Walleij

[PATCH v3 3/5] brcmfmac: sdio: Disable auto-tuning around commands expected to fail

[Douglas Anderson]

There are certain cases, notably when transitioning between sleep and
active state, when Broadcom SDIO WiFi cards will produce errors on the
SDIO bus.  This is evident from the source code where you can see that
we try commands in a loop until we either get success or we've tried
too many times.  The comment in the code reinforces this by saying
"just one write attempt may fail"

Unfortunately these failures sometimes end up causing an "-EILSEQ"
back to the core which triggers a retuning of the SDIO card and that
blocks all traffic to the card until it's done.

Let's disable retuning around the commands we expect might fail.

Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Douglas Anderson 
---

Changes in v3:
- Expect errors for all of brcmf_sdio_kso_control() (Adrian).

Changes in v2: None

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4a750838d8cd..4040aae1f9ed 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -667,6 +668,8 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
 
brcmf_dbg(TRACE, "Enter: on=%d\n", on);
 
+   mmc_expect_errors_begin(bus->sdiodev->func1->card->host);
+
wr_val = (on << SBSDIO_FUNC1_SLEEPCSR_KSO_SHIFT);
/* 1st KSO write goes to AOS wake up core if device is asleep  */
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val, );
@@ -727,6 +730,8 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
if (try_cnt > MAX_KSO_ATTEMPTS)
brcmf_err("max tries: rd_val=0x%x err=%d\n", rd_val, err);
 
+   mmc_expect_errors_end(bus->sdiodev->func1->card->host);
+
return err;
 }
 
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v3 1/5] Revert "brcmfmac: disable command decode in sdio_aos"

[Douglas Anderson]

This reverts commit 29f6589140a10ece8c1d73f58043ea5b3473ab3e.

After that patch landed I find that my kernel log on
rk3288-veyron-minnie and rk3288-veyron-speedy is filled with:
brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110

This seems to happen every time the Broadcom WiFi transitions out of
sleep mode.  Reverting the commit fixes the problem for me, so that's
what this patch does.

Note that, in general, the justification in the original commit seemed
a little weak.  It looked like someone was testing on a SD card
controller that would sometimes die if there were CRC errors on the
bus.  This used to happen back in early days of dw_mmc (the controller
on my boards), but we fixed it.  Disabling a feature on all boards
just because one SD card controller is broken seems bad.

Fixes: 29f6589140a1 ("brcmfmac: disable command decode in sdio_aos")
Cc: Wright Feng 
Cc: Double Lo 
Cc: Madhan Mohan R 
Cc: Chi-Hsien Lin 
Signed-off-by: Douglas Anderson 
---
As far as I know this patch can land anytime.

Changes in v3: None
Changes in v2:
- A full revert, not just a partial one (Arend).  ...with explicit Cc.

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4e15ea57d4f5..4a750838d8cd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3364,11 +3364,7 @@ static int brcmf_sdio_download_firmware(struct 
brcmf_sdio *bus,
 
 static bool brcmf_sdio_aos_no_decode(struct brcmf_sdio *bus)
 {
-   if (bus->ci->chip == CY_CC_43012_CHIP_ID ||
-   bus->ci->chip == CY_CC_4373_CHIP_ID ||
-   bus->ci->chip == BRCM_CC_4339_CHIP_ID ||
-   bus->ci->chip == BRCM_CC_4345_CHIP_ID ||
-   bus->ci->chip == BRCM_CC_4354_CHIP_ID)
+   if (bus->ci->chip == CY_CC_43012_CHIP_ID)
return true;
else
return false;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v3 0/5] brcmfmac: sdio: Deal better w/ transmission errors related to idle

[Douglas Anderson]

This series attempts to deal better with the expected transmission
errors related to the idle states (handled by the Always-On-Subsystem
or AOS) on the SDIO-based WiFi on rk3288-veyron-minnie,
rk3288-veyron-speedy, and rk3288-veyron-mickey.

Some details about those errors can be found in
, but to summarize it here: if we try to
send the wakeup command to the WiFi card at the same time it has
decided to wake up itself then it will behave badly on the SDIO bus.
This can cause timeouts or CRC errors.

When I tested on 4.19 and 4.20 these CRC errors can be seen to cause
re-tuning.  Since I am currently developing on 4.19 this was the
original problem I attempted to solve.

On mainline it turns out that you don't see the retuning errors but
you see tons of spam about timeouts trying to wakeup from sleep.  I
tracked down the commit that was causing that and have partially
reverted it here.  I have no real knowledge about Broadcom WiFi, but
the commit that was causing problems sounds (from the descriptioin) to
be a hack commit penalizing all Broadcom WiFi users because of a bug
in a Cypress SD controller.  I will let others comment if this is
truly the case and, if so, what the right solution should be.

For v3 of this series I have added 2 patches to the end of the series
to address errors that would show up on systems with these same SDIO
WiFi cards when used on controllers that do periodic retuning.  These
systems need an extra fix to prevent the retuning from happening when
the card is asleep.

Changes in v3:
- Took out the spinlock since I believe this is all in one context.
- Expect errors for all of brcmf_sdio_kso_control() (Adrian).
- ("mmc: core: Export mmc_retune_hold_now() mmc_retune_release()") new for v3.
- ("brcmfmac: sdio: Don't tune while the card is off") new for v3.

Changes in v2:
- A full revert, not just a partial one (Arend).  ...with explicit Cc.
- Updated commit message to clarify based on discussion of v1.

Douglas Anderson (5):
  Revert "brcmfmac: disable command decode in sdio_aos"
  mmc: core: API for temporarily disabling auto-retuning due to errors
  brcmfmac: sdio: Disable auto-tuning around commands expected to fail
  mmc: core: Export mmc_retune_hold_now() mmc_retune_release()
  brcmfmac: sdio: Don't tune while the card is off

 drivers/mmc/core/core.c   | 19 +--
 drivers/mmc/core/host.c   |  7 +++
 drivers/mmc/core/host.h   |  7 ---
 .../broadcom/brcm80211/brcmfmac/sdio.c| 18 +-
 include/linux/mmc/core.h  |  4 
 include/linux/mmc/host.h  |  1 +
 6 files changed, 42 insertions(+), 14 deletions(-)

-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v3 4/5] mmc: core: Export mmc_retune_hold_now() mmc_retune_release()

[Douglas Anderson]

We want SDIO drivers to be able to temporarily stop retuning when the
driver knows that the SDIO card is not in a state where retuning will
work (maybe because the card is asleep).  We'll move the relevant
functions to a place where drivers can call them.

NOTE: We'll leave the calls with a mmc_ prefix following the lead of
the API call mmc_hw_reset(), which is also expected to be called
directly by SDIO cards.

Signed-off-by: Douglas Anderson 
---

Changes in v3:
- ("mmc: core: Export mmc_retune_hold_now() mmc_retune_release()") new for v3.

Changes in v2: None

 drivers/mmc/core/host.c  | 7 +++
 drivers/mmc/core/host.h  | 7 ---
 include/linux/mmc/core.h | 2 ++
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 6a51f7a06ce7..361f4d151d20 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -111,6 +111,13 @@ void mmc_retune_hold(struct mmc_host *host)
host->hold_retune += 1;
 }
 
+void mmc_retune_hold_now(struct mmc_host *host)
+{
+   host->retune_now = 0;
+   host->hold_retune += 1;
+}
+EXPORT_SYMBOL(mmc_retune_hold_now);
+
 void mmc_retune_release(struct mmc_host *host)
 {
if (host->hold_retune)
diff --git a/drivers/mmc/core/host.h b/drivers/mmc/core/host.h
index 4805438c02ff..3212afc6c9fe 100644
--- a/drivers/mmc/core/host.h
+++ b/drivers/mmc/core/host.h
@@ -19,17 +19,10 @@ void mmc_unregister_host_class(void);
 void mmc_retune_enable(struct mmc_host *host);
 void mmc_retune_disable(struct mmc_host *host);
 void mmc_retune_hold(struct mmc_host *host);
-void mmc_retune_release(struct mmc_host *host);
 int mmc_retune(struct mmc_host *host);
 void mmc_retune_pause(struct mmc_host *host);
 void mmc_retune_unpause(struct mmc_host *host);
 
-static inline void mmc_retune_hold_now(struct mmc_host *host)
-{
-   host->retune_now = 0;
-   host->hold_retune += 1;
-}
-
 static inline void mmc_retune_recheck(struct mmc_host *host)
 {
if (host->hold_retune <= 1)
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 02a13abf0cda..53085245383c 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -181,5 +181,7 @@ int mmc_sw_reset(struct mmc_host *host);
 void mmc_expect_errors_begin(struct mmc_host *host);
 void mmc_expect_errors_end(struct mmc_host *host);
 void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card);
+void mmc_retune_release(struct mmc_host *host);
+void mmc_retune_hold_now(struct mmc_host *host);
 
 #endif /* LINUX_MMC_CORE_H */
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

[PATCH v3 5/5] brcmfmac: sdio: Don't tune while the card is off

[Douglas Anderson]

When Broadcom SDIO cards are idled they go to sleep and a whole
separate subsystem takes over their SDIO communication.  This is the
Always-On-Subsystem (AOS) and it can't handle tuning requests.

Specifically, as tested on rk3288-veyron-minnie (which reports having
BCM4354/1 in dmesg), if I force a retune in brcmf_sdio_kso_control()
when "on = 1" (aka we're transition from sleep to wake) by whacking:
  bus->sdiodev->func1->card->host->need_retune = 1
...then I can often see tuning fail.  In this case dw_mmc reports "All
phases bad!").  Note that I don't get 100% failure, presumably because
sometimes the card itself has already transitioned away from the AOS
itself by the time we try to wake it up.  If I force retuning when "on
= 0" (AKA force retuning right before sending the command to go to
sleep) then retuning is always OK.

NOTE: we need _both_ this patch and the patch to avoid triggering
tuning due to CRC errors in the sleep/wake transition, AKA ("brcmfmac:
sdio: Disable auto-tuning around commands expected to fail").  Though
both patches handle issues with Broadcom's AOS, the problems are
distinct:
1. We want to defer (but not ignore) asynchronous (like
   timer-requested) tuning requests till the card is awake.  However,
   we want to ignore CRC errors during the transition, we don't want
   to queue deferred tuning request.
2. You could imagine that the AOS could implement retuning but we
   could still get errors while transitioning in and out of the AOS.
   Similarly you could imagine a seamless transition into and out of
   the AOS (with no CRC errors) even if the AOS couldn't handle
   tuning.

ALSO NOTE: presumably there is never a desperate need to retune in
order to wake up the card, since doing so is impossible.  Luckily the
only way the card can get into sleep state is if we had a good enough
tuning to send it a sleep command, so presumably that "good enough"
tuning is enough to wake us up, at least with a few retries.

Signed-off-by: Douglas Anderson 
---

Changes in v3:
- ("brcmfmac: sdio: Don't tune while the card is off") new for v3.

Changes in v2: None

 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4040aae1f9ed..98ffb4e90e15 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -670,6 +670,10 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
 
mmc_expect_errors_begin(bus->sdiodev->func1->card->host);
 
+   /* Cannot re-tune if device is asleep; defer till we're awake */
+   if (on)
+   mmc_retune_hold_now(bus->sdiodev->func1->card->host);
+
wr_val = (on << SBSDIO_FUNC1_SLEEPCSR_KSO_SHIFT);
/* 1st KSO write goes to AOS wake up core if device is asleep  */
brcmf_sdiod_writeb(bus->sdiodev, SBSDIO_FUNC1_SLEEPCSR, wr_val, );
@@ -730,6 +734,9 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
if (try_cnt > MAX_KSO_ATTEMPTS)
brcmf_err("max tries: rd_val=0x%x err=%d\n", rd_val, err);
 
+   if (on)
+   mmc_retune_release(bus->sdiodev->func1->card->host);
+
mmc_expect_errors_end(bus->sdiodev->func1->card->host);
 
return err;
-- 
2.22.0.rc2.383.gf4fbbf30c2-goog

Re: [PATCH v2 3/3] gpio: Davinci: Add K3 dependencies

[Linus Walleij]

On Wed, Jun 5, 2019 at 10:02 AM Keerthy  wrote:

> Add K3 dependencies to enable the driver on K3 platforms.
>
> Signed-off-by: Keerthy 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 2/3] gpio: davinci: Add new compatible for K3 AM654 SoCs

[Linus Walleij]

On Wed, Jun 5, 2019 at 10:02 AM Keerthy  wrote:

> Add new compatible for K3 AM654 SoCs.
>
> Signed-off-by: Keerthy 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 1/3] gpio: davinci: Fix the compiler warning with ARM64 config enabled

[Linus Walleij]

On Wed, Jun 5, 2019 at 10:02 AM Keerthy  wrote:

> Fix the compiler warning with ARM64 config enabled
> as the current mask assumes 32 bit by default.
>
> Signed-off-by: Keerthy 

Patch applied, I think this and patch 2/3 work fine
together as-is.

Yours,
Linus Walleij

Re: [PATCH] MAINTAINERS: Karthikeyan Ramasubramanian is MIA

[Wolfram Sang]

On Mon, May 27, 2019 at 09:45:45PM +0200, Wolfram Sang wrote:
> A mail just bounced back with "user unknown":
> 
> 550 5.1.1  User doesn't exist
> 
> I also couldn't find a more recent address in git history. So, remove
> this stale entry.
> 
> Signed-off-by: Wolfram Sang 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

Re: [PATCH] hwmon: pmbus: protect read-modify-write with lock

[Wolfram Sang]

On Tue, May 28, 2019 at 09:08:21AM +, Adamski, Krzysztof (Nokia - 
PL/Wroclaw) wrote:
> The operation done in the pmbus_update_fan() function is a
> read-modify-write operation but it lacks any kind of lock protection
> which may cause problems if run more than once simultaneously. This
> patch uses an existing update_lock mutex to fix this problem.
> 
> Signed-off-by: Krzysztof Adamski 

Please use get_maintainer to find the people responsible for this file.
It is not my realm.

> +out:
> + mutex_lock(>update_lock);

Despite the above, have you tested the code? This likely should be
mutex_unlock?



signature.asc
Description: PGP signature

Re: [PATCH trivial] mm/vmalloc: Spelling s/configuraion/configuration/

[Souptick Joarder]

On Fri, Jun 7, 2019 at 5:05 PM Geert Uytterhoeven
 wrote:
>
> Signed-off-by: Geert Uytterhoeven 

Subject line should be s/informaion/information. With that fix,
Acked-by: Souptick Joarder 

> ---
>  mm/vmalloc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 7350a124524bb4b2..08b8b5a117576561 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2783,7 +2783,7 @@ static int aligned_vwrite(char *buf, char *addr, 
> unsigned long count)
>   * Note: In usual ops, vread() is never necessary because the caller
>   * should know vmalloc() area is valid and can use memcpy().
>   * This is for routines which have to access vmalloc area without
> - * any informaion, as /dev/kmem.
> + * any information, as /dev/kmem.
>   *
>   * Return: number of bytes for which addr and buf should be increased
>   * (same number as @count) or %0 if [addr...addr+count) doesn't
> @@ -2862,7 +2862,7 @@ long vread(char *buf, char *addr, unsigned long count)
>   * Note: In usual ops, vwrite() is never necessary because the caller
>   * should know vmalloc() area is valid and can use memcpy().
>   * This is for routines which have to access vmalloc area without
> - * any informaion, as /dev/kmem.
> + * any information, as /dev/kmem.
>   *
>   * Return: number of bytes for which addr and buf should be
>   * increased (same number as @count) or %0 if [addr...addr+count)
> --
> 2.17.1
>

Re: [PATCH v2 3/3] arm64: dts: meson-g12a-sei510: Enable Wifi SDIO module

[Kevin Hilman]

Neil Armstrong  writes:

> The SEI510 embeds an AP6398S SDIO module, let's add the
> corresponding SDIO, PWM clock and mmc-pwrseq nodes.
>
> Acked-by: Martin Blumenstingl 
> Signed-off-by: Neil Armstrong 

Queued for v5.3,

Thanks,

Kevin

Re: [PATCH v2 4/4] arm64: dts: meson-g12a-x96-max: bump bluetooth bus speed to 2Mbaud/s

[Kevin Hilman]

Neil Armstrong  writes:

> Setting to 2Mbaud/s is the nominal bus speed for common usages.
>
> Signed-off-by: Neil Armstrong 
> Acked-by: Martin Blumenstingl 

Queued for v5.3,

Thanks,

Kevin

Re: [PATCH v2 0/4] arm64: dts: meson-g12a: bluetooth fixups

[Kevin Hilman]

Neil Armstrong  writes:

> These patches :
> - adds the 32khz low power clock to the bluetooth node, since this
>   clock is needed for the bluetooth part of the module to initialize
> - bumps the bus speed to 2Mbaud/s

Queued for v5.3,

Thanks,

Kevin

Re: [PATCH v7 03/14] x86/cet/ibt: Add IBT legacy code bitmap setup function

[Andy Lutomirski]

> On Jun 7, 2019, at 2:09 PM, Dave Hansen  wrote:
> 
> On 6/7/19 1:06 PM, Yu-cheng Yu wrote:
>>> Huh, how does glibc know about all possible past and future legacy code
>>> in the application?
>> When dlopen() gets a legacy binary and the policy allows that, it will manage
>> the bitmap:
>> 
>>  If a bitmap has not been created, create one.
>>  Set bits for the legacy code being loaded.
> 
> I was thinking about code that doesn't go through GLIBC like JITs.

CRIU is another consideration: it would be rather annoying if CET programs 
can’t migrate between LA57 and normal machines.

Re: [PATCH] ASoC: Intel: sst: fix kmalloc call with wrong flags

[Curtis Malainey]

On Fri, Jun 7, 2019 at 3:19 PM Alex Levin  wrote:
>
> When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset,
> kmem_cache_alloc_trace is called.
>
> In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball
nit: *call
> slab_alloc, which will call slab_pre_alloc_hook which might_sleep_if.
>
> The context in which it is called in this case, the
> intel_sst_interrupt_mrfld, calling a sleeping kmalloc generates a BUG():
>
> Fixes: 972b0d456e64 ("ASoC: Intel: remove GFP_ATOMIC, use GFP_KERNEL")
>
> [   20.250671] BUG: sleeping function called from invalid context at 
> mm/slab.h:422
> [   20.250683] in_atomic(): 1, irqs_disabled(): 1, pid: 1791, name: 
> Chrome_IOThread
> [   20.250690] CPU: 0 PID: 1791 Comm: Chrome_IOThread Tainted: GW 
> 4.19.43 #61
> [   20.250693] Hardware name: GOOGLE Kefka, BIOS Google_Kefka.7287.337.0 
> 03/02/2017
> [   20.250893] R10: 562dd1064d30 R11: 3c8cc825b908 R12: 
> 3c8cc966d3c0
> [   20.250896] R13: 3c8cc9e280c0 R14:  R15: 
> 
>
> Signed-off-by: Alex Levin 
Reviewed-by: Curtis Malainey 
> ---
>

Re: [PATCH 1/3 linux dev-5.1 arm/soc v2] ARM: dts: aspeed: Add SGPM pinmux

[Linus Walleij]

On Tue, Jun 4, 2019 at 11:42 PM Hongwei Zhang  wrote:

> Add SGPM pinmux to ast2500-pinctrl function and group, to prepare for
> supporting SGPIO in AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang 

Acked-by: Linus Walleij 

Please funnel this part of the patch through the ARM SoC
tree. I guess Joel will queue this?

Yours,
Linus Walleij