[PATCH v2 07/13] ANDROID: binder: Add BINDER_GET_NODE_DEBUG_INFO ioctl

[Martijn Coenen]

From: Colin Cross 

The BINDER_GET_NODE_DEBUG_INFO ioctl will return debug info on
a node.  Each successive call reusing the previous return value
will return the next node.  The data will be used by
libmemunreachable to mark the pointers with kernel references
as reachable.

Signed-off-by: Colin Cross 
Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c| 43 +
 include/uapi/linux/android/binder.h | 14 
 2 files changed, 57 insertions(+)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 5edde38a77b3..017693dd4ec1 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4595,6 +4595,31 @@ static int binder_ioctl_set_ctx_mgr(struct file *filp)
return ret;
 }
 
+static int binder_ioctl_get_node_debug_info(struct binder_proc *proc,
+   struct binder_node_debug_info *info)
+{
+   struct rb_node *n;
+   binder_uintptr_t ptr = info->ptr;
+
+   memset(info, 0, sizeof(*info));
+
+   binder_inner_proc_lock(proc);
+   for (n = rb_first(>nodes); n != NULL; n = rb_next(n)) {
+   struct binder_node *node = rb_entry(n, struct binder_node,
+   rb_node);
+   if (node->ptr > ptr) {
+   info->ptr = node->ptr;
+   info->cookie = node->cookie;
+   info->has_strong_ref = node->has_strong_ref;
+   info->has_weak_ref = node->has_weak_ref;
+   break;
+   }
+   }
+   binder_inner_proc_unlock(proc);
+
+   return 0;
+}
+
 static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long 
