RE: [lkp-robot] e5a305ac4a: WARNING:at_lib/list_debug.c:#__list_del_entry_valid
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
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
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
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
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
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
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
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
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
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
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
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
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 McNicollThanks 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
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.
Hi Shawn, On 1/10/2017 2:45 PM, Shawn Lin wrote: On 2017/1/10 14:41, Ritesh Harjani wrote: From: Sahitya TummalaAdd 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
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 JosserandPlease 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
>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
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 TsaiApplied, 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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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()
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()
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)
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
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()
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
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
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
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
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
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
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
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
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
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()
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
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)
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
On 17 January 2017 at 19:15, Mark Brownwrote: > 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
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
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
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
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
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
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
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 GautamAcked-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
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
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
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)
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
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
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
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 PrzywaraTested-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
On 15 January 2017 at 22:31, Alden Tondettarwrote: > 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
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
On Tue, Jan 17, 2017 at 4:20 PM, Paolo Bonziniwrote: > > > 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;
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
From: Brian StarkeyThe 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
From: Brian StarkeyThe 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
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
From: Brian StarkeyWe'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
From: Brian StarkeyRemove 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
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
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
On 16 January 2017 at 15:15, Bhupesh Sharmawrote: > 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"
On Mon, Jan 16, 2017 at 8:49 AM, Greg KHwrote: > 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
On Mon, Jan 16, 2017 at 3:30 PM, Augusto Mecking Caringiwrote: > 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
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
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
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
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
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
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 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
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
From: Namhyung KimWhen --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
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
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 BabkaSigned-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
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
On Tue, Jan 17, 2017 at 8:21 AM, Luis R. Rodriguezwrote: >>> >>> 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()
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
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 StrashkoSigned-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
On Mon, 16 Jan 2017 10:59:04 + Will Deaconwrote: > 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