RE: [lkp-robot] e5a305ac4a: WARNING:at_lib/list_debug.c:#__list_del_entry_valid

2017-01-17 Thread Matthew Wilcox
From: lkp-robot-requ...@eclists.intel.com 
[mailto:lkp-robot-requ...@eclists.intel.com] On Behalf Of kernel test robot
> FYI, we noticed the following commit:
> 
> commit: e5a305ac4a5233e039586c97f4ea643a4c7dc484 ("Reimplement IDR
> and IDA using the radix tree")
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel
> .org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-
> next.git=02%7C01%7Cmawilcox%40microsoft.com%7C3b615320ff5c48f
> efde708d43f40a5f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> 36202994282292096=vMGk%2FAoZeMkABynnuEIiKM07li%2FzdZlSMM
> NmwNIGQ1s%3D=0 master

1. I'm not entirely convinced that this is a reasonable commit to test.  Due to 
the way Andrew has merged a fix for this commit in a second commit, it's 
expected to be buggy.  Although I don't think it could cause this specific 
failure pattern.  Testing commit ffc87d11841ec68a44c57735ff4fada521ab5a27 would 
make more sense.

2. Ignoring the mangling that outlook has done to that URL, it's pointing 
somewhere not very useful for a web browser to access: 
http://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/

Pointing to https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/ 
would make more sense

3. Thank you for reminding me that I need to send Andrew a complete replacement 
for that patch.



[RESEND PATCH v5 2/3] perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info

2017-01-17 Thread Hari Bathini
This patch updates perf tool to examine PERF_RECORD_NAMESPACES events
emitted by the kernel when fork, clone, setns or unshare are invoked.
Also, it synthesizes PERF_RECORD_NAMESPACES events for processes that
were running prior to invocation of perf record, the data for which
is taken from /proc/$PID/ns. These changes make way for analyzing
events with regard to namespaces.

Signed-off-by: Hari Bathini 
---

Changes from v4:
* Added warning when nr_namespaces values of the kernel
  and perf tool mismatch.
* Improved printing of namespace records.


 tools/include/uapi/linux/perf_event.h |   38 +
 tools/perf/builtin-annotate.c |1 
 tools/perf/builtin-diff.c |1 
 tools/perf/builtin-inject.c   |   14 +++
 tools/perf/builtin-kmem.c |1 
 tools/perf/builtin-kvm.c  |2 
 tools/perf/builtin-lock.c |1 
 tools/perf/builtin-mem.c  |1 
 tools/perf/builtin-record.c   |   33 +++-
 tools/perf/builtin-report.c   |1 
 tools/perf/builtin-sched.c|1 
 tools/perf/builtin-script.c   |   41 +
 tools/perf/builtin-trace.c|3 -
 tools/perf/perf.h |1 
 tools/perf/util/Build |1 
 tools/perf/util/data-convert-bt.c |2 
 tools/perf/util/event.c   |  143 -
 tools/perf/util/event.h   |   19 
 tools/perf/util/evsel.c   |3 +
 tools/perf/util/machine.c |   34 
 tools/perf/util/machine.h |3 +
 tools/perf/util/namespaces.c  |   35 
 tools/perf/util/namespaces.h  |   26 ++
 tools/perf/util/session.c |7 ++
 tools/perf/util/thread.c  |   44 ++
 tools/perf/util/thread.h  |6 +
 tools/perf/util/tool.h|2 
 27 files changed, 450 insertions(+), 14 deletions(-)
 create mode 100644 tools/perf/util/namespaces.c
 create mode 100644 tools/perf/util/namespaces.h

diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index c66a485..ee60f54 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -344,7 +344,8 @@ struct perf_event_attr {
use_clockid:  1, /* use @clockid for time 
fields */
context_switch :  1, /* context switch data */
write_backward :  1, /* Write ring buffer from 
end to beginning */
-   __reserved_1   : 36;
+   namespaces :  1, /* include namespaces data 
*/
+   __reserved_1   : 35;
 
union {
__u32   wakeup_events;/* wakeup every n events */
@@ -610,6 +611,29 @@ struct perf_event_header {
__u16   size;
 };
 
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE   8
+
+struct perf_ns_link_info {
+   charname[NS_NAME_SIZE];
+   __u64   dev;
+   __u64   ino;
+};
+
+enum {
+   NET_NS_INDEX= 0,
+   UTS_NS_INDEX= 1,
+   IPC_NS_INDEX= 2,
+   PID_NS_INDEX= 3,
+   USER_NS_INDEX   = 4,
+   MNT_NS_INDEX= 5,
+   CGROUP_NS_INDEX = 6,
+
+   NAMESPACES_MAX, /* maximum available namespaces */
+};
+
 enum perf_event_type {
 
/*
@@ -862,6 +886,18 @@ enum perf_event_type {
 */
PERF_RECORD_SWITCH_CPU_WIDE = 15,
 
+   /*
+* struct {
+*  struct perf_event_headerheader;
+*  u32 pid;
+*  u32 tid;
+*  u32 nr_namespaces;
+*  struct namespace_link_info  link_info[NAMESPACES_MAX];
+*  struct sample_idsample_id;
+* };
+*/
+   PERF_RECORD_NAMESPACES  = 16,
+
PERF_RECORD_MAX,/* non-ABI */
 };
 
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index ebb6283..1b63dc4 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -393,6 +393,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
.comm   = perf_event__process_comm,
.exit   = perf_event__process_exit,
.fork   = perf_event__process_fork,
+   .namespaces = perf_event__process_namespaces,
.ordered_events = true,
.ordering_requires_timestamps = true,
},
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 9ff0db4..c52552f 

[RESEND PATCH v5 0/3] perf: add support for analyzing events for containers

2017-01-17 Thread Hari Bathini
Please ignore the previously sent v5 of this patchset.

Currently, there is no trivial mechanism to analyze events based on
containers. perf -G can be used, but it will not filter events for the
containers created after perf is invoked, making it difficult to assess/
analyze performance issues of multiple containers at once.

This patch-set is aimed at addressing this limitation by introducing a
new PERF_RECORD_NAMESPACES event that records namespaces related info.
As containers are created with namespaces, the new data can be used to
in assessment/analysis of multiple containers.

The first patch introduces PERF_RECORD_NAMESPACES in kernel while the
second patch makes the corresponding changes in perf tool to read this
PERF_RECORD_NAMESPACES events. The third patch demonstrates analysis
of containers with this data by adding a cgroup identifier column in
perf report, which contains the cgroup namespace's device and inode
numbers. This is based on the assumption that each container is created
with it's own cgroup namespace. The third patch has scope for improvement
based on the conventions a container is attributed with, going forward.

---

Hari Bathini (3):
  perf: add PERF_RECORD_NAMESPACES to include namespaces related info
  perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info
  perf tool: add cgroup identifier entry in perf report


 include/linux/perf_event.h|2 
 include/uapi/linux/perf_event.h   |   38 +
 kernel/events/core.c  |  142 +
 kernel/fork.c |3 +
 kernel/nsproxy.c  |5 +
 tools/include/uapi/linux/perf_event.h |   38 +
 tools/perf/builtin-annotate.c |1 
 tools/perf/builtin-diff.c |1 
 tools/perf/builtin-inject.c   |   14 +++
 tools/perf/builtin-kmem.c |1 
 tools/perf/builtin-kvm.c  |2 
 tools/perf/builtin-lock.c |1 
 tools/perf/builtin-mem.c  |1 
 tools/perf/builtin-record.c   |   33 +++-
 tools/perf/builtin-report.c   |1 
 tools/perf/builtin-sched.c|1 
 tools/perf/builtin-script.c   |   41 +
 tools/perf/builtin-trace.c|3 -
 tools/perf/perf.h |1 
 tools/perf/util/Build |1 
 tools/perf/util/data-convert-bt.c |2 
 tools/perf/util/event.c   |  143 -
 tools/perf/util/event.h   |   19 
 tools/perf/util/evsel.c   |3 +
 tools/perf/util/hist.c|7 ++
 tools/perf/util/hist.h|1 
 tools/perf/util/machine.c |   34 
 tools/perf/util/machine.h |3 +
 tools/perf/util/namespaces.c  |   35 
 tools/perf/util/namespaces.h  |   26 ++
 tools/perf/util/session.c |7 ++
 tools/perf/util/sort.c|   41 +
 tools/perf/util/sort.h|7 ++
 tools/perf/util/thread.c  |   44 ++
 tools/perf/util/thread.h  |6 +
 tools/perf/util/tool.h|2 
 36 files changed, 695 insertions(+), 15 deletions(-)
 create mode 100644 tools/perf/util/namespaces.c
 create mode 100644 tools/perf/util/namespaces.h



[RESEND PATCH v5 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

2017-01-17 Thread Hari Bathini
With the advert of container technologies like docker, that depend
on namespaces for isolation, there is a need for tracing support for
namespaces. This patch introduces new PERF_RECORD_NAMESPACES event
for tracing based on namespaces related info.

Signed-off-by: Hari Bathini 
---

Changes from v4:
* Added nr_namespaces to PERF_RECORD_NAMESPACES record. Also added the
  name of the namespaces.


 include/linux/perf_event.h  |2 +
 include/uapi/linux/perf_event.h |   38 ++
 kernel/events/core.c|  142 +++
 kernel/fork.c   |3 +
 kernel/nsproxy.c|5 +
 5 files changed, 189 insertions(+), 1 deletion(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 78ed810..063a99f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1110,6 +1110,7 @@ extern int perf_unregister_guest_info_callbacks(struct 
perf_guest_info_callbacks
 
 extern void perf_event_exec(void);
 extern void perf_event_comm(struct task_struct *tsk, bool exec);
+extern void perf_event_namespaces(struct task_struct *tsk);
 extern void perf_event_fork(struct task_struct *tsk);
 
 /* Callchains */
@@ -1313,6 +1314,7 @@ static inline int perf_unregister_guest_info_callbacks
 static inline void perf_event_mmap(struct vm_area_struct *vma) { }
 static inline void perf_event_exec(void)   { }
 static inline void perf_event_comm(struct task_struct *tsk, bool exec) { }
+static inline void perf_event_namespaces(struct task_struct *tsk)  { }
 static inline void perf_event_fork(struct task_struct *tsk){ }
 static inline void perf_event_init(void)   { }
 static inline int  perf_swevent_get_recursion_context(void){ 
return -1; }
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index c66a485..ee60f54 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -344,7 +344,8 @@ struct perf_event_attr {
use_clockid:  1, /* use @clockid for time 
fields */
context_switch :  1, /* context switch data */
write_backward :  1, /* Write ring buffer from 
end to beginning */
-   __reserved_1   : 36;
+   namespaces :  1, /* include namespaces data 
*/
+   __reserved_1   : 35;
 
union {
__u32   wakeup_events;/* wakeup every n events */
@@ -610,6 +611,29 @@ struct perf_event_header {
__u16   size;
 };
 
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE   8
+
+struct perf_ns_link_info {
+   charname[NS_NAME_SIZE];
+   __u64   dev;
+   __u64   ino;
+};
+
+enum {
+   NET_NS_INDEX= 0,
+   UTS_NS_INDEX= 1,
+   IPC_NS_INDEX= 2,
+   PID_NS_INDEX= 3,
+   USER_NS_INDEX   = 4,
+   MNT_NS_INDEX= 5,
+   CGROUP_NS_INDEX = 6,
+
+   NAMESPACES_MAX, /* maximum available namespaces */
+};
+
 enum perf_event_type {
 
/*
@@ -862,6 +886,18 @@ enum perf_event_type {
 */
PERF_RECORD_SWITCH_CPU_WIDE = 15,
 
+   /*
+* struct {
+*  struct perf_event_headerheader;
+*  u32 pid;
+*  u32 tid;
+*  u32 nr_namespaces;
+*  struct namespace_link_info  link_info[NAMESPACES_MAX];
+*  struct sample_idsample_id;
+* };
+*/
+   PERF_RECORD_NAMESPACES  = 16,
+
PERF_RECORD_MAX,/* non-ABI */
 };
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 110b38a..15ebae1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -46,6 +46,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "internal.h"
 
@@ -375,6 +377,7 @@ static DEFINE_PER_CPU(struct pmu_event_list, pmu_sb_events);
 
 static atomic_t nr_mmap_events __read_mostly;
 static atomic_t nr_comm_events __read_mostly;
+static atomic_t nr_namespaces_events __read_mostly;
 static atomic_t nr_task_events __read_mostly;
 static atomic_t nr_freq_events __read_mostly;
 static atomic_t nr_switch_events __read_mostly;
@@ -3908,6 +3911,8 @@ static void unaccount_event(struct perf_event *event)
atomic_dec(_mmap_events);
if (event->attr.comm)
atomic_dec(_comm_events);
+   if (event->attr.namespaces)
+   atomic_dec(_namespaces_events);
if (event->attr.task)
atomic_dec(_task_events);
if (event->attr.freq)
@@ -6408,6 +6413,7 @@ 

Re: [PATCH v11 08/12] drm/mediatek: add dsi interrupt control

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi interrupt control
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 92 
> ++
>  1 file changed, 92 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 6f4b3bb..474861a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,16 @@
>  
>  #define DSI_START0x00
>  
> +#define DSI_INTEN0x08
> +
> +#define DSI_INTSTA   0x0c
> +#define LPRX_RD_RDY_INT_FLAG BIT(0)
> +#define CMD_DONE_INT_FLAGBIT(1)
> +#define TE_RDY_INT_FLAG  BIT(2)
> +#define VM_DONE_INT_FLAG BIT(3)
> +#define EXT_TE_RDY_INT_FLAG  BIT(4)
> +#define DSI_BUSY BIT(31)
> +
>  #define DSI_CON_CTRL 0x10
>  #define DSI_RESETBIT(0)
>  #define DSI_EN   BIT(1)
> @@ -71,6 +82,9 @@
>  
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RACK 0x84
> +#define RACK BIT(0)
> +
>  #define DSI_PHY_LCCON0x104
>  #define LC_HS_TX_EN  BIT(0)
>  #define LC_ULPM_EN   BIT(1)
> @@ -137,6 +151,8 @@ struct mtk_dsi {
>   struct videomode vm;
>   int refcount;
>   bool enabled;
> + u32 irq_data;
> + wait_queue_head_t irq_wait_queue;
>  };
>  
>  static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> @@ -469,6 +485,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
>   writel(1, dsi->regs + DSI_START);
>  }
>  
> +static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> +{
> + u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + writel(inten, dsi->regs + DSI_INTEN);
> +}
> +
> +static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
> +{
> + dsi->irq_data |= irq_bit;
> +}
> +
> +static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +{
> + dsi->irq_data &= ~irq_bit;
> +}
> +
> +static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +  unsigned int timeout)
> +{
> + s32 ret = 0;
> + unsigned long jiffies = msecs_to_jiffies(timeout);
> +
> + ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +dsi->irq_data & irq_flag,
> +jiffies);
> + if (ret == 0) {
> + DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +
> + return ret;
> +}
> +
> +static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> +{
> + struct mtk_dsi *dsi = dev_id;
> + u32 status, tmp;
> + u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + status = readl(dsi->regs + DSI_INTSTA) & flag;
> +
> + if (status) {
> + do {
> + mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
> + tmp = readl(dsi->regs + DSI_INTSTA);
> + } while (tmp & DSI_BUSY);
> +
> + mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
> + mtk_dsi_irq_data_set(dsi, status);
> + wake_up_interruptible(>irq_wait_queue);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -517,6 +591,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>  
>   mtk_dsi_ps_control_vact(dsi);
>   mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>  
>   mtk_dsi_set_mode(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -818,6 +893,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct device_node *remote_node, *endpoint;
>   struct resource *regs;
> + int irq_num;
>   int comp_id;
>   int ret;
>  
> @@ -894,6 +970,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> + irq_num = platform_get_irq(pdev, 0);
> + if (irq_num < 0) {
> + dev_err(>dev, "failed to request dsi irq resource\n");
> + return -EPROBE_DEFER;
> + }
> +
> + irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
> + ret = devm_request_irq(>dev, irq_num, mtk_dsi_irq,
> +IRQF_TRIGGER_LOW, dev_name(>dev), dsi);
> + if (ret) {
> + dev_err(>dev, "failed to request mediatek dsi 

Re: [RFC 4/4] mm, page_alloc: fix premature OOM when racing with cpuset mems update

2017-01-17 Thread Hillf Danton

On Wednesday, January 18, 2017 6:16 AM Vlastimil Babka wrote: 
> 
> @@ -3802,13 +3811,8 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
> order,
>* Also recalculate the starting point for the zonelist iterator or
>* we could end up iterating over non-eligible zones endlessly.
>*/
Is the newly added comment still needed?

> - if (unlikely(ac.nodemask != nodemask)) {
> -no_zone:
> + if (unlikely(ac.nodemask != nodemask))
>   ac.nodemask = nodemask;
> - ac.preferred_zoneref = first_zones_zonelist(ac.zonelist,
> - ac.high_zoneidx, ac.nodemask);
> - /* If we have NULL preferred zone, slowpath wll handle that */
> - }
> 
>   page = __alloc_pages_slowpath(alloc_mask, order, );
> 
> --
> 2.11.0



Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs

2017-01-17 Thread Peter Chen
On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-15 19:45:51)
> > 
> > So, you need to call phy_set_mode when switching between host and device.
> > Besides, you also need to toggle VBUSVLDEXT when the external vbus
> > is on or off at device mode (doesn't need for host mode), is it correct?
> 
> Correct.
> 
> > 
> > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> > to port it to generic phy framework.
> > 
> 
> Ok. I'll look into that. Can the other patches in this series be picked
> up? Otherwise I can resend them all again once I fix the phy_set_mode()
> call location and introduce a new phy op.

I can pick up chipidea patches after you test the patch I supplied at:

[PATCH v6 11/25] usb: chipidea: vbus event may exist before starting
gadget

You may ping other maintainers to pick up other patches.

-- 

Best Regards,
Peter Chen


Re: [PATCH v11 09/12] drm/mediatek: add dsi transfer function

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi read/write commands for transfer function
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 168 
> -
>  1 file changed, 166 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 474861a..b3c7fd8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "mtk_drm_ddp_comp.h"
> @@ -80,8 +81,16 @@
>  #define DSI_HBP_WC   0x54
>  #define DSI_HFP_WC   0x58
>  
> +#define DSI_CMDQ_SIZE0x60
> +#define CMDQ_SIZE0x3f
> +
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RX_DATA0 0x74
> +#define DSI_RX_DATA1 0x78
> +#define DSI_RX_DATA2 0x7c
> +#define DSI_RX_DATA3 0x80
> +
>  #define DSI_RACK 0x84
>  #define RACK BIT(0)
>  
> @@ -117,6 +126,15 @@
>  #define CLK_HS_POST  (0xff << 8)
>  #define CLK_HS_EXIT  (0xff << 16)
>  
> +#define DSI_CMDQ00x180
> +#define CONFIG   (0xff << 0)
> +#define SHORT_PACKET 0
> +#define LONG_PACKET  2
> +#define BTA  BIT(2)
> +#define DATA_ID  (0xff << 8)
> +#define DATA_0   (0xff << 16)
> +#define DATA_1   (0xff << 24)
> +
>  #define T_LPX5
>  #define T_HS_PREP6
>  #define T_HS_TRAIL   8
> @@ -125,6 +143,12 @@
>  
>  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
>  
> +#define MTK_DSI_HOST_IS_READ(type) \
> + ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> + (type == MIPI_DSI_DCS_READ))
> +
>  struct phy;
>  
>  struct mtk_dsi {
> @@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, 
> u32 irq_bit)
>   dsi->irq_data |= irq_bit;
>  }
>  
> -static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
>  {
>   dsi->irq_data &= ~irq_bit;
>  }
>  
> -static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
>unsigned int timeout)
>  {
>   s32 ret = 0;
> @@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   return 0;
>  }
>  
> +static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> +{
> + u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
> +
> + while (timeout_ms--) {
> + if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
> + break;
> +
> + usleep_range(2, 4);
> + }
> +
> + if (timeout_ms == 0) {
> + DRM_WARN("polling dsi wait not busy timeout!\n");
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +}
> +
> +static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
> +{
> + switch (type) {
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
> + return 1;
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
> + return 2;
> + case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
> + case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
> + return read_data[1] + read_data[2] * 16;
> + case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
> + DRM_INFO("type is 0x02, try again\n");
> + break;
> + default:
> + DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
> +{
> + const char *tx_buf = msg->tx_buf;
> + u8 config, cmdq_size, cmdq_off, type = msg->type;
> + u32 reg_val, cmdq_mask, i;
> +
> + if (MTK_DSI_HOST_IS_READ(type))
> + config = BTA;
> + else
> + config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
> +
> + if (msg->tx_len > 2) {
> + cmdq_size = 1 + (msg->tx_len + 3) / 4;
> + cmdq_off = 4;
> + cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
> + reg_val = (msg->tx_len << 16) | (type << 8) | config;
> + } else {
> + cmdq_size = 1;
> + 

[PATCH 2/6] phy: phy-mt65xx-usb3: split SuperSpeed port into two ones

2017-01-17 Thread Chunfeng Yun
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If wants to support SS, we can compound u2port0 and u3port0,
or u2port1 and u3port0, if select latter one, u2port0 is not needed.

So it's more flexible to split usb3 port into two ones and also try
best to save power by disabling unnecessary ports.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |  124 -
 1 file changed, 61 insertions(+), 63 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index fc9a4f0..c187a3b 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -30,11 +30,11 @@
 #define SSUSB_SIFSLV_SPLLC 0x
 #define SSUSB_SIFSLV_U2FREQ0x0100
 
-/* offsets of sub-segment in each port registers */
+/* offsets of banks in each u2phy registers */
 #define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-#define SSUSB_SIFSLV_U3PHYD_BASE   0x0100
-#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
-#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+/* offsets of banks in each u3phy registers */
+#define SSUSB_SIFSLV_U3PHYD_BASE   0x
+#define SSUSB_SIFSLV_U3PHYA_BASE   0x0200
 
 #define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
 #define PA0_RG_U2PLL_FORCE_ON  BIT(15)
@@ -49,7 +49,6 @@
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
 
 #define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
-#define PA6_RG_U2_ISO_EN   BIT(31)
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
 #define PA6_RG_U2_SQTH GENMASK(3, 0)
@@ -91,18 +90,18 @@
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
-#define U3P_U3_PHYA_REG0   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x)
+#define U3P_U3_PHYA_REG0   (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
 #define P3A_RG_U3_VUSB10_ONBIT(5)
 
-#define U3P_U3_PHYA_REG6   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
 
-#define U3P_U3_PHYA_REG9   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
 #define P3A_RG_RX_DAC_MUX  GENMASK(5, 1)
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_DA_BASE + 0x)
+#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
@@ -148,7 +147,7 @@ struct mt65xx_phy_instance {
 
 struct mt65xx_u3phy {
struct device *dev;
-   void __iomem *sif_base; /* include sif2, but exclude port's */
+   void __iomem *sif_base; /* only shared sif */
struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
@@ -179,7 +178,7 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
-   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index >> 1);
writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
 
/* enable frequency meter */
@@ -227,6 +226,41 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
writel(tmp, instance->port_base + U3P_USBPHYACR5);
 }
 
+static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
+   struct mt65xx_phy_instance *instance)
+{
+   void __iomem *port_base = instance->port_base;
+   u32 tmp;
+
+   /* gating PCIe Analog XTAL clock */
+   tmp = readl(u3phy->sif_base + U3P_XTALCTL3);
+   tmp |= XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD;
+   writel(tmp, u3phy->sif_base + U3P_XTALCTL3);
+
+   /* gating XSQ */
+   tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
+   tmp &= ~P3A_RG_XTAL_EXT_EN_U3;
+   tmp |= P3A_RG_XTAL_EXT_EN_U3_VAL(2);
+   writel(tmp, port_base + U3P_U3PHYA_DA_REG0);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG9);
+   tmp &= ~P3A_RG_RX_DAC_MUX;
+   tmp |= P3A_RG_RX_DAC_MUX_VAL(4);
+   writel(tmp, port_base + U3P_U3_PHYA_REG9);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG6);
+   tmp &= ~P3A_RG_TX_EIDLE_CM;
+   tmp |= P3A_RG_TX_EIDLE_CM_VAL(0xe);
+   writel(tmp, port_base + U3P_U3_PHYA_REG6);
+
+   tmp = 

[PATCH 4/6] arm64: dts: mt8173: add a new reference clock for usb3 analog phy

2017-01-17 Thread Chunfeng Yun
add a new reference clock which comes from 26M oscillator directly
for SuperSpeed analog phy. and the old one which comes for PLL is
48M for HighSpeed analog phy.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..5d1663b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -754,8 +754,8 @@
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, 
<>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
-- 
1.7.9.5



[PATCH 3/6] phy: phy-mt65xx-usb3: add support for mt2712 platform

2017-01-17 Thread Chunfeng Yun
There are some variations from mt2701 to mt2712:
1. banks shared by multiple ports are put back into each port,
such as SPLLC and U2FREQ;
2. add a new bank MISC for u2port, and CHIP for u3port;
3. bank's offset in each port are also rearranged;

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |  326 ++---
 1 file changed, 208 insertions(+), 118 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index c187a3b..d515c69 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -23,46 +23,54 @@
 #include 
 #include 
 
-/*
- * for sifslv2 register, but exclude port's;
- * relative to USB3_SIF2_BASE base address
- */
-#define SSUSB_SIFSLV_SPLLC 0x
-#define SSUSB_SIFSLV_U2FREQ0x0100
-
-/* offsets of banks in each u2phy registers */
-#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-/* offsets of banks in each u3phy registers */
-#define SSUSB_SIFSLV_U3PHYD_BASE   0x
-#define SSUSB_SIFSLV_U3PHYA_BASE   0x0200
-
-#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
+/* version V1 sub-banks offset base address */
+/* banks shared by multiple phys */
+#define SSUSB_SIFSLV_V1_SPLLC  0x000   /* shared by u3 phys */
+#define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
+/* u2 phy bank */
+#define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
+/* u3 phy banks */
+#define SSUSB_SIFSLV_V1_U3PHYD 0x000
+#define SSUSB_SIFSLV_V1_U3PHYA 0x200
+
+/* version V2 sub-banks offset base address */
+/* u2 phy banks */
+#define SSUSB_SIFSLV_V2_MISC   0x000
+#define SSUSB_SIFSLV_V2_U2FREQ 0x100
+#define SSUSB_SIFSLV_V2_U2PHY_COM  0x300
+/* u3 phy banks */
+#define SSUSB_SIFSLV_V2_SPLLC  0x000
+#define SSUSB_SIFSLV_V2_CHIP   0x100
+#define SSUSB_SIFSLV_V2_U3PHYD 0x200
+#define SSUSB_SIFSLV_V2_U3PHYA 0x400
+
+#define U3P_USBPHYACR0 0x000
 #define PA0_RG_U2PLL_FORCE_ON  BIT(15)
 
-#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008)
+#define U3P_USBPHYACR2 0x008
 #define PA2_RG_SIF_U2PLL_FORCE_EN  BIT(18)
 
-#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define U3P_USBPHYACR5 0x014
 #define PA5_RG_U2_HSTX_SRCAL_ENBIT(15)
 #define PA5_RG_U2_HSTX_SRCTRL  GENMASK(14, 12)
 #define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
 
-#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
+#define U3P_USBPHYACR6 0x018
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
 #define PA6_RG_U2_SQTH GENMASK(3, 0)
 #define PA6_RG_U2_SQTH_VAL(x)  (0xf & (x))
 
-#define U3P_U2PHYACR4  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
+#define U3P_U2PHYACR4  0x020
 #define P2C_RG_USB20_GPIO_CTL  BIT(9)
 #define P2C_USB20_GPIO_MODEBIT(8)
 #define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
 
-#define U3D_U2PHYDCR0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060)
+#define U3D_U2PHYDCR0  0x060
 #define P2C_RG_SIF_U2PLL_FORCE_ON  BIT(24)
 
-#define U3P_U2PHYDTM0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068)
+#define U3P_U2PHYDTM0  0x068
 #define P2C_FORCE_UART_EN  BIT(26)
 #define P2C_FORCE_DATAIN   BIT(23)
 #define P2C_FORCE_DM_PULLDOWN  BIT(21)
@@ -84,47 +92,44 @@
P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \
P2C_RG_DPPULLDOWN | P2C_RG_TERMSEL)
 
-#define U3P_U2PHYDTM1  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x006C)
+#define U3P_U2PHYDTM1  0x06C
 #define P2C_RG_UART_EN BIT(16)
 #define P2C_RG_VBUSVALID   BIT(5)
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
-#define U3P_U3_PHYA_REG0   (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
-#define P3A_RG_U3_VUSB10_ONBIT(5)
-
-#define U3P_U3_PHYA_REG6   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6   0x018
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
 
-#define U3P_U3_PHYA_REG9   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9   0x024
 #define P3A_RG_RX_DAC_MUX  GENMASK(5, 1)
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
+#define U3P_U3_PHYA_DA_REG00x100
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
-#define U3P_PHYD_CDR1  (SSUSB_SIFSLV_U3PHYD_BASE + 0x005c)
+#define U3P_U3_PHYD_CDR1   0x05c
 #define P3D_RG_CDR_BIR_LTD1GENMASK(28, 24)
 #define P3D_RG_CDR_BIR_LTD1_VAL(x) ((0x1f & (x)) << 

[RESEND PATCH v5 3/3] perf tool: add cgroup identifier entry in perf report

2017-01-17 Thread Hari Bathini
This patch introduces a cgroup identifier entry field in perf report to
identify or distinguish data of different cgroups. It uses the device
number and inode number of cgroup namespace, included in perf data with
the new PERF_RECORD_NAMESPACES event, as cgroup identifier. With the
assumption that each container is created with it's own cgroup namespace,
this allows assessment/analysis of multiple containers at once.

Shown below is the output of perf report, sorted based on cgroup id, on
a system that was running three containers at the time of perf record
and clearly showing one of the containers' considerable use of kernel
memory in comparison with others:


$ perf report -s cgroup_id,sample --stdio
#
# Total Lost Samples: 0
#
# Samples: 2K of event 'kmem:kmalloc'
# Event count (approx.): 2176
#
# Overhead  cgroup id (dev/inode)   Samples
#   .  
#
89.20%  3/0xf0cf   1941
 3.31%  3/0xeffb 72
 3.08%  3/0xf0d0 67
 2.25%  3/0xf0d1 49
 2.16%  0/0x047

Signed-off-by: Hari Bathini 
---

* No changes since v4.


 tools/perf/util/hist.c |7 +++
 tools/perf/util/hist.h |1 +
 tools/perf/util/sort.c |   41 +
 tools/perf/util/sort.h |7 +++
 4 files changed, 56 insertions(+)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 6770a96..9996e0c 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -2,6 +2,7 @@
 #include "build-id.h"
 #include "hist.h"
 #include "session.h"
+#include "namespaces.h"
 #include "sort.h"
 #include "evlist.h"
 #include "evsel.h"
@@ -168,6 +169,7 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
hists__set_unres_dso_col_len(hists, HISTC_MEM_DADDR_DSO);
}
 
+   hists__new_col_len(hists, HISTC_CGROUP_ID, 20);
hists__new_col_len(hists, HISTC_CPU, 3);
hists__new_col_len(hists, HISTC_SOCKET, 6);
hists__new_col_len(hists, HISTC_MEM_LOCKED, 6);
@@ -573,9 +575,14 @@ __hists__add_entry(struct hists *hists,
   bool sample_self,
   struct hist_entry_ops *ops)
 {
+   struct namespaces *ns = thread__namespaces(al->thread);
struct hist_entry entry = {
.thread = al->thread,
.comm = thread__comm(al->thread),
+   .cgroup_id = {
+   .dev = ns ? ns->link_info[CGROUP_NS_INDEX].dev : 0,
+   .ino = ns ? ns->link_info[CGROUP_NS_INDEX].ino : 0,
+   },
.ms = {
.map= al->map,
.sym= al->sym,
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index d4b6514..d7696fd 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -30,6 +30,7 @@ enum hist_column {
HISTC_DSO,
HISTC_THREAD,
HISTC_COMM,
+   HISTC_CGROUP_ID,
HISTC_PARENT,
HISTC_CPU,
HISTC_SOCKET,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index df622f4..9f5f404 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -536,6 +536,46 @@ struct sort_entry sort_cpu = {
.se_width_idx   = HISTC_CPU,
 };
 
+/* --sort cgroup_id */
+
+static int64_t _sort__cgroup_dev_cmp(u64 left_dev, u64 right_dev)
+{
+   return (int64_t)(right_dev - left_dev);
+}
+
+static int64_t _sort__cgroup_inode_cmp(u64 left_ino, u64 right_ino)
+{
+   return (int64_t)(right_ino - left_ino);
+}
+
+static int64_t
+sort__cgroup_id_cmp(struct hist_entry *left, struct hist_entry *right)
+{
+   int64_t ret;
+
+   ret = _sort__cgroup_dev_cmp(right->cgroup_id.dev, left->cgroup_id.dev);
+   if (ret != 0)
+   return ret;
+
+   return _sort__cgroup_inode_cmp(right->cgroup_id.ino,
+  left->cgroup_id.ino);
+}
+
+static int hist_entry__cgroup_id_snprintf(struct hist_entry *he,
+ char *bf, size_t size,
+ unsigned int width __maybe_unused)
+{
+   return repsep_snprintf(bf, size, "%lu/0x%lx", he->cgroup_id.dev,
+  he->cgroup_id.ino);
+}
+
+struct sort_entry sort_cgroup_id = {
+   .se_header  = "cgroup id (dev/inode)",
+   .se_cmp = sort__cgroup_id_cmp,
+   .se_snprintf= hist_entry__cgroup_id_snprintf,
+   .se_width_idx   = HISTC_CGROUP_ID,
+};
+
 /* --sort socket */
 
 static int64_t
@@ -1418,6 +1458,7 @@ static struct sort_dimension common_sort_dimensions[] = {
DIM(SORT_GLOBAL_WEIGHT, "weight", sort_global_weight),
DIM(SORT_TRANSACTION, "transaction", sort_transaction),

Re: [RESEND PATCHv1 0/8] mmc: sdhci-msm: Provide support for enhanced strobe

2017-01-17 Thread Ritesh Harjani



On 1/17/2017 6:37 AM, Jeremy McNicoll wrote:

On Tue, Jan 10, 2017 at 12:30:44PM +0530, Ritesh Harjani wrote:

Hi,

Resending this patch series, as no one could review it -possibly due to
holidays during that time.

This patch series mainly provides enhanced strobe support to sdhci-msm driver
along with some additions of HW recommended sequence. This has been tested on
8996 based internal target & on db410c.

Patches 1-3 :- Factors out few functions to be re-used again.
   To also simplify large functions and makes it more readable.

Patches 4-5 :- Few recommendations based on HW prog. guide.

Patches 6 :- Clear SDHCI_HS400_TUNING flag after platform_execute_tuning
 so that ->platform_execute_tuning (underlying platform driver) can
 know about HS400 tuning.

Patch 7 :- Implements an additional step as per HPG for HS400 tuning.

Patch 8 :- Implements enhanced strobe functionality in sdhci-msm driver.




I have included this series in my tree while testing my SDHCI V2 series.

One message did occur which looks new or unfamilar and relatively
harmless,

"sdhci_msm f9824900.mmc: TCXO clk not present (-2) "

This should be ok.



Is that something I am missing on my side?

You should provide this in your DT.
@@ -463,8 +463,9 @@
interrupts = <0 141 0>, <0 134 0>;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC1_APPS_CLK>,
-< GCC_SDCC1_AHB_CLK>;
-   clock-names = "core", "iface";
+< GCC_SDCC1_AHB_CLK>,
+<_board>;
+   clock-names = "core", "iface", "xo";





In anycase,

Tested-by: Jeremy McNicoll 

Thanks for testing this series.

Hi Adrian/Ulf,
In case if we dont have any other comments, can we please include this 
series in next ?



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


[PATCH] mm/memblock.c: remove unnecessary log and clean up

2017-01-17 Thread Miles Chen
There is no variable named flags in memblock_add() and memblock_reserve()
so remove it from the log messages.
This patch also cleans up the type casting for phys_addr_t by using
%pa to print them.

Signed-off-by: Miles Chen 
---
 mm/memblock.c | 54 +-
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..8683f02 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -611,10 +611,10 @@ int __init_memblock memblock_add_node(phys_addr_t base, 
phys_addr_t size,
 
 int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("memblock_add: [%#016llx-%#016llx] flags %#02lx %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-0UL, (void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("memblock_add: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
return memblock_add_range(, base, size, MAX_NUMNODES, 
0);
 }
@@ -718,10 +718,10 @@ int __init_memblock memblock_remove(phys_addr_t base, 
phys_addr_t size)
 
 int __init_memblock memblock_free(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("   memblock_free: [%#016llx-%#016llx] %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-(void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("   memblock_free: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
kmemleak_free_part_phys(base, size);
return memblock_remove_range(, base, size);
@@ -729,10 +729,10 @@ int __init_memblock memblock_free(phys_addr_t base, 
phys_addr_t size)
 
 int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("memblock_reserve: [%#016llx-%#016llx] flags %#02lx %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-0UL, (void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("memblock_reserve: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
return memblock_add_range(, base, size, MAX_NUMNODES, 
0);
 }
@@ -1202,8 +1202,8 @@ phys_addr_t __init memblock_alloc_base(phys_addr_t size, 
phys_addr_t align, phys
alloc = __memblock_alloc_base(size, align, max_addr);
 
if (alloc == 0)
-   panic("ERROR: Failed to allocate 0x%llx bytes below 0x%llx.\n",
- (unsigned long long) size, (unsigned long long) max_addr);
+   panic("ERROR: Failed to allocate %pa bytes below %pa.\n",
+ , _addr);
 
return alloc;
 }
@@ -1673,7 +1673,7 @@ phys_addr_t __init_memblock 
memblock_get_current_limit(void)
 
 static void __init_memblock memblock_dump(struct memblock_type *type, char 
*name)
 {
-   unsigned long long base, size;
+   phys_addr_t base, end, size;
unsigned long flags;
int idx;
struct memblock_region *rgn;
@@ -1685,23 +1685,24 @@ static void __init_memblock memblock_dump(struct 
memblock_type *type, char *name
 
base = rgn->base;
size = rgn->size;
+   end = base + size - 1;
flags = rgn->flags;
 #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
if (memblock_get_region_node(rgn) != MAX_NUMNODES)
snprintf(nid_buf, sizeof(nid_buf), " on node %d",
 memblock_get_region_node(rgn));
 #endif
-   pr_info(" %s[%#x]\t[%#016llx-%#016llx], %#llx bytes%s flags: 
%#lx\n",
-   name, idx, base, base + size - 1, size, nid_buf, flags);
+   pr_info(" %s[%#x]\t[%pa-%pa], %pa bytes%s flags: %#lx\n",
+   name, idx, , , , nid_buf, flags);
}
 }
 
 void __init_memblock __memblock_dump_all(void)
 {
pr_info("MEMBLOCK configuration:\n");
-   pr_info(" memory size = %#llx reserved size = %#llx\n",
-   (unsigned long long)memblock.memory.total_size,
-   (unsigned long long)memblock.reserved.total_size);
+   pr_info(" memory size = %pa reserved size = %pa\n",
+   _size,
+   _size);
 
memblock_dump(, "memory");
memblock_dump(, "reserved");
@@ -1727,19 +1728,14 @@ static int memblock_debug_show(struct seq_file *m, void 
*private)
struct memblock_type *type = m->private;
struct memblock_region *reg;
int i;
+   phys_addr_t end;
 
for (i = 0; i < type->cnt; i++) {
reg = >regions[i];
-   seq_printf(m, "%4d: ", i);
-   if (sizeof(phys_addr_t) == 4)
-   seq_printf(m, "0x%08lx..0x%08lx\n",
-  (unsigned long)reg->base,
-   

Re: [RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

2017-01-17 Thread Ritesh Harjani

Hi Shawn,

On 1/10/2017 2:45 PM, Shawn Lin wrote:

On 2017/1/10 14:41, Ritesh Harjani wrote:

From: Sahitya Tummala 

Add new host operation ->platform_dumpregs to provide a
mechanism through which host drivers can dump platform
specific registers in addition to SDHC registers
during error conditions.



Although we have been preventing from adding new callback
for sdhci core, this one makes sense as there are more and more
vendor registers outside the scope of SDHCI spec.

Sure thanks, shall I add your Reviewed-by on this patch 1/3.
Would you be able to review other as well?



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


Re: [PATCH v2 02/10] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig

2017-01-17 Thread Mylene Josserand

Hi,

On 17/01/2017 17:44, Maxime Ripard wrote:

Hi,

On Tue, Jan 17, 2017 at 03:02:22PM +0100, Mylène Josserand wrote:

The audio DAI needs to set the clock rates of the ac-dig clock.
To make it possible, the parent PLL audio clock rates should
also be changed. This is possible via "CLK_SET_RATE_PARENT" flag.

Signed-off-by: Mylène Josserand 


Please make sure to look at the prefixes usually used in the commit
titles of the area you're working on. In this case that would have
been "clk: sunxi-ng:". I fixed it, and applied.


Okay, I will pay more attention to prefixes for commit titles for next 
times.


Thank you !

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


RE: [PATCHv2] firmware: Correct handling of fw_state_wait_timeout() return value

2017-01-17 Thread linux-kernel-dev
>From: Jakub Kicinski [mailto:jakub.kicin...@netronome.com]
>Sent: Dienstag, 17. Januar 2017 22:18
>
>On Tue, Jan 17, 2017 at 12:53 PM, Luis R. Rodriguez 
>wrote:
>> On Tue, Jan 17, 2017 at 10:04:20AM -0800, Jakub Kicinski wrote:
>>> On Tue, Jan 17, 2017 at 9:30 AM, Luis R. Rodriguez 
>wrote:
>>> > On Tue, Jan 17, 2017 at 08:30:37AM -0800, Jakub Kicinski wrote:
>>> >> Adding a NULL-check would just paper over the
>>> >> issue and can cause trouble down the line.
>>> >
>>> > We typically bail on errors and use similar code to bail out, and we
>>> > typically do these things. Here its no different. The *real* issue
>>> > is the fact that we have a waiting timeout which can fail race against
>>> > a user imposed error out on the sysfs interface. There is one catch:
>>> >
>>> > We already lock with the big fw_lock and use this to be able to check
>>> > for the status of the fw, so once aborted we technically should not have
>>> > to abort again. A proper way to address then this would have been to
>check
>>> > for the status of the fw prior to aborting again given we also lock on the
>>> > big fw_lock. A problem with this though is the status is part of the buf
>>> > which is set to NULL after we are done aborting.
>>>
>>> Yes, I've seen that too :\  This race seems to have been there prior
>>> to 4.9, though.  I guess we could fix both issues with the NULL-check
>>> although I would prefer if we had both patches.
>>>
>>> FWIW I think the NULL-check could be put in the existing conditional:
>>>
>>>  * There is a small window in which user can write to 'loading'
>>>  * between loading done and disappearance of 'loading'
>>>  */
>>> -   if (fw_state_is_done(>fw_st))
>>> +   if (!buf || fw_state_is_done(>fw_st))
>>> return;
>>>
>>> list_del_init(>pending_list);
>>>
>>> Note that the comment above seems to be mentioning the race we're
>>> trying to solve.
>>
>> Right, I think another approach is to *enable* the state of the buf
>> to be used to avoid further use on the sysfs iterface instead. Fortunately
>> other sysfs interfaces already use fw_state_is_done() to bail out,
>> so all that would be needed I think would be:
>>
>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> index b9ac348e8d33..30ccf7aea3ca 100644
>> --- a/drivers/base/firmware_class.c
>> +++ b/drivers/base/firmware_class.c
>> @@ -558,9 +558,6 @@ static void fw_load_abort(struct firmware_priv
>*fw_priv)
>> struct firmware_buf *buf = fw_priv->buf;
>>
>> __fw_load_abort(buf);
>> -
>> -   /* avoid user action after loading abort */
>> -   fw_priv->buf = NULL;
>>  }
>>
>>  static LIST_HEAD(pending_fw_head);
>> @@ -713,7 +710,7 @@ static ssize_t firmware_loading_store(struct device
>*dev,
>>
>> mutex_lock(_lock);
>> fw_buf = fw_priv->buf;
>> -   if (!fw_buf)
>> +   if (!fw_buf || fw_state_is_aborted(_buf->fw_st))
>> goto out;
>>
>> switch (loading) {
>
>IMHO this one is nice!  I think you can even drop the !fw_buf check in
>this case because AFAICS the only case where fw_buf is set to NULL is
>in the abort function.
>
I can confirm, that patch looks nice and is working for my setup, even without 
the !fw_buf. 
Feel free to grab everything you need from my commit log, if it helps.
Unfortunately there is a crazy spam filter between us, so you can't rely on me.
 


Re: [PATCH] ARM: dts: sun6i: sina31s: Enable USB OTG controller in peripheral mode

2017-01-17 Thread Maxime Ripard
On Wed, Jan 18, 2017 at 09:01:05AM +0800, Chen-Yu Tsai wrote:
> While the SinA31s does have a proper 5-pin mini USB OTG port, the ID
> pin does not seem to work. The pin used in the schematics is always low,
> regardless of the attached OTG cable or SoC internal pin bias settings.
> 
> The v1.5 board is missing bias resistors shown in the schematics for
> earlier revisions, and the connections of the remaining one does not
> match the schematics either.
> 
> In addition, VBUS for this port is disconnected from the board's 5V
> power rail. The board features a pad to solder jumper pins to connect
> VBUS to 5V manually.
> 
> Given the above and the fact that the board has 5 more USB host ports,
> it makes more sense to have the OTG port work in peripheral mode.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

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


signature.asc
Description: PGP signature


Re: [PATCH v5 0/4] usb: early: add support for early printk through USB3 debug port

2017-01-17 Thread Lu Baolu
Hi Greg,

This patch series has been there for 2 months without
further comments. Will you consider it for usb-next?

Best regards,
Lu Baolu

On 11/15/2016 02:02 PM, Lu Baolu wrote:
> xHCI debug capability (DbC) is an optional but standalone
> functionality provided by an xHCI host controller. With DbC
> hardware initialized, the system will present a debug device
> through the USB3 debug port (normally the first USB3 port).
> The debug device is fully compliant with the USB framework
> and provides the equivalent of a very high performance (USB3)
> full-duplex serial link between the debug host and target.
> The DbC functionality is independent of xHCI host. There
> isn't any precondition from xHCI host side for DbC to work.
>
> This patch set adds support for early printk functionality
> through a USB3 debug port by 1) initializing and enabling
> the DbC hardware during early boot; 2) registering a boot
> console to the system so that early printk messages can go
> through the USB3 debug port. It also includes some lines
> of changes in usb_debug driver so that it can be bound when
> a USB3 debug device is enumerated.
>
> This code is designed to be used only for kernel debugging
> when machine crashes very early before the console code is
> initialized. It makes the life of kernel debugging easier
> when people work with a modern machine without any legacy
> serial ports.
>
> ---
> Change log:
> v4->v5:
>   - add raw_spin_lock to make xdbc_bulk_write() reentrant. 
>
> v3->v4:
>   - Rename the document with .dst suffix.
>   - Add the list of hardware that has been succesfuly
> tested on in the document.
>
> v2->v3:
>   - Removed spinlock usage.
>   - Removed work queue usage.
>   - Refined the user guide document.
>
> v1->v2:
>   - Refactor the duplicate code in xdbc_early_start() and
> xdbc_handle_external_reset().
>   - Free resources when hardware not used any more.
>   - Refine the user guide document.
>
> Lu Baolu (4):
>   usb: dbc: early driver for xhci debug capability
>   x86: add support for earlyprintk via USB3 debug port
>   usb: serial: usb_debug: add support for dbc debug device
>   usb: doc: add document for USB3 debug port usage
>
>  Documentation/kernel-parameters.txt   |1 +
>  Documentation/usb/usb3-debug-port.rst |   95 +++
>  arch/x86/Kconfig.debug|   14 +
>  arch/x86/kernel/early_printk.c|5 +
>  arch/x86/kernel/setup.c   |7 +
>  drivers/usb/Kconfig   |3 +
>  drivers/usb/Makefile  |2 +-
>  drivers/usb/early/Makefile|1 +
>  drivers/usb/early/xhci-dbc.c  | 1068 
> +
>  drivers/usb/early/xhci-dbc.h  |  205 +++
>  drivers/usb/serial/usb_debug.c|   28 +-
>  include/linux/usb/xhci-dbgp.h |   22 +
>  12 files changed, 1447 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/usb/usb3-debug-port.rst
>  create mode 100644 drivers/usb/early/xhci-dbc.c
>  create mode 100644 drivers/usb/early/xhci-dbc.h
>  create mode 100644 include/linux/usb/xhci-dbgp.h
>



Re: [PATCH v4 15/15] lockdep: Crossrelease feature documentation

2017-01-17 Thread Boqun Feng
On Fri, Dec 09, 2016 at 02:12:11PM +0900, Byungchul Park wrote:
[...]
> +Example 1:
> +
> +   CONTEXT XCONTEXT Y
> +   --
> +   mutext_lock A
> +lock_page B
> +   lock_page B
> +mutext_lock A /* DEADLOCK */

s/mutext_lock/mutex_lock

> +   unlock_page B
> +mutext_unlock A
> +   mutex_unlock A
> +unlock_page B
> +
> +   where A is a lock class and B is a page lock.
> +
> +No, we cannot.
> +
> +Example 2:
> +
> +   CONTEXT XCONTEXT Y   CONTEXT Z
> +   --   --
> +mutex_lock A
> +   lock_page B
> +lock_page B
> +mutext_lock A /* DEADLOCK */
> +mutext_unlock A

Ditto.

> +unlock_page B held by X
> +unlock_page B
> +mutex_unlock A
> +
> +   where A is a lock class and B is a page lock.
> +
> +No, we cannot.
> +
> +Example 3:
> +
> +   CONTEXT XCONTEXT Y
> +   --
> +mutex_lock A
> +   mutex_lock A
> +   mutex_unlock A
> +wait_for_complete B /* DEADLOCK */

I think this part better be:

   CONTEXT X   CONTEXT Y
   -   -
   mutex_lock A
   mutex_lock A
   wait_for_complete B /* DEADLOCK */
   mutex_unlock A

, right? Because Y triggers DEADLOCK before X could run mutex_unlock().

Regards,
Boqun


signature.asc
Description: PGP signature


Re: [PATCH] printk: Correctly handle preemption in console_unlock()

2017-01-17 Thread Sergey Senozhatsky
On (01/16/17 12:00), Petr Mladek wrote:
[..]
> > Makes perfect sense to me. The only thing that worries me is that it
> > does change the logic slightly, and I'm not sure if this will have any
> > ramifications with it. That is, console_unlock() use to always leave
> > with console_may_schedule equal to zero, where console_unlock() clears
> > it. With this change, console_unlock() no longer clears that variable.
> > Will that have any side effects that we are unaware of?
> 
> Good question!

it does look a bit worrisome.

> If I get it correctly, the variable should never be used without the
> console semaphore. IMHO, if it was used without the semaphore or if
> it was not set correctly when the semaphore was taken, it would be a
> bug. It means that leaving the variable set might actually help
> to find a buggy usage if there is any.
> 
> My findings:
> 
>   + console_may_lock is set only by functions that get the console
> semaphore.
> 
>   + The function that takes the semaphore and does not set the
> variable is resume_console(). IMHO, it is a bug.
> 
> We are on the safe side because the function is called from
> the same context as suspend_console() and it allows rescheduling.
> 
> 
>   + I am not aware of any use of the variable without the
> semaphore. But it is not easy to prove just be reading
> the code.

there is a function that clears @console_may_schedule out of
console_sem scope - console_flush_on_panic().
so I *may be* can think about a worst case scenario of race
condition between
console_flush_on_panic()->console_may_schedule = 0 on panic CPU
and
console_unlock()->console_may_schedule = 1 from CPU that panic CPU
failed to stop (smp_send_stop() can return with secondary CPUs still being
online).

thoughts?

-ss


logical cpu number is discontinuity

2017-01-17 Thread Masayoshi Mizuma
Hi,

On v4.9 and v4.10 kernel, when I booted my box which has two nodes and
each nodes have 48 logical cpus (Hyper Threading is enabled),
the logical cpu number is discontinuity as follows.

node 0:  0-23, 256-279
node 1: 24-47, 280-303

So the following shell script fail to run.
---
#!/bin/bash

for ((cpu = 0; cpu < `nproc`; cpu++))
do
taskset -c $cpu ./do_work
done
---

I think the logical cpu number should be continuity like as v4.8 and earlier
because user applications may expect the number is continuity.

I believe this behavior was introduced by the patch series beginning with
the following commit.

f7c2883 x86/acpi: Enable acpi to register all possible cpus at boot time

Do anyone have ideas for fix this behavior...?

FYI.
v4.8 kernel, the logical cpu number is continuity as follows.

node 0:  0-23, 48-71
node 1: 24-47, 72-95

- Masayoshi Mizuma


[PATCH 2/6] usb: mtu3: add reference clock

2017-01-17 Thread Chunfeng Yun
usually, the reference clock comes from 26M oscillator directly,
but some SoCs are not, add it for compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3.h  |1 +
 drivers/usb/mtu3/mtu3_plat.c |   21 +++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index ba9df71..aa6fd6a 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -225,6 +225,7 @@ struct ssusb_mtk {
/* common power & clock */
struct regulator *vusb33;
struct clk *sys_clk;
+   struct clk *ref_clk;
/* otg */
struct otg_switch_mtk otg_switch;
enum usb_dr_mode dr_mode;
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 6344859..19a345d 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -123,7 +123,13 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
ret = clk_prepare_enable(ssusb->sys_clk);
if (ret) {
dev_err(ssusb->dev, "failed to enable sys_clk\n");
-   goto clk_err;
+   goto sys_clk_err;
+   }
+
+   ret = clk_prepare_enable(ssusb->ref_clk);
+   if (ret) {
+   dev_err(ssusb->dev, "failed to enable ref_clk\n");
+   goto ref_clk_err;
}
 
ret = ssusb_phy_init(ssusb);
@@ -143,8 +149,10 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
 phy_err:
ssusb_phy_exit(ssusb);
 phy_init_err:
+   clk_disable_unprepare(ssusb->ref_clk);
+ref_clk_err:
clk_disable_unprepare(ssusb->sys_clk);
-clk_err:
+sys_clk_err:
regulator_disable(ssusb->vusb33);
 vusb33_err:
 
@@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
 static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
 {
clk_disable_unprepare(ssusb->sys_clk);
+   clk_disable_unprepare(ssusb->ref_clk);
regulator_disable(ssusb->vusb33);
ssusb_phy_power_off(ssusb);
ssusb_phy_exit(ssusb);
@@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->sys_clk);
}
 
+   ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
+   if (IS_ERR(ssusb->ref_clk)) {
+   dev_err(dev, "failed to get ref clock\n");
+   return PTR_ERR(ssusb->ref_clk);
+   }
+
ssusb->num_phys = of_count_phandle_with_args(node,
"phys", "#phy-cells");
if (ssusb->num_phys > 0) {
@@ -428,6 +443,7 @@ static int __maybe_unused mtu3_suspend(struct device *dev)
ssusb_host_disable(ssusb, true);
ssusb_phy_power_off(ssusb);
clk_disable_unprepare(ssusb->sys_clk);
+   clk_disable_unprepare(ssusb->ref_clk);
ssusb_wakeup_enable(ssusb);
 
return 0;
@@ -445,6 +461,7 @@ static int __maybe_unused mtu3_resume(struct device *dev)
 
ssusb_wakeup_disable(ssusb);
clk_prepare_enable(ssusb->sys_clk);
+   clk_prepare_enable(ssusb->ref_clk);
ssusb_phy_power_on(ssusb);
ssusb_host_enable(ssusb);
 
-- 
1.7.9.5



[PATCH 4/6] arm64: dts: mt8173: add reference clock for usb

2017-01-17 Thread Chunfeng Yun
add 26M reference clock for ssusb and xhci nodes

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 07fd2eb..e2862b6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -729,9 +729,11 @@
   < PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
+<>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
clock-names = "sys_ck",
+ "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
mediatek,syscon-wakeup = <>;
@@ -746,8 +748,8 @@
reg-names = "mac";
interrupts = ;
power-domains = < 
MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, 
<>;
+   clock-names = "sys_ck", "ref_ck";
status = "disabled";
};
};
-- 
1.7.9.5



[PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock

2017-01-17 Thread Chunfeng Yun
add a reference clock for compatibility

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index 2a930bd..ab8bb27 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -23,6 +23,7 @@ Required properties:
entry in clock-names
  - clock-names : must contain
"sys_ck": for clock of xHCI MAC
+   "ref_ck": for reference clock of xHCI MAC
"wakeup_deb_p0": for USB wakeup debounce clock of port0
"wakeup_deb_p1": for USB wakeup debounce clock of port1
 
@@ -47,10 +48,10 @@ usb30: usb@1127 {
reg-names = "mac", "ippc";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>,
+   clocks = < CLK_TOP_USB30_SEL>, <>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
-   clock-names = "sys_ck",
+   clock-names = "sys_ck", "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
phys = <_port0 PHY_TYPE_USB3>,
@@ -82,6 +83,7 @@ Required properties:
entry in clock-names
  - clock-names : must be
"sys_ck": for clock of xHCI MAC
+   "ref_ck": for reference clock of xHCI MAC
 
 Optional properties:
  - vbus-supply : reference to the VBUS regulator;
@@ -94,8 +96,8 @@ usb30: usb@1127 {
reg-names = "mac";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, <>;
+   clock-names = "sys_ck", "ref_ck";
vusb33-supply = <_vusb_reg>;
usb3-lpm-capable;
 };
-- 
1.7.9.5



[PATCH 1/6] usb: mtu3: get resources that cause deferred probe earlier

2017-01-17 Thread Chunfeng Yun
Some resources such as regulator, clock usually cause deferred
probe, get them earlier to avoid more ineffective processing.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_plat.c |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 7833678..6344859 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -204,6 +204,18 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
int i;
int ret;
 
+   ssusb->vusb33 = devm_regulator_get(>dev, "vusb33");
+   if (IS_ERR(ssusb->vusb33)) {
+   dev_err(dev, "failed to get vusb33\n");
+   return PTR_ERR(ssusb->vusb33);
+   }
+
+   ssusb->sys_clk = devm_clk_get(dev, "sys_ck");
+   if (IS_ERR(ssusb->sys_clk)) {
+   dev_err(dev, "failed to get sys clock\n");
+   return PTR_ERR(ssusb->sys_clk);
+   }
+
ssusb->num_phys = of_count_phandle_with_args(node,
"phys", "#phy-cells");
if (ssusb->num_phys > 0) {
@@ -230,18 +242,6 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->ippc_base);
}
 
-   ssusb->vusb33 = devm_regulator_get(>dev, "vusb33");
-   if (IS_ERR(ssusb->vusb33)) {
-   dev_err(dev, "failed to get vusb33\n");
-   return PTR_ERR(ssusb->vusb33);
-   }
-
-   ssusb->sys_clk = devm_clk_get(dev, "sys_ck");
-   if (IS_ERR(ssusb->sys_clk)) {
-   dev_err(dev, "failed to get sys clock\n");
-   return PTR_ERR(ssusb->sys_clk);
-   }
-
ssusb->dr_mode = usb_get_dr_mode(dev);
if (ssusb->dr_mode == USB_DR_MODE_UNKNOWN) {
dev_err(dev, "dr_mode is error\n");
-- 
1.7.9.5



[PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock

2017-01-17 Thread Chunfeng Yun
add a reference clock for compatibility

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-mtu3.txt|   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
index e049d19..8c976cd 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -10,7 +10,7 @@ Required properties:
  - vusb33-supply : regulator of USB avdd3.3v
  - clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
- - clock-names : must contain "sys_ck" for clock of controller;
+ - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
"wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
depends on "mediatek,enable-wakeup"
  - phys : a list of phandle + phy specifier pairs
@@ -56,10 +56,10 @@ ssusb: usb@11271000 {
phys = <_port0 PHY_TYPE_USB3>,
   <_port1 PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>,
+   clocks = < CLK_TOP_USB30_SEL>, <>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
-   clock-names = "sys_ck",
+   clock-names = "sys_ck", "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
vusb33-supply = <_vusb_reg>;
@@ -79,8 +79,8 @@ ssusb: usb@11271000 {
reg-names = "mac";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, <>;
+   clock-names = "sys_ck", "ref_ck";
vusb33-supply = <_vusb_reg>;
status = "disabled";
};
-- 
1.7.9.5



[PATCH 3/6] usb: xhci-mtk: add reference clock

2017-01-17 Thread Chunfeng Yun
usually, the reference clock comes from 26M oscillator directly,
but some SoCs are not, add it for compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   15 +++
 drivers/usb/host/xhci-mtk.h |1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 1094ebd..4d75ac5 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -212,6 +212,12 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
 {
int ret;
 
+   ret = clk_prepare_enable(mtk->ref_clk);
+   if (ret) {
+   dev_err(mtk->dev, "failed to enable ref_clk\n");
+   goto ref_clk_err;
+   }
+
ret = clk_prepare_enable(mtk->sys_clk);
if (ret) {
dev_err(mtk->dev, "failed to enable sys_clk\n");
@@ -238,6 +244,8 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
 usb_p0_err:
clk_disable_unprepare(mtk->sys_clk);
 sys_clk_err:
+   clk_disable_unprepare(mtk->ref_clk);
+ref_clk_err:
return -EINVAL;
 }
 
@@ -248,6 +256,7 @@ static void xhci_mtk_clks_disable(struct xhci_hcd_mtk *mtk)
clk_disable_unprepare(mtk->wk_deb_p0);
}
clk_disable_unprepare(mtk->sys_clk);
+   clk_disable_unprepare(mtk->ref_clk);
 }
 
 /* only clocks can be turn off for ip-sleep wakeup mode */
@@ -550,6 +559,12 @@ static int xhci_mtk_probe(struct platform_device *pdev)
return PTR_ERR(mtk->sys_clk);
}
 
+   mtk->ref_clk = devm_clk_get(dev, "ref_ck");
+   if (IS_ERR(mtk->ref_clk)) {
+   dev_err(dev, "fail to get ref_ck\n");
+   return PTR_ERR(mtk->ref_clk);
+   }
+
mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
 
ret = usb_wakeup_of_property_parse(mtk, node);
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 2845c49..3aa5e1d 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -124,6 +124,7 @@ struct xhci_hcd_mtk {
struct regulator *vusb33;
struct regulator *vbus;
struct clk *sys_clk;/* sys and mac clock */
+   struct clk *ref_clk;
struct clk *wk_deb_p0;  /* port0's wakeup debounce clock */
struct clk *wk_deb_p1;
struct regmap *pericfg;
-- 
1.7.9.5



[PATCH] arm64: dts: exynos: Remove address node from usb parent node

2017-01-17 Thread Pankaj Dubey
Address node does not required to be put after parent't node,
so remove address node from usb parent node.

Signed-off-by: Pankaj Dubey 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e..0d7a55d 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1285,7 +1285,7 @@
status = "disabled";
};
 
-   usbdrd30: usb@1540  {
+   usbdrd30: usb3-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <_fsys CLK_ACLK_USBDRD30>,
<_fsys CLK_SCLK_USBDRD30>;
@@ -1332,7 +1332,7 @@
status = "disabled";
};
 
-   usbhost30: usb@15a0 {
+   usbhost30: usbhost3-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <_fsys CLK_ACLK_USBHOST30>,
<_fsys CLK_SCLK_USBHOST30>;
-- 
2.7.4



[PATCH v2 3/3] clk: rockchip: rk3288: make all niu clocks critical

2017-01-17 Thread Jacob Chen
NIU clocks are related to the interconnect and it's important to other blocks.
Since we don't have a driver to handle it, we should always enable it to avoid
casually close.

Make all of them critical,so that we don't have to each clock on its own
once things break.

Signed-off-by: Jacob Chen 
---
 drivers/clk/rockchip/clk-rk3288.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 3d02aa2..c50386c 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -808,8 +808,15 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
 static const char *const rk3288_critical_clocks[] __initconst = {
"aclk_cpu",
"aclk_peri",
+   "aclk_peri_niu",
+   "aclk_vio0_niu",
+   "aclk_vio1_niu",
+   "aclk_rga_niu",
"hclk_peri",
+   "hclk_vio_niu",
+   "pclk_alive_niu",
"pclk_pd_pmu",
+   "pclk_pmu_niu",
 };
 
 static void __iomem *rk3288_cru_base;
-- 
2.7.4



[PATCH v2 tip/core/rcu 07/18] rcu: Add long-term CPU kicking

2017-01-17 Thread Paul E. McKenney
Commit d2db185bfee8 ("rcu: Remove short-term CPU kicking") removed
frequent calls to resched_cpu(), which means that the only time
resched_cpu() is invoked is after an RCU CPU stall warning.  Although
this is good from an avoid-IPIs perspective, we should try to break
things loose -before- splatting.  This commit therefore starts invoking
resched_cpu() for each holdout at each force-quiescent-state interval
that is more than halfway through the stall-warning interval.

Signed-off-by: Paul E. McKenney 
---
 kernel/rcu/tree.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 83bf054e194e..0e61b62e3f4a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1225,6 +1225,12 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
 rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
+   /*
+* If more than halfway to RCU CPU stall-warning time, do
+* a resched_cpu() to try to loosen things up a bit.
+*/
+   if (jiffies - rdp->rsp->gp_start > rcu_jiffies_till_stall_check() / 2)
+   resched_cpu(rdp->cpu);
 
return 0;
 }
-- 
2.5.2



[PATCH v2 tip/core/rcu 05/18] rcu: Remove unneeded rcu_process_callbacks() declarations

2017-01-17 Thread Paul E. McKenney
The declarations of __rcu_process_callbacks() and rcu_process_callbacks()
are not needed, as the definition of both of these functions appear before
any uses.  This commit therefore removes both declarations.

Reported-by: "Ahmed, Iftekhar" 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett 
---
 kernel/rcu/tiny.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index b23a4d076f3d..fa6a48d3917b 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -41,8 +41,6 @@
 
 /* Forward declarations for tiny_plugin.h. */
 struct rcu_ctrlblk;
-static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp);
-static void rcu_process_callbacks(struct softirq_action *unused);
 static void __call_rcu(struct rcu_head *head,
   rcu_callback_t func,
   struct rcu_ctrlblk *rcp);
-- 
2.5.2



Re: [PATCH tip/core/rcu 11/20] sched,rcu: Make cond_resched() provide RCU quiescent state

2017-01-17 Thread Paul E. McKenney
On Tue, Jan 17, 2017 at 01:11:46PM +0100, Michal Hocko wrote:
> On Tue 17-01-17 04:05:13, Paul E. McKenney wrote:
> > On Tue, Jan 17, 2017 at 11:51:41AM +0100, Michal Hocko wrote:
> > > On Mon 16-01-17 16:54:03, Paul E. McKenney wrote:
> > > > On Mon, Jan 16, 2017 at 06:11:30PM +0100, Peter Zijlstra wrote:
> > > > > On Sat, Jan 14, 2017 at 01:13:12AM -0800, Paul E. McKenney wrote:
> > > > > > There is some confusion as to which of cond_resched() or
> > > > > > cond_resched_rcu_qs() should be added to long in-kernel loops.
> > > > > > This commit therefore eliminates the decision by adding RCU
> > > > > > quiescent states to cond_resched().
> > > > > 
> > > > > Which would make: rcu_read_lock(); cond_resched(); rcu_read_unlock();
> > > > > invalid under preemptible RCU. Is it already?
> > > > 
> > > > In theory, yes.  In practice, I just tested it with preemption and
> > > > lockdep enabled, and it didn't complain.  If further testing finds
> > > > complaints, we can either fix those uses (preferred) or revert
> > > > this patch.
> > > > 
> > > > > > Warning: This is a prototype.  For example, it does not correctly
> > > > > > handle Tasks RCU.  Which is OK for the moment, given that no one
> > > > > > actually uses Tasks RCU yet.
> > > > > 
> > > > > > --- a/kernel/sched/core.c
> > > > > > +++ b/kernel/sched/core.c
> > > > > > @@ -4907,6 +4907,7 @@ int __sched _cond_resched(void)
> > > > > > preempt_schedule_common();
> > > > > > return 1;
> > > > > > }
> > > > > > +   rcu_all_qs();
> > > > > > return 0;
> > > > > >  }
> > > > > 
> > > > > Still not a real fan of this, it does make cond_resched() touch a 
> > > > > bunch
> > > > > more cachelines, also, I suppose that if we're going to do this, we
> > > > > should make __cond_resched_lock() and __cond_resched_softirq() act
> > > > > similarly.
> > > > 
> > > > Michal (now CCed) argues that having to distinguish between 
> > > > cond_resched()
> > > > and cond_resched_rcu_qs() is overly burdensome.  Michal?
> > > 
> > > Yes, it is really not clear which one is meant to be in which context. I
> > > really do not see which cond_resched should be turned intto
> > > cond_resched_rcu_qs.
> > > 
> > > > Any thoughts on how we might remove this burden without the additional
> > > > cache misses?  I will take another look as well to see what could make
> > > > it lower cost.  There are probably ways...  Would it make sense to
> > > > have RCU maintain a need-rcu_all_qs() flage in the same cacheline as
> > > > the __preempt_count?  Perhaps throttling the writes to this flag from
> > > > the RCU grace-period kthreads to once per 100 milliseconds or so?
> > > 
> > > Can the stall detector simply request rescheduling when it gets
> > > dangerously close to the timeout?
> > 
> > It is quite possible that half of the stall timeout would be a better
> > choice than my 100 milliseconds, but either way, there would be need
> > for a flag or some such.
> 
> E.g. set_tsk_need_resched() on the task currently running on a cpu which
> is preventing the rcu grace period for too long?
> 
> That would only require change to the stall detector and the cond_resched
> could be left alone completely.

Thank you!!!

The other complication is that under CONFIG_PREEMPT=y, _cond_resched()
is an empty function.  That would be one reason why use of cond_resched()
wasn't always giving RCU the quiescent states that it needs.  And that
is a problem with this patch, which I therefore need to defer to 4.12.

That aside, the reason I am reluctant to use the need-resched approach
except as an emergency measure is that the way I have to set that bit
remotely involves IPIs.

But don't get me wrong, it is extremely useful as an emergency meaure.
I am just trying to get cond_resched() to help on a non-emergency basis.

Thanx, Paul



Re: [PATCHSET v2] slab: make memcg slab destruction scalable

2017-01-17 Thread Joonsoo Kim
On Tue, Jan 17, 2017 at 08:49:13AM -0800, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 17, 2017 at 09:12:57AM +0900, Joonsoo Kim wrote:
> > Could you confirm that your series solves the problem that is reported
> > by Doug? It would be great if the result is mentioned to the patch
> > description.
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=172991
> 
> So, that's an issue in the creation path which is already resolved by
> switching to an ordered workqueue (it'd probably be better to use
> per-cpu wq w/ @max_active == 1 tho).  This patchset is about relesae
> path.  slab_mutex contention would definitely go down with this but
> I don't think there's more connection to it than that.

That problem is caused by slow release path and then contention on the
slab_mutex. With an ordered workqueue, kworker would not be created a
lot but it can be possible that a lot of work items to create a new
cache for memcg is pending for a long time due to slow release path.

Your patchset replaces optimization for release path so it's better to
check that the work isn't pending for a long time in above workload.

Thanks.


[RESEND PATCH 5/6] arm64: dts: mt8173: split usb SuperSpeed port into two ports

2017-01-17 Thread Chunfeng Yun
split the old SuperSpeed port node into a HighSpeed one and a new
SuperSpeed one.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 5d1663b..07fd2eb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -724,8 +724,9 @@
  <0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
interrupts = ;
-   phys = <_port0 PHY_TYPE_USB3>,
-  <_port1 PHY_TYPE_USB2>;
+   phys = < PHY_TYPE_USB2>,
+  < PHY_TYPE_USB3>,
+  < PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
 < CLK_PERI_USB0>,
@@ -761,14 +762,20 @@
ranges;
status = "okay";
 
-   phy_port0: port@11290800 {
-   reg = <0 0x11290800 0 0x800>;
+   u2port0: port@11290800 {
+   reg = <0 0x11290800 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
 
-   phy_port1: port@11291000 {
-   reg = <0 0x11291000 0 0x800>;
+   u3port0: port@11290900 {
+   reg = <0 0x11290900 0 0x700>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   u2port1: port@11291000 {
+   reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
-- 
1.7.9.5



[RESEND PATCH 3/6] phy: phy-mt65xx-usb3: add support for mt2712 platform

2017-01-17 Thread Chunfeng Yun
There are some variations from mt2701 to mt2712:
1. banks shared by multiple ports are put back into each port,
such as SPLLC and U2FREQ;
2. add a new bank MISC for u2port, and CHIP for u3port;
3. bank's offset in each port are also rearranged;

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |  326 ++---
 1 file changed, 208 insertions(+), 118 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index c187a3b..d515c69 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -23,46 +23,54 @@
 #include 
 #include 
 
-/*
- * for sifslv2 register, but exclude port's;
- * relative to USB3_SIF2_BASE base address
- */
-#define SSUSB_SIFSLV_SPLLC 0x
-#define SSUSB_SIFSLV_U2FREQ0x0100
-
-/* offsets of banks in each u2phy registers */
-#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-/* offsets of banks in each u3phy registers */
-#define SSUSB_SIFSLV_U3PHYD_BASE   0x
-#define SSUSB_SIFSLV_U3PHYA_BASE   0x0200
-
-#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
+/* version V1 sub-banks offset base address */
+/* banks shared by multiple phys */
+#define SSUSB_SIFSLV_V1_SPLLC  0x000   /* shared by u3 phys */
+#define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
+/* u2 phy bank */
+#define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
+/* u3 phy banks */
+#define SSUSB_SIFSLV_V1_U3PHYD 0x000
+#define SSUSB_SIFSLV_V1_U3PHYA 0x200
+
+/* version V2 sub-banks offset base address */
+/* u2 phy banks */
+#define SSUSB_SIFSLV_V2_MISC   0x000
+#define SSUSB_SIFSLV_V2_U2FREQ 0x100
+#define SSUSB_SIFSLV_V2_U2PHY_COM  0x300
+/* u3 phy banks */
+#define SSUSB_SIFSLV_V2_SPLLC  0x000
+#define SSUSB_SIFSLV_V2_CHIP   0x100
+#define SSUSB_SIFSLV_V2_U3PHYD 0x200
+#define SSUSB_SIFSLV_V2_U3PHYA 0x400
+
+#define U3P_USBPHYACR0 0x000
 #define PA0_RG_U2PLL_FORCE_ON  BIT(15)
 
-#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008)
+#define U3P_USBPHYACR2 0x008
 #define PA2_RG_SIF_U2PLL_FORCE_EN  BIT(18)
 
-#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define U3P_USBPHYACR5 0x014
 #define PA5_RG_U2_HSTX_SRCAL_ENBIT(15)
 #define PA5_RG_U2_HSTX_SRCTRL  GENMASK(14, 12)
 #define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
 
-#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
+#define U3P_USBPHYACR6 0x018
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
 #define PA6_RG_U2_SQTH GENMASK(3, 0)
 #define PA6_RG_U2_SQTH_VAL(x)  (0xf & (x))
 
-#define U3P_U2PHYACR4  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
+#define U3P_U2PHYACR4  0x020
 #define P2C_RG_USB20_GPIO_CTL  BIT(9)
 #define P2C_USB20_GPIO_MODEBIT(8)
 #define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
 
-#define U3D_U2PHYDCR0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060)
+#define U3D_U2PHYDCR0  0x060
 #define P2C_RG_SIF_U2PLL_FORCE_ON  BIT(24)
 
-#define U3P_U2PHYDTM0  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068)
+#define U3P_U2PHYDTM0  0x068
 #define P2C_FORCE_UART_EN  BIT(26)
 #define P2C_FORCE_DATAIN   BIT(23)
 #define P2C_FORCE_DM_PULLDOWN  BIT(21)
@@ -84,47 +92,44 @@
P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \
P2C_RG_DPPULLDOWN | P2C_RG_TERMSEL)
 
-#define U3P_U2PHYDTM1  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x006C)
+#define U3P_U2PHYDTM1  0x06C
 #define P2C_RG_UART_EN BIT(16)
 #define P2C_RG_VBUSVALID   BIT(5)
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
-#define U3P_U3_PHYA_REG0   (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
-#define P3A_RG_U3_VUSB10_ONBIT(5)
-
-#define U3P_U3_PHYA_REG6   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6   0x018
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
 
-#define U3P_U3_PHYA_REG9   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9   0x024
 #define P3A_RG_RX_DAC_MUX  GENMASK(5, 1)
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
+#define U3P_U3_PHYA_DA_REG00x100
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
-#define U3P_PHYD_CDR1  (SSUSB_SIFSLV_U3PHYD_BASE + 0x005c)
+#define U3P_U3_PHYD_CDR1   0x05c
 #define P3D_RG_CDR_BIR_LTD1GENMASK(28, 24)
 #define P3D_RG_CDR_BIR_LTD1_VAL(x) ((0x1f & (x)) << 

Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers

2017-01-17 Thread John Hubbard


On 01/16/2017 11:51 PM, Michal Hocko wrote:

On Mon 16-01-17 13:57:43, John Hubbard wrote:



On 01/16/2017 01:48 PM, Michal Hocko wrote:

On Mon 16-01-17 13:15:08, John Hubbard wrote:



On 01/16/2017 11:40 AM, Michal Hocko wrote:

On Mon 16-01-17 11:09:37, John Hubbard wrote:



On 01/16/2017 12:47 AM, Michal Hocko wrote:

On Sun 15-01-17 20:34:13, John Hubbard wrote:

[...]

Is that "Reclaim modifiers" line still true, or is it a leftover from an
earlier approach? I am having trouble reconciling it with rest of the
patchset, because:

a) the flags argument below is effectively passed on to either kmalloc_node
(possibly adding, but not removing flags), or to __vmalloc_node_flags.


The above only says thos are _unsupported_ - in other words the behavior
is not defined. Even if flags are passed down to kmalloc resp. vmalloc
it doesn't mean they are used that way.  Remember that vmalloc uses
some hardcoded GFP_KERNEL allocations.  So while I could be really
strict about this and mask away these flags I doubt this is worth the
additional code.


I do wonder about passing those flags through to kmalloc. Maybe it is worth
stripping out __GFP_NORETRY and __GFP_NOFAIL, after all. It provides some
insulation from any future changes to the implementation of kmalloc, and it
also makes the documentation more believable.


I am not really convinced that we should take an extra steps for these
flags. There are no existing users for those flags and new users should
follow the documentation.


OK, let's just fortify the documentation ever so slightly, then, so that
users are more likely to do the right thing. How's this sound:

* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL are not supported. (Even
* though the current implementation passes the flags on through to kmalloc and
* vmalloc, that is done for efficiency and to avoid unnecessary code. The caller
* should not pass in these flags.)
*
* __GFP_REPEAT is supported, but only for large (>64kB) allocations.


? Or is that documentation overkill?


Dunno, it sounds like an overkill to me. It is telling more than
necessary. If we want to be so vocal about gfp flags then we would have
to say much more I suspect. E.g. what about __GFP_HIGHMEM? This flag is
supported for vmalloc while unsupported for kmalloc. I am pretty sure
there would be other gfp flags to consider and then this would grow
borringly large and uninteresting to the point when people simply stop
reading it. Let's just be as simple as possible.


Agreed, on the simplicity point: simple and clear is ideal. But here, it's
merely short, and not quite simple. :)  People will look at that short bit
of documentation, and then notice that the flags are, in fact, all passed
right on through down to both kmalloc_node and __vmalloc_node_flags.

If you don't want too much documentation, then I'd be inclined to say
something higher-level, about the intent, rather than mentioning those two
flags directly. Because as it stands, the documentation contradicts what the
code does.


Feel free to suggest a better wording. I am, of course, open to any
changes.


OK, here's the best I've got, I tried to keep it concise, but (as you suspected) I'm not sure it's 
actually any better than the original:


 * Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
 * Passing in __GFP_REPEAT is supported, but note that it is ignored for small
 * (<=64KB) allocations, during the kmalloc attempt. __GFP_REPEAT is fully
 * honored for  all allocation sizes during the second part: the vmalloc 
attempt.




--
Michal Hocko
SUSE Labs



Re: [PATCH net-next v2] bridge: multicast to unicast

2017-01-17 Thread kbuild test robot
Hi Felix,

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Linus-L-ssing/bridge-multicast-to-unicast/20170118-120345
config: x86_64-rhel-7.2 (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=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   net/bridge/br_forward.c: In function 'br_multicast_flood':
>> net/bridge/br_forward.c:261:27: warning: 'port' may be used uninitialized in 
>> this function [-Wmaybe-uninitialized]
  struct net_bridge_port *port, *lport, *rport;
  ^~~~

vim +/port +261 net/bridge/br_forward.c

5cb5e947 Herbert Xu  2010-02-27  245  #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
5cb5e947 Herbert Xu  2010-02-27  246  /* called with rcu_read_lock */
37b090e6 Nikolay Aleksandrov 2016-07-14  247  void br_multicast_flood(struct 
net_bridge_mdb_entry *mdst,
b35c5f63 Nikolay Aleksandrov 2016-07-14  248struct sk_buff 
*skb,
37b090e6 Nikolay Aleksandrov 2016-07-14  249bool local_rcv, 
bool local_orig)
5cb5e947 Herbert Xu  2010-02-27  250  {
5cb5e947 Herbert Xu  2010-02-27  251struct net_device *dev = 
BR_INPUT_SKB_CB(skb)->brdev;
1080ab95 Nikolay Aleksandrov 2016-06-28  252u8 igmp_type = 
br_multicast_igmp_type(skb);
5cb5e947 Herbert Xu  2010-02-27  253struct net_bridge *br = 
netdev_priv(dev);
afe0159d stephen hemminger   2010-04-27  254struct net_bridge_port *prev = 
NULL;
5cb5e947 Herbert Xu  2010-02-27  255struct net_bridge_port_group *p;
5cb5e947 Herbert Xu  2010-02-27  256struct hlist_node *rp;
5cb5e947 Herbert Xu  2010-02-27  257  
e8051688 Eric Dumazet2010-11-15  258rp = 
rcu_dereference(hlist_first_rcu(>router_list));
83f6a740 stephen hemminger   2010-04-27  259p = mdst ? 
rcu_dereference(mdst->ports) : NULL;
5cb5e947 Herbert Xu  2010-02-27  260while (p || rp) {
afe0159d stephen hemminger   2010-04-27 @261struct net_bridge_port 
*port, *lport, *rport;
afe0159d stephen hemminger   2010-04-27  262  
5cb5e947 Herbert Xu  2010-02-27  263lport = p ? p->port : 
NULL;
5cb5e947 Herbert Xu  2010-02-27  264rport = rp ? 
hlist_entry(rp, struct net_bridge_port, rlist) :
5cb5e947 Herbert Xu  2010-02-27  265 NULL;
5cb5e947 Herbert Xu  2010-02-27  266  
507962cd Felix Fietkau   2017-01-17  267if ((unsigned 
long)lport > (unsigned long)rport) {
507962cd Felix Fietkau   2017-01-17  268if (p->flags & 
MDB_PG_FLAGS_MCAST_TO_UCAST) {
507962cd Felix Fietkau   2017-01-17  269
maybe_deliver_addr(lport, skb, p->eth_addr,

:: The code at line 261 was first introduced by commit
:: afe0159d935ab731c682e811356914bb2be9470c bridge: multicast_flood cleanup

:: TO: stephen hemminger 
:: CC: David S. Miller 

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


.config.gz
Description: application/gzip


Re: [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()

2017-01-17 Thread Greg Kroah-Hartman
On Tue, Jan 17, 2017 at 03:21:47PM -0800, Florian Fainelli wrote:
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/base/core.c| 31 +++
>  include/linux/device.h |  2 ++
>  2 files changed, 33 insertions(+)

My NAK still stands here, please give me a day or so to respond to the
other thread about this...

thanks,

greg k-h


Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

2017-01-17 Thread Greg KH
On Mon, Jan 16, 2017 at 12:01:02PM -0800, Florian Fainelli wrote:
> On 01/15/2017 11:16 AM, Andrew Lunn wrote:
> >>> What exactly is the relationship between these devices (a ascii-art tree
> >>> or sysfs tree output might be nice) so I can try to understand what is
> >>> going on here.
> > 
> > Hi Greg, Florian
> > 
> > A few diagrams and trees which might help understand what is going on.
> > 
> > The first diagram comes from the 2008 patch which added all this code:
> > 
> > +---+   +---+
> > |   | RGMII |   |
> > |   +---+   +-- 1000baseT MDI ("WAN")
> > |   |   |  6-port   +-- 1000baseT MDI ("LAN1")
> > |CPU|   |  ethernet +-- 1000baseT MDI ("LAN2")
> > |   |MIImgmt|  switch   +-- 1000baseT MDI ("LAN3")
> > |   +---+  w/5 PHYs +-- 1000baseT MDI ("LAN4")
> > |   |   |   |
> > +---+   +---+
> > 
> > We have an ethernet switch and a host CPU. The switch is connected to
> > the CPU in two different ways. RGMII allows us to get Ethernet frames
> > from the CPU into the switch. MIImgmt, is the management bus normally
> > used for Ethernet PHYs, but Marvell switches also use it for Managing
> > switches.
> > 
> > The diagram above is the simplest setup. You can have multiple
> > Ethernet switches, connected together via switch ports. Each switch
> > has its own MIImgmt connect to the CPU, but there is only one RGMII
> > link.
> > 
> > When this code was designed back in 2008, it was decided to represent
> > this is a platform device, and it has a platform_data, which i have
> > slightly edited to keep it simple:
> > 
> > struct dsa_platform_data {
> > /*
> >  * Reference to a Linux network interface that connects
> >  * to the root switch chip of the tree.
> >  */
> > struct device   *netdev;
> > 
> > /*
> >  * Info structs describing each of the switch chips
> >  * connected via this network interface.
> >  */
> > int nr_chips;
> > struct dsa_chip_data*chip;
> > };
> > 
> > This netdev is the CPU side of the RGMII interface.
> > 
> > Each switch has a dsa_chip_data, again edited:
> > 
> > struct dsa_chip_data {
> > /*
> >  * How to access the switch configuration registers.
> >  */
> > struct device   *host_dev;
> > int sw_addr;
> > ...
> > }
> > 
> > The host_dev is the CPU side of the MIImgmt, and we have the address
> > the switch is using on the bus.
> > 
> > During probe of this platform device, we need to get from the
> > struct device *netdev to a struct net_device *dev.
> > 
> > So the code looks in the device net class to find the device
> > 
> > |   |   |   |-- f1074000.ethernet
> > |   |   |   |   |-- deferred_probe
> > |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/mvneta
> > |   |   |   |   |-- driver_override
> > |   |   |   |   |-- modalias
> > |   |   |   |   |-- net
> > |   |   |   |   |   `-- eth1
> > |   |   |   |   |   |-- addr_assign_type
> > |   |   |   |   |   |-- address
> > |   |   |   |   |   |-- addr_len
> > |   |   |   |   |   |-- broadcast
> > |   |   |   |   |   |-- carrier
> > |   |   |   |   |   |-- carrier_changes
> > |   |   |   |   |   |-- deferred_probe
> > |   |   |   |   |   |-- device -> ../../../f1074000.ethernet
> > 
> > and then use container_of() to get the net_device.
> > 
> > Similarly, the code needs to get from struct device *host_dev to a struct 
> > mii_bus *.
> > 
> > |   |   |   |-- f1072004.mdio
> > |   |   |   |   |-- deferred_probe
> > |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/orion-mdio
> > |   |   |   |   |-- driver_override
> > |   |   |   |   |-- mdio_bus
> > |   |   |   |   |   `-- f1072004.mdio-mi
> > |   |   |   |   |   |-- deferred_probe
> > |   |   |   |   |   |-- device -> ../../../f1072004.mdio
> > 
> 
> Thanks Andrew! Greg, does that make it clearer how these devices
> references are used, do you still think the way this is done is wrong,
> too cautious, or valid?

I'm still not sold on it, I think there is something odd here with your
use/assumptions of the driver model.  Give me a few days to catch up
with other stuff to respond back please...

thanks,

greg k-h


Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

2017-01-17 Thread Trevor Cordes
On 2017-01-17 Michal Hocko wrote:
> On Tue 17-01-17 14:21:14, Mel Gorman wrote:
> > On Tue, Jan 17, 2017 at 02:52:28PM +0100, Michal Hocko wrote:  
> > > On Mon 16-01-17 11:09:34, Mel Gorman wrote:
> > > [...]  
> > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > index 532a2a750952..46aac487b89a 100644
> > > > --- a/mm/vmscan.c
> > > > +++ b/mm/vmscan.c
> > > > @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist
> > > > *zonelist, struct scan_control *sc) continue;
> > > >  
> > > > if (sc->priority != DEF_PRIORITY &&
> > > > +   !buffer_heads_over_limit &&
> > > > !pgdat_reclaimable(zone->zone_pgdat))
> > > > continue;   /* Let kswapd
> > > > poll it */  
> > > 
> > > I think we should rather remove pgdat_reclaimable here. This
> > > sounds like a wrong layer to decide whether we want to reclaim
> > > and how much. 
> > 
> > I had considered that but it'd also be important to add the other
> > 32-bit patches you have posted to see the impact. Because of the
> > ratio of LRU pages to slab pages, it may not have an impact but
> > it'd need to be eliminated.  
> 
> OK, Trevor you can pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
> fixes/highmem-node-fixes branch. This contains the current mmotm tree
> + the latest highmem fixes. I also do not expect this would help much
> in your case but as Mel've said we should rule that out at least.

OK, ignore my last question re: what to do next.  I am building
this mhocko git tree now per your above instructions and will reboot
into it in a few hours with*out* the cgroup_disable=memory option.
Might take ~50 hours for a result.

I should note that the workload on the box with the bug is mostly as a
file server and iptables firewall/router.  It routes around 8GB(ytes) a
day, and periodic file server loads.  That's about it.  Everything else
that is running is not doing much, and not using much RAM; except
maybe clamav, by far the biggest RAM.

I don't see this bug on other nearly identical boxes, including:
F24 4.8.15 32-bit (no PAE) 1GB ram P4
F24 4.8.15 32-bit (no PAE) 2GB ram Core2 Quad

However, just noticed for the first time today that one other box is
also seeing this bug (gets an oom message), though with much less
frequency: twice in 2 months since upgrading to 4.8.  However, it
recovers from the oom without a reboot and hasn't hanged (yet).  That
could be because this box does not do as much file serving or I/O as
the one I've been building/testing on. Also, this box is a much older
Pentium-D with 4GB (PAE on).  If it would be helpful to see its oom
log, let me know.  (Scanning all my boxes now, I also found 1 single oom
on yet another 1 computer with the same story; but this is a Xeon
E3-1220 32-bit with PAE, 4GB.)

So far the commonality seems to be >2GB RAM and PAE on.  Might be
interesting to boot my build/test box with mem=2G and isolate it to
small RAM vs PAE.  "mem=2G" would make a great, easy, immediate
workaround for this problem for me (as cgroup_disable=memory also seems
to do, so far).  Thanks!


Re: [PATCH 12/13] pwm: jz4740: Let the pinctrl driver configure the pins

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:20AM +0100, Paul Cercueil wrote:
> Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on
> the pins being properly configured before the driver probes.
> 
> One inherent problem of this new approach is that the pinctrl framework
> does not allow us to configure each pin on demand, when the various PWM
> channels are requested or released. For instance, the PWM channels can
> be configured from sysfs, which would require all PWM pins to be configured
> properly beforehand for the PWM function, eventually causing conflicts
> with other platform or board drivers.
> 
> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.
> 
> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/pwm/pwm-jz4740.c | 29 -
>  1 file changed, 29 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
> index 76d13150283f..a75ff3622450 100644
> --- a/drivers/pwm/pwm-jz4740.c
> +++ b/drivers/pwm/pwm-jz4740.c
> @@ -21,22 +21,10 @@
>  #include 
>  #include 
>  
> -#include 

What about the linux/gpio.h header? It seems to me like that would be no
longer needed after this patch either.

Other than that this looks like the patch I'd expect if the pinmux was
configured statically, based on board design.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH] printk: Correctly handle preemption in console_unlock()

2017-01-17 Thread Sergey Senozhatsky
On (01/18/17 14:45), Sergey Senozhatsky wrote:
[..]
> 
> there is a function that clears @console_may_schedule out of
> console_sem scope - console_flush_on_panic().
> so I *may be* can think about a worst case scenario of race
> condition between
>   console_flush_on_panic()->console_may_schedule = 0 on panic CPU
> and
>   console_unlock()->console_may_schedule = 1 from CPU that panic CPU
> failed to stop (smp_send_stop() can return with secondary CPUs still being
> online).

what I mean, is that we can have, let's say, 2 CPUs spinning in
console_unlock(), both with @console_may_schedule == 1 (because secondary
CPU restores global @console_may_schedule value). now, suppose, we have
misbehaving scheduler (well, we are in panic after all). secondary CPU
will cond_resched() and may be lockup somewhere in the scheduler. which is
fine, we don't care about that secondary CPU anyway. but the same can happen
to panic CPU as well.

what do you think?

-ss


Re: [PATCH 13/13] MIPS: jz4740: Remove custom GPIO code

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:21AM +0100, Paul Cercueil wrote:
> All the drivers for the various hardware elements of the jz4740 SoC have
> been modified to use the pinctrl framework for their pin configuration
> needs.
> As such, this platform code is now unused and can be deleted.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  arch/mips/include/asm/mach-jz4740/gpio.h | 371 --
>  arch/mips/jz4740/Makefile|   2 -
>  arch/mips/jz4740/gpio.c  | 519 
> ---
>  3 files changed, 892 deletions(-)
>  delete mode 100644 arch/mips/jz4740/gpio.c

Have you considered how this could best be merged? It's probably easiest
to take all of this through the MIPS tree because we have an addition of
the pinctrl that would be a replacement for the GPIO code, while at the
same time a bunch of drivers rely on the JZ4740 GPIO code for successful
compilation.

That's slightly complicated by the number of drivers, so needs a lot of
coordination, but it's not the worst I've seen.

Maybe one other solution that would make the transition easier would be
to stub out the GPIO functions if the pinctrl driver is enabled, and do
the removal of the mach-jz4740/gpio.h after all drivers have been merged
through their corresponding subsystem trees. That way all drivers should
remain compilable and functional at runtime, while still having the
possibility to merge through the subsystem trees.

That said, the whole series is fairly simple, so merging everything
through the MIPS tree sounds like the easiest way to go.

Thierry


signature.asc
Description: PGP signature


Re: [RFC PATCH] initramfs: finish fput() before accessing any binary from initramfs

2017-01-17 Thread Lokesh Vutla


On Tuesday 17 January 2017 06:23 PM, Tero Kristo wrote:
> On 17/01/17 13:14, Lokesh Vutla wrote:
>> commit 4a9d4b024a31 ("switch fput to task_work_add") implements a
>> schedule_work() for completing fput(), but did not guarantee calling
>> __fput() after unpacking initramfs. Because of this, there is a
>> possibility that during boot a driver can see ETXTBSY when it tries
>> to load a binary from initramfs as fput() is still pending on that
>> binary. This patch makes sure that fput() is completed after unpacking
>> initramfs.
> 
> Good find there.
> 
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>
>> - Reproduced on TI K2HK EVM. K2HK Queue Manager subsystem driver[1] tries
>> to load a firmware from initramfs during boot. Sometimes loading of this
>> firmware fails with error ETXTBSY. Digging a bit more observed that
>> deny_write_access() is returning ETXTBSY as inode->i_writecount is > 0
>> for that file. This is because Unpacking initramfs does a
>> get_write_access(from open) but hasn't done put_write_access(from fput)
>> as it hasn't been scheduled yet.
>>
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/ti/knav_qmss_queue.c
>>
>>
>>  init/initramfs.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/init/initramfs.c b/init/initramfs.c
>> index b32ad7d97ac9..c42c69b48a4b 100644
>> --- a/init/initramfs.c
>> +++ b/init/initramfs.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  static ssize_t __init xwrite(int fd, const char *p, size_t count)
>>  {
>> @@ -652,6 +653,7 @@ static int __init populate_rootfs(void)
>>   * us a chance to load before device_initcalls.
>>   */
>>  load_default_modules();
>> +flush_delayed_fput();
> 
> Shouldn't the flush be called before the load_default_modules() though?

Good point. Will wait for sometime for more comments and then repost it.

Thanks and regards,
Lokesh


Re: [PATCH v11 07/12] drm/mediatek: cleaning up and refine

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> cleaning up unused define and refine function name and variable
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 73 
> --
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c |  8 ++--
>  2 files changed, 39 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 2c42f90..6f4b3bb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -27,9 +27,6 @@
>  
>  #include "mtk_drm_ddp_comp.h"
>  
> -#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
> -#define DSI_HOST_FIFO_DEPTH  64
> -
>  #define DSI_START0x00
>  
>  #define DSI_CON_CTRL 0x10
> @@ -46,7 +43,7 @@
>  #define MIX_MODE BIT(17)
>  
>  #define DSI_TXRX_CTRL0x18
> -#define VC_NUM   (2 << 0)
> +#define VC_NUM   BIT(1)
>  #define LANE_NUM (0xf << 2)
>  #define DIS_EOT  BIT(6)
>  #define NULL_EN  BIT(7)
> @@ -164,7 +161,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
> u32 mask, u32 data)
>   writel((temp & ~mask) | (data & mask), dsi->regs + offset);
>  }
>  
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
>  {
>   u32 timcon0, timcon1, timcon2, timcon3;
>   u32 ui, cycle_time;
> @@ -196,7 +193,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
>  }
>  
> -static void mtk_dsi_reset(struct mtk_dsi *dsi)
> +static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
> @@ -267,8 +264,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_enable(dsi);
> - mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> + mtk_dsi_reset_engine(dsi);
> + mtk_dsi_phy_timconfig(dsi);
>  
>   return 0;
>  
> @@ -281,33 +278,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   return ret;
>  }
>  
> -static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>  }
>  
> -static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
>  }
>  
> -static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
> +static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
>  {
>   u32 tmp_reg1;
>  
> @@ -315,15 +312,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
>   return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
>  }
>  
> -static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
> +static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
>  {
> - if (enter && !dsi_clk_hs_state(dsi))
> + if (enter && !mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
> - else if (!enter && dsi_clk_hs_state(dsi))
> + else if (!enter && mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>  }
>  
> -static void dsi_set_mode(struct mtk_dsi *dsi)
> +static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
>  {
>   u32 vid_mode = CMD_MODE;
>  
> @@ -338,7 +335,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
>   writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
>  }
>  
> -static void dsi_ps_control_vact(struct mtk_dsi *dsi)
> +static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
>  {
>   struct videomode *vm = >vm;
>   u32 dsi_buf_bpp, ps_wc;
> @@ -372,7 +369,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
>   writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
>  }
>  
> -static void dsi_rxtx_control(struct mtk_dsi *dsi)
> 

[RESEND PATCH 4/6] arm64: dts: mt8173: add a new reference clock for usb3 analog phy

2017-01-17 Thread Chunfeng Yun
add a new reference clock which comes from 26M oscillator directly
for SuperSpeed analog phy. and the old one which comes for PLL is
48M for HighSpeed analog phy.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..5d1663b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -754,8 +754,8 @@
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, 
<>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
-- 
1.7.9.5



[RESEND PATCH 2/6] phy: phy-mt65xx-usb3: split SuperSpeed port into two ones

2017-01-17 Thread Chunfeng Yun
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If wants to support SS, we can compound u2port0 and u3port0,
or u2port1 and u3port0, if select latter one, u2port0 is not needed.

So it's more flexible to split usb3 port into two ones and also try
best to save power by disabling unnecessary ports.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |  124 -
 1 file changed, 61 insertions(+), 63 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index fc9a4f0..c187a3b 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -30,11 +30,11 @@
 #define SSUSB_SIFSLV_SPLLC 0x
 #define SSUSB_SIFSLV_U2FREQ0x0100
 
-/* offsets of sub-segment in each port registers */
+/* offsets of banks in each u2phy registers */
 #define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-#define SSUSB_SIFSLV_U3PHYD_BASE   0x0100
-#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
-#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+/* offsets of banks in each u3phy registers */
+#define SSUSB_SIFSLV_U3PHYD_BASE   0x
+#define SSUSB_SIFSLV_U3PHYA_BASE   0x0200
 
 #define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
 #define PA0_RG_U2PLL_FORCE_ON  BIT(15)
@@ -49,7 +49,6 @@
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
 
 #define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
-#define PA6_RG_U2_ISO_EN   BIT(31)
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
 #define PA6_RG_U2_SQTH GENMASK(3, 0)
@@ -91,18 +90,18 @@
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
-#define U3P_U3_PHYA_REG0   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x)
+#define U3P_U3_PHYA_REG0   (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
 #define P3A_RG_U3_VUSB10_ONBIT(5)
 
-#define U3P_U3_PHYA_REG6   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
 
-#define U3P_U3_PHYA_REG9   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
 #define P3A_RG_RX_DAC_MUX  GENMASK(5, 1)
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_DA_BASE + 0x)
+#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
@@ -148,7 +147,7 @@ struct mt65xx_phy_instance {
 
 struct mt65xx_u3phy {
struct device *dev;
-   void __iomem *sif_base; /* include sif2, but exclude port's */
+   void __iomem *sif_base; /* only shared sif */
struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
@@ -179,7 +178,7 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
-   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index >> 1);
writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
 
/* enable frequency meter */
@@ -227,6 +226,41 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
writel(tmp, instance->port_base + U3P_USBPHYACR5);
 }
 
+static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
+   struct mt65xx_phy_instance *instance)
+{
+   void __iomem *port_base = instance->port_base;
+   u32 tmp;
+
+   /* gating PCIe Analog XTAL clock */
+   tmp = readl(u3phy->sif_base + U3P_XTALCTL3);
+   tmp |= XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD;
+   writel(tmp, u3phy->sif_base + U3P_XTALCTL3);
+
+   /* gating XSQ */
+   tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
+   tmp &= ~P3A_RG_XTAL_EXT_EN_U3;
+   tmp |= P3A_RG_XTAL_EXT_EN_U3_VAL(2);
+   writel(tmp, port_base + U3P_U3PHYA_DA_REG0);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG9);
+   tmp &= ~P3A_RG_RX_DAC_MUX;
+   tmp |= P3A_RG_RX_DAC_MUX_VAL(4);
+   writel(tmp, port_base + U3P_U3_PHYA_REG9);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG6);
+   tmp &= ~P3A_RG_TX_EIDLE_CM;
+   tmp |= P3A_RG_TX_EIDLE_CM_VAL(0xe);
+   writel(tmp, port_base + U3P_U3_PHYA_REG6);
+
+   tmp = 

[RESEND PATCH 1/6] phy: phy-mt65xx-usb3: add reference clock of usb3 analog phy

2017-01-17 Thread Chunfeng Yun
usually, the reference clock of usb3 analog phy comes from
26M oscillator directly, but some SoCs are not, add it for
compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |   36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index d972067..fc9a4f0 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -149,7 +149,8 @@ struct mt65xx_phy_instance {
 struct mt65xx_u3phy {
struct device *dev;
void __iomem *sif_base; /* include sif2, but exclude port's */
-   struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
+   struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
+   struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
int nphys;
@@ -429,11 +430,17 @@ static int mt65xx_phy_init(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
int ret;
 
-   ret = clk_prepare_enable(u3phy->u3phya_ref);
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   ret = clk_prepare_enable(ref_clk);
if (ret) {
-   dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
+   dev_err(u3phy->dev, "failed to enable ref clk\n");
return ret;
}
 
@@ -464,9 +471,16 @@ static int mt65xx_phy_exit(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
 
phy_instance_exit(u3phy, instance);
-   clk_disable_unprepare(u3phy->u3phya_ref);
+
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   clk_disable_unprepare(ref_clk);
return 0;
 }
 
@@ -566,10 +580,16 @@ static int mt65xx_u3phy_probe(struct platform_device 
*pdev)
return PTR_ERR(u3phy->sif_base);
}
 
-   u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
-   if (IS_ERR(u3phy->u3phya_ref)) {
-   dev_err(dev, "error to get u3phya_ref\n");
-   return PTR_ERR(u3phy->u3phya_ref);
+   u3phy->u2ref_clk = devm_clk_get(dev, "u2ref_clk");
+   if (IS_ERR(u3phy->u2ref_clk)) {
+   dev_err(dev, "failed to get u2ref_clk\n");
+   return PTR_ERR(u3phy->u2ref_clk);
+   }
+
+   u3phy->u3ref_clk = devm_clk_get(dev, "u3ref_clk");
+   if (IS_ERR(u3phy->u3ref_clk)) {
+   dev_err(dev, "failed to get u3ref_clk\n");
+   return PTR_ERR(u3phy->u3ref_clk);
}
 
port = 0;
-- 
1.7.9.5



[RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

2017-01-17 Thread Chunfeng Yun
add a new compatible string for "mt2712", and a new reference clock
for SuperSpeed analog phy;

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 +---
 1 file changed, 70 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..8f91136 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of 
Medaitek SoC.
 Required properties (controller (parent) node):
  - compatible  : should be one of
  "mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
  "mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
  - clocks  : a list of phandle + clock-specifier pairs, one for each
  entry in clock-names
  - clock-names : must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
+ "u2ref_clk": 48M reference clock of HighSpeed analog phy.
+ "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
+   sometimes is 24M, 25M or 27M, depended on platform.
 
 Required nodes : a sub-node is required for each port the controller
  provides. Address range information including the usual
  'reg' property is used inside these nodes to describe
  the controller's topology.
 
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
 Required properties (port (child) node):
 - reg  : address and length of the register set for the port.
 - #phy-cells   : should be 1 (See second example)
@@ -31,21 +37,27 @@ Example:
 u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, <>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
 
-   phy_port0: port@11290800 {
-   reg = <0 0x11290800 0 0x800>;
+   u2port0: port@11290800 {
+   reg = <0 0x11290800 0 0x100>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   u3port0: port@11290900 {
+   reg = <0 0x11290800 0 0x700>;
#phy-cells = <1>;
status = "okay";
};
 
-   phy_port1: port@11291000 {
-   reg = <0 0x11291000 0 0x800>;
+   u2port1: port@11291000 {
+   reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +76,54 @@ Example:
 
 usb30: usb@1127 {
...
-   phys = <_port0 PHY_TYPE_USB3>;
-   phy-names = "usb3-0";
+   phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
+   phy-names = "usb2-0", "usb3-0";
...
 };
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-
+mt8173 and mt2701:
+portoffsetbank
+shared  0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+mt2712:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u3 port10x1700SPLLC
+0x1800CHIP
+0x1900U3PHYD
+0x1a00U3PHYD_BANK2
+0x1b00U3PHYA
+0x1c00U3PHYA_DA
+u2 port20x2000MISC
+...
+
+SPLLC shared by u3 ports and FMREG shared by u2 ports on
+mt8173/mt2701 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on mt2712.
-- 
1.7.9.5



[PATCH 0/3] PM / devfreq: Fix issues about passive governor

2017-01-17 Thread Chanwoo Choi
This patchset fix the two issues about passive governor
and remove the unneeded separate _remove_devfreq() function.

First, the parent devfreq device can use the governors except for
the passive governor on the fly through sysfs entry and the passive
devfreq device is only possible to use the passive governor.

The 'available_governors' entry doesn't divide this difference
between parent devfreq and passive devfreq device. So, the patch1
fixes the this issue.

Second, the devfreq updates the statistic of frequency for each
device. But, 'trans_stat' of the passive devfreq device doesn't
update the statistic. So, the patch2 fixes this issue by calling
the update_devfreqw_passive() after setting the frequency
of passive devfreq device.

Finally, the patch3 removes the separate _remove_devfreq()
because this function is only called once in devfreq_dev_release().
I think that it is not necessary to make the separate function.


Depends on:
- These patches depends on the devfreq.git[1] and devfreq patches[2].
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
for-4.10-rc)
[2] https://lkml.org/lkml/2017/1/16/254
- ("[PATCH v3 0/4] PM / devfreq: Update the devfreq and devfreq-event device")


For example,
Following exmaple is the bus frequency device
of INT (Internal) block on Exynos5433-based TM2 board.

1. There are differences about 'available_governors' sysfs entry.
- Parent devfreq device (soc\:bus0)
- Passive devfreq device (soc\:bus1) depends on the parent devfreq (soc\:bus0).

1-1. Before applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/available_governors
passive userspace powersave performance simple_ondemand

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus1/available_governors
passive userspace powersave performance simple_ondemand

1-2. After applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/available_governors
userspace powersave performance simple_ondemand

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus1/available_governors
passive


2. There are differences about 'trans_stat' sysfs entry.
- Parent devfreq device (soc\:bus0)
- Passive devfreq device (soc\:bus3) depends on the parent devfreq (soc\:bus0).

2-1. Before applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 0 1 0 0 0 
80664
  13400: 0 0 0 0 1 0  
7552
  16000: 0 1 0 0 0 0  
8136
  2: 0 0 0 0 0 0
 0
  26700: 0 0 0 0 0 1 
23208
* 4: 0 0 0 0 0 0   
1188144
Total transition : 4

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus3/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 0 0 0 0 0
 0
  13400: 0 0 0 0 0 0
 0
  16000: 0 0 0 0 0 0
 0
  2: 0 0 0 0 0 0
 0
  26700: 0 0 0 0 0 0
 0
* 4: 0 0 0 0 0 0   
1317400
Total transition : 0


2-2. After applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 1 0 0 0 0
110372
  13400: 0 0 1 0 0 0  
6180
  16000: 0 0 0 1 0 0  
3748
  2: 0 0 0 0 1 0  
2992
  26700: 0 0 0 0 0 1  
4648
* 4: 0 0 0 0 0 0  
1636
Total transition : 5

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus3/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 1 0 0 0 0
110372
  13400: 0 0 1 0 0 0  
6180
  16000: 0 0 0 1 0 0  
3748
  2: 0 0 0 0 1 0  
2992
  26700: 0 0 0 0   

[PATCH 1/3] PM / devfreq: Fix available_governor sysfs

2017-01-17 Thread Chanwoo Choi
The devfreq using passive governor is not able to change the governor.
So, the user can not change the governor through 'available_governor' sysfs
entry. Also, the devfreq which don't use the passive governor is not able to
change to 'passive' governor on the fly.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 4bd7a8f71b07..a2c575a5a9ab 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -43,6 +43,11 @@
 static LIST_HEAD(devfreq_list);
 static DEFINE_MUTEX(devfreq_list_lock);
 
+static int is_passive_gov(const char *governor_name)
+{
+   return (!strncmp(governor_name, "passive", 7)) ? 1 : 0;
+}
+
 /**
  * find_device_devfreq() - find devfreq struct using device pointer
  * @dev:   device pointer used to lookup device devfreq.
@@ -933,6 +938,10 @@ static ssize_t governor_store(struct device *dev, struct 
device_attribute *attr,
if (ret != 1)
return -EINVAL;
 
+   /* The passive devfreq is not able to change the governor. */
+   if (is_passive_gov(df->governor_name))
+   return 0;
+
mutex_lock(_list_lock);
governor = find_devfreq_governor(str_governor);
if (IS_ERR(governor)) {
@@ -972,12 +981,35 @@ static ssize_t available_governors_show(struct device *d,
char *buf)
 {
struct devfreq_governor *tmp_governor;
+   struct devfreq *df = to_devfreq(d);
ssize_t count = 0;
 
mutex_lock(_list_lock);
-   list_for_each_entry(tmp_governor, _governor_list, node)
+
+   /*
+* The passive devfreq shows only passive governor.
+* The governor except for passive are not available
+* for passive devfreq device.
+*/
+   if (is_passive_gov(df->governor_name)) {
+   count += scnprintf([count], (PAGE_SIZE - count - 2),
+  "%s ", df->governor_name);
+   goto out;
+   }
+
+   /*
+* The devfreq device show the registered governor except for
+* 'passive' governor.
+*/
+   list_for_each_entry(tmp_governor, _governor_list, node) {
+   if (is_passive_gov(tmp_governor->name))
+   continue;
+
count += scnprintf([count], (PAGE_SIZE - count - 2),
   "%s ", tmp_governor->name);
+   }
+
+out:
mutex_unlock(_list_lock);
 
/* Truncate the trailing space */
-- 
1.9.1



[PATCH 3/3] PM / devfreq: Remove unnecessary separate _remove_devfreq()

2017-01-17 Thread Chanwoo Choi
The _remove_devfreq() releases the all resources of the devfreq
device. This function is only called in the devfreq_dev_release().
For that reason, the devfreq core doesn't need to leave the
_remove_devfreq() separately. This patch releases the all
resources in the devfreq_dev_release() and then removes the
_remove_devfreq().

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 6c560af2a801..c908c10c200a 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -480,11 +480,15 @@ static int devfreq_notifier_call(struct notifier_block 
*nb, unsigned long type,
 }
 
 /**
- * _remove_devfreq() - Remove devfreq from the list and release its resources.
- * @devfreq:   the devfreq struct
+ * devfreq_dev_release() - Callback for struct device to release the device.
+ * @dev:   the devfreq device
+ *
+ * Remove devfreq from the list and release its resources.
  */
-static void _remove_devfreq(struct devfreq *devfreq)
+static void devfreq_dev_release(struct device *dev)
 {
+   struct devfreq *devfreq = to_devfreq(dev);
+
mutex_lock(_list_lock);
if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
mutex_unlock(_list_lock);
@@ -506,19 +510,6 @@ static void _remove_devfreq(struct devfreq *devfreq)
 }
 
 /**
- * devfreq_dev_release() - Callback for struct device to release the device.
- * @dev:   the devfreq device
- *
- * This calls _remove_devfreq() if _remove_devfreq() is not called.
- */
-static void devfreq_dev_release(struct device *dev)
-{
-   struct devfreq *devfreq = to_devfreq(dev);
-
-   _remove_devfreq(devfreq);
-}
-
-/**
  * devfreq_add_device() - Add devfreq feature to the device
  * @dev:   the device to add devfreq feature.
  * @profile:   device-specific profile to run devfreq.
-- 
1.9.1



[PATCH 2/3] PM / devfreq: Fix wrong trans_stat of passive devfreq device

2017-01-17 Thread Chanwoo Choi
Until now, the trans_stat information of passive devfreq is not updated.
This patch updates the trans_stat information after setting the target
frequency of passive devfreq device.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c  | 3 ++-
 drivers/devfreq/governor.h | 2 ++
 drivers/devfreq/governor_passive.c | 5 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index a2c575a5a9ab..6c560af2a801 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -135,7 +135,7 @@ static void devfreq_set_freq_table(struct devfreq *devfreq)
  * @devfreq:   the devfreq instance
  * @freq:  the update target frequency
  */
-static int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
+int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
 {
int lev, prev_lev, ret = 0;
unsigned long cur_time;
@@ -171,6 +171,7 @@ static int devfreq_update_status(struct devfreq *devfreq, 
unsigned long freq)
devfreq->last_stat_updated = cur_time;
return ret;
 }
+EXPORT_SYMBOL(devfreq_update_status);
 
 /**
  * find_devfreq_governor() - find devfreq governor from name
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..71576b8bdfef 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -38,4 +38,6 @@ extern void devfreq_interval_update(struct devfreq *devfreq,
 extern int devfreq_add_governor(struct devfreq_governor *governor);
 extern int devfreq_remove_governor(struct devfreq_governor *governor);
 
+extern int devfreq_update_status(struct devfreq *devfreq, unsigned long freq);
+
 #endif /* _GOVERNOR_H */
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 9ef46e2592c4..443be65f4561 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -112,6 +112,11 @@ static int update_devfreq_passive(struct devfreq *devfreq, 
unsigned long freq)
if (ret < 0)
goto out;
 
+   if (devfreq->profile->freq_table
+   && (devfreq_update_status(devfreq, freq)))
+   dev_err(>dev,
+   "Couldn't update frequency transition information.\n");
+
devfreq->previous_freq = freq;
 
 out:
-- 
1.9.1



Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

2017-01-17 Thread Trevor Cordes
On 2017-01-16 Mel Gorman wrote:
> > > You can easily check whether this is memcg related by trying to
> > > run the same workload with cgroup_disable=memory kernel command
> > > line parameter. This will put all the memcg specifics out of the
> > > way.  
> > 
> > I will try booting now into cgroup_disable=memory to see if that
> > helps at all.  I'll reply back in 48 hours, or when it oom's,
> > whichever comes first.
> >   
> 
> Thanks.

It has successfully survived 70 hours and 2 3am cycles (when it
normally oom's) with your first patch *and* cgroup_disable=memory
grafted on Fedora's 4.8.13.  Since it has never survived 2 3am cycles,
I strongly suspect the cgroup_disable=memory mitigates my bug.

> > Also, should I bother trying the latest git HEAD to see if that
> > solves anything?  Thanks!  
> 
> That's worth trying. If that also fails then could you try the
> following hack to encourage direct reclaim to reclaim slab when
> buffers are over the limit please?
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 532a2a750952..46aac487b89a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist
> *zonelist, struct scan_control *sc) continue;
>  
>   if (sc->priority != DEF_PRIORITY &&
> + !buffer_heads_over_limit &&
>   !pgdat_reclaimable(zone->zone_pgdat))
>   continue;   /* Let kswapd poll
> it */ 

What's the next best step?  HEAD?  HEAD + the above patch?  A new
patch?  I'll start a HEAD compile until I hear more.  I assume I should
test without cgroup_disable=memory as that's just a kludge/workaround,
right?

Also, is there a way to spot the slab pressure you are talking about
before oom's occur?  slabinfo?  I suppose I'd be able to see some
counter slowly getting too high or low?  Thanks!


Re: [linux-sunxi] Re: [PATCH] ASoC: sunxi: Add bindings for sun8i to SPDIF

2017-01-17 Thread Code Kipper
On 17 January 2017 at 19:15, Mark Brown  wrote:
> On Thu, Jan 12, 2017 at 06:33:43PM +0100, codekip...@gmail.com wrote:
>> From: Marcus Cooper 
>>
>> The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the
>> transmit fifo is at a different address.
>>
>> Signed-off-by: Marcus Cooper 
>> ---
>>  Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt | 1 +
>>  1 file changed, 1 insertion(+)
>
> This is fine but it doesn't actually add the compatible string to the
> driver which I'd expect.
Hi Mark,
I missed the binding documentation on the patch for the driver so I
pushed it separately instead of pushing a new patch version.
You can find it under the subject heading 'ASoC: sun4i-spdif: Add
support for the H3 SoC' and Maxime has ACK it (on the condition that I
add the binding doc).
BR,
CK
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to slowpath

2017-01-17 Thread Hillf Danton
On Wednesday, January 18, 2017 6:16 AM Vlastimil Babka wrote: 
> 
> This is a preparation for the following patch to make review simpler. While
> the primary motivation is a bug fix, this could also save some cycles in the
> fast path.
> 
This also gets kswapd involved. 
Dunno how frequent cpuset is changed in real life.

Hillf



[PATCH 1/6] phy: phy-mt65xx-usb3: add reference clock of usb3 analog phy

2017-01-17 Thread Chunfeng Yun
usually, the reference clock of usb3 analog phy comes from
26M oscillator directly, but some SoCs are not, add it for
compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |   36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index d972067..fc9a4f0 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -149,7 +149,8 @@ struct mt65xx_phy_instance {
 struct mt65xx_u3phy {
struct device *dev;
void __iomem *sif_base; /* include sif2, but exclude port's */
-   struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
+   struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
+   struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
int nphys;
@@ -429,11 +430,17 @@ static int mt65xx_phy_init(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
int ret;
 
-   ret = clk_prepare_enable(u3phy->u3phya_ref);
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   ret = clk_prepare_enable(ref_clk);
if (ret) {
-   dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
+   dev_err(u3phy->dev, "failed to enable ref clk\n");
return ret;
}
 
@@ -464,9 +471,16 @@ static int mt65xx_phy_exit(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
 
phy_instance_exit(u3phy, instance);
-   clk_disable_unprepare(u3phy->u3phya_ref);
+
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   clk_disable_unprepare(ref_clk);
return 0;
 }
 
@@ -566,10 +580,16 @@ static int mt65xx_u3phy_probe(struct platform_device 
*pdev)
return PTR_ERR(u3phy->sif_base);
}
 
-   u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
-   if (IS_ERR(u3phy->u3phya_ref)) {
-   dev_err(dev, "error to get u3phya_ref\n");
-   return PTR_ERR(u3phy->u3phya_ref);
+   u3phy->u2ref_clk = devm_clk_get(dev, "u2ref_clk");
+   if (IS_ERR(u3phy->u2ref_clk)) {
+   dev_err(dev, "failed to get u2ref_clk\n");
+   return PTR_ERR(u3phy->u2ref_clk);
+   }
+
+   u3phy->u3ref_clk = devm_clk_get(dev, "u3ref_clk");
+   if (IS_ERR(u3phy->u3ref_clk)) {
+   dev_err(dev, "failed to get u3ref_clk\n");
+   return PTR_ERR(u3phy->u3ref_clk);
}
 
port = 0;
-- 
1.7.9.5



[PATCH 5/6] arm64: dts: mt8173: split usb SuperSpeed port into two ports

2017-01-17 Thread Chunfeng Yun
split the old SuperSpeed port node into a HighSpeed one and a new
SuperSpeed one.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 5d1663b..07fd2eb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -724,8 +724,9 @@
  <0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
interrupts = ;
-   phys = <_port0 PHY_TYPE_USB3>,
-  <_port1 PHY_TYPE_USB2>;
+   phys = < PHY_TYPE_USB2>,
+  < PHY_TYPE_USB3>,
+  < PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
 < CLK_PERI_USB0>,
@@ -761,14 +762,20 @@
ranges;
status = "okay";
 
-   phy_port0: port@11290800 {
-   reg = <0 0x11290800 0 0x800>;
+   u2port0: port@11290800 {
+   reg = <0 0x11290800 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
 
-   phy_port1: port@11291000 {
-   reg = <0 0x11291000 0 0x800>;
+   u3port0: port@11290900 {
+   reg = <0 0x11290900 0 0x700>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   u2port1: port@11291000 {
+   reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
-- 
1.7.9.5



[PATCH v2 1/3] clk: rockchip: add rk3288 vip_out clock ids

2017-01-17 Thread Jacob Chen
Add clock-ids for the vip block of the rk3288

Signed-off-by: Jacob Chen 
---
 include/dt-bindings/clock/rk3288-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index 9a586e2..11183bf 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -88,6 +88,7 @@
 #define SCLK_PVTM_GPU  124
 #define SCLK_CRYPTO125
 #define SCLK_MIPIDSI_24M   126
+#define SCLK_VIP_OUT   127
 
 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
2.7.4



[PATCH v2 2/3] clk: rockchip: use rk3288 vip_out clock ids

2017-01-17 Thread Jacob Chen
Reference the newly added vip clock-ids in the clock-tree.

Signed-off-by: Jacob Chen 
---
 drivers/clk/rockchip/clk-rk3288.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 39af05a..3d02aa2 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -469,7 +469,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
COMPOSITE_NODIV(0, "vip_src", mux_pll_src_cpll_gpll_p, 0,
RK3288_CLKSEL_CON(26), 8, 1, MFLAGS,
RK3288_CLKGATE_CON(3), 7, GFLAGS),
-   COMPOSITE_NOGATE(0, "sclk_vip_out", mux_vip_out_p, 0,
+   COMPOSITE_NOGATE(SCLK_VIP_OUT, "sclk_vip_out", mux_vip_out_p, 0,
RK3288_CLKSEL_CON(26), 15, 1, MFLAGS, 9, 5, DFLAGS),
 
DIV(0, "pclk_pd_alive", "gpll", 0,
-- 
2.7.4



[PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

2017-01-17 Thread Chunfeng Yun
add a new compatible string for "mt2712", and a new reference clock
for SuperSpeed analog phy;

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 +---
 1 file changed, 70 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..8f91136 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of 
Medaitek SoC.
 Required properties (controller (parent) node):
  - compatible  : should be one of
  "mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
  "mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
  - clocks  : a list of phandle + clock-specifier pairs, one for each
  entry in clock-names
  - clock-names : must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
+ "u2ref_clk": 48M reference clock of HighSpeed analog phy.
+ "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
+   sometimes is 24M, 25M or 27M, depended on platform.
 
 Required nodes : a sub-node is required for each port the controller
  provides. Address range information including the usual
  'reg' property is used inside these nodes to describe
  the controller's topology.
 
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
 Required properties (port (child) node):
 - reg  : address and length of the register set for the port.
 - #phy-cells   : should be 1 (See second example)
@@ -31,21 +37,27 @@ Example:
 u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, <>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
 
-   phy_port0: port@11290800 {
-   reg = <0 0x11290800 0 0x800>;
+   u2port0: port@11290800 {
+   reg = <0 0x11290800 0 0x100>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   u3port0: port@11290900 {
+   reg = <0 0x11290800 0 0x700>;
#phy-cells = <1>;
status = "okay";
};
 
-   phy_port1: port@11291000 {
-   reg = <0 0x11291000 0 0x800>;
+   u2port1: port@11291000 {
+   reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +76,54 @@ Example:
 
 usb30: usb@1127 {
...
-   phys = <_port0 PHY_TYPE_USB3>;
-   phy-names = "usb3-0";
+   phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
+   phy-names = "usb2-0", "usb3-0";
...
 };
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-
+mt8173 and mt2701:
+portoffsetbank
+shared  0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+mt2712:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u3 port10x1700SPLLC
+0x1800CHIP
+0x1900U3PHYD
+0x1a00U3PHYD_BANK2
+0x1b00U3PHYA
+0x1c00U3PHYA_DA
+u2 port20x2000MISC
+...
+
+SPLLC shared by u3 ports and FMREG shared by u2 ports on
+mt8173/mt2701 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on mt2712.
-- 
1.7.9.5



Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

2017-01-17 Thread Vivek Gautam

Hi Kishon,


On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v3:
  - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
  - Removed binding for "ref_clk_src" since we don't request this
clock in the driver.
  - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
  - Using 'phy' for the node name.

Changes since v1:
  - New patch, forked out of the original driver patch:
"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
  - Added 'Acked-by' from Rob.
  - Updated bindings to include mem resource as a list of
offset - length pair for serdes block and for each lane.
  - Added a new binding for 'lane-offsets' that contains offsets
to tx, rx and pcs blocks from each lane base address.

  .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 76 ++
  1 file changed, 76 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..6f510fe48f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+ - reg: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #phy-cells: must be 1
+- Cell after phy phandle should be the port (lane) number.
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   "pipe" for pipe clock specific to
+   each port/lane (Optional).
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: must be "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   "port" for reset specific to
+   each port/lane (Optional).
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Example:
+   pcie_phy: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+   #clock-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>,
+   < GCC_PCIE_0_PHY_BCR>,
+   < GCC_PCIE_1_PHY_BCR>,
+   < GCC_PCIE_2_PHY_BCR>;
+   reset-names = "phy", "common", "cfg",
+ 

Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:08AM +0100, Paul Cercueil wrote:
[...]
> One problem still unresolved: the pinctrl framework does not allow us to
> configure each pin on demand (someone please prove me wrong), when the
> various PWM channels are requested or released. For instance, the PWM
> channels can be configured from sysfs, which would require all PWM pins
> to be configured properly beforehand for the PWM function, eventually
> causing conflicts with other platform or board drivers.

Still catching up on a lot of email, so I haven't gone through the
entire series. But I don't think the above is true.

My understanding is that you can have separate pin groups for each
pin (provided the hardware supports that) and then control each of
these groups dynamically at runtime.

That is you could have the PWM driver's ->request() and ->free()
call into the pinctrl framework to select the correct pinmux
configuration as necessary.

> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.

That could probably work. From only looking at the JZ4740 PWM driver
there's no separate IP block to deal with the PWM outputs, but they are
merely GPIOs controller via a timer, so one instance per GPIO seems like
a fine solution to me.

> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board. The only jz4780 board upstream (CI20) does not yet support the
> PWM driver.

Typically all of the pinmux is pre-determined by the board design. That
is if you've got 8 pins that can be driven by a PWM signal, not all of
those might be exposed by the design. If, say, only 0-4 and 6 expose the
PWM signal while 5 and 7 expose a different function then you can simply
use a static pinmux configuration and ignore PWMs 5 and 7. Even if
someone were to configure them, the signal would simply go nowhere.

Of course you'd have to check that your hardware actually matches those
assumptions. They certainly apply to many SoCs that I've come across.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH] arm64: dts: exynos: Remove address node from usb parent node

2017-01-17 Thread Chanwoo Choi
Hi Pankaj,

This issue already posted by Javier Martinez Canillas[1].
Maybe, he will post v2.

[1] https://lkml.org/lkml/2017/1/10/907
- ("Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in 
Exynos5433 nodes")

On 2017년 01월 18일 14:46, Pankaj Dubey wrote:
> Address node does not required to be put after parent't node,
> so remove address node from usb parent node.
> 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 68f764e..0d7a55d 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -1285,7 +1285,7 @@
>   status = "disabled";
>   };
>  
> - usbdrd30: usb@1540  {
> + usbdrd30: usb3-0 {
>   compatible = "samsung,exynos5250-dwusb3";
>   clocks = <_fsys CLK_ACLK_USBDRD30>,
>   <_fsys CLK_SCLK_USBDRD30>;
> @@ -1332,7 +1332,7 @@
>   status = "disabled";
>   };
>  
> - usbhost30: usb@15a0 {
> + usbhost30: usbhost3-0 {
>   compatible = "samsung,exynos5250-dwusb3";
>   clocks = <_fsys CLK_ACLK_USBHOST30>,
>   <_fsys CLK_SCLK_USBHOST30>;
> 


-- 
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics


[PATCH v2] block: Don't register a registered bdi device

2017-01-17 Thread Yijing Wang
Following calltrace is quoted from Sreekanth Reddy's
patch email, we found the same issue in our platform.
link:https://patchwork.kernel.org/patch/9394471/

Observing below kernel panic while creating second raid disk
on LSI SAS3008 HBA card.
[  +0.55] [ cut here ]
[  +0.07] WARNING: CPU: 2 PID: 281 at fs/sysfs/dir.c:31 
sysfs_warn_dup+0x62/0x80
[  +0.02] sysfs: cannot create duplicate filename 
'/devices/virtual/bdi/8:32'
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.67] CPU: 2 PID: 281 Comm: kworker/u49:5 Not tainted 4.9.0-rc2 #1
[  +0.02] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.05] Workqueue: events_unbound async_run_entry_fn
[  +0.04] Call Trace:
[  +0.09]  [] dump_stack+0x63/0x85
[  +0.05]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.06]  [] ? kernfs_path_from_node+0x4f/0x60
[  +0.02]  [] sysfs_warn_dup+0x62/0x80
[  +0.02]  [] sysfs_create_dir_ns+0x77/0x90
[  +0.04]  [] kobject_add_internal+0x99/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.06]  [] ? device_private_init+0x23/0x70
[  +0.07]  [] ? mutex_lock+0x12/0x30
[  +0.03]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.06]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.06]  [] device_add_disk+0x168/0x480
[  +0.05]  [] ? update_autosuspend+0x51/0x60
[  +0.05]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.03]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.02] [ cut here ]
[  +0.04] WARNING: CPU: 2 PID: 281 at lib/kobject.c:240 
kobject_add_internal+0x2bd/0x330
[  +0.01] kobject_add_internal failed for 8:32 with -EEXIST, don't try to 
register things with the same name in the same
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.43] CPU: 2 PID: 281 Comm: kworker/u49:5 Tainted: GW   
4.9.0-rc2 #1
[  +0.01] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.02] Workqueue: events_unbound async_run_entry_fn
[  +0.03] Call Trace:
[  +0.03]  [] dump_stack+0x63/0x85
[  +0.03]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.02]  [] ? sysfs_warn_dup+0x6a/0x80
[  +0.03]  [] kobject_add_internal+0x2bd/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.03]  [] ? device_private_init+0x23/0x70
[  +0.04]  [] ? mutex_lock+0x12/0x30
[  +0.02]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.03]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.04]  [] device_add_disk+0x168/0x480
[  +0.03]  [] ? update_autosuspend+0x51/0x60
[  +0.02]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.02]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.000949] BUG: unable to handle kernel
[  +0.005263] NULL pointer dereference
[  +0.002853] IP: [] sysfs_do_create_link_sd.isra.2+0x34/0xb0
[  +0.008584] PGD 0

[  +0.006115] Oops:  [#1] SMP
[  +0.004531] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter 

[PATCH v3] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)

2017-01-17 Thread Aleksey Makarov
Enable the Extended Stream ID feature when available.

This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and IOVA reserved regions" by Eric Auger [1] allows to passthrough
an external PCIe network card on a ThunderX server successfully.

Without this patch that card caused a warning like

pci 0006:90:00.0: stream ID 0x9000 out of range for SMMU (0x7fff)

during boot.

[1] 
https://lkml.kernel.org/r/1484127714-3263-1-git-send-email-eric.au...@redhat.com

Signed-off-by: Aleksey Makarov 
---
v3:
- keep formatting of the comment
- fix printk message after the deleted chunk.  "[Do] not print a mask
  here, since it's not overly interesting in itself, and add_device will
  still show the offending mask in full if it ever actually matters (as in
  the commit message)." (Robin Murphy)

v2:
https://lkml.kernel.org/r/2017011614.29444-1-aleksey.maka...@linaro.org
- remove unnecessary parentheses (Robin Murphy)
- refactor testing SMR fields to after setting sCR0 as theirs width
  depends on sCR0_EXIDENABLE (Robin Murphy)

v1 (rfc):
https://lkml.kernel.org/r/20170110115755.19102-1-aleksey.maka...@linaro.org

 drivers/iommu/arm-smmu.c | 69 +---
 1 file changed, 48 insertions(+), 21 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 13d26009b8e0..861cc135722f 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -24,6 +24,7 @@
  * - v7/v8 long-descriptor format
  * - Non-secure access to the SMMU
  * - Context fault reporting
+ * - Extended Stream ID (16 bit)
  */
 
 #define pr_fmt(fmt) "arm-smmu: " fmt
@@ -87,6 +88,7 @@
 #define sCR0_CLIENTPD  (1 << 0)
 #define sCR0_GFRE  (1 << 1)
 #define sCR0_GFIE  (1 << 2)
+#define sCR0_EXIDENABLE(1 << 3)
 #define sCR0_GCFGFRE   (1 << 4)
 #define sCR0_GCFGFIE   (1 << 5)
 #define sCR0_USFCFG(1 << 10)
@@ -126,6 +128,7 @@
 #define ID0_NUMIRPT_MASK   0xff
 #define ID0_NUMSIDB_SHIFT  9
 #define ID0_NUMSIDB_MASK   0xf
+#define ID0_EXIDS  (1 << 8)
 #define ID0_NUMSMRG_SHIFT  0
 #define ID0_NUMSMRG_MASK   0xff
 
@@ -169,6 +172,7 @@
 #define ARM_SMMU_GR0_S2CR(n)   (0xc00 + ((n) << 2))
 #define S2CR_CBNDX_SHIFT   0
 #define S2CR_CBNDX_MASK0xff
+#define S2CR_EXIDVALID (1 << 10)
 #define S2CR_TYPE_SHIFT16
 #define S2CR_TYPE_MASK 0x3
 enum arm_smmu_s2cr_type {
@@ -354,6 +358,7 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_FMT_AARCH64_64K  (1 << 9)
 #define ARM_SMMU_FEAT_FMT_AARCH32_L(1 << 10)
 #define ARM_SMMU_FEAT_FMT_AARCH32_S(1 << 11)
+#define ARM_SMMU_FEAT_EXIDS(1 << 12)
u32 features;
 
 #define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
@@ -1051,7 +1056,7 @@ static void arm_smmu_write_smr(struct arm_smmu_device 
*smmu, int idx)
struct arm_smmu_smr *smr = smmu->smrs + idx;
u32 reg = smr->id << SMR_ID_SHIFT | smr->mask << SMR_MASK_SHIFT;
 
-   if (smr->valid)
+   if (!(smmu->features & ARM_SMMU_FEAT_EXIDS) && smr->valid)
reg |= SMR_VALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_SMR(idx));
 }
@@ -1063,6 +1068,9 @@ static void arm_smmu_write_s2cr(struct arm_smmu_device 
*smmu, int idx)
  (s2cr->cbndx & S2CR_CBNDX_MASK) << S2CR_CBNDX_SHIFT |
  (s2cr->privcfg & S2CR_PRIVCFG_MASK) << S2CR_PRIVCFG_SHIFT;
 
+   if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs &&
+   smmu->smrs[idx].valid)
+   reg |= S2CR_EXIDVALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_S2CR(idx));
 }
 
@@ -1073,6 +1081,34 @@ static void arm_smmu_write_sme(struct arm_smmu_device 
*smmu, int idx)
arm_smmu_write_smr(smmu, idx);
 }
 
+/*
+ * The width of SMR's mask field depends on sCR0_EXIDENABLE, so this function
+ * should be called after sCR0 is written.
+ */
+static void arm_smmu_test_smr_masks(struct arm_smmu_device *smmu)
+{
+   void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+   u32 smr;
+
+   if (!smmu->smrs)
+   return;
+
+   /*
+* SMR.ID bits may not be preserved if the corresponding MASK
+* bits are set, so check each one separately. We can reject
+* masters later if they try to claim IDs outside these masks.
+*/
+   smr = smmu->streamid_mask << SMR_ID_SHIFT;
+   writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+   smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
+   smmu->streamid_mask = smr >> SMR_ID_SHIFT;
+
+   smr = smmu->streamid_mask << SMR_MASK_SHIFT;
+   writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+   smr = 

Re: [PATCH v8 0/9] perf/amd/iommu: Enable multi-IOMMU support

2017-01-17 Thread Joerg Roedel
On Mon, Jan 16, 2017 at 01:23:27AM -0600, Suthikulpanit, Suravee wrote:
> Suravee Suthikulpanit (9):
>   perf/amd/iommu: Declare pr_fmt and remove unnecessary pr_debug
>   perf/amd/iommu: Clean up perf_iommu_enable_event
>   perf/amd/iommu: Misc fix up perf_iommu_read
>   iommu/amd: Introduce amd_iommu_get_num_iommus()
>   perf/amd/iommu: Modify functions to query max banks and counters
>   perf/amd/iommu: Modify amd_iommu_pc_get_set_reg_val() API to allow
> specifying IOMMU index
>   perf/amd/iommu: Check return value when set and get counter value
>   perf/amd/iommu: Fix sysfs perf attribute groups
>   perf/amd/iommu: Enable support for multiple IOMMUs

For the iommu changes:

Acked-by: Joerg Roedel 


Re: [PATCH] ACPI, APEI, EINJ: fix malformed newline escape

2017-01-17 Thread Borislav Petkov
On Tue, Jan 17, 2017 at 02:57:20PM +, Colin King wrote:
> From: Colin Ian King 
> 
> The pr_warn message has a malformed newline escape, add in the
> missing \
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/acpi/apei/einj.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
> index eebb7e3..ec50c32 100644
> --- a/drivers/acpi/apei/einj.c
> +++ b/drivers/acpi/apei/einj.c
> @@ -711,7 +711,7 @@ static int __init einj_init(void)
>  
>   rc = einj_check_table(einj_tab);
>   if (rc) {
> - pr_warn(FW_BUG "Invalid EINJ table.n");
> + pr_warn(FW_BUG "Invalid EINJ table.\n");
>   return -EINVAL;
>   }
>  
> -- 

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 


[PATCH] irqdomain: Avoid activating interrupts more than once

2017-01-17 Thread Marc Zyngier
Since commit f3b0946d629c ("genirq/msi: Make sure PCI MSIs are
activated early"), we can end-up activating a PCI/MSI twice (once
at allocation time, and once at startup time).

This is normally of no consequences, except that there is some
HW out there that may misbehave if activate is used more than once
(the GICv3 ITS, for example, uses the activate callback
to issue the MAPVI command, and the architecture spec says that
"If there is an existing mapping for the EventID-DeviceID
combination, behavior is UNPREDICTABLE").

While this could be worked around in each individual driver, it may
make more sense to tackle the issue at the core level. In order to
avoid getting in that situation, let's have a per-interrupt flag
to remember if we have already activated that interrupt or not.

Fixes: f3b0946d629c ("genirq/msi: Make sure PCI MSIs are activated early")
Reported-by: Andre Przywara 
Tested-by: Andre Przywara 
Signed-off-by: Marc Zyngier 
---
 include/linux/irq.h| 17 +
 kernel/irq/irqdomain.c | 44 ++--
 2 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index e798755..39e3254 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -184,6 +184,7 @@ struct irq_data {
  *
  * IRQD_TRIGGER_MASK   - Mask for the trigger type bits
  * IRQD_SETAFFINITY_PENDING- Affinity setting is pending
+ * IRQD_ACTIVATED  - Interrupt has already been activated
  * IRQD_NO_BALANCING   - Balancing disabled for this IRQ
  * IRQD_PER_CPU- Interrupt is per cpu
  * IRQD_AFFINITY_SET   - Interrupt affinity was set
@@ -202,6 +203,7 @@ struct irq_data {
 enum {
IRQD_TRIGGER_MASK   = 0xf,
IRQD_SETAFFINITY_PENDING= (1 <<  8),
+   IRQD_ACTIVATED  = (1 <<  9),
IRQD_NO_BALANCING   = (1 << 10),
IRQD_PER_CPU= (1 << 11),
IRQD_AFFINITY_SET   = (1 << 12),
@@ -312,6 +314,21 @@ static inline bool irqd_affinity_is_managed(struct 
irq_data *d)
return __irqd_to_state(d) & IRQD_AFFINITY_MANAGED;
 }
 
+static inline bool irqd_is_activated(struct irq_data *d)
+{
+   return __irqd_to_state(d) & IRQD_ACTIVATED;
+}
+
+static inline void irqd_set_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) |= IRQD_ACTIVATED;
+}
+
+static inline void irqd_clr_activated(struct irq_data *d)
+{
+   __irqd_to_state(d) &= ~IRQD_ACTIVATED;
+}
+
 #undef __irqd_to_state
 
 static inline irq_hw_number_t irqd_to_hwirq(struct irq_data *d)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 8c0a0ae..b59e676 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -1346,6 +1346,30 @@ void irq_domain_free_irqs_parent(struct irq_domain 
*domain,
 }
 EXPORT_SYMBOL_GPL(irq_domain_free_irqs_parent);
 
+static void __irq_domain_activate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (irq_data->parent_data)
+   __irq_domain_activate_irq(irq_data->parent_data);
+   if (domain->ops->activate)
+   domain->ops->activate(domain, irq_data);
+   }
+}
+
+static void __irq_domain_deactivate_irq(struct irq_data *irq_data)
+{
+   if (irq_data && irq_data->domain) {
+   struct irq_domain *domain = irq_data->domain;
+
+   if (domain->ops->deactivate)
+   domain->ops->deactivate(domain, irq_data);
+   if (irq_data->parent_data)
+   __irq_domain_deactivate_irq(irq_data->parent_data);
+   }
+}
+
 /**
  * irq_domain_activate_irq - Call domain_ops->activate recursively to activate
  *  interrupt
@@ -1356,13 +1380,9 @@ EXPORT_SYMBOL_GPL(irq_domain_free_irqs_parent);
  */
 void irq_domain_activate_irq(struct irq_data *irq_data)
 {
-   if (irq_data && irq_data->domain) {
-   struct irq_domain *domain = irq_data->domain;
-
-   if (irq_data->parent_data)
-   irq_domain_activate_irq(irq_data->parent_data);
-   if (domain->ops->activate)
-   domain->ops->activate(domain, irq_data);
+   if (!irqd_is_activated(irq_data)) {
+   __irq_domain_activate_irq(irq_data);
+   irqd_set_activated(irq_data);
}
 }
 
@@ -1376,13 +1396,9 @@ void irq_domain_activate_irq(struct irq_data *irq_data)
  */
 void irq_domain_deactivate_irq(struct irq_data *irq_data)
 {
-   if (irq_data && irq_data->domain) {
-   struct irq_domain *domain = irq_data->domain;
-
-   if (domain->ops->deactivate)
-   domain->ops->deactivate(domain, irq_data);
-   if (irq_data->parent_data)

Re: [PATCH] partitions/efi: Fix integer overflow in GPT size calculation

2017-01-17 Thread Ard Biesheuvel
On 15 January 2017 at 22:31, Alden Tondettar  wrote:
> If a GUID Partition Table claims to have more than 2**25 entries, the
> calculation of the partition table size in alloc_read_gpt_entries() will
> overflow a 32-bit integer and not enough space will be allocated for the
> table.
>
> Nothing seems to get written out of bounds, but later efi_partition() will
> read up to 32768 bytes from a 128 byte buffer, possibly OOPSing or exposing
> information to /proc/partitions and uevents.
>
> The problem exists on both 64-bit and 32-bit platforms.
>
> Fix the overflow and also print a meaningful debug message if the table
> size is too large.
>
> Signed-off-by: Alden Tondettar 

Acked-by: Ard Biesheuvel 

> ---
>  block/partitions/efi.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/block/partitions/efi.c b/block/partitions/efi.c
> index bcd86e5..39f70d9 100644
> --- a/block/partitions/efi.c
> +++ b/block/partitions/efi.c
> @@ -293,7 +293,7 @@ static gpt_entry *alloc_read_gpt_entries(struct 
> parsed_partitions *state,
> if (!gpt)
> return NULL;
>
> -   count = le32_to_cpu(gpt->num_partition_entries) *
> +   count = (size_t)le32_to_cpu(gpt->num_partition_entries) *
>  le32_to_cpu(gpt->sizeof_partition_entry);
> if (!count)
> return NULL;
> @@ -352,7 +352,7 @@ static int is_gpt_valid(struct parsed_partitions *state, 
> u64 lba,
> gpt_header **gpt, gpt_entry **ptes)
>  {
> u32 crc, origcrc;
> -   u64 lastlba;
> +   u64 lastlba, pt_size;
>
> if (!ptes)
> return 0;
> @@ -434,13 +434,20 @@ static int is_gpt_valid(struct parsed_partitions 
> *state, u64 lba,
> goto fail;
> }
>
> +   /* Sanity check partition table size */
> +   pt_size = (u64)le32_to_cpu((*gpt)->num_partition_entries) *
> +   le32_to_cpu((*gpt)->sizeof_partition_entry);
> +   if (pt_size > KMALLOC_MAX_SIZE) {
> +   pr_debug("GUID Partition Table is too large: %llu > %lu 
> bytes\n",
> +(unsigned long long)pt_size, KMALLOC_MAX_SIZE);
> +   goto fail;
> +   }
> +
> if (!(*ptes = alloc_read_gpt_entries(state, *gpt)))
> goto fail;
>
> /* Check the GUID Partition Entry Array CRC */
> -   crc = efi_crc32((const unsigned char *) (*ptes),
> -   le32_to_cpu((*gpt)->num_partition_entries) *
> -   le32_to_cpu((*gpt)->sizeof_partition_entry));
> +   crc = efi_crc32((const unsigned char *) (*ptes), pt_size);
>
> if (crc != le32_to_cpu((*gpt)->partition_entry_array_crc32)) {
> pr_debug("GUID Partition Entry Array CRC check failed.\n");
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

2017-01-17 Thread Alan Stern
On Mon, 16 Jan 2017, Felipe Balbi wrote:

> > The gadget driver never calls usb_ep_queue in order to receive the next
> > SETUP packet; the UDC driver takes care of SETUP handling
> > automatically.
> 
> yeah, that's another thing I'd like to change. Currently, we have no
> means to either try to implement device-initiated LPM without adding a
> ton of hacks to UDC drivers. If we require upper layers (composite.c,
> most of the time) to usb_ep_queue() separate requests for all 3 phases
> of a ctrl transfer, we can actually rely on the fact that a new SETUP
> phase hasn't been queued yet to trigger U3 entry.

I haven't given any thought to LPM.

However, requiring gadget drivers to request SETUP packets seems rather
questionable.  It flies against the USB spec, which requires
peripherals to accept SETUP packets at any time -- a device is not
allowed to NAK or STALL a SETUP packet (see 8.4.6.4 in the USB-2 spec).  
In fact, the hardware in UDCs probably isn't capable of doing it.

This means that to do what you want, the UDC driver would have to
accept SETUP packets at any time, and store the most recent packet
contents.  Then, when the gadget driver submits a request, the UDC
driver would give it this stored data.  It would also have to detect
and prevent a nasty race where the gadget driver tries to queue a
request on ep0 that is a response to an old SETUP, one that has already
been overwritten.  I'm not even sure preventing this race would be
possible in your scheme.

The advantage to invoking the gadget driver's setup callback directly
from the UDC driver's interrupt handler is that the gadget driver will
know immediately when an old SETUP has become stale.  (That's what
ep0_req_tag is for in f_mass_storage.)  It also provides a concurrency
guarantee, because the driver does not re-enable UDC SETUP interrupts 
until the handler is finished.

> Another detail that this helps is that PM (overall) becomes simpler as,
> most likely, we won't need to mess with transfer cancellation, for
> example.

System PM on a gadget is always troublesome.  Even if the USB 
connection is a wakeup source, it may not be possible to guarantee that 
the gadget can wake up quickly enough to handle an incoming packet.

> > You are suggesting that status stage requests should not be queued 
> > automatically by UDC drivers but instead queued explicitly by gadget 
> > drivers.  This would mean changing every UDC driver and every gadget 
> > driver.
> 
> yes, a bit of work but has been done before. One example that comes to
> mind is when I added ->udc_start() and ->udc_stop(). It's totally
> doable. We can, for instance, add a temporary
> "wants_explicit_ctrl_phases"  flag to struct usb_gadget which, if set,
> will tell composite.c (or whatever) that the UDC wants explicitly queued
> ctrl phases.

The term used in the USB spec is "stage", not "phase".  "Phase" refers
to the packets making up a single transaction: token, data, and
handshake.

Also, data stages are already explicit.  So your temporary flag might 
better be called "wants_explicit_status_stages".

> Then add support for that to each UDC and set the flag. Once all are
> converted, add one extra patch to remove the flag and the legacy
> code. This has, of course, the draw back of increasing complexity until
> everything is converted over; but if it's all done in a single series, I
> can't see any problems with that.
> 
> > Also, it won't fix the race that Baolin Wang found.  The setup routine
> 
> well, it will help... see below.
> 
> > is always called in interrupt context, so it can't sleep.  Doing
> > anything non-trivial will require a separate task, and it's possible
> > that this task will try to enqueue the data-stage or status-stage
> > request before the UDC driver is ready to handle it (for example, 
> > before or shortly after the setup routine returns).
> >
> > To work properly, the UDC driver must be able to accept a request for 
> > ep0 any time after it invokes the setup callback -- either before the 
> > callback returns or after.
> 
> Right, all UDCs are *already* required to support this case anyway
> because of USB_GADGET_DELAYED_STATUS. There was a bug in DWC3, sure, but
> it was already required to support this case.
> 
> By removing USB_GADGET_DELAYED_STATUS altogether and making phases more
> explict, we enforce this requirement and it'll be much easier to test
> for it IMO.

Okay, I can see the point of requiring explicit status requests.  
Implementing it will be a little tricky, because right now some status 
requests already are explicit (those for length-0 OUT transfers) while 
others are implicit.

(One possible approach would be to have the setup routine return 
different values for explicit and implicit status stages -- for 
example, return 1 if it wants to submit an explicit status request.  
That wouldn't be very different from the current 
USB_GADGET_DELAYED_STATUS approach.)

On the other hand, I am very doubtful about requiring 

Re: kvm: WARNING in mmu_spte_clear_track_bits

2017-01-17 Thread Dmitry Vyukov
On Tue, Jan 17, 2017 at 4:20 PM, Paolo Bonzini  wrote:
>
>
> On 13/01/2017 12:15, Dmitry Vyukov wrote:
>>
>> I've commented out the WARNING for now, but I am seeing lots of
>> use-after-free's and rcu stalls involving mmu_spte_clear_track_bits:
>>
>>
>> BUG: KASAN: use-after-free in mmu_spte_clear_track_bits+0x186/0x190
>> arch/x86/kvm/mmu.c:597 at addr 880068ae2008
>> Read of size 8 by task syz-executor2/16715
>> page:ea00016e6170 count:0 mapcount:0 mapping:  (null) index:0x0
>> flags: 0x500()
>> raw: 0500   
>> raw: ea00017ec5a0 ea0001783d48 88006aec5d98
>> page dumped because: kasan: bad access detected
>> CPU: 2 PID: 16715 Comm: syz-executor2 Not tainted 4.10.0-rc3+ #163
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:15 [inline]
>>  dump_stack+0x292/0x3a2 lib/dump_stack.c:51
>>  kasan_report_error mm/kasan/report.c:213 [inline]
>>  kasan_report+0x42d/0x460 mm/kasan/report.c:307
>>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:333
>>  mmu_spte_clear_track_bits+0x186/0x190 arch/x86/kvm/mmu.c:597
>>  drop_spte+0x24/0x280 arch/x86/kvm/mmu.c:1182
>>  kvm_zap_rmapp+0x119/0x260 arch/x86/kvm/mmu.c:1401
>>  kvm_unmap_rmapp+0x1d/0x30 arch/x86/kvm/mmu.c:1412
>>  kvm_handle_hva_range+0x54a/0x7d0 arch/x86/kvm/mmu.c:1565
>>  kvm_unmap_hva_range+0x2e/0x40 arch/x86/kvm/mmu.c:1591
>>  kvm_mmu_notifier_invalidate_range_start+0xae/0x140
>> arch/x86/kvm/../../../virt/kvm/kvm_main.c:360
>>  __mmu_notifier_invalidate_range_start+0x1f8/0x300 mm/mmu_notifier.c:199
>>  mmu_notifier_invalidate_range_start include/linux/mmu_notifier.h:282 
>> [inline]
>>  unmap_vmas+0x14b/0x1b0 mm/memory.c:1368
>>  unmap_region+0x2f8/0x560 mm/mmap.c:2460
>>  do_munmap+0x7b8/0xfa0 mm/mmap.c:2657
>>  mmap_region+0x68f/0x18e0 mm/mmap.c:1612
>>  do_mmap+0x6a2/0xd40 mm/mmap.c:1450
>>  do_mmap_pgoff include/linux/mm.h:2031 [inline]
>>  vm_mmap_pgoff+0x1a9/0x200 mm/util.c:305
>>  SYSC_mmap_pgoff mm/mmap.c:1500 [inline]
>>  SyS_mmap_pgoff+0x22c/0x5d0 mm/mmap.c:1458
>>  SYSC_mmap arch/x86/kernel/sys_x86_64.c:95 [inline]
>>  SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:86
>>  entry_SYSCALL_64_fastpath+0x1f/0xc2
>> RIP: 0033:0x445329
>> RSP: 002b:7fb33933cb58 EFLAGS: 0282 ORIG_RAX: 0009
>> RAX: ffda RBX: 2000 RCX: 00445329
>> RDX: 0003 RSI: 00af1000 RDI: 2000
>> RBP: 006dfe90 R08:  R09: 
>> R10: 0032 R11: 0282 R12: 0070
>> R13: 0006 R14:  R15: 20001000
>> Memory state around the buggy address:
>>  880068ae1f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>  880068ae1f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 880068ae2000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>   ^
>>  880068ae2080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>  880068ae2100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> ==
>
> This could be related to the gfn_to_rmap issues.


Humm... That's possible. Potentially I am not seeing any more of
spte-related crashes after I applied the following patch:

--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -968,8 +968,7 @@ int __kvm_set_memory_region(struct kvm *kvm,
/* Check for overlaps */
r = -EEXIST;
kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
-   if ((slot->id >= KVM_USER_MEM_SLOTS) ||
-   (slot->id == id))
+   if (slot->id == id)
continue;
if (!((base_gfn + npages <= slot->base_gfn) ||
  (base_gfn >= slot->base_gfn + slot->npages)))


ATTENZIONE;

2017-01-17 Thread amministratore
ATTENZIONE;

La cassetta postale ha superato il limite di archiviazione, che è 5 GB come 
definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si 
può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare 
la tua mailbox. Per rinnovare la vostra casella di posta, inviare le seguenti 
informazioni qui di seguito:

nome:
Nome utente:
Password:
Conferma Password:
E-mail:
telefono:

Se non si riesce a rinnovare la vostra casella di posta, la vostra caselladi 
posta sarà disabilitato!

Ci dispiace per l'inconvenienza.
Codice di verifica: en:0085362LK.ft6789000.2016 
Mail Technical Support ©2017

grazie
Sistemi amministratore


[PATCH 5/8] drm: mali-dp: Fix destination size handling when rotating

2017-01-17 Thread Liviu Dudau
From: Brian Starkey 

The destination rectangle provided by userspace in the CRTC_X/Y/W/H
properties is already expressed as the dimensions after rotation.
This means we shouldn't swap the width and height ourselves when a
90/270 degree rotation is requested, so remove the code doing the swap.

Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 69eba71253c9..8c5ce36147f3 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -187,13 +187,8 @@ static void malidp_de_plane_update(struct drm_plane *plane,
/* convert src values from Q16 fixed point to integer */
src_w = plane->state->src_w >> 16;
src_h = plane->state->src_h >> 16;
-   if (plane->state->rotation & MALIDP_ROTATED_MASK) {
-   dest_w = plane->state->crtc_h;
-   dest_h = plane->state->crtc_w;
-   } else {
-   dest_w = plane->state->crtc_w;
-   dest_h = plane->state->crtc_h;
-   }
+   dest_w = plane->state->crtc_w;
+   dest_h = plane->state->crtc_h;
 
malidp_hw_write(mp->hwdev, ms->format, mp->layer->base);
 
-- 
2.11.0



[PATCH 6/8] drm: mali-dp: Fix transposed horizontal/vertical flip

2017-01-17 Thread Liviu Dudau
From: Brian Starkey 

The horizontal and vertical flip flags were the wrong way around,
causing reflect-x to result in reflect-y being applied and vice-versa.
Fix them.

Fixes: ad49f8602fe8 ("drm/arm: Add support for Mali Display Processors")

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 8c5ce36147f3..629f634872a4 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -221,9 +221,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) << 
LAYER_ROT_OFFSET;
if (plane->state->rotation & DRM_REFLECT_X)
-   val |= LAYER_V_FLIP;
-   if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;
+   if (plane->state->rotation & DRM_REFLECT_Y)
+   val |= LAYER_V_FLIP;
 
/*
 * always enable pixel alpha blending until we have a way to change
-- 
2.11.0



[PATCH 2/8] drm: malidp: Remove event_list member from struct malidp_drm

2017-01-17 Thread Liviu Dudau
This struct member managed to outlive the submission process without
being removed. It is useless.

Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_drv.c | 2 --
 drivers/gpu/drm/arm/malidp_drv.h | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 32f746e31379..080f7631c672 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -286,7 +285,6 @@ static int malidp_bind(struct device *dev)
memcpy(hwdev, of_device_get_match_data(dev), sizeof(*hwdev));
malidp->dev = hwdev;
 
-   INIT_LIST_HEAD(>event_list);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hwdev->regs = devm_ioremap_resource(dev, res);
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 9fc8a2e405e4..dbc617c6e4ef 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -15,12 +15,12 @@
 
 #include 
 #include 
+#include 
 #include "malidp_hw.h"
 
 struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_fbdev_cma *fbdev;
-   struct list_head event_list;
struct drm_crtc crtc;
wait_queue_head_t wq;
atomic_t config_valid;
-- 
2.11.0



[PATCH 8/8] drm: mali-dp: Rename malidp_input_format to malidp_pixel_format

2017-01-17 Thread Liviu Dudau
From: Brian Starkey 

We're going to use the same format list for output formats, so rename
everything related to input formats to avoid confusion.

Signed-off-by: Brian Starkey 
[touched commit message to clarify the final struct name]
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_hw.c | 24 
 drivers/gpu/drm/arm/malidp_hw.h |  8 
 drivers/gpu/drm/arm/malidp_planes.c |  8 
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 4bdf531f7844..9ec6d6904f5e 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -21,7 +21,7 @@
 #include "malidp_drv.h"
 #include "malidp_hw.h"
 
-static const struct malidp_input_format malidp500_de_formats[] = {
+static const struct malidp_format_id malidp500_de_formats[] = {
/*fourcc,   layers supporting the format, internal id  */
{ DRM_FORMAT_ARGB2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2,  0 },
{ DRM_FORMAT_ABGR2101010, DE_VIDEO1 | DE_GRAPHICS1 | DE_GRAPHICS2,  1 },
@@ -69,7 +69,7 @@ static const struct malidp_input_format 
malidp500_de_formats[] = {
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) },\
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
 
-static const struct malidp_input_format malidp550_de_formats[] = {
+static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
 };
 
@@ -436,8 +436,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP500_DE_IRQ_CONF_VALID,
.vsync_irq = MALIDP500_DE_IRQ_CONF_VALID,
},
-   .input_formats = malidp500_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp500_de_formats),
+   .pixel_formats = malidp500_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp500_de_formats),
.bus_align_bytes = 8,
},
.query_hw = malidp500_query_hw,
@@ -469,8 +469,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
-   .input_formats = malidp550_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .pixel_formats = malidp550_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
.bus_align_bytes = 8,
},
.query_hw = malidp550_query_hw,
@@ -503,8 +503,8 @@ const struct malidp_hw_device 
malidp_device[MALIDP_MAX_DEVICES] = {
.irq_mask = MALIDP550_DC_IRQ_CONF_VALID,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
-   .input_formats = malidp550_de_formats,
-   .n_input_formats = ARRAY_SIZE(malidp550_de_formats),
+   .pixel_formats = malidp550_de_formats,
+   .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
@@ -522,10 +522,10 @@ u8 malidp_hw_get_format_id(const struct malidp_hw_regmap 
*map,
 {
unsigned int i;
 
-   for (i = 0; i < map->n_input_formats; i++) {
-   if (((map->input_formats[i].layer & layer_id) == layer_id) &&
-   (map->input_formats[i].format == format))
-   return map->input_formats[i].id;
+   for (i = 0; i < map->n_pixel_formats; i++) {
+   if (((map->pixel_formats[i].layer & layer_id) == layer_id) &&
+   (map->pixel_formats[i].format == format))
+   return map->pixel_formats[i].id;
}
 
return MALIDP_INVALID_FORMAT_ID;
diff --git a/drivers/gpu/drm/arm/malidp_hw.h b/drivers/gpu/drm/arm/malidp_hw.h
index 087e1202db3d..4f8c884d1960 100644
--- a/drivers/gpu/drm/arm/malidp_hw.h
+++ b/drivers/gpu/drm/arm/malidp_hw.h
@@ -35,7 +35,7 @@ enum {
DE_SMART = BIT(4),
 };
 
-struct malidp_input_format {
+struct malidp_format_id {
u32 format; /* DRM fourcc */
u8 layer;   /* bitmask of layers supporting it */
u8 id;  /* used internally */
@@ -85,9 +85,9 @@ struct malidp_hw_regmap {
const struct malidp_irq_map se_irq_map;
const struct malidp_irq_map dc_irq_map;
 
-   /* list of supported input formats for each layer */
-   const struct malidp_input_format *input_formats;
-   const u8 

[PATCH 4/8] drm: mali-dp: Don't force source size == crtc size

2017-01-17 Thread Liviu Dudau
From: Brian Starkey 

Remove the check enforcing that src_w and src_h match crtc_w and crtc_h,
as this prevents rotation from working.

The check was intended to disallow scaling, but
drm_plane_helper_check_state() does that for us, while also taking
rotation into account, so the removed check was redundant in any case.

Signed-off-by: Brian Starkey 
Signed-off-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/malidp_planes.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index f684fe4a80d2..69eba71253c9 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -135,8 +135,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
if ((state->crtc_w > mp->hwdev->max_line_size) ||
(state->crtc_h > mp->hwdev->max_line_size) ||
(state->crtc_w < mp->hwdev->min_line_size) ||
-   (state->crtc_h < mp->hwdev->min_line_size) ||
-   (state->crtc_w != src_w) || (state->crtc_h != src_h))
+   (state->crtc_h < mp->hwdev->min_line_size))
return -EINVAL;
 
/* packed RGB888 / BGR888 can't be rotated or flipped */
-- 
2.11.0



[PATCH 0/8] drm/mali-dp: Fixes for v4.11

2017-01-17 Thread Liviu Dudau
Hello,

Here is the collected list of patches that I have accumulated since last
December in my inbox. They are offered for review and comments before
I commit them to the mali-dp tree and they get added to linux-next.

Best regards,
Liviu

Brian Starkey (4):
  drm: mali-dp: Don't force source size == crtc size
  drm: mali-dp: Fix destination size handling when rotating
  drm: mali-dp: Fix transposed horizontal/vertical flip
  drm: mali-dp: Rename malidp_input_format to malidp_pixel_format

Liviu Dudau (2):
  drm: malidp: Remove event_list member from struct malidp_drm
  drm: mali-dp: Check more use cases in the plane's ->atomic_check()

Mihail Atanassov (1):
  drm: mali-dp: fix Lx_CONTROL register fields clobber

Shailendra Verma (1):
  drm/arm/malidp: Fix possible dereference of NULL

 drivers/gpu/drm/arm/malidp_drv.c|  2 --
 drivers/gpu/drm/arm/malidp_drv.h|  2 +-
 drivers/gpu/drm/arm/malidp_hw.c | 24 
 drivers/gpu/drm/arm/malidp_hw.h |  8 +++---
 drivers/gpu/drm/arm/malidp_planes.c | 57 +
 5 files changed, 50 insertions(+), 43 deletions(-)

-- 
2.11.0



Re: [PATCH v4 05/15] lockdep: Make check_prev_add can use a separate stack_trace

2017-01-17 Thread Peter Zijlstra
On Fri, Jan 13, 2017 at 07:11:43PM +0900, Byungchul Park wrote:
> What do you think about the following patches doing it?

I was more thinking about something like so...

Also, I think I want to muck with struct stack_trace; the members:
max_nr_entries and skip are input arguments to save_stack_trace() and
bloat the structure for no reason.

---
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 7c38f8f3d97b..f2df300a96ee 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -430,6 +430,21 @@ static int save_trace(struct stack_trace *trace)
return 1;
 }
 
+static bool return_trace(struct stack_trace *trace)
+{
+   /*
+* If @trace is the last trace generated by save_trace(), then we can
+* return the entries by simply subtracting @nr_stack_trace_entries
+* again.
+*/
+   if (trace->entries != stack_trace + nr_stack_trace_entries - 
trace->nr_entres)
+   return false;
+
+   nr_stack_trace_entries -= trace->nr_entries;
+   trace->entries = NULL;
+   return true;
+}
+
 unsigned int nr_hardirq_chains;
 unsigned int nr_softirq_chains;
 unsigned int nr_process_chains;
@@ -1797,20 +1812,12 @@ static inline void inc_chains(void)
  */
 static int
 check_prev_add(struct task_struct *curr, struct held_lock *prev,
-  struct held_lock *next, int distance, int *stack_saved)
+  struct held_lock *next, int distance, struct stack_trace *trace)
 {
struct lock_list *entry;
int ret;
struct lock_list this;
struct lock_list *uninitialized_var(target_entry);
-   /*
-* Static variable, serialized by the graph_lock().
-*
-* We use this static variable to save the stack trace in case
-* we call into this function multiple times due to encountering
-* trylocks in the held lock stack.
-*/
-   static struct stack_trace trace;
 
/*
 * Prove that the new  ->  dependency would not
@@ -1858,11 +1865,7 @@ static inline void inc_chains(void)
}
}
 
-   if (!*stack_saved) {
-   if (!save_trace())
-   return 0;
-   *stack_saved = 1;
-   }
+   trace->skip = 1; /* mark used */
 
/*
 * Ok, all validations passed, add the new lock
@@ -1870,14 +1873,14 @@ static inline void inc_chains(void)
 */
ret = add_lock_to_list(hlock_class(next),
   _class(prev)->locks_after,
-  next->acquire_ip, distance, );
+  next->acquire_ip, distance, trace);
 
if (!ret)
return 0;
 
ret = add_lock_to_list(hlock_class(prev),
   _class(next)->locks_before,
-  next->acquire_ip, distance, );
+  next->acquire_ip, distance, trace);
if (!ret)
return 0;
 
@@ -1885,8 +1888,6 @@ static inline void inc_chains(void)
 * Debugging printouts:
 */
if (verbose(hlock_class(prev)) || verbose(hlock_class(next))) {
-   /* We drop graph lock, so another thread can overwrite trace. */
-   *stack_saved = 0;
graph_unlock();
printk("\n new dependency: ");
print_lock_name(hlock_class(prev));
@@ -1908,10 +1909,15 @@ static inline void inc_chains(void)
 static int
 check_prevs_add(struct task_struct *curr, struct held_lock *next)
 {
+   struct stack_trace trace = { .nr_entries = 0, .skip = 0, };
int depth = curr->lockdep_depth;
-   int stack_saved = 0;
struct held_lock *hlock;
 
+   if (!save_trace())
+   goto out_bug;
+
+   trace.skip = 0; /* abuse to mark usage */
+
/*
 * Debugging checks.
 *
@@ -1936,7 +1942,7 @@ static inline void inc_chains(void)
 */
if (hlock->read != 2 && hlock->check) {
if (!check_prev_add(curr, hlock, next,
-   distance, _saved))
+   distance, ))
return 0;
/*
 * Stop after the first non-trylock entry,
@@ -1962,6 +1968,9 @@ static inline void inc_chains(void)
}
return 1;
 out_bug:
+   if (trace.nr_entries && !trace.skip)
+   return_trace();
+
if (!debug_locks_off_graph_unlock())
return 0;
 


Re: [PATCH 2/4] efi/x86: move efi bgrt init code to early init code

2017-01-17 Thread Ard Biesheuvel
On 16 January 2017 at 15:15, Bhupesh Sharma  wrote:
> Thanks Dave.
>
> On Fri, Jan 13, 2017 at 3:03 AM, Dave Young  wrote:
>> On 01/12/17 at 04:20pm, Ard Biesheuvel wrote:
>>> On 12 January 2017 at 09:41, Dave Young  wrote:
>>> > Before invoking the arch specific handler, efi_mem_reserve() reserves
>>> > the given memory region through memblock.
>>> >
>>> > efi_bgrt_init will call efi_mem_reserve after mm_init(), at that time
>>> > memblock is dead and it should not be used any more.
>>> >
>>> > efi bgrt code depend on acpi intialization to get the bgrt acpi table,
>>> > moving bgrt parsing to acpi early boot code can make sure efi_mem_reserve
>>> > in efi bgrt code still use memblock safely.
>>> >
>>> > Signed-off-by: Dave Young 
>>>
>>> I know this is probably out of scope for you, but since we're moving
>>> things around, any chance we could do so in a manner that will enable
>>> BGRT support for arm64/ACPI? Happy to test/collaborate on this.
>>>
>>
>> I'm happy to do so, Bhupesh Sharma  said he had
>> some investigation on that already, I would like to ask him to help on that.
>>
>> Already cced him..
>
>
> Hi Ard,
>
> I have started working on an implementation where most of the BGRT
> code which exists inside 'arch/x86/platform/efi-bgrt.c' can be reused
> for ARM/ARM64.
>
> I am testing a RFC approach for the same using Qemu for AARCH64. I
> have sent out a patch to enable BGRT support in ArmVirtPkg (see [1])
>
> I have one question regarding the placement of the early bgrt handling
> code so that it can be reused on both arm/arm64 and x86:
>
> - Should I consider moving the current code from
> arch/x86/platform/efi-bgrt.c to outside arch/x86 so that it can be
> used by both the ARCHs or should I reuse the existing x86 stuff in a
> ARM specific way - no mem_remap for e.g. in a find inside arch/arm -
> say efi-arm-bgrt.c
>

-ENOPARSE

Please first move the code from x86 to a generic location
(drivers/firmware/efi or drivers/acpi), and make sure that it still
works as expected.
Then you can modify the code so that it works for arm64 as well as
x86, in a separate patch.

Thanks,
Ard.

> Suggestions?
>
>
> [1] https://lists.01.org/pipermail/edk2-devel/2017-January/006588.html
>
> Regards,
> Bhupesh


Re: [PATCH 0/4] make call_usermodehelper a bit more "safe"

2017-01-17 Thread Kees Cook
On Mon, Jan 16, 2017 at 8:49 AM, Greg KH  wrote:
> Hi all,
>
> Here's a second cut at my attempt to make call_usermodehelper a bit more
> "safe".  It includes some patches from my previous series, and one new
> one.  In all, this is a much smaller patchset, with better functionality
> in the end.
>
> The issue is that if you end up getting write access to kernel memory,
> if you change the string '/sbin/hotplug' to point to
> '/home/hacked/my_binary', then the next uevent that the system makes
> will call this binary instead of the "trusted" one.
>
> This series addresses this issue by doing two different things.  The
> first 2 patches move a lot of existing call_usermodehelper binaries to
> read-only memory, preventing them from being able to be changed at all.
>
> The last patch introduces a new configuration option,
> STATIC_USERMODEHELPER.  This option routes all call_usermodehelper()
> calls to a single userspace binary.  That binary can then
> filter/mediate/blacklist/whitelist/whatever the "real" usermodehelper
> binaries and call them as needed (it determines the real one by looking
> at the first argument.)
>
> The location of this new binary can be set with the
> STATIC_USERMODEHELPER_PATH configuration option.
>
> If the user wants call_usermodehelper() to be disabled entirely,
> STATIC_USERMODEHELPER_PATH can be set to "", which will cause all
> call_usermodehelper() calls to do nothing, but return successful.
>
> Many thanks to the reviewers of the last patch series for their hints on
> how to mark strings properly to live in read-only memory always, and to
> Neil Brown for the idea of STATIC_USERMODEHELPER.
>
> If there are no complaints about these patches, I'll take them through
> my driver-core tree.

I like it! More things into .rodata. :)

Consider all three patches:

Acked-by: Kees Cook 

-Kees

-- 
Kees Cook
Nexus Security


Re: [PATCH] gpio: intel-mid: Fix build warning when !CONFIG_PM

2017-01-17 Thread Linus Walleij
On Mon, Jan 16, 2017 at 3:30 PM, Augusto Mecking Caringi
 wrote:

> The only usage of function intel_gpio_runtime_idle() is here (in the
> same file):
>
> static const struct dev_pm_ops intel_gpio_pm_ops = {
> SET_RUNTIME_PM_OPS(NULL, NULL, intel_gpio_runtime_idle)
> };
>
> And when CONFIG_PM is not set, the macro SET_RUNTIME_PM_OPS expands to
> nothing, causing the following compiler warning:
>
> drivers/gpio/gpio-intel-mid.c:324:12: warning: ‘intel_gpio_runtime_idle’
> defined but not used [-Wunused-function]
> static int intel_gpio_runtime_idle(struct device *dev)
>
> Fix it by annotating the function with __maybe_unused.
>
> Signed-off-by: Augusto Mecking Caringi 

Patch applied with Andy's ACK.

Yours,
Linus Walleij


[PATCH v3 0/2] hv_util: adjust system time smoothly

2017-01-17 Thread Vitaly Kuznetsov
With TimeSync version 4 protocol support we started updating system time
continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
there is a time sample from the host which triggers do_settimeofday[64]().
While the time from the host is very accurate such adjustments may cause
issues:
- Time is jumping forward and backward, some applications may misbehave.
- In case an NTP server runs in parallel and uses something else for time
  sync (network, PTP,...) system time will never converge.
- Systemd starts annoying you by printing "Time has been changed" every 5
  seconds to the system log.

Instead of doing in-kernel time adjustments offload the work to an
NTP client by exposing TimeSync messages as a PTP device. Users may now
decide what they want to use as a source.

Changes since v2:
- Implement Hyper-V PTP device instead of doint in-kernel time sync.

Changes since "[PATCH RFC] hv_utils: implement Hyper-V PTP source":
- Richard Cochran: implement .adjfreq, .adjtime, .settime64 returning
  -EOPNOTSUPP.
- Olaf Hering: change IS_ERR->IS_ERR_OR_NULL as CONFIG_PTP_1588_CLOCK
  can be disabled.
- Thomas Gleixner: formatting fixes, comments added.

Vitaly Kuznetsov (2):
  hv_util: switch to using timespec64
  hv_utils: implement Hyper-V PTP source

 drivers/hv/hv_util.c | 142 +--
 1 file changed, 116 insertions(+), 26 deletions(-)

-- 
2.9.3



[PATCH v9 5/5] ARM: configs: stm32: Add I2C support for STM32 defconfig

2017-01-17 Thread M'boumba Cedric Madianga
This patch adds I2C support for STM32 default configuration

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/configs/stm32_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig
index 5a72d69..323d2a3 100644
--- a/arch/arm/configs/stm32_defconfig
+++ b/arch/arm/configs/stm32_defconfig
@@ -47,6 +47,9 @@ CONFIG_SERIAL_NONSTANDARD=y
 CONFIG_SERIAL_STM32=y
 CONFIG_SERIAL_STM32_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_STM32F4=y
 # CONFIG_HWMON is not set
 # CONFIG_USB_SUPPORT is not set
 CONFIG_NEW_LEDS=y
-- 
1.9.1



[GIT PULL] MMC fixes for v.4.10 rc5

2017-01-17 Thread Ulf Hansson
Hi Linus,

Here are some mmc fixes intended for v4.9 rc5. They are based on v4.9-rc3.

Details are as usual found in the signed tag. Please pull this in!

Kind regards
Ulf Hansson


The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v4.10-rc3

for you to fetch changes up to ee6ff743e3a4b697e8286054667d7e4e1b56510d:

  mmc: core: Restore parts of the polling policy when switch to HS/HS
DDR (2017-01-16 16:17:42 +0100)


MMC core:
 - Fix regressions detecting HS/HS DDR eMMC cards related to CMD6

MMC host:
 - mmc: mxs-mmc: Fix additional cycles after transmission stop
 - sdhci-acpi: Only powered up enabled acpi child devices
 - meson: avoid possible NULL dereference


Hans de Goede (1):
  mmc: sdhci-acpi: Only powered up enabled acpi child devices

Heinrich Schuchardt (1):
  MMC: meson: avoid possible NULL dereference

Stefan Wahren (1):
  mmc: mxs-mmc: Fix additional cycles after transmission stop

Ulf Hansson (1):
  mmc: core: Restore parts of the polling policy when switch to HS/HS DDR

 drivers/mmc/core/mmc_ops.c  | 25 -
 drivers/mmc/host/meson-gx-mmc.c |  8 +---
 drivers/mmc/host/mxs-mmc.c  |  6 --
 drivers/mmc/host/sdhci-acpi.c   |  3 ++-
 4 files changed, 23 insertions(+), 19 deletions(-)


[PATCH v3 2/2] hv_utils: implement Hyper-V PTP source

2017-01-17 Thread Vitaly Kuznetsov
With TimeSync version 4 protocol support we started updating system time
continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
there is a time sample from the host which triggers do_settimeofday[64]().
While the time from the host is very accurate such adjustments may cause
issues:
- Time is jumping forward and backward, some applications may misbehave.
- In case an NTP server runs in parallel and uses something else for time
  sync (network, PTP,...) system time will never converge.
- Systemd starts annoying you by printing "Time has been changed" every 5
  seconds to the system log.

Instead of doing in-kernel time adjustments offload the work to an
NTP client by exposing TimeSync messages as a PTP device. Users may now
decide what they want to use as a source.

I tested the solution with chrony, the config was:

 refclock PHC /dev/ptp0 poll 3 precision 1e-9

The result I'm seeing is accurate enough, the time delta between the guest
and the host is almost always within [-10us, +10us], the in-kernel solution
was giving us comparable results.

I also tried implementing PPS device instead of PTP by using not currently
used Hyper-V synthetic timers (we use only one of four for clockevent) but
with PPS source only chrony wasn't able to give me the required accuracy,
the delta often more that 100us.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/hv_util.c | 140 ++-
 1 file changed, 115 insertions(+), 25 deletions(-)

diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
index 94719eb..e49c5f3 100644
--- a/drivers/hv/hv_util.c
+++ b/drivers/hv/hv_util.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hyperv_vmbus.h"
 
@@ -179,31 +180,35 @@ struct adj_time_work {
u8  flags;
 };
 
+static inline u64 get_timeadj_latency(u64 ref_time)
+{
+   u64 current_tick;
+
+   if (ts_srv_version <= TS_VERSION_3)
+   return 0;
+
+   /*
+* Some latency has been introduced since Hyper-V generated
+* its time sample. Take that latency into account before
+* using TSC reference time sample from Hyper-V.
+*
+* This sample is given by TimeSync v4 and above hosts.
+*/
+
+   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
+   return current_tick - ref_time;
+}
+
 static void hv_set_host_time(struct work_struct *work)
 {
struct adj_time_work*wrk;
-   s64 host_tns;
-   u64 newtime;
struct timespec64 host_ts;
+   u64 newtime;
 
wrk = container_of(work, struct adj_time_work, work);
 
-   newtime = wrk->host_time;
-   if (ts_srv_version > TS_VERSION_3) {
-   /*
-* Some latency has been introduced since Hyper-V generated
-* its time sample. Take that latency into account before
-* using TSC reference time sample from Hyper-V.
-*
-* This sample is given by TimeSync v4 and above hosts.
-*/
-   u64 current_tick;
-
-   rdmsrl(HV_X64_MSR_TIME_REF_COUNT, current_tick);
-   newtime += (current_tick - wrk->ref_time);
-   }
-   host_tns = (newtime - WLTIMEDELTA) * 100;
-   host_ts = ns_to_timespec64(host_tns);
+   newtime = wrk->host_time + get_timeadj_latency(wrk->ref_time);
+   host_ts = ns_to_timespec64((newtime - WLTIMEDELTA) * 100);
 
do_settimeofday64(_ts);
 }
@@ -222,22 +227,52 @@ static void hv_set_host_time(struct work_struct *work)
  * to discipline the clock.
  */
 static struct adj_time_work  wrk;
-static inline void adj_guesttime(u64 hosttime, u64 reftime, u8 flags)
+
+/*
+ * The last time sample, received from the host. PTP device responds to
+ * requests by using this data and the current partition-wide time reference
+ * count.
+ */
+static struct {
+   u64 host_time;
+   u64 ref_time;
+   spinlock_t  lock;
+} host_ts;
+
+static inline void adj_guesttime(u64 hosttime, u64 reftime, u8 adj_flags)
 {
+   unsigned long flags;
 
/*
 * This check is safe since we are executing in the
 * interrupt context and time synch messages arre always
 * delivered on the same CPU.
 */
-   if (work_pending())
-   return;
+   if (adj_flags & ICTIMESYNCFLAG_SYNC) {
+   if (work_pending())
+   return;
 
-   wrk.host_time = hosttime;
-   wrk.ref_time = reftime;
-   wrk.flags = flags;
-   if ((flags & (ICTIMESYNCFLAG_SYNC | ICTIMESYNCFLAG_SAMPLE)) != 0) {
+   wrk.host_time = hosttime;
+   wrk.ref_time = reftime;
+   wrk.flags = adj_flags;
schedule_work();
+   } else {
+   spin_lock_irqsave(_ts.lock, flags);
+   host_ts.host_time = hosttime;
+
+   /*
+* Prior to version 4 

[PATCH v9 4/5] ARM: dts: stm32: Add I2C1 support for STM32429 eval board

2017-01-17 Thread M'boumba Cedric Madianga
This patch adds I2C1 instance support for STM32x9I-Eval board.

Signed-off-by: M'boumba Cedric Madianga 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 76f7206..c943539 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -146,3 +146,9 @@
pinctrl-names = "default";
status = "okay";
 };
+
+ {
+   pinctrl-0 = <_pins_b>;
+   pinctrl-names = "default";
+   status = "okay";
+};
-- 
1.9.1



[PATCH 10/13] MIPS: loongson64: fix empty-body warning in dma_alloc

2017-01-17 Thread Arnd Bergmann
A new gcc warning shows up for this old code with gcc-6:

arch/mips/loongson64/common/dma-swiotlb.c: In function 
'loongson_dma_alloc_coherent':
arch/mips/loongson64/common/dma-swiotlb.c:35:2: error: suggest braces around 
empty body in an 'else' statement [-Werror=empty-body]

The code can be easily restructured to look more readable
and avoid the warning at the same time.

Signed-off-by: Arnd Bergmann 
---
 arch/mips/loongson64/common/dma-swiotlb.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/arch/mips/loongson64/common/dma-swiotlb.c 
b/arch/mips/loongson64/common/dma-swiotlb.c
index aab4fd681e1f..df7235e33499 100644
--- a/arch/mips/loongson64/common/dma-swiotlb.c
+++ b/arch/mips/loongson64/common/dma-swiotlb.c
@@ -17,22 +17,14 @@ static void *loongson_dma_alloc_coherent(struct device 
*dev, size_t size,
/* ignore region specifiers */
gfp &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM);
 
-#ifdef CONFIG_ISA
-   if (dev == NULL)
+   if ((IS_ENABLED(CONFIG_ISA) && dev == NULL) ||
+   (IS_ENABLED(CONFIG_ZONE_DMA) &&
+dev->coherent_dma_mask < DMA_BIT_MASK(32)))
gfp |= __GFP_DMA;
-   else
-#endif
-#ifdef CONFIG_ZONE_DMA
-   if (dev->coherent_dma_mask < DMA_BIT_MASK(32))
-   gfp |= __GFP_DMA;
-   else
-#endif
-#ifdef CONFIG_ZONE_DMA32
-   if (dev->coherent_dma_mask < DMA_BIT_MASK(40))
+   else if (IS_ENABLED(CONFIG_ZONE_DMA32) &&
+dev->coherent_dma_mask < DMA_BIT_MASK(40))
gfp |= __GFP_DMA32;
-   else
-#endif
-   ;
+
gfp |= __GFP_NORETRY;
 
ret = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
-- 
2.9.0



Re: [patch 3/3] PTP: add kvm PTP driver

2017-01-17 Thread Radim Krcmar
2017-01-17 09:30-0200, Marcelo Tosatti:
> On Tue, Jan 17, 2017 at 09:03:27AM +0100, Miroslav Lichvar wrote:
>> On Mon, Jan 16, 2017 at 06:01:14PM -0200, Marcelo Tosatti wrote:
>> > On Mon, Jan 16, 2017 at 05:47:15PM -0200, Marcelo Tosatti wrote:
>> > > On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote:
>> > > > Sorry, unless i am misunderstanding how this works, it'll get the 
>> > > > guest clock
>> > > > 2us behind, which is something not wanted.
>> > > > 
>> > > > Miroslav, if ->gettime64 returns the host realtime at 2us in the past, 
>> > > > this means Chrony will sync the guest clock to
>> > > > 
>> > > > host realtime - 2us
>> > > > 
>> > > > Is that correct?
>> 
>> Probably. It depends on the error of both host and guest timestamps.
>> If the error is the same on both sides, it will cancel out. An
>> occasional spike in the delay shouldn't be a problem as the reading
>> will be filtered out, but for best accuracy it's necessary that the
>> host's timestamp is taken in the middle between the guest's
>> timestamps.
> 
> The problem is that spikes can be far from occasional: it depends on activity 
> of
> the host CPU and interrupts. Whose delay can be "intermittent": as long
> as interrupts are being sent to the host CPU, for example, the delay
> will be high (which can last minutes).
> 
> The TSC reading in the guest KVM PTP driver corrects for that delay.
> 
>> Users of the PTP_SYS_OFFSET ioctl assume that (ts[0]+ts[2])/2
>> corresponds to ts[1], (ts[2]+ts[4])/2 corresponds to ts[3], and so on.
>> 
>> ts[1] ts[3]
>> Host time-+-+
>>   | |
>>   | |
>> Guest time   +-+-+..
>> ts[0]ts[2] ts[4]

KVM PTP delay moves host ts[i] to be close to guest ts[i+1] and makes
the offset very consistent, so the graph would look like:

ts[1] ts[3]
Host time-+-+
  | |
  | |
Guest time   +-+-+..
ts[0]ts[2] ts[4]

which doesn't sound good if users assume that the host reading is in the
middle -- the guest time would be ahead of the host time.

I'm wondering why is the PTP precision around 10ns, when the hypercall
takes around 2-3k cycles.  Have you measured the guest<->host offset by
getting the output of the hypercall, i.e.
  {host_sec @ tsc, host_nsec @ tsc, tsc}
and comparing it with guest time computed from the same tsc, i.e.
  {guest_sec @ tsc, guest_nsec @ tsc}
?

Thanks.


[PATCH v2 1/4] dt-bindings: phy: Add documentation for NSP USB3 PHY

2017-01-17 Thread Yendapally Reddy Dhananjaya Reddy
Add documentation for USB3 PHY available in Northstar plus SoC

Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
---
 .../devicetree/bindings/phy/brcm,nsp-usb3-phy.txt  | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt 
b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
new file mode 100644
index 000..e68ae5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,nsp-usb3-phy.txt
@@ -0,0 +1,39 @@
+Broadcom USB3 phy binding for northstar plus SoC
+The USB3 phy is internal to the SoC and is accessed using mdio interface.
+
+Required mdio bus properties:
+- reg: Should be 0x0 for SoC internal USB3 phy
+- #address-cells: must be 1
+- #size-cells: must be 0
+
+Required USB3 PHY properties:
+- compatible: should be "brcm,nsp-usb3-phy"
+- reg: USB3 Phy address on SoC internal MDIO bus and it should be 0x10.
+- usb3-ctrl-syscon: handler of syscon node defining physical address
+  of usb3 control register.
+- #phy-cells: must be 0
+
+Required usb3 control properties:
+- compatible: should be "brcm,nsp-usb3-ctrl"
+- reg: offset and length of the control registers
+
+Example:
+
+   mdio@0 {
+   reg = <0x0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb3_phy: usb-phy@10 {
+   compatible = "brcm,nsp-usb3-phy";
+   reg = <0x10>;
+   usb3-ctrl-syscon = <_ctrl>;
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+   };
+
+   usb3_ctrl: syscon@104408 {
+   compatible = "brcm,nsp-usb3-ctrl", "syscon";
+   reg = <0x104408 0x3fc>;
+   };
-- 
2.1.0



[PATCH 08/10] perf sched timehist: Show total wait times for summary

2017-01-17 Thread Arnaldo Carvalho de Melo
From: Namhyung Kim 

When --state option is given, the summary will show total run, sleep,
iowait, preempt and delay time instead of statistics of runtime.

  $ perf sched timehist -s --state

  Wait-time summary
comm  parent sched-in run-time  sleep iowait preempt delay
  (count)   (msec) (msec) (msec)  (msec) (msec)
  -
   systemd[1]  030.497   1.685 0.000   0.000 0.061
   ksoftirqd/0[3]  2   210.434 989.948 0.000   0.000 0.325
   rcu_preempt[7]  2   280.386 993.211 0.000   0.000 0.712
  migration/0[10]  2   120.126  50.174 0.000   0.000 0.044
   watchdog/0[11]  210.009   0.000 0.000   0.000 0.016
  migration/1[13]  220.029  11.755 0.000   0.000 0.007
  

Signed-off-by: Namhyung Kim 
Tested-by: Arnaldo Carvalho de Melo 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Minchan Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20170113104523.31212-3-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-sched.c | 44 +---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index a8ac76602187..daceb3202200 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -241,6 +241,10 @@ struct thread_runtime {
 
struct stats run_stats;
u64 total_run_time;
+   u64 total_sleep_time;
+   u64 total_iowait_time;
+   u64 total_preempt_time;
+   u64 total_delay_time;
 
int last_state;
u64 migrations;
@@ -2008,7 +2012,12 @@ static void timehist_update_runtime_stats(struct 
thread_runtime *r,
}
 
update_stats(>run_stats, r->dt_run);
-   r->total_run_time += r->dt_run;
+
+   r->total_run_time += r->dt_run;
+   r->total_delay_time   += r->dt_delay;
+   r->total_sleep_time   += r->dt_sleep;
+   r->total_iowait_time  += r->dt_iowait;
+   r->total_preempt_time += r->dt_preempt;
 }
 
 static bool is_idle_sample(struct perf_sample *sample,
@@ -2593,7 +2602,26 @@ static void print_thread_runtime(struct thread *t,
printf("\n");
 }
 
+static void print_thread_waittime(struct thread *t,
+ struct thread_runtime *r)
+{
+   printf("%*s   %5d  %9" PRIu64 " ",
+  comm_width, timehist_get_commstr(t), t->ppid,
+  (u64) r->run_stats.n);
+
+   print_sched_time(r->total_run_time, 8);
+   print_sched_time(r->total_sleep_time, 6);
+   printf(" ");
+   print_sched_time(r->total_iowait_time, 6);
+   printf(" ");
+   print_sched_time(r->total_preempt_time, 6);
+   printf(" ");
+   print_sched_time(r->total_delay_time, 6);
+   printf("\n");
+}
+
 struct total_run_stats {
+   struct perf_sched *sched;
u64  sched_count;
u64  task_count;
u64  total_run_time;
@@ -2612,7 +2640,11 @@ static int __show_thread_runtime(struct thread *t, void 
*priv)
stats->task_count++;
stats->sched_count += r->run_stats.n;
stats->total_run_time += r->total_run_time;
-   print_thread_runtime(t, r);
+
+   if (stats->sched->show_state)
+   print_thread_waittime(t, r);
+   else
+   print_thread_runtime(t, r);
}
 
return 0;
@@ -2700,18 +2732,24 @@ static void timehist_print_summary(struct perf_sched 
*sched,
u64 hist_time = sched->hist_time.end - sched->hist_time.start;
 
memset(, 0, sizeof(totals));
+   totals.sched = sched;
 
if (sched->idle_hist) {
printf("\nIdle-time summary\n");
printf("%*s  parent  sched-out  ", comm_width, "comm");
printf("  idle-time   min-idleavg-idlemax-idle  stddev  
migrations\n");
+   } else if (sched->show_state) {
+   printf("\nWait-time summary\n");
+   printf("%*s  parent   sched-in  ", comm_width, "comm");
+   printf("   run-time  sleep  iowait preempt   
delay\n");
} else {
printf("\nRuntime summary\n");
printf("%*s  parent   sched-in  ", comm_width, "comm");
printf("   run-timemin-run avg-run max-run  stddev  
migrations\n");
}
printf("%*s(count)  ", comm_width, "");
-   printf(" (msec) (msec)  (msec)  (msec)   %%\n");
+   printf(" (msec) (msec)  (msec)  (msec)   %s\n",
+  sched->show_state ? "(msec)" : "%");
printf("%.117s\n", graph_dotted_line);
 
machine__for_each_thread(m, 

[PATCH v2 4/4] arm: dts: nsp: Add USB nodes to device tree

2017-01-17 Thread Yendapally Reddy Dhananjaya Reddy
Add USB nodes to the Northstar plus device tree file

Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
---
 arch/arm/boot/dts/bcm-nsp.dtsi   | 56 
 arch/arm/boot/dts/bcm958625k.dts | 16 
 2 files changed, 72 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index b6142bd..94b3231 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -259,6 +259,34 @@
status = "disabled";
};
 
+   xhci: usb@29000 {
+   compatible = "generic-xhci";
+   reg = <0x29000 0x1000>;
+   interrupts = ;
+   phys = <_phy>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
+   ehci0: usb@2a000 {
+   compatible = "generic-ehci";
+   reg = <0x2a000 0x100>;
+   interrupts = ;
+   status = "disabled";
+   };
+
+   ohci0: usb@2b000 {
+   compatible = "generic-ohci";
+   reg = <0x2b000 0x100>;
+   interrupts = ;
+   status = "disabled";
+   };
+
+   mdio: mdio@32000 {
+   compatible = "brcm,iproc-mdio";
+   reg = <0x32000 0x8>;
+   };
+
rng: rng@33000 {
compatible = "brcm,bcm-nsp-rng";
reg = <0x33000 0x14>;
@@ -358,6 +386,29 @@
 "sata2";
};
 
+   mdio-mux {
+   compatible = "mdio-mux-mmioreg";
+   mdio-parent-bus = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x32000 0x4>;
+   mux-mask = <0x200>;
+
+   mdio@0 {
+   reg = <0x00>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb3_phy: usb-phy@10 {
+   compatible = "brcm,nsp-usb3-phy";
+   reg = <0x10>;
+   usb3-ctrl-syscon = <_ctrl>;
+   #phy-cells = <0>;
+   status = "disabled";
+   };
+   };
+   };
+
pinctrl: pinctrl@3f1c0 {
compatible = "brcm,nsp-pinmux";
reg = <0x3f1c0 0x04>,
@@ -406,6 +457,11 @@
phy-names = "sata-phy";
};
};
+
+   usb3_ctrl: syscon@104408 {
+   compatible = "brcm,nsp-usb3-ctrl", "syscon";
+   reg = <0x104408 0x3fc>;
+   };
};
 
pcie0: pcie@18012000 {
diff --git a/arch/arm/boot/dts/bcm958625k.dts b/arch/arm/boot/dts/bcm958625k.dts
index 59d96fb..1da22dc 100644
--- a/arch/arm/boot/dts/bcm958625k.dts
+++ b/arch/arm/boot/dts/bcm958625k.dts
@@ -53,6 +53,22 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.1.0



Re: [PATCH -next] init/main: Init jump_labels before they are used to build zonelists

2017-01-17 Thread Vlastimil Babka
On 01/17/2017 03:30 PM, Stafford Horne wrote:
> On Tue, Jan 17, 2017 at 02:44:54PM +0100, Peter Zijlstra wrote:
>> On Tue, Jan 17, 2017 at 02:07:36PM +0100, Vlastimil Babka wrote:
>>
>>> Anyway I'm not sure if this patch is safe. Hopefully Peter can judge
>>> this better...
>>>
 Cc: Vlastimil Babka 
 Signed-off-by: Stafford Horne 
 ---
  init/main.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/init/main.c b/init/main.c
 index 8b1adb6e..d1ca7cb 100644
 --- a/init/main.c
 +++ b/init/main.c
 @@ -513,6 +513,7 @@ asmlinkage __visible void __init start_kernel(void)
boot_cpu_state_init();
smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */
  
 +  jump_label_init();
build_all_zonelists(NULL, NULL);
page_alloc_init();
  
 @@ -526,8 +527,6 @@ asmlinkage __visible void __init start_kernel(void)
parse_args("Setting init args", after_dashes, NULL, 0, -1, -1,
   NULL, set_init_arg);
  
 -  jump_label_init();
 -
>>
>> Urgh, that means auditing all archs that implement this. The thing
>> you're looking for is if the self-modifying code cruft can be done that
>> early.
>>
>> x86 looks to be fine, because this is after setup_arch() which is
>> required for ideal_nops[] to be initialied and we use text_poke_early()
>> which doesn't really need anything else.
>>
>> I've not gone through the other arches...
> 
> Vlastimil,
> 
> Will you be able to look into that? Openrisc doesnt have jump_label
> support, so its no issue at the moment.
> 
> Archs that do have it:
> 
> arch/arm64/Kconfig: select HAVE_ARCH_JUMP_LABEL
> arch/mips/Kconfig:  select HAVE_ARCH_JUMP_LABEL
> arch/s390/Kconfig:  select HAVE_ARCH_JUMP_LABEL
> arch/sparc/Kconfig: select HAVE_ARCH_JUMP_LABEL if SPARC64
> arch/tile/Kconfig:  select HAVE_ARCH_JUMP_LABEL
> arch/x86/Kconfig:   select HAVE_ARCH_JUMP_LABEL
> arch/arm/Kconfig:   select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && 
> !CPU_ENDIAN_BE32 && MMU
> arch/powerpc/Kconfig:   select HAVE_ARCH_JUMP_LABEL
> 
> I looked at a few (arm, tile) and I dont see their arch_jump_label_transform*
> implementations depending on global state like ideal_nops from x86. They
> should be ok.

Thanks, I'll try.

> If no time, Should you change your patch to not use static keys for
> build_all_zonelists at least?

Yes that would be uglier but possible if I find issues or I'm not
confident enough with the auditing...



Re: [PATCH] tpm: add session handles to the save and restore of the tpm2 space manager

2017-01-17 Thread Jarkko Sakkinen
On Tue, Jan 17, 2017 at 06:18:12AM -0800, James Bottomley wrote:
> On Tue, 2017-01-17 at 09:23 +0200, Jarkko Sakkinen wrote:
> > On Mon, Jan 16, 2017 at 03:18:45PM -0800, James Bottomley wrote:
> > > On Mon, 2017-01-16 at 12:04 +0200, Jarkko Sakkinen wrote:
> > > > On Fri, Jan 13, 2017 at 11:24:13AM -0800, James Bottomley wrote:
> > > > > Session handles are slightly more difficult to manage because
> > > > > any
> > > > > TPM
> > > > > only has a finite number of allowed handles, even if the
> > > > > session
> > > > > has
> > > > > been saved; so when you context save a session, you must not
> > > > > flush
> > > > > it
> > > > > because that would destroy the ability to context load it (you
> > > > > only
> > > > > flush sessions when you're done with them) and the tpm won't re
> > > > > -use
> > > > > the handle.  Additionally, sessions can be flushed as part of
> > > > > the
> > > > > successful execution of a command if the continueSession
> > > > > attribute
> > > > > is
> > > > > clear, so we have to mark any session we find in the command
> > > > > (using
> > > > > TPM2_HT_TAG_FOR_FLUSH) so it can be cleared from the space if
> > > > > the
> > > > > command successfully executes.
> > > > > 
> > > > > Finally, a session may also be cleared by flushing it, so we
> > > > > have
> > > > > to
> > > > > emulate the TPM2_FlushContext command to see if a session is
> > > > > being
> > > > > flushed and manually clear it from the space.
> > > > > 
> > > > > We also fully flush all sessions on device close.
> > > > 
> > > > Some big overview comments without going deeply into details. I
> > > > will
> > > > use more time for this once the 
> > > > 
> > > > Please do not use handle allocation code for sessions. This
> > > > commit
> > > > makes the implementation a mess. Just use the phandle directly
> > > > and
> > > > have array of session phandles for each space.
> > > > 
> > > > I would also almost require to have at minimum two patches: one
> > > > that
> > > > implements purely isolation and another that implements swapping.
> > > > 
> > > > It might be for example that I want to land TPM spaces with
> > > > session
> > > > isolation to one release and swapping to n+1 because my hunch
> > > > tells
> > > > me that it is better to bake the swapping part for a while.
> > > > 
> > > > One more thing. Maybe commit messages should speak uniformally
> > > > about
> > > > TPM spaces? They are a tool to implement resource manager, not a
> > > > resource manager.
> > > 
> > > Yes, so Ken also had a reply to this which the Mailing List seems
> > > to
> > > have eaten:
> > > 
> > > > This looks like session handles are virtualized.  I believe that
> > > > this 
> > > > will break the HMAC for commands (e.g. TPM2_PolicySecret) that
> > > > have
> > > > a session handle in the handle area.  The session's handle is its
> > > > "Name" and is included in the cpHash (command parameter hash)
> > > > data 
> > > > that is HMACed. 
> > > 
> > > Basically this means that the advice to virtualize session handles
> > > in
> > > the TCG RM document is wrong and we have to use physical handles.
> > > I'll
> > > redo the implementation for this ... and now, since we'll have
> > > nothing
> > > to use as an index, it probably does make sense to have sessions in
> > > a
> > > separate array.  I can also separate isolation from context
> > > switching
> > > ... although I really think this is less optimal: my TPM only
> > > allows
> > > three active context handles, so if we don't context switch them
> > > identially to transient object (which it also only allows three of)
> > > I'm
> > > going to run out.  I actually redid my openssl_tpm_engine patches
> > > so
> > > they use session handles for parameter encryption and HMAC based
> > > authority, so this may end up biting me soon ...
> > > 
> > > James
> > 
> > This might be obvious to you but saying this just in case: everytime 
> > a session handle is created, you must traverse through struct 
> > tpm_space instances and check if they have that physical handle and 
> > remove it so that they don't leak.
> 
> Actually, the code pre-emptively manages handles, so it ensures that we
> actively collect them (in the flush emulation and the command attribute
> processing).  I've got an unpublished patch that actually does global
> session management, but it's part of the resource exhaustion stuff
> which I'm still testing.
> 
> Note that when we save contexts, there's no need even to check.  If a
> handle gets re-used, the old context won't load.

Yes, I understand. In that way swapping simplifies things like it does
with transient objects.

> > I would probably just create a linked list of struct tpm_space
> > instances. Radix tree does not make much sense with the amount of
> > sessions you might except to have on a system simultaneously.
> 
> Global array.  The tpm has a small limit for total number of sessions
> TPM_PT_SESSIONS_MAX (it's about 64 in every TPM I've seen).

[x]

> 

Re: [PATCHv2] firmware: Correct handling of fw_state_wait_timeout() return value

2017-01-17 Thread Jakub Kicinski
On Tue, Jan 17, 2017 at 8:21 AM, Luis R. Rodriguez  wrote:
>>>
>>>   retval = fw_state_wait_timeout(>fw_st, timeout);
>>> - if (retval < 0) {
>>> + if (retval == -ETIMEDOUT || retval == -ERESTARTSYS) {
>>>   mutex_lock(_lock);
>>>   fw_load_abort(fw_priv);
>>>   mutex_unlock(_lock);
>>
>> This is a bit messy, two other similar issues were reported before
>> and upon review I suggested Patrick Bruenn's fix with a better commit
>> log seems best fit. Patrick sent a patch Jan 4, 2017 but never followed up
>> despite my feedback on a small change on the commit log message [0]. Can you
>> try that and if that fixes it can you adjust the commit log accordingly? 
>> Please
>> note the preferred solution would be:
>>
>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> index b9ac348e8d33..c530f8b4af01 100644
>> --- a/drivers/base/firmware_class.c
>> +++ b/drivers/base/firmware_class.c
>> @@ -542,6 +542,8 @@ static struct firmware_priv *to_firmware_priv(struct 
>> device *dev)
>>
>>  static void __fw_load_abort(struct firmware_buf *buf)
>>  {
>> +   if (!buf)
>> +   return;

Allow me to try to persuade you one last time :)  My patch makes the
code more logical and easier to follow.  The code says:
in case no wake up happened - finish the wait (otherwise the waking
thread finishes it).  Adding a NULL-check would just paper over the
issue and can cause trouble down the line.  If fw_state_wait_timeout()
returned because someone woke it up - there is no reason to abort the
wait.  The wait is already finished. The buggy commit mixed up return
codes from fw_state_wait_timeout() - mixed "nobody woke us up" with
"we couldn't find the FW", that's why we need to check for specific
error codes.


Re: [PATCH 07/46] selinux: Delete unnecessary variable assignments in policydb_index()

2017-01-17 Thread Casey Schaufler
On 1/15/2017 7:04 AM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 14 Jan 2017 13:40:25 +0100
>
> The local variable "rc" was reset with an error code up to five times
> before a memory allocation failure was detected.
>
> Add a jump target so that this assignment will only be performed after
> a concrete software failure.
>
> Signed-off-by: Markus Elfring 

Of course the maintainers get the call on this,
but I see this as an example of the kind of code
that led to the "gotos considered harmful" mindset.
What value does it add? All I see is unnecessary
code churn. And a backwards goto.


> ---
>  security/selinux/ss/policydb.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
> index 21869b622c0c..4d4ba1ad910d 100644
> --- a/security/selinux/ss/policydb.c
> +++ b/security/selinux/ss/policydb.c
> @@ -539,34 +539,30 @@ static int policydb_index(struct policydb *p)
>   symtab_hash_eval(p->symtab);
>  #endif
>  
> - rc = -ENOMEM;
>   p->class_val_to_struct = kcalloc(p->p_classes.nprim,
>sizeof(*p->class_val_to_struct),
>GFP_KERNEL);
>   if (!p->class_val_to_struct)
> - goto out;
> + goto failure_indication;
>  
> - rc = -ENOMEM;
>   p->role_val_to_struct = kcalloc(p->p_roles.nprim,
>   sizeof(*p->role_val_to_struct),
>   GFP_KERNEL);
>   if (!p->role_val_to_struct)
> - goto out;
> + goto failure_indication;
>  
> - rc = -ENOMEM;
>   p->user_val_to_struct = kcalloc(p->p_users.nprim,
>   sizeof(*p->user_val_to_struct),
>   GFP_KERNEL);
>   if (!p->user_val_to_struct)
> - goto out;
> + goto failure_indication;
>  
>   /* Yes, I want the sizeof the pointer, not the structure */
> - rc = -ENOMEM;
>   p->type_val_to_struct_array = flex_array_alloc(sizeof(struct type_datum 
> *),
>  p->p_types.nprim,
>  GFP_KERNEL | __GFP_ZERO);
>   if (!p->type_val_to_struct_array)
> - goto out;
> + goto failure_indication;
>  
>   rc = flex_array_prealloc(p->type_val_to_struct_array, 0,
>p->p_types.nprim, GFP_KERNEL | __GFP_ZERO);
> @@ -578,12 +574,11 @@ static int policydb_index(struct policydb *p)
>   goto out;
>  
>   for (i = 0; i < SYM_NUM; i++) {
> - rc = -ENOMEM;
>   p->sym_val_to_name[i] = flex_array_alloc(sizeof(char *),
>p->symtab[i].nprim,
>GFP_KERNEL | 
> __GFP_ZERO);
>   if (!p->sym_val_to_name[i])
> - goto out;
> + goto failure_indication;
>  
>   rc = flex_array_prealloc(p->sym_val_to_name[i],
>0, p->symtab[i].nprim,
> @@ -598,6 +593,9 @@ static int policydb_index(struct policydb *p)
>   rc = 0;
>  out:
>   return rc;
> +failure_indication:
> + rc = -ENOMEM;
> + goto out;
>  }
>  
>  /*



[PATCH V3 5/5] gpio: davinci: Remove custom .xlate

2017-01-17 Thread Keerthy
With the current redesign of driver it's not necessary to have
custom .xlate() as the gpiolib will assign default of_gpio_simple_xlate().

Suggested-by: Grygorii Strashko 
Signed-off-by: Keerthy 
Reviewed-by: Grygorii Strashko 
---
 drivers/gpio/gpio-davinci.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 2a5ae04..86b4950 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -163,27 +163,6 @@ static int davinci_gpio_get(struct gpio_chip *chip, 
unsigned offset)
return NULL;
 }
 
-#ifdef CONFIG_OF_GPIO
-static int davinci_gpio_of_xlate(struct gpio_chip *gc,
-const struct of_phandle_args *gpiospec,
-u32 *flags)
-{
-   struct davinci_gpio_controller *chips = dev_get_drvdata(gc->parent);
-   struct davinci_gpio_platform_data *pdata = dev_get_platdata(gc->parent);
-
-   if (gpiospec->args[0] > pdata->ngpio)
-   return -EINVAL;
-
-   if (gc != >chip)
-   return -EINVAL;
-
-   if (flags)
-   *flags = gpiospec->args[1];
-
-   return gpiospec->args[0] % 32;
-}
-#endif
-
 static int davinci_gpio_probe(struct platform_device *pdev)
 {
static int ctrl_num, bank_base;
@@ -244,7 +223,6 @@ static int davinci_gpio_probe(struct platform_device *pdev)
 
 #ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
-   chips->chip.of_xlate = davinci_gpio_of_xlate;
chips->chip.parent = dev;
chips->chip.of_node = dev->of_node;
 #endif
-- 
1.9.1



Re: [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE

2017-01-17 Thread Kim Phillips
On Mon, 16 Jan 2017 10:59:04 +
Will Deacon  wrote:

> On Fri, Jan 13, 2017 at 06:43:52PM +, Mark Rutland wrote:
> > On Fri, Jan 13, 2017 at 04:03:49PM +, Will Deacon wrote:
> > > +- compatible : should be one of:
> > > +"arm,arm-spe-pmu-v1"
> > 
> > The second "arm" here doesn't seem to add much. Should that be "armv8.2"
> > instead?
> 
> I don't think armv8.2 is particularly helpful, because that effectively ties
> together the SPE version and the architecture version, which I don't think
> is strictly required. The reason I added it was so that you could describe
> a partner implementation as something like:
> 
>   acme,arm-spe-pmu-v1
> 
> and know that it was acme's implementation of an ARM architectural feature.

Wouldn't such an implementation be compatible with an
"arm,arm-spe-pmu-v1" (or one with less "arm"s)?

> If I drop the second "arm", I was worried that it might conflict with other
> namespaces (e.g. acme's signal-processing-element's power-management-unit).

I'd personally let them worry about that, esp. because this problem
would come up first and hopefully be fixed in the marketing domain
before it reaches its device tree specification stage.

Kim


  1   2   3   4   5   6   7   8   9   10   >