arg)
 {
int ret;
@@ -4664,6 +4689,24 @@ static long binder_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
}
break;
}
+   case BINDER_GET_NODE_DEBUG_INFO: {
+   struct binder_node_debug_info info;
+
+   if (copy_from_user(, ubuf, sizeof(info))) {
+   ret = -EFAULT;
+   goto err;
+   }
+
+   ret = binder_ioctl_get_node_debug_info(proc, );
+   if (ret < 0)
+   goto err;
+
+   if (copy_to_user(ubuf, , sizeof(info))) {
+   ret = -EFAULT;
+   goto err;
+   }
+   break;
+   }
default:
ret = -EINVAL;
goto err;
diff --git a/include/uapi/linux/android/binder.h 
b/include/uapi/linux/android/binder.h
index 70e252bf0be0..5539933b3491 100644
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@ -233,6 +233,19 @@ struct binder_version {
 #define BINDER_CURRENT_PROTOCOL_VERSION 8
 #endif
 
+/*
+ * Use with BINDER_GET_NODE_DEBUG_INFO, driver reads ptr, writes to all fields.
+ * Set ptr to NULL for the first call to get the info for the first node, and
+ * then repeat the call passing the previously returned value to get the next
+ * nodes.  ptr will be 0 when there are no more nodes.
+ */
+struct binder_node_debug_info {
+   binder_uintptr_t ptr;
+   binder_uintptr_t cookie;
+   __u32has_strong_ref;
+   __u32has_weak_ref;
+};
+
 #define BINDER_WRITE_READ  _IOWR('b', 1, struct binder_write_read)
 #define BINDER_SET_IDLE_TIMEOUT_IOW('b', 3, __s64)
 #define BINDER_SET_MAX_THREADS _IOW('b', 5, __u32)
@@ -240,6 +253,7 @@ struct binder_version {
 #define BINDER_SET_CONTEXT_MGR _IOW('b', 7, __s32)
 #define BINDER_THREAD_EXIT _IOW('b', 8, __s32)
 #define BINDER_VERSION _IOWR('b', 9, struct binder_version)
+#define BINDER_GET_NODE_DEBUG_INFO _IOWR('b', 11, struct 
binder_node_debug_info)
 
 /*
  * NOTE: Two special error codes you should check for when calling
-- 
2.14.1.581.gf28d330327-goog

Re: WARNING: possible circular locking dependency detected

[Peter Zijlstra]

On Thu, Aug 31, 2017 at 09:55:57AM +0200, Thomas Gleixner wrote:
> > Arghh!!!
> > 
> > And allowing us to create events for offline CPUs (possible I think, but
> > maybe slightly tricky) won't solve that, because we're already holding
> > the hotplug_lock during PREPARE.
> 
> There are two ways to cure that:
> 
> 1) Have a pre cpus_write_lock() stage which is serialized via
>cpus_add_remove_lock, which is the outer lock for hotplug.
> 
>There we can sanely create stuff and fail with all consequences.

True, if you're willing to add more state to that hotplug thing I'll try
and make that perf patch that allows attaching to offline CPUs.

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Pavel Machek]

On Wed 2017-08-30 22:44:00, Jacek Anaszewski wrote:
> Hi,
> 
> On 08/29/2017 10:38 PM, Pavel Machek wrote:
> > Hi!
> > 
> >>> -As a specific example of this use-case, let's look at vibrate feature on
> >>> -phones. Vibrate function on phones is implemented using PWM pins on SoC 
> >>> or
> >>> -PMIC. There is a need to activate one shot timer to control the vibrate
> >>> -feature, to prevent user space crashes leaving the phone in vibrate mode
> >>> -permanently causing the battery to drain.
> >>
> >> I'm not sure if it is a good idea to remove this description. Users will
> >> still be able to use transient trigger this way. It has been around for
> >> five years already and there are users which employ it in this
> >> particular way [0].

Actually, I checked, and no ARM mainline board does that.

> > I am. Yes, people were doing that, but no, vibration motor is not a
> > LED. PWM behaviour is different, for example, motor is likely to stop
> > at low PWM values. We do not want people to do that.
> 
> Could you elaborate on how it can be harmful?

Well, you can safely route low current to the LEDs. What will it to do
vibration motor, if you leave it on forever? Can the motor safely be
run forever on high current? Not sure.

> I really don't see any merit in removing this from documentation.

There's right API to use for vibrations, and that's force-feedback
support in input/. Not here.

> You can convince me by collecting some acks from involved people.
> I'd like to especially see Rob's opinion. Adding Rob to this thread.

Rob is device tree maintainer. This has little to do with device tree.

> >> Apart from that it's the only documented kernel API for vibrate devices
> >> AFAICT.
> > 
> > Input subsystem has force-feedback protocol, which is very often just
> > vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
> > uses that API.
> 
> Word "vibration" doesn't appear there, so what this patch does
> is remove explicit advertisement of kernel support for vibrate
> devices without redirecting people to the replacement.

Well... this is LED documentation. If there's other documentation
missing somewhere else... we can fix it :-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH v2 08/13] ANDROID: binder: don't check prio permissions on restore.

[Martijn Coenen]

Because we have disabled RT priority inheritance for
the regular binder domain, the following can happen:

1) thread A (prio 98) calls into thread B
2) because RT prio inheritance is disabled, thread B
   runs at the lowest nice (prio 100) instead
3) thread B calls back into A; A will run at prio 100
   for the duration of the transaction
4) When thread A is done with the call from B, we will
   try to restore the prio back to 98. But, we fail
   because the process doesn't hold CAP_SYS_NICE,
   neither is RLIMIT_RT_PRIO set.

While the proper fix going forward will be to
correctly apply CAP_SYS_NICE or RLIMIT_RT_PRIO,
for now it seems reasonable to not check permissions
on the restore path.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 017693dd4ec1..0c0ecd78b9a7 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1109,9 +1109,10 @@ static int to_kernel_prio(int policy, int user_priority)
 }
 
 /**
- * binder_set_priority() - sets the scheduler priority of a task
+ * binder_do_set_priority() - sets the scheduler priority of a task
  * @task:  task to set priority on
  * @desired:   desired priority to run at
+ * @verify:verify whether @task is allowed to run at @desired prio
  *
  * The scheduler policy of tasks is changed explicitly, because we want to
  * support a few distinct features:
@@ -1145,8 +1146,9 @@ static int to_kernel_prio(int policy, int user_priority)
  *temporarily runs at its original priority.
  * 5) rt_mutex does not currently support PI for CFS tasks.
  */
-static void binder_set_priority(struct task_struct *task,
-   struct binder_priority desired)
+static void binder_do_set_priority(struct task_struct *task,
+  struct binder_priority desired,
+  bool verify)
 {
int priority; /* user-space prio value */
bool has_cap_nice;
@@ -1170,7 +1172,7 @@ static void binder_set_priority(struct task_struct *task,
 
priority = to_userspace_prio(policy, desired.prio);
 
-   if (is_rt_policy(policy) && !has_cap_nice) {
+   if (verify && is_rt_policy(policy) && !has_cap_nice) {
long max_rtprio = task_rlimit(task, RLIMIT_RTPRIO);
 
if (max_rtprio == 0) {
@@ -1182,7 +1184,7 @@ static void binder_set_priority(struct task_struct *task,
}
}
 
-   if (is_fair_policy(policy) && !has_cap_nice) {
+   if (verify && is_fair_policy(policy) && !has_cap_nice) {
long min_nice = rlimit_to_nice(task_rlimit(task, RLIMIT_NICE));
 
if (min_nice > MAX_NICE) {
@@ -1215,6 +1217,18 @@ static void binder_set_priority(struct task_struct *task,
set_user_nice(task, priority);
 }
 
+static void binder_set_priority(struct task_struct *task,
+   struct binder_priority desired)
+{
+   binder_do_set_priority(task, desired, /* verify = */ true);
+}
+
+static void binder_restore_priority(struct task_struct *task,
+   struct binder_priority desired)
+{
+   binder_do_set_priority(task, desired, /* verify = */ false);
+}
+
 static void binder_transaction_priority(struct task_struct *task,
struct binder_transaction *t,
struct binder_priority node_prio,
@@ -3251,7 +3265,7 @@ static void binder_transaction(struct binder_proc *proc,
binder_enqueue_work_ilocked(>work, _thread->todo);
binder_inner_proc_unlock(target_proc);
wake_up_interruptible_sync(_thread->wait);
-   binder_set_priority(current, in_reply_to->saved_priority);
+   binder_restore_priority(current, in_reply_to->saved_priority);
binder_free_transaction(in_reply_to);
} else if (!(t->flags & TF_ONE_WAY)) {
BUG_ON(t->buffer->async_transaction != 0);
@@ -3340,7 +3354,7 @@ static void binder_transaction(struct binder_proc *proc,
 
BUG_ON(thread->return_error.cmd != BR_OK);
if (in_reply_to) {
-   binder_set_priority(current, in_reply_to->saved_priority);
+   binder_restore_priority(current, in_reply_to->saved_priority);
thread->return_error.cmd = BR_TRANSACTION_COMPLETE;
binder_enqueue_work(thread->proc,
>return_error.work,
@@ -3940,7 +3954,7 @@ static int binder_thread_read(struct binder_proc *proc,
wait_event_interruptible(binder_user_error_wait,
 binder_stop_on_user_error < 2);
}
-   binder_set_priority(current, proc->default_priority);
+   

Re: WARNING: possible circular locking dependency detected

[Thomas Gleixner]

On Thu, 31 Aug 2017, Peter Zijlstra wrote:

> On Thu, Aug 31, 2017 at 09:55:57AM +0200, Thomas Gleixner wrote:
> > > Arghh!!!
> > > 
> > > And allowing us to create events for offline CPUs (possible I think, but
> > > maybe slightly tricky) won't solve that, because we're already holding
> > > the hotplug_lock during PREPARE.
> > 
> > There are two ways to cure that:
> > 
> > 1) Have a pre cpus_write_lock() stage which is serialized via
> >cpus_add_remove_lock, which is the outer lock for hotplug.
> > 
> >There we can sanely create stuff and fail with all consequences.
> 
> True, if you're willing to add more state to that hotplug thing I'll try
> and make that perf patch that allows attaching to offline CPUs.

Now that I think more about it. That's going to be an interesting exercise
vs. the hotplug state registration which relies on cpus_read_lock()
serialization.

Thanks,

tglx

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

[Byungchul Park]

On Thu, Aug 31, 2017 at 10:04:42AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 30, 2017 at 08:25:46PM +0900, Byungchul Park wrote:
> 
> > For example - I'm giving you the same example repeatedly:
> > 
> > context X context Y
> > - -
> >   wait_for_completion(C)
> > acquire(A)
> > process_one_work()
> >acquire(B)
> >work->fn()
> >   complete(C)
> > 
> > Please check C->A and C->B.
> 
> Is there a caller of procesS_one_work() that holds a lock?

It's not important. Ok, check the following, instead:

context X context Y
- -
  wait_for_completion(C)
acquire(A)
release(A)
process_one_work()
   acquire(B)
   release(B)
   work->fn()
  complete(C)

We don't need to lose C->A and C->B dependencies unnecessarily.

[RFC PATCH 3/6] ACPI: IORT: Add stall and pasid properties to iommu_fwspec

[Yisheng Xie]

According to ACPI IORT spec, named component specific data has a node
flags field whoes bit0 is for Stall support. However, it do not have any
field for pasid bit.

As PCIe SMMU support 20 pasid bits, this patch suggest to use 5 bits[5:1]
in node flags field for pasid bits which means we can have 32 pasid bits.
And this should be enough for platform device. Anyway, this is just a RFC.

Signed-off-by: Yisheng Xie 
---
 drivers/acpi/arm64/iort.c | 20 
 include/acpi/actbl2.h |  5 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 4d9ccdd0..514caca3 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -710,6 +710,22 @@ static bool iort_pci_rc_supports_ats(struct acpi_iort_node 
*node)
return pci_rc->ats_attribute & ACPI_IORT_ATS_SUPPORTED;
 }
 
+static bool iort_platform_support_stall(struct acpi_iort_node *node)
+{
+   struct acpi_iort_named_component *ncomp;
+
+   ncomp = (struct acpi_iort_named_component *)node->node_data;
+   return ncomp->node_flags & ACPI_IORT_STALL_SUPPORTED;
+}
+
+static unsigned long iort_platform_get_pasid_bits(struct acpi_iort_node *node)
+{
+   struct acpi_iort_named_component *ncomp;
+
+   ncomp = (struct acpi_iort_named_component *)node->node_data;
+   return (ncomp->node_flags & ACPI_IORT_PASID_BITS_MASK) >> 
ACPI_IORT_PASID_BITS_SHIFT;
+}
+
 /**
  * iort_iommu_configure - Set-up IOMMU configuration for a device.
  *
@@ -772,6 +788,10 @@ const struct iommu_ops *iort_iommu_configure(struct device 
*dev)
   IORT_IOMMU_TYPE,
   i++);
}
+   if (!IS_ERR_OR_NULL(ops)) {
+   dev->iommu_fwspec->can_stall = 
iort_platform_support_stall(node);
+   dev->iommu_fwspec->num_pasid_bits = 
iort_platform_get_pasid_bits(node);
+   }
}
 
/*
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 707dda74..125b150 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -749,6 +749,11 @@ struct acpi_iort_named_component {
char device_name[1];/* Path of namespace object */
 };
 
+#define ACPI_IORT_STALL_SUPPORTED  0x0001  /* The platform device 
supports stall */
+#define ACPI_IORT_STALL_UNSUPPORTED0x  /* The platform device 
doesn't support stall */
+#define ACPI_IORT_PASID_BITS_MASK  0x003e  /* 5 bits for PASID 
BITS */
+#define ACPI_IORT_PASID_BITS_SHIFT 1   /* PASID BITS numbers 
shift */
+
 struct acpi_iort_root_complex {
u64 memory_properties;  /* Memory access properties */
u32 ats_attribute;
-- 
1.7.12.4

[PATCH v2 1/4] phy: rcar-gen3-usb2: check dr_mode for otg mode

[Yoshihiro Shimoda]

The previous code assumed a channel has otg capability if a channel
has interrupt property. But, it is not good because:
 - Battery charging feature also needs interrupt property.
 - Some R-Car Gen3 SoCs (e.g. R-Car D3) doesn't have OTG capability.

So, this patch checks whether usb 2.0 host node has dr_mode property or
not. If it has 'dr_mode = "otg";', this driver enables otg capability.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 54c3429..e00e99a 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -1,7 +1,7 @@
 /*
  * Renesas R-Car Gen3 for USB2.0 PHY driver
  *
- * Copyright (C) 2015 Renesas Electronics Corporation
+ * Copyright (C) 2015-2017 Renesas Electronics Corporation
  *
  * This is based on the phy-rcar-gen2 driver:
  * Copyright (C) 2014 Renesas Solutions Corp.
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*** USB2.0 Host registers (original offset is +0x200) ***/
@@ -415,13 +416,16 @@ static int rcar_gen3_phy_usb2_probe(struct 
platform_device *pdev)
/* call request_irq for OTG */
irq = platform_get_irq(pdev, 0);
if (irq >= 0) {
-   int ret;
-
INIT_WORK(>work, rcar_gen3_phy_usb2_work);
irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
   IRQF_SHARED, dev_name(dev), channel);
if (irq < 0)
dev_err(dev, "No irq handler (%d)\n", irq);
+   }
+
+   if (of_usb_get_dr_mode_by_phy(dev->of_node, 0) == USB_DR_MODE_OTG) {
+   int ret;
+
channel->has_otg = true;
channel->extcon = devm_extcon_dev_allocate(dev,
rcar_gen3_phy_cable);
-- 
1.9.1

[PATCH v2 3/4] phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins

[Yoshihiro Shimoda]

This patch adds SoC-specific parameter to avoid reading/writing
specific registers wrongly if this driver runs on a SoC which doesn't
have dedicated pins (e.g. R-Car D3).

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 24 +++-
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 4ea9902..15e095e 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -80,6 +81,8 @@
 #define USB2_ADPCTRL_IDPULLUP  BIT(5)  /* 1 = ID sampling is enabled */
 #define USB2_ADPCTRL_DRVVBUS   BIT(4)
 
+#define RCAR_GEN3_PHY_HAS_DEDICATED_PINS   1
+
 struct rcar_gen3_chan {
void __iomem *base;
struct extcon_dev *extcon;
@@ -400,9 +403,17 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void 
*_ch)
 }
 
 static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
-   { .compatible = "renesas,usb2-phy-r8a7795" },
-   { .compatible = "renesas,usb2-phy-r8a7796" },
-   { .compatible = "renesas,rcar-gen3-usb2-phy" },
+   {
+   .compatible = "renesas,usb2-phy-r8a7795",
+   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
+   },
+   {
+   .compatible = "renesas,usb2-phy-r8a7796",
+   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
+   },
+   {
+   .compatible = "renesas,rcar-gen3-usb2-phy",
+   },
{ }
 };
 MODULE_DEVICE_TABLE(of, rcar_gen3_phy_usb2_match_table);
@@ -446,9 +457,12 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
}
 
if (of_usb_get_dr_mode_by_phy(dev->of_node, 0) == USB_DR_MODE_OTG) {
-   int ret;
+   int ret, dedicated_pins;
+   const struct of_device_id *of_id =
+   of_match_device(rcar_gen3_phy_usb2_match_table, dev);
 
-   channel->has_otg = true;
+   dedicated_pins = of_id ? (uintptr_t)of_id->data : 0;
+   channel->has_otg = !!dedicated_pins;
channel->can_role_swap = true;
channel->extcon = devm_extcon_dev_allocate(dev,
rcar_gen3_phy_cable);
-- 
1.9.1

[PATCH v2 4/4] phy: rcar-gen3-usb2: add binding for r8a77995

[Yoshihiro Shimoda]

This patch adds binding for r8a77995 (R-Car D3). Since r8a77995 doesn't
have dedicated pins (ID, VBUS), this will match against the generic
fallback on R-Car D3.

For now, this driver doesn't support usb role swap for r8a77995.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index ace9cce..99b651b 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -8,6 +8,8 @@ Required properties:
  SoC.
  "renesas,usb2-phy-r8a7796" if the device is a part of an R8A7796
  SoC.
+ "renesas,usb2-phy-r8a77995" if the device is a part of an
+ R8A77995 SoC.
  "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible 
device.
 
  When compatible with the generic version, nodes must list the
-- 
1.9.1

[PATCH v2 0/4] phy: rcar-gen3-usb2: add support for r8a77995

[Yoshihiro Shimoda]

This patch set is based on the latest phy.git / next branch
(the commit id = d9c51f4c53ae2af03aa8bd001d46f21b0adcdab8).

After this patch set is applied, a usb 2.0 host node that is combined
with usb 2.0 peripheral needs 'dr_mode = "otg";' property.

Changes from v1:
 - Revise typo "wronly" to "wrongly".
 - Remove RCAR_GEN3_PHY_HAS_DEDICATED_PINS from generic gen3 entry in
   patch 3/4
 - Remove the driver change from patch 4/4.
 - Revise the commit log of patch 4/4.

Yoshihiro Shimoda (4):
  phy: rcar-gen3-usb2: check dr_mode for otg mode
  phy: rcar-gen3-usb2: split the two meaning of "has_otg"
  phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins
  phy: rcar-gen3-usb2: add binding for r8a77995

 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  2 +
 drivers/phy/renesas/phy-rcar-gen3-usb2.c   | 93 --
 2 files changed, 69 insertions(+), 26 deletions(-)

-- 
1.9.1

Re: [RFC 04/11] KVM, arm, arm64: Offer PAs to IPAs idmapping to internal VMs

[Christoffer Dall]

Hi Florent,

I'd like for the UEFI folks and arm64 kernel maintainers to express
their views on this overall approach before I do an in-depth review, but
I have some random comments based on reading this patch:

On Fri, Aug 25, 2017 at 09:31:34AM +0100, Florent Revest wrote:
> Usual KVM virtual machines map guest's physical addresses from a process
> userspace memory. However, with the new concept of internal VMs, a virtual
> machine can be created from the kernel, without any link to a userspace
> context. Hence, some of the KVM's architecture-specific code needs to be
> modified to take this kind of VMs into account.
> 
> The approach chosen with this patch is to let internal VMs idmap physical
> addresses into intermediary physical addresses by calling
> kvm_set_memory_region with a kvm_userspace_memory_region where the
> guest_phys_addr field points both to the original PAs and to the IPAs. The
> userspace_addr field of this struct is therefore ignored with internal VMs.
> 
> This patch extends the capabilities of the arm and arm64 stage2 MMU code
> to handle internal VMs. Three things are changed:
> 
> - Various parts of the MMU code which are related to a userspace context
> are now only executed if kvm->mm is present.
> 
> - When this pointer is NULL, struct kvm_userspace_memory_regions are
> treated by internal_vm_prep_mem as idmaps of physical memory.
> 
> - A set of 256 additional private memslots is now reserved on arm64 for the
> usage of internal VMs memory idmapping.
> 
> Note: this patch should have pretty much no performance impact on the
> critical path of traditional VMs since only one unlikely branch had to be
> added to the page fault handler.
> 
> Signed-off-by: Florent Revest 
> ---
>  arch/arm64/include/asm/kvm_host.h |  1 +
>  virt/kvm/arm/mmu.c| 76 
> +--
>  2 files changed, 74 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_host.h 
> b/arch/arm64/include/asm/kvm_host.h
> index d686300..65aab35 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -32,6 +32,7 @@
>  #define __KVM_HAVE_ARCH_INTC_INITIALIZED
> 
>  #define KVM_USER_MEM_SLOTS 512
> +#define KVM_PRIVATE_MEM_SLOTS 256
>  #define KVM_HALT_POLL_NS_DEFAULT 50
> 
>  #include 
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 2ea21da..1d2d3df 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -772,6 +772,11 @@ static void stage2_unmap_memslot(struct kvm *kvm,
> phys_addr_t size = PAGE_SIZE * memslot->npages;
> hva_t reg_end = hva + size;
> 
> +   if (unlikely(!kvm->mm)) {

I think you should consider using a predicate so that it's clear that
this is for in-kernel VMs and not just some random situation where mm
can be NULL.

> +   unmap_stage2_range(kvm, addr, size);
> +   return;
> +   }
> +
> /*
>  * A memory region could potentially cover multiple VMAs, and any 
> holes
>  * between them, so iterate over all of them to find out if we should
> @@ -819,7 +824,8 @@ void stage2_unmap_vm(struct kvm *kvm)
> int idx;
> 
> idx = srcu_read_lock(>srcu);
> -   down_read(>mm->mmap_sem);
> +   if (likely(kvm->mm))
> +   down_read(>mm->mmap_sem);
> spin_lock(>mmu_lock);
> 
> slots = kvm_memslots(kvm);
> @@ -827,7 +833,8 @@ void stage2_unmap_vm(struct kvm *kvm)
> stage2_unmap_memslot(kvm, memslot);
> 
> spin_unlock(>mmu_lock);
> -   up_read(>mm->mmap_sem);
> +   if (likely(kvm->mm))
> +   up_read(>mm->mmap_sem);
> srcu_read_unlock(>srcu, idx);
>  }
> 
> @@ -1303,6 +1310,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, 
> phys_addr_t fault_ipa,
> return -EFAULT;
> }
> 
> +   if (unlikely(!kvm->mm)) {
> +   kvm_err("Unexpected internal VM page fault\n");
> +   kvm_inject_vabt(vcpu);
> +   return 0;
> +   }
> +

So it's unclear to me why we don't need any special casing in
kvm_handle_guest_abort, related to MMIO exits etc.  You probably assume
that we will never do emulation, but that should be described and
addressed somewhere before I can critically review this patch.

> /* Let's check if we will get back a huge page backed by hugetlbfs */
> down_read(>mm->mmap_sem);
> vma = find_vma_intersection(current->mm, hva, hva + 1);
> @@ -1850,6 +1863,54 @@ void kvm_arch_commit_memory_region(struct kvm *kvm,
> kvm_mmu_wp_memory_region(kvm, mem->slot);
>  }
> 
> +/*
> + * internal_vm_prep_mem - maps a range of hpa to gpa at stage2
> + *
> + * While userspace VMs manage gpas using hvas, internal virtual machines 
> need a
> + * way to map physical addresses to a guest. In order to avoid code 
> duplication,
> + * the kvm_set_memory_region call is kept for internal VMs, however it 
> usually
> 

Re: [PATCH v3 4/5] cramfs: add mmap support

[Christoph Hellwig]

The whole VMA games here look entirely bogus  you can't just drop
and reacquire mmap_sem for example.  And splitting vmas looks just
as promblematic.

As a minimum you really must see the linux-mm list can get some
feedback there.

On Wed, Aug 30, 2017 at 11:09:31PM -0400, Nicolas Pitre wrote:
> When cramfs_physmem is used then we have the opportunity to map files
> directly from ROM, directly into user space, saving on RAM usage.
> This gives us Execute-In-Place (XIP) support.
> 
> For a file to be mmap()-able, the map area has to correspond to a range
> of uncompressed and contiguous blocks, and in the MMU case it also has
> to be page aligned. A version of mkcramfs with appropriate support is
> necessary to create such a filesystem image.
> 
> In the MMU case it may happen for a vma structure to extend beyond the
> actual file size. This is notably the case in binfmt_elf.c:elf_map().
> Or the file's last block is shared with other files and cannot be mapped
> as is. Rather than refusing to mmap it, we do a partial map and set up
> a special vm_ops fault handler that splits the vma in two: the direct
> mapping vma and the memory-backed vma populated by the readpage method.
> In practice the unmapped area is seldom accessed so the split might never
> occur before this area is discarded.
> 
> In the non-MMU case it is the get_unmapped_area method that is responsible
> for providing the address where the actual data can be found. No mapping
> is necessary of course.
> 
> Signed-off-by: Nicolas Pitre 
> Tested-by: Chris Brandt 
> ---
>  fs/cramfs/inode.c | 295 
> ++
>  1 file changed, 295 insertions(+)
> 
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 2fc886092b..1d7d61354b 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -15,7 +15,9 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -49,6 +51,7 @@ static inline struct cramfs_sb_info *CRAMFS_SB(struct 
> super_block *sb)
>  static const struct super_operations cramfs_ops;
>  static const struct inode_operations cramfs_dir_inode_operations;
>  static const struct file_operations cramfs_directory_operations;
> +static const struct file_operations cramfs_physmem_fops;
>  static const struct address_space_operations cramfs_aops;
>  
>  static DEFINE_MUTEX(read_mutex);
> @@ -96,6 +99,10 @@ static struct inode *get_cramfs_inode(struct super_block 
> *sb,
>   case S_IFREG:
>   inode->i_fop = _ro_fops;
>   inode->i_data.a_ops = _aops;
> + if (IS_ENABLED(CONFIG_CRAMFS_PHYSMEM) &&
> + CRAMFS_SB(sb)->flags & CRAMFS_FLAG_EXT_BLOCK_POINTERS &&
> + CRAMFS_SB(sb)->linear_phys_addr)
> + inode->i_fop = _physmem_fops;
>   break;
>   case S_IFDIR:
>   inode->i_op = _dir_inode_operations;
> @@ -277,6 +284,294 @@ static void *cramfs_read(struct super_block *sb, 
> unsigned int offset,
>   return NULL;
>  }
>  
> +/*
> + * For a mapping to be possible, we need a range of uncompressed and
> + * contiguous blocks. Return the offset for the first block and number of
> + * valid blocks for which that is true, or zero otherwise.
> + */
> +static u32 cramfs_get_block_range(struct inode *inode, u32 pgoff, u32 *pages)
> +{
> + struct super_block *sb = inode->i_sb;
> + struct cramfs_sb_info *sbi = CRAMFS_SB(sb);
> + int i;
> + u32 *blockptrs, blockaddr;
> +
> + /*
> +  * We can dereference memory directly here as this code may be
> +  * reached only when there is a direct filesystem image mapping
> +  * available in memory.
> +  */
> + blockptrs = (u32 *)(sbi->linear_virt_addr + OFFSET(inode) + pgoff*4);
> + blockaddr = blockptrs[0] & ~CRAMFS_BLK_FLAGS;
> + i = 0;
> + do {
> + u32 expect = blockaddr + i * (PAGE_SIZE >> 2);
> + expect |= 
> CRAMFS_BLK_FLAG_DIRECT_PTR|CRAMFS_BLK_FLAG_UNCOMPRESSED;
> + if (blockptrs[i] != expect) {
> + pr_debug("range: block %d/%d got %#x expects %#x\n",
> +  pgoff+i, pgoff+*pages-1, blockptrs[i], expect);
> + if (i == 0)
> + return 0;
> + break;
> + }
> + } while (++i < *pages);
> +
> + *pages = i;
> +
> + /* stored "direct" block ptrs are shifted down by 2 bits */
> + return blockaddr << 2;
> +}
> +
> +/*
> + * It is possible for cramfs_physmem_mmap() to partially populate the mapping
> + * causing page faults in the unmapped area. When that happens, we need to
> + * split the vma so that the unmapped area gets its own vma that can be 
> backed
> + * with actual memory pages and loaded normally. This is necessary because
> + * remap_pfn_range() overwrites vma->vm_pgoff with the pfn and 
> filemap_fault()
> + * no 

Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

[Alexandre Belloni]

On 31/08/2017 at 12:04:03 +0300, Andy Shevchenko wrote:
> On Thu, 2017-08-31 at 10:23 +0200, Julia Lawall wrote:
> > 
> > On Thu, 31 Aug 2017, Alexandre Belloni wrote:
> > 
> > > On 31/08/2017 at 06:40:42 +0200, Christophe JAILLET wrote:
> > > > If 'clk_prepare_enable()' fails, we must release some resources
> > > > before
> > > > returning. Add a new label in the existing error handling path and
> > > > 'goto'
> > > > there.
> > > > 
> > > > Fixes: 260ea95cc027 ("ASoC: atmel: ac97c: Handle return value of
> > > > clk_prepare_enable.")
> > > > Signed-off-by: Christophe JAILLET 
> > > 
> > > And here is the fallout of the stupid, brainless "fixing" of issues
> > > reported by static analysis tools.
> > > 
> > > This clk_prepare_enable will never fail. If it was going to fail,
> > > the
> > > platform would never boot to a point were it is able to execute that
> > > code. It is really annoying to have so much churn for absolutely 0
> > > benefit.
> > 
> > Would it be more productive to put the code back like it was before,
> > ie no
> > return value and no check, and add a comment to the definition of
> > clk_prepare_enable indicating that there are many case where the call
> > cannot fail?  Grepping through the code suggests that it is about 50-
> > 50 on
> > checking the return value or not doing so, which might suggest that
> > checking the value is often not required.
> 
> I didn't look into the code, though speculating it might be the case
> when CLK framework is not enabled, though many drivers are dependent to
> it, so, it would never fail in such cases.

It is not the case, it would return 0. Anyway, this will not happen
because that driver depends on ARCH_AT91 which selects COMMON_CLK_AT91
which selects COMMON_CLK.

> Nevertheless there might be
> other cases for CLK API to fail.
> 

The only case would be for a clock to be enabled without being prepared
and this will never happen because clk_prepare_enable is used.

This call will just never fail.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH resend v2] power: supply: bq27xxx: enable writing capacity values for bq27421

[H. Nikolaus Schaller]

Hi Liam,

> Am 31.08.2017 um 10:58 schrieb Liam Breck :
> 
> On Wed, Aug 30, 2017 at 11:58 PM, H. Nikolaus Schaller
>  wrote:
>> Hi Liam,
>> 
>>> Am 30.08.2017 um 13:24 schrieb Liam Breck :
>>> 
>>> Hi Nikolaus,
>>> 
>>> On Wed, Aug 30, 2017 at 2:30 AM, H. Nikolaus Schaller  
>>> wrote:
 Hi Liam and Sebastian,
 
> Am 29.08.2017 um 22:20 schrieb Liam Breck :
> 
> Hi Nikolaus, thanks for the patch...
> 
> On Tue, Aug 29, 2017 at 1:10 PM, H. Nikolaus Schaller 
>  wrote:
>> Tested on Pyra prototype with bq27421.
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> drivers/power/supply/bq27xxx_battery.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/power/supply/bq27xxx_battery.c 
>> b/drivers/power/supply/bq27xxx_battery.c
>> index b6c3120ca5ad..e3c878ef7c7e 100644
>> --- a/drivers/power/supply/bq27xxx_battery.c
>> +++ b/drivers/power/supply/bq27xxx_battery.c
>> @@ -688,7 +688,7 @@ static struct bq27xxx_dm_reg bq27545_dm_regs[] = {
>> #define bq27545_dm_regs 0
>> #endif
>> 
>> -#if 0 /* not yet tested */
>> +#if 1 /* tested on Pyra */
>> static struct bq27xxx_dm_reg bq27421_dm_regs[] = {
> 
> I think we can drop the #if and #else...#endif so it's just the
> dm_regs table, as with bq27425.
 
 I have fixed that and did take the chance to update my OpenPandora
 kernel so that I also could test and make the bq27500 working.
>>> 
>>> Is this gauge on the board or in the battery?
>> 
>> It is on the board.
>> 
>>> If in the battery,
>>> monitored-battery should not be used.
>>> 
>>> For a gauge on the board, if a user changes the battery to a different
>>> type, they need to update the dtb.
>> 
>> Well, that is a little difficult to control, but here we have only
>> one standard Pandora cell. There may exist replacements with different
>> capacity, but that should not be our problem...
>> 
>>> 
>>> I assume you built with config_battery_bq27xxx_dt_updates_nvm?
>> 
>> Yes.
>> 
>>> 
 The biggest hurdle was to find out that I have to change the
 compatible string to "ti,bq27500-1" to get non-NULL dm_regs...
 
 [   12.765930] bq27xxx_battery_i2c_probe name=bq27500-1-0
 [   12.771392] bq27xxx_battery_i2c_probe call setup
 [   12.874816] bq27xxx_battery_setup
 [   12.904266] bq27xxx_battery_setup: dm_regs=bf0520e0
 [   12.933380] (NULL device *): hwmon: 'bq27500-1-0' is not a valid name 
 attribute, please fix
 [   13.234893] bq27xxx_battery_settings
 [   13.238891] bq27xxx-battery 2-0055: invalid 
 battery:energy-full-design-microwatt-hours 1480
>>> 
>>> The chip does not support this param, so it should be zero, as it has
>>> to be set if charge-full-design-* is set. Can you try that?
>> 
>> Hm. IMHO the DT should describe what the battery has and the driver should 
>> simply ignore
>> values it can't handle or reject them but do the best out of it. Telling the 
>> driver to ignore
>> a value by setting to 0 would IMHO be the wrong approach.
> 
> The driver requires that if either charge- or energy-full-design is
> set, then the other must be. Setting one and leaving the other at
> default would be an error. Allowing any value for a field unsupported
> by the chip, when supported field values must be within a range, isn't
> useful for hw development or production scenarios. The solution for
> shipped equipment is to drop the monitored-battery ref; see below.
> 
>> We are also working on the generic-adc-battery driver that makes use of the 
>> same battery DT
>> node so that people can choose if they want to configure a kernel for fuel 
>> gauge or
>> g-a-b or even both.
>> 
>>> 
 [   13.312469] bq27xxx_battery_set_config
 [   13.407745] bq27xxx_battery_unseal
 [   13.455993] bq27xxx_battery_update_dm_block
 [   13.460418] bq27xxx-battery 2-0055: update terminate-voltage to 3200
 [   13.694885] bq27xxx_battery_seal
>>> 
>>> We need to see output after a reboot.
>> 
>> This was the value after first boot with the new driver enabled.
>> 
>> A second boot after removing and reinserting battery shows:
>> 
>> [   11.256713] bq27xxx_battery_setup
>> [   11.256744] bq27xxx_battery_setup: dm_regs=bf05b0e0
>> [   11.257690] (NULL device *): hwmon: 'bq27500-1-0' is not a valid name 
>> attribute, please fix
>> [   11.258056] bq27xxx_battery_settings
>> [   11.258300] bq27xxx-battery 2-0055: invalid 
>> battery:energy-full-design-microwatt-hours 1480
>> [   11.258300] bq27xxx_battery_set_config
>> [   11.258331] bq27xxx_battery_unseal
> 
> No mention of terminate-voltage in that run?

No, I didn't see it again.

> Or is this truncated?
> Looks like you didn't set energy-* to zero, so I can't tell if charge-* works.

Seems to need more 

[PATCH] f2fs: constify super_operations

[Arvind Yadav]

super_operations are not supposed to change at runtime.
"struct super_block" working with super_operations provided
by  work with const super_operations. So mark
the non-const structs as const

Signed-off-by: Arvind Yadav 
---
 fs/f2fs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 32e4c02..2bf0869 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1199,7 +1199,7 @@ static inline void f2fs_quota_off_umount(struct 
super_block *sb)
 }
 #endif
 
-static struct super_operations f2fs_sops = {
+static const struct super_operations f2fs_sops = {
.alloc_inode= f2fs_alloc_inode,
.drop_inode = f2fs_drop_inode,
.destroy_inode  = f2fs_destroy_inode,
-- 
1.9.1

Re: [kernel-hardening] [PATCH v5 04/10] arm64: Add __flush_tlb_one()

[Mark Rutland]

On Thu, Aug 31, 2017 at 11:43:53AM +0200, Juerg Haefliger wrote:
> On 08/30/2017 06:47 PM, Tycho Andersen wrote:
> > On Wed, Aug 30, 2017 at 07:31:25AM +0200, Juerg Haefliger wrote:
> >>
> >>
> >> On 08/23/2017 07:04 PM, Mark Rutland wrote:
> >>> On Wed, Aug 23, 2017 at 10:58:42AM -0600, Tycho Andersen wrote:
>  Hi Mark,
> 
>  On Mon, Aug 14, 2017 at 05:50:47PM +0100, Mark Rutland wrote:
> > That said, is there any reason not to use flush_tlb_kernel_range()
> > directly?
> 
>  So it turns out that there is a difference between __flush_tlb_one() and
>  flush_tlb_kernel_range() on x86: flush_tlb_kernel_range() flushes all 
>  the TLBs
>  via on_each_cpu(), where as __flush_tlb_one() only flushes the local TLB 
>  (which
>  I think is enough here).
> >>>
> >>> That sounds suspicious; I don't think that __flush_tlb_one() is
> >>> sufficient.
> >>>
> >>> If you only do local TLB maintenance, then the page is left accessible
> >>> to other CPUs via the (stale) kernel mappings. i.e. the page isn't
> >>> exclusively mapped by userspace.
> >>
> >> We flush all CPUs to get rid of stale entries when a new page is
> >> allocated to userspace that was previously allocated to the kernel.
> >> Is that the scenario you were thinking of?
> > 
> > I think there are two cases, the one you describe above, where the
> > pages are first allocated, and a second one, where e.g. the pages are
> > mapped into the kernel because of DMA or whatever. In the case you
> > describe above, I think we're doing the right thing (which is why my
> > test worked correctly, because it tested this case).
> > 
> > In the second case, when the pages are unmapped (i.e. the kernel is
> > done doing DMA), do we need to flush the other CPUs TLBs? I think the
> > current code is not quite correct, because if multiple tasks (CPUs)
> > map the pages, only the TLB of the last one is flushed when the
> > mapping is cleared, because the tlb is only flushed when ->mapcount
> > drops to zero, leaving stale entries in the other TLBs. It's not clear
> > to me what to do about this case.
> 
> For this to happen, multiple CPUs need to have the same userspace page
> mapped at the same time. Is this a valid scenario?

I believe so. I think you could trigger that with a multi-threaded
application running across several CPUs. All those threads would share
the same page tables.

Thanks,
Mark.

Re: [RFC PATCH v9 5/7] perf: cavium: Support memory controller PMU counters

[Jan Glauber]

On Wed, Aug 30, 2017 at 10:54:03AM +0800, Zhangshaokun wrote:
> Hi Jan,
> 
> Some trivial things i noticed, please consider if you are glad.
> 
> Thanks,
> Shaokun

Hi Shaokun, thanks for the review.

> On 2017/8/29 21:12, Jan Glauber wrote:
> > Add support for the PMU counters on Cavium SOC memory controllers.
> > 
> > This patch also adds generic functions to allow supporting more
> > devices with PMU counters.
> > 
> > Properties of the LMC PMU counters:
> > - not stoppable
> > - fixed purpose
> > - read-only
> > - one PCI device per memory controller
> > 
> > Signed-off-by: Jan Glauber 
> > ---
> >  drivers/perf/Kconfig|   8 +
> >  drivers/perf/Makefile   |   1 +
> >  drivers/perf/cavium_pmu.c   | 445 
> > 
> >  drivers/soc/cavium/cavium_lmc.c |   4 +
> >  include/linux/cpuhotplug.h  |   1 +
> >  include/linux/soc/cavium/lmc.h  |   3 +
> >  6 files changed, 462 insertions(+)
> >  create mode 100644 drivers/perf/cavium_pmu.c
> > 
> > diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
> > index e5197ff..a787562 100644
> > --- a/drivers/perf/Kconfig
> > +++ b/drivers/perf/Kconfig
> > @@ -43,4 +43,12 @@ config XGENE_PMU
> >  help
> >Say y if you want to use APM X-Gene SoC performance monitors.
> >  
> > +config CAVIUM_PMU_LMC
> > +   tristate "Cavium SOC memory controller PMU"
> > +   depends on ARCH_THUNDER && m
> > +   select CAVIUM_LMC
> > +   help
> > + Provides PMU counters for the memory controller on
> > + Cavium ThunderX or OcteonTX SOCs.
> > +
> >  endmenu
> > diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
> > index 6420bd4..077a15d 100644
> > --- a/drivers/perf/Makefile
> > +++ b/drivers/perf/Makefile
> > @@ -3,3 +3,4 @@ obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
> >  obj-$(CONFIG_QCOM_L2_PMU)  += qcom_l2_pmu.o
> >  obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
> >  obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
> > +obj-$(CONFIG_CAVIUM_PMU_LMC) += cavium_pmu.o
> 
> Keep in alphabetic order?
> 

OK.

> > diff --git a/drivers/perf/cavium_pmu.c b/drivers/perf/cavium_pmu.c
> > new file mode 100644
> > index 000..bcdedaa
> > --- /dev/null
> > +++ b/drivers/perf/cavium_pmu.c
> > @@ -0,0 +1,445 @@
> > +/*
> > + * Cavium ARM SOC "uncore" PMU counters
> > + *
> > + * This file is subject to the terms and conditions of the GNU General 
> > Public
> > + * License.  See the file "COPYING" in the main directory of this archive
> > + * for more details.
> > + *
> > + * Copyright Cavium, Inc. 2017
> > + * Author(s): Jan Glauber 
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> Keep the include header files in alphabetic order too?
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +enum cvm_pmu_type {
> > +   CVM_PMU_LMC,
> > +};
> > +
> > +/* maximum number of parallel hardware counters for all pmu types */
> > +#define CVM_PMU_MAX_COUNTERS 64
> > +
> > +/* generic struct to cover the different pmu types */
> > +struct cvm_pmu_dev {
> > +   struct pmu pmu;
> > +   const char *pmu_name;
> 
> It seems that pmu_name is redundant since struct pmu has a name field,
> Mark has mentioned it in HiSilicon uncore PMU driver, Link:
> https://patchwork.kernel.org/patch/9861821/

I don't get it. perf_pmu_register() just copies the char* from the
argument into pmu->name. Somewhere the string must be allocated.
That's why I have cvm_pmu_dev->pmu_name.

> > +   bool (*event_valid)(u64);
> > +   void __iomem *map;
> > +   struct pci_dev *pdev;
> > +   int num_counters;
> > +   struct perf_event *events[CVM_PMU_MAX_COUNTERS];
> > +   struct list_head entry;
> > +   struct hlist_node cpuhp_node;
> > +   cpumask_t active_mask;
> > +};
> > +
> > +static struct list_head cvm_pmu_lmcs;
> > +static struct list_head cvm_pmu_tlks;
> > +
> > +/*
> > + * Common Cavium PMU stuff
> > + *
> > + * Shared properties of the different PMU types:
> > + * - all counters are 64 bit long
> > + * - there are no overflow interrupts
> > + * - all devices with PMU counters appear as PCI devices
> > + *
> > + * Counter control, access and device association depends on the
> > + * PMU type.
> > + */
> > +
> > +#define to_pmu_dev(x) container_of((x), struct cvm_pmu_dev, pmu)
> > +
> > +static int cvm_pmu_event_init(struct perf_event *event)
> > +{
> > +   struct hw_perf_event *hwc = >hw;
> > +   struct cvm_pmu_dev *pmu_dev;
> > +   struct perf_event *sibling;
> > +
> > +   if (event->attr.type != event->pmu->type)
> > +   return -ENOENT;
> > +
> > +   /* we do not support sampling */
> > +   if (is_sampling_event(event))
> > +   return -EINVAL;
> > +
> > +   /* PMU counters do not support any these bits */
> > +   if (event->attr.exclude_user||
> > +   event->attr.exclude_kernel  ||
> > +   event->attr.exclude_host||
> > +   event->attr.exclude_guest   ||
> > +   

Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

[Alexandre Belloni]

On 31/08/2017 at 12:38:17 +0300, Andy Shevchenko wrote:
> On Thu, 2017-08-31 at 11:35 +0200, Alexandre Belloni wrote:
> > On 31/08/2017 at 12:04:03 +0300, Andy Shevchenko wrote:
> > > On Thu, 2017-08-31 at 10:23 +0200, Julia Lawall wrote:
> > > > 
> > > > On Thu, 31 Aug 2017, Alexandre Belloni wrote:
> > > > 
> > > > > On 31/08/2017 at 06:40:42 +0200, Christophe JAILLET wrote:
> > > > > > 
> 
> > > I didn't look into the code, though speculating it might be the case
> > > when CLK framework is not enabled, though many drivers are dependent
> > > to
> > > it, so, it would never fail in such cases.
> > 
> > It is not the case, it would return 0. Anyway, this will not happen
> > because that driver depends on ARCH_AT91 which selects COMMON_CLK_AT91
> > which selects COMMON_CLK.
> > 
> > > Nevertheless there might be
> > > other cases for CLK API to fail.
> > > 
> > 
> > The only case would be for a clock to be enabled without being
> > prepared
> > and this will never happen because clk_prepare_enable is used.
> > 
> > This call will just never fail.
> 
> So, then this is a bug of CLK API per se to have a prototype to return
> int, right?
> 

No because it may fail on other platforms.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH] arm64: relax assembly code alignment from 16 byte to 4 byte

[Masahiro Yamada]

Aarch64 instructions must be word aligned.  The current 16 byte
alignment is more than enough.  Relax it into 4 byte alignment.

Signed-off-by: Masahiro Yamada 
---

I do not know why arm64 Linux requires 16 byte alignment.

I dug git-history of arch/arm64/include/asm/linkage.h
and the only commit I see is:

  commit aeed41a9371ee02257b608eb06a9058507a7d0f4
  Author: Marc Zyngier 
  Date:   Fri Oct 19 17:33:27 2012 +0100

  arm64: fix alignment padding in assembly code

It just opt out of the asm-generic variant to remove 0x90.
So, the amount of alignment might not be not optimized yet.

Please correct me if I am missing something.


 arch/arm64/include/asm/linkage.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/linkage.h b/arch/arm64/include/asm/linkage.h
index 636c1bc..1b26629 100644
--- a/arch/arm64/include/asm/linkage.h
+++ b/arch/arm64/include/asm/linkage.h
@@ -1,7 +1,7 @@
 #ifndef __ASM_LINKAGE_H
 #define __ASM_LINKAGE_H
 
-#define __ALIGN.align 4
-#define __ALIGN_STR".align 4"
+#define __ALIGN.align 2
+#define __ALIGN_STR".align 2"
 
 #endif
-- 
2.7.4

Re: [RFC PATCH v9 5/7] perf: cavium: Support memory controller PMU counters

[Mark Rutland]

On Thu, Aug 31, 2017 at 11:57:46AM +0200, Jan Glauber wrote:
> On Wed, Aug 30, 2017 at 10:54:03AM +0800, Zhangshaokun wrote:
> > On 2017/8/29 21:12, Jan Glauber wrote:
> > > Add support for the PMU counters on Cavium SOC memory controllers.
> > > 
> > > This patch also adds generic functions to allow supporting more
> > > devices with PMU counters.

> > > +/* generic struct to cover the different pmu types */
> > > +struct cvm_pmu_dev {
> > > + struct pmu pmu;
> > > + const char *pmu_name;
> > 
> > It seems that pmu_name is redundant since struct pmu has a name field,
> > Mark has mentioned it in HiSilicon uncore PMU driver, Link:
> > https://patchwork.kernel.org/patch/9861821/
> 
> I don't get it. perf_pmu_register() just copies the char* from the
> argument into pmu->name. Somewhere the string must be allocated.
> That's why I have cvm_pmu_dev->pmu_name.

I'm not sure I follow. cvm_pmu_dev->pmu_name is just a char *, so what
does that have to do with allocation?

... unless you mean you want to allocate this in some variant-specific
code prior to passing it to code which calls perf_pmu_register(), and
you just need a place to stash it in the mean time?

> > > diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> > > index 82b30e6..ca84ac8 100644
> > > --- a/include/linux/cpuhotplug.h
> > > +++ b/include/linux/cpuhotplug.h
> > > @@ -139,6 +139,7 @@ enum cpuhp_state {
> > >   CPUHP_AP_PERF_ARM_QCOM_L3_ONLINE,
> > >   CPUHP_AP_WORKQUEUE_ONLINE,
> > >   CPUHP_AP_RCUTREE_ONLINE,
> > > + CPUHP_AP_PERF_ARM_CVM_ONLINE,
> > 
> > Alphabetic order?
> 
> These don't look alphabetically ordered to me.

Sure, the full list is ordered by dependency.

However, we've generally kept the uncore PMUs together, and within the
group of system PMU CPUHP_AP_PERF_ARM_* callbacks, we've retained
alphabetical order.

Does this PMU need workqueues and RCU up before its HP callback is
invoked? Or can this be moved into the group of CPUHP_AP_PERF_ARM_*
above CPUHP_AP_WORKQUEUE_ONLINE and CPUHP_AP_RCUTREE_ONLINE? i.e.
between CPUHP_AP_PERF_ARM_CCN_ONLINE and CPUHP_AP_PERF_ARM_L2X0_ONLINE.

THanks,
Mark.

Re: [PATCH v6 4/4] perf vendor events arm64: Add ThunderX2 implementation defined pmu core events

[Zhangshaokun]

Hi Robert,

On 2017/8/29 20:47, Robert Richter wrote:
> Shaokun,
> 
> On 29.08.17 17:26:00, Zhangshaokun wrote:
>> On 2017/8/24 20:03, Ganapatrao Kulkarni wrote:
>>> This is not a full event list, but a short list of useful events.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> ---
>>>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>>>  .../arm64/thunderx2/implementation-defined.json| 62 
>>> ++
>>>  2 files changed, 77 insertions(+)
>>>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>>>  create mode 100644 
>>> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>>>
>>
>> I saw you also used thunderx2 in tools/perf/pmu-events/arch/arm64/, how 
>> about John's suggestion
>> that would use vendor sub-folder?
>> Of course, appreciate maintainer's comments.
> 
> this would just add another level of subdirectories. I rather would
> prefer to have a per platform dir comparable to what is listed in
> 
>  arch/arm64/Kconfig.platforms
> 

Check it again that not all vendors have specific platform config per SoC 
family,
so this would not work for us (HiSilicon) and maybe some other vendors.

Thanks,
Shaokun

> This is the same as Ganapat has implemented it.
> 
> -Robert
> 
> 

Re: [PATCH v2 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

[kbuild test robot]

Hi Leon,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.13-rc7 next-20170829]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Soren-Brinkmann/media-imx274-device-tree-binding-file/20170831-144636
base:   git://linuxtv.org/media_tree.git master
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   drivers/media/i2c/imx274.o: In function `imx274_set_exposure':
>> imx274.c:(.text+0x42c): undefined reference to `__divdi3'
   imx274.c:(.text+0x464): undefined reference to `__divdi3'
   imx274.c:(.text+0x94c): undefined reference to `__divdi3'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 10/13] openrisc: add simple_smp dts and defconfig for simulators

[Mark Rutland]

On Thu, Aug 31, 2017 at 07:03:11AM +0900, Stafford Horne wrote:
> From: Stefan Kristiansson 
> 
> Simple enough to be compatible with simulation environments,
> such as verilated systems, QEMU and other targets supporting OpenRISC
> SMP.  This also supports our base FPGA SoC's if the cpu frequency is
> upped to 50Mhz.
> 
> Signed-off-by: Stefan Kristiansson 
> [sho...@gmail.com: Added defconfig]
> Signed-off-by: Stafford Horne 
> ---
>  arch/openrisc/boot/dts/simple_smp.dts  | 58 ++
>  arch/openrisc/configs/simple_smp_defconfig | 66 
> ++
>  2 files changed, 124 insertions(+)
>  create mode 100644 arch/openrisc/boot/dts/simple_smp.dts
>  create mode 100644 arch/openrisc/configs/simple_smp_defconfig
> 
> diff --git a/arch/openrisc/boot/dts/simple_smp.dts 
> b/arch/openrisc/boot/dts/simple_smp.dts
> new file mode 100644
> index ..47c54101baae
> --- /dev/null
> +++ b/arch/openrisc/boot/dts/simple_smp.dts
> @@ -0,0 +1,58 @@
> +/dts-v1/;
> +/ {
> + compatible = "opencores,or1ksim";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + interrupt-parent = <>;
> +
> + chosen {
> + bootargs = "console=uart,mmio,0x9000,115200";
> + };

Any reason this isn't using stdout-path?

> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x 0x0200>;
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu@0 {
> + compatible = "opencores,or1200-rtlsvn481";
> + reg = <0>;
> + clock-frequency = <2000>;
> + };
> + cpu@1 {
> + compatible = "opencores,or1200-rtlsvn481";
> + reg = <1>;
> + clock-frequency = <2000>;
> + };
> + };

No enable-method or similar?

Is your SMP bringup/teardown architected?

> +
> + ompic: ompic {
> + compatible = "ompic";

This needs a vendor prefix.

Thanks,
Mark.

RE: [PATCH] RM64: dts: ls208xa: Add iommu-map property for pci

[Bharat Bhushan]

> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Thursday, August 31, 2017 3:02 PM
> To: Bharat Bhushan ; robh...@kernel.org;
> ark.rutl...@arm.com; will.dea...@arm.com; o...@buserror.net; Gang Liu
> ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> catalin.mari...@arm.com
> Subject: Re: [PATCH] RM64: dts: ls208xa: Add iommu-map property for pci
> 
> On 31/08/17 10:23, Bharat Bhushan wrote:
> > This patch adds iommu-map property for PCIe, which enables SMMU for
> > these devices on LS208xA devices.
> >
> > Signed-off-by: Bharat Bhushan 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > index 94cdd30..67cf605 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> > @@ -606,6 +606,7 @@
> > num-lanes = <4>;
> > bus-range = <0x0 0xff>;
> > msi-parent = <>;
> > +   iommu-map = <0  0 1>;  /* This is fixed-up by
> u-boot */
> 
> What does this do when your version of u-boot doesn't fill this in for you?

Good question, frankly I have not thought of this case before.
But if we pass length = 0 in above property then no fixup happen with happen 
with older u-boot. In this case of_iommu_configure() will return NULL iommu-ops 
and it switch to swio-tlb. Will that work?

Thanks
-Bharat

> 
> Thanks,
> 
>   M.
> --
> Jazz is not dead. It just smells funny...

Re: [PATCH v4 3/5] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Wed, Aug 23, 2017 at 04:54:45PM -0600, Toshi Kani wrote:
> The ghes_edac driver was introduced in 2013 [1], but it has not
> been enabled by any distro yet.  This driver obtains error info
> from firmware interfaces, which are not properly implemented on
> many platforms, as the driver always emits the messages below:
> 
>  This EDAC driver relies on BIOS to enumerate memory and get error reports.
>  Unfortunately, not all BIOSes reflect the memory layout correctly
>  So, the end result of using this driver varies from vendor to vendor
>  If you find incorrect reports, please contact your hardware vendor
>  to correct its BIOS.
> 
> To get out from this situation, add a platform check to selectively
> enable the driver on the platforms that are known to have proper
> firmware implementation.  Platform vendors can add their platforms
> to the list when they support ghes_edac.
> 
> "ghes_edac.force_load=1" skips this platform check.
> 
> [1]: https://lwn.net/Articles/538438/
> Signed-off-by: Toshi Kani 
> Cc: Borislav Petkov 
> Cc: Mauro Carvalho Chehab 
> Cc: Tony Luck 
> ---
>  drivers/edac/ghes_edac.c |   29 -
>  1 file changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
> index 8d904df..0030a09 100644
> --- a/drivers/edac/ghes_edac.c
> +++ b/drivers/edac/ghes_edac.c
> @@ -38,6 +38,10 @@ static struct ghes_edac_pvt *ghes_pvt;
>   */
>  static DEFINE_SPINLOCK(ghes_lock);
>  
> +/* Set 1 to skip the platform check */
> +static bool __read_mostly ghes_edac_force_load;

It is static - "force_load" as a bool name is enough.

> +module_param_named(force_load, ghes_edac_force_load, bool, 0);

ERROR: Use 4 digit octal (0777) not decimal permissions
#53: FILE: drivers/edac/ghes_edac.c:43:
+module_param_named(force_load, ghes_edac_force_load, bool, 0);

This last param is @perm: visibility in sysfs. Why not visible in sysfs?

> +
>  /* Memory Device - Type 17 of SMBIOS spec */
>  struct memdev_dmi_entry {
>   u8 type;
> @@ -415,6 +419,15 @@ void ghes_edac_report_mem_error(struct ghes *ghes, int 
> sev,
>   spin_unlock_irqrestore(_lock, flags);
>  }
>  
> +/*
> + * Known systems that are safe to enable this module.
> + * "ghes_edac.force_load=1" skips this check if necessary.

Put this second sentence over the parameter definition.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v2 2/2] media:imx274 V4l2 driver for Sony imx274 CMOS sensor

[kbuild test robot]

Hi Leon,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.13-rc7 next-20170829]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Soren-Brinkmann/media-imx274-device-tree-binding-file/20170831-144636
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "__divdi3" [drivers/media/i2c/imx274.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] f2fs: constify super_operations

[Chao Yu]

On 2017/8/31 17:36, Arvind Yadav wrote:
> super_operations are not supposed to change at runtime.
> "struct super_block" working with super_operations provided
> by  work with const super_operations. So mark
> the non-const structs as const
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Chao Yu 

> ---
>  fs/f2fs/super.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 32e4c02..2bf0869 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1199,7 +1199,7 @@ static inline void f2fs_quota_off_umount(struct 
> super_block *sb)
>  }
>  #endif
>  
> -static struct super_operations f2fs_sops = {
> +static const struct super_operations f2fs_sops = {
>   .alloc_inode= f2fs_alloc_inode,
>   .drop_inode = f2fs_drop_inode,
>   .destroy_inode  = f2fs_destroy_inode,
> 

[PATCH 1/2] f2fs: avoid race in between atomic_read & atomic_inc

[Chao Yu]

Previously, we will miss merging flush command during fsync due to below
race condition:

Thread AThread BThread C
- f2fs_issue_flush
 - atomic_read(_flush)
- f2fs_issue_flush
 - atomic_read(_flush)
- f2fs_issue_flush
 - atomic_read(_flush)
  - atomic_inc(_flush)
  - atomic_inc(_flush)
  - atomic_inc(_flush)
   - submit_flush_wait
   - submit_flush_wait
   - submit_flush_wait

It needs to use atomic_inc_return instead to avoid such race.

Signed-off-by: Chao Yu 
---
 fs/f2fs/segment.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index d6c3f456ea51..1215ca1bd4e2 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -536,8 +536,7 @@ int f2fs_issue_flush(struct f2fs_sb_info *sbi)
return ret;
}
 
-   if (!atomic_read(>issing_flush)) {
-   atomic_inc(>issing_flush);
+   if (atomic_inc_return(>issing_flush) == 1) {
ret = submit_flush_wait(sbi);
atomic_dec(>issing_flush);
 
@@ -547,7 +546,6 @@ int f2fs_issue_flush(struct f2fs_sb_info *sbi)
 
init_completion();
 
-   atomic_inc(>issing_flush);
llist_add(, >issue_list);
 
/* update issue_list before we wake up issue_flush thread */
-- 
2.13.1.388.g69e6b9b4f4a9

[PATCH 2/2] f2fs: fix to wake up all sleeping flusher

[Chao Yu]

In scenario of remount_ro vs flush, after flush_thread exits in
->remount_fs, flusher will only clean up golbal issue_list, but
without waking up flushers waiting on that list, result in hang
related user threads.

In order to fix this issue, this patch enables the flusher to
take charge of issue_flush thread: executes merged flush command,
and wake up all sleeping flushers.

Fixes: 5eba8c5d1fb3 ("f2fs: fix to access nullified flush_cmd_control pointer")
Signed-off-by: Chao Yu 
---
 fs/f2fs/segment.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 1215ca1bd4e2..265c3bc44f2d 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -558,8 +558,27 @@ int f2fs_issue_flush(struct f2fs_sb_info *sbi)
wait_for_completion();
atomic_dec(>issing_flush);
} else {
-   llist_del_all(>issue_list);
-   atomic_set(>issing_flush, 0);
+   struct llist_node *list;
+
+   list = llist_del_all(>issue_list);
+   if (!list) {
+   wait_for_completion();
+   atomic_dec(>issing_flush);
+   } else {
+   struct flush_cmd *tmp, *next;
+
+   ret = submit_flush_wait(sbi);
+
+   llist_for_each_entry_safe(tmp, next, list, llnode) {
+   if (tmp == ) {
+   cmd.ret = ret;
+   atomic_dec(>issing_flush);
+   continue;
+   }
+   tmp->ret = ret;
+   complete(>wait);
+   }
+   }
}
 
return cmd.ret;
-- 
2.13.1.388.g69e6b9b4f4a9

[PATCH v2 04/13] ANDROID: binder: add min sched_policy to node.

[Martijn Coenen]

This change adds flags to flat_binder_object.flags
to allow indicating a minimum scheduling policy for
the node. It also clarifies the valid value range
for the priority bits in the flags.

Internally, we use the priority map that the kernel
uses, e.g. [0..99] for real-time policies and [100..139]
for the SCHED_NORMAL/SCHED_BATCH policies.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c| 28 +
 include/uapi/linux/android/binder.h | 41 -
 2 files changed, 60 insertions(+), 9 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 282c2a89ab2e..afb3297ae520 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -352,6 +352,8 @@ struct binder_error {
  *and by @lock)
  * @has_async_transaction: async transaction to node in progress
  *(protected by @lock)
+ * @sched_policy: minimum scheduling policy for node
+ *(invariant after initialized)
  * @accept_fds:   file descriptor operations supported for node
  *(invariant after initialized)
  * @min_priority: minimum scheduling priority
@@ -391,6 +393,7 @@ struct binder_node {
/*
 * invariant after initialization
 */
+   u8 sched_policy:2;
u8 accept_fds:1;
u8 min_priority;
};
@@ -1256,6 +1259,7 @@ static struct binder_node *binder_init_node_ilocked(
binder_uintptr_t ptr = fp ? fp->binder : 0;
binder_uintptr_t cookie = fp ? fp->cookie : 0;
__u32 flags = fp ? fp->flags : 0;
+   s8 priority;
 
BUG_ON(!spin_is_locked(>inner_lock));
while (*p) {
@@ -1287,8 +1291,10 @@ static struct binder_node *binder_init_node_ilocked(
node->ptr = ptr;
node->cookie = cookie;
node->work.type = BINDER_WORK_NODE;
-   node->min_priority = NICE_TO_PRIO(
-   flags & FLAT_BINDER_FLAG_PRIORITY_MASK);
+   priority = flags & FLAT_BINDER_FLAG_PRIORITY_MASK;
+   node->sched_policy = (flags & FLAT_BINDER_FLAG_PRIORITY_MASK) >>
+   FLAT_BINDER_FLAG_SCHED_POLICY_SHIFT;
+   node->min_priority = to_kernel_prio(node->sched_policy, priority);
node->accept_fds = !!(flags & FLAT_BINDER_FLAG_ACCEPTS_FDS);
spin_lock_init(>lock);
INIT_LIST_HEAD(>work.entry);
@@ -4099,12 +4105,17 @@ static int binder_thread_read(struct binder_proc *proc,
tr.cookie =  target_node->cookie;
t->saved_priority.sched_policy = current->policy;
t->saved_priority.prio = current->normal_prio;
-   if (target_node->min_priority < t->priority.prio) {
-   /* The min_priority on a node can currently
-* only use SCHED_NORMAL, so we can just
-* hardcode this here.
+   if (target_node->min_priority < t->priority.prio ||
+   (target_node->min_priority == t->priority.prio &&
+target_node->sched_policy == SCHED_FIFO)) {
+   /*
+* In case the minimum priority on the node is
+* higher (lower value), use that priority. If
+* the priority is the same, but the node uses
+* SCHED_FIFO, prefer SCHED_FIFO, since it can
+* run unbounded, unlike SCHED_RR.
 */
-   prio.sched_policy = SCHED_NORMAL;
+   prio.sched_policy = target_node->sched_policy;
prio.prio = target_node->min_priority;
}
binder_set_priority(current, prio);
@@ -5145,8 +5156,9 @@ static void print_binder_node_nilocked(struct seq_file *m,
hlist_for_each_entry(ref, >refs, node_entry)
count++;
 
-   seq_printf(m, "  node %d: u%016llx c%016llx hs %d hw %d ls %d lw %d is 
%d iw %d tr %d",
+   seq_printf(m, "  node %d: u%016llx c%016llx pri %d:%d hs %d hw %d ls %d 
lw %d is %d iw %d tr %d",
   node->debug_id, (u64)node->ptr, (u64)node->cookie,
+  node->sched_policy, node->min_priority,
   node->has_strong_ref, node->has_weak_ref,
   node->local_strong_refs, node->local_weak_refs,
   node->internal_strong_refs, count, node->tmp_refs);
diff --git a/include/uapi/linux/android/binder.h 
b/include/uapi/linux/android/binder.h
index 7668b5791c91..026558ac254d 100644
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@ -37,9 +37,48 @@ enum {

Re: [RESEND PATCH v5 1/3] pinctrl: Add sleep related state to indicate sleep related configs

[Baolin Wang]

Hi,

On 31 August 2017 at 15:16, Linus Walleij  wrote:
> On Thu, Aug 17, 2017 at 8:50 AM, Baolin Wang  
> wrote:
>
>> In some scenarios, we should set some pins as input/output/pullup/pulldown
>> when the specified system goes into deep sleep mode, then when the system
>> goes into deep sleep mode, these pins will be set automatically by hardware.
>>
>> That means some pins are not controlled by any specific driver in the OS, but
>> need to be controlled when entering sleep mode. Thus we introduce one sleep
>> state config into pinconf-generic for users to configure.
>>
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes since v4:
>>  - Add sleep-hardware-state config to indicate sleep related configs.
>
> No reactions and I can certainly not think of anything better (I even
> suggested this) so patch applied.
>
> Sorry for taking so long to look at this, I've been choked :/

I can understand you are so busy :), thanks for your help.

-- 
Baolin.wang
Best Regards

RE: [PATCH 3/4] phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins

[Yoshihiro Shimoda]

Hi Geert-san,

Thank you for the comments!

> From: Geert Uytterhoeven
> Sent: Thursday, August 31, 2017 4:51 PM
> 
> Hi Shimoda-san,
> 
> On Thu, Aug 31, 2017 at 9:31 AM, Yoshihiro Shimoda
>  wrote:
> > This patch adds SoC-specific parameter to avoid reading/writing
> > specific registers wronly if this driver runs on a SoC which doesn't
> > have dedicated pins (e.g. R-Car D3).
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  drivers/phy/renesas/phy-rcar-gen3-usb2.c | 25 -
> >  1 file changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
> > b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > index 4ea9902..28ebc98 100644
> > --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> 
> > @@ -400,9 +403,18 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, 
> > void *_ch)
> >  }
> >
> >  static const struct of_device_id rcar_gen3_phy_usb2_match_table[] = {
> > -   { .compatible = "renesas,usb2-phy-r8a7795" },
> > -   { .compatible = "renesas,usb2-phy-r8a7796" },
> > -   { .compatible = "renesas,rcar-gen3-usb2-phy" },
> > +   {
> > +   .compatible = "renesas,usb2-phy-r8a7795",
> > +   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
> > +   },
> > +   {
> > +   .compatible = "renesas,usb2-phy-r8a7796",
> > +   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
> > +   },
> > +   {
> > +   .compatible = "renesas,rcar-gen3-usb2-phy",
> > +   .data = (void *)RCAR_GEN3_PHY_HAS_DEDICATED_PINS,
> > +   },
> > { }
> >  };
> 
> Given the generic R-Car Gen3 entry sets RCAR_GEN3_PHY_HAS_DEDICATED_PINS, you
> cannot specify the fallback compatible value of "renesas,rcar-gen3-usb2-phy"
> in the R-Car D3 .dtsi.

I understood it.

> So I'm wondering, does the USB2 PHY still work (with limitations) on R-Car H3
> and M3-W if you drop RCAR_GEN3_PHY_HAS_DEDICATED_PINS?

Yes, the USB PHY still work with limitation (otg capability channel works as
peripheral mode only. Other channels are no limitation).

> If yes, you can drop the flag from the generic entry, and R-Car D3 can specify
> the generic fallback compatible value in its .dtsi, like H3 and M3-W.

I got it. I will fix this patch set.

Best regards,
Yoshihiro Shimoda

> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip

[Eduardo Otubo]

On Mon, Aug 28, 2017 at 04:48:32PM +, KY Srinivasan wrote:
> 
> 
> > -Original Message-
> > From: Haiyang Zhang
> > Sent: Monday, August 28, 2017 8:57 AM
> > To: Stephen Hemminger ; Eduardo Otubo
> > ; KY Srinivasan 
> > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Stephen
> > Hemminger ; David Miller
> > 
> > Subject: RE: [PATCHv2] hv_set_ifconfig.sh double check before setting ip
> > 
> > 
> > 
> > > -Original Message-
> > > From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > > Sent: Monday, August 28, 2017 11:16 AM
> > > To: Eduardo Otubo 
> > > Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; Haiyang
> > > Zhang ; Stephen Hemminger
> > > ; David Miller 
> > > Subject: Re: [PATCHv2] hv_set_ifconfig.sh double check before setting ip
> > >
> > > On Mon, 28 Aug 2017 12:01:21 +0200
> > > Eduardo Otubo  wrote:
> > >
> > > > v2: The script is now a little bit safer so it doesn't conflicts with
> > > > network daemon trying to set configurations at the same time.
> > > >
> > > > This patch fixes the behavior of the hv_set_ifconfig script when
> > > setting
> > > > the interface ip. Sometimes the interface has already been configured
> > > by
> > > > network daemon, in this case hv_set_ifconfig causes "RTNETLINK: file
> > > > exists error"; in order to avoid this error this patch makes sure
> > > double
> > > > checks the interface before trying anything.
> > > >
> > > > Signed-off-by: Eduardo Otubo 
> > >
> > > Adding new dependency on systemd is not going to make this script
> > > even less useful.  I wonder why the script still exists at all? Most of
> > > the
> > > Linux distro's can already setup HV networking without it.
> > >
> > 
> > This script is used by a host to inject IP into guests. KY knows more
> > details about it.
> 
> I wrote this script initially to provide an example script for Distros to 
> base their solution on.
> KVP supports IP injection to enable VM migration. For this scenario, I think 
> we recommend that NM be
> disabled.
> 

So, what you're saying is that this should be fixed downstream,
instead? This solution seems pretty safe for me and long term we can
think about something else that could get rid of this script. So NM or
whatever is in use can actually do the configuration.

Any chance to have this patch ACK'd as a form of a short term
solution?

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

[Peter Zijlstra]

On Thu, Aug 31, 2017 at 05:15:01PM +0900, Byungchul Park wrote:
> It's not important. Ok, check the following, instead:
> 
> context X context Y
> - -
>   wait_for_completion(C)
> acquire(A)
> release(A)
> process_one_work()
>acquire(B)
>release(B)
>work->fn()
>   complete(C)
> 
> We don't need to lose C->A and C->B dependencies unnecessarily.

I really can't be arsed about them. Its really only the first few works
that will retain that dependency anyway, even if you were to retain
them.

All of that is contained in kernel/kthread and kernel/workqueue and can
be audited if needed. Its a very limited amount of code.

Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

[Andy Shevchenko]

On Thu, 2017-08-31 at 10:23 +0200, Julia Lawall wrote:
> 
> On Thu, 31 Aug 2017, Alexandre Belloni wrote:
> 
> > On 31/08/2017 at 06:40:42 +0200, Christophe JAILLET wrote:
> > > If 'clk_prepare_enable()' fails, we must release some resources
> > > before
> > > returning. Add a new label in the existing error handling path and
> > > 'goto'
> > > there.
> > > 
> > > Fixes: 260ea95cc027 ("ASoC: atmel: ac97c: Handle return value of
> > > clk_prepare_enable.")
> > > Signed-off-by: Christophe JAILLET 
> > 
> > And here is the fallout of the stupid, brainless "fixing" of issues
> > reported by static analysis tools.
> > 
> > This clk_prepare_enable will never fail. If it was going to fail,
> > the
> > platform would never boot to a point were it is able to execute that
> > code. It is really annoying to have so much churn for absolutely 0
> > benefit.
> 
> Would it be more productive to put the code back like it was before,
> ie no
> return value and no check, and add a comment to the definition of
> clk_prepare_enable indicating that there are many case where the call
> cannot fail?  Grepping through the code suggests that it is about 50-
> 50 on
> checking the return value or not doing so, which might suggest that
> checking the value is often not required.

I didn't look into the code, though speculating it might be the case
when CLK framework is not enabled, though many drivers are dependent to
it, so, it would never fail in such cases. Nevertheless there might be
other cases for CLK API to fail.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor

[Pavel Machek]

On Thu 2017-08-31 12:01:01, Nikita Yushchenko wrote:
> >> I think that trying to make this generic is purely synthetic. This
> >> information is board-specific per it's nature, it comes from what board
> >> is designed for, different boards have quite different sets of possible
> >> reset reasons. What is needed is - pass this board-specific information
> >> to board-specific user space.
> >>
> >> What's proper API for that, if not a sysfs attribute?
> > 
> > Please go through the thread.
> > 
> > Sysfs attribute is okay, but:
> > 
> > 1) it should probably be a string
> > 
> > 2) it should certainly be superset of all the reasons
> > 
> > 3) it should be in generic place, say /sys/power/reset_reason
> > 
> > 4) it should be documented what each state means
> 
> What I'm concerned here is that a requirement appears for kernel driver
> to keep and maintain knowledge of what all that codes mean. For me,

There's no way around that. Kernel interfaces need to be
documented. If you are passing codes between kernel and application,
_those codes need to be documented_.
 
> So question is - is there any proper API to communicate
> application-private information from hardware through kernel to
> userspace without any in-kernel interpretation?

No.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH v2] perf test powerpc: Fix 'Object code reading' test

[Ravi Bangoria]

'Object code reading' test always fails on powerpc guest. Two reasons
for the failure are:

1. When elf section is too big (size beyond 'unsigned int' max value).
objdump fails to disassemble from such section. This was fixed with
commit 0f6329bd7fc ("binutils/objdump: Fix disassemble for huge elf
sections") in binutils.

2. When the sample is from hypervisor. Hypervisor symbols can not
be resolved within guest and thus thread__find_addr_map() fails for
such symbols. Fix this by ignoring hypervisor symbols in the test.

Signed-off-by: Ravi Bangoria 
---
Changes in v2:
 - Add pr_debug()

 tools/perf/tests/code-reading.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 761c5a4..466a462 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -237,6 +237,11 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
 
thread__find_addr_map(thread, cpumode, MAP__FUNCTION, addr, );
if (!al.map || !al.map->dso) {
+   if (cpumode == PERF_RECORD_MISC_HYPERVISOR) {
+   pr_debug("Hypervisor address can not be resolved - 
skipping\n");
+   return 0;
+   }
+
pr_debug("thread__find_addr_map failed\n");
return -1;
}
-- 
1.8.3.1

Re: [PATCH v2] perf test powerpc: Fix 'Object code reading' test

[Adrian Hunter]

On 31/08/17 12:14, Ravi Bangoria wrote:
> 'Object code reading' test always fails on powerpc guest. Two reasons
> for the failure are:
> 
> 1. When elf section is too big (size beyond 'unsigned int' max value).
> objdump fails to disassemble from such section. This was fixed with
> commit 0f6329bd7fc ("binutils/objdump: Fix disassemble for huge elf
> sections") in binutils.
> 
> 2. When the sample is from hypervisor. Hypervisor symbols can not
> be resolved within guest and thus thread__find_addr_map() fails for
> such symbols. Fix this by ignoring hypervisor symbols in the test.
> 
> Signed-off-by: Ravi Bangoria 

Acked-by: Adrian Hunter 

> ---
> Changes in v2:
>  - Add pr_debug()
> 
>  tools/perf/tests/code-reading.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
> index 761c5a4..466a462 100644
> --- a/tools/perf/tests/code-reading.c
> +++ b/tools/perf/tests/code-reading.c
> @@ -237,6 +237,11 @@ static int read_object_code(u64 addr, size_t len, u8 
> cpumode,
>  
>   thread__find_addr_map(thread, cpumode, MAP__FUNCTION, addr, );
>   if (!al.map || !al.map->dso) {
> + if (cpumode == PERF_RECORD_MISC_HYPERVISOR) {
> + pr_debug("Hypervisor address can not be resolved - 
> skipping\n");
> + return 0;
> + }
> +
>   pr_debug("thread__find_addr_map failed\n");
>   return -1;
>   }
> 

Re: [PATCH v2] pinctrl: qcom: General Purpose clocks for apq8064

[Linus Walleij]

On Wed, Aug 16, 2017 at 8:02 AM, Vinay Simha BN  wrote:

> Add support for general purpose (GP) clocks
> for apq8064
>
> DT binding documentation updated for
> qcom,apq8064-pinctrl general purpose (GP) clocks.
>
> Acked-by: Bjorn Andersson 
> Signed-off-by: Vinay Simha BN 
>
> ---
> v1:
> * only gp_clk_1b tested in nexus7 anx7808 slimport.
>
> v2:
> * bjorn review comments incorporated
>   added gp clock functions
>   merged documentation and driver to single patch

I applied this v2 instead of v1 which has the right ACKs and also
added Rob's ACK.

Yours,
Linus Walleij

Re: [kernel-hardening] [PATCH v5 04/10] arm64: Add __flush_tlb_one()

[Juerg Haefliger]

On 08/30/2017 06:47 PM, Tycho Andersen wrote:
> On Wed, Aug 30, 2017 at 07:31:25AM +0200, Juerg Haefliger wrote:
>>
>>
>> On 08/23/2017 07:04 PM, Mark Rutland wrote:
>>> On Wed, Aug 23, 2017 at 10:58:42AM -0600, Tycho Andersen wrote:
 Hi Mark,

 On Mon, Aug 14, 2017 at 05:50:47PM +0100, Mark Rutland wrote:
> That said, is there any reason not to use flush_tlb_kernel_range()
> directly?

 So it turns out that there is a difference between __flush_tlb_one() and
 flush_tlb_kernel_range() on x86: flush_tlb_kernel_range() flushes all the 
 TLBs
 via on_each_cpu(), where as __flush_tlb_one() only flushes the local TLB 
 (which
 I think is enough here).
>>>
>>> That sounds suspicious; I don't think that __flush_tlb_one() is
>>> sufficient.
>>>
>>> If you only do local TLB maintenance, then the page is left accessible
>>> to other CPUs via the (stale) kernel mappings. i.e. the page isn't
>>> exclusively mapped by userspace.
>>
>> We flush all CPUs to get rid of stale entries when a new page is
>> allocated to userspace that was previously allocated to the kernel.
>> Is that the scenario you were thinking of?
> 
> I think there are two cases, the one you describe above, where the
> pages are first allocated, and a second one, where e.g. the pages are
> mapped into the kernel because of DMA or whatever. In the case you
> describe above, I think we're doing the right thing (which is why my
> test worked correctly, because it tested this case).
> 
> In the second case, when the pages are unmapped (i.e. the kernel is
> done doing DMA), do we need to flush the other CPUs TLBs? I think the
> current code is not quite correct, because if multiple tasks (CPUs)
> map the pages, only the TLB of the last one is flushed when the
> mapping is cleared, because the tlb is only flushed when ->mapcount
> drops to zero, leaving stale entries in the other TLBs. It's not clear
> to me what to do about this case.

For this to happen, multiple CPUs need to have the same userspace page
mapped at the same time. Is this a valid scenario?

...Juerg


> Thoughts?
> 
> Tycho
> 
>> ...Juerg
>>
>>
>>> Thanks,
>>> Mark.
>>>
>>
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] clk: at91: utmi: Support configurable multipliers

[Ludovic Desroches]

Hi Ingo,

I did a similar patch, and I was told that you sent something similar.
I missed your patch since I have not subscribed to the linux-clk mailing
list. If it's related to at91, you should send it to linux-arm mailing list
too.

On Mon, Jul 10, 2017 at 02:24:09PM +0200, Ingo van Lil wrote:
> The AT91 UTMI clock is a PLL generating the 480 MHz USB clock.
> Originally, this PLL always had a fixed x40 multiplier, thus requiring
> a 12 MHz input clock. Recent SOCs (sama5d2 and sama5d3) have a special
> function register for configuring this multiplier, allowing to use
> different main clock frequencies.
> 
> Signed-off-by: Ingo van Lil 

Unfortunately, replacing my patch by yours, it no longer works. More
precisely, USB stuff is broken: utmi rate is weird.

> ---
>  drivers/clk/at91/clk-utmi.c  | 105 
> +--
>  include/soc/at91/atmel-sfr.h |   2 +
>  2 files changed, 104 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/at91/clk-utmi.c b/drivers/clk/at91/clk-utmi.c
> index aadabd9..d41c38b 100644
> --- a/drivers/clk/at91/clk-utmi.c
> +++ b/drivers/clk/at91/clk-utmi.c
> @@ -14,14 +14,29 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "pmc.h"
>  
> +/* default multiplier for SOCs that do not allow configuration via SFR */
>  #define UTMI_FIXED_MUL   40
>  
> +/* supported multiplier settings for SOCs that allow configuration via SFR */
> +struct utmi_multipliers {
> + const char *sfr_compatible_name;
> + u8 multipliers[4];
> +};
> +
> +static const struct utmi_multipliers utmi_multipliers[] = {
> + { "atmel,sama5d2-sfr", { 40, 30, 20, 40 } },
> + { "atmel,sama5d3-sfr", { 40, 30, 20, 10 } },
> +};
> +

I will see if there is no mistake in the datasheet. On my side, I deal
only with '40, 30, 20, 10' case, I am not sure we have to take care of
'40, 30, 20, 40' even if it's not a mistake in the datasheet.

>  struct clk_utmi {
>   struct clk_hw hw;
>   struct regmap *regmap;
> + struct regmap *sfr_regmap;
> + const u8 *multipliers;
>  };
>  
>  #define to_clk_utmi(hw) container_of(hw, struct clk_utmi, hw)
> @@ -66,8 +81,67 @@ static void clk_utmi_unprepare(struct clk_hw *hw)
>  static unsigned long clk_utmi_recalc_rate(struct clk_hw *hw,
> unsigned long parent_rate)
>  {
> - /* UTMI clk is a fixed clk multiplier */
> - return parent_rate * UTMI_FIXED_MUL;
> + struct clk_utmi *utmi = to_clk_utmi(hw);
> + u8 mul = UTMI_FIXED_MUL;
> +
> + if (utmi->sfr_regmap && utmi->multipliers) {
> + u32 regval;
> + regmap_read(utmi->sfr_regmap, AT91_SFR_UTMICKTRIM, );
> + mul = utmi->multipliers[regval & AT91_UTMICKTRIM_FREQ_MASK];
> + }
> +
> + return parent_rate * mul;
> +}
> +
> +static long clk_utmi_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *parent_rate)
> +{
> + struct clk_utmi *utmi = to_clk_utmi(hw);
> + unsigned long bestrate = 0;
> + int bestdiff = -1;
> + int i;
> +
> + if (!utmi->sfr_regmap || !utmi->multipliers)
> + return *parent_rate * UTMI_FIXED_MUL;
> +
> + for (i = 0; i < ARRAY_SIZE(utmi_multipliers); i++) {
> + unsigned long tmprate = *parent_rate * utmi->multipliers[i];
> + int tmpdiff;
> +
> + if (tmprate < rate)
> + continue;
> +
> + tmpdiff = tmprate - rate;
> + if (bestdiff < 0 || bestdiff > tmpdiff) {
> + bestrate = tmprate;
> + bestdiff = tmpdiff;
> + }
> +
> + if (!bestdiff)
> + break;
> + }
> +
> + return bestrate;
> +}
> +
> +static int clk_utmi_set_rate(struct clk_hw *hw, unsigned long rate,
> +  unsigned long parent_rate)
> +{
> + struct clk_utmi *utmi = to_clk_utmi(hw);
> + int i;
> +
> + if (!utmi->sfr_regmap || !utmi->multipliers)
> + return rate == parent_rate * UTMI_FIXED_MUL ? 0 : -EINVAL;
> +
> + for (i = 0; i < ARRAY_SIZE(utmi_multipliers); i++) {
> + if (rate == parent_rate * utmi->multipliers[i]) {
> + regmap_update_bits(utmi->sfr_regmap, 
> AT91_SFR_UTMICKTRIM,
> +AT91_UTMICKTRIM_FREQ_MASK, i);
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
>  }

What's the purpose of this addition? Who should set the rate of the utmi
clock? I mean you have no choice, the rate is 480 MHz.

>  
>  static const struct clk_ops utmi_ops = {
> @@ -75,10 +149,13 @@ static const struct clk_ops utmi_ops = {
>   .unprepare = clk_utmi_unprepare,
>   .is_prepared = clk_utmi_is_prepared,
>   .recalc_rate = clk_utmi_recalc_rate,
> + .round_rate = clk_utmi_round_rate,
> + .set_rate = clk_utmi_set_rate,
>  };
>  
>  static struct clk_hw * 

Re: linux-next: build warning after merge of the xfs tree

[Brian Foster]

On Thu, Aug 31, 2017 at 10:07:03AM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the xfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
> 
> fs/xfs/xfs_buf_item.c: In function 'xfs_buf_item_unlock':
> fs/xfs/xfs_buf_item.c:573:9: warning: unused variable 'ordered' 
> [-Wunused-variable]
>   bool   ordered = !!(bip->bli_flags & XFS_BLI_ORDERED);
>  ^
> 
> Introduced by commit
> 
>   a097077ef708 ("xfs: remove unnecessary dirty bli format check for ordered 
> bufs")
> 

Ugh, this is due to the refactoring of this patch between v1 and v2. I
specifically recall testing for this in v1 because I added the ordered
bool purely to clean up the ASSERT(), then I apparently lost of track of
it for v2.

Anyways.. Christoph, Darrick, preferences to clean this up..? I have no
preference between the v1 or v2 factoring. Or if it's easier, we could
always just drop something like the hunk below on top. Thoughts?

Brian

--- 8< ---

diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c
index ef2c137..f5d25f5 100644
--- a/fs/xfs/xfs_buf_item.c
+++ b/fs/xfs/xfs_buf_item.c
@@ -567,10 +567,15 @@ xfs_buf_item_unlock(
 {
struct xfs_buf_log_item *bip = BUF_ITEM(lip);
struct xfs_buf  *bp = bip->bli_buf;
-   boolaborted = !!(lip->li_flags & XFS_LI_ABORTED);
-   boolhold = !!(bip->bli_flags & XFS_BLI_HOLD);
-   booldirty = !!(bip->bli_flags & XFS_BLI_DIRTY);
-   boolordered = !!(bip->bli_flags & XFS_BLI_ORDERED);
+   boolaborted;
+   boolhold;
+   booldirty;
+   boolordered;
+
+   aborted = !!(lip->li_flags & XFS_LI_ABORTED);
+   hold = !!(bip->bli_flags & XFS_BLI_HOLD);
+   dirty = !!(bip->bli_flags & XFS_BLI_DIRTY);
+   ordered = !!(bip->bli_flags & XFS_BLI_ORDERED);
 
/* Clear the buffer's association with this transaction. */
bp->b_transp = NULL;

Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

[Mark Brown]

On Thu, Aug 31, 2017 at 12:31:33PM +0200, Takashi Iwai wrote:

> This is again a typical problem by such a trivial fix patch: the code
> looks as if it were trivial and correct, buried in a patch series that
> easily leads to the oversight by the maintainer's review.

Right, plus the amount of context that diff shows you.


signature.asc
Description: PGP signature

Re: [PATCH] arm64: relax assembly code alignment from 16 byte to 4 byte

[Robin Murphy]

On 31/08/17 11:23, Lothar Waßmann wrote:
> Hi,
> 
> On Thu, 31 Aug 2017 18:56:23 +0900 Masahiro Yamada wrote:
>> Aarch64 instructions must be word aligned.  The current 16 byte
>> alignment is more than enough.  Relax it into 4 byte alignment.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> I do not know why arm64 Linux requires 16 byte alignment.
>>
>> I dug git-history of arch/arm64/include/asm/linkage.h
>> and the only commit I see is:
>>
>>   commit aeed41a9371ee02257b608eb06a9058507a7d0f4
>>   Author: Marc Zyngier 
>>   Date:   Fri Oct 19 17:33:27 2012 +0100
>>
>>   arm64: fix alignment padding in assembly code
>>
>> It just opt out of the asm-generic variant to remove 0x90.
>> So, the amount of alignment might not be not optimized yet.
>>
>> Please correct me if I am missing something.
>>
>>
>>  arch/arm64/include/asm/linkage.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/linkage.h 
>> b/arch/arm64/include/asm/linkage.h
>> index 636c1bc..1b26629 100644
>> --- a/arch/arm64/include/asm/linkage.h
>> +++ b/arch/arm64/include/asm/linkage.h
>> @@ -1,7 +1,7 @@
>>  #ifndef __ASM_LINKAGE_H
>>  #define __ASM_LINKAGE_H
>>  
>> -#define __ALIGN .align 4
>> -#define __ALIGN_STR ".align 4"
>> +#define __ALIGN .align 2
>> +#define __ALIGN_STR ".align 2"
>>  
>>  #endif
>>
> My math tells me, that 2 is one half of 4 but 4 is one fourth of 16, so
> this change doesn't line up with your commit message, or am I missing
> something?

2^4 = 16
2^2 = 4

The ARM behaviour of the .align directive is a bit funky...

Robin.

> 
> 
> Lothar Waßmann
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

[Mark Brown]

On Thu, Aug 31, 2017 at 12:23:14PM +0200, Takashi Iwai wrote:

> Ah, wait, now I see your point.  It was introduced by the very recent
> patch through Mark's asoc tree (since it was wrongly labeled as "ASoC"
> while it isn't).  That patch looks indeed fishy.  The change in
> atmel_ac97c_resume() is also bad.

The resume check looks fine?  The function appears to do nothing other
than the clk_prepare_enable().

> So, I'd prefer reverting the wrong commit instead, and leave some
> comment about the uselessness of clk_prepare_enable() return value
> check.

I'd rather keep the error checking there, it means that people don't
need to open the code and verify it when they go scanning for potential
problems.


signature.asc
Description: PGP signature

Re: [PATCH v3 00/13] mmc: meson-gx: driver fixups and upgrades

[Ulf Hansson]

On 30 August 2017 at 21:03, Kevin Hilman  wrote:
> Hi Ulf,
>
> Ulf Hansson  writes:
>
>> On 28 August 2017 at 16:29, Jerome Brunet  wrote:
>>> The patchset features several bugfixes, rework and upgrade for the
>>> meson-gx MMC driver.
>>>
>>> The main goal is to improve readability and enable new high speed
>>> modes, such as eMMC DDR52 and sdcard UHS modes up to SDR50 (100Mhz)
>>>
>>> SDR104 is not working with a few cards on the p200 and the
>>> libretech-cc. I suspect that 200Mhz might be a bit too fast for the PCB
>>> of these boards, adding noise to the signal and eventually breaking
>>> the communication with some cards. The same cards are working well on a
>>> laptop or the nanopi-k2 at 200Mhz.
>>>
>>> This series has been tested on gxbb-p200, gxbb-nanopi-k2 and
>>> gxl-s905x-libretech-cc
>>>
>>> Changes since v2 [1]:
>>> * Drop patches 1 to 3: Applied.
>>> * Drop patch 4: Debug stuff which should not have been sent.
>>> * Added fix to previous patch 3:
>>>   If the clock register is not initialized before registering the clk
>>>   with CCF, the framework will complain about an illegal divider value.
>>>   This had gone unnoticed because it was later fixed by the clock init
>>>   rework.
>>>
>>>   Ulf, I know it is getting late but it would be nice if patch #1 of
>>>   this v3 could go with 3 patches you already applied. The rest can
>>>   wait for the following cycle.
>>
>> I decided to pick them all, so applied for next!
>>
>
> Just to double-check, so I can plan for the DT patches
> accordingly... you are queuing this for v4.14, right?

Yes, correct!

Kind regards
Uffe

Re: WARNING: at arch/x86/kernel/stacktrace.c:132 save_stack_trace_tsk_reliable

[Jiri Slaby]

On 08/25/2017, 10:31 PM, Josh Poimboeuf wrote:
> On Fri, Aug 25, 2017 at 10:01:58AM -0500, Josh Poimboeuf wrote:
>> On Fri, Aug 25, 2017 at 03:54:12PM +0200, Jiri Slaby wrote:
>>> So now, there are two things:
>>> 1) how to fix orc_find & unwind_init properly?
>>> 2) how to generate an EMPTY hint for secondary_startup_64 and maybe
>>> later REGS hint after the rsp setup there? The function seems to be a
>>> pretty killer for orc generate (among others in head_64.S):
>>
>> I think the solution is to get head_64.S annotated properly.  Then there
>> won't be a gap between _stext and the first ORC entry, and we won't need
>> to fix __orc_find().
>>
>> I can work up a patch for you to test with.
> 
> Can you try this?

Yep, this works for me. Except I left bad_address in place as I tested
against 4.12.

thanks,
-- 
js
suse labs

RE: [PATCH v4 3/3] eeprom: at24: enable runtime pm support

[Mohandass, Divagar]

Hi Sakari,

Thanks for the review.
My comments below.

---
^Divagar

>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Thursday, August 31, 2017 2:50 AM
>To: Mohandass, Divagar 
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
>devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Mani, Rajmohan 
>Subject: Re: [PATCH v4 3/3] eeprom: at24: enable runtime pm support
>
>Hi Divagar,
>
>Thanks for the update.
>
>On Wed, Aug 30, 2017 at 10:35:40PM +0530, Divagar Mohandass wrote:
>> Currently the device is kept in D0, there is an opportunity to save
>> power by enabling runtime pm.
>>
>> Device can be daisy chained from PMIC and we can't rely on I2C core
>> for auto resume/suspend. Driver will decide when to resume/suspend.
>>
>> Signed-off-by: Divagar Mohandass 
>> ---
>>  drivers/misc/eeprom/at24.c | 40
>> 
>>  1 file changed, 40 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
>> index 2199c42..65a7d83 100644
>> --- a/drivers/misc/eeprom/at24.c
>> +++ b/drivers/misc/eeprom/at24.c
>> @@ -24,6 +24,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /*
>>   * I2C EEPROMs from most vendors are inexpensive and mostly
>interchangeable.
>> @@ -501,11 +502,21 @@ static ssize_t at24_eeprom_write_i2c(struct
>> at24_data *at24, const char *buf,  static int at24_read(void *priv,
>> unsigned int off, void *val, size_t count)  {
>>  struct at24_data *at24 = priv;
>> +struct i2c_client *client;
>>  char *buf = val;
>> +int ret;
>>
>>  if (unlikely(!count))
>>  return count;
>>
>> +client = at24_translate_offset(at24, );
>> +
>> +ret = pm_runtime_get_sync(>dev);
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(>dev);
>> +return ret;
>> +}
>> +
>>  /*
>>   * Read data from chip, protecting against concurrent updates
>>   * from this host, but not from other I2C masters.
>> @@ -518,6 +529,7 @@ static int at24_read(void *priv, unsigned int off,
>void *val, size_t count)
>>  status = at24->read_func(at24, buf, off, count);
>>  if (status < 0) {
>>  mutex_unlock(>lock);
>> +pm_runtime_put(>dev);
>>  return status;
>>  }
>>  buf += status;
>> @@ -527,17 +539,29 @@ static int at24_read(void *priv, unsigned int
>> off, void *val, size_t count)
>>
>>  mutex_unlock(>lock);
>>
>> +pm_runtime_put(>dev);
>> +
>>  return 0;
>>  }
>>
>>  static int at24_write(void *priv, unsigned int off, void *val, size_t
>> count)  {
>>  struct at24_data *at24 = priv;
>> +struct i2c_client *client;
>>  char *buf = val;
>> +int ret;
>>
>>  if (unlikely(!count))
>>  return -EINVAL;
>>
>> +client = at24_translate_offset(at24, );
>> +
>> +ret = pm_runtime_get_sync(>dev);
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(>dev);
>> +return ret;
>> +}
>> +
>>  /*
>>   * Write data to chip, protecting against concurrent updates
>>   * from this host, but not from other I2C masters.
>> @@ -550,6 +574,7 @@ static int at24_write(void *priv, unsigned int off,
>void *val, size_t count)
>>  status = at24->write_func(at24, buf, off, count);
>>  if (status < 0) {
>>  mutex_unlock(>lock);
>> +pm_runtime_put(>dev);
>>  return status;
>>  }
>>  buf += status;
>> @@ -559,6 +584,8 @@ static int at24_write(void *priv, unsigned int
>> off, void *val, size_t count)
>>
>>  mutex_unlock(>lock);
>>
>> +pm_runtime_put(>dev);
>> +
>>  return 0;
>>  }
>>
>> @@ -743,6 +770,14 @@ static int at24_probe(struct i2c_client *client,
>> const struct i2c_device_id *id)
>>
>>  i2c_set_clientdata(client, at24);
>>
>> +/* enable runtime pm */
>> +pm_runtime_get_noresume(>dev);
>> +err = pm_runtime_set_active(>dev);
>> +if (err < 0)
>> +goto err_clients;
>
>Btw. I don't think pm_runtime_set_active() can fail here. In other words it'd 
>be
>fine to ignore the return value.
>

Ack


>> +
>> +pm_runtime_enable(>dev);
>> +
>>  /*
>>   * Perform a one-byte test read to verify that the
>>   * chip is functional.
>> @@ -753,6 +788,8 @@ static int at24_probe(struct i2c_client *client, const
>struct i2c_device_id *id)
>>  goto err_clients;
>
>I suppose the runtime PM state is re-initialised for a device when a driver is
>probed, but it'd still be nice to decrement the use count if this fails.

Ack

>You should also disable PM runtime if probe fails and set the device
>suspended again.
>
>Same for other error cases. I think you'll need a new label.
>

Can I disable PM runtime and set suspend in 

Re: [PATCH] ARC: reset: introduce AXS10x reset driver

[Eugeniy Paltsev]

Hi Philipp,

Do you have plans to add reset-simple driver into 4.14?
It would be nice to use it for AXS10x in 4.14.

Thanks.

On Mon, 2017-08-14 at 13:37 +, Eugeniy Paltsev wrote:
> On Fri, 2017-08-11 at 15:46 +0200, Philipp Zabel wrote:
> > Hi Eugeniy,
> > 
> > On Thu, 2017-08-10 at 19:41 +0300, Eugeniy Paltsev wrote:
> > > ARC AXS10x boards support custom IP-block which allows to control
> > > reset signals of selected peripherals. For example DW GMAC, etc...
> > > This block is controlled via memory-mapped register (AKA CREG)
> > > which
> > > represents up-to 32 reset lines.
> > > 
> > > As of today only the following lines are used:
> > >  - DW GMAC - line 5
> > > 
> > > Signed-off-by: Eugeniy Paltsev 
> > 
> > Could you check if the reset-simple driver that I posted today would
> > work for you?
> > 
> 
> Yes, it would. Thanks.
> 
> -- 
>  Eugeniy Paltsev
-- 
 Eugeniy Paltsev

[PATCH v2 12/13] ANDROID: binder: don't queue async transactions to thread.

[Martijn Coenen]

This can cause issues with processes using the poll()
interface:

1) client sends two oneway transactions
2) the second one gets queued on async_todo
   (because the server didn't handle the first one
yet)
3) server returns from poll(), picks up the
   first transaction and does transaction work
4) server is done with the transaction, sends
   BC_FREE_BUFFER, and the second transaction gets
   moved to thread->todo
5) libbinder's handlePolledCommands() only handles
   the commands in the current data buffer, so
   doesn't see the new transaction
6) the server continues running and issues a new
   outgoing transaction. Now, it suddenly finds
   the incoming oneway transaction on its thread
   todo, and returns that to userspace.
7) userspace does not expect this to happen; it
   may be holding a lock while making the outgoing
   transaction, and if handling the incoming
   trasnaction requires taking the same lock,
   userspace will deadlock.

By queueing the async transaction to the proc
workqueue, we make sure it's only picked up when
a thread is ready for proc work.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 2d23f8699d40..7768ba280177 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3570,11 +3570,13 @@ static int binder_thread_write(struct binder_proc *proc,
BUG_ON(buf_node->proc != proc);
w = binder_dequeue_work_head_ilocked(
_node->async_todo);
-   if (!w)
+   if (!w) {
buf_node->has_async_transaction = 0;
-   else
+   } else {
binder_enqueue_work_ilocked(
-   w, >todo);
+   w, >todo);
+   binder_wakeup_proc_ilocked(proc);
+   }
binder_node_inner_unlock(buf_node);
}
trace_binder_transaction_buffer_release(buffer);
-- 
2.14.1.581.gf28d330327-goog

[PATCH v2 05/13] ANDROID: binder: improve priority inheritance.

[Martijn Coenen]

By raising the priority of a thread selected for
a transaction *before* we wake it up.

Delay restoring the priority when doing a reply
until after we wake-up the process receiving
the reply.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 74 ++--
 1 file changed, 53 insertions(+), 21 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index afb3297ae520..196676729521 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -610,6 +610,7 @@ enum {
  * @is_dead:  thread is dead and awaiting free
  *when outstanding transactions are cleaned up
  *(protected by @proc->inner_lock)
+ * @task: struct task_struct for this thread
  *
  * Bookkeeping structure for binder threads.
  */
@@ -628,6 +629,7 @@ struct binder_thread {
struct binder_stats stats;
atomic_t tmp_ref;
bool is_dead;
+   struct task_struct *task;
 };
 
 struct binder_transaction {
@@ -646,6 +648,7 @@ struct binder_transaction {
unsigned intflags;
struct binder_priority  priority;
struct binder_priority  saved_priority;
+   boolset_priority_called;
kuid_t  sender_euid;
/**
 * @lock:  protects @from, @to_proc, and @to_thread
@@ -1209,6 +1212,38 @@ static void binder_set_priority(struct task_struct *task,
set_user_nice(task, priority);
 }
 
+static void binder_transaction_priority(struct task_struct *task,
+   struct binder_transaction *t,
+   struct binder_priority node_prio)
+{
+   struct binder_priority desired_prio;
+
+   if (t->set_priority_called)
+   return;
+
+   t->set_priority_called = true;
+   t->saved_priority.sched_policy = task->policy;
+   t->saved_priority.prio = task->normal_prio;
+
+   desired_prio.prio = t->priority.prio;
+   desired_prio.sched_policy = t->priority.sched_policy;
+
+   if (node_prio.prio < t->priority.prio ||
+   (node_prio.prio == t->priority.prio &&
+node_prio.sched_policy == SCHED_FIFO)) {
+   /*
+* In case the minimum priority on the node is
+* higher (lower value), use that priority. If
+* the priority is the same, but the node uses
+* SCHED_FIFO, prefer SCHED_FIFO, since it can
+* run unbounded, unlike SCHED_RR.
+*/
+   desired_prio = node_prio;
+   }
+
+   binder_set_priority(task, desired_prio);
+}
+
 static struct binder_node *binder_get_node_ilocked(struct binder_proc *proc,
   binder_uintptr_t ptr)
 {
@@ -2682,11 +2717,15 @@ static bool binder_proc_transaction(struct 
binder_transaction *t,
 {
struct list_head *target_list = NULL;
struct binder_node *node = t->buffer->target_node;
+   struct binder_priority node_prio;
bool oneway = !!(t->flags & TF_ONE_WAY);
bool wakeup = true;
 
BUG_ON(!node);
binder_node_lock(node);
+   node_prio.prio = node->min_priority;
+   node_prio.sched_policy = node->sched_policy;
+
if (oneway) {
BUG_ON(thread);
if (node->has_async_transaction) {
@@ -2708,12 +2747,14 @@ static bool binder_proc_transaction(struct 
binder_transaction *t,
if (!thread && !target_list)
thread = binder_select_thread_ilocked(proc);
 
-   if (thread)
+   if (thread) {
target_list = >todo;
-   else if (!target_list)
+   binder_transaction_priority(thread->task, t, node_prio);
+   } else if (!target_list) {
target_list = >todo;
-   else
+   } else {
BUG_ON(target_list != >async_todo);
+   }
 
binder_enqueue_work_ilocked(>work, target_list);
 
@@ -2790,7 +2831,6 @@ static void binder_transaction(struct binder_proc *proc,
}
thread->transaction_stack = in_reply_to->to_parent;
binder_inner_proc_unlock(proc);
-   binder_set_priority(current, in_reply_to->saved_priority);
target_thread = binder_get_txn_from_and_acq_inner(in_reply_to);
if (target_thread == NULL) {
return_error = BR_DEAD_REPLY;
@@ -3200,6 +3240,7 @@ static void binder_transaction(struct binder_proc *proc,
binder_enqueue_work_ilocked(>work, _thread->todo);
binder_inner_proc_unlock(target_proc);
wake_up_interruptible_sync(_thread->wait);
+   binder_set_priority(current, in_reply_to->saved_priority);
binder_free_transaction(in_reply_to);
} else if (!(t->flags & TF_ONE_WAY)) {
BUG_ON(t->buffer->async_transaction != 0);
@@ 

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

[Peter Zijlstra]

On Wed, Aug 30, 2017 at 08:25:46PM +0900, Byungchul Park wrote:

> For example - I'm giving you the same example repeatedly:
> 
> context X context Y
> - -
>   wait_for_completion(C)
> acquire(A)
> process_one_work()
>acquire(B)
>work->fn()
>   complete(C)
> 
> Please check C->A and C->B.

Is there a caller of procesS_one_work() that holds a lock?

[PATCH] perf tools: Fix syntax in documentation of intel-pt config option

[Jack Henschel]

As specified in tools/perf/Documentation/perf-config.txt, perf
configuration items must be in 'key = value' format, otherwise the
following error message occurs:

$ perf record -e intel_pt//u -- ls
bad config file line 2 in ~/.perfconfig
$ cat .perfconfig
[intel-pt]
mispred-all

Changing assigning a value to the key 'mispred-all' fixes the issue:
$ perf record -e intel_pt//u -- ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Capured and wrote 0.031 MB perf.data]
$ cat .perfconfig
[intel-pt]
mispred-all = true
---
 tools/perf/Documentation/intel-pt.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/intel-pt.txt 
b/tools/perf/Documentation/intel-pt.txt
index 4b6cdbf8f935..a47d845b9b61 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -873,7 +873,7 @@ amended to take the number of elements as a parameter.
 
$ cat ~/.perfconfig
[intel-pt]
-   mispred-all
+   mispred-all = on
 
$ perf record -e intel_pt//u ./sort 3000
Bubble sorting array of 3000 elements
-- 
2.14.1

Re: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration

[Pavel Machek]

Hi!

> >> > -As a specific example of this use-case, let's look at vibrate feature on
> >> > -phones. Vibrate function on phones is implemented using PWM pins on SoC 
> >> > or
> >> > -PMIC. There is a need to activate one shot timer to control the vibrate
> >> > -feature, to prevent user space crashes leaving the phone in vibrate mode
> >> > -permanently causing the battery to drain.
> >> 
> >> I'm not sure if it is a good idea to remove this description. Users will
> >> still be able to use transient trigger this way. It has been around for
> >> five years already and there are users which employ it in this
> >> particular way [0].
> >
> > I am. Yes, people were doing that, but no, vibration motor is not a
> > LED. PWM behaviour is different, for example, motor is likely to stop
> > at low PWM values. We do not want people to do that.
> >
> >> Apart from that it's the only documented kernel API for vibrate devices
> >> AFAICT.
> >
> > Input subsystem has force-feedback protocol, which is very often just
> > vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
> > uses that API.
> 
> N900 as shipped by Nokia used an ad hoc sysfs interface. Because that
> sucked, I advocated using the force feedback API for N950 and
> N9. Because what is vibration but force feedback? It's a much more
> versatile API for vibration than a simple trigger. You get to upload
> effects and have the kernel play them for you, also stopping them in a
> timely manner regardless of the userspace dying and whatnot. I didn't
> double check now, but IIRC you could also link the input to force
> feedback, e.g. for touch vibrations.

Ok, N900 support in mainline actually uses force feedback, as in N9,
N950. It is the right interface.

AFAICT, no mainline ARM board uses LEDs for vibrations. And I hope to
keep it that way :-).

(OpenMoko gta01 did that, IIRC. But that is not mainline, good).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH v2 13/13] ANDROID: binder: Add tracing for binder priority inheritance.

[Martijn Coenen]

This allows to easily trace and visualize priority inheritance
in the binder driver.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c   |  4 
 drivers/android/binder_trace.h | 24 
 2 files changed, 28 insertions(+)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 7768ba280177..9e13711acd14 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1203,6 +1203,10 @@ static void binder_do_set_priority(struct task_struct 
*task,
  task->pid, desired.prio,
  to_kernel_prio(policy, priority));
 
+   trace_binder_set_priority(task->tgid, task->pid, task->normal_prio,
+ to_kernel_prio(policy, priority),
+ desired.prio);
+
/* Set the actual priority */
if (task->policy != policy || is_rt_policy(policy)) {
struct sched_param params;
diff --git a/drivers/android/binder_trace.h b/drivers/android/binder_trace.h
index 76e3b9c8a8a2..b11dffc521e8 100644
--- a/drivers/android/binder_trace.h
+++ b/drivers/android/binder_trace.h
@@ -85,6 +85,30 @@ DEFINE_BINDER_FUNCTION_RETURN_EVENT(binder_ioctl_done);
 DEFINE_BINDER_FUNCTION_RETURN_EVENT(binder_write_done);
 DEFINE_BINDER_FUNCTION_RETURN_EVENT(binder_read_done);
 
+TRACE_EVENT(binder_set_priority,
+   TP_PROTO(int proc, int thread, unsigned int old_prio,
+unsigned int desired_prio, unsigned int new_prio),
+   TP_ARGS(proc, thread, old_prio, new_prio, desired_prio),
+
+   TP_STRUCT__entry(
+   __field(int, proc)
+   __field(int, thread)
+   __field(unsigned int, old_prio)
+   __field(unsigned int, new_prio)
+   __field(unsigned int, desired_prio)
+   ),
+   TP_fast_assign(
+   __entry->proc = proc;
+   __entry->thread = thread;
+   __entry->old_prio = old_prio;
+   __entry->new_prio = new_prio;
+   __entry->desired_prio = desired_prio;
+   ),
+   TP_printk("proc=%d thread=%d old=%d => new=%d desired=%d",
+ __entry->proc, __entry->thread, __entry->old_prio,
+ __entry->new_prio, __entry->desired_prio)
+);
+
 TRACE_EVENT(binder_wait_for_work,
TP_PROTO(bool proc_work, bool transaction_stack, bool thread_todo),
TP_ARGS(proc_work, transaction_stack, thread_todo),
-- 
2.14.1.581.gf28d330327-goog

[PATCH v4 2/3] ACPI / EC: Add event detection support for noirq stages

[Lv Zheng]

1. Problems: Cannot detect EC event in noirq stages.
EC IRQs contain transaction IRQs (OBF/IBF) and event IRQ (SCI_EVT).
Transactions are initiated by hosts. The earliest OSPMs execution of EC
transactions is from acpi_ec_transaction(), where the common EC IRQ
handling procedure - advance_transaction() - is initiated from the task
context.
Events are initiated by targets. The earliest OSPMs execution of EC events
is from acpi_ec_gpe_handler(), where the common EC IRQ handling procedure -
advance_transaction() - is initiated from the IRQ context.
During suspend/resume noirq stage, IRQ is disabled, advance_transaction()
which detects SCI_EVT can only be invoked from task context - ec_poll().
Thus if there is no EC transaction occurring in this stage, EC driver
cannot detect SCI_EVT. And the worst case is if there is no EC transaction
after resume, EC event handling will stuck (FW flags SCI_EVT, but there is
no triggering source for OS to detect it).
Note that in noirq stage if there is an EC transaction pending,
advance_transaction() invoked because of the EC transaction can also help
to detect SCI_EVT and initiate the handling of the EC events. That's why
real reports related to this problem are rare and unreproducible as whether
there is an EC transaction occurred after an undetectable EC events during
noirq stages is random.

2. Old assumption and solution:
In order to solve the above issue, "ec_freeze_events" is implemented to:
stop handling SCI_EVT before suspend noirq stage and restart handling
SCI_EVT after resume noirq stage.
We assumed that detecting SCI_EVT in noirq stage is useless because there
are other conflict issues related to the EC event handling actually making
it not fully functioning during suspend/resume.
This assumption and the solution efficiently solves all issues.
Finally, the EC event handling is namely "frozen" for a specific period
during suspend/resume and "ec_freeze_events" controls the timing of the
"begin/end of the freeze". If freezing event handling earlier could work,
we shouldn't be required to implement event detection in noirq stages.

3. New facts and new problems:
Recently, some bug reports (see Link #1) revealed that we shouldn't
"freeze" EC event handling too early during these system suspend/resume
procedures.
Also enabling EC event handling too late surely changes the event
triggering timing, and may leave driver order issues during resume.
The previous commit in the same series resumes EC event handling earlier in
acpi_ec_unblock_transactions(), but that still leaves another problem to us
that we still cannot detect SCI_EVT occurred after
acpi_ec_unblock_transactions() and before acpi_ec_resume(). In order to
solve the final gap, we need to implement event detection in noirq stages.

4. New solution:
This patch adds a timer to poll EC events timely (0.5s) during system
suspend/resume noirq stages.
This patch has been validated to be able to improve situation related to
the reported bug (see Link #1) which requires to handle EC GPEs longer
during suspend.
With this patch applied, ACPI sleep core may still need to tune the order
of sleep steps by tuning the timing of invoking
acpi_ec_block/unblock_transactions() to fully solve the reported issue.
Actually ec_detect_noirq_events should always be true when ec_freeze_events
is false. But since there could be no noirq stage affection, this patch
introduces a separate runtime configurable option for it so that we can
disable it when there is no affection of the noirq stage.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196129 [#1]
Signed-off-by: Lv Zheng 
Tested-by: Tomislav Ivek 
---
 drivers/acpi/ec.c   | 93 +++--
 drivers/acpi/internal.h |  1 +
 2 files changed, 92 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 3dc4205..9363656 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "internal.h"
@@ -102,6 +103,7 @@ enum ec_command {
 #define ACPI_EC_CLEAR_MAX  100 /* Maximum number of events to query
 * when trying to clear the EC */
 #define ACPI_EC_MAX_QUERIES16  /* Maximum number of parallel queries */
+#define ACPI_EC_EVENT_INTERVAL 500 /* Detecting event every 500ms */
 
 enum {
EC_FLAGS_QUERY_ENABLED, /* Query is enabled */
@@ -113,6 +115,7 @@ enum {
EC_FLAGS_STARTED,   /* Driver is started */
EC_FLAGS_STOPPED,   /* Driver is stopped */
EC_FLAGS_GPE_MASKED,/* GPE masked */
+   EC_FLAGS_GPE_POLLING,   /* GPE polling is enabled */
 };
 
 #define ACPI_EC_COMMAND_POLL   0x01 /* Available for command byte */
@@ -154,6 +157,15 @@ static bool ec_no_wakeup __read_mostly;
 module_param(ec_no_wakeup, bool, 0644);
 MODULE_PARM_DESC(ec_no_wakeup, "Do 

[PATCH v2 01/13] ANDROID: binder: remove proc waitqueue

[Martijn Coenen]

Removes the process waitqueue, so that threads
can only wait on the thread waitqueue. Whenever
there is process work to do, pick a thread and
wake it up. Having the caller pick a thread is
helpful for things like priority inheritance.

This also fixes an issue with using epoll(),
since we no longer have to block on different
waitqueues.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 255 +--
 1 file changed, 181 insertions(+), 74 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index ba9e613b42d6..56211d025c2d 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -28,10 +28,10 @@
  *binder_node_lock() and binder_node_unlock() are
  *used to acq/rel
  * 3) proc->inner_lock : protects the thread and node lists
- *(proc->threads, proc->nodes) and all todo lists associated
- *with the binder_proc (proc->todo, thread->todo,
- *proc->delivered_death and node->async_todo), as well as
- *thread->transaction_stack
+ *(proc->threads, proc->waiting_threads, proc->nodes)
+ *and all todo lists associated with the binder_proc
+ *(proc->todo, thread->todo, proc->delivered_death and
+ *node->async_todo), as well as thread->transaction_stack
  *binder_inner_proc_lock() and binder_inner_proc_unlock()
  *are used to acq/rel
  *
@@ -475,6 +475,8 @@ enum binder_deferred_state {
  *(protected by @outer_lock)
  * @refs_by_node: rbtree of refs ordered by ref->node
  *(protected by @outer_lock)
+ * @waiting_threads:  threads currently waiting for proc work
+ *(protected by @inner_lock)
  * @pid   PID of group_leader of process
  *(invariant after initialized)
  * @tsk   task_struct for group_leader of process
@@ -504,8 +506,6 @@ enum binder_deferred_state {
  *(protected by @inner_lock)
  * @requested_threads_started: number binder threads started
  *(protected by @inner_lock)
- * @ready_threads:number of threads waiting for proc work
- *(protected by @inner_lock)
  * @tmp_ref:  temporary reference to indicate proc is in use
  *(protected by @inner_lock)
  * @default_priority: default scheduler priority
@@ -526,6 +526,7 @@ struct binder_proc {
struct rb_root nodes;
struct rb_root refs_by_desc;
struct rb_root refs_by_node;
+   struct list_head waiting_threads;
int pid;
struct task_struct *tsk;
struct files_struct *files;
@@ -540,7 +541,6 @@ struct binder_proc {
int max_threads;
int requested_threads;
int requested_threads_started;
-   int ready_threads;
int tmp_ref;
long default_priority;
struct dentry *debugfs_entry;
@@ -556,6 +556,7 @@ enum {
BINDER_LOOPER_STATE_EXITED  = 0x04,
BINDER_LOOPER_STATE_INVALID = 0x08,
BINDER_LOOPER_STATE_WAITING = 0x10,
+   BINDER_LOOPER_STATE_POLL= 0x20,
 };
 
 /**
@@ -564,6 +565,8 @@ enum {
  *(invariant after initialization)
  * @rb_node:  element for proc->threads rbtree
  *(protected by @proc->inner_lock)
+ * @waiting_thread_node:  element for @proc->waiting_threads list
+ *(protected by @proc->inner_lock)
  * @pid:  PID for this thread
  *(invariant after initialization)
  * @looper:   bitmap of looping state
@@ -593,6 +596,7 @@ enum {
 struct binder_thread {
struct binder_proc *proc;
struct rb_node rb_node;
+   struct list_head waiting_thread_node;
int pid;
int looper;  /* only modified by this thread */
bool looper_need_return; /* can be written by other thread */
@@ -920,6 +924,86 @@ static long task_close_fd(struct binder_proc *proc, 
unsigned int fd)
return retval;
 }
 
+static bool binder_has_work_ilocked(struct binder_thread *thread,
+   bool do_proc_work)
+{
+   return !binder_worklist_empty_ilocked(>todo) ||
+   thread->looper_need_return ||
+   (do_proc_work &&
+!binder_worklist_empty_ilocked(>proc->todo));
+}
+
+static bool binder_has_work(struct binder_thread *thread, bool do_proc_work)
+{
+   bool has_work;
+
+   binder_inner_proc_lock(thread->proc);
+   has_work = binder_has_work_ilocked(thread, do_proc_work);
+   binder_inner_proc_unlock(thread->proc);
+
+   return has_work;
+}
+
+static bool binder_available_for_proc_work_ilocked(struct binder_thread 
*thread)
+{
+   return !thread->transaction_stack &&
+   binder_worklist_empty_ilocked(>todo) &&
+   (thread->looper & 

[PATCH v2 02/13] ANDROID: binder: push new transactions to waiting threads.

[Martijn Coenen]

Instead of pushing new transactions to the process
waitqueue, select a thread that is waiting on proc
work to handle the transaction. This will make it
easier to improve priority inheritance in future
patches, by setting the priority before we wake up
a thread.

If we can't find a waiting thread, submit the work
to the proc waitqueue instead as we did previously.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 181 +--
 1 file changed, 127 insertions(+), 54 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 56211d025c2d..5366726db968 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -970,7 +970,20 @@ static void binder_wakeup_poll_threads_ilocked(struct 
binder_proc *proc,
}
 }
 
-static void binder_wakeup_proc_ilocked(struct binder_proc *proc, bool sync)
+/**
+ * binder_select_thread_ilocked() - selects a thread for doing proc work.
+ * @proc:  process to select a thread from
+ *
+ * Note that calling this function moves the thread off the waiting_threads
+ * list, so it can only be woken up by the caller of this function, or a
+ * signal. Therefore, callers *should* always wake up the thread this function
+ * returns.
+ *
+ * Return: If there's a thread currently waiting for process work,
+ * returns that thread. Otherwise returns NULL.
+ */
+static struct binder_thread *
+binder_select_thread_ilocked(struct binder_proc *proc)
 {
struct binder_thread *thread;
 
@@ -979,8 +992,35 @@ static void binder_wakeup_proc_ilocked(struct binder_proc 
*proc, bool sync)
  struct binder_thread,
  waiting_thread_node);
 
-   if (thread) {
+   if (thread)
list_del_init(>waiting_thread_node);
+
+   return thread;
+}
+
+/**
+ * binder_wakeup_thread_ilocked() - wakes up a thread for doing proc work.
+ * @proc:  process to wake up a thread in
+ * @thread:specific thread to wake-up (may be NULL)
+ * @sync:  whether to do a synchronous wake-up
+ *
+ * This function wakes up a thread in the @proc process.
+ * The caller may provide a specific thread to wake-up in
+ * the @thread parameter. If @thread is NULL, this function
+ * will wake up threads that have called poll().
+ *
+ * Note that for this function to work as expected, callers
+ * should first call binder_select_thread() to find a thread
+ * to handle the work (if they don't have a thread already),
+ * and pass the result into the @thread parameter.
+ */
+static void binder_wakeup_thread_ilocked(struct binder_proc *proc,
+struct binder_thread *thread,
+bool sync)
+{
+   BUG_ON(!spin_is_locked(>inner_lock));
+
+   if (thread) {
if (sync)
wake_up_interruptible_sync(>wait);
else
@@ -1004,6 +1044,13 @@ static void binder_wakeup_proc_ilocked(struct 
binder_proc *proc, bool sync)
binder_wakeup_poll_threads_ilocked(proc, sync);
 }
 
+static void binder_wakeup_proc_ilocked(struct binder_proc *proc)
+{
+   struct binder_thread *thread = binder_select_thread_ilocked(proc);
+
+   binder_wakeup_thread_ilocked(proc, thread, /* sync = */false);
+}
+
 static void binder_set_nice(long nice)
 {
long min_nice;
@@ -1222,7 +1269,7 @@ static bool binder_dec_node_nilocked(struct binder_node 
*node,
if (proc && (node->has_strong_ref || node->has_weak_ref)) {
if (list_empty(>work.entry)) {
binder_enqueue_work_ilocked(>work, >todo);
-   binder_wakeup_proc_ilocked(proc, false);
+   binder_wakeup_proc_ilocked(proc);
}
} else {
if (hlist_empty(>refs) && !node->local_strong_refs &&
@@ -2468,6 +2515,73 @@ static int binder_fixup_parent(struct binder_transaction 
*t,
return 0;
 }
 
+/**
+ * binder_proc_transaction() - sends a transaction to a process and wakes it up
+ * @t: transaction to send
+ * @proc:  process to send the transaction to
+ * @thread:thread in @proc to send the transaction to (may be NULL)
+ *
+ * This function queues a transaction to the specified process. It will try
+ * to find a thread in the target process to handle the transaction and
+ * wake it up. If no thread is found, the work is queued to the proc
+ * waitqueue.
+ *
+ * If the @thread parameter is not NULL, the transaction is always queued
+ * to the waitlist of that specific thread.
+ *
+ * Return: true if the transactions was successfully queued
+ * false if the target process or thread is dead
+ */
+static bool binder_proc_transaction(struct binder_transaction *t,
+   struct binder_proc *proc,
+   struct binder_thread *thread)
+{
+   

[RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

[Yisheng Xie]

From: Jean-Philippe Brucker 

Platform device can realise SVM function by using the stall mode. That
is to say, when device access a memory via iova which is not populated,
it will stalled and when SMMU try to translate this iova, it also will
stall and meanwhile send an event to CPU via MSI.

After SMMU driver handle the event and populated the iova, it will send
a RESUME command to SMMU to exit the stall mode, therefore the platform
device can contiue access the memory.

Signed-off-by: Jean-Philippe Brucker 
---
 drivers/iommu/arm-smmu-v3.c | 218 
 1 file changed, 181 insertions(+), 37 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index cafbeef..d44256a 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -359,6 +359,7 @@
 #define CTXDESC_CD_0_TCR_HA_SHIFT  43
 #define CTXDESC_CD_0_HD(1UL << 
CTXDESC_CD_0_TCR_HD_SHIFT)
 #define CTXDESC_CD_0_HA(1UL << 
CTXDESC_CD_0_TCR_HA_SHIFT)
+#define CTXDESC_CD_0_S (1UL << 44)
 #define CTXDESC_CD_0_R (1UL << 45)
 #define CTXDESC_CD_0_A (1UL << 46)
 #define CTXDESC_CD_0_ASET_SHIFT47
@@ -432,6 +433,15 @@
 #define CMDQ_PRI_1_RESP_FAIL   (1UL << CMDQ_PRI_1_RESP_SHIFT)
 #define CMDQ_PRI_1_RESP_SUCC   (2UL << CMDQ_PRI_1_RESP_SHIFT)
 
+#define CMDQ_RESUME_0_SID_SHIFT32
+#define CMDQ_RESUME_0_SID_MASK 0xUL
+#define CMDQ_RESUME_0_ACTION_SHIFT 12
+#define CMDQ_RESUME_0_ACTION_TERM  (0UL << CMDQ_RESUME_0_ACTION_SHIFT)
+#define CMDQ_RESUME_0_ACTION_RETRY (1UL << CMDQ_RESUME_0_ACTION_SHIFT)
+#define CMDQ_RESUME_0_ACTION_ABORT (2UL << CMDQ_RESUME_0_ACTION_SHIFT)
+#define CMDQ_RESUME_1_STAG_SHIFT   0
+#define CMDQ_RESUME_1_STAG_MASK0xUL
+
 #define CMDQ_SYNC_0_CS_SHIFT   12
 #define CMDQ_SYNC_0_CS_NONE(0UL << CMDQ_SYNC_0_CS_SHIFT)
 #define CMDQ_SYNC_0_CS_SEV (2UL << CMDQ_SYNC_0_CS_SHIFT)
@@ -443,6 +453,31 @@
 #define EVTQ_0_ID_SHIFT0
 #define EVTQ_0_ID_MASK 0xffUL
 
+#define EVT_ID_TRANSLATION_FAULT   0x10
+#define EVT_ID_ADDR_SIZE_FAULT 0x11
+#define EVT_ID_ACCESS_FAULT0x12
+#define EVT_ID_PERMISSION_FAULT0x13
+
+#define EVTQ_0_SSV (1UL << 11)
+#define EVTQ_0_SSID_SHIFT  12
+#define EVTQ_0_SSID_MASK   0xfUL
+#define EVTQ_0_SID_SHIFT   32
+#define EVTQ_0_SID_MASK0xUL
+#define EVTQ_1_STAG_SHIFT  0
+#define EVTQ_1_STAG_MASK   0xUL
+#define EVTQ_1_STALL   (1UL << 31)
+#define EVTQ_1_PRIV(1UL << 33)
+#define EVTQ_1_EXEC(1UL << 34)
+#define EVTQ_1_READ(1UL << 35)
+#define EVTQ_1_S2  (1UL << 39)
+#define EVTQ_1_CLASS_SHIFT 40
+#define EVTQ_1_CLASS_MASK  0x3UL
+#define EVTQ_1_TT_READ (1UL << 44)
+#define EVTQ_2_ADDR_SHIFT  0
+#define EVTQ_2_ADDR_MASK   0xUL
+#define EVTQ_3_IPA_SHIFT   12
+#define EVTQ_3_IPA_MASK0xffUL
+
 /* PRI queue */
 #define PRIQ_ENT_DWORDS2
 #define PRIQ_MAX_SZ_SHIFT  8
@@ -586,6 +621,13 @@ struct arm_smmu_cmdq_ent {
enum fault_status   resp;
} pri;
 
+   #define CMDQ_OP_RESUME  0x44
+   struct {
+   u32 sid;
+   u16 stag;
+   enum fault_status   resp;
+   } resume;
+
#define CMDQ_OP_CMD_SYNC0x46
};
 };
@@ -659,6 +701,7 @@ struct arm_smmu_s1_cfg {
 
struct list_headcontexts;
size_t  num_contexts;
+   boolcan_stall;
 
struct arm_smmu_ctx_desccd; /* Default context (SSID0) */
 };
@@ -682,6 +725,7 @@ struct arm_smmu_strtab_ent {
struct arm_smmu_s2_cfg  *s2_cfg;
 
boolprg_response_needs_ssid;
+   boolcan_stall;
 };
 
 struct arm_smmu_strtab_cfg {
@@ -816,6 +860,7 @@ struct arm_smmu_fault {
boolpriv;
 
boollast;
+   boolstall;
 
struct work_struct  work;
 };
@@ -1098,6 +1143,21 @@ static int arm_smmu_cmdq_build_cmd(u64 *cmd, struct 
arm_smmu_cmdq_ent *ent)
return -EINVAL;
}
break;
+   case CMDQ_OP_RESUME:
+   switch 

[RFC PATCH 5/6] iommu/arm-smmu-v3: fix panic when handle stall mode irq

[Yisheng Xie]

When SMMU do not support SVM feature, however the master support SVM,
which means matser can stall and with mult-pasid number, then the user
can bind a task to device using API like iommu_bind_task(). however,
when device trigger a stall mode fault i will cause panic:

[  106.996087] Unable to handle kernel NULL pointer dereference at virtual 
address 0100
[  106.996122] user pgtable: 4k pages, 48-bit VAs, pgd = 80003e023000
[  106.996150] [0100] *pgd=3e04a003, *pud=3e04b003, 
*pmd=
[  106.996201] Internal error: Oops: 9606 [#1] PREEMPT SM
[  106.996224] Modules linked in:
[  106.996256] CPU: 0 PID: 916 Comm: irq/14-arm-smmu Not tainted 
4.13.0-rc5-00035-g1235ddd-dirty #67
[  106.996288] Hardware name: Hisilicon PhosphorHi1383 ESL (DT)
[  106.996317] task: 80003adc1c00 task.stack: 80003a9f8000
[  106.996347] PC is at __queue_work+0x30/0x3a8
[  106.996374] LR is at queue_work_on+0x60/0x78
[  106.996401] pc : [] lr : [] pstate: 
40c001c9
[  106.996430] sp : 80003a9fbc20
[  106.996451] x29: 80003a9fbc20 x28: 80003adc1c00
[  106.996488] x27: 08d05080 x26: 80003ab0e028
[  106.996526] x25: 80003a9900ac x24: 0001
[  106.996562] x23: 0040 x22: 
[  106.996598] x21:  x20: 0140
[  106.996634] x19: 80003ab0e028 x18: 0010
[  106.996670] x17: a52a5040 x16: 0820f260
[  106.996708] x15: 0018e97629e0 x14: 80003fb89468
[  106.996744] x13:  x12: 80003abb0600
[  106.996781] x11:  x10: 01010100
[  106.996817] x9 : 85de5010 x8 : e4830001
[  106.996854] x7 : 80003a9fbcf8 x6 : 000fffe0
[  106.996890] x5 :  x4 : 0001
[  106.996926] x3 :  x2 : 80003ab0e028
[  106.996962] x1 :  x0 : 01c0
[  106.997002] Process irq/14-arm-smmu (pid: 916, stack limit 
=0x80003a9f8000)
[  106.997035] Stack: (0x80003a9fbc20 to 0x80003a9fc000)
[...]
[  106.998366] Call trace:
[  106.998842] [] __queue_work+0x30/0x3a8
[  106.998874] [] queue_work_on+0x60/0x78
[  106.998912] [] arm_smmu_handle_stall+0x104/0x138
[  106.998952] [] arm_smmu_evtq_thread+0xc0/0x158
[  106.998989] [] irq_thread_fn+0x28/0x68
[  106.999025] [] irq_thread+0x128/0x1d0
[  106.999060] [] kthread+0xfc/0x128
[  106.999093] [] ret_from_fork+0x10/0x50
[  106.999130] Code: a90153f3 a90573fb d53b4220 363814c0 (b94102a0)
[  106.999159] ---[ end trace 7e5c9f0cb1f2fecd ]---

And the resean is we donot init fault_queue while the fault handle need
to use it. Fix by return -EINVAL in arm_smmu_bind_task() when smmu do not
support the feature of SVM.

Signed-off-by: Yisheng Xie 
---
 drivers/iommu/arm-smmu-v3.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index d44256a..dbda2eb 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2922,6 +2922,8 @@ static int arm_smmu_bind_task(struct device *dev, struct 
task_struct *task,
return -EINVAL;
 
smmu = master->smmu;
+   if (!(smmu->features & ARM_SMMU_FEAT_SVM))
+   return -EINVAL;
 
domain = iommu_get_domain_for_dev(dev);
if (WARN_ON(!domain))
-- 
1.7.12.4

[RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

[Yisheng Xie]

Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:
https://www.spinics.net/lists/arm-kernel/msg565155.html

But for some platform devices(aka on-chip integrated devices), there is also
SVM requirement, which works based on the SMMU stall mode.
Jean-Philippe has prepared a prototype patchset to support it:
git://linux-arm.org/linux-jpb.git svm/stall

We tested this patchset with some fixes on a on-chip integrated device. The
basic function is ok, so I just send them out for review, although this
patchset heavily depends on the former patchset (PCIe SVM support for ARM
SMMUv3), which is still under discussion.

Patch Overview:
*1 to 3 prepare for device tree or acpi get the device stall ability and pasid 
bits
*4 is to realise the SVM function for platform device
*5 is fix a bug when test SVM function while SMMU donnot support this feature
*6 avoid ILLEGAL setting of STE and CD entry about stall

Acctually here, I also have a question about SVM on SMMUv3:

1. Why the SVM feature on SMMUv3 depends on BTM feature? when bind a task to 
device,
   it will register a mmu_notify. Therefore, when a page range is invalid, we 
can
   send TLBI or ATC invalid without BTM?

2. According to ACPI IORT spec, named component specific data has a node flags 
field
   whoes bit0 is for Stall support. However, it do not have any field for pasid 
bit.
   Can we use other 5 bits[5:1] for pasid bit numbers, so we can have 32 pasid 
bit for
   a single platform device which should be enough, because SMMU only support 
20 bit pasid

3. Presently, the pasid is allocate for a task but not for a context, if a task 
is trying
   to bind to 2 device A and B:
 a) A support 5 pasid bits
 b) B support 2 pasid bits
 c) when the task bind to device A, it allocate pasid = 16
 d) then it must be fail when trying to bind to task B, for its highest 
pasid is 4.
   So it should allocate a single pasid for a context to avoid this?


Jean-Philippe Brucker (3):
  dt-bindings: document stall and PASID properties for IOMMU masters
  iommu/of: Add stall and pasid properties to iommu_fwspec
  iommu/arm-smmu-v3: Add SVM support for platform devices

Yisheng Xie (3):
  ACPI: IORT: Add stall and pasid properties to iommu_fwspec
  iommu/arm-smmu-v3: fix panic when handle stall mode irq
  iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

 Documentation/devicetree/bindings/iommu/iommu.txt |  13 ++
 drivers/acpi/arm64/iort.c |  20 ++
 drivers/iommu/arm-smmu-v3.c   | 230 ++
 drivers/iommu/of_iommu.c  |  11 +
 include/acpi/actbl2.h |   5 +
 include/linux/iommu.h |   2 +
 6 files changed, 244 insertions(+), 37 deletions(-)

--
1.7.12.4

[RFC PATCH 1/6] dt-bindings: document stall and PASID properties for IOMMU masters

[Yisheng Xie]

From: Jean-Philippe Brucker 

Document the bindings for stall and PASID capable platform devices.

Signed-off-by: Jean-Philippe Brucker 
---
 Documentation/devicetree/bindings/iommu/iommu.txt | 13 +
 1 file changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt 
b/Documentation/devicetree/bindings/iommu/iommu.txt
index 5a8b462..7355d7f 100644
--- a/Documentation/devicetree/bindings/iommu/iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -86,6 +86,19 @@ have a means to turn off translation. But it is invalid in 
such cases to
 disable the IOMMU's device tree node in the first place because it would
 prevent any driver from properly setting up the translations.
 
+Optional properties:
+
+- dma-can-stall: When present, the master can wait for a DMA transaction
+  to be handled by the IOMMU and can recover from a fault. For example, if
+  the page accessed by the DMA transaction isn't mapped, some IOMMUs are
+  able to stall the transaction and let the OS populate the page tables.
+  The IOMMU then performs the transaction if the fault was successfully
+  handled, or aborts the transaction otherwise.
+
+- pasid-bits: Some masters support multiple address spaces for DMA. By
+  tagging DMA transactions with an address space identifier. By default,
+  this is 0, which means that the device only has one address space.
+
 
 Notes:
 ==
-- 
1.7.12.4

[RFC PATCH 6/6] iommu/arm-smmu-v3: Avoid ILLEGAL setting of STE.S1STALLD and CD.S

[Yisheng Xie]

It is ILLEGAL to set STE.S1STALLD if STALL_MODEL is not 0b00, which
means we should not disable stall mode if stall/terminate mode is not
configuable.

Meanwhile, it is also ILLEGAL when STALL_MODEL==0b10 && CD.S==0 which
means if stall mode is force we should always set CD.S.

This patch add ARM_SMMU_FEAT_TERMINATE feature bit for smmu, and use
TERMINATE feature checking to ensue above ILLEGAL cases from happening.

Signed-off-by: Yisheng Xie 
---
 drivers/iommu/arm-smmu-v3.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index dbda2eb..0745522 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -55,6 +55,7 @@
 #define IDR0_STALL_MODEL_SHIFT 24
 #define IDR0_STALL_MODEL_MASK  0x3
 #define IDR0_STALL_MODEL_STALL (0 << IDR0_STALL_MODEL_SHIFT)
+#define IDR0_STALL_MODEL_NS(1 << IDR0_STALL_MODEL_SHIFT)
 #define IDR0_STALL_MODEL_FORCE (2 << IDR0_STALL_MODEL_SHIFT)
 #define IDR0_TTENDIAN_SHIFT21
 #define IDR0_TTENDIAN_MASK 0x3
@@ -766,6 +767,7 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_SVM  (1 << 15)
 #define ARM_SMMU_FEAT_HA   (1 << 16)
 #define ARM_SMMU_FEAT_HD   (1 << 17)
+#define ARM_SMMU_FEAT_TERMINATE(1 << 18)
u32 features;
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH (1 << 0)
@@ -1402,6 +1404,7 @@ static void arm_smmu_write_ctx_desc(struct 
arm_smmu_domain *smmu_domain,
u64 val;
bool cd_live;
__u64 *cdptr = arm_smmu_get_cd_ptr(smmu_domain, ssid);
+   struct arm_smmu_device *smmu = smmu_domain->smmu;
 
/*
 * This function handles the following cases:
@@ -1468,9 +1471,11 @@ static void arm_smmu_write_ctx_desc(struct 
arm_smmu_domain *smmu_domain,
  CTXDESC_CD_0_V;
 
/*
-* FIXME: STALL_MODEL==0b10 && CD.S==0 is ILLEGAL
+* STALL_MODEL==0b10 && CD.S==0 is ILLEGAL
 */
-   if (ssid && smmu_domain->s1_cfg.can_stall)
+   if ((ssid && smmu_domain->s1_cfg.can_stall) ||
+   (!(smmu->features & ARM_SMMU_FEAT_TERMINATE) &&
+   smmu->features & ARM_SMMU_FEAT_STALLS))
val |= CTXDESC_CD_0_S;
 
cdptr[0] = cpu_to_le64(val);
@@ -1690,12 +1695,13 @@ static void arm_smmu_write_strtab_ent(struct 
arm_smmu_device *smmu, u32 sid,
dst[1] |= STRTAB_STE_1_PPAR;
 
/*
-* FIXME: it is illegal to set S1STALLD if STALL_MODEL=0b10
-* (force). But according to the spec, it *must* be set for
+* According to spec, it is illegal to set S1STALLD if
+* STALL_MODEL is not 0b00. And it *must* be set for
 * devices that aren't capable of stalling (notably pci!)
-* So we need a "STALL_MODEL=0b00" feature bit.
 */
-   if (smmu->features & ARM_SMMU_FEAT_STALLS && !ste->can_stall)
+   if (smmu->features & ARM_SMMU_FEAT_STALLS &&
+   smmu->features & ARM_SMMU_FEAT_TERMINATE &&
+   !ste->can_stall)
dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
 
val |= (s1ctxptr & STRTAB_STE_0_S1CTXPTR_MASK
@@ -4577,9 +4583,13 @@ static int arm_smmu_device_hw_probe(struct 
arm_smmu_device *smmu)
 
switch (reg & IDR0_STALL_MODEL_MASK << IDR0_STALL_MODEL_SHIFT) {
case IDR0_STALL_MODEL_STALL:
+   smmu->features |= ARM_SMMU_FEAT_TERMINATE;
/* Fallthrough */
case IDR0_STALL_MODEL_FORCE:
smmu->features |= ARM_SMMU_FEAT_STALLS;
+   break;
+   case IDR0_STALL_MODEL_NS:
+   smmu->features |= ARM_SMMU_FEAT_TERMINATE;
}
 
if (reg & IDR0_S1P)
-- 
1.7.12.4

Re: [PATCH V2] spmi: pmic-arb: Enforce the ownership check optionally

[Shawn Guo]

On Wed, Aug 30, 2017 at 02:02:03PM -0700, Stephen Boyd wrote:
> On 08/26, Shawn Guo wrote:
> > On Fri, Aug 25, 2017 at 04:18:18PM -0700, Stephen Boyd wrote:
> > > 
> > > Right. Does the GPIO work? If so, it sounds like the read/write
> > > access checks in spmi pmic arb don't work properly.
> > 
> > The check works.  With the check in there, PM8916 GPIO doesn't work.
> > However, the consequence is that not only user3 but all GPIO leds under
> > 'leds' node will fail to register, because any GPIO led's failing on
> > create_gpio_led() makes leds-gpio driver probe fail as a while.  That's
> > how leds-gpio driver works.
> > 
> > Also, per schematics, PM8916 GPIO1 is indeed routed to user3 LED on
> > db410c board.  Why do you think apq8016-sbc device tree shouldn't use
> > the GPIO for that at all?  Isn't it firmware's fault that the ownership
> > of the peripheral is not properly configured?
> 
> If the ownership was not properly configured in the firmware,
> then I imagine it would mean that we can't control the GPIO for
> the LED. But that doesn't seem to be true. I can see on my board
> that I get impermissible write failures on the GPIO when
> controlling the GPIO brightness, but it doesn't actually matter
> because the led still lights up. So the checks for write/read
> permission seem incorrect, or they're not being enforced.

I'm not sure what is happening on your side.  As I said above, with the
4.13-rc series, leds-gpio driver doesn't probe at all, due to the
impermissible write to PM8916 GPIO in function create_gpio_led(), and
none of the LEDs lights up on my board.

Shawn

RE: [PATCH 3/4] phy: rcar-gen3-usb2: add SoC-specific parameter for dedicated pins

[Yoshihiro Shimoda]

Hi Geert-san,

> From: Geert Uytterhoeven
> Sent: Thursday, August 31, 2017 5:27 PM
> 
> Hi Shimoda-san,
> 
> On Thu, Aug 31, 2017 at 10:15 AM, Yoshihiro Shimoda
>  wrote:
> >> From: Geert Uytterhoeven
> >> Sent: Thursday, August 31, 2017 4:51 PM
> >> On Thu, Aug 31, 2017 at 9:31 AM, Yoshihiro Shimoda
> >>  wrote:
< snip >
> >> Given the generic R-Car Gen3 entry sets RCAR_GEN3_PHY_HAS_DEDICATED_PINS, 
> >> you
> >> cannot specify the fallback compatible value of 
> >> "renesas,rcar-gen3-usb2-phy"
> >> in the R-Car D3 .dtsi.
> >
> > I understood it.
> >
> >> So I'm wondering, does the USB2 PHY still work (with limitations) on R-Car 
> >> H3
> >> and M3-W if you drop RCAR_GEN3_PHY_HAS_DEDICATED_PINS?
> >
> > Yes, the USB PHY still work with limitation (otg capability channel works as
> > peripheral mode only. Other channels are no limitation).
> 
> That's good to hear.
> 
> >> If yes, you can drop the flag from the generic entry, and R-Car D3 can 
> >> specify
> >> the generic fallback compatible value in its .dtsi, like H3 and M3-W.
> >
> > I got it. I will fix this patch set.
> 
> And you can drop the driver change from "[PATCH 4/4] phy: rcar-gen3-usb2: add
> binding for r8a77995", as it will match against the generic fallback on D3.

I got it. I will submit v2 patches soon.

Best regards,
Yoshihiro Shimoda

> Thanks.
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

Re: [PATCH] RM64: dts: ls208xa: Add iommu-map property for pci

[Marc Zyngier]

On 31/08/17 10:23, Bharat Bhushan wrote:
> This patch adds iommu-map property for PCIe, which enables
> SMMU for these devices on LS208xA devices.
> 
> Signed-off-by: Bharat Bhushan 
> ---
>  arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> index 94cdd30..67cf605 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
> @@ -606,6 +606,7 @@
>   num-lanes = <4>;
>   bus-range = <0x0 0xff>;
>   msi-parent = <>;
> + iommu-map = <0  0 1>;  /* This is fixed-up by 
> u-boot */

What does this do when your version of u-boot doesn't fill this in for you?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 1/2] pinctrl: msm: GP clock for pinctrl-apq8064 binding

[Linus Walleij]

On Fri, Aug 11, 2017 at 8:55 AM, Vinay Simha BN  wrote:

> DT binding documentation for qcom,apq8064-pinctrl driver
> for general purpose (GP) clocks.
>
> Signed-off-by: Vinay Simha BN 

Patch applied with Rob's ACK.
I don't think Björn will mind.

Yours,
Linus Walleij

Re: [PATCH 1/4] phy: rcar-gen3-usb2: check dr_mode for otg mode

[Sergei Shtylyov]

Hello!

On 8/31/2017 10:31 AM, Yoshihiro Shimoda wrote:


The previous code assumed a channel has otg capability if a channel
has interrupt property. But, it is not good because:
  - Battery charging feature also needs interrupt property.
  - Some R-Car Gen3 SoCs (e.g. R-Car D3) doesn't have OTG capability.


   Don't.


So, this patch checks whether usb 2.0 host node has dr_mode property or
not. If it has 'dr_mode = "otg";', this driver enables otg capability.

Signed-off-by: Yoshihiro Shimoda 

[...]

MBR, Sergei

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

[Leizhen (ThunderTown)]

On 2017/8/4 3:41, Nate Watterson wrote:
> Hi Robin,
> 
> On 7/31/2017 7:42 AM, Robin Murphy wrote:
>> Hi Nate,
>>
>> On 29/07/17 04:57, Nate Watterson wrote:
>>> Hi Robin,
>>> I am seeing a crash when performing very basic testing on this series
>>> with a Mellanox CX4 NIC. I dug into the crash a bit, and think this
>>> patch is the culprit, but this rcache business is still mostly
>>> witchcraft to me.
>>>
>>> # ifconfig eth5 up
>>> # ifconfig eth5 down
>>>  Unable to handle kernel NULL pointer dereference at virtual address
>>> 0020
>>>  user pgtable: 64k pages, 48-bit VAs, pgd = 8007dbf47c00
>>>  [0020] *pgd=0006efab0003, *pud=0006efab0003,
>>> *pmd=0007d8720003, *pte=
>>>  Internal error: Oops: 9607 [#1] SMP
>>>  Modules linked in:
>>>  CPU: 47 PID: 5082 Comm: ifconfig Not tainted 4.13.0-rtp-enablement+ #3
>>>  task: 8007da1e5780 task.stack: 8007ddcb8000
>>>  PC is at __cached_rbnode_delete_update+0x2c/0x58
>>>  LR is at private_free_iova+0x2c/0x60
>>>  pc : [] lr : [] pstate: 204001c5
>>>  sp : 8007ddcbba00
>>>  x29: 8007ddcbba00 x28: 8007c8350210
>>>  x27: 8007d1a8 x26: 8007dcc20800
>>>  x25: 0140 x24: 8007c98f0008
>>>  x23: fe4e x22: 0140
>>>  x21: 8007c98f0008 x20: 8007c9adb240
>>>  x19: 8007c98f0018 x18: 0010
>>>  x17:  x16: 
>>>  x15: 4000 x14: 
>>>  x13:  x12: 0001
>>>  x11: dead0200 x10: 
>>>  x9 :  x8 : 8007c9adb1c0
>>>  x7 : 40002000 x6 : 00210d00
>>>  x5 :  x4 : c57e
>>>  x3 : ffcf x2 : ffcf
>>>  x1 : 8007c9adb240 x0 : 
>>>  [...]
>>>  [] __cached_rbnode_delete_update+0x2c/0x58
>>>  [] private_free_iova+0x2c/0x60
>>>  [] iova_magazine_free_pfns+0x4c/0xa0
>>>  [] free_iova_fast+0x1b0/0x230
>>>  [] iommu_dma_free_iova+0x5c/0x80
>>>  [] __iommu_dma_unmap+0x5c/0x98
>>>  [] iommu_dma_unmap_resource+0x24/0x30
>>>  [] iommu_dma_unmap_page+0xc/0x18
>>>  [] __iommu_unmap_page+0x40/0x60
>>>  [] mlx5e_page_release+0xbc/0x128
>>>  [] mlx5e_dealloc_rx_wqe+0x30/0x40
>>>  [] mlx5e_close_channel+0x70/0x1f8
>>>  [] mlx5e_close_channels+0x2c/0x50
>>>  [] mlx5e_close_locked+0x54/0x68
>>>  [] mlx5e_close+0x30/0x58
>>>  [...]
>>>
>>> ** Disassembly for __cached_rbnode_delete_update() near the fault **
>>>92|if (free->pfn_hi < iovad->dma_32bit_pfn)
>>> 0852C6C4|ldr x3,[x1,#0x18]; x3,[free,#24]
>>> 0852C6C8|ldr x2,[x0,#0x30]; x2,[iovad,#48]
>>> 0852C6CC|cmp x3,x2
>>> 0852C6D0|b.cs0x0852C708
>>>  |curr = >cached32_node;
>>>94|if (!curr)
>>> 0852C6D4|addsx19,x0,#0x18 ; x19,iovad,#24
>>> 0852C6D8|b.eq0x0852C708
>>>  |
>>>  |cached_iova = rb_entry(*curr, struct iova, node);
>>>  |
>>>99|if (free->pfn_lo >= cached_iova->pfn_lo)
>>> 0852C6DC|ldr x0,[x19] ; xiovad,[curr]
>>> 0852C6E0|ldr x2,[x1,#0x20]; x2,[free,#32]
>>> 0852C6E4|ldr x0,[x0,#0x20]; x0,[x0,#32]
>>> Apparently cached_iova was NULL so the pfn_lo access faulted.
>>>
>>> 0852C6E8|cmp x2,x0
>>> 0852C6EC|b.cc0x0852C6FC
>>> 0852C6F0|mov x0,x1; x0,free
>>>   100|*curr = rb_next(>node);
>>> After instrumenting the code a bit, this seems to be the culprit. In the
>>> previous call, free->pfn_lo was 0x_ which is actually the
>>> dma_limit for the domain so rb_next() returns NULL.
>>>
>>> Let me know if you have any questions or would like additional tests
>>> run. I also applied your "DMA domain debug info" patches and dumped the
>>> contents of the domain at each of the steps above in case that would be
>>> useful. If nothing else, they reinforce how thirsty the CX4 NIC is
>>> especially when using 64k pages and many CPUs.
>>
>> Thanks for the report - I somehow managed to reason myself out of
>> keeping the "no cached node" check in __cached_rbnode_delete_update() on
>> the assumption that it must always be set by a previous allocation.
>> However, there is indeed just one case case for which that fails: when
>> you free any IOVA immediately after freeing the very topmost one. Which
>> is something that freeing an entire magazine's worth of IOVAs back to
>> the tree all at once has a very real chance of doing...
>>
>> The obvious 

[PATCH] staging: vboxvideo: constify drm_fb_helper_funcs

[Arvind Yadav]

drm_fb_helper_funcs are not supposed to change at runtime.
All functions working with drm_fb_helper_funcs provided by
 work with const drm_fb_helper_funcs.
So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/staging/vboxvideo/vbox_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vboxvideo/vbox_fb.c 
b/drivers/staging/vboxvideo/vbox_fb.c
index 35f6d9f..70d99b7 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -330,7 +330,7 @@ static void vbox_fb_gamma_get(struct drm_crtc *crtc, u16 
*red, u16 *green,
*blue = regno;
 }
 
-static struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
+static const struct drm_fb_helper_funcs vbox_fb_helper_funcs = {
.gamma_set = vbox_fb_gamma_set,
.gamma_get = vbox_fb_gamma_get,
.fb_probe = vboxfb_create,
-- 
1.9.1

[tip:x86/mm] x86/mm: Use pr_cont() in dump_pagetable()

[tip-bot for Jan Beulich]

Commit-ID:  39e48d9b128abbd2ea9b8403bb1e2693323db2f4
Gitweb: http://git.kernel.org/tip/39e48d9b128abbd2ea9b8403bb1e2693323db2f4
Author: Jan Beulich 
AuthorDate: Thu, 31 Aug 2017 01:30:19 -0600
Committer:  Ingo Molnar 
CommitDate: Thu, 31 Aug 2017 11:01:58 +0200

x86/mm: Use pr_cont() in dump_pagetable()

The lack of newlines in preceding format strings is a clear indication
that these were meant to be continuations of one another, and indeed
output ends up quite a bit more compact (and readable) that way.

Switch other plain printk()-s in the function instances to pr_info(),
as requested.

Signed-off-by: Jan Beulich 
Acked-by: Thomas Gleixner 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/59a7d72b027800175...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/mm/fault.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 2a1fa10c..0cdf14c 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -396,14 +396,18 @@ static void dump_pagetable(unsigned long address)
pte_t *pte;
 
 #ifdef CONFIG_X86_PAE
-   printk("*pdpt = %016Lx ", pgd_val(*pgd));
+   pr_info("*pdpt = %016Lx ", pgd_val(*pgd));
if (!low_pfn(pgd_val(*pgd) >> PAGE_SHIFT) || !pgd_present(*pgd))
goto out;
+#define pr_pde pr_cont
+#else
+#define pr_pde pr_info
 #endif
p4d = p4d_offset(pgd, address);
pud = pud_offset(p4d, address);
pmd = pmd_offset(pud, address);
-   printk(KERN_CONT "*pde = %0*Lx ", sizeof(*pmd) * 2, (u64)pmd_val(*pmd));
+   pr_pde("*pde = %0*Lx ", sizeof(*pmd) * 2, (u64)pmd_val(*pmd));
+#undef pr_pde
 
/*
 * We must not directly access the pte in the highpte
@@ -415,9 +419,9 @@ static void dump_pagetable(unsigned long address)
goto out;
 
pte = pte_offset_kernel(pmd, address);
-   printk("*pte = %0*Lx ", sizeof(*pte) * 2, (u64)pte_val(*pte));
+   pr_cont("*pte = %0*Lx ", sizeof(*pte) * 2, (u64)pte_val(*pte));
 out:
-   printk("\n");
+   pr_cont("\n");
 }
 
 #else /* CONFIG_X86_64: */
@@ -565,7 +569,7 @@ static void dump_pagetable(unsigned long address)
if (bad_address(pgd))
goto bad;
 
-   printk("PGD %lx ", pgd_val(*pgd));
+   pr_info("PGD %lx ", pgd_val(*pgd));
 
if (!pgd_present(*pgd))
goto out;
@@ -574,7 +578,7 @@ static void dump_pagetable(unsigned long address)
if (bad_address(p4d))
goto bad;
 
-   printk("P4D %lx ", p4d_val(*p4d));
+   pr_cont("P4D %lx ", p4d_val(*p4d));
if (!p4d_present(*p4d) || p4d_large(*p4d))
goto out;
 
@@ -582,7 +586,7 @@ static void dump_pagetable(unsigned long address)
if (bad_address(pud))
goto bad;
 
-   printk("PUD %lx ", pud_val(*pud));
+   pr_cont("PUD %lx ", pud_val(*pud));
if (!pud_present(*pud) || pud_large(*pud))
goto out;
 
@@ -590,7 +594,7 @@ static void dump_pagetable(unsigned long address)
if (bad_address(pmd))
goto bad;
 
-   printk("PMD %lx ", pmd_val(*pmd));
+   pr_cont("PMD %lx ", pmd_val(*pmd));
if (!pmd_present(*pmd) || pmd_large(*pmd))
goto out;
 
@@ -598,12 +602,12 @@ static void dump_pagetable(unsigned long address)
if (bad_address(pte))
goto bad;
 
-   printk("PTE %lx", pte_val(*pte));
+   pr_cont("PTE %lx", pte_val(*pte));
 out:
-   printk("\n");
+   pr_cont("\n");
return;
 bad:
-   printk("BAD\n");
+   pr_info("BAD\n");
 }
 
 #endif /* CONFIG_X86_64 */

[tip:x86/apic] x86/apic: Silence "FW_BUG TSC_DEADLINE disabled due to Errata" on CPUs without the feature

[tip-bot for Hans de Goede]

Commit-ID:  594a30fb12424717a41c62323d2a8bf167dbccad
Gitweb: http://git.kernel.org/tip/594a30fb12424717a41c62323d2a8bf167dbccad
Author: Hans de Goede 
AuthorDate: Wed, 30 Aug 2017 12:58:11 +0200
Committer:  Ingo Molnar 
CommitDate: Thu, 31 Aug 2017 11:17:27 +0200

x86/apic: Silence "FW_BUG TSC_DEADLINE disabled due to Errata" on CPUs without 
the feature

When booting 4.13 on a VirtualBox VM on a Skylake host the following
error shows up in the logs:

 [0.00] [Firmware Bug]: TSC_DEADLINE disabled due to Errata;
please update microcode to version: 0xb2 (or later)

This is caused by apic_check_deadline_errata() only checking CPU model
and not the X86_FEATURE_TSC_DEADLINE_TIMER flag (which VirtualBox does
NOT export to the guest), combined with VirtualBox not exporting the
micro-code version to the guest.

This commit adds a check for X86_FEATURE_TSC_DEADLINE_TIMER to
apic_check_deadline_errata(), silencing this error on VirtualBox VMs.

Signed-off-by: Hans de Goede 
Acked-by: Thomas Gleixner 
Cc: Frank Mehnert 
Cc: Linus Torvalds 
Cc: Michael Thayer 
Cc: Michal Necasek 
Cc: Peter Zijlstra 
Fixes: bd9240a18e ("x86/apic: Add TSC_DEADLINE quirk due to errata")
Link: http://lkml.kernel.org/r/20170830105811.27539-1-hdego...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/apic/apic.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index eebee4c..7834f73 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -597,9 +597,13 @@ static const struct x86_cpu_id deadline_match[] = {
 
 static void apic_check_deadline_errata(void)
 {
-   const struct x86_cpu_id *m = x86_match_cpu(deadline_match);
+   const struct x86_cpu_id *m;
u32 rev;
 
+   if (!boot_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER))
+   return;
+
+   m = x86_match_cpu(deadline_match);
if (!m)
return;
 

[PATCH] 9p: constify xattr_handler

[Arvind Yadav]

xattr_handler are not supposed to change at runtime.
"struct super_block" working with xattr_handler provided
by  work with const xattr_handler. So mark
the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 fs/9p/xattr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/9p/xattr.c b/fs/9p/xattr.c
index f329eee..3d45d25 100644
--- a/fs/9p/xattr.c
+++ b/fs/9p/xattr.c
@@ -154,20 +154,20 @@ static int v9fs_xattr_handler_set(const struct 
xattr_handler *handler,
return v9fs_xattr_set(dentry, full_name, value, size, flags);
 }
 
-static struct xattr_handler v9fs_xattr_user_handler = {
+static const struct xattr_handler v9fs_xattr_user_handler = {
.prefix = XATTR_USER_PREFIX,
.get= v9fs_xattr_handler_get,
.set= v9fs_xattr_handler_set,
 };
 
-static struct xattr_handler v9fs_xattr_trusted_handler = {
+static const struct xattr_handler v9fs_xattr_trusted_handler = {
.prefix = XATTR_TRUSTED_PREFIX,
.get= v9fs_xattr_handler_get,
.set= v9fs_xattr_handler_set,
 };
 
 #ifdef CONFIG_9P_FS_SECURITY
-static struct xattr_handler v9fs_xattr_security_handler = {
+static const struct xattr_handler v9fs_xattr_security_handler = {
.prefix = XATTR_SECURITY_PREFIX,
.get= v9fs_xattr_handler_get,
.set= v9fs_xattr_handler_set,
-- 
1.9.1

Re: [PATCH v6 1/3] perf/core: use rb trees for pinned/flexible groups

[Alexey Budankov]

On 30.08.2017 14:16, Alexey Budankov wrote:
> On 30.08.2017 11:30, Alexey Budankov wrote:
>> On 29.08.2017 16:51, Alexander Shishkin wrote:
>>> Alexey Budankov  writes:
>>>
 Now I figured that not all indexed events are always located under 
 the root with the same cpu, and it depends on the order of insertion
 e.g. with insertion order 01,02,03,14,15,16 we get this:

  02
 /  \
01  14
   /  \
  03  15
\
16

 and it is unclear how to iterate cpu==0 part of tree in this case.
>>>
>>> Using this example, rb_next() should take you through the nodes in this
>>> order (assuming you start with 01): 01, 02, 03, 14, etc. So you iterate
>>> while event->cpu==cpu using rb_next() and you should be fine.
>>
>> Well, indeed we get the most left leaf (03) in rb_next() for the case above.
>>
>>>
 Iterating cpu specific subtree like this:

 #define for_each_group_event(event, group, cpu, pmu, field) \
for (event = rb_entry_safe(group_first(group, cpu, pmu), \
   typeof(*event), field);   \
 event && event->cpu == cpu && event->pmu == pmu;\
 event = rb_entry_safe(rb_next(>field),   \
   typeof(*event), field))
>>>
>>> Afaict, this assumes that you are also ordering on event->pmu, which
>>> should be reflected in your _less function. And also assuming that
>>> group_first() is doing the right thing. Can we see the code?
>>
>> I didn't do ordering by PMU for this patch set. Yet more I implemented 
>> groups_first() like this:
>>
>> static struct perf_event *
>> perf_event_groups_first(struct perf_event_groups *groups, int cpu)
>> {
>>  struct perf_event *node_event = NULL;
>>  struct rb_node *node = NULL;
>>
>>  node = groups->tree.rb_node;
>>
>>  while (node) {
>>  node_event = container_of(node,
>>  struct perf_event, group_node);
>>
>>  if (cpu < node_event->cpu) {
>>  node = node->rb_left;
>>  } else if (cpu > node_event->cpu) {
>>  node = node->rb_right;
>>  } else {
>>  node = node->rb_left;
>>  }
>>  }
>>
>>  return node_event;
>> }
>>
>> and it doesn't work as expected for case above with cpu == 1.
>>
>> I corrected the code above to this:
>>
>> static struct perf_event *
>> perf_event_groups_first(struct perf_event_groups *groups, int cpu)
>> {
>>  struct perf_event *node_event = NULL, *match = NULL;
>>  struct rb_node *node = NULL;
>>
>>  node = groups->tree.rb_node;
>>
>>  while (node) {
>>  node_event = container_of(node,
>>  struct perf_event, group_node);
>>
>>  if (cpu < node_event->cpu) {
>>  node = node->rb_left;
>>  } else if (cpu > node_event->cpu) {
>>  node = node->rb_right;
>>  } else {
>>  match = node_event;
>>  node = node->rb_left;
>>  }
>>  }
>>
>>  return match;
>> }
>>
>> but now struggling with silent oopses which I guess are not 
>> related to multiplexing at all.
> 
> Added logging into the code and now see this in dmesg output:
> 
> [  175.743879] BUG: unable to handle kernel paging request at 7fe2a90d1a54
> [  175.743899] IP: __task_pid_nr_ns+0x3b/0x90
> [  175.743903] PGD 2f317ca067 
> [  175.743906] P4D 2f317ca067 
> [  175.743910] PUD 0 
> 
> [  175.743926] Oops:  [#1] SMP
> [  175.743931] Modules linked in: fuse xt_CHECKSUM iptable_mangle 
> ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun 
> bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables nfsv3 
> rpcsec_gss_krb5 nfsv4 cmac arc4 md4 nls_utf8 cifs nfs ccm dns_resolver 
> fscache rpcrdma ib_isert iscsi_target_mod ib_iser libiscsi 
> scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp 
> ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm intel_rapl 
> sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp hfi1 crct10dif_pclmul 
> crc32_pclmul ghash_clmulni_intel intel_cstate rdmavt joydev ipmi_ssif 
> intel_uncore ib_core ipmi_si ipmi_devintf intel_rapl_perf iTCO_wdt 
> iTCO_vendor_support pcspkr tpm_tis tpm_tis_core
> [  175.744088]  mei_me tpm i2c_i801 ipmi_msghandler lpc_ich mei shpchp wmi 
> acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc mgag200 
> drm_kms_helper ttm drm igb crc32c_intel ptp pps_core dca i2c_algo_bit
> [  175.744156] CPU: 12 PID: 8272 Comm: perf Not tainted 4.13.0-rc4-v7.3.3+ #13
> [  175.744160] Hardware name: Intel Corporation S7200AP/S7200AP, BIOS 
> S72C610.86B.01.01.0190.080520162104 08/05/2016
> [  175.744165] task: 

Re: linux-next: manual merge of the xen-tip tree with the tip tree

[Juergen Gross]

On 31/08/17 11:00, Thomas Gleixner wrote:
> On Thu, 31 Aug 2017, Thomas Gleixner wrote:
>> Hrm. For some reason I missed to remove these defines after getting rid of
>> the tracing idt.
>>
>> I'll remove that now in tip and pull in the XEN stuff to see what needs to
>> be done.
> 
> I pushed out the removal of the trace leftovers. Talked to Juergen on IRC
> and he suggested to revert the XEN patch in the xen tree and merge it
> through tip.
> 
> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
> mindlessly. Patch below.
> 
> Juergen, can you please check the result?
> 
> Thanks,
> 
>   tglx
> 
> 8<-
> Subject: xen: Get rid of paravirt op adjust_exception_frame
> From: Juergen Gross 
> Date: Fri, 11 Aug 2017 16:54:48 +0200
> 
> When running as Xen pv-guest the exception frame on the stack contains
> %r11 and %rcx additional to the other data pushed by the processor.
> 
> Instead of having a paravirt op being called for each exception type
> prepend the Xen specific code to each exception entry. When running as
> Xen pv-guest just use the exception entry with prepended instructions,
> otherwise use the entry without the Xen specific code.
> 
> Signed-off-by: Juergen Gross 
> Cc: xen-de...@lists.xenproject.org
> Cc: boris.ostrov...@oracle.com
> Cc: l...@amacapital.net
> Link: http://lkml.kernel.org/r/20170811145448.5679-1-jgr...@suse.com
> 
> ---
>  arch/x86/entry/entry_64.S |   11 +--
>  arch/x86/entry/entry_64_compat.S  |1 
>  arch/x86/include/asm/paravirt.h   |5 -
>  arch/x86/include/asm/paravirt_types.h |4 -
>  arch/x86/include/asm/proto.h  |3 +
>  arch/x86/include/asm/traps.h  |3 -
>  arch/x86/kernel/asm-offsets_64.c  |1 
>  arch/x86/kernel/paravirt.c|3 -
>  arch/x86/xen/enlighten_pv.c   |   96 
> ++
>  arch/x86/xen/irq.c|3 -
>  arch/x86/xen/xen-ops.h|1 
>  11 files changed, 70 insertions(+), 61 deletions(-)
> 
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -816,7 +816,6 @@ ENTRY(\sym)
>   .endif
>  
>   ASM_CLAC
> - PARAVIRT_ADJUST_EXCEPTION_FRAME
>  
>   .ifeq \has_error_code
>   pushq   $-1 /* ORIG_RAX: no syscall to 
> restart */
> @@ -962,7 +961,7 @@ ENTRY(do_softirq_own_stack)
>  ENDPROC(do_softirq_own_stack)
>  
>  #ifdef CONFIG_XEN
> -idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
> +idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
>  
>  /*
>   * A note on the "critical region" in our callback handler.
> @@ -1029,8 +1028,6 @@ ENTRY(xen_failsafe_callback)
>   movq8(%rsp), %r11
>   addq$0x30, %rsp
>   pushq   $0  /* RIP */
> - pushq   %r11
> - pushq   %rcx
>   UNWIND_HINT_IRET_REGS offset=8
>   jmp general_protection
>  1:   /* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
> @@ -1061,9 +1058,8 @@ idtentry int3   do_int3 
> has_error_code
>  idtentry stack_segment   do_stack_segmenthas_error_code=1
>  
>  #ifdef CONFIG_XEN
> -idtentry xen_debug   do_debughas_error_code=0
> -idtentry xen_int3do_int3 has_error_code=0
> -idtentry xen_stack_segment   do_stack_segmenthas_error_code=1
> +idtentry xendebugdo_debughas_error_code=0
> +idtentry xenint3 do_int3 has_error_code=0
>  #endif
>  
>  idtentry general_protection  do_general_protection   has_error_code=1
> @@ -1227,6 +1223,7 @@ ENTRY(error_exit)
>  END(error_exit)
>  
>  /* Runs on exception stack */
> +/* XXX: broken on Xen PV */
>  ENTRY(nmi)
>   UNWIND_HINT_IRET_REGS
>   /*
> --- a/arch/x86/entry/entry_64_compat.S
> +++ b/arch/x86/entry/entry_64_compat.S
> @@ -293,7 +293,6 @@ ENTRY(entry_INT80_compat)
>   /*
>* Interrupts are off on entry.
>*/
> - PARAVIRT_ADJUST_EXCEPTION_FRAME
>   ASM_CLAC/* Do this early to minimize exposure */
>   SWAPGS
>  
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -960,11 +960,6 @@ extern void default_banner(void);
>  #define GET_CR2_INTO_RAX \
>   call PARA_INDIRECT(pv_mmu_ops+PV_MMU_read_cr2)
>  
> -#define PARAVIRT_ADJUST_EXCEPTION_FRAME  
> \
> - PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_adjust_exception_frame), \
> -   CLBR_NONE,\
> -   call PARA_INDIRECT(pv_irq_ops+PV_IRQ_adjust_exception_frame))
> -
>  #define USERGS_SYSRET64  
> \
>   PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64),   \
> 

Re: [PATCH v7 0/2] perf/core: addressing 4x slowdown during per-process profiling of STREAM benchmark on Intel Xeon Phi

[Alexey Budankov]

Hi,
On 22.08.2017 23:21, Peter Zijlstra wrote:
> On Fri, Aug 18, 2017 at 08:17:15AM +0300, Alexey Budankov wrote:
>> Hi,
> 
> Please don't post new versions in reply to old versions, that gets them
> lost in thread sorted views.
> 
>> This patch set v7 moves event groups into rb trees and implements 
>> skipping to the current CPU's list on hrtimer interrupt.
> 
> Does this depend on your timekeeping rework posted in that v6 thread?
> If so, I would have expected to see that as part of these patches, if
> not, I'm confused, because part of the problem was that we currently
> need to update times for events we don't want to schedule etc..
> 
>> Events allocated for the same CPU are still kept in a linked list
>> of the event directly attached to the tree because it is unclear 
>> how to implement fast iteration thru events allocated for 
>> the same CPU when they are all attached to a tree employing 
>> additional 64bit index as a secondary treee key.
> 
> Finding the CPU subtree and rb_next() wasn't good?

I eventually managed to overcome difficulties with implementation
of rb_tree indexed by {cpu,index} for event groups so please 
see patches v9.

> 
> 
> 

Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

[Takashi Iwai]

On Thu, 31 Aug 2017 11:56:16 +0200,
Alexandre Belloni wrote:
> 
> On 31/08/2017 at 10:23:19 +0200, Julia Lawall wrote:
> > 
> > 
> > On Thu, 31 Aug 2017, Alexandre Belloni wrote:
> > 
> > > On 31/08/2017 at 06:40:42 +0200, Christophe JAILLET wrote:
> > > > If 'clk_prepare_enable()' fails, we must release some resources before
> > > > returning. Add a new label in the existing error handling path and 
> > > > 'goto'
> > > > there.
> > > >
> > > > Fixes: 260ea95cc027 ("ASoC: atmel: ac97c: Handle return value of 
> > > > clk_prepare_enable.")
> > > > Signed-off-by: Christophe JAILLET 
> > >
> > > And here is the fallout of the stupid, brainless "fixing" of issues
> > > reported by static analysis tools.
> > >
> > > This clk_prepare_enable will never fail. If it was going to fail, the
> > > platform would never boot to a point were it is able to execute that
> > > code. It is really annoying to have so much churn for absolutely 0
> > > benefit.
> > 
> > Would it be more productive to put the code back like it was before, ie no
> > return value and no check, and add a comment to the definition of
> > clk_prepare_enable indicating that there are many case where the call
> > cannot fail?  Grepping through the code suggests that it is about 50-50 on
> > checking the return value or not doing so, which might suggest that
> > checking the value is often not required.
> > 
> 
> I'd say that it is often useless to test the value. I don't have any
> problem with the test as it doesn't add much (at least it doesn't print
> an error message). So it may stays here. What I'm really unhappy about
> is people sending hundreds of similar, autogenerated patches to
> maintainers without actually putting any thought into them. That put all
> the burden on the maintainers to weed out the incorrect patches.

I share your concerns, e.g. the burden of maintenance is a problem.

But in this case, the original code looks really buggy.  If the test
doesn't make sense, don't test it but give a proper comment from the
beginning.  Instead, the current code does check the return value yet
with the incorrect error path.

The proposed "fix" won't change any actual behavior in practice, which
is useless, yes.  (And this is good -- at least it's safe to apply :)
OTOH, the semantics is a different question, and the patch corrects
it, which isn't so stupid, IMO.


thanks,

Takashi

Re: [PATCH v6 1/3] perf/core: use rb trees for pinned/flexible groups

[Alexey Budankov]

On 15.08.2017 20:28, Alexey Budankov wrote:
> Hi Peter,
> 
> On 07.08.2017 10:17, Alexey Budankov wrote:
>> On 04.08.2017 17:36, Peter Zijlstra wrote:
>>> On Thu, Aug 03, 2017 at 11:30:09PM +0300, Alexey Budankov wrote:
 On 03.08.2017 16:00, Peter Zijlstra wrote:
> On Wed, Aug 02, 2017 at 11:13:54AM +0300, Alexey Budankov wrote:
>>>
>> +/*
>> + * Find group list by a cpu key and rotate it.
>> + */
>> +static void
>> +perf_event_groups_rotate(struct rb_root *groups, int cpu)
>> +{
>> +struct rb_node *node;
>> +struct perf_event *node_event;
>> +
>> +node = groups->rb_node;
>> +
>> +while (node) {
>> +node_event = container_of(node,
>> +struct perf_event, group_node);
>> +
>> +if (cpu < node_event->cpu) {
>> +node = node->rb_left;
>> +} else if (cpu > node_event->cpu) {
>> +node = node->rb_right;
>> +} else {
>> +list_rotate_left(_event->group_list);
>> +break;
>> +}
>> +}
>> +}
>
> Ah, you worry about how to rotate inside a tree?

 Exactly.

>
> You can do that by adding (run)time based ordering, and you'll end up
> with a runtime based scheduler.

 Do you mean replacing a CPU indexed rb_tree of lists with 
 an CPU indexed rb_tree of counter indexed rb_trees?
>>>
>>> No, single tree, just more complicated ordering rules.
>>>
> A trivial variant keeps a simple counter per tree that is incremented
> for each rotation. That should end up with the events ordered exactly
> like the list. And if you have that comparator like above, expressing
> that additional ordering becomes simple ;-)
>
> Something like:
>
> struct group {
>   u64 vtime;
>   rb_tree tree;
> };
>
> bool event_less(left, right)
> {
>   if (left->cpu < right->cpu)
> return true;
>
>   if (left->cpu > right_cpu)
> return false;
>
>   if (left->vtime < right->vtime)
> return true;
>
>   return false;
> }
>
> insert_group(group, event, tail)
> {
>   if (tail)
> event->vtime = ++group->vtime;
>
>   tree_insert(>root, event);
> }
>
> Then every time you use insert_group(.tail=1) it goes to the end of that
> CPU's 'list'.
>

 Could you elaborate more on how to implement rotation?
>>>
>>> Its almost all there, but let me write a complete replacement for your
>>> perf_event_group_rotate() above.
>>>
>>> /* find the leftmost event matching @cpu */
>>> /* XXX not sure how to best parametrise a subtree search, */
>>> /* again, C sucks... */
>>> struct perf_event *__group_find_cpu(group, cpu)
>>> {
>>> struct rb_node *node = group->tree.rb_node;
>>> struct perf_event *event, *match = NULL;
>>>
>>> while (node) {
>>> event = container_of(node, struct perf_event, group_node);
>>>
>>> if (cpu > event->cpu) {
>>> node = node->rb_right;
>>> } else if (cpu < event->cpu) {
>>> node = node->rb_left;
>>> } else {
>>> /*
>>>  * subtree match, try left subtree for a
>>>  * 'smaller' match.
>>>  */
>>> match = event;
>>> node = node->rb_left;
>>> }
>>> }
>>>
>>> return match;
>>> }
>>>
>>> void perf_event_group_rotate(group, int cpu)
>>> {
>>> struct perf_event *event = __group_find_cpu(cpu);
>>>
>>> if (!event)
>>> return;
>>>
>>> tree_delete(>tree, event);
>>> insert_group(group, event, 1);
>>> }
>>>
>>> So we have a tree ordered by {cpu,vtime} and what we do is find the
>>> leftmost {cpu} entry, that is the smallest vtime entry for that cpu. We
>>> then take it out and re-insert it with a vtime number larger than any
>>> other, which places it as the rightmost entry for that cpu.
>>>
>>>
>>> So given:
>>>
>>>{1,1}
>>>/ \
>>> {0,5} {1,2}
>>>/ \\
>>> {0,1} {0,6}  {1,4}
>>>
>>>
>>> __group_find_cpu(.cpu=1) will return {1,1} as being the leftmost entry
>>> with cpu=1. We'll then remove it, update its vtime to 7 and re-insert.
>>> resulting in something like:
>>>
>>>{1,2}
>>>/ \
>>> {0,5} {1,4}
>>>/ \\
>>> {0,1} {0,6}  {1,7}
>>>
>>
>> Makes sense. The implementation becomes a bit simpler. The drawbacks 
>> may be several rotations of potentially big tree on the critical path, 
>> instead of updating four pointers in case of the tree of lists.
> 
> I implemented the approach you had suggested (as I understood it),
> tested it and got results that are drastically different from what 
> 

[PATCH v2 5/6] mmc: sdhci-omap: Add OMAP SDHCI driver

[Kishon Vijay Abraham I]

Create a new sdhci-omap driver to configure the eMMC/SD/SDIO controller
in TI's OMAP SoCs making use of the SDHCI core library. For OMAP specific
configurations, populate sdhci_ops with OMAP specific callbacks and use
SDHCI quirks.
Enable only high speed mode for both SD and eMMC here and add other
UHS mode support later.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/mmc/host/Kconfig  |  12 +
 drivers/mmc/host/Makefile |   1 +
 drivers/mmc/host/sdhci-omap.c | 604 ++
 3 files changed, 617 insertions(+)
 create mode 100644 drivers/mmc/host/sdhci-omap.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 02179ed2a40d..03178c42efbb 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -899,3 +899,15 @@ config MMC_SDHCI_XENON
  This selects Marvell Xenon eMMC/SD/SDIO SDHCI.
  If you have a controller with this interface, say Y or M here.
  If unsure, say N.
+
+config MMC_SDHCI_OMAP
+   tristate "TI SDHCI Controller Support"
+   depends on MMC_SDHCI_PLTFM && OF
+   help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in TI's DRA7 SOCs. The controller supports
+ SD/MMC/SDIO devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 303f5cd46cd9..2b5a8133948d 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_MMC_SDHCI_MSM)   += sdhci-msm.o
 obj-$(CONFIG_MMC_SDHCI_ST) += sdhci-st.o
 obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)+= sdhci-pic32.o
 obj-$(CONFIG_MMC_SDHCI_BRCMSTB)+= sdhci-brcmstb.o
+obj-$(CONFIG_MMC_SDHCI_OMAP)   += sdhci-omap.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
CFLAGS-cb710-mmc+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
new file mode 100644
index ..cdbd3e1b894e
--- /dev/null
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -0,0 +1,604 @@
+/**
+ * SDHCI Controller driver for TI's OMAP SoCs
+ *
+ * Copyright (C) 2017 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sdhci-pltfm.h"
+
+#define SDHCI_OMAP_CON 0x12c
+#define CON_DW8BIT(5)
+#define CON_DMA_MASTER BIT(20)
+#define CON_INIT   BIT(1)
+#define CON_OD BIT(0)
+
+#define SDHCI_OMAP_CMD 0x20c
+
+#define SDHCI_OMAP_HCTL0x228
+#define HCTL_SDBP  BIT(8)
+#define HCTL_SDVS_SHIFT9
+#define HCTL_SDVS_MASK (0x7 << HCTL_SDVS_SHIFT)
+#define HCTL_SDVS_33   (0x7 << HCTL_SDVS_SHIFT)
+#define HCTL_SDVS_30   (0x6 << HCTL_SDVS_SHIFT)
+#define HCTL_SDVS_18   (0x5 << HCTL_SDVS_SHIFT)
+
+#define SDHCI_OMAP_SYSCTL  0x22c
+#define SYSCTL_CEN BIT(2)
+#define SYSCTL_CLKD_SHIFT  6
+#define SYSCTL_CLKD_MASK   0x3ff
+
+#define SDHCI_OMAP_STAT0x230
+
+#define SDHCI_OMAP_IE  0x234
+#define INT_CC_EN  BIT(0)
+
+#define SDHCI_OMAP_AC120x23c
+#define AC12_V1V8_SIGENBIT(19)
+
+#define SDHCI_OMAP_CAPA0x240
+#define CAPA_VS33  BIT(24)
+#define CAPA_VS30  BIT(25)
+#define CAPA_VS18  BIT(26)
+
+#define SDHCI_OMAP_TIMEOUT 1   /* 1 msec */
+
+#define SYSCTL_CLKD_MAX0x3FF
+
+#define IOV_1V8180 /* 18 uV */
+#define IOV_3V0300 /* 30 uV */
+#define IOV_3V3330 /* 33 uV */
+
+struct sdhci_omap_data {
+   u32 offset;
+};
+
+struct sdhci_omap_host {
+   void __iomem*base;
+   struct device   *dev;
+   struct  regulator   *pbias;
+   boolpbias_enabled;
+   struct sdhci_host   *host;
+   u8  bus_mode;
+   u8  power_mode;
+};
+
+static inline u32 sdhci_omap_readl(struct sdhci_omap_host *host,
+  

[PATCH v2 0/6] mmc: Add OMAP SDHCI driver

[Kishon Vijay Abraham I]

This is the first step in deprecating omap_hsmmc driver completely
and moving to sdhci-omap driver which uses the sdhci library.

This patch that adds a new SDHCI quirk "MMC_RSP_136" has already been
merged and hence removed it in this revision.

Apart from the quirk, sdhci-omap has it's own callbacks
to set_clock (clock divider programming is different from generic sdhci)
, set_power, set_bus_width, set_bus_mode and platform_send_init_74_clocks.
These callback functions are implemented based on omap_hsmmc driver.
Since sdhci-omap driver requires pbias regulator fixes to be present, I've
sent them as part of this series.

The sdhci-omap driver supports only the high speed mode and UHS/HS200
mode will be added in a later series.

It has been tested only in boards having DRA7 SoCs like dra7-evm, dra72-evm,
am571x-idk, am572x-idk, am57xx-evm. (Tested only eMMC and SD.
SDIO support will be added later). The plan is to fully convert DRA7
SoC to use SDHCI driver and then convert other legacy platforms to use
SDHCI.

The first 3 patches have also been verified not to cause any regression.

Next Steps:
*) Add UHS support to sdhci-omap
*) Add SDIO support
*) Add support for older TI platforms

Changes from v2:
*) Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
*) Included a couple of patches from Ravikumar to fix pbias-regulator driver
   to support max-voltage of 3.3V. This is required for sdhci-omap driver.
*) Create sdhci-omap as a new driver with MMC generic bindings and hence doesn't
   have bindings like ti,dual-volt added for omap-hsmmc. (Instead of
   ti,dual-volt, sdhci-omap driver uses the supported regulator voltage to
   set controller IO voltage capabilities).
   When omap-hsmmc driver is deprecated, support for these properties will
   be added to sdhci-omap.
*) Fixed minor comments from Adrian).

Changes from v1:
*) Remove the quirks and instead use sdhci_omap specific callbacks for
   set_power, set_busmode etc.
*) Add a patch from Adrian to tidy reading 136-bit responses

I've also pushed the entire series along with dependent dt patches @
https://github.com/kishon/linux-wip.git ulf_next (in case someone
wants to test)

Kishon Vijay Abraham I (4):
  mmc: host: omap_hsmmc: Remove setting PBIAS voltage
  dt-bindings: sdhci-omap: Add bindings for the sdhci-omap controller
  mmc: sdhci-omap: Add OMAP SDHCI driver
  MAINTAINERS: Add TI OMAP SDHCI Maintainer

Ravikumar Kattekola (2):
  regulator: pbias: Select voltage table based on max-voltage
  ARM: dts: dra7: Increase max-voltage of pbias regulator

 .../devicetree/bindings/mmc/sdhci-omap.txt |  16 +
 MAINTAINERS|   6 +
 arch/arm/boot/dts/dra7.dtsi|   2 +-
 drivers/mmc/host/Kconfig   |  12 +
 drivers/mmc/host/Makefile  |   1 +
 drivers/mmc/host/omap_hsmmc.c  |  33 +-
 drivers/mmc/host/sdhci-omap.c  | 604 +
 drivers/regulator/pbias-regulator.c|  21 +-
 8 files changed, 666 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt
 create mode 100644 drivers/mmc/host/sdhci-omap.c

-- 
2.11.0

Re: [alsa-devel] [PATCH] ALSA: ac97c: Fix an error handling path in 'atmel_ac97c_probe()'

[Takashi Iwai]

On Thu, 31 Aug 2017 12:13:00 +0200,
Takashi Iwai wrote:
> 
> On Thu, 31 Aug 2017 11:56:16 +0200,
> Alexandre Belloni wrote:
> > 
> > On 31/08/2017 at 10:23:19 +0200, Julia Lawall wrote:
> > > 
> > > 
> > > On Thu, 31 Aug 2017, Alexandre Belloni wrote:
> > > 
> > > > On 31/08/2017 at 06:40:42 +0200, Christophe JAILLET wrote:
> > > > > If 'clk_prepare_enable()' fails, we must release some resources before
> > > > > returning. Add a new label in the existing error handling path and 
> > > > > 'goto'
> > > > > there.
> > > > >
> > > > > Fixes: 260ea95cc027 ("ASoC: atmel: ac97c: Handle return value of 
> > > > > clk_prepare_enable.")
> > > > > Signed-off-by: Christophe JAILLET 
> > > >
> > > > And here is the fallout of the stupid, brainless "fixing" of issues
> > > > reported by static analysis tools.
> > > >
> > > > This clk_prepare_enable will never fail. If it was going to fail, the
> > > > platform would never boot to a point were it is able to execute that
> > > > code. It is really annoying to have so much churn for absolutely 0
> > > > benefit.
> > > 
> > > Would it be more productive to put the code back like it was before, ie no
> > > return value and no check, and add a comment to the definition of
> > > clk_prepare_enable indicating that there are many case where the call
> > > cannot fail?  Grepping through the code suggests that it is about 50-50 on
> > > checking the return value or not doing so, which might suggest that
> > > checking the value is often not required.
> > > 
> > 
> > I'd say that it is often useless to test the value. I don't have any
> > problem with the test as it doesn't add much (at least it doesn't print
> > an error message). So it may stays here. What I'm really unhappy about
> > is people sending hundreds of similar, autogenerated patches to
> > maintainers without actually putting any thought into them. That put all
> > the burden on the maintainers to weed out the incorrect patches.
> 
> I share your concerns, e.g. the burden of maintenance is a problem.
> 
> But in this case, the original code looks really buggy.  If the test
> doesn't make sense, don't test it but give a proper comment from the
> beginning.  Instead, the current code does check the return value yet
> with the incorrect error path.
> 
> The proposed "fix" won't change any actual behavior in practice, which
> is useless, yes.  (And this is good -- at least it's safe to apply :)
> OTOH, the semantics is a different question, and the patch corrects
> it, which isn't so stupid, IMO.

Ah, wait, now I see your point.  It was introduced by the very recent
patch through Mark's asoc tree (since it was wrongly labeled as "ASoC"
while it isn't).  That patch looks indeed fishy.  The change in
atmel_ac97c_resume() is also bad.

So, I'd prefer reverting the wrong commit instead, and leave some
comment about the uselessness of clk_prepare_enable() return value
check.


thanks,

Takashi

[PATCH v2 2/6] regulator: pbias: Select voltage table based on max-voltage

[Kishon Vijay Abraham I]

From: Ravikumar Kattekola 

Reference manuals of OMAP5x and DRA7x have been updated to reflect
the PBIAS regulator max-voltage as 3.3V instead of 3.0V, while OMAP3x
and OMAP4x are still quoting 3.0V. So, as of now, the pbias driver
needs to support both 3.0V and 3.3V IO voltage based on the max-voltage
supported by the PBIAS regulator.

Document reference:
SWPU249AF - OMAP543x Technical reference manual - August 2016
SPRUI30C – DRA75x, DRA74x Technical reference manual November 2016

Tested on:
DRA75x PG 2.0 REV H EVM

Signed-off-by: Ravikumar Kattekola 
Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/regulator/pbias-regulator.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index 0cb76ba29e84..8f782d22fdbe 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -34,6 +34,8 @@ struct pbias_reg_info {
u32 vmode;
unsigned int enable_time;
char *name;
+   const unsigned int *pbias_volt_table;
+   int n_voltages;
 };
 
 struct pbias_regulator_data {
@@ -49,11 +51,16 @@ struct pbias_of_data {
unsigned int offset;
 };
 
-static const unsigned int pbias_volt_table[] = {
+static const unsigned int pbias_volt_table_3_0V[] = {
180,
300
 };
 
+static const unsigned int pbias_volt_table_3_3V[] = {
+   180,
+   330
+};
+
 static const struct regulator_ops pbias_regulator_voltage_ops = {
.list_voltage = regulator_list_voltage_table,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
@@ -69,6 +76,8 @@ static const struct pbias_reg_info pbias_mmc_omap2430 = {
.vmode = BIT(0),
.disable_val = 0,
.enable_time = 100,
+   .pbias_volt_table = pbias_volt_table_3_0V,
+   .n_voltages = 2,
.name = "pbias_mmc_omap2430"
 };
 
@@ -77,6 +86,8 @@ static const struct pbias_reg_info pbias_sim_omap3 = {
.enable_mask = BIT(9),
.vmode = BIT(8),
.enable_time = 100,
+   .pbias_volt_table = pbias_volt_table_3_0V,
+   .n_voltages = 2,
.name = "pbias_sim_omap3"
 };
 
@@ -86,6 +97,8 @@ static const struct pbias_reg_info pbias_mmc_omap4 = {
.disable_val = BIT(25),
.vmode = BIT(21),
.enable_time = 100,
+   .pbias_volt_table = pbias_volt_table_3_0V,
+   .n_voltages = 2,
.name = "pbias_mmc_omap4"
 };
 
@@ -95,6 +108,8 @@ static const struct pbias_reg_info pbias_mmc_omap5 = {
.disable_val = BIT(25),
.vmode = BIT(21),
.enable_time = 100,
+   .pbias_volt_table = pbias_volt_table_3_3V,
+   .n_voltages = 2,
.name = "pbias_mmc_omap5"
 };
 
@@ -199,8 +214,8 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.owner = THIS_MODULE;
drvdata[data_idx].desc.type = REGULATOR_VOLTAGE;
drvdata[data_idx].desc.ops = _regulator_voltage_ops;
-   drvdata[data_idx].desc.volt_table = pbias_volt_table;
-   drvdata[data_idx].desc.n_voltages = 2;
+   drvdata[data_idx].desc.volt_table = info->pbias_volt_table;
+   drvdata[data_idx].desc.n_voltages = info->n_voltages;
drvdata[data_idx].desc.enable_time = info->enable_time;
drvdata[data_idx].desc.vsel_reg = offset;
drvdata[data_idx].desc.vsel_mask = info->vmode;
-- 
2.11.0

[PATCH v2 3/6] ARM: dts: dra7: Increase max-voltage of pbias regulator

[Kishon Vijay Abraham I]

From: Ravikumar Kattekola 

As per recent TRM, PBIAS cell on dra7 devices supports
3.3V and not 3.0V as documented earlier.

Update PBIAS regulator max voltage to match this.

Document reference:
SPRUI30C – DRA75x, DRA74x Technical reference manual- November 2016

Tested on:
DRA75x PG 2.0 REV H EVM

Signed-off-by: Ravikumar Kattekola 
Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 0f0f6f58bd18..fc14e48b482e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -170,7 +170,7 @@
pbias_mmc_reg: pbias_mmc_omap5 {
regulator-name = 
"pbias_mmc_omap5";
regulator-min-microvolt 
= <180>;
-   regulator-max-microvolt 
= <300>;
+   regulator-max-microvolt 
= <330>;
};
};
 
-- 
2.11.0

[PATCH v2 4/6] dt-bindings: sdhci-omap: Add bindings for the sdhci-omap controller

[Kishon Vijay Abraham I]

Add binding for the TI's sdhci-omap controller.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/mmc/sdhci-omap.txt | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-omap.txt

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-omap.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
new file mode 100644
index ..66b5517d79d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-omap.txt
@@ -0,0 +1,16 @@
+* TI OMAP SDHCI Controller
+
+Refer to mmc.txt for standard MMC bindings.
+
+Required properties:
+- compatible: Should be "ti,dra7-sdhci" for DRA7 and DRA72 controllers
+- ti,hwmods: Must be "mmc",  is controller instance starting 1
+
+Example:
+   mmc1: mmc@0x4809c000 {
+   compatible = "ti,dra7-sdhci";
+   reg = <0x4809c000 0x400>;
+   ti,hwmods = "mmc1";
+   bus-width = <4>;
+   vmmc-supply = <>; /* phandle to regulator node */
+   };
-- 
2.11.0

[PATCH v2 6/6] MAINTAINERS: Add TI OMAP SDHCI Maintainer

[Kishon Vijay Abraham I]

Add Maintainer for the TI OMAP SDHCI driver.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Adrian Hunter 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c3feffb1c1c..e52af3b87404 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11776,6 +11776,12 @@ L: linux-...@vger.kernel.org
 S: Maintained
 F: drivers/mmc/host/sdhci-spear.c
 
+SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) TI OMAP DRIVER
+M: Kishon Vijay Abraham I 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/mmc/host/sdhci-omap.c
+
 SECURE ENCRYPTING DEVICE (SED) OPAL DRIVER
 M: Scott Bauer 
 M: Jonathan Derrick 
-- 
2.11.0

[PATCH v2 1/6] mmc: host: omap_hsmmc: Remove setting PBIAS voltage

[Kishon Vijay Abraham I]

PBIAS voltage should be set along with setting vqmmc voltage and
these voltages should be set as part of start_signal_voltage_switch
callback. However since omap_hsmmc is about to be deprecated,
remove setting of PBIAS voltage leaving the PBIAS voltage to be
at the reset value of 3.3V (we'll never have to change this to 1.8V
since UHS mode support will not be added to omap_hsmmc). This will
let pbias regulator driver to be fixed to support a maximum voltage of
3.3V.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/mmc/host/omap_hsmmc.c | 33 -
 1 file changed, 8 insertions(+), 25 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 3b5e6d11069b..f2a1137be8bc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -147,10 +147,6 @@
 #define OMAP_MMC_MAX_CLOCK 5200
 #define DRIVER_NAME"omap_hsmmc"
 
-#define VDD_1V8180 /* 18 uV */
-#define VDD_3V0300 /* 30 uV */
-#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
-
 /*
  * One controller can have multiple slots, like on some omap boards using
  * omap.c controller driver. Luckily this is not currently done on any known
@@ -308,8 +304,7 @@ static int omap_hsmmc_disable_supply(struct mmc_host *mmc)
return ret;
 }
 
-static int omap_hsmmc_set_pbias(struct omap_hsmmc_host *host, bool power_on,
-   int vdd)
+static int omap_hsmmc_set_pbias(struct omap_hsmmc_host *host, bool power_on)
 {
int ret;
 
@@ -317,17 +312,6 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host 
*host, bool power_on,
return 0;
 
if (power_on) {
-   if (vdd <= VDD_165_195)
-   ret = regulator_set_voltage(host->pbias, VDD_1V8,
-   VDD_1V8);
-   else
-   ret = regulator_set_voltage(host->pbias, VDD_3V0,
-   VDD_3V0);
-   if (ret < 0) {
-   dev_err(host->dev, "pbias set voltage fail\n");
-   return ret;
-   }
-
if (host->pbias_enabled == 0) {
ret = regulator_enable(host->pbias);
if (ret) {
@@ -350,8 +334,7 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host 
*host, bool power_on,
return 0;
 }
 
-static int omap_hsmmc_set_power(struct omap_hsmmc_host *host, int power_on,
-   int vdd)
+static int omap_hsmmc_set_power(struct omap_hsmmc_host *host, int power_on)
 {
struct mmc_host *mmc = host->mmc;
int ret = 0;
@@ -363,7 +346,7 @@ static int omap_hsmmc_set_power(struct omap_hsmmc_host 
*host, int power_on,
if (IS_ERR(mmc->supply.vmmc))
return 0;
 
-   ret = omap_hsmmc_set_pbias(host, false, 0);
+   ret = omap_hsmmc_set_pbias(host, false);
if (ret)
return ret;
 
@@ -385,7 +368,7 @@ static int omap_hsmmc_set_power(struct omap_hsmmc_host 
*host, int power_on,
if (ret)
return ret;
 
-   ret = omap_hsmmc_set_pbias(host, true, vdd);
+   ret = omap_hsmmc_set_pbias(host, true);
if (ret)
goto err_set_voltage;
} else {
@@ -1220,11 +1203,11 @@ static int omap_hsmmc_switch_opcond(struct 
omap_hsmmc_host *host, int vdd)
clk_disable_unprepare(host->dbclk);
 
/* Turn the power off */
-   ret = omap_hsmmc_set_power(host, 0, 0);
+   ret = omap_hsmmc_set_power(host, 0);
 
/* Turn the power ON with given VDD 1.8 or 3.0v */
if (!ret)
-   ret = omap_hsmmc_set_power(host, 1, vdd);
+   ret = omap_hsmmc_set_power(host, 1);
if (host->dbclk)
clk_prepare_enable(host->dbclk);
 
@@ -1621,10 +1604,10 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
if (ios->power_mode != host->power_mode) {
switch (ios->power_mode) {
case MMC_POWER_OFF:
-   omap_hsmmc_set_power(host, 0, 0);
+   omap_hsmmc_set_power(host, 0);
break;
case MMC_POWER_UP:
-   omap_hsmmc_set_power(host, 1, ios->vdd);
+   omap_hsmmc_set_power(host, 1);
break;
case MMC_POWER_ON:
do_send_init_stream = 1;
-- 
2.11.0

Re: [PATCH 2/4] arm: dts: exynos: add exynos5420 cpu capacity-dmips-mhz information

[Dietmar Eggemann]

On 30/08/17 21:26, Krzysztof Kozlowski wrote:
> On Wed, Aug 30, 2017 at 03:41:18PM +0100, Dietmar Eggemann wrote:
>> The following 'capacity-dmips-mhz' dt property values are used:
>>
>> Cortex-A15: 1024, Cortex-A7: 539
>>
>> They have been derived from the cpu_efficiency values:
>>
>> Cortex-A15: 3891, Cortex-A7: 2048
>>
>> by scaling them so that the Cortex-A15s (big cores) use 1024.
>>
>> The cpu_efficiency values were originally derived from the "Big.LITTLE
>> Processing with ARM Cortex™-A15 & Cortex-A7" white paper
>> (http://www.cl.cam.ac.uk/~rdm34/big.LITTLE.pdf). Table 1 lists 1.9x
>> (3891/2048) as the Cortex-A15 vs Cortex-A7 performance ratio for the
>> Dhrystone benchmark.
>>
>> The following platforms are affected once cpu-invariant accounting
>> support is re-connected to the task scheduler:
>>
>> arndale-octa, peach-pi, peach-pit, smdk5420
>>
>> The patch has been tested on Samsung Chromebook 2 13" (peach-pi, Exynos
>> 5800).
>>
>> $ cat /sys/devices/system/cpu/cpu*/cpu_capacity
>> 1024
>> 1024
>> 1024
>> 1024
>> 389
>> 389
>> 389
>> 389
> 
> I am missing something... shouldn't this be 539? Or is it scaled with
> the clock-frequency (1 GHz) value?

Yeah, the capacity-dmips-mhz dt value of 539 for the little cpus is
scaled by 1.3/1.8 (max cpu capacity/ system wide max cpu capacity):

539 * 1.3/1.8 = 389

This max cpu capacity scaling is part of both solutions, the 'cpu
capacity-dmips-mhz' and the 'cpu_efficiency/clock-frequency dt property'
one.

The (original*) cpu capacity on a heterogeneous platform expresses uArch
and max cpu frequency differences between the (logical) cpus of the
system.

* not further reduced by rt and/or irq pressure.

[...]

[PATCH v2 06/13] ANDROID: binder: add RT inheritance flag to node.

[Martijn Coenen]

Allows a binder node to specify whether it wants to
inherit real-time scheduling policy from a caller. This
inheritance may not always be desirable, for example in
cases where the binder call runs untrusted and therefore
potentially unbounded code.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c| 22 +-
 include/uapi/linux/android/binder.h |  8 
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 196676729521..5edde38a77b3 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -358,6 +358,8 @@ struct binder_error {
  *(invariant after initialized)
  * @min_priority: minimum scheduling priority
  *(invariant after initialized)
+ * @inherit_rt:   inherit RT scheduling policy from caller
+ *(invariant after initialized)
  * @async_todo:   list of async work items
  *(protected by @proc->inner_lock)
  *
@@ -394,6 +396,7 @@ struct binder_node {
 * invariant after initialization
 */
u8 sched_policy:2;
+   u8 inherit_rt:1;
u8 accept_fds:1;
u8 min_priority;
};
@@ -1214,7 +1217,8 @@ static void binder_set_priority(struct task_struct *task,
 
 static void binder_transaction_priority(struct task_struct *task,
struct binder_transaction *t,
-   struct binder_priority node_prio)
+   struct binder_priority node_prio,
+   bool inherit_rt)
 {
struct binder_priority desired_prio;
 
@@ -1225,8 +1229,13 @@ static void binder_transaction_priority(struct 
task_struct *task,
t->saved_priority.sched_policy = task->policy;
t->saved_priority.prio = task->normal_prio;
 
-   desired_prio.prio = t->priority.prio;
-   desired_prio.sched_policy = t->priority.sched_policy;
+   if (!inherit_rt && is_rt_policy(desired_prio.sched_policy)) {
+   desired_prio.prio = NICE_TO_PRIO(0);
+   desired_prio.sched_policy = SCHED_NORMAL;
+   } else {
+   desired_prio.prio = t->priority.prio;
+   desired_prio.sched_policy = t->priority.sched_policy;
+   }
 
if (node_prio.prio < t->priority.prio ||
(node_prio.prio == t->priority.prio &&
@@ -1331,6 +1340,7 @@ static struct binder_node *binder_init_node_ilocked(
FLAT_BINDER_FLAG_SCHED_POLICY_SHIFT;
node->min_priority = to_kernel_prio(node->sched_policy, priority);
node->accept_fds = !!(flags & FLAT_BINDER_FLAG_ACCEPTS_FDS);
+   node->inherit_rt = !!(flags & FLAT_BINDER_FLAG_INHERIT_RT);
spin_lock_init(>lock);
INIT_LIST_HEAD(>work.entry);
INIT_LIST_HEAD(>async_todo);
@@ -2749,7 +2759,8 @@ static bool binder_proc_transaction(struct 
binder_transaction *t,
 
if (thread) {
target_list = >todo;
-   binder_transaction_priority(thread->task, t, node_prio);
+   binder_transaction_priority(thread->task, t, node_prio,
+   node->inherit_rt);
} else if (!target_list) {
target_list = >todo;
} else {
@@ -4147,7 +4158,8 @@ static int binder_thread_read(struct binder_proc *proc,
tr.cookie =  target_node->cookie;
node_prio.sched_policy = target_node->sched_policy;
node_prio.prio = target_node->min_priority;
-   binder_transaction_priority(current, t, node_prio);
+   binder_transaction_priority(current, t, node_prio,
+   target_node->inherit_rt);
cmd = BR_TRANSACTION;
} else {
tr.target.ptr = 0;
diff --git a/include/uapi/linux/android/binder.h 
b/include/uapi/linux/android/binder.h
index 026558ac254d..70e252bf0be0 100644
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@ -79,6 +79,14 @@ enum flat_binder_object_flags {
 */
FLAT_BINDER_FLAG_SCHED_POLICY_MASK =
3U << FLAT_BINDER_FLAG_SCHED_POLICY_SHIFT,
+
+   /**
+* @FLAT_BINDER_FLAG_INHERIT_RT: whether the node inherits RT policy
+*
+* Only when set, calls into this node will inherit a real-time
+* scheduling policy from the caller (for synchronous transactions).
+*/
+   FLAT_BINDER_FLAG_INHERIT_RT = 0x800,
 };
 
 #ifdef BINDER_IPC_32BIT
-- 
2.14.1.581.gf28d330327-goog

[PATCH v2 00/13] ANDROID: binder: RT priority inheritance and small fixes.

[Martijn Coenen]

Changes since v1 [1]:
- added more detailed commit messages and comments to the priority
  inheritance patches, including rationale for not using
  schet_setscheduler() directly, or rt_mutex prio inheritance.
  No functional changes.

[1]: https://lkml.kernel.org/r/20170825093335.100892-1-m...@android.com

---

The first six patches in this set introduce support for priority
inheritance of real-time scheduling policies in binder. With the
introduction of Android Treble, functionality that used to be in a
single process is now split over two or more processes, which
communicate using binder IPC. For latency sensitive operations such as
sensor events, Bluetooth audio and rendering, inheriting the
(real-time) priority of the caller is crucial to meet requirements.

The implementation in this series directly calls into the scheduler to
modify priorities, since I haven't found a way to make this work
correctly with rt_mutex or other existing priority inheritance
mechanisms. I have found the current approach to be reliable, but I'm
happy to look into suggestions to make this work with existing
infrastructure. More details in the patches themselves.

Colin's patch adds a debug ioctl that allows us to more accurately track
memory leaks, as it allows us to identify objects to which only remote
processes have a reference.

The subsequent patches are mostly small fixes and (hopefully) well
explained in the commit messages.

All patches except 'Add tracing for binder priority inheritance' have
already been reviewed by Android engineers and are merged in Android's
common kernel trees.

---

Colin Cross (1):
  ANDROID: binder: Add BINDER_GET_NODE_DEBUG_INFO ioctl

Martijn Coenen (12):
  ANDROID: binder: remove proc waitqueue
  ANDROID: binder: push new transactions to waiting threads.
  ANDROID: binder: add support for RT prio inheritance.
  ANDROID: binder: add min sched_policy to node.
  ANDROID: binder: improve priority inheritance.
  ANDROID: binder: add RT inheritance flag to node.
  ANDROID: binder: don't check prio permissions on restore.
  ANDROID: binder: Don't BUG_ON(!spin_is_locked()).
  ANDROID: binder: call poll_wait() unconditionally.
  ANDROID: binder: don't enqueue death notifications to thread todo.
  ANDROID: binder: don't queue async transactions to thread.
  ANDROID: binder: Add tracing for binder priority inheritance.

 drivers/android/binder.c| 773 
 drivers/android/binder_trace.h  |  24 ++
 include/uapi/linux/android/binder.h |  63 ++-
 3 files changed, 689 insertions(+), 171 deletions(-)

-- 
2.14.1.581.gf28d330327-goog

[PATCH v2 03/13] ANDROID: binder: add support for RT prio inheritance.

[Martijn Coenen]

Adds support for SCHED_BATCH/SCHED_FIFO/SCHED_RR priority inheritance
to the binder driver. The desired behavior is as follows:

Each thread in the binder threadpool runs at a default priority, which is
typically nice 0.

Binder nodes (endpoints that can receive binder transactions) can have a
minimum priority associated with them, which means that all transactions
on this node must run at least at this priority.

Let's say a synchronous transaction is made from task T1 in process P1
to process P2, into node N1 which has a 'N1_min_priority':
1) T1 wakes up a task T2 in P2, then blocks on a waitqueue for reply
2) T2 determines prio=max(prio_of_T1, N1_min_priority);
3) T2 sets its own priority to prio, and stores its old prio
4) T2 returns to userspace, does work
5) Eventually, T2 returns a reply transaction to the driver
6) T2 queues the reply to T1 and wakes it up
7) T2 restores its own priority to what it was

For an asynchronous transaction:
1) T1 wakes up a task T2 in P2, returns to userspace (no work left)
2) T2 determines prio=max(default_prio, N1_min_priority)
3) T2 sets its own priority to prio, and stores its old prio
4) T2 returns to userspace, does work, completes
5) T2 calls back into kernel for more work
6) T2 restores its own priority to its default priority

This still leaves a race condition, where T2 wakes up and gets preempted
before it has a chance to change its own priority. This is addressed in
one of the next patches in the series, by letting T1 change the priority
of T2 *before* waking it up.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 217 ---
 1 file changed, 188 insertions(+), 29 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 5366726db968..282c2a89ab2e 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -77,6 +77,7 @@
 #endif
 
 #include 
+#include 
 #include "binder_alloc.h"
 #include "binder_trace.h"
 
@@ -463,6 +464,22 @@ enum binder_deferred_state {
BINDER_DEFERRED_RELEASE  = 0x04,
 };
 
+/**
+ * struct binder_priority - scheduler policy and priority
+ * @sched_policyscheduler policy
+ * @prio[100..139] for SCHED_NORMAL, [0..99] for FIFO/RT
+ *
+ * The binder driver supports inheriting the following scheduler policies:
+ * SCHED_NORMAL
+ * SCHED_BATCH
+ * SCHED_FIFO
+ * SCHED_RR
+ */
+struct binder_priority {
+   unsigned int sched_policy;
+   int prio;
+};
+
 /**
  * struct binder_proc - binder process bookkeeping
  * @proc_node:element for binder_procs list
@@ -542,7 +559,7 @@ struct binder_proc {
int requested_threads;
int requested_threads_started;
int tmp_ref;
-   long default_priority;
+   struct binder_priority default_priority;
struct dentry *debugfs_entry;
struct binder_alloc alloc;
struct binder_context *context;
@@ -624,8 +641,8 @@ struct binder_transaction {
struct binder_buffer *buffer;
unsigned intcode;
unsigned intflags;
-   longpriority;
-   longsaved_priority;
+   struct binder_priority  priority;
+   struct binder_priority  saved_priority;
kuid_t  sender_euid;
/**
 * @lock:  protects @from, @to_proc, and @to_thread
@@ -1051,22 +1068,142 @@ static void binder_wakeup_proc_ilocked(struct 
binder_proc *proc)
binder_wakeup_thread_ilocked(proc, thread, /* sync = */false);
 }
 
-static void binder_set_nice(long nice)
+static bool is_rt_policy(int policy)
+{
+   return policy == SCHED_FIFO || policy == SCHED_RR;
+}
+
+static bool is_fair_policy(int policy)
+{
+   return policy == SCHED_NORMAL || policy == SCHED_BATCH;
+}
+
+static bool binder_supported_policy(int policy)
+{
+   return is_fair_policy(policy) || is_rt_policy(policy);
+}
+
+static int to_userspace_prio(int policy, int kernel_priority)
+{
+   if (is_fair_policy(policy))
+   return PRIO_TO_NICE(kernel_priority);
+   else
+   return MAX_USER_RT_PRIO - 1 - kernel_priority;
+}
+
+static int to_kernel_prio(int policy, int user_priority)
+{
+   if (is_fair_policy(policy))
+   return NICE_TO_PRIO(user_priority);
+   else
+   return MAX_USER_RT_PRIO - 1 - user_priority;
+}
+
+/**
+ * binder_set_priority() - sets the scheduler priority of a task
+ * @task:  task to set priority on
+ * @desired:   desired priority to run at
+ *
+ * The scheduler policy of tasks is changed explicitly, because we want to
+ * support a few distinct features:
+ * 1) If the requested priority is higher than the maximum allowed priority,
+ *we want to "clip" at the highest supported priority.
+ * 2) For a future patch, we need to allow changing the priority of a task
+ *with a different UID; when we make a binder transaction from process A
+ *to process B with different UIDs, A must be able to set B's 

Re: [PATCH v3] staging: ks7010: Fix coding style and remove checkpatch.pl warnings.

[Dan Carpenter]

Thanks!

regards,
dan carpenter

Re: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation

[Peter Zijlstra]

On Wed, Aug 30, 2017 at 06:24:39PM +0900, Byungchul Park wrote:
> > And there obviously _should_ not be any dependencies between those. A
> 
> 100% right. Since there obviously should not be any, it would be better
> to check them. So I've endlessly asked you 'do you have any reason removing
> the opportunity for that check?'. Overhead? Logical problem? Or want to
> believe workqueue setup code perfect forever? I mean, is it a problem if we
> check them?

Nothing is perfect. And cross-release less that others. Covering that
case for the first few works really isn't worth it.

[PATCH v2 10/13] ANDROID: binder: call poll_wait() unconditionally.

[Martijn Coenen]

Because we're not guaranteed that subsequent calls
to poll() will have a poll_table_struct parameter
with _qproc set. When _qproc is not set, poll_wait()
is a noop, and we won't be woken up correctly.

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 7da9c42583f7..68780b8e856c 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3850,12 +3850,6 @@ static void binder_stat_br(struct binder_proc *proc,
}
 }
 
-static int binder_has_thread_work(struct binder_thread *thread)
-{
-   return !binder_worklist_empty(thread->proc, >todo) ||
-   thread->looper_need_return;
-}
-
 static int binder_put_node_cmd(struct binder_proc *proc,
   struct binder_thread *thread,
   void __user **ptrp,
@@ -4486,12 +4480,9 @@ static unsigned int binder_poll(struct file *filp,
 
binder_inner_proc_unlock(thread->proc);
 
-   if (binder_has_work(thread, wait_for_proc_work))
-   return POLLIN;
-
poll_wait(filp, >wait, wait);
 
-   if (binder_has_thread_work(thread))
+   if (binder_has_work(thread, wait_for_proc_work))
return POLLIN;
 
return 0;
-- 
2.14.1.581.gf28d330327-goog

[PATCH v2 11/13] ANDROID: binder: don't enqueue death notifications to thread todo.

[Martijn Coenen]

This allows userspace to request death notifications without
having to worry about getting an immediate callback on the same
thread; one scenario where this would be problematic is if the
death recipient handler grabs a lock that was already taken
earlier (eg as part of a nested transaction).

Signed-off-by: Martijn Coenen 
---
 drivers/android/binder.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 68780b8e856c..2d23f8699d40 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3718,22 +3718,12 @@ static int binder_thread_write(struct binder_proc *proc,
ref->death = death;
if (ref->node->proc == NULL) {
ref->death->work.type = 
BINDER_WORK_DEAD_BINDER;
-   if (thread->looper &
-   (BINDER_LOOPER_STATE_REGISTERED |
-BINDER_LOOPER_STATE_ENTERED))
-   binder_enqueue_work(
-   proc,
-   >death->work,
-   >todo);
-   else {
-   binder_inner_proc_lock(proc);
-   binder_enqueue_work_ilocked(
-   >death->work,
-   >todo);
-   binder_wakeup_proc_ilocked(
-   proc);
-   binder_inner_proc_unlock(proc);
-   }
+
+   binder_inner_proc_lock(proc);
+   binder_enqueue_work_ilocked(
+   >death->work, >todo);
+   binder_wakeup_proc_ilocked(proc);
+   binder_inner_proc_unlock(proc);
}
} else {
if (ref->death == NULL) {
-- 
2.14.1.581.gf28d330327-goog

Re: [PATCH v3 51/59] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

[Marc Zyngier]

On 30/08/17 21:58, Christoffer Dall wrote:
> On Wed, Aug 30, 2017 at 04:36:06PM +0100, Marc Zyngier wrote:
>> On 28/08/17 19:18, Christoffer Dall wrote:
>>> On Mon, Jul 31, 2017 at 06:26:29PM +0100, Marc Zyngier wrote:
 When a vPE is not running, a VLPI being made pending results in a
 doorbell interrupt being delivered. Let's handle this interrupt
 and update the pending_last flag that indicates that VLPIs are
 pending. The corresponding vcpu is also kicked into action.

 Signed-off-by: Marc Zyngier 
 ---
  virt/kvm/arm/vgic/vgic-v4.c | 34 ++
  1 file changed, 34 insertions(+)

 diff --git a/virt/kvm/arm/vgic/vgic-v4.c b/virt/kvm/arm/vgic/vgic-v4.c
 index 534d3051a078..6af3cde6d7d4 100644
 --- a/virt/kvm/arm/vgic/vgic-v4.c
 +++ b/virt/kvm/arm/vgic/vgic-v4.c
 @@ -21,6 +21,19 @@
  
  #include "vgic.h"
  
 +static irqreturn_t vgic_v4_doorbell_handler(int irq, void *info)
 +{
 +  struct kvm_vcpu *vcpu = info;
 +
 +  if (!kvm_vgic_vcpu_pending_irq(vcpu)) {
 +  vcpu->arch.vgic_cpu.vgic_v3.its_vpe.pending_last = true;
 +  kvm_make_request(KVM_REQ_IRQ_PENDING, vcpu);
 +  kvm_vcpu_kick(vcpu);
 +  }
>>>
>>> Can this ever fire while vgic_v4_init() is running and before te rest of
>>> the system has been properly initialized with some entertaining results
>>> to follow?  (I'm not sure if spurious doorbell non-resident vPE
>>> interrupts is a thing or not).
>>
>> It could if you only had this patch. The following patch makes sure that
>> the interrupt does not get enabled at request time, meaning it will only
>> get enabled when the vcpu will eventually block.
>>
>> And yes, spurious doorbells are a real thing. And they suck.
>>
> 
> Ah, my abilities to forward read on a patch series are quite poor.
Not quite. It indicates that the patch split is a bit wrong, and that

irq_set_status_flags(irq, IRQ_NOAUTOEN | IRQ_DISABLE_UNLAZY);

should really be in this patch and not the following one.

I'll fix that as I rebase the whole thing.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v2 03/13] ANDROID: binder: add support for RT prio inheritance.

[Peter Zijlstra]

On Thu, Aug 31, 2017 at 10:04:20AM +0200, Martijn Coenen wrote:
> Adds support for SCHED_BATCH/SCHED_FIFO/SCHED_RR priority inheritance
> to the binder driver. The desired behavior is as follows:

You fail to support SCHED_DEADLINE, that's not optional.

[PATCH] arm64: move TASK_* definitions to

[Yury Norov]

ILP32 series [1] introduces the dependency on  for
TASK_SIZE macro. Which in turn requires , and
 include , giving a circular dependency,
because TASK_SIZE is currently located in .

In other architectures, TASK_SIZE is defined in , and
moving TASK_SIZE there fixes the problem. 

Discussion: https://patchwork.kernel.org/patch/9929107/

[1] https://github.com/norov/linux/tree/ilp32-next

CC: Will Deacon 
CC: Laura Abbott 
Cc: Ard Biesheuvel 
Cc: Catalin Marinas 
Cc: James Morse 
Suggested-by: Mark Rutland 
Signed-off-by: Yury Norov 
---
 arch/arm64/include/asm/memory.h| 15 ---
 arch/arm64/include/asm/processor.h | 21 +
 arch/arm64/kernel/entry.S  |  2 +-
 3 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 3585a5e26151..87296a6ed1b3 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -61,8 +61,6 @@
  * KIMAGE_VADDR - the virtual address of the start of the kernel image
  * VA_BITS - the maximum number of bits for virtual addresses.
  * VA_START - the first kernel virtual address.
- * TASK_SIZE - the maximum size of a user space task.
- * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
  */
 #define VA_BITS(CONFIG_ARM64_VA_BITS)
 #define VA_START   (UL(0x) - \
@@ -77,19 +75,6 @@
 #define PCI_IO_END (VMEMMAP_START - SZ_2M)
 #define PCI_IO_START   (PCI_IO_END - PCI_IO_SIZE)
 #define FIXADDR_TOP(PCI_IO_START - SZ_2M)
-#define TASK_SIZE_64   (UL(1) << VA_BITS)
-
-#ifdef CONFIG_COMPAT
-#define TASK_SIZE_32   UL(0x1)
-#define TASK_SIZE  (test_thread_flag(TIF_32BIT) ? \
-   TASK_SIZE_32 : TASK_SIZE_64)
-#define TASK_SIZE_OF(tsk)  (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
-   TASK_SIZE_32 : TASK_SIZE_64)
-#else
-#define TASK_SIZE  TASK_SIZE_64
-#endif /* CONFIG_COMPAT */
-
-#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
 
 #define KERNEL_START  _text
 #define KERNEL_END_end
diff --git a/arch/arm64/include/asm/processor.h 
b/arch/arm64/include/asm/processor.h
index 29adab8138c3..7dddca21fc64 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -19,6 +19,10 @@
 #ifndef __ASM_PROCESSOR_H
 #define __ASM_PROCESSOR_H
 
+#define TASK_SIZE_64   (UL(1) << VA_BITS)
+
+#ifndef __ASSEMBLY__
+
 /*
  * Default implementation of macro that returns current
  * instruction pointer ("program counter").
@@ -37,6 +41,22 @@
 #include 
 #include 
 
+/*
+ * TASK_SIZE - the maximum size of a user space task.
+ * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
+ */
+#ifdef CONFIG_COMPAT
+#define TASK_SIZE_32   UL(0x1)
+#define TASK_SIZE  (test_thread_flag(TIF_32BIT) ? \
+   TASK_SIZE_32 : TASK_SIZE_64)
+#define TASK_SIZE_OF(tsk)  (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
+   TASK_SIZE_32 : TASK_SIZE_64)
+#else
+#define TASK_SIZE  TASK_SIZE_64
+#endif /* CONFIG_COMPAT */
+
+#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
+
 #define STACK_TOP_MAX  TASK_SIZE_64
 #ifdef CONFIG_COMPAT
 #define AARCH32_VECTORS_BASE   0x
@@ -194,4 +214,5 @@ static inline void spin_lock_prefetch(const void *ptr)
 int cpu_enable_pan(void *__unused);
 int cpu_enable_cache_maint_trap(void *__unused);
 
+#endif /* __ASSEMBLY__ */
 #endif /* __ASM_PROCESSOR_H */
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index e1c59d4008a8..f5e851eeda4b 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -28,7 +28,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.11.0

[RFC PATCH 2/6] iommu/of: Add stall and pasid properties to iommu_fwspec

[Yisheng Xie]

From: Jean-Philippe Brucker 

Add stall and pasid properties to iommu_fwspec.

Signed-off-by: Jean-Philippe Brucker 
---
 drivers/iommu/of_iommu.c | 11 +++
 include/linux/iommu.h|  2 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 84fa6b4..b926276 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -209,6 +209,16 @@ static bool of_pci_rc_supports_ats(struct device_node 
*rc_node)
break;
}
 
+   if (dev->iommu_fwspec) {
+   const __be32 *prop;
+
+   if (of_get_property(np, "dma-can-stall", NULL))
+   dev->iommu_fwspec->can_stall = true;
+
+   prop = of_get_property(np, "pasid-bits", NULL);
+   if (prop)
+   dev->iommu_fwspec->num_pasid_bits = be32_to_cpu(*prop);
+   }
+
return ops;
 }
 
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 1c5a216..5f580de 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -387,6 +387,8 @@ struct iommu_fwspec {
void*iommu_priv;
u32 flags;
unsigned intnum_ids;
+   unsigned long   num_pasid_bits;
+   boolcan_stall;
u32 ids[1];
 };
 
-- 
1.7.12.4

Re: [RFC 0/4] mmc: sdhci-msm: Add CQE support for sdhci-msm

[Adrian Hunter]

On 30/08/17 16:04, Ritesh Harjani wrote:
> Hi All,
> 
> Please ignore the previous patch series from a wrong email
> address. Stupid gitconfig issue. Apologies for the spam.
> 
> This is RFC patch series based on top of ulfh_mmc/cmdq branch
> which is based upon Adrian's CMDQ patch series.
> 
> Below patch series enables CQE for sdhci-msm platform.
> This has been tested on internal 8996 MTP which has CMDQ support.
> 
> Fixes w.r.t. CMDQ:-
> There are some patches identified which were required atleast on
> MSM platform. I am not sure if these are required for any other
> CQE platform or not. Patchset 1, 3 & 4 commit text describes
> the problems.
> 
> Performance related:- 
> I gave one small shot for performance and the numbers were not looking good.
> So, unless I have tested for performance completely, I should not discuss 
> on performance numbers as of now with this patchset. 
> I can try doing some more performance testing and post the results -
> though this may take some while.

You might also need custom Send Status Configuration.

> 
> I used below test script for random read/write test.
> 
> *randwrite-test-script*
> [global]
> bs=32k
> size=1g
> rw=randwrite
> direct=1
> directory=/data/fiotest

Random write results can vary a lot.  It is important to know if the eMMC
has lots of un-mapped blocks or not. e.g. for ext4 is the "-o discard"
option being used.  I find I get more consistent results if I always have
discards enabled.

> 
> [file1]
> filename=singlefile1
> 
> *randread-test-script*
> [global]
> bs=32k
> size=1g
> rw=randread
> directory=/data/fiotest

If you don't set numjobs > 1 then there is little benefit of the queue.
Also still need direct=1

> 
> [file1]
> filename=singlefile1
> 
> @Adrian,
> Thanks a lot for pursuing and bringing CMDQ patch series to it's final stages 
> :)
> 
> 
> Ritesh Harjani (4):
>   mmc: cqhci: Move CQHCI_ENABLE before setting TDLBA/TDLBAU
>   mmc: sdhci-msm: Add CQHCI support for sdhci-msm
>   mmc: sdhci-msm: Change the desc_sz on cqe_enable/disable.
>   mmc: sdhci-msm: Handle unexpected interrupt case on enabling legacy
> IRQs on CQE halt
> 
>  .../devicetree/bindings/mmc/sdhci-msm.txt  |   1 +
>  drivers/mmc/host/Kconfig   |   1 +
>  drivers/mmc/host/cqhci.c   |   7 +-
>  drivers/mmc/host/sdhci-msm.c   | 121 
> -
>  4 files changed, 125 insertions(+), 5 deletions(-)
>