Re: [PATCH v6 4/4] tracing: Histogram for delayed hrtimer offsets

[Masami Hiramatsu]

2016-09-07 20:13 GMT+09:00 Binoy Jayan :
> Generate a histogram of the latencies of delayed timer offsets in
> nanoseconds. It shows the latency captured due to a delayed timer expire
> event. It happens for example when a timer misses its deadline due to
> disabled interrupts. A process if scheduled as a result of the timer
> expiration suffers this latency.
>
> The following filter(s) may be used
>
> 'hist:key=common_pid.execname:val=toffset,hitcount'
> 'hist:key=cpu,tcomm:val=toffset:sort=tcomm'
> 'hist:key=comm,tcomm:sort=comm,tcomm'
>

Ok, so this event is hit only when the hrtimer is delayed.

I just have a comment on the event name:

> +TRACE_EVENT(latency_hrtimer_interrupt,

Since this event will be hit only when the hrtimer is delayed,
would we better add "delayed" in the event name?
e.g. "latency_delayed_hrtimer"

Others are OK for me.

Thanks,

> Signed-off-by: Binoy Jayan 
> ---
>  include/linux/hrtimer.h  |  3 +++
>  include/trace/events/timer.h | 25 +
>  kernel/time/Kconfig  |  7 ++
>  kernel/time/hrtimer.c| 52 
> 
>  4 files changed, 87 insertions(+)
>
> diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
> index 5e00f80..9146842 100644
> --- a/include/linux/hrtimer.h
> +++ b/include/linux/hrtimer.h
> @@ -104,6 +104,9 @@ struct hrtimer {
> struct hrtimer_clock_base   *base;
> u8  state;
> u8  is_rel;
> +#ifdef CONFIG_DELAYED_TIMER_OFFSETS_HIST
> +   ktime_t praecox;
> +#endif
>  #ifdef CONFIG_TIMER_STATS
> int start_pid;
> void*start_site;
> diff --git a/include/trace/events/timer.h b/include/trace/events/timer.h
> index 28c5da6..ee45aed 100644
> --- a/include/trace/events/timer.h
> +++ b/include/trace/events/timer.h
> @@ -382,6 +382,31 @@ TRACE_EVENT(tick_stop,
>  );
>  #endif
>
> +#ifdef CONFIG_DELAYED_TIMER_OFFSETS_HIST
> +TRACE_EVENT(latency_hrtimer_interrupt,
> +
> +   TP_PROTO(long long toffset, struct task_struct *task),
> +
> +   TP_ARGS(toffset, task),
> +
> +   TP_STRUCT__entry(
> +   __field(long long,  toffset)
> +   __array(char,   tcomm,  TASK_COMM_LEN)
> +   __field(int,tprio)
> +   ),
> +
> +   TP_fast_assign(
> +   __entry->toffset = toffset;
> +   memcpy(__entry->tcomm, task != NULL ? task->comm : "",
> +   task != NULL ? TASK_COMM_LEN : 7);
> +   __entry->tprio  = task != NULL ? task->prio : -1;
> +   ),
> +
> +   TP_printk("toffset=%lld thread=%s[%d]",
> +   __entry->toffset, __entry->tcomm, __entry->tprio)
> +);
> +#endif
> +
>  #endif /*  _TRACE_TIMER_H */
>
>  /* This part must be outside protection */
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index 4008d9f..8ff19dd 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -193,5 +193,12 @@ config HIGH_RES_TIMERS
>   hardware is not capable then this option only increases
>   the size of the kernel image.
>
> +config DELAYED_TIMER_OFFSETS_HIST
> +   depends on HIGH_RES_TIMERS
> +   select GENERIC_TRACER
> +   bool "Delayed Timer Offsets Histogram"
> +   help
> + Generate a histogram of delayed timer offsets in nanoseconds.
> +
>  endmenu
>  endif
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 9ba7c82..432d49a 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -56,6 +56,8 @@
>
>  #include "tick-internal.h"
>
> +static enum hrtimer_restart hrtimer_wakeup(struct hrtimer *timer);
> +
>  /*
>   * The timer bases:
>   *
> @@ -960,6 +962,52 @@ static inline ktime_t hrtimer_update_lowres(struct 
> hrtimer *timer, ktime_t tim,
> return tim;
>  }
>
> +#ifdef CONFIG_DELAYED_TIMER_OFFSETS_HIST
> +static inline void latency_hrtimer_timing_start(struct hrtimer *timer,
> +struct hrtimer_clock_base *new_base,
> +ktime_t tim)
> +{
> +   if (unlikely(trace_latency_hrtimer_interrupt_enabled())) {
> +   ktime_t now = new_base->get_time();
> +
> +   if (ktime_to_ns(tim) < ktime_to_ns(now))
> +   timer->praecox = now;
> +   else
> +   timer->praecox = ktime_set(0, 0);
> +   }
> +}
> +
> +static inline void latency_hrtimer_timing_stop(struct hrtimer *timer,
> +   ktime_t basenow)
> +{
> +   long latency;
> +   struct task_struct *task;
> +
> +   if (likely(!trace_latency_hrtimer_interrupt_enabled()))
> +   return;
> +
> +   latency = ktime_to_ns(ktime_sub(basenow,
> + ktime_to_ns(timer->praecox) ?
> + timer->

Re: [PATCH] syscon: dt-bindings: Add documentation for Aspeed system control units

[Lee Jones]

On Thu, 08 Sep 2016, Andrew Jeffery wrote:

> Signed-off-by: Andrew Jeffery 
> Acked-by: Rob Herring 
> Acked-by: Joel Stanley 
> Acked-by: Linus Walleij 
> ---
>  Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 18 ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-scu.txt

Thanks for resending.

Applied, thanks

> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt 
> b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
> new file mode 100644
> index ..4fc5b83726d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
> @@ -0,0 +1,18 @@
> +The Aspeed System Control Unit manages the global behaviour of the SoC,
> +configuring elements such as clocks, pinmux, and reset.
> +
> +Required properties:
> +- compatible:One of:
> + "aspeed,ast2400-scu", "syscon", "simple-mfd"
> + "aspeed,g4-scu", "syscon", "simple-mfd"
> + "aspeed,ast2500-scu", "syscon", "simple-mfd"
> + "aspeed,g5-scu", "syscon", "simple-mfd"
> +
> +- reg:   contains the offset and length of the SCU memory region
> +
> +Example:
> +
> +syscon: syscon@1e6e2000 {
> + compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[RESEND PATCH v3 1/2] phy: rockchip-typec: add pm runtime support

[Chris Zhong]

Adds pm_runtime support for rockchip Type-C, so that power domain is
enabled only when there is a transaction going on to help save power.

Signed-off-by: Chris Zhong 
---

Changes in v3:
- use phy_core pm_runtime

Changes in v2:
- add pm_runtime_put_sync in err case

 drivers/phy/phy-rockchip-typec.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/phy/phy-rockchip-typec.c b/drivers/phy/phy-rockchip-typec.c
index fb58a27..7cfb0f8 100644
--- a/drivers/phy/phy-rockchip-typec.c
+++ b/drivers/phy/phy-rockchip-typec.c
@@ -960,6 +960,8 @@ static int rockchip_typec_phy_probe(struct platform_device 
*pdev)
return PTR_ERR(tcphy->extcon);
}
 
+   pm_runtime_enable(dev);
+
for_each_available_child_of_node(np, child_np) {
struct phy *phy;
 
@@ -990,6 +992,13 @@ static int rockchip_typec_phy_probe(struct platform_device 
*pdev)
return 0;
 }
 
+static int rockchip_typec_phy_remove(struct platform_device *pdev)
+{
+   pm_runtime_disable(&pdev->dev);
+
+   return 0;
+}
+
 static const struct of_device_id rockchip_typec_phy_dt_ids[] = {
{ .compatible = "rockchip,rk3399-typec-phy" },
{}
@@ -999,6 +1008,7 @@ MODULE_DEVICE_TABLE(of, rockchip_typec_phy_dt_ids);
 
 static struct platform_driver rockchip_typec_phy_driver = {
.probe  = rockchip_typec_phy_probe,
+   .remove = rockchip_typec_phy_remove,
.driver = {
.name   = "rockchip-typec-phy",
.of_match_table = rockchip_typec_phy_dt_ids,
-- 
1.9.1

[PATCH v2 00/33] Enable Intel Resource Allocation in Resource Director Technology

[Fenghua Yu]

From: Fenghua Yu 

L3 cache allocation allows per task control over which areas of the last
level cache are available for allocation. It is the first resource that
can be controlled as part of Intel Resource Director Technology (RDT).
This patch series creates a framework that will make it easy to add
additional resources (like L2 cache).

See Intel Software Developer manual volume 3, chapter 17 for architectural
details. Also Documentation/x86/intel_rdt.txt and
Documentation/x86/intel_rdt_ui.txt (in parts 0001 & 0013 of this patch
series).

A previous implementation used "cgroups" as the user interface. This was
rejected.

The new interface:
1) Aligns better with the h/w capabilities provided
2) Gives finer control (per thread instead of process)
3) Gives control over kernel threads as well as user threads
4) Allows resource allocation policies to be tied to certain cpus across
all contexts (tglx request)

Note 1: that parts 1-12 are largely unchanged from what was posted last
year except for the removal of cgroup pieces and dynamic CAT/CDP switch.

Note 2: This patch set is an infrastructure for future multi-resources
support. Some code are not only for L3. For example, cat_l3_enabled
is checked after initialization and mount time. This doesn't make
sense for L3 only. But it's easy to add L2 support on top of the
current patch set.

Changes:
v2:
- Merge and reorder some patches
- "tasks" has higher priority than "cpus".
- Re-write UI doc.
- Add include/linux/resctrl.h
- Remove rg_list
- A few other changes.

Fenghua Yu (21):
  cacheinfo: Introduce cache id
  Documentation, ABI: Add a document entry for cache id
  x86, intel_cacheinfo: Enable cache id in x86
  drivers/base/cacheinfo.c: Export some cacheinfo functions for others
to use
  Documentation, x86: Documentation for Intel resource allocation user
interface
  sched.h: Add rg_list and rdtgroup in task_struct
  magic number for resctrl file system
  x86/intel_rdt.h: Header for inter_rdt.c
  x86/intel_rdt_rdtgroup.h: Header for user interface
  x86/intel_rdt.c: Extend RDT to per cache and per resources
  x86/intel_rdt_rdtgroup.c: User interface for RDT
  x86/intel_rdt_rdtgroup.c: Create info directory
  include/linux/resctrl.h: Define fork and exit functions in a new
header file
  Task fork and exit for rdtgroup
  x86/intel_rdt_rdtgroup.c: Implement resctrl file system commands
  x86/intel_rdt_rdtgroup.c: Read and write cpus
  x86/intel_rdt_rdtgroup.c: Tasks iterator and write
  x86/intel_rdt_rdtgroup.c: Process schemata input from resctrl
interface
  Documentation/kernel-parameters: Add kernel parameter "resctrl" for
CAT
  MAINTAINERS: Add maintainer for Intel RDT resource allocation
  x86/Makefile: Build intel_rdt_rdtgroup.c

Vikas Shivappa (12):
  x86/intel_rdt: Cache Allocation documentation
  x86/intel_rdt: Add support for Cache Allocation detection
  x86/intel_rdt: Add Class of service management
  x86/intel_rdt: Add L3 cache capacity bitmask management
  x86/intel_rdt: Implement scheduling support for Intel RDT
  x86/intel_rdt: Hot cpu support for Cache Allocation
  x86/intel_rdt: Intel haswell Cache Allocation enumeration
  Define CONFIG_INTEL_RDT
  x86/intel_rdt: Intel Code Data Prioritization detection
  x86/intel_rdt: Adds support to enable Code Data Prioritization
  x86/intel_rdt: Class of service and capacity bitmask management for
CDP
  x86/intel_rdt: Hot cpu update for code data prioritization

 Documentation/ABI/testing/sysfs-devices-system-cpu |   17 +
 Documentation/kernel-parameters.txt|   13 +
 Documentation/x86/intel_rdt.txt|  109 ++
 Documentation/x86/intel_rdt_ui.txt |  164 +++
 MAINTAINERS|9 +
 arch/x86/Kconfig   |   13 +
 arch/x86/events/intel/cqm.c|   24 +-
 arch/x86/include/asm/cpufeature.h  |   10 +-
 arch/x86/include/asm/cpufeatures.h |9 +-
 arch/x86/include/asm/disabled-features.h   |4 +-
 arch/x86/include/asm/intel_rdt.h   |  129 ++
 arch/x86/include/asm/intel_rdt_rdtgroup.h  |  164 +++
 arch/x86/include/asm/pqr_common.h  |   27 +
 arch/x86/include/asm/processor.h   |3 +
 arch/x86/include/asm/required-features.h   |4 +-
 arch/x86/kernel/cpu/Makefile   |2 +
 arch/x86/kernel/cpu/common.c   |   19 +
 arch/x86/kernel/cpu/intel_cacheinfo.c  |   20 +
 arch/x86/kernel/cpu/intel_rdt.c|  802 
 arch/x86/kernel/cpu/intel_rdt_rdtgroup.c   | 1362 
 arch/x86/kernel/cpu/intel_rdt_schemata.c   |  674 ++
 arch/x86/kernel/process_64.c   |6 +
 drivers/base/cacheinfo.c   |7 +-
 include/linux/cacheinfo.h  |5 +
 include/linux/resctrl.h 

Re: [PATCH, net-next] perf, bpf: fix conditional call to bpf_overflow_handler

[Peter Zijlstra]

On Thu, Sep 08, 2016 at 08:30:52AM +0200, Ingo Molnar wrote:
> > Thanks for the fix. Just saw build bot complaining last night and
> > by the morning your fix is already here. Thanks!
> 
> Guys, this is the first time I saw this patch (and presumably there's some 
> other 
> patch as well?) - could you please submit it properly for review and get an 
> Acked-by from one of the perf maintainers before appying it?

I was involved with the original patch and Ack'ed it.

Ack on this one as well.

Re: [PATCH RFC v6] x86,mm,sched: make lazy TLB mode even lazier

[Ingo Molnar]

* Rik van Riel  wrote:

> On Sat, 27 Aug 2016 16:02:25 -0700
> Linus Torvalds  wrote:
> 
> > Yeah, with those small fixes from Ingo, I definitely don't think this
> > looks hacky at all. This all seems to be exactly what we should always
> > have done.
> 
> OK, so I was too tired yesterday to do kernel hacking, and
> missed yet another bit (xen_flush_tlb_others). Sigh.
> 
> Otherwise, the patch is identical.
> 
> Looking forward to Ben's test results.

Gentle ping to Ben.

I can also apply this without waiting for the test result, the patch looks sane 
enough to me.

Thanks,

Ingo

Re: [PATCH v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Neil,

On 6 September 2016 at 13:40, NeilBrown  wrote:
> On Mon, Aug 29 2016, Baolin Wang wrote:
>
>> Hi Felipe,
>>
>> On 11 August 2016 at 11:14, Baolin Wang  wrote:
>>> Hi Felipe,
>>>
>>> On 1 August 2016 at 15:09, Baolin Wang  wrote:
 Currently the Linux kernel does not provide any standard integration of 
 this
 feature that integrates the USB subsystem with the system power regulation
 provided by PMICs meaning that either vendors must add this in their 
 kernels
 or USB gadget devices based on Linux (such as mobile phones) may not behave
 as they should. Thus provide a standard framework for doing this in kernel.

 Now introduce one user with wm831x_power to support and test the usb 
 charger,
 which is pending testing. Moreover there may be other potential users will 
 use
 it in future.
>>>
>>> Could you please apply this patchset into your 'next' branch if you
>>> have no comments about it? Thank you.
>>
>> Since there are no other comments about this patchset for a long time,
>> could you please apply this patchset? Thanks.
>

Sorry for the late reply.

> Sorry, I should have replied earlier.  Tim Bird mentioned on the
> ksummit-discuss list that there was a frustration with this not making
> progress so I decided to contribute what I could now.
>
> I think this patch set is attempting to address an important problem
> that needs solving.  However I think it gets some key aspects wrong.
> Maybe they can get fixed up after the patchset is upstream, maybe they
> should be fixed first - I have no strong opinion on that.
>
> My main complaints involve the detection and handling of the different
> charger types - DCP, CDP, ACA etc.
> The big-picture requirement here that the PHY will detect the physical
> properties of the cable (e.g. resistance to ground on ID) and determine
> the type of charger expected.  This information must be communicated to
> the PMIC "power_supply" device so it can regulate the power being drawn
> through the cable.
>
> The first problem is that there are two different ways that the
> distinction between DCP, CDP, ACA etc can be represented in Linux.  They
> are cable types in the 'extcon' subsystem, and they are power_supply
> types in the 'power_supply' subsystem.  This duplication is confusing.
> It is not caused by your patch set, but I believe your patchset needs to
> work with the duplication and I think it does so poorly.

Now the usb charger will not get charger type from 'extcon' subsystem,
we get the charger type from 'power_supply' and calllback
'get_charger_type' for users.

>
> In my mind, the power_supply should *not* know about this distinction at
> all (except possibly as an advisor attribute simiarly to the current
> battery technology attribute).  The other types it knows of are "AC",
> "USB", and "BATTERY".  The contrast between these is quite different
> From the contrast between DCP, CDP, ACA, which, from the perspective of
> the power supply, are almost irrelevant.  Your patchset effectively
> examines the power_supply_type of one power_supply, and communicates it
> to another.  It isn't clear to me how the first power_supply gets the
> information, or what the relationship between the two power_supplies is
> meant to be.

We just get the charger type from the power supply which can get the
charger type from register or something else, and the usb charger did
nothing for this power supply. In some platform, the charger type is
get in power supply driver, thus we should link this power supply to
get the charger type when USB cable is plugin. If you don't get
charger type from power supply driver, then it does not need to link
this power supply phandle.

>
> It makes much more sense, to me, to utilized the knowledge of this
> distinction that extcon provides.  A usb PHY can register an extcon,
> declare the sorts of cables that it can detect, and tell the extcon as
> cables appear or disappear.  The PMIC power_supply can then register with
> that extcon for events and can find out when a cable is attached, and
> what sort of cable.
> Your usb-charging framework would be well placed to help the
> power_supply to find the correct extcon, and possibly even to handle the
> registration for events.
>
> Your framework does currently register with extcon, but only listens for
> EXTCON_USB cables.  I don't think that cable type is (reliably) reported
> when a DCP (for example) is plugged in.

Here we just listen the plugin/out events from extcon, if one cable
plugin it will report to usb charger.

>
> Here there is another problem that is not of your making, but still
> needs fixing.  Extcon declares a number of cable types like:
>
> /* USB external connector */
> #define EXTCON_USB  1
> #define EXTCON_USB_HOST 2
>
> /* Charging external connector */
> #define EXTCON_CHG_USB_SDP  5   /* Standard Downstream Port */
> #define EXTCON_CHG_USB_DCP  6   /* Dedicated Charging Port 

Re: [alsa-devel] [PATCH] ALSA: usb: constify snd_pcm_ops structures

[Clemens Ladisch]

Julia Lawall wrote:
> Check for snd_pcm_ops structures that are only stored in the ops field of a
> snd_soc_platform_driver structure or passed as the third argument to
> snd_pcm_set_ops.  The corresponding field or parameter is declared const,
> so snd_pcm_ops structures that have this property can be declared as const
> also.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // 
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct snd_pcm_ops i@p = { ... };
>
> @ok1@
> identifier r.i;
> struct snd_soc_platform_driver e;
> position p;
> @@
> e.ops = &i@p;
>
> @ok2@
> identifier r.i;
> expression e1, e2;
> position p;
> @@
> snd_pcm_set_ops(e1, e2, &i@p)
>
> @bad@
> position p != {r.p,ok1.p,ok2.p};
> identifier r.i;
> struct snd_pcm_ops e;
> @@
> e@i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
>  struct snd_pcm_ops i = { ... };
> // 
>
> Signed-off-by: Julia Lawall 

Acked-by: Clemens Ladisch 

> ---
>  sound/usb/6fire/pcm.c   |2 +-
>  sound/usb/caiaq/audio.c |2 +-
>  sound/usb/hiface/pcm.c  |2 +-
>  sound/usb/misc/ua101.c  |4 ++--
>  sound/usb/usx2y/usx2yhwdeppcm.c |2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/sound/usb/6fire/pcm.c b/sound/usb/6fire/pcm.c
> index 36f4115..224a6a5 100644
> --- a/sound/usb/6fire/pcm.c
> +++ b/sound/usb/6fire/pcm.c
> @@ -555,7 +555,7 @@ static snd_pcm_uframes_t usb6fire_pcm_pointer(
>   return ret;
>  }
>
> -static struct snd_pcm_ops pcm_ops = {
> +static const struct snd_pcm_ops pcm_ops = {
>   .open = usb6fire_pcm_open,
>   .close = usb6fire_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> diff --git a/sound/usb/hiface/pcm.c b/sound/usb/hiface/pcm.c
> index 2c44139..23e66ed 100644
> --- a/sound/usb/hiface/pcm.c
> +++ b/sound/usb/hiface/pcm.c
> @@ -511,7 +511,7 @@ static snd_pcm_uframes_t hiface_pcm_pointer(struct 
> snd_pcm_substream *alsa_sub)
>   return bytes_to_frames(alsa_sub->runtime, dma_offset);
>  }
>
> -static struct snd_pcm_ops pcm_ops = {
> +static const struct snd_pcm_ops pcm_ops = {
>   .open = hiface_pcm_open,
>   .close = hiface_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> diff --git a/sound/usb/usx2y/usx2yhwdeppcm.c b/sound/usb/usx2y/usx2yhwdeppcm.c
> index 90766a9..1f28cb2a 100644
> --- a/sound/usb/usx2y/usx2yhwdeppcm.c
> +++ b/sound/usb/usx2y/usx2yhwdeppcm.c
> @@ -587,7 +587,7 @@ static int snd_usX2Y_usbpcm_close(struct 
> snd_pcm_substream *substream)
>  }
>
>
> -static struct snd_pcm_ops snd_usX2Y_usbpcm_ops =
> +static const struct snd_pcm_ops snd_usX2Y_usbpcm_ops =
>  {
>   .open = snd_usX2Y_usbpcm_open,
>   .close =snd_usX2Y_usbpcm_close,
> diff --git a/sound/usb/misc/ua101.c b/sound/usb/misc/ua101.c
> index c19a5dd..71a0e9e 100644
> --- a/sound/usb/misc/ua101.c
> +++ b/sound/usb/misc/ua101.c
> @@ -890,7 +890,7 @@ static snd_pcm_uframes_t playback_pcm_pointer(struct 
> snd_pcm_substream *subs)
>   return ua101_pcm_pointer(ua, &ua->playback);
>  }
>
> -static struct snd_pcm_ops capture_pcm_ops = {
> +static const struct snd_pcm_ops capture_pcm_ops = {
>   .open = capture_pcm_open,
>   .close = capture_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> @@ -903,7 +903,7 @@ static struct snd_pcm_ops capture_pcm_ops = {
>   .mmap = snd_pcm_lib_mmap_vmalloc,
>  };
>
> -static struct snd_pcm_ops playback_pcm_ops = {
> +static const struct snd_pcm_ops playback_pcm_ops = {
>   .open = playback_pcm_open,
>   .close = playback_pcm_close,
>   .ioctl = snd_pcm_lib_ioctl,
> diff --git a/sound/usb/caiaq/audio.c b/sound/usb/caiaq/audio.c
> index 8f66ba7..af5ad84 100644
> --- a/sound/usb/caiaq/audio.c
> +++ b/sound/usb/caiaq/audio.c
> @@ -338,7 +338,7 @@ unlock:
>  }
>
>  /* operators for both playback and capture */
> -static struct snd_pcm_ops snd_usb_caiaq_ops = {
> +static const struct snd_pcm_ops snd_usb_caiaq_ops = {
>   .open = snd_usb_caiaq_substream_open,
>   .close =snd_usb_caiaq_substream_close,
>   .ioctl =snd_pcm_lib_ioctl,

Re: [PATCH 4.7 114/143] Revert "floppy: fix open(O_ACCMODE) for ioctl-only open"

[Greg Kroah-Hartman]

On Wed, Sep 07, 2016 at 12:53:51PM -0400, Mark Hounschell wrote:
> On 09/05/2016 12:44 PM, Greg Kroah-Hartman wrote:
> > 4.7-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Jens Axboe 
> > 
> > commit 468c298ad3ed3f0d94a65f8ca00f6bfc6c2b4e33 upstream.
> > 
> > This reverts commit ff06db1efb2ad6db06eb5b99b88a0c15a9cc9b0e.
> > 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> >  drivers/block/floppy.c |   21 -
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> > 
> > --- a/drivers/block/floppy.c
> > +++ b/drivers/block/floppy.c
> > @@ -3663,6 +3663,11 @@ static int floppy_open(struct block_devi
> > 
> > opened_bdev[drive] = bdev;
> > 
> > +   if (!(mode & (FMODE_READ|FMODE_WRITE))) {
> > +   res = -EINVAL;
> > +   goto out;
> > +   }
> > +
> > res = -ENXIO;
> > 
> > if (!floppy_track_buffer) {
> > @@ -3706,15 +3711,13 @@ static int floppy_open(struct block_devi
> > if (UFDCS->rawcmd == 1)
> > UFDCS->rawcmd = 2;
> > 
> > -   if (mode & (FMODE_READ|FMODE_WRITE)) {
> > -   UDRS->last_checked = 0;
> > -   clear_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags);
> > -   check_disk_change(bdev);
> > -   if (test_bit(FD_DISK_CHANGED_BIT, &UDRS->flags))
> > -   goto out;
> > -   if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags))
> > -   goto out;
> > -   }
> > +   UDRS->last_checked = 0;
> > +   clear_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags);
> > +   check_disk_change(bdev);
> > +   if (test_bit(FD_DISK_CHANGED_BIT, &UDRS->flags))
> > +   goto out;
> > +   if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags))
> > +   goto out;
> > 
> > res = -EROFS;
> > 
> > 
> > 
> > 
> 
> Can I assume the one to revert 09954bad448791ef01202351d437abdd9497a804 will
> be a separate one?

Hm, I didn't think I needed that here.  What is the git commit id of
that patch in Linus's tree?

sorry about this,

greg k-h

Re: [PATCH 4.7 000/143] 4.7.3-stable review

[Greg Kroah-Hartman]

On Wed, Sep 07, 2016 at 04:59:37PM -0400, Levin, Alexander wrote:
> On Mon, Sep 05, 2016 at 06:42:56PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.7.3 release.
> > There are 143 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Sep  7 16:44:10 UTC 2016.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.7.3-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.7.y
> > and the diffstat can be found below.
> 
> Hey Greg,
> 
> For reference, I've generated a list of <=4.8-rc4 commits that look to me 
> like stable material but are not in 4.7.3:
> 
> 422eac3f7deae34dbaffd08e03e27f37a5394a56 (v4.8-rc1) tpm_crb: fix mapping of 
> the buffers
> a36aa80f3cb2540fb1dbad6240852de4365a2e82 (v4.8-rc1) intel_th: Fix a deadlock 
> in modprobing
> 7a1a47ce35821b40f5b2ce46379ba14393bc3873 (v4.8-rc1) intel_th: pci: Add Kaby 
> Lake PCH-H support
> fa95986095e39205ea2fb5b5dafe271bca7eb8d1 (v4.8-rc1) drm/i915: Set legacy 
> properties when using legacy gamma set IOCTL. (v2)
> 78f4f7c2341f1cf510152ad494108850fec1ae39 (v4.8-rc1) ALSA: hda/realtek - 
> ALC891 headset mode for Dell
> 9b51fe3efe4c270005e34f55a97e5a84ad68e581 (v4.8-rc1) ALSA: hda - On-board 
> speaker fixup on ACER Veriton
> 7d9595d848cdff5c7939f68eec39e0c5d36a1d67 (v4.8-rc1) dm rq: fix the starting 
> and stopping of blk-mq queues
> 3b2c1710fac7fb278b760d1545e637cbb5ea5b5b (v4.8-rc2) drm/i915: Wait up to 3ms 
> for the pcu to ack the cdclk change request on SKL
> c518189567eaf42b2ec50a4d982484c8e38799f8 (v4.8-rc3) net: macb: Correct CAPS 
> mask
> 80788a0fbbdfbb125e3fd45a640cddb582160bc7 (v4.8-rc1) drm/i915/fbc: sanitize 
> i915.enable_fbc during FBC init
> 0a491b96aa59a7232f6c1a81414aa57fb8de8594 (v4.8-rc3) drm/i915/fbc: FBC causes 
> display flicker when VT-d is enabled on Skylake
> 3e103a65514c2947e53f3171b21255fbde8b60c6 (v4.8-rc4) ASoC: atmel_ssc_dai: 
> Don't unconditionally reset SSC on stream startup
> 1b856086813be9371929b6cc62045f9fd470f5a0 (v4.8-rc4) block: Fix race triggered 
> by blk_set_queue_dying()
> ae5b80d2b68eac945b124227dea34462118a6f01 (v4.8-rc4) drm/radeon: only apply 
> the SS fractional workaround to RS[78]80
> d9dc1702b297ec4a6bb9c0326a70641b322ba886 (v4.8-rc4) bcache: 
> register_bcache(): call blkdev_put() when cache_alloc() fails
> acc9cf8c66c66b2cbbdb4a375537edee72be64df (v4.8-rc4) bcache: RESERVE_PRIO is 
> too small by one when prio_buckets() is a power of two.
> 13f479b9df4e2bbf2d16e7e1b02f3f55f70e2455 (v4.8-rc4) drm/radeon: fix 
> radeon_move_blit on 32bit systems
> d77976c414ed7f521b9c79b2a9dde0147a3cf754 (v4.8-rc4) ARC: export kmap
> c57653dc94d0db7bf63067433ceaa97bdcd0a312 (v4.8-rc4) ARC: export __udivdi3 for 
> modules
> 6f00975c619064a18c23fd3aced325ae165a73b9 (v4.8-rc4) drm: Reject page_flip for 
> !DRIVER_MODESET
> e9e5e3fae8da7e237049e00e0bfc9e32fd808fe8 (v4.8-rc4) bdev: fix NULL pointer 
> dereference
> 6a33fa2b87513fee44cb8f0cd17b1acd6316bc6b (v4.8-rc4) irqchip/mips-gic: Cleanup 
> chip and handler setup
> 2564970a381651865364974ea414384b569cb9c0 (v4.8-rc4) irqchip/mips-gic: 
> Implement activate op for device domain
> c62fb260a86dde3df5b2905432caa0e9f6898434 (v4.8-rc4) IB/hfi1,IB/qib: Fix 
> qp_stats sleep with rcu read lock held
> a77ec83a57890240c546df00ca5df1cdeedb1cc3 (v4.8-rc4) vhost/scsi: fix reuse of 
> &vq->iov[out] in response
> c0082e985fdf77b02fc9e0dac3b58504dcf11b7a (v4.8-rc4) ubifs: Fix assertion in 
> layout_in_gaps()
> 17ce1eb0b64eb27d4f9180daae7495fa022c7b0d (v4.8-rc4) ubifs: Fix xattr generic 
> handler usage
> 27727df240c7cc84f2ba6047c6f18d5addfd25ef (v4.8-rc4) timekeeping: Avoid taking 
> lock in NMI path with CONFIG_DEBUG_TIMEKEEPING
> a4f8f6667f099036c88f231dcad4cf233652c824 (v4.8-rc4) timekeeping: Cap array 
> access in timekeeping_debug
> 2e63ad4bd5dd583871e6602f9d398b9322d358d9 (v4.8-rc4) x86/apic: Do not init irq 
> remapping if ioapic is disabled
> 9b47f77a680447e0132b2cf7fb82374e014bec1c (v4.8-rc4) nvme: Fix 
> nvme_get/set_features() with a NULL result pointer
> 4d70dca4eadf2f95abe389116ac02b8439c2d16c (v4.8-rc4) block: make sure a big 
> bio is split into at most 256 bvecs
> 9a035a40f7f3f6708b79224b86c5777a3334f7ea (v4.8-rc4) xenbus: don't look up 
> transaction IDs for ordinary writes
> 299f6230bc6d0ccd5f95bb0fb865d80a9c7d5ccc (v4.8-rc4) dm flakey: fix reads to 
> be issued if drop_writes configured
> b53e7d000d9e6e9fd2c6eb6b82d2783c67fd599e (v4.8-rc4) 
> clocksource/drivers/sun4i: Clear interrupts after stopping timer in probe 
> function
> add1fa75101263ab4d74240f93000998d4325624 (v4.8-rc4) drm/atomic: Don't 
> potentially reset color_mgmt_changed on successive property updates.
> 

Thanks for 

Re: [PATCH v5 0/5] Add MT8173 MDP Driver

[Hans Verkuil]

FYI: I'm missing a MAINTAINERS entry for this driver.

Please add one when you post v6.

Thanks!

Hans

On 08/30/2016 02:25 PM, Minghsiu Tsai wrote:
> Changes in v5:
> - Add ack in the comment of dts patch 
> - Fix s/g_selection()
> - Separate format V4L2_PIX_FMT_MT21C into new patch  
> 
> Changes in v4:
> - Add "depends on HAS_DMA" in Kconfig.
> - Fix s/g_selection()
> - Replace struct v4l2_crop with u32 and struct v4l2_rect
> - Remove VB2_USERPTR
> - Move mutex lock after ctx allocation in mtk_mdp_m2m_open()
> - Add new format V4L2_PIX_FMT_YVU420 to support software on Android platform.
> - Only width/height of image in format V4L2_PIX_FMT_MT21 is aligned to 16/16,
>   other ones are aligned to 2/2 by default
> 
> Changes in v3:
> - Modify device ndoe as structured one.
> - Fix conflict in dts on Linux 4.8-rc1
> 
> Changes in v2:
> - Add section to describe blocks function in dts-bindings
> - Remove the assignment of device_caps in querycap()
> - Remove format's name assignment
> - Copy colorspace-related parameters from OUTPUT to CAPTURE
> - Use m2m helper functions
> - Fix DMA allocation failure
> - Initialize lazily vpu instance in streamon()
> 
> ==
>  Introduction
> ==
> 
> The purpose of this series is to add the driver for Media Data Path HW 
> embedded in the Mediatek's MT8173 SoC.
> MDP is used for scaling and color space conversion.
> 
> It could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or 
> V4L2_PIX_FMT_YUV420M.
> 
> NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M
> 
> This patch series rely on MTK VPU driver in patch series "Add MT8173 Video 
> Encoder Driver and VPU Driver"[1] and "Add MT8173 Video Decoder Driver"[2].
> MDP driver rely on VPU driver to load, communicate with VPU.
> 
> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both 
> have been merged in v4.6-rc1.
> 
> [1]https://patchwork.kernel.org/patch/9002171/
> [2]https://patchwork.kernel.org/patch/9141245/
> 
> ==
>  Device interface
> ==
> 
> In principle the driver bases on v4l2 memory-to-memory framework:
> it provides a single video node and each opened file handle gets its own 
> private context with separate buffer queues. Each context consist of 2 buffer 
> queues: OUTPUT (for source buffers) and CAPTURE (for destination buffers).
> OUTPUT and CAPTURE buffer could be MMAP or DMABUF memory type.
> 
> v4l2-compliance test output:
> # v4l2-compliance -d /dev/image-proc0
> v4l2-compliance SHA   : a737a6161485fffb70bf51e4fd7f6e2d910174c1
> 
> Driver Info:
> Driver name   : mtk-mdp
> Card type : soc:mdp
> Bus info  : platform:mt8173
> Driver version: 4.8.0
> Capabilities  : 0x84204000
> Video Memory-to-Memory Multiplanar
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x04204000
> Video Memory-to-Memory Multiplanar
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/image-proc0 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK (Not Supported)
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 0 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 5 Private Controls: 0
> 
> Format ioctls:
> test VIDIO

Re: [PATCH] virtio_console: Stop doing DMA on the stack

[Ingo Molnar]

* Amit Shah  wrote:

> On (Tue) 30 Aug 2016 [08:04:15], Andy Lutomirski wrote:
> > virtio_console uses a small DMA buffer for control requests.  Move
> > that buffer into heap memory.
> > 
> > Doing virtio DMA on the stack is normally okay on non-DMA-API virtio
> > systems (which is currently most of them), but it breaks completely
> > if the stack is virtually mapped.
> > 
> > Tested by typing both directions using picocom aimed at /dev/hvc0.
> > 
> > Signed-off-by: Andy Lutomirski 
> 
> Looks fine,
> 
> Reviewed-by: Amit Shah 
> 
> > ---
> > 
> > Hi all-
> > 
> > This is currently broken in tip:x86/asm.  If you (Amit) like this patch,
> > would it make sense for Ingo to add it to -tip?
> 
> Yes, I'm fine with that.

Thanks! FYI, this patch now lives as:

  9472fe7040bb ("virtio_console: Stop doing DMA on the stack")

in tip:x86/asm, and is targeted for a v4.9 merge.

Thanks,

Ingo

Re: linux-next: Tree for Sep 7 (kernel/trace/trace_hwlat.c)

[Randy Dunlap]

On 09/07/16 19:58, Steven Rostedt wrote:
> On Wed, 7 Sep 2016 13:55:47 -0700
> Randy Dunlap  wrote:
>  
>> Yes, that works. Thanks.
>>
>> Acked-by: Randy Dunlap 
> 
> Hmm, would "Tested-by" be a more appropriate tag?

I considered that. Either is OK with me.

-- 
~Randy

Re: [PATCH v6 1/4] tracing: Deference pointers without RCU checks

[Masami Hiramatsu]

2016-09-07 20:13 GMT+09:00 Binoy Jayan :
>
> From: Daniel Wagner 
>
> The tracepoint can't be used in code section where we are in the
> middle of a state transition.
>
> For example if we place a tracepoint inside start/stop_critical_section(),
> lockdep complains with
>
> [0.035589] WARNING: CPU: 0 PID: 3 at kernel/locking/lockdep.c:3560 \
> check_flags.part.36+0x1bc/0x210() [0.036000] \
> DEBUG_LOCKS_WARN_ON(current->softirqs_enabled) [0.036000] Kernel panic - 
> not \
> syncing: panic_on_warn set ... [0.036000]
> [0.036000] CPU: 0 PID: 3 Comm: ksoftirqd/0 Not tainted 4.0.0-rc7+ #460
> [0.036000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS \
> 1.7.5-20140709_153950- 04/01/2014 [0.036000]  81f2463a 
> 88007c93bb98 \
> 81afb317 0001 [0.036000]  81f212b3 
> 88007c93bc18 \
> 81af7bc2 88007c93bbb8 [0.036000]  0008 
> 88007c93bc28 \
> 88007c93bbc8 0093bbd8 [0.036000] Call Trace:
> [0.036000]  [] dump_stack+0x4f/0x7b
> [0.036000]  [] panic+0xc0/0x1e9
> [0.036000]  [] ? _raw_spin_unlock_irqrestore+0x38/0x80
> [0.036000]  [] warn_slowpath_common+0xc0/0xc0
> [0.036000]  [] ? __local_bh_enable+0x36/0x70
> [0.036000]  [] warn_slowpath_fmt+0x46/0x50
> [0.036000]  [] check_flags.part.36+0x1bc/0x210
> [0.036000]  [] lock_is_held+0x78/0x90
> [0.036000]  [] ? __local_bh_enable+0x36/0x70
> [0.036000]  [] ? __do_softirq+0x3db/0x500
> [0.036000]  [] trace_preempt_on+0x255/0x260
> [0.036000]  [] preempt_count_sub+0xab/0xf0
> [0.036000]  [] __local_bh_enable+0x36/0x70
> [0.036000]  [] __do_softirq+0x3db/0x500
> [0.036000]  [] run_ksoftirqd+0x1f/0x60
> [0.036000]  [] smpboot_thread_fn+0x193/0x2a0
> [0.036000]  [] ? SyS_setgroups+0x150/0x150
> [0.036000]  [] kthread+0xf2/0x110
> [0.036000]  [] ? wait_for_completion+0xc3/0x120
> [0.036000]  [] ? preempt_count_sub+0xab/0xf0
> [0.036000]  [] ? kthread_create_on_node+0x240/0x240
> [0.036000]  [] ret_from_fork+0x58/0x90
> [0.036000]  [] ? kthread_create_on_node+0x240/0x240
> [0.036000] ---[ end Kernel panic - not syncing: panic_on_warn set ...
>
> PeterZ was so kind to explain it to me what is happening:
>
> "__local_bh_enable() tests if this is the last SOFTIRQ_OFFSET, if so it
> tells lockdep softirqs are enabled with trace_softirqs_on() after that
> we go an actually modify the preempt_count with preempt_count_sub().
> Then in preempt_count_sub() you call into trace_preempt_on() if this
> was the last preempt_count increment but you do that _before_ you
> actually change the preempt_count with __preempt_count_sub() at this
> point lockdep and preempt_count think the world differs and *boom*"
>
> So the simplest way to avoid this is by disabling the consistency
> checks.
>
> We also need to take care of the iterating in trace_events_trigger.c
> to avoid a splatter in conjunction with the hist trigger.
>

Looks good to me :)

Reviewed-by: Masami Hiramatsu 

Thanks,

> Signed-off-by: Daniel Wagner 
> Signed-off-by: Binoy Jayan 
> ---
>  include/linux/rculist.h | 36 
>  include/linux/tracepoint.h  |  4 ++--
>  kernel/trace/trace_events_filter.c  |  4 ++--
>  kernel/trace/trace_events_trigger.c |  6 +++---
>  4 files changed, 43 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> index 8beb98d..bee836b 100644
> --- a/include/linux/rculist.h
> +++ b/include/linux/rculist.h
> @@ -279,6 +279,24 @@ static inline void list_splice_tail_init_rcu(struct 
> list_head *list,
> container_of(lockless_dereference(ptr), type, member)
>
>  /**
> + * list_entry_rcu_notrace - get the struct for this entry (for tracing)
> + * @ptr:the &struct list_head pointer.
> + * @type:   the type of the struct this is embedded in.
> + * @member: the name of the list_head within the struct.
> + *
> + * This primitive may safely run concurrently with the _rcu list-mutation
> + * primitives such as list_add_rcu() as long as it's guarded by 
> rcu_read_lock().
> + *
> + * This is the same as list_entry_rcu() except that it does
> + * not do any RCU debugging or tracing.
> + */
> +#define list_entry_rcu_notrace(ptr, type, member) \
> +({ \
> +   typeof(*ptr) __rcu *__ptr = (typeof(*ptr) __rcu __force *)ptr; \
> +   container_of((typeof(ptr))rcu_dereference_raw_notrace(__ptr), type, 
> member); \
> +})
> +
> +/**
>   * Where are list_empty_rcu() and list_first_entry_rcu()?
>   *
>   * Implementing those functions following their counterparts list_empty() and
> @@ -391,6 +409,24 @@ static inline void list_splice_tail_init_rcu(struct 
> list_head *list,
>  pos = list_entry_lockless(pos->member.next, typeof(*pos), 
> member))
>
>  /**
> + * list_for_each_entry_rcu_notrace -   iterate over rcu list of 
> given type (for tracing)
> + * @pos

Re: [PATCH 2/4] docs-rst: Add compressed video formats used on MT8173 codec driver

[Tiffany Lin]

Hi Hans,

On Wed, 2016-09-07 at 11:23 +0200, Hans Verkuil wrote:
> On 09/07/16 08:56, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21C documentation
> >
> > Signed-off-by: Tiffany Lin 
> > ---
> >  Documentation/media/uapi/v4l/pixfmt-reserved.rst |6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-reserved.rst 
> > b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
> > index 0dd2f7f..2e21fbc 100644
> > --- a/Documentation/media/uapi/v4l/pixfmt-reserved.rst
> > +++ b/Documentation/media/uapi/v4l/pixfmt-reserved.rst
> > @@ -339,7 +339,13 @@ please make a proposal on the linux-media mailing list.
> >   array. Anything what's in between the UYVY lines is JPEG data and
> >   should be concatenated to form the JPEG stream.
> >
> > +-  .. _V4L2-PIX-FMT-MT21C:
> >
> > +   -  ``V4L2_PIX_FMT_MT21C``
> > +
> > +   -  'MT21C'
> > +
> > +   -  Compressed two-planar YVU420 format used by Mediatek MT8173.
> 
> This really needs to be expanded.
> 
> Ideally this should reference the precise specification of this format if
> available.
> 

> It certainly should explain which HW blocks of the mediatek SoC use this
> format, it should explain that is it meant as an opaque intermediate format
> between those blocks.
> 

Yes. it is an opaque intermediate format.
VDEC HW only output MT21C format, and it need MDP HW to convert to other
standard format.

At first, we plan to put "convert MT21C to other standard format" in our
v4l2 decoder driver, actually in VPU firmware.
In this case, there is no need to expose MT21C format to user space.

But consider that MDP is a stand alone HW (interrupt, power, clk),
combine decode and format convert in one decode step impact performance.
VDEC HW and MDP HW could process different frame at same time.
MDP may also used by other modules to do format convert, not only VDEC.

That's why we need to expose MT21C to user space.
When user space application enumerate VDEC and display HW and found that
the format is not match.
It need to use MDP driver to do format convert.


> If you have some characteristics (i.e. is it lossy or lossless 
> compression, I
> presume it's lossless), then that will be useful to add as well.
> 
I will update this in next version.


best regards,
Tiffany

> We like to have as much information about formats as possible.
> 
> Regards,
> 
>   Hans
> 
> >
> >  .. tabularcolumns:: |p{6.6cm}|p{2.2cm}|p{8.7cm}|
> >
> >

Re: [ANNOUNCE] 4.8-rc5-rt1 beta

[Mike Galbraith]

On Tue, 2016-09-06 at 14:25 -0400, Paul Gortmaker wrote:

>   Patch conflicts/issues of interest 4.6 --> 4.7
>   --
> 
> -v4.7 introduced a lot of users of down_write_killable which wasn't
>  implemented for -rt (rwsem_rt.h), so I created one.  (see new patch
>  rt-create-down_write_killable.patch -- local commit 14625e96ff085f),
>  it probably warrants a look see from other people smarter than me.

You forgot nested, so btrfs won't build.  I posted a patchlet here that
includes it.

> -Al Viro added a 2nd user of down_read_non_owner into NFS unlink.
>  Previously it was just bcache and Sebastian just made that depend on
>  !RT_FULL (md-disable-bcache.patch).  So we'll need to decide what to
>  with that; I just ignored NFS for now, since it is horrible anyway.
>  (see upstream commit 884be175351e73c)

Yeah, that is annoying.  I've been carrying a revert ever since, with
poke nfs on todo, but it seems to be marooned there (haven't even
gotten around to generating the first obligatory explosion).

-Mike

Re: [Question] about patch: don't use [delayed_]work_pending()

[qiaozhou]

On 2016年09月02日 22:21, Tejun Heo wrote:
> On Fri, Sep 02, 2016 at 09:50:07AM -0400, Tejun Heo wrote:
>> Hello,
>>
>> On Fri, Sep 02, 2016 at 09:17:04AM +0800, qiaozhou wrote:
> I don't know whether it's meaningful to still check pending work here, or
> it's not suggested to use pm_qos_update_request in this early boot up 
> phase.
> Could you help to share some opinions? (I can fix this issue by adding the
> current qos value directly instead of default value, though.)
 Hmmm... but I suppose this is super-early in the boot.  Would it make
 sense to have a static variable (e.g. bool clk_fully_initailized) to
 gate the cancel_delayed_sync() call?
>>> You're right that it's indeed super-early stage. But currently we can't
>>> control the gate of can_delayed_work_sync, since it's inside
>>> pm_qos_update_request. Out of our control. We can choose to not call
>>> pm_qos_update_request to avoid this issue, and use pm_qos_add_request
>>> alternatively. Good to have it.
>> Ah sorry, didn't understand that the offending cancel_sync call is in
>> the generic part.  Hmm... but yeah, we should still be able to take
>> the same approach.  I'll see what's the right thing to gate the
>> operation there.
> Does the following patch work?
The patch can fix this issue. Thanks a lot.
>
> Subject: power: avoid calling cancel_delayed_work_sync() during early boot
>
> of_clk_init() ends up calling into pm_qos_update_request() very early
> during boot where irq is expected to stay disabled.
> pm_qos_update_request() uses cancel_delayed_work_sync() which
> correctly assumes that irq is enabled on invocation and
> unconditionally disables and re-enables it.
>
> Gate cancel_delayed_work_sync() invocation with kevented_up() to avoid
> enabling irq unexpectedly during early boot.
>
> Signed-off-by: Tejun Heo 
> Reported-by: Qiao Zhou 
> Link: 
> http://lkml.kernel.org/r/d2501c4c-8e7b-bea3-1b01-000b36b5d...@asrmicro.com
> ---
>   kernel/power/qos.c |   11 ++-
>1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/power/qos.c b/kernel/power/qos.c
> index 97b0df7..168ff44 100644
> --- a/kernel/power/qos.c
> +++ b/kernel/power/qos.c
> @@ -482,7 +482,16 @@ void pm_qos_update_request(struct pm_qos_request *req,
>   return;
>   }
>   
> - cancel_delayed_work_sync(&req->work);
> + /*
> +  * This function may be called very early during boot, for example,
> +  * from of_clk_init(), where irq needs to stay disabled.
> +  * cancel_delayed_work_sync() assumes that irq is enabled on
> +  * invocation and re-enables it on return.  Avoid calling it until
> +  * workqueue is initialized.
> +  */
> + if (keventd_up())
> + cancel_delayed_work_sync(&req->work);
> +
>   __pm_qos_update_request(req, new_value);
>   }
>   EXPORT_SYMBOL_GPL(pm_qos_update_request);

Re: [PATCH v2 1/1] usb: xhci: fix return value of xhci_setup_device()

[Greg KH]

On Thu, Sep 08, 2016 at 08:41:02AM +0800, Lu Baolu wrote:
> xhci_setup_device() should return failure with correct error number
> when xhci host has died, removed or halted.
> 
> Cc: sta...@vger.kernel.org # 4.3+

Why is this a stable kernel issue?  What bug does it fix that affects
users?

thanks,

greg k-h

[PATCH] lib/syscall: Pin the task stack in collect_syscall()

[Andy Lutomirski]

This will avoid a potential read-after-free if collect_syscall()
(e.g. /proc/PID/syscall) is called on an exiting task.

Reported-by: Jann Horn 
Signed-off-by: Andy Lutomirski 
---

Ingo-

This applies on top of the patches I sent out earlier.  If you want
to avoid any possible bisection issue, you could also apply it in
the middle of the series: put it right after "x86/process: Pin the
target stack in get_wchan".

 lib/syscall.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/lib/syscall.c b/lib/syscall.c
index e30e03932480..63239e097b13 100644
--- a/lib/syscall.c
+++ b/lib/syscall.c
@@ -7,9 +7,19 @@ static int collect_syscall(struct task_struct *target, long 
*callno,
   unsigned long args[6], unsigned int maxargs,
   unsigned long *sp, unsigned long *pc)
 {
-   struct pt_regs *regs = task_pt_regs(target);
-   if (unlikely(!regs))
+   struct pt_regs *regs;
+
+   if (!try_get_task_stack(target)) {
+   /* Task has no stack, so the task isn't in a syscall. */
+   *callno = -1;
+   return 0;
+   }
+
+   regs = task_pt_regs(target);
+   if (unlikely(!regs)) {
+   put_task_stack(target);
return -EAGAIN;
+   }
 
*sp = user_stack_pointer(regs);
*pc = instruction_pointer(regs);
@@ -18,6 +28,7 @@ static int collect_syscall(struct task_struct *target, long 
*callno,
if (*callno != -1L && maxargs > 0)
syscall_get_arguments(target, regs, 0, maxargs, args);
 
+   put_task_stack(target);
return 0;
 }
 
-- 
2.7.4

[patch v4] leds: add driver for Mellanox systems LEDs

[vadimp]

From: Vadim Pasternak 

This makes it possible to create a set of LEDs for Mellanox systems:
"msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410",
"msb7800", "msn2740", "msn2100".

Driver obtains LED devices according to system configuration, provided
through system DMI data, like fan1:green, fan1:red and creates devices in
form: "devicename:colour:function".

LED setting is controlled through on board CPLD Lattice device.
For setting particular LED off, solid, blink:
echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness
echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness
echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger

On module probing all LEDs are set green, on removing - off.

Last setting overwrites previous, f.e. sequence for
changing LED from green - red - green:
echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness
echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness
Note: LEDs cannot be turned on/off simultaneously.

The Kconfig currently controlling compilation of this code is:
drivers/leds/Kconfig:config LEDS_MLXCPLD

Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
---
v3->v4
 Fixes issues pointed out by Jacek:
 - change in all commnets led to LED;
 - add in defines prefix MLXCPLD;
 - add to LED names device prefix mlxcpld;
 - fix long comment stile;
 - replace mlxcpld_led_brightness by mlxcpld_led_set_brightness;
 - replace mlxcpld_led_blink by mlxcpld_led_blink_set
---
v2->v3:
 Fixes issues pointed out by Dave:
 - fix in comments 3KHz and 6KHz to 3Hz and 6Hz respectively;
---
v1->v2:
 Fixes issues pointed out by Jacek:
 - fix style in patch cover text;
 - add doc file with hw description;
 - arrange include directives in alphabetical order;
 - make defines more clear;
 - fix several comments for structure descriptions;
 - add several empty lines between defentions;
 - change max_brightness profile setting to 1 instead of LED_FULL;
 - use capital letters for the enumerator;
 - change in if (product == NULL) to (!product);
 - add comments to mlxcpld_led_store_hw;
 - remove switch statement from mlxcpld_led_brightness;
 - modify mlxcpld_led_blink;
 - remove unnecessary devm_kfree in mlxcpld_led_config;
 - remove switch statement from mlxcpld_led_config;
 - remove platform_get_drvdata from mlxcpld_led_probe;
---
 Documentation/leds/leds-mlxcpld.txt | 110 +
 MAINTAINERS |   8 +
 drivers/leds/Kconfig|   8 +
 drivers/leds/Makefile   |   1 +
 drivers/leds/leds-mlxcpld.c | 429 
 5 files changed, 556 insertions(+)
 create mode 100644 Documentation/leds/leds-mlxcpld.txt
 create mode 100644 drivers/leds/leds-mlxcpld.c

diff --git a/Documentation/leds/leds-mlxcpld.txt 
b/Documentation/leds/leds-mlxcpld.txt
new file mode 100644
index 000..7b4c2a3
--- /dev/null
+++ b/Documentation/leds/leds-mlxcpld.txt
@@ -0,0 +1,110 @@
+ver LEDs-mlxcpld
+==
+Driver for Mellanox systems LEDs.
+Provide system LED support for the nex Mellanox systems:
+"msx6710", "msx6720", "msb7700", "msn2700", "msx1410",
+"msn2410", "msb7800", "msn2740", "msn2100".
+
+Description
+---
+Driver provides the following LEDs for the systems "msx6710", "msx6720",
+"msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740":
+  mlxcpld:fan1:green
+  mlxcpld:fan1:red
+  mlxcpld:fan2:green
+  mlxcpld:fan2:red
+  mlxcpld:fan3:green
+  mlxcpld:fan3:red
+  mlxcpld:fan4:green
+  mlxcpld:fan4:red
+  mlxcpld:psu:green
+  mlxcpld:psu:red
+  mlxcpld:status:green
+  mlxcpld:status:red
+
+ "status"
+  CPLD reg offset: 0x20
+  Bits [3:0]
+
+ "psu"
+  CPLD reg offset: 0x20
+  Bits [7:4]
+
+ "fan1"
+  CPLD reg offset: 0x21
+  Bits [3:0]
+
+ "fan2"
+  CPLD reg offset: 0x21
+  Bits [7:4]
+
+ "fan3"
+  CPLD reg offset: 0x22
+  Bits [3:0]
+
+ "fan4"
+  CPLD reg offset: 0x22
+  Bits [7:4]
+
+ Color mask for all the above LEDs:
+  [bit3,bit2,bit1,bit0] or
+  [bit7,bit6,bit5,bit4]:
+   [0,0,0,0] = LED OFF
+   [0,1,0,1] = Red static ON
+   [1,1,0,1] = Green static ON
+   [0,1,1,0] = Red blink 3Hz
+   [1,1,1,0] = Green blink 3Hz
+   [0,1,1,1] = Red blink 6Hz
+   [1,1,1,1] = Green blink 6Hz
+
+Driver provides the following LEDs for the system "msn2100":
+  mlxcpld:fan:green
+  mlxcpld:fan:red
+  mlxcpld:psu1:green
+  mlxcpld:psu1:red
+  mlxcpld:psu2:green
+  mlxcpld:psu2:red
+  mlxcpld:status:green
+  mlxcpld:status:red
+  mlxcpld:uid:blue
+
+ "status"
+  CPLD reg offset: 0x20
+  Bits [3:0]
+
+ "fan"
+  CPLD reg offset: 0x21
+  Bits [3:0]
+
+ "psu1"
+  CPLD reg offset: 0x23
+  Bits [3:0]
+
+ "psu2"
+  CPLD reg offset: 0x23
+  Bits [7:4]
+
+ "uid"
+  CPLD reg offset: 0x24
+  Bits [3:0]
+
+ Color mask for all the above LEDs, excepted uid:
+  [bit3,bit2,bit1,bit0] or
+  [bit7,bit6,bit5,bit4]:
+   [0,0,0,0] = LED OFF
+   [0,1,0,1] = Red static ON
+   [1,1,0,1] = Green static ON
+   [0,1,1,

Re: Observing Softlockup's while running heavy IOs

[Sreekanth Reddy]

On Wed, Sep 7, 2016 at 6:54 PM, Neil Horman  wrote:
> On Wed, Sep 07, 2016 at 11:30:04AM +0530, Sreekanth Reddy wrote:
>> On Tue, Sep 6, 2016 at 8:36 PM, Neil Horman  wrote:
>> > On Tue, Sep 06, 2016 at 04:52:37PM +0530, Sreekanth Reddy wrote:
>> >> On Fri, Sep 2, 2016 at 4:34 AM, Bart Van Assche
>> >>  wrote:
>> >> > On 09/01/2016 03:31 AM, Sreekanth Reddy wrote:
>> >> >>
>> >> >> I reduced the ISR workload by one third in-order to reduce the time
>> >> >> that is spent per CPU in interrupt context, even then I am observing
>> >> >> softlockups.
>> >> >>
>> >> >> As I mentioned before only same single CPU in the set of CPUs(enabled
>> >> >> in affinity_hint) is busy with handling the interrupts from
>> >> >> corresponding IRQx. I have done below experiment in driver to limit
>> >> >> these softlockups/hardlockups. But I am not sure whether it is
>> >> >> reasonable to do this in driver,
>> >> >>
>> >> >> Experiment:
>> >> >> If the CPUx is continuously busy with handling the remote CPUs
>> >> >> (enabled in the corresponding IRQ's affinity_hint) IO works by 1/4th
>> >> >> of the HBA queue depth in the same ISR context then enable a flag
>> >> >> called 'change_smp_affinity' for this IRQ. Also created a thread with
>> >> >> will poll for this flag for every IRQ's (enabled by driver) for every
>> >> >> second. If this thread see that this flag is enabled for any IRQ then
>> >> >> it will write next CPU number from the CPUs enabled in the IRQ's
>> >> >> affinity_hint to the IRQ's smp_affinity procfs attribute using
>> >> >> 'call_usermodehelper()' API.
>> >> >>
>> >> >> This to make sure that interrupts are not processed by same single CPU
>> >> >> all the time and to make the other CPUs to handle the interrupts if
>> >> >> the current CPU is continuously busy with handling the other CPUs IO
>> >> >> interrupts.
>> >> >>
>> >> >> For example consider a system which has 8 logical CPUs and one MSIx
>> >> >> vector enabled (called IRQ 120) in driver, HBA queue depth as 8K.
>> >> >> then IRQ's procfs attributes will be
>> >> >> IRQ# 120, affinity_hint=0xff, smp_affinity=0x00
>> >> >>
>> >> >> After starting heavy IOs, we will observe that only CPU0 will be busy
>> >> >> with handling the interrupts. This experiment driver will change the
>> >> >> smp_affinity to next CPU number i.e. 0x01 (using cmd 'echo 0x01 >
>> >> >> /proc/irq/120/smp_affinity', driver issue's this cmd using
>> >> >> call_usermodehelper() API) if it observes that CPU0 is continuously
>> >> >> processing more than 2K of IOs replies of other CPUs i.e from CPU1 to
>> >> >> CPU7.
>> >> >>
>> >> >> Whether doing this kind of stuff in driver is ok?
>> >> >
>> >> >
>> >> > Hello Sreekanth,
>> >> >
>> >> > To me this sounds like something that should be implemented in the I/O
>> >> > chipset on the motherboard. If you have a look at the Intel Software
>> >> > Developer Manuals then you will see that logical destination mode 
>> >> > supports
>> >> > round-robin interrupt delivery. However, the Linux kernel selects 
>> >> > physical
>> >> > destination mode on systems with more than eight logical CPUs (see also
>> >> > arch/x86/kernel/apic/apic_flat_64.c).
>> >> >
>> >> > I'm not sure the maintainers of the interrupt subsystem would welcome 
>> >> > code
>> >> > that emulates round-robin interrupt delivery. So your best option is
>> >> > probably to minimize the amount of work that is done in interrupt 
>> >> > context
>> >> > and to move as much work as possible out of interrupt context in such a 
>> >> > way
>> >> > that it can be spread over multiple CPU cores, e.g. by using
>> >> > queue_work_on().
>> >> >
>> >> > Bart.
>> >>
>> >> Bart,
>> >>
>> >> Thanks a lot for providing lot of inputs and valuable information on this 
>> >> issue.
>> >>
>> >> Today I got one more observation. i.e. I am not observing any lockups
>> >> if I use 1.0.4-6 versioned irqbalance.
>> >> Since this versioned irqbalance is able to shift the load to other CPU
>> >> when one CPU is heavily loaded.
>> >>
>> >
>> > This isn't happening because irqbalance is no longer able to shift load 
>> > between
>> > cpus, its happening because of commit 
>> > 996ee2cf7a4d10454de68ac4978adb5cf22850f8.
>> > irqs with higher interrupt volumes sould be balanced to a specific cpu 
>> > core,
>> > rather than to a cache domain to maximize cpu-local cache hit rates.  
>> > Prior to
>> > that change we balanced to a cache domain and your workload didn't have to
>> > serialize multiple interrupts to a single core.  My suggestion to you is 
>> > to use
>> > the --policyscript option to make your storage irqs get balanced to the 
>> > cache
>> > level, rather than the core level.  That should return the behavior to 
>> > what you
>> > want.
>> >
>> > Neil
>>
>> Hi Neil,
>>
>> Thanks for reply.
>>
>> Today I tried with setting balance_level to 'cache' for mpt3sas driver
>> IRQ's using below policy script and used 1.0.9 versioned irqbalance,
>> --

Re: [PATCH v6 3/4] tracing: Add trace_irqsoff tracepoints

[Thomas Gleixner]

On Thu, 8 Sep 2016, Daniel Wagner wrote:
> On 09/07/2016 06:42 PM, Thomas Gleixner wrote:
> > On Wed, 7 Sep 2016, Binoy Jayan wrote:
> > 
> > > This work is based on work by Daniel Wagner. A few tracepoints are added
> > 
> > Interesting. The patch you are referring to was written by Carsten
> > Emde. Can you please get these attributions right? They want to be
> > reflected in the Tags and if you did not rewrite the whole thing from
> > scratch then original authorship must be preserved.
> 
> This is probably my bad. I didn't point out to Binoy that the original idea
> and patches were done by Carsten. Binoy's work is based on my RFC patches from
> 2015. Thanks for pointing out. Let's add Carsten here as well.

Ditto for the hrtimer stuff .

Re: [PATCH] x86: squash lines for simple wrapper functions

[Ingo Molnar]

* Masahiro Yamada  wrote:

> Remove unneeded variables and assignments.  I am also removing
> unnecessary parentheses while I am here.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/x86/kernel/apic/apic_flat_64.c  | 16 +++-
>  arch/x86/kernel/apic/apic_numachip.c |  5 +
>  arch/x86/kernel/apic/x2apic_uv_x.c   |  5 +
>  arch/x86/mm/pat_rbtree.c |  4 +---
>  arch/x86/platform/uv/bios_uv.c   |  7 ++-
>  arch/x86/platform/uv/tlb_uv.c|  6 +-
>  6 files changed, 9 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/x86/kernel/apic/apic_flat_64.c 
> b/arch/x86/kernel/apic/apic_flat_64.c
> index 5b2ae10..c7228f9 100644
> --- a/arch/x86/kernel/apic/apic_flat_64.c
> +++ b/arch/x86/kernel/apic/apic_flat_64.c
> @@ -116,27 +116,17 @@ static void flat_send_IPI_all(int vector)
>  
>  static unsigned int flat_get_apic_id(unsigned long x)
>  {
> - unsigned int id;
> -
> - id = (((x)>>24) & 0xFFu);
> -
> - return id;
> + return ((x) >> 24) & 0xFFu;

So while we are removing unnecessary things, exactly why does the 'x' need 
parentheses?

>  static unsigned long set_apic_id(unsigned int id)
>  {
> - unsigned long x;
> -
> - x = ((id & 0xFFu)<<24);
> - return x;
> + return (id & 0xFFu) << 24;

'id' is already unsigned, why does the 'u' have to be stressed in the literal? 
(Ditto for other places as well)

>  static unsigned long numachip1_set_apic_id(unsigned int id)
>  {
> - unsigned long x;
> -
> - x = ((id & 0xffU) << 24);
> - return x;
> + return (id & 0xffU) << 24;
>  }

Why is the spelling of the literal inconsistent here with the other patterns?

> +++ b/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -533,11 +533,8 @@ static unsigned int x2apic_get_apic_id(unsigned long x)
>  
>  static unsigned long set_apic_id(unsigned int id)
>  {
> - unsigned long x;
> -
>   /* maskout x2apic_extra_bits ? */
> - x = id;
> - return x;
> + return id;
>  }

This was clearly left there to document a quirk and as a placeholder for future 
changes.

Thanks,

Ingo

Re: [PATCH v2 1/2] phy: rockchip-typec: add pm runtime support

[Kishon Vijay Abraham I]

Hi,

On Thursday 08 September 2016 04:36 AM, Chris Zhong wrote:
> Adds pm_runtime support for rockchip Type-C, so that power domain is
> enabled only when there is a transaction going on to help save power.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v2:
> -- add pm_runtime_put_sync in err case
> 
>  drivers/phy/phy-rockchip-typec.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/phy/phy-rockchip-typec.c 
> b/drivers/phy/phy-rockchip-typec.c
> index fb58a27..0b2f528 100644
> --- a/drivers/phy/phy-rockchip-typec.c
> +++ b/drivers/phy/phy-rockchip-typec.c
> @@ -552,6 +552,12 @@ static int tcphy_phy_init(struct rockchip_typec_phy 
> *tcphy, u8 mode)
>   goto err_clk_core;
>   }
>  
> + ret = pm_runtime_get_sync(tcphy->dev);
> + if (ret < 0) {
> + dev_err(tcphy->dev, "cannot get pm runtime %d\n", ret);
> + goto err_clk_ref;
> + }

phy_core will do get_sync for you if.. 
> +
>   reset_control_deassert(tcphy->tcphy_rst);
>  
>   property_enable(tcphy, &cfg->typec_conn_dir, tcphy->flip);
> @@ -600,8 +606,10 @@ static int tcphy_phy_init(struct rockchip_typec_phy 
> *tcphy, u8 mode)
>   return 0;
>  
>  err_wait_pma:
> + pm_runtime_put_sync(tcphy->dev);
>   reset_control_assert(tcphy->uphy_rst);
>   reset_control_assert(tcphy->tcphy_rst);
> +err_clk_ref:
>   clk_disable_unprepare(tcphy->clk_ref);
>  err_clk_core:
>   clk_disable_unprepare(tcphy->clk_core);
> @@ -610,6 +618,7 @@ err_clk_core:
>  
>  static void tcphy_phy_deinit(struct rockchip_typec_phy *tcphy)
>  {
> + pm_runtime_put_sync(tcphy->dev);
>   reset_control_assert(tcphy->tcphy_rst);
>   reset_control_assert(tcphy->uphy_rst);
>   reset_control_assert(tcphy->pipe_rst);
> @@ -987,6 +996,15 @@ static int rockchip_typec_phy_probe(struct 
> platform_device *pdev)
>   return PTR_ERR(phy_provider);
>   }
>  
> + pm_runtime_enable(dev);

... pm_runtime_enable is invoked before phy_create.

Thanks
Kishon

[tip:x86/platform] x86/cpu: Rename Merrifield2 to Moorefield

[tip-bot for Andy Shevchenko]

Commit-ID:  f5fbf848303c8704d0e1a1e7cabd08fd0a49552f
Gitweb: http://git.kernel.org/tip/f5fbf848303c8704d0e1a1e7cabd08fd0a49552f
Author: Andy Shevchenko 
AuthorDate: Tue, 6 Sep 2016 21:42:54 +0300
Committer:  Ingo Molnar 
CommitDate: Thu, 8 Sep 2016 08:13:08 +0200

x86/cpu: Rename Merrifield2 to Moorefield

Merrifield2 is actually Moorefield.

Rename it accordingly and drop tail digit from Merrifield1.

Signed-off-by: Andy Shevchenko 
Cc: Dave Hansen 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/20160906184254.94440-1-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/intel-family.h   | 4 ++--
 arch/x86/platform/atom/punit_atom_debug.c | 2 +-
 drivers/pci/pci-mid.c | 2 +-
 drivers/powercap/intel_rapl.c | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/intel-family.h 
b/arch/x86/include/asm/intel-family.h
index 6277194..9ae5ab8 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -56,8 +56,8 @@
 #define INTEL_FAM6_ATOM_SILVERMONT10x37 /* BayTrail/BYT / Valleyview */
 #define INTEL_FAM6_ATOM_SILVERMONT20x4D /* Avaton/Rangely */
 #define INTEL_FAM6_ATOM_AIRMONT0x4C /* CherryTrail / Braswell 
*/
-#define INTEL_FAM6_ATOM_MERRIFIELD10x4A /* Tangier */
-#define INTEL_FAM6_ATOM_MERRIFIELD20x5A /* Annidale */
+#define INTEL_FAM6_ATOM_MERRIFIELD 0x4A /* Tangier */
+#define INTEL_FAM6_ATOM_MOOREFIELD 0x5A /* Annidale */
 #define INTEL_FAM6_ATOM_GOLDMONT   0x5C
 #define INTEL_FAM6_ATOM_DENVERTON  0x5F /* Goldmont Microserver */
 
diff --git a/arch/x86/platform/atom/punit_atom_debug.c 
b/arch/x86/platform/atom/punit_atom_debug.c
index 8ff7b93..d49d3be 100644
--- a/arch/x86/platform/atom/punit_atom_debug.c
+++ b/arch/x86/platform/atom/punit_atom_debug.c
@@ -155,7 +155,7 @@ static void punit_dbgfs_unregister(void)
 
 static const struct x86_cpu_id intel_punit_cpu_ids[] = {
ICPU(INTEL_FAM6_ATOM_SILVERMONT1, punit_device_byt),
-   ICPU(INTEL_FAM6_ATOM_MERRIFIELD1, punit_device_tng),
+   ICPU(INTEL_FAM6_ATOM_MERRIFIELD,  punit_device_tng),
ICPU(INTEL_FAM6_ATOM_AIRMONT, punit_device_cht),
{}
 };
diff --git a/drivers/pci/pci-mid.c b/drivers/pci/pci-mid.c
index c878aa7..b7ea64f 100644
--- a/drivers/pci/pci-mid.c
+++ b/drivers/pci/pci-mid.c
@@ -61,7 +61,7 @@ static struct pci_platform_pm_ops mid_pci_platform_pm = {
 #define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
 
 static const struct x86_cpu_id lpss_cpu_ids[] = {
-   ICPU(INTEL_FAM6_ATOM_MERRIFIELD1),
+   ICPU(INTEL_FAM6_ATOM_MERRIFIELD),
{}
 };
 
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index fbab29d..243b233 100644
--- a/drivers/powercap/intel_rapl.c
+++ b/drivers/powercap/intel_rapl.c
@@ -1154,8 +1154,8 @@ static const struct x86_cpu_id rapl_ids[] __initconst = {
 
RAPL_CPU(INTEL_FAM6_ATOM_SILVERMONT1,   rapl_defaults_byt),
RAPL_CPU(INTEL_FAM6_ATOM_AIRMONT,   rapl_defaults_cht),
-   RAPL_CPU(INTEL_FAM6_ATOM_MERRIFIELD1,   rapl_defaults_tng),
-   RAPL_CPU(INTEL_FAM6_ATOM_MERRIFIELD2,   rapl_defaults_ann),
+   RAPL_CPU(INTEL_FAM6_ATOM_MERRIFIELD,rapl_defaults_tng),
+   RAPL_CPU(INTEL_FAM6_ATOM_MOOREFIELD,rapl_defaults_ann),
RAPL_CPU(INTEL_FAM6_ATOM_GOLDMONT,  rapl_defaults_core),
RAPL_CPU(INTEL_FAM6_ATOM_DENVERTON, rapl_defaults_core),
 

[tip:x86/urgent] x86/apic: Fix num_processors value in case of failure

[tip-bot for Dou Liyang]

Commit-ID:  c291b015158577be533dd5a959dfc09bab119eed
Gitweb: http://git.kernel.org/tip/c291b015158577be533dd5a959dfc09bab119eed
Author: Dou Liyang 
AuthorDate: Wed, 7 Sep 2016 10:21:33 +0800
Committer:  Ingo Molnar 
CommitDate: Thu, 8 Sep 2016 08:11:03 +0200

x86/apic: Fix num_processors value in case of failure

If the topology package map check of the APIC ID and the CPU is a failure,
we don't generate the processor info for that APIC ID yet we increase
disabled_cpus by one - which is buggy.

Only increase num_processors once we are sure we don't fail.

Signed-off-by: Dou Liyang 
Acked-by: David Rientjes 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1473214893-16481-1-git-send-email-douly.f...@cn.fujitsu.com
[ Rewrote the changelog. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/apic/apic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 50c95af..f3e9b2d 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2093,7 +2093,6 @@ int generic_processor_info(int apicid, int version)
return -EINVAL;
}
 
-   num_processors++;
if (apicid == boot_cpu_physical_apicid) {
/*
 * x86_bios_cpu_apicid is required to have processors listed
@@ -2116,10 +2115,13 @@ int generic_processor_info(int apicid, int version)
 
pr_warning("APIC: Package limit reached. Processor %d/0x%x 
ignored.\n",
   thiscpu, apicid);
+
disabled_cpus++;
return -ENOSPC;
}
 
+   num_processors++;
+
/*
 * Validate version
 */

[tip:x86/platform] x86/platform/intel-mid: Implement power off sequence

[tip-bot for Andy Shevchenko]

Commit-ID:  bda7b072de999280ef78aaea4335ec58afc4bdb2
Gitweb: http://git.kernel.org/tip/bda7b072de999280ef78aaea4335ec58afc4bdb2
Author: Andy Shevchenko 
AuthorDate: Wed, 7 Sep 2016 15:39:55 +0300
Committer:  Ingo Molnar 
CommitDate: Thu, 8 Sep 2016 08:03:58 +0200

x86/platform/intel-mid: Implement power off sequence

Tell SCU that we are about powering off the device.

Signed-off-by: Andy Shevchenko 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/20160907123955.21228-1-andriy.shevche...@linux.intel.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/intel-mid.h|  2 ++
 arch/x86/include/asm/intel_scu_ipc.h|  2 ++
 arch/x86/platform/intel-mid/intel-mid.c |  5 +
 arch/x86/platform/intel-mid/pwr.c   | 24 +++-
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index 9d6b097..5b6753d 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -18,6 +18,8 @@
 extern int intel_mid_pci_init(void);
 extern int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t 
state);
 
+extern void intel_mid_pwr_power_off(void);
+
 #define INTEL_MID_PWR_LSS_OFFSET   4
 #define INTEL_MID_PWR_LSS_TYPE (1 << 7)
 
diff --git a/arch/x86/include/asm/intel_scu_ipc.h 
b/arch/x86/include/asm/intel_scu_ipc.h
index 925b605..4fb1d0a 100644
--- a/arch/x86/include/asm/intel_scu_ipc.h
+++ b/arch/x86/include/asm/intel_scu_ipc.h
@@ -3,6 +3,8 @@
 
 #include 
 
+#define IPCMSG_COLD_OFF0x80/* Only for Tangier */
+
 #define IPCMSG_WARM_RESET  0xF0
 #define IPCMSG_COLD_RESET  0xF1
 #define IPCMSG_SOFT_RESET  0xF2
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index ce119d2..7850128 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -70,6 +70,11 @@ EXPORT_SYMBOL_GPL(__intel_mid_cpu_chip);
 
 static void intel_mid_power_off(void)
 {
+   /* Shut down South Complex via PWRMU */
+   intel_mid_pwr_power_off();
+
+   /* Only for Tangier, the rest will ignore this command */
+   intel_scu_ipc_simple_command(IPCMSG_COLD_OFF, 1);
 };
 
 static void intel_mid_reboot(void)
diff --git a/arch/x86/platform/intel-mid/pwr.c 
b/arch/x86/platform/intel-mid/pwr.c
index 0548741..2dfe998 100644
--- a/arch/x86/platform/intel-mid/pwr.c
+++ b/arch/x86/platform/intel-mid/pwr.c
@@ -48,7 +48,15 @@
 #define PM_CMD_CM_IMMEDIATE(1 << 9)
 #define PM_CMD_CM_DELAY(2 << 9)
 #define PM_CMD_CM_TRIGGER  (3 << 9)
-#define PM_CMD_D3cold  (1 << 21)
+
+/* System states */
+#define PM_CMD_SYS_STATE_S5(5 << 16)
+
+/* Trigger variants */
+#define PM_CMD_CFG_TRIGGER_NC  (3 << 19)
+
+/* Message to wait for TRIGGER_NC case */
+#define TRIGGER_NC_MSG_2   (2 << 22)
 
 /* List of commands */
 #define CMD_SET_CFG0x01
@@ -264,6 +272,20 @@ int intel_mid_pci_set_power_state(struct pci_dev *pdev, 
pci_power_t state)
 }
 EXPORT_SYMBOL_GPL(intel_mid_pci_set_power_state);
 
+void intel_mid_pwr_power_off(void)
+{
+   struct mid_pwr *pwr = midpwr;
+   u32 cmd = PM_CMD_SYS_STATE_S5 |
+ PM_CMD_CMD(CMD_SET_CFG) |
+ PM_CMD_CM_TRIGGER |
+ PM_CMD_CFG_TRIGGER_NC |
+ TRIGGER_NC_MSG_2;
+
+   /* Send command to SCU */
+   writel(cmd, pwr->regs + PM_CMD);
+   mid_pwr_wait(pwr);
+}
+
 int intel_mid_pwr_get_lss_id(struct pci_dev *pdev)
 {
int vndr;

Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Wei Chen]

Hi Vitaly,

On 2016/9/5 17:42, Vitaly Kuznetsov wrote:
> Julien Grall  writes:
>
>> Hi Vitaly,
>>
>> On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
>>> on the vCPU which crashed. This doesn't work very well for PVHVM guests as
>>> we have a number of hypercalls where we pass vCPU id as a parameter. These
>>> hypercalls either fail or do something unexpected. To solve the issue
>>> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping
>>> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
>>> CPUs it is a bit more trickier. Currently, we initialize IPI vectors
>>> before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
>>> instead.
>>>
>>> Signed-off-by: Vitaly Kuznetsov 
>>> ---
>>> Changes since v2:
>>> - Use uint32_t for xen_vcpu_id mapping [Julien Grall]
>>>
>>> Changes since v1:
>>> - Introduce xen_vcpu_nr() helper [David Vrabel]
>>> - Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
>>> ---
>>>  arch/arm/xen/enlighten.c | 10 ++
>>>  arch/x86/xen/enlighten.c | 23 ++-
>>>  include/xen/xen-ops.h|  6 ++
>>>  3 files changed, 38 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>>> index 75cd734..fe32267 100644
>>> --- a/arch/arm/xen/enlighten.c
>>> +++ b/arch/arm/xen/enlighten.c
>>> @@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
>>> *)&xen_dummy_shared_info;
>>>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>>  static struct vcpu_info __percpu *xen_vcpu_info;
>>>
>>> +/* Linux <-> Xen vCPU id mapping */
>>> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
>>> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
>>> +
>>>  /* These are unused until we support booting "pre-ballooned" */
>>>  unsigned long xen_released_pages;
>>>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] 
>>> __initdata;
>>> @@ -179,6 +183,9 @@ static void xen_percpu_init(void)
>>>  pr_info("Xen: initializing cpu%d\n", cpu);
>>>  vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>>>
>>> +/* Direct vCPU id mapping for ARM guests. */
>>> +per_cpu(xen_vcpu_id, cpu) = cpu;
>>> +
>>
>> We did some internal testing on ARM64 with the latest Linux kernel
>> (4.8-rc4) and noticed that this patch is breaking SMP support. Sorry
>> for noticing the issue that late.
>
> Sorry for the breakage :-(
>
>>
>> This function is called on the running CPU whilst some code (e.g
>> init_control_block in drivers/xen/events/events_fifo.c) is executed
>> whilst preparing the CPU on the boot CPU.
>>
>> So xen_vcpu_nr(cpu) will always return 0 in this case and
>> init_control_block will fail to execute.
>>
>
> I see,
>
> CPU_UP_PREPARE event happens before xen_starting_cpu() is called.
>
>
>> I am not sure how to fix. I guess we could setup per_cpu(xen_vcpu_id,
>> *) in xen_guest_init. Any opinions?
>
> As we're not doing kexec on ARM we can fix the immediate issue. I don't
> know much about ARM and unfortunatelly I don't have a setup to test but
> it seems there is no early_per_cpu* infrastructure for ARM so we may fix
> it with the following:
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 3d2cef6..f193414 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -170,9 +170,6 @@ static int xen_starting_cpu(unsigned int cpu)
> pr_info("Xen: initializing cpu%d\n", cpu);
> vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>
> -   /* Direct vCPU id mapping for ARM guests. */
> -   per_cpu(xen_vcpu_id, cpu) = cpu;
> -
> info.mfn = virt_to_gfn(vcpup);
> info.offset = xen_offset_in_page(vcpup);
>
> @@ -330,6 +327,7 @@ static int __init xen_guest_init(void)
>  {
> struct xen_add_to_physmap xatp;
> struct shared_info *shared_info_page = NULL;
> +   int cpu;
>
> if (!xen_domain())
> return 0;
> @@ -380,7 +378,8 @@ static int __init xen_guest_init(void)
> return -ENOMEM;
>
> /* Direct vCPU id mapping for ARM guests. */
> -   per_cpu(xen_vcpu_id, 0) = 0;
> +   for_each_possible_cpu(cpu)
> +   per_cpu(xen_vcpu_id, cpu) = cpu;
>
> xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
> if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
>
> (not tested, if we can't use for_each_possible_cpu() that early we'll
> have to check against NR_CPUS instead).
>

I have tested this patch just now, it can work with the latest Linux
kernel and latest Xen hypervisor on my ARM platform:

[0.299927] xen:events: Using FIFO-based ABI
[0.304259] Xen: initializing cpu0
[0.336402] EFI services will not be available.
[0.388985] Detected PIPT I-cache on CPU1
[0.389024] Xen: initia

Re: [PATCH, net-next] perf, bpf: fix conditional call to bpf_overflow_handler

[Ingo Molnar]

* Alexei Starovoitov  wrote:

> On Tue, Sep 06, 2016 at 03:10:22PM +0200, Arnd Bergmann wrote:
> > The newly added bpf_overflow_handler function is only built of both
> > CONFIG_EVENT_TRACING and CONFIG_BPF_SYSCALL are enabled, but the caller
> > only checks the latter:
> > 
> > kernel/events/core.c: In function 'perf_event_alloc':
> > kernel/events/core.c:9106:27: error: 'bpf_overflow_handler' undeclared 
> > (first use in this function)
> > 
> > This changes the caller so we also skip this call if CONFIG_EVENT_TRACING
> > is disabled entirely.
> > 
> > Signed-off-by: Arnd Bergmann 
> > Fixes: aa6a5f3cb2b2 ("perf, bpf: add perf events core support for 
> > BPF_PROG_TYPE_PERF_EVENT programs")
> > ---
> >  kernel/events/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > I'm not entirely sure if this is the correct solution, please check before 
> > applying
> 
> Acked-by: Alexei Starovoitov 
> 
> Thanks for the fix. Just saw build bot complaining last night and
> by the morning your fix is already here. Thanks!

Guys, this is the first time I saw this patch (and presumably there's some 
other 
patch as well?) - could you please submit it properly for review and get an 
Acked-by from one of the perf maintainers before appying it?

Thanks,

Ingo

Re: drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer

[Greg Kroah-Hartman]

On Wed, Sep 07, 2016 at 05:38:52PM +0100, Nick Warne wrote:
> Hi Daniel,
> 
> kernel build 4.4.20 - I am still seeing this warning:
> 
> drivers/gpu/drm/i915/intel_display.c: In function
> ‘intel_plane_obj_offset’: drivers/gpu/drm/i915/intel_display.c:2969:11:
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast] offset = (unsigned char *)vma->node.start;
> 
> but according to here:
> 
> https://patchwork.kernel.org/patch/7897461/
> 
> this has been fixed up.  Any reason why it hasn't in the latest 4.4.x
> longterm tree?

What is the commit id that fixed this in Linus's tree?

thanks,

greg k-h

Re: [PATCH v4 1/8] dts: sun8i-h3: drop _a and address suffix from uart0 pinmux

[Maxime Ripard]

Hi,

On Wed, Sep 07, 2016 at 09:58:54AM +0200, jo...@kippendief.biz wrote:
> From: Jorik Jonker 
> 
> These are the only possible pins for UART0 on H3

That's not true, you can also mux it on PF2 / PF4.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH v4 2/8] dts: sun8i-h3: clarify uart1 pinmux definition name

[Maxime Ripard]

Hi,

On Wed, Sep 07, 2016 at 09:58:55AM +0200, jo...@kippendief.biz wrote:
> From: Jorik Jonker 
> 
> Signed-off-by: Jorik Jonker 

Commit log?

> ---
>  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 2 +-
>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts 
> b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> index 3779280..45f623b 100644
> --- a/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts
> @@ -185,7 +185,7 @@
>  
>  &uart1 {
>   pinctrl-names = "default";
> - pinctrl-0 = <&uart1_pins_a>;
> + pinctrl-0 = <&uart1_rts_cts_pins>;
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index ee10004..933d42c 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -367,7 +367,7 @@
>   allwinner,pull = ;
>   };
>  
> - uart1_pins_a: uart1@0 {
> + uart1_rts_cts_pins: uart1_rts_cts {
>   allwinner,pins = "PG6", "PG7", "PG8", "PG9";

I'd prefer to have one pinctrl node for RX/TX, and one for
RTS/CTS. That way, we don't have to duplicate the nodes for the boards
that want to enable only RX/TX

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH v5 2/3] Documentation/filesystems: Fixed typo

[Jonathan Corbet]

On Wed, 7 Sep 2016 20:22:00 -0400
Robert Foss  wrote:

> > This could be taken directly into the docs tree, I think -- no reason
> > to make it depend on the rest of the series.  
> 
> Agreed. Would you like a separate submission for that?

Please, I've lost track of the original...

Thanks,

jon

Re: [PATCH v2 0/5] perf, bts: Fallout from the fuzzer for perf/urgent

[Ingo Molnar]

* Ingo Molnar  wrote:

> Yeah, please re-send it - and please also Vince's Reported-by tag to all 
> commits 
   ^--- add
> that would explain failures that Vince reported.

Thanks,

Ingo

checkpatch.pl: Use of uninitialized value $str in split at ./scripts/checkpatch.pl line 1079.

[Charlemagne Lasse]

Hi,

I've noticed that checkpatch prints an error in linux-next. This can
be reproduced via

./scripts/checkpatch.pl --strict --file net/batman-adv/bat_iv_ogm.c

This problem seems to be introduced by d369873d2f53 ("Merge branch
'akpm-current/current'") which is a merge of 6a6594aace5c ("Merge
remote-tracking branch 'nvdimm/libnvdimm-for-next'") and cdaa6aa1e90c
("kexec_file fixup"). But please check this because I am new to
git-bisect

Greetings

Re: [PATCH v4 4/8] dts: sun8i-h3: move uart1 pinmux/peripheral assocation to DSTI

[Maxime Ripard]

On Wed, Sep 07, 2016 at 09:58:57AM +0200, jo...@kippendief.biz wrote:
> From: Jorik Jonker 
> 
> Users using this UART without RTS/CTS should override the association in
> their board specific DTS. All (1) board using this UART uses RTS/CTS, so
> this breaks nothing.

Using RTS / CTS is very rare among the boards. Forcing it down the
throat of every user doesn't seem like the right thing to do.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

[Alexander Stein]

On Thursday 08 September 2016 10:04:55, Meng Yi wrote:
> If the FTM counter reaches the FTM_MOD value between the reading of the
> TOF bit and the writing of 0 to the TOF bit, the process of clearing the
> TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
> current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
> is met, the TOF bit remains set. If the TOF interrupt is enabled
> (FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.
> 
> Above is the errata discription
> 
> The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
> always reache the FTM_MOD anyway),which may cost some cycles.
> 
> Signed-off-by: Meng Yi 
> ---
>  drivers/clocksource/fsl_ftm_timer.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clocksource/fsl_ftm_timer.c
> b/drivers/clocksource/fsl_ftm_timer.c index 738515b..ade26e5 100644
> --- a/drivers/clocksource/fsl_ftm_timer.c
> +++ b/drivers/clocksource/fsl_ftm_timer.c
> @@ -83,11 +83,10 @@ static inline void ftm_counter_disable(void __iomem
> *base)
> 
>  static inline void ftm_irq_acknowledge(void __iomem *base)
>  {
> - u32 val;
> -
> - val = ftm_readl(base + FTM_SC);
> - val &= ~FTM_SC_TOF;
> - ftm_writel(val, base + FTM_SC);
> + /*read and clean the FTM_SC_TOF bit until its cleared*/
> + while (FTM_SC_TOF & ftm_readl(base + FTM_SC))
> + ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
> +base + FTM_SC);
>  }

So you are essentially polling hardware in interrupt context. Please add a 
sensible timeout to abort this loop in case of defective hardware, and maybe 
disable the interrupt in that case.

Best regards,
Alexander

Re: [PATCH v4 3/8] dts: sun8i-h3: move uart0 pinmux/peripheral assocation to DSTI

[Maxime Ripard]

On Wed, Sep 07, 2016 at 09:58:56AM +0200, jo...@kippendief.biz wrote:
> From: Jorik Jonker 
> 
> This is the only sensible pinmux/peripheral association for uart0, so I have
> moved it from the board specific DTS to the DTSI. It is still up to the boards
> to enable it, though.
> 
> Signed-off-by: Jorik Jonker 

There's really several options for the UART0 to be muxed, so it's
better if we leave that to the board entirely.

That's useful only for pins where you truely have only a single
option in the entire SoC.

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Leon Romanovsky]

On Wed, Sep 07, 2016 at 08:37:23PM +0530, Parav Pandit wrote:
> Hi Leon,
>
> >> Signed-off-by: Parav Pandit 
> >> +static struct rdmacg_resource_pool *
> >> +get_cg_rpool_locked(struct rdma_cgroup *cg, struct rdmacg_device *device)
> >> +{
> >> + struct rdmacg_resource_pool *rpool;
> >> +
> >> + rpool = find_cg_rpool_locked(cg, device);
> >> + if (rpool)
> >> + return rpool;
> >> +
> >> + rpool = kzalloc(sizeof(*rpool), GFP_KERNEL);
> >> + if (!rpool)
> >> + return ERR_PTR(-ENOMEM);
> >> +
> >> + rpool->device = device;
> >> + set_all_resource_max_limit(rpool);
> >> +
> >> + INIT_LIST_HEAD(&rpool->cg_node);
> >> + INIT_LIST_HEAD(&rpool->dev_node);
> >> + list_add_tail(&rpool->cg_node, &cg->rpools);
> >> + list_add_tail(&rpool->dev_node, &device->rpools);
> >> + return rpool;
> >> +}
> >
> > <...>
> >
> >> + for (p = cg; p; p = parent_rdmacg(p)) {
> >> + rpool = get_cg_rpool_locked(p, device);
> >> + if (IS_ERR_OR_NULL(rpool)) {
> >
> > get_cg_rpool_locked always returns !NULL (error, or pointer)
>
> Can this change go as incremental change after this patch, since this
> patch is close to completion?
> Or I need to revise v13?

Sure, it is cleanup. It is not worth of respinning.

>
> >
> >> + ret = PTR_ERR(rpool);
> >> + goto err;
> >
> > I didn't review the whole series yet.
>
> Did you get a chance to review the series?

We need to decide on fundamental question before reviewing it, which is
"how to fit rdmacg to new ABI model".

Thanks


signature.asc
Description: PGP signature

Re: [PATCH v2 0/5] perf, bts: Fallout from the fuzzer for perf/urgent

[Ingo Molnar]

* Alexander Shishkin  wrote:

> Ingo Molnar  writes:
> 
> > * Alexander Shishkin  wrote:
> >
> >> Hi,
> >> 
> >> There were more bugs since the previous version, plus the BTS barriers got 
> >> fixed. With these patches, my testcase keeps running and no spurious NMI 
> >> warnings pop up any more.
> >
> > Could you please also run the fuzzer that Vince uses, does it now pass on 
> > hardware 
> > you have access to?
> 
> Sure. And yes, I did catch a warning, which calls for one more patch
> (below). Also one unrelated thing in PEBS that Peter fixed.
> 
> > I'd like to make "passes the fuzzer" a standard requirement before new 
> > changes are 
> > accepted to perf core.
> 
> Let's make it so.
> 
> For the sake of consistency, this one needs to go before 3/5. I'll
> re-send the whole series, though, if need be. I've got 2 perf_fuzzers
> running on this meanwhile.

Yeah, please re-send it - and please also Vince's Reported-by tag to all 
commits 
that would explain failures that Vince reported.

Also, please document how much and what type of fuzzer testing the series got: 
fuzzer version, time it ran and (rough) hardware it ran on would be useful. 
(That 
way we can look back later on whether there was any fuzzer testing on AMD 
systems 
for example, which you might not be able to perform.)

It would also be very, very nice to also add a Documentation/perf/testing.txt 
step 
by step ELI5 style document that explains how to set up and run the fuzzer!

> + * registers, so the PMU state remains unchanged.
> + *
> + * intel_bts events don't coexist with intel pmu's BTS events because of
> + * x86_add_exclusive(x86_lbr_exclusive_lbr); there's no need to keep them
> + * disabled around intel pmu's event batching etc, only inside the PMI 
> handler.

Pet peeve nit: please capitalize 'PMU' correctly and consistently (upper case). 
This paragraph has both variants: "PMU" and "pmu" which is the worst variant 
really.

Thanks,

Ingo

linux-next: Tree for Sep 8

[Stephen Rothwell]

Hi all,

Changes since 20160907:

The btrfs-kdave tree still had its build failure so I used the version
from next-20160906.

The drm-intel tree gained a conflict aginst Linus' tree.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

Non-merge commits (relative to Linus' tree): 5695
 5456 files changed, 262032 insertions(+), 100267 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 240 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (80a77045daac Merge tag 'usercopy-v4.8-rc6-part2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (da60626e7d02 ARM: sa1100: clear reset status prior 
to reboot)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (78a3e8889b4b powerpc: signals: Discard transaction 
state from signal frames)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (751eb6b6042a ipv6: addrconf: fix dev refcont leak when DAD 
failed)
Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups)
Merging netfilter/master (d1a6cba576fc netfilter: nft_chain_route: re-route 
before skb is queued to userspace)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (61aaa0e8c1c1 cfg80211: Add stub for 
cfg80211_get_station())
Merging sound-current/for-linus (7a5fa2b81bc5 ALSA: timer: Fix zero-division by 
continue of uninitialized instance)
Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control 
Unit as having non-compliant BARs)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (c6935931c189 Linux 4.8-rc5)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add 
WeTelecom 0x6802 and 0x6803 products)
Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: 
don't touch DP when controller is in host mode)
Merging staging.current/staging-linus (c6935931c189 Linux 4.8-rc5)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant 
regulator_disable call)
Merging crypto-current/master (0bd2223594a4 crypto: cryptd - initialize child 
shash_desc on import)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops

Re: [RFC 0/4] ZRAM: make it just store the high compression rate page

[Minchan Kim]

On Mon, Sep 05, 2016 at 01:12:05PM +0800, Hui Zhu wrote:
> On Mon, Sep 5, 2016 at 10:18 AM, Minchan Kim  wrote:
> > On Thu, Aug 25, 2016 at 04:25:30PM +0800, Hui Zhu wrote:
> >> On Thu, Aug 25, 2016 at 2:09 PM, Sergey Senozhatsky
> >>  wrote:
> >> > Hello,
> >> >
> >> > On (08/22/16 16:25), Hui Zhu wrote:
> >> >>
> >> >> Current ZRAM just can store all pages even if the compression rate
> >> >> of a page is really low.  So the compression rate of ZRAM is out of
> >> >> control when it is running.
> >> >> In my part, I did some test and record with ZRAM.  The compression rate
> >> >> is about 40%.
> >> >>
> >> >> This series of patches make ZRAM can just store the page that the
> >> >> compressed size is smaller than a value.
> >> >> With these patches, I set the value to 2048 and did the same test with
> >> >> before.  The compression rate is about 20%.  The times of 
> >> >> lowmemorykiller
> >> >> also decreased.
> >> >
> >> > I haven't looked at the patches in details yet. can you educate me a bit?
> >> > is your test stable? why the number of lowmemorykill-s has decreased?
> >> > ... or am reading "The times of lowmemorykiller also decreased" wrong?
> >> >
> >> > suppose you have X pages that result in bad compression size (from zram
> >> > point of view). zram stores such pages uncompressed, IOW we have no 
> >> > memory
> >> > savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you
> >> > don't try to store those pages in zsmalloc, but keep them as unevictable.
> >> > so the page still occupies PAGE_SIZE; no memory saving again. why did it
> >> > improve LMK?
> >>
> >> No, zram will not save this page uncompressed with these patches.  It
> >> will set it as non-swap and kick back to shrink_page_list.
> >> Shrink_page_list will remove this page from swapcache and kick it to
> >> unevictable list.
> >> Then this page will not be swaped before it get write.
> >> That is why most of code are around vmscan.c.
> >
> > If I understand Sergey's point right, he means there is no gain
> > to save memory between before and after.
> >
> > With your approach, you can prevent unnecessary pageout(i.e.,
> > uncompressible page swap out) but it doesn't mean you save the
> > memory compared to old so why does your patch decrease the number of
> > lowmemory killing?
> >
> > A thing I can imagine is without this feature, zram could be full of
> > uncompressible pages so good-compressible page cannot be swapped out.
> > Hui, is this scenario right for your case?
> >
> 
> That is one reason.  But it is not the principal one.
> 
> Another reason is when swap is running to put page to zram, what the
> system wants is to get memory.
> Then the deal is system spends cpu time and memory to get memory. If
> the zram just access the high compression rate pages, system can get
> more memory with the same amount of memory. It will pull system from
> low memory status earlier. (Maybe more cpu time, because the
> compression rate checks. But maybe less, because fewer pages need to
> digress. That is the interesting part. :)
> I think that is why lmk times decrease.
> 
> And yes, all of this depends on the number of high compression rate
> pages. So you cannot just set a non_swap limit to the system and get
> everything. You need to do a lot of test around it to make sure the
> non_swap limit is good for your system.
> 
> And I think use AOP_WRITEPAGE_ACTIVATE without kicking page to a
> special list will make cpu too busy sometimes.

Yes, and it would same with your patch if new arraival write on CoWed
page is uncompressible data.

> I did some tests before I kick page to a special list. The shrink task

What kinds of test? Could you elaborate a bit more?
shrink task. What does it mean?

> will be moved around, around and around because low compression rate
> pages just moved from one list to another a lot of times, again, again
> and again.
> And all this low compression rate pages always stay together.

I cannot understand with detail description. :(
Could you explain more?

Re: [PATCH] [media] VPU: mediatek: fix null pointer dereference on pdev

[Tiffany Lin]

On Wed, 2016-09-07 at 18:10 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> pdev is being null checked, however, prior to that it is being
> dereferenced by platform_get_drvdata.  Move the assignments of
> vpu and run to after the pdev null check to avoid a potential
> null pointer dereference.
> 

Reviewed-by:Tiffany Lin 

> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/platform/mtk-vpu/mtk_vpu.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c 
> b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> index c9bf58c..43907a3 100644
> --- a/drivers/media/platform/mtk-vpu/mtk_vpu.c
> +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
> @@ -523,9 +523,9 @@ static int load_requested_vpu(struct mtk_vpu *vpu,
>  
>  int vpu_load_firmware(struct platform_device *pdev)
>  {
> - struct mtk_vpu *vpu = platform_get_drvdata(pdev);
> + struct mtk_vpu *vpu;
>   struct device *dev = &pdev->dev;
> - struct vpu_run *run = &vpu->run;
> + struct vpu_run *run;
>   const struct firmware *vpu_fw = NULL;
>   int ret;
>  
> @@ -534,6 +534,9 @@ int vpu_load_firmware(struct platform_device *pdev)
>   return -EINVAL;
>   }
>  
> + vpu = platform_get_drvdata(pdev);
> + run = &vpu->run;
> +
>   mutex_lock(&vpu->vpu_mutex);
>   if (vpu->fw_loaded) {
>   mutex_unlock(&vpu->vpu_mutex);

Re: [PATCH v6 3/4] tracing: Add trace_irqsoff tracepoints

[Daniel Wagner]

On 09/07/2016 06:42 PM, Thomas Gleixner wrote:

On Wed, 7 Sep 2016, Binoy Jayan wrote:


This work is based on work by Daniel Wagner. A few tracepoints are added


Interesting. The patch you are referring to was written by Carsten
Emde. Can you please get these attributions right? They want to be
reflected in the Tags and if you did not rewrite the whole thing from
scratch then original authorship must be preserved.


This is probably my bad. I didn't point out to Binoy that the original 
idea and patches were done by Carsten. Binoy's work is based on my RFC 
patches from 2015. Thanks for pointing out. Let's add Carsten here as well.


Sorry about that.

cheers,
daniel

[PATCH v4] dt-bindings: Add jdi lt070me05000 panel bindings

[Vinay Simha BN]

Add documentation for lt070me05000 panel

Cc: Archit Taneja 
Cc: John Stultz 
Cc: Thierry Reding 
Cc: Sumit Semwal 
Signed-off-by: Vinay Simha BN 
Acked-by: Rob Herring 

---
v2:
 * incorporated rob herring and thierry reviews
   gpio to gpios, gpio to regulator using fixed regulators
   and pwm backlight is removed, since it is controlled by
   dcs commands

v3:
 * incorporated thierry reviews
   - Added gpio polarity details for reset-gpios
   - proper naming conventions and sequence wrt panel datasheet
 (vddp-supply, iovcc-supply,
  enable-gpios, reset-gpios, dcdc-en-gpios)
v4:
 * pinctrl-names, pinctrl-0 removed, not required for
   reset-gpios
---
 .../bindings/display/panel/jdi,lt070me05000.txt| 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
new file mode 100644
index 000..4989c91d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
@@ -0,0 +1,31 @@
+JDI model LT070ME05000 1200x1920 7" DSI Panel
+
+Required properties:
+- compatible: should be "jdi,lt070me05000"
+- vddp-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply (3-5V)
+- iovcc-supply: phandle of the regulator that provides the supply voltage
+  IOVCC , power supply for LCM (1.8V)
+- enable-gpios: phandle of gpio for enable line
+  LED_EN, LED backlight enable, High active
+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+  XRES, Reset, Low active
+- dcdc-en-gpios: phandle of the gpio for power ic line
+  Power IC supply enable, High active
+
+Example:
+
+   dsi0: qcom,mdss_dsi@470 {
+   panel@0 {
+   compatible = "jdi,lt070me05000";
+   reg = <0>;
+
+   vddp-supply = <&pm8921_l17>;
+   iovcc-supply = <&pm8921_lvs7>;
+
+   enable-gpios = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
+   reset-gpios = <&tlmm_pinmux 54 GPIO_ACTIVE_LOW>;
+   dcdc-en-gpios = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
2.1.2

[PATCH] syscon: dt-bindings: Add documentation for Aspeed system control units

[Andrew Jeffery]

Signed-off-by: Andrew Jeffery 
Acked-by: Rob Herring 
Acked-by: Joel Stanley 
Acked-by: Linus Walleij 
---
 Documentation/devicetree/bindings/mfd/aspeed-scu.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-scu.txt

diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt 
b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
new file mode 100644
index ..4fc5b83726d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt
@@ -0,0 +1,18 @@
+The Aspeed System Control Unit manages the global behaviour of the SoC,
+configuring elements such as clocks, pinmux, and reset.
+
+Required properties:
+- compatible:  One of:
+   "aspeed,ast2400-scu", "syscon", "simple-mfd"
+   "aspeed,g4-scu", "syscon", "simple-mfd"
+   "aspeed,ast2500-scu", "syscon", "simple-mfd"
+   "aspeed,g5-scu", "syscon", "simple-mfd"
+
+- reg: contains the offset and length of the SCU memory region
+
+Example:
+
+syscon: syscon@1e6e2000 {
+   compatible = "aspeed,ast2400-scu", "syscon", "simple-mfd";
+   reg = <0x1e6e2000 0x1a8>;
+};
-- 
2.7.4

Hibernation broken since commit 274ad65c9d02 ("drm/radeon: hard reset r600 and newer GPU when hibernating.")

[Sven Joachim]

Recently I got myself a new laptop with the following integrated GPU:

00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Mullins [Radeon R3 Graphics] (rev 40)

I found that hibernation is broken in Linux 4.7+ (it works in Linux 4.6)
and bisected it to commit 274ad65c9d02 ("drm/radeon: hard reset r600 and
newer GPU when hibernating.").

This has already been reported three months ago, but for a much older
GPU, see the thread starting at
https://lists.freedesktop.org/archives/dri-devel/2016-June/110050.html.
The symptoms are exactly the same as described by Boris Petkov in that
thread: after "systemctl hibernate" the screen goes blank, but the
machine remains powered on and needs to be power-cycled.

Any suggestions would be welcome.

Cheers,
   Sven

Re: [PATCH] ubifs: compress lines for immediate return

[Richard Weinberger]

Heiko,

On 05.09.2016 06:59, Heiko Schocher wrote:
> fix the following code:
> 
> -ret = expression;
> -if (ret)
> -return ret;
> -return 0;
> +return expression;

"Fix"? ;-)
What was broken?

I agree that we can write the expression in a different way, but is it really 
worth it?
Is this part of a tree-wide cleanup?

Thanks,
//richard

[GIT PULL] ARM: SoC fixes

[Olof Johansson]

Hi Linus,

The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:

  Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-fixes

for you to fetch changes up to 95390e3290e8bf69091116e0d91b9754c0e93a24:

  Merge tag 'sunxi-fixes-for-4.8' of 
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into fixes 
(2016-09-07 21:25:08 -0700)


ARM: SoC fixes

This is a slightly larger batch of fixes that we've been sitting on a few
-rcs. Most of them are simple oneliners, but there are two sets that are
slightly larger and worth pointing out:

 - A set of patches to OMAP to deal with hwmod for RTC on am33xx (beaglebone
   SoC, among others). It's the only clock that ever has a valid offset of 0,
   so a new flag needed introduction once this problem was discovered.

 - A collection of CCI fixes for performance counters discovered once people
   started using it on X-Gene CPUs.


Adam Ford (2):
  ARM: dts: logicpd-torpedo-som: Provide NAND ready pin
  ARM: dts: logicpd-somlv: Fix NAND device nodes

Andreas F??rber (1):
  ARM: dts: imx6sx-sabreauto: Fix misspelled property

Anson Huang (1):
  ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx

Arnd Bergmann (2):
  Merge tag 'mvebu-fixes-4.8-2' of git://git.infradead.org/linux-mvebu into 
fixes
  Merge tag 'ccn/fixes-for-4.8-v2' of 
git://git.linaro.org/people/pawel.moll/linux into fixes

Dave Gerlach (4):
  ARM: OMAP4+: hwmod: Add hwmod flag for HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET
  ARM: OMAP2+: AM33XX: Add HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET flag to rtc hwmod
  ARM: OMAP4+: Have _omap4_wait_target_* check for valid clkctrl_offs
  ARM: OMAP4+: CM: Remove redundant checks for clkctrl_offs of zero

Fabio Estevam (1):
  ARM: dts: imx6qdl: Fix SPDIF regression

Gregory CLEMENT (1):
  ARM: dts: kirkwood: Fix PCIe label on OpenRD

Hugo Grostabussiat (1):
  ARM: sun5i: Fix typo in trip point temperature

Johan Hovold (3):
  memory: omap-gpmc: allow probe of child nodes to fail
  ARM: dts: overo: fix gpmc nand cs0 range
  ARM: dts: overo: fix gpmc nand on boards with ethernet

Jon Hunter (1):
  ARM: tegra: Correct polarity for Tegra114 PMIC interrupt

Krzysztof Kozlowski (2):
  ARM: dts: exynos: Properly select eMMC HighSpeed mode on Odroid XU
  MAINTAINERS: Switch to kernel.org account for Krzysztof Kozlowski

Mark Rutland (3):
  bus: arm-ccn: fix PMU interrupt flags
  bus: arm-ccn: fix hrtimer registration
  bus: arm-ccn: make event groups reliable

Masahiro Yamada (1):
  MAINTAINERS: add tree entry for ARM/UniPhier architecture

Olof Johansson (9):
  Merge tag 'mvebu-fixes-4.8-1' of git://git.infradead.org/linux-mvebu into 
fixes
  Merge tag 'gpmc-omap-v4.8-rc1' of https://github.com/rogerq/linux into 
fixes
  Merge tag 'vexpress-fixes-4.8-rc' of 
git://git.kernel.org/.../sudeep.holla/linux into fixes
  Merge tag 'omap-for-v4.8/fixes-rc2' of 
git://git.kernel.org/.../tmlind/linux-omap into fixes
  Merge tag 'imx-fixes-4.8' of git://git.kernel.org/.../shawnguo/linux into 
fixes
  Merge tag 'samsung-fixes-4.8' of git://git.kernel.org/.../krzk/linux into 
fixes
  Revert "ARM: tegra: fix erroneous address in dts"
  Merge tag 'imx-fixes-4.8-2' of git://git.kernel.org/.../shawnguo/linux 
into fixes
  Merge tag 'sunxi-fixes-for-4.8' of 
https://git.kernel.org/.../mripard/linux into fixes

Pawel Moll (5):
  bus: arm-ccn: Fix PMU handling of MN
  bus: arm-ccn: Do not attempt to configure XPs for cycle counter
  bus: arm-ccn: Fix XP watchpoint settings bitmask
  bus: arm-ccn: Correct required arguments for XP PMU events
  bus: arm-ccn: Add missing event attribute exclusions for host/guest

Peter Chen (4):
  bus: vexpress-config: add missing of_node_put after calling 
of_parse_phandle
  firmware: arm_scpi: add missing of_node_put after calling of_parse_phandle
  ARM: imx6: add missing BM_CLPCR_BYP_MMDC_CH0_LPM_HS setting for imx6ul
  ARM: imx6ul: populates platform device at .init_machine

Russell King (1):
  ARM: dts: armada-388-clearfog: number LAN ports properly

Sebastian Reichel (1):
  ARM: OMAP3: hwmod data: Add sysc information for DSI

Simon Baatz (1):
  ARM: kirkwood: ib62x0: fix size of u-boot environment partition

Suzuki K Poulose (1):
  arm-cci: pmu: Fix typo in event name

Teresa Remmet (1):
  ARM: dts: am335x: Update elm phandle binding

Tony Lindgren (2):
  Merge branch 'omap-for-v4.8/soc' into omap-for-v4.8/fixes
  Merge branch 'dts-fixes' into omap-for-v4.8/fixes

Vladimir Zapolskiy (1):
  ARM: dts: imx7d-sdb: fix ti,x-plate-ohms property name

 .mailmap   |   1 

Re: [RFC2 PATCH 00/23] ARM64: support ILP32

[Zhangjian (Bamvor)]

Hi, Guys

There was a discussion about bump vdso version of kernel. We need
update the vdso version in glibc correspondingly otherwise the
application could not make use of the vdso.

Is it make sense to you?

Regards

Bamvor

commit 3ffc1d798fc25ccb02e7cc325fe5fb3890c085e3
Author: Bamvor Jian Zhang 
Date:   Thu Sep 8 12:21:16 2016 +0800

[AARCH64] ILP32: bump vdso version consistent with kernel

Signed-off-by: Jun Ji 
Signed-off-by: Bamvor Jian Zhang 

diff --git a/sysdeps/unix/sysv/linux/aarch64/init-first.c 
b/sysdeps/unix/sysv/linux/aarch64/init-first.c
index f7224a2..3e4eaad 100644
--- a/sysdeps/unix/sysv/linux/aarch64/init-first.c
+++ b/sysdeps/unix/sysv/linux/aarch64/init-first.c
@@ -27,17 +27,21 @@ int (*VDSO_SYMBOL(clock_getres)) (clockid_t, struct 
timespec *);
 static inline void
 _libc_vdso_platform_setup (void)
 {
-  PREPARE_VERSION (linux2639, "LINUX_2.6.39", 123718537);
+#ifndef __ILP32__
+  PREPARE_VERSION (linux, "LINUX_2.6.39", 123718537);
+#else
+  PREPARE_VERSION (linux, "LINUX_4.8", 61765624);
+#endif /* #ifndef __ILP32__ */

-  void *p = _dl_vdso_vsym ("__kernel_gettimeofday", &linux2639);
+  void *p = _dl_vdso_vsym ("__kernel_gettimeofday", &linux);
   PTR_MANGLE (p);
   VDSO_SYMBOL(gettimeofday) = p;

-  p = _dl_vdso_vsym ("__kernel_clock_gettime", &linux2639);
+  p = _dl_vdso_vsym ("__kernel_clock_gettime", &linux);
   PTR_MANGLE (p);
   VDSO_SYMBOL(clock_gettime) = p;

-  p = _dl_vdso_vsym ("__kernel_clock_getres", &linux2639);
+  p = _dl_vdso_vsym ("__kernel_clock_getres", &linux);
   PTR_MANGLE (p);
   VDSO_SYMBOL(clock_getres) = p;
 }


On 2016/6/29 0:39, Yury Norov wrote:

This series enables aarch64 port with ilp32 mode.

ABI details:
 - types are taken from AARCH32, next types turned to 64-bit,
   as modern requirement for new APIs tells:
ino_t  is  u64 type
off_t  is  s64 type
blkcnt_t   is  s64 type
fsblkcnt_t is  u64 type
fsfilcnt_t is  u64 type
 - 64-bit arguments are passed in syscall as register pair,
   as kernel internally clears top halves for all input regs;
 - standard syscall table is used;
 - 32-bit time_t is used. AARCH64/ILP32 is waiting for general
   fix of Y2038 problem just like other 32-bit arches;
 - stat{64}, statfs{64} structures are of the identical layout
   with LP64. Corresponding syscalls are taken from 64-bit code
 - struct utmp, utmpx layouts are the same.

v1: https://sourceware.org/ml/libc-alpha/2016-06/msg00730.html
v2:
 - rebased on master;
 - dropped unneeded/unrelated patches;
 - pread family platform implementation removed;
 - addressed v1 comments (I'm really sorry if I missed something,
   there are a lot of them, and I am really thankfull for detailed review);

Tested with LTP. Regressions are like this:
abort01FAIL   2
kill11 FAIL   2
mmap16 FAIL   6
open12 FAIL   2
rename11   FAIL   2
rmdir02FAIL   2
umount2_01 FAIL   2
umount2_02 FAIL   2
umount2_03 FAIL   2
utime06FAIL   2

It's better than v1, and there are ~5 additional regressions comparing to
aarch64, all are related to filesystem.

Andrew Pinski (17):
  [AARCH64] define word size for lp64 and ilp32
  [AARCH64] Add header guards to sysdep.h headers.
  Add dynamic ILP32 AARCH64 relocations to elf.h
  [AARCH64] Add PTR_REG, PTR_LOG_SIZE, and PTR_SIZE.  Use it in
LDST_PCREL and LDST_GLOBAL.
  [AARCH64] Use PTR_REG in crti.S.
  [AARCH64] Use PTR_REG/PTR_SIZE/PTR_SIZE_LOG in dl-tlsesc.S
  [AARCH64] Use PTR_* macros in dl-trampoline.S
  [AARCH64] Use PTR_* in start.S
  [AARCH64] Use PTR_REG in getcontext.S.
  [AARCH64] Detect ILP32 in configure scripts.
  [AARCH64] Add ILP32 support to elf_machine_load_address.
  [AARCH64] Add ILP32 to makefiles
  [AARCH64] Add support to ldconfig for ILP32 and libilp32
  [AARCH64] Add ILP32 ld.so to the known interpreter names.
  [AARCH64] Add ldd-rewrite.sed so that ilp32 ld.so can be found
  [AARCH64] Make lp64 and ilp32 directories.
  [AARCH64] Fix ILP32 warning

Yury Norov (6):
  [AARCH64] ILP32: introduce syscalls that pass off_t
  [AARCH64] ILP32: support stat syscall family
  [AARCH64] delouse input arguments in system functions
  [AARCH64] Make __SIZEOF_SEM_T 16 for ILP32
  off_t: fix register pair calculation for 64-bit case
  [AARCH64] Take utmp{,x}.h from s390 port

 elf/cache.c|   3 +
 sysdeps/aarch64/Implies|   6 -
 sysdeps/aarch64/__longjmp.S|   6 +-
 sysdeps/aarch64/bits/wordsize.h|  25 +++
 sysdeps/aarch64/configure  |  15 +-
 sysdeps/aarch64/configure.ac   |  11 +-
 sysdeps/aarch64/crti.S |   3 +-
 sysdeps/aarch64/dl-irel.h  

Re: [RFC PATCH 1/2] macb: Add 1588 support in Cadence GEM.

[Harini Katakam]

Hi,

On Tue, Sep 6, 2016 at 9:18 PM, Richard Cochran
 wrote:
>

>> +#define GEM_TISUBN   0x01bc /* 1588 Timer Increment Sub-ns */
>
> This regsiter does not exist.  Looking at
>
>Zynq-7000 AP SoC Technical Reference Manual
>UG585 (v1.10) February 23, 2015
>
> starting on page 1273 we see:
>
> udp_csum_errors 0x01B0 32 ro0x UDP checksum error
> timer_strobe_s  0x01C8 32 rw0x 1588 timer sync strobe seconds
> timer_strobe_ns 0x01CC 32 mixed 0x 1588 timer sync strobe 
> nanoseconds
> timer_s 0x01D0 32 rw0x 1588 timer seconds
> timer_ns0x01D4 32 mixed 0x 1588 timer nanoseconds
> timer_adjust0x01D8 32 mixed 0x 1588 timer adjust
> timer_incr  0x01DC 32 mixed 0x 1588 timer increment
>
> There is no register at 0x1BC.
>
>> +#define GEM_TSH  0x01c0 /* 1588 Timer Seconds High */
>
> This one doesn't exist either.  What is going on here?

I cant be sure of the version of Cadence GEM used in SAMA5D2
but these registers (sub ns increments alteast) only exist in
the IP version used in Zynq Ultrascale+ MPSoC.


>> + /* get GEM internal time */
>> + sech = gem_readl(bp, TSH);
>> + secl = gem_readl(bp, TSL);
>
> Does reading TSH latch the time?  The TRM is silent about that, and
> most other designs latch on reading the LSB.

No, it does not latch the time.
When doing a read + adjust + write, this will
mean there's room for some error.

Although when writing, the write to MSB and LSB registers
was made atomic. This bug fix came only in the
most recent version of the IP, am afraid.

Regards,
Harini

[sched/wait] 02ae2b22bd: WARNING: CPU: 0 PID: 958 at kernel/sched/core.c:7610 __might_sleep+0x6e/0x90

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Oleg-Nesterov/sched-wait-fix-and-then-kill-abort_exclusive_wait/20160907-145024
commit 02ae2b22bd2a42c4e4054563b139a541ba67a43e ("sched/wait: avoid 
abort_exclusive_wait() in ___wait_event()")

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -m 320M

caused below changes:


+---+++
|   | 9272868493 | 02ae2b22bd |
+---+++
| boot_successes| 16 | 1  |
| boot_failures | 0  | 15 |
| WARNING:at_kernel/sched/core.c:#__might_sleep | 0  | 15 |
+---+++



[   30.775242] kill 958 cat /proc/kmsg 
[   30.775242] wait for background monitors: 959 962 oom-killer nfs-hang
[   32.078512] [ cut here ]
[   32.080657] WARNING: CPU: 0 PID: 958 at kernel/sched/core.c:7610 
__might_sleep+0x6e/0x90
[   32.084787] do not call blocking ops when !TASK_RUNNING; state=1 set at 
[] prepare_to_wait_event+0xad/0x120
[   32.091287] Modules linked in:
[   32.094001] CPU: 0 PID: 958 Comm: cat Not tainted 4.8.0-rc5-00035-g02ae2b2 #1
[   32.094017] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[   32.094017]   880009497be8 813c9947 
810e993e
[   32.094017]  880009497c48 880009497c48  
880009497c38
[   32.094017]  810c18e7 880009497c08 1dba8110ea1d 
880009497c28
[   32.094017] Call Trace:
[   32.094017]  [] dump_stack+0xc4/0x12d
[   32.094017]  [] ? __might_sleep+0x6e/0x90
[   32.094017]  [] __warn+0xe7/0x110
[   32.094017]  [] warn_slowpath_fmt+0x44/0x50
[   32.094017]  [] ? prepare_to_wait_event+0xad/0x120
[   32.094017]  [] ? prepare_to_wait_event+0xad/0x120
[   32.094017]  [] __might_sleep+0x6e/0x90
[   32.094017]  [] get_signal+0x63/0x3c0
[   32.094017]  [] ? tty_write+0x2c6/0x2f0
[   32.094017]  [] ? kmsg_read+0x55/0x70
[   32.094017]  [] do_signal+0x20/0x100
[   32.094017]  [] ? security_file_permission+0x99/0xb0
[   32.094017]  [] ? exit_to_usermode_loop+0x44/0xd0
[   32.094017]  [] ? trace_hardirqs_on_caller+0x193/0x1f0
[   32.094017]  [] exit_to_usermode_loop+0x72/0xd0
[   32.094017]  [] do_int80_syscall_32+0x1fa/0x230
[   32.094017]  [] ? entry_INT80_compat+0x3d/0x50
[   32.094017]  [] entry_INT80_compat+0x38/0x50
[   32.225846] ---[ end trace 8f84425f8176b010 ]---
[   32.225846] ---[ end trace 8f84425f8176b010 ]---






Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.8.0-rc5 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_KASAN_SHADOW_OFFSET=0xdc00
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_KERNEL_LZ4=y
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=

Re: [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi

[Chen-Yu Tsai]

On Thu, Sep 8, 2016 at 3:37 AM, Linus Walleij  wrote:
> On Wed, Sep 7, 2016 at 4:53 PM, Maxime Ripard
>  wrote:
>
>> From: Mylène Josserand 
>>
>> The GR8 is an SoC made by Nextthing loosely based on the sun5i family.
>>
>> Since it's not clear yet what we can factor out and merge with the A10s and
>> A13 support, let's keep it out of the sun5i.dtsi include tree. We will
>> figure out what can be shared when things settle down.
>>
>> Signed-off-by: Mylène Josserand 
>> Signed-off-by: Maxime Ripard 
>
> Acked-by: Linus Walleij 
>
> I was just thinking:
>
>> +   i2c0_pins_a: i2c0@0 {
>> +   allwinner,pins = "PB0", "PB1";
>> +   allwinner,function = "i2c0";
>> +   allwinner,drive = ;
>> +   allwinner,pull = ;
>> +   };
>
> It would be *NICE* if the sunxi driver would start to support the new standard
> bindings for this stuff, see
> Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>
> So you could just use pins, function and the drive-strength and
> bias-disable in this case.
>
> Since I know the AllWinner support is a community project I have much higher
> tolerance with this legacy binding sticking around for the new generation of
> SoCs but still, if you find time.
>
> I mean it like supporting these in *addition* to the custom ones, so there can
> be a smooth phase-over.
>
> Check for example Laurent's commit for SH-PFC:
> commit 16ccaf5bb5a52372bfebd3dfbb79dd810ad49c09
> "pinctrl: sh-pfc: Accept standard function, pins and groups properties"
> It's awesome, and since, they have improved the looks of Renesas
> DTS files a lot.
>
> It could look a bit like this nice thing from
> lpc4337-ciaa.dts:
>
> &pinctrl {
> enet_rmii_pins: enet-rmii-pins {
> enet_rmii_rxd_cfg {
> pins = "p1_15", "p0_0";
> function = "enet";
> slew-rate = <1>;
> bias-disable;
> input-enable;
> input-schmitt-disable;
> };
>
> enet_rmii_txd_cfg {
> pins = "p1_18", "p1_20";
> function = "enet";
> slew-rate = <1>;
> bias-disable;
> input-enable;
> input-schmitt-disable;
> };
> (etc)

This looks nice. I've slightly looked at the generic pinconf stuff.
I think we should be able to support them, though the sunxi pinctrl
driver currently doesn't work well with it though. For example,
it doesn't declare ".is_generic = true", it doesn't filter
unsupported pinconf parameters, and it doesn't reply to queries
correctly. I will fix these bits.

Also, I think we are needlessly using pin groups, 1 pin per group.
Can pinconf/pinctrl work without them? Would there be any harm
converting the sunxi driver to work directly with pins? This would
make it match generic pinconf parsing, and make it easier to get
both working together.


Regards
ChenYu

Re: [GIT PULL] seccomp fixes for v4.8-rc6

[James Morris]

Actually I asked if you could send them to me...


On 08/09/16 02:29, Kees Cook wrote:

Hi,

Please pull these seccomp fixes for v4.8-rc6. These got accidentally
put in James's -next tree, but they're needed for v4.8. He asked me to
forward them directly to you.

Thanks!

-Kees

The following changes since commit d060e0f603a4156087813d221d818bb39ec91429:

  Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma (2016-09-06 
12:33:12 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/seccomp-v4.8-rc6

for you to fetch changes up to 4fadd04d504a82f7f1fdeaddc144a9c396d1285e:

  seccomp: Remove 2-phase API documentation (2016-09-07 09:25:05 -0700)


- Fix UM seccomp vs ptrace, after reordering landed.


Mickaël Salaün (3):
  um/ptrace: Fix the syscall_trace_leave call
  um/ptrace: Fix the syscall number update after a ptrace
  seccomp: Remove 2-phase API documentation

 arch/Kconfig  | 11 ---
 arch/um/kernel/skas/syscall.c | 10 +++---
 arch/x86/um/ptrace_32.c   |  3 +++
 arch/x86/um/ptrace_64.c   |  4 
 4 files changed, 10 insertions(+), 18 deletions(-)

DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Dan Williams]

[ adding linux-fsdevel and linux-nvdimm ]

On Wed, Sep 7, 2016 at 8:36 PM, Xiao Guangrong
 wrote:
[..]
> However, it is not easy to handle the case that the new VMA overlays with
> the old VMA
> already got by userspace. I think we have some choices:
> 1: One way is completely skipping the new VMA region as current kernel code
> does but i
>do not think this is good as the later VMAs will be dropped.
>
> 2: show the un-overlayed portion of new VMA. In your case, we just show the
> region
>(0x2000 -> 0x3000), however, it can not work well if the VMA is a new
> created
>region with different attributions.
>
> 3: completely show the new VMA as this patch does.
>
> Which one do you prefer?
>

I don't have a preference, but perhaps this breakage and uncertainty
is a good opportunity to propose a more reliable interface for NVML to
get the information it needs?

My understanding is that it is looking for the VM_MIXEDMAP flag which
is already ambiguous for determining if DAX is enabled even if this
dynamic listing issue is fixed.  XFS has arranged for DAX to be a
per-inode capability and has an XFS-specific inode flag.  We can make
that a common inode flag, but it seems we should have a way to
interrogate the mapping itself in the case where the inode is unknown
or unavailable.  I'm thinking extensions to mincore to have flags for
DAX and possibly whether the page is part of a pte, pmd, or pud
mapping.  Just floating that idea before starting to look into the
implementation, comments or other ideas welcome...

Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts

[Olof Johansson]

On Wed, Sep 07, 2016 at 03:50:57PM +0200, Ralf Ramsauer wrote:
> Hi all,
> 
> may I *poke* you again?
> 
> We're close to the release of 4.8, and this patch (b5c86b749 upstream)
> should still be reverted on mainline

Ok, done in fixes now.


-Olof

Re: bcache vs bcachefs

[Kent Overstreet]

On Wed, Sep 07, 2016 at 11:01:40PM -0400, Theodore Ts'o wrote:
> On Wed, Sep 07, 2016 at 07:55:52AM -0800, Kent Overstreet wrote:
> > That said, I'm not advocating people rush out to throw bcachefs on their 
> > servers
> > or use it without backups yet, it's still young and needs more widespread
> > testing.
> 
> Hi Kent!
> 
> Have you started using xfstests to stress test bcachefs yet?

Yep, since I had enough of a filesystem to test.

> You may be interested in reading through this presentation, especially
> the last slide.  :-)
> 
>  https://thunk.org/gce-xfstests

Looks similar conceptually to my own xfstests wrapper...

lol @ the last slide :)

[PATCH] Bluetooth: fix kzalloc-simple.cocci warnings

[kbuild test robot]

net/bluetooth/mgmt.c:905:6-13: WARNING: kzalloc should be used for rp, instead 
of kmalloc/memset


 Use kzalloc rather than kmalloc followed by memset with 0

 This considers some simple cases that are common and easy to validate
 Note in particular that there are no ...s in the rule, so all of the
 matched code has to be contiguous

Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci

CC: Michał Narajowski 
Signed-off-by: Fengguang Wu 
---

 mgmt.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -902,12 +902,10 @@ static int read_ext_controller_info(stru
eir_len = eir_append_data(buff, eir_len, EIR_NAME_SHORT,
  hdev->short_name, name_len);
 
-   rp = kmalloc(sizeof(*rp) + eir_len, GFP_KERNEL);
+   rp = kzalloc(sizeof(*rp) + eir_len, GFP_KERNEL);
if (!rp)
return -ENOMEM;
 
-   memset(rp, 0, sizeof(*rp) + eir_len);
-
rp->eir_len = cpu_to_le16(eir_len);
memcpy(rp->eir, buff, eir_len);
 

Re: [Linaro-acpi] [PATCH V8 1/8] ACPI: I/O Remapping Table (IORT) initial support

[Tomasz Nowicki]

On 02.09.2016 13:52, Fu Wei wrote:
> Hi Tomasz,
>
> On 11 August 2016 at 18:06, Tomasz Nowicki  wrote:
>> IORT shows representation of IO topology for ARM based systems.
>> It describes how various components are connected together on
>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>>
>> Initial support allows to detect IORT table presence and save its
>> root pointer obtained through acpi_get_table(). The pointer validity
>> depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
>> is not set while using IORT nodes we would dereference unmapped pointers.
>>
>> For the aforementioned reason call iort_table_detect() from acpi_init()
>> which guarantees acpi_gbl_permanent_mmap to be set at that point.
>>
>> Add generic helpers which are helpful for scanning and retrieving
>> information from IORT table content. List of the most important helpers:
>> - iort_find_dev_node() finds IORT node for a given device
>> - iort_node_map_rid() maps device RID and returns IORT node which provides
>>   final translation
>>
>> IORT support is placed under drivers/acpi/arm64/ new directory due to its
>> ARM64 specific nature. The code there is considered only for ARM64.
>> The long term plan is to keep all ARM64 specific tables support
>> in this place e.g. GTDT table.
>>
>> Signed-off-by: Tomasz Nowicki 
>> Reviewed-by: Hanjun Guo 
>> ---
>>  drivers/acpi/Kconfig|   5 +
>>  drivers/acpi/Makefile   |   2 +
>>  drivers/acpi/arm64/Kconfig  |   6 ++
>>  drivers/acpi/arm64/Makefile |   1 +
>>  drivers/acpi/arm64/iort.c   | 218 
>> 
>>  drivers/acpi/bus.c  |   2 +
>>  include/linux/iort.h|  30 ++
>>  7 files changed, 264 insertions(+)
>>  create mode 100644 drivers/acpi/arm64/Kconfig
>>  create mode 100644 drivers/acpi/arm64/Makefile
>>  create mode 100644 drivers/acpi/arm64/iort.c
>>  create mode 100644 include/linux/iort.h
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 445ce28..6cef2d1 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -521,4 +521,9 @@ config ACPI_CONFIGFS
>>   userspace. The configurable ACPI groups will be visible under
>>   /config/acpi, assuming configfs is mounted under /config.
>>
>> +if ARM64
>> +source "drivers/acpi/arm64/Kconfig"
>> +
>> +endif
>> +
>>  endif  # ACPI
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 5ae9d85..e5ada78 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -105,3 +105,5 @@ obj-$(CONFIG_ACPI_CONFIGFS) += acpi_configfs.o
>>
>>  video-objs += acpi_video.o video_detect.o
>>  obj-y  += dptf/
>> +
>> +obj-$(CONFIG_ARM64)+= arm64/
>> diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
>> new file mode 100644
>> index 000..fc818dc
>> --- /dev/null
>> +++ b/drivers/acpi/arm64/Kconfig
>> @@ -0,0 +1,6 @@
>> +#
>> +# ACPI Configuration for ARM64
>> +#
>> +
>> +config IORT_TABLE
>
> Sorry for nit-picking, but is that better to use ACPI_IORT
> or maybe ARM64__IORT ??

ACPI_IORT sounds good.

Tomasz

Re: [PATCH v3 5/8] pinctrl: Add core support for Aspeed SoCs

[Andrew Jeffery]

On Wed, 2016-09-07 at 16:50 +0200, Linus Walleij wrote:
> On Tue, Aug 30, 2016 at 9:54 AM, Andrew Jeffery  wrote:
> 
> > 
> > The Aspeed SoCs typically provide more than 200 pins for GPIO and other
> > functions. The signal enabled on a pin is determined on a priority
> > basis, where a given pin can provide a number of different signal types.
> > 
> > In addition to the priority levels, the Aspeed pin controllers describe
> > the signal active on a pin by compound logical expressions involving
> > multiple operators, registers and bits. Some difficulty arises as a
> > pin's function bit masks for each priority level are frequently not the
> > same (i.e. we cannot just flip a bit to change from a high to low
> > priority signal), or even in the same register(s). Some configuration
> > bits affect multiple pins, while in other cases the signals for a bus
> > must each be enabled individually.
> > 
> > Together, these features give rise to some complexity in the
> > implementation. A more complete description of the complexities is
> > provided in the associated header file.
> > 
> > The patch doesn't implement pinctrl/pinmux/pinconf for any particular
> > Aspeed SoC, rather it adds the framework for defining pinmux
> > configurations.
> > 
> > Signed-off-by: Andrew Jeffery 
> > Reviewed-by: Joel Stanley 
> Patch applied! It's not getting better than this through iteration, it is 
> better
> to get the system up and develop inside the mainline tree from now on.
> 
> > 
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1027,6 +1027,7 @@ S:Maintained
> >  F: arch/arm/mach-aspeed/
> >  F: arch/arm/boot/dts/aspeed-*
> >  F: drivers/*/*aspeed*
> > +F: drivers/pinctrl/aspeed/
> >  F: Documentation/devicetree/bindings/*/*aspeed*
> I dropped this hunk of the patch, because:
> 
> (A) I didn't merge the glob patch and

Okay

> (B) the glob covers this driver too, it is a tautology/truism

So experimenting with this my results don't agree - without the hunk
get_maintainer.pl falls back to git and s-o-bs to pick up the Aspeed
maintainer:

With the hunk:

$ ./scripts/get_maintainer.pl drivers/pinctrl/aspeed/pinctrl-aspeed.c
Joel Stanley  (maintainer:ARM/ASPEED MACHINE 
SUPPORT)
Linus Walleij  (maintainer:PIN CONTROL 
SUBSYSTEM)
linux-g...@vger.kernel.org (open list:PIN CONTROL SUBSYSTEM)

Without the hunk:

$ ./scripts/get_maintainer.pl drivers/pinctrl/aspeed/pinctrl-aspeed.c
Linus Walleij  (maintainer:PIN CONTROL 
SUBSYSTEM)
Joel Stanley  (commit_signer:1/1=100%)
Andrew Jeffery  
(commit_signer:1/1=100%,authored:1/1=100%,added_lines:498/498=100%)
linux-g...@vger.kernel.org (open list:PIN CONTROL SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)

So removing git as a fallback Joel isn't listed as a relevant
maintainer despite the glob:

$ ./scripts/get_maintainer.pl --no-git-fallback 
drivers/pinctrl/aspeed/pinctrl-aspeed.c
Linus Walleij  (maintainer:PIN CONTROL 
SUBSYSTEM)
linux-g...@vger.kernel.org (open list:PIN CONTROL SUBSYSTEM)
linux-kernel@vger.kernel.org (open list)

I expect it's the case that the globbing doesn't match directories like
the hunk in question does with its trailing '/'. However, given we will
likely do something different in light of Arnd's suggestion it probably
doesn't matter.

Cheers,

Andrew

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v4 3/3] iio: adc: add support for Allwinner SoCs ADC

[Quentin Schulz]

On 04/09/2016 16:35, Jonathan Cameron wrote:
> On 01/09/16 15:05, Quentin Schulz wrote:
>> The Allwinner SoCs all have an ADC that can also act as a touchscreen
>> controller and a thermal sensor. This patch adds the ADC driver which is
>> based on the MFD for the same SoCs ADC.
>>
>> This also registers the thermal adc channel in the iio map array so
>> iio_hwmon could use it without modifying the Device Tree. This registers
>> the driver in the thermal framework.
>>
>> This driver probes on three different platform_device_id to take into
>> account slight differences (registers bit and temperature computation)
>> between Allwinner SoCs ADCs.
>>
>> Signed-off-by: Quentin Schulz 
> One utterly trivial point about unrolling code ordering inline.
> 
> Other than the bit about patch 1 I'm basically happy with this..

ACK. Will revert this patch in v5. Thanks.

> However I would like some input (i.e. an Ack) from thermal given this
> sets up a thermal zone.
> 
> Zhang or Eduardo, could you take a quick look at this and confirm you
> are happy with it?
> 
> Thanks,
> 
> Jonathan
[...]
>> +
>> +err_map:
>> +iio_map_array_unregister(indio_dev);
>> +
>> +err_fifo_irq:
>> +/* Disable FIFO_DATA_PENDING interrupt on hardware side. */
>> +regmap_update_bits(info->regmap, SUN4I_GPADC_INT_FIFOC,
>> +   SUN4I_GPADC_INT_FIFOC_TP_DATA_IRQ_EN,
>> +   0);
>> +
>> +err_temp_irq:
>> +/* Disable TEMP_DATA_PENDING interrupt on hardware side. */
>> +regmap_update_bits(info->regmap, SUN4I_GPADC_INT_FIFOC,
>> +   SUN4I_GPADC_INT_FIFOC_TEMP_IRQ_EN,
>> +   0);
>> +
>> +err:
>> +pm_runtime_put(&pdev->dev);
>> +pm_runtime_disable(&pdev->dev);
>> +
>> +return ret;
>> +}
>> +
>> +static int sun4i_gpadc_remove(struct platform_device *pdev)
>> +{
>> +struct sun4i_gpadc_dev *info;
>> +struct iio_dev *indio_dev = platform_get_drvdata(pdev);
>> +
>> +info = iio_priv(indio_dev);
>> +iio_device_unregister(indio_dev);
>> +iio_map_array_unregister(indio_dev);
>> +pm_runtime_put(&pdev->dev);
>> +pm_runtime_disable(&pdev->dev);
> Its really minor but in the interests of 'obviously correct' making
> review easy I'd rather everything in the remove was in the reverse order
> of probe (and hence the same as the error path in probe for most of it).
> 
> That would put the pm_runtime stuff last I think..
> 
> If you weren't rerolling anyway over patch 1 I'd probably have just let
> this go, but might as well make this trivial change as well.
> 

I'm going with the following order:
pm_runtime_put
pm_runtime_disable
regmap_update_bits
iio_map_array_unregister
iio_device_unregister

Is that okay? (I don't really know which one of iio_map_array_unregister
or iio_device_unregister to put first, if it matters in any way).

Thanks!
Quentin
> 
>> +/*
>> + * Disable TEMP_DATA_PENDING and FIFO_DATA_PENDING interrupts on
>> + * hardware side.
>> + */
>> +regmap_update_bits(info->regmap, SUN4I_GPADC_INT_FIFOC,
>> +   SUN4I_GPADC_INT_FIFOC_TEMP_IRQ_EN |
>> +SUN4I_GPADC_INT_FIFOC_TP_DATA_IRQ_EN,
>> +   0);
>> +
>> +return 0;
>> +}
>> +
>> +static const struct platform_device_id sun4i_gpadc_id[] = {
>> +{ "sun4i-a10-gpadc-iio", (kernel_ulong_t)&sun4i_gpadc_soc_specific },
>> +{ "sun5i-a13-gpadc-iio", (kernel_ulong_t)&sun5i_gpadc_soc_specific },
>> +{ "sun6i-a31-gpadc-iio", (kernel_ulong_t)&sun6i_gpadc_soc_specific },
>> +{ /* sentinel */ },
>> +};
>> +
>> +static struct platform_driver sun4i_gpadc_driver = {
>> +.driver = {
>> +.name = "sun4i-gpadc-iio",
>> +.pm = &sun4i_gpadc_pm_ops,
>> +},
>> +.id_table = sun4i_gpadc_id,
>> +.probe = sun4i_gpadc_probe,
>> +.remove = sun4i_gpadc_remove,
>> +};
>> +
>> +module_platform_driver(sun4i_gpadc_driver);
>> +
>> +MODULE_DESCRIPTION("ADC driver for sunxi platforms");
>> +MODULE_AUTHOR("Quentin Schulz ");
>> +MODULE_LICENSE("GPL v2");
>>
> 

[PATCH v2 2/2] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[Yakir Yang]

Make sure the request PSR state could effect in analogix_dp_send_psr_spd()
function, or printing the error Sink PSR state if we failed to effect
the request PSR setting.

Signed-off-by: Yakir Yang 
---
Changes in v2:
- A bunch of good fixes from Sean

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 25 --
 3 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5fe3982..c0ce16a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -116,8 +116,7 @@ int analogix_dp_enable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;
 
-   analogix_dp_send_psr_spd(dp, &psr_vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, &psr_vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
 
@@ -139,8 +138,7 @@ int analogix_dp_disable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = 0;
 
-   analogix_dp_send_psr_spd(dp, &psr_vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, &psr_vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index a15f076..6c07a50 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -247,8 +247,8 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
 #endif /* _ANALOGIX_DP_CORE_H */
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a4d17b8..09d703b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1004,10 +1004,12 @@ void analogix_dp_enable_psr_crc(struct 
analogix_dp_device *dp)
writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
 }
 
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc)
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
 {
+   unsigned long timeout;
unsigned int val;
+   u8 sink;
 
/* don't send info frame */
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1048,6 +1050,25 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+   timeout = jiffies + msecs_to_jiffies(DP_TIMEOUT_LOOP_COUNT);
+   while (time_before(jiffies, timeout)) {
+   val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink);
+   if (val != 1) {
+   dev_err(dp->dev, "PSR_STATUS read failed ret=%d", val);
+   return val;
+   }
+
+   if (vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB ||
+   !vsc->DB1 && sink == DP_PSR_SINK_INACTIVE)
+   break;
+
+   usleep_range(1000, 1500);
+   }
+
+   dev_warn(dp->dev, "Failed to effect PSR: %x", sink);
+
+   return -ETIMEDOUT;
 }
 
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
-- 
1.9.1

[PATCH v2 1/2] drm/bridge: analogix_dp: Remove duplicated code v2

[Yakir Yang]

From: Tomeu Vizoso 

Remove code for reading the EDID and DPCD fields and use the helpers
instead.

Besides the obvious code reduction, other helpers are being added to the
core that could be used in this driver and will be good to be able to
use them instead of duplicating them.

Signed-off-by: Tomeu Vizoso 
Cc: Javier Martinez Canillas 
Cc: Mika Kahola 
Cc: Yakir Yang 
Cc: Daniel Vetter 

Reviewed-by: Sean Paul 
Reviewed-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
Tested-by: Sean Paul 
---
Changes in v2:
- A bunch of good fixes from Sean and Yakir
- Moved the transfer function to analogix_dp_reg.c
- Removed reference to the EDID from the dp struct
- Rebase on Sean's next tree
git://people.freedesktop.org/~seanpaul/dogwood

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 263 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  41 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 451 ++---
 3 files changed, 204 insertions(+), 551 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index efac8ab..5fe3982 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -31,6 +31,7 @@
 #include 
 
 #include "analogix_dp_core.h"
+#include "analogix_dp_reg.h"
 
 #define to_dp(nm)  container_of(nm, struct analogix_dp_device, nm)
 
@@ -174,150 +175,21 @@ static void analogix_dp_enable_sink_psr(struct 
analogix_dp_device *dp)
analogix_dp_enable_psr_crc(dp);
 }
 
-static unsigned char analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
-{
-   int i;
-   unsigned char sum = 0;
-
-   for (i = 0; i < EDID_BLOCK_LENGTH; i++)
-   sum = sum + edid_data[i];
-
-   return sum;
-}
-
-static int analogix_dp_read_edid(struct analogix_dp_device *dp)
-{
-   unsigned char *edid = dp->edid;
-   unsigned int extend_block = 0;
-   unsigned char sum;
-   unsigned char test_vector;
-   int retval;
-
-   /*
-* EDID device address is 0x50.
-* However, if necessary, you must have set upper address
-* into E-EDID in I2C device, 0x30.
-*/
-
-   /* Read Extension Flag, Number of 128-byte EDID extension blocks */
-   retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   &extend_block);
-   if (retval)
-   return retval;
-
-   if (extend_block > 0) {
-   dev_dbg(dp->dev, "EDID data includes a single extension!\n");
-
-   /* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   &edid[EDID_HEADER_PATTERN]);
-   if (retval != 0) {
-   dev_err(dp->dev, "EDID Read failed!\n");
-   return -EIO;
-   }
-   sum = analogix_dp_calc_edid_check_sum(edid);
-   if (sum != 0) {
-   dev_err(dp->dev, "EDID bad checksum!\n");
-   return -EIO;
-   }
-
-   /* Read additional EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_BLOCK_LENGTH,
-   EDID_BLOCK_LENGTH,
-   &edid[EDID_BLOCK_LENGTH]);
-   if (retval != 0) {
-   dev_err(dp->dev, "EDID Read failed!\n");
-   return -EIO;
-   }
-   sum = analogix_dp_calc_edid_check_sum(&edid[EDID_BLOCK_LENGTH]);
-   if (sum != 0) {
-   dev_err(dp->dev, "EDID bad checksum!\n");
-   return -EIO;
-   }
-
-   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   &test_vector);
-   if (test_vector & DP_TEST_LINK_EDID_READ) {
-   analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_EDID_CHECKSUM,
-   edid[EDID_BLOCK_LENGTH + EDID_CHECKSUM]);
-   analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_RESPONSE,
-   DP_TEST_EDID_CHECKSUM_WRITE);
-   }
-   } else {
-   dev_info(dp->dev, "EDID data does not include any 
extensions.\n");
-
-   /* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,

Re: [PATCH 4/6] clk: sunxi-ng: Add A33 CCU support

[Chen-Yu Tsai]

Hi,

On Thu, Sep 1, 2016 at 10:16 PM, Maxime Ripard
 wrote:
> This commit introduces the clocks found in the Allwinner A33 CCU.
>
> Since this SoC is very similar to the A23, and we share a significant share
> of the DTSI, the clock IDs that are going to be used will also be shared
> with the A23, hence the name of the various header files.
>
> Signed-off-by: Maxime Ripard 
> ---
>  .../devicetree/bindings/clock/sunxi-ccu.txt|   1 +
>  drivers/clk/sunxi-ng/Kconfig   |  12 +
>  drivers/clk/sunxi-ng/Makefile  |   1 +
>  drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h   |  63 ++
>  drivers/clk/sunxi-ng/ccu-sun8i-a33.c   | 772 
> +
>  include/dt-bindings/clock/sun8i-a23-a33-ccu.h  | 127 
>  include/dt-bindings/reset/sun8i-a23-a33-ccu.h  |  87 +++
>  7 files changed, 1063 insertions(+)
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h
>  create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a33.c
>  create mode 100644 include/dt-bindings/clock/sun8i-a23-a33-ccu.h
>  create mode 100644 include/dt-bindings/reset/sun8i-a23-a33-ccu.h
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt 
> b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> index eac458720b28..8fd765ea3660 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
> @@ -4,6 +4,7 @@ Allwinner Clock Control Unit Binding
>  Required properties :
>  - compatible: must contain one of the following compatibles:
> - "allwinner,sun6i-a31-ccu"
> +   - "allwinner,sun8i-a33-ccu"
> - "allwinner,sun8i-h3-ccu"
>
>  - reg: Must contain the registers base address and length
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
> index c7258779daa8..dff3feff9c3c 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -65,6 +65,18 @@ config SUN6I_A31_CCU
> select SUNXI_CCU_PHASE
> default MACH_SUN6I
>
> +config SUN8I_A33_CCU
> +   bool "Support for the Allwinner A33 CCU"
> +   select SUNXI_CCU_DIV
> +   select SUNXI_CCU_MULT
> +   select SUNXI_CCU_NK
> +   select SUNXI_CCU_NKM
> +   select SUNXI_CCU_NKMP
> +   select SUNXI_CCU_NM
> +   select SUNXI_CCU_MP
> +   select SUNXI_CCU_PHASE
> +   default MACH_SUN8I
> +
>  config SUN8I_H3_CCU
> bool "Support for the Allwinner H3 CCU"
> select SUNXI_CCU_DIV
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
> index 462a5f8383ed..4f7e99fb433f 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -19,4 +19,5 @@ obj-$(CONFIG_SUNXI_CCU_MP)+= ccu_mp.o
>
>  # SoC support
>  obj-$(CONFIG_SUN6I_A31_CCU)+= ccu-sun6i-a31.o
> +obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
>  obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h 
> b/drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h
> new file mode 100644
> index ..62c0f8d49ef8
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23-a33.h
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright 2016 Maxime Ripard
> + *
> + * Maxime Ripard 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef _CCU_SUN8I_A23_A33_H_
> +#define _CCU_SUN8I_A23_A33_H_
> +
> +#include 
> +#include 
> +
> +#define CLK_PLL_CPUX   0
> +#define CLK_PLL_AUDIO_BASE 1
> +#define CLK_PLL_AUDIO  2
> +#define CLK_PLL_AUDIO_2X   3
> +#define CLK_PLL_AUDIO_4X   4
> +#define CLK_PLL_AUDIO_8X   5
> +#define CLK_PLL_VIDEO  6
> +#define CLK_PLL_VIDEO_2X   7
> +#define CLK_PLL_VE 8
> +#define CLK_PLL_DDR0   9
> +#define CLK_PLL_PERIPH 10
> +#define CLK_PLL_PERIPH_2X  11
> +#define CLK_PLL_GPU12
> +#define CLK_PLL_MIPI   13
> +#define CLK_PLL_HSIC   14
> +#define CLK_PLL_DE 15
> +#define CLK_PLL_DDR1   16
> +#define CLK_PLL_DDR17
> +
> +/* The CPUX clock is exported */
> +
> +#define CLK_AXI19
> +#define CLK_AHB1   20
> +#define CLK_APB1   21
> +#define CLK_APB2   22
> +
> +/* All the bus gates are exported */
> +
> +/* The first part of the mod clocks is exported */
> +
> +#define CLK_DRAM   79
> +
> +/* Some more module clocks are exported */
> +
> +#define CLK

Re: [PATCH] Fix region lost in /proc/self/smaps

[Xiao Guangrong]

On 09/08/2016 12:34 AM, Dave Hansen wrote:

On 09/06/2016 11:51 PM, Xiao Guangrong wrote:

In order to fix this bug, we make 'file->version' indicate the next VMA
we want to handle


This new approach makes it more likely that we'll skip a new VMA that
gets inserted in between the read()s.  But, I guess that's OK.  We don't
exactly claim to be giving super up-to-date data at the time of read().


Yes, I completely agree with you. :)



With the old code, was there also a case that we could print out the
same virtual address range more than once?  It seems like that could
happen if we had a VMA split between two reads.


Yes.



I think this introduces one oddity: if you have a VMA merge between two
reads(), you might get the same virtual address range twice in your
output.  This didn't happen before because we would have just skipped
over the area that got merged.

Take two example VMAs:

vma-A: (0x1000 -> 0x2000)
vma-B: (0x2000 -> 0x3000)

read() #1: prints vma-A, sets m->version=0x2000

Now, merge A/B to make C:

vma-C: (0x1000 -> 0x3000)

read() #2: find_vma(m->version=0x2000), returns vma-C, prints vma-C

The user will see two VMAs in their output:

A: 0x1000->0x2000
C: 0x1000->0x3000

Will it confuse them to see the same virtual address range twice?  Or is
there something preventing that happening that I'm missing?



You are right. Nothing can prevent it.

However, it is not easy to handle the case that the new VMA overlays with the 
old VMA
already got by userspace. I think we have some choices:
1: One way is completely skipping the new VMA region as current kernel code 
does but i
   do not think this is good as the later VMAs will be dropped.

2: show the un-overlayed portion of new VMA. In your case, we just show the 
region
   (0x2000 -> 0x3000), however, it can not work well if the VMA is a new created
   region with different attributions.

3: completely show the new VMA as this patch does.

Which one do you prefer?

Thanks!

Re: [PATCH v2 0/5] perf, bts: Fallout from the fuzzer for perf/urgent

[Vince Weaver]

On Wed, 7 Sep 2016, Alexander Shishkin wrote:

> Vince Weaver  writes:
> 
> > On Wed, 7 Sep 2016, Alexander Shishkin wrote:
> >
> >> Sure. And yes, I did catch a warning, which calls for one more patch
> >> (below). Also one unrelated thing in PEBS that Peter fixed.
> >
> > Does that fix this which I just got on my skylake machine (4.8-rc5 with 
> > your other 5 patches applied)
> >
> > [ 5351.822559] WARNING: CPU: 3 PID: 19191 at 
> > arch/x86/events/intel/bts.c:344 event_function+0xa1/0x160
> 
> Yes, it fixes a problem that triggered this warning. Can't tell from the
> absence of backtrace what's going on here, though.

On the skylake machine with the original 5 patches I got this after 
continuing to fuzz.  Sorry about the lack of frame pointer, next
compile will have it enabled.

If it matters, prior to this I hit the unrelated
[25510.278199] WARNING: CPU: 1 PID: 25405 at kernel/events/core.c:3554 
perf_event_read+0x18f/0x1a0


[28682.174684] WARNING: CPU: 7 PID: 31992 at kernel/events/core.c:4961 
perf_mmap_close+0x2e1/0x2f0
[28682.280579] CPU: 7 PID: 31992 Comm: perf_fuzzer Tainted: GW   
4.8.0-rc5+ #3
[28682.288739] Hardware name: LENOVO 10FY0017US/SKYBAY, BIOS FWKT53A   
06/06/2016
[28682.296096]  0286 8e07b373 8cf1f9f5 

[28682.303738]   8cc7b624 9c676e780e00 
9c676e029280
[28682.311362]  9c6772ab3398 9c676e029000 9c676e780bb0 
9c676f7c0280
[28682.319036] Call Trace:
[28682.321529]  [] ? dump_stack+0x5c/0x77
[28682.326939]  [] ? __warn+0xc4/0xe0
[28682.332018]  [] ? perf_mmap_close+0x2e1/0x2f0
[28682.338083]  [] ? perf_iterate_ctx+0x150/0x150
[28682.344218]  [] ? remove_vma+0x2d/0x70
[28682.349662]  [] ? do_munmap+0x246/0x400
[28682.355197]  [] ? SyS_munmap+0x4b/0x70
[28682.360612]  [] ? do_syscall_64+0x5f/0x160
[28682.366404]  [] ? entry_SYSCALL64_slow_path+0x25/0x25
[28682.373149] ---[ end trace bc7b0b7d0c024d62 ]---
[28682.377975] [ cut here ]
[28682.382681] WARNING: CPU: 4 PID: 0 at kernel/events/ring_buffer.c:543 
__rb_free_aux+0x110/0x120
[28682.489412] CPU: 4 PID: 0 Comm: swapper/4 Tainted: GW   
4.8.0-rc5+ #3
[28682.498106] Hardware name: LENOVO 10FY0017US/SKYBAY, BIOS FWKT53A   
06/06/2016
[28682.506518]  0086 6d2f07ae6326ed5e 8cf1f9f5 

[28682.515223]   8cc7b624 9c676e780e00 
9c677dd0b740
[28682.523996]   9c676e029000 9c676e780e00 
1a16168dab54
[28682.532867] Call Trace:
[28682.536458][] ? dump_stack+0x5c/0x77
[28682.543615]  [] ? __warn+0xc4/0xe0
[28682.549741]  [] ? __rb_free_aux+0x110/0x120
[28682.556829]  [] ? perf_aux_output_end+0xba/0x100
[28682.564312]  [] ? bts_event_stop+0xc1/0x130
[28682.571238]  [] ? perf_cgroup_attach+0x70/0x70
[28682.578402]  [] ? __perf_event_stop+0x40/0x60
[28682.585484]  [] ? remote_function+0x3a/0x40
[28682.592644]  [] ? flush_smp_call_function_queue+0x76/0x160
[28682.600867]  [] ? 
smp_trace_call_function_single_interrupt+0x29/0xc0
[28682.609914]  [] ? 
trace_call_function_single_interrupt+0x82/0x90
[28682.618608][] ? cpuidle_enter_state+0x113/0x260
[28682.626570]  [] ? cpu_startup_entry+0x2cc/0x370
[28682.633675]  [] ? start_secondary+0x14d/0x190
[28682.640749] ---[ end trace bc7b0b7d0c024d63 ]---

Re: [PATCH V2] ARM: BCM5301X: Add basic dts for BCM53573 based Tenda AC9

[Florian Fainelli]

Le 22/08/2016 à 22:37, Rafał Miłecki a écrit :
> BCM53573 seems to be low priced alternative for Northstar chipsts. It
> uses single core Cortex-A7 and doesn't have SDU or local (TWD) timer. It
> was also stripped out of independent SPI controller and 2 GMACs.
> 
> DTS for Tenda AC9 isn't completed yet. It misses e.g. switch entry (we
> still need some b53 fixes) and probably some clocks. It adds support for
> basic features however and can be improved later.
> 
> Signed-off-by: Rafał Miłecki 

Applied, thanks!
-- 
Florian

Re: [PATCH] ARM: BCM5301X: Add DT for Netgear R8500

[Florian Fainelli]

Le 22/08/2016 à 23:40, Rafał Miłecki a écrit :
> From: Rafał Miłecki 
> 
> Netgear R8500 is another BCM47094 device, it just has three BCM4366
> wireless chipsets. It's a very standard DT with mostly GPIO devices.
> 
> Signed-off-by: Rafał Miłecki 

Applied, thanks!
-- 
Florian

[PATCH] usb: dwc3: OCTEON: add support for device tree

[Steven J. Hill]

This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.

Signed-off-by: Steven J. Hill 
---
 drivers/usb/dwc3/Kconfig   | 10 +
 drivers/usb/dwc3/Makefile  |  1 +
 drivers/usb/dwc3/dwc3-octeon.c | 96 ++
 3 files changed, 107 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-octeon.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a64ce1c..99db6008 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -105,4 +105,14 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_OCTEON
+   tristate "Cavium OCTEON III Platforms"
+   depends on CAVIUM_OCTEON_SOC
+   depends on OF
+   default USB_DWC3
+   help
+ Cavium OCTEON III SoCs with one DesignWare Core USB3 IP
+ inside (i.e. cn71xx and cn78xx).
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 22420e1..f1a7a3e 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_OCTEON)  += dwc3-octeon.o
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
new file mode 100644
index 000..4339dd6
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -0,0 +1,96 @@
+/**
+ * dwc3-octeon.c - Cavium OCTEON III DWC3 Specific Glue Layer
+ *
+ * Copyright (C) 2016 Cavium Networks
+ *
+ * Author: Steven J. Hill 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Inspired by dwc3-exynos.c and dwc3-st.c files.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc3_octeon {
+   struct device   *dev;
+   void __iomem*usbctl;
+   int index;
+};
+
+static int dwc3_octeon_probe(struct platform_device *pdev)
+{
+   struct device   *dev = &pdev->dev;
+   struct resource *res;
+   struct dwc3_octeon  *octeon;
+   int ret;
+
+   octeon = devm_kzalloc(dev, sizeof(*octeon), GFP_KERNEL);
+   if (!octeon)
+   return - ENOMEM;
+
+   /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+*/
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
+   platform_set_drvdata(pdev, octeon);
+   octeon->dev = dev;
+
+   /* Resources for lower level OCTEON USB control. */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   octeon->usbctl = devm_ioremap_resource(dev, res);
+   if (IS_ERR(octeon->usbctl))
+   return PTR_ERR(octeon->usbctl);
+
+   /* Controller index. */
+   octeon->index = ((u64)octeon->usbctl >> 24) & 1;
+
+   return 0;
+}
+
+static int dwc3_octeon_remove(struct platform_device *pdev)
+{
+   struct dwc3_octeon *octeon = platform_get_drvdata(pdev);
+
+   octeon->usbctl = NULL;
+   octeon->index = -1;
+
+   return 0;
+}
+
+static const struct of_device_id octeon_dwc3_match[] = {
+   { .compatible = "cavium,octeon-7130-usb-uctl", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, octeon_dwc3_match);
+
+static struct platform_driver dwc3_octeon_driver = {
+   .probe  = dwc3_octeon_probe,
+   .remove = dwc3_octeon_remove,
+   .driver = {
+   .name   = "octeon-dwc3",
+   .of_match_table = octeon_dwc3_match,
+   .pm = NULL,
+   },
+};
+module_platform_driver(dwc3_octeon_driver);
+
+MODULE_ALIAS("platform:octeon-dwc3");
+MODULE_AUTHOR("Steven J. Hill 

[PATCH] ARM: dts: sun8i: Move A23/A33 usbphy and usb_otg nodes to common dtsi

[Chen-Yu Tsai]

The usbphy and usb_otg nodes in the A23 and A33 dts files only differ
by compatible, and for the usbphy, the size of one of its register
regions.

Move all the common bits to the A23/A33 common dtsi file.

Signed-off-by: Chen-Yu Tsai 
---

Hi Maxime,

This patch applies on top of your A23/A33 CCU patches.

---
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 30 +
 arch/arm/boot/dts/sun8i-a23.dtsi | 43 +---
 arch/arm/boot/dts/sun8i-a33.dtsi | 41 +-
 3 files changed, 50 insertions(+), 64 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 9cb474bf7911..2d1ad55daf2d 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -201,6 +201,36 @@
#size-cells = <0>;
};
 
+   usb_otg: usb@01c19000 {
+   /* compatible gets set in SoC specific dtsi file */
+   reg = <0x01c19000 0x0400>;
+   clocks = <&ccu CLK_BUS_OTG>;
+   resets = <&ccu RST_BUS_OTG>;
+   interrupts = ;
+   interrupt-names = "mc";
+   phys = <&usbphy 0>;
+   phy-names = "usb";
+   extcon = <&usbphy 0>;
+   status = "disabled";
+   };
+
+   usbphy: phy@01c19400 {
+   /*
+* compatible and address regions get set in
+* SoC specific dtsi file
+*/
+   clocks = <&ccu CLK_USB_PHY0>,
+<&ccu CLK_USB_PHY1>;
+   clock-names = "usb0_phy",
+ "usb1_phy";
+   resets = <&ccu RST_USB_PHY0>,
+<&ccu RST_USB_PHY1>;
+   reset-names = "usb0_reset",
+ "usb1_reset";
+   status = "disabled";
+   #phy-cells = <1>;
+   };
+
ehci0: usb@01c1a000 {
compatible = "allwinner,sun8i-a23-ehci", "generic-ehci";
reg = <0x01c1a000 0x100>;
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index a915feb3a494..54d045dab825 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -48,39 +48,6 @@
memory {
reg = <0x4000 0x4000>;
};
-
-   soc@01c0 {
-   usb_otg: usb@01c19000 {
-   compatible = "allwinner,sun6i-a31-musb";
-   reg = <0x01c19000 0x0400>;
-   clocks = <&ccu CLK_BUS_OTG>;
-   resets = <&ccu RST_BUS_OTG>;
-   interrupts = ;
-   interrupt-names = "mc";
-   phys = <&usbphy 0>;
-   phy-names = "usb";
-   extcon = <&usbphy 0>;
-   status = "disabled";
-   };
-
-   usbphy: phy@01c19400 {
-   compatible = "allwinner,sun8i-a23-usb-phy";
-   reg = <0x01c19400 0x10>,
- <0x01c1a800 0x4>;
-   reg-names = "phy_ctrl",
-   "pmu1";
-   clocks = <&ccu CLK_USB_PHY0>,
-<&ccu CLK_USB_PHY1>;
-   clock-names = "usb0_phy",
- "usb1_phy";
-   resets = <&ccu RST_USB_PHY0>,
-<&ccu RST_USB_PHY1>;
-   reset-names = "usb0_reset",
- "usb1_reset";
-   status = "disabled";
-   #phy-cells = <1>;
-   };
-   };
 };
 
 &ccu {
@@ -93,3 +60,13 @@
 ,
 ;
 };
+
+&usb_otg {
+   compatible = "allwinner,sun6i-a31-musb";
+};
+
+&usbphy {
+   compatible = "allwinner,sun8i-a23-usb-phy";
+   reg = <0x01c19400 0x10>, <0x01c1a800 0x4>;
+   reg-names = "phy_ctrl", "pmu1";
+};
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index f3d91d2c96ef..bc939c0e317d 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -73,37 +73,6 @@
resets = <&ccu RST_BUS_SS>;
reset-names = "ahb";
};
-
-   usb_otg: usb@01c19000 {
-   compatible = "allwinner,sun8i-a33-musb";
-   reg = <0x01c19000 0x0400>;
-   clocks = <&ccu CLK_BUS_OTG>;
-   resets = <&ccu RST_BUS_OTG>;
-   interr

Re: [PATCH V2 2/3] pwm: Add MediaTek MT2701 display PWM driver support

[Thierry Reding]

On Mon, Jul 11, 2016 at 04:18:08PM +0800, Weiqing Kong wrote:
> Use the mtk_pwm_data struction to define different registers
> and add MT2701 specific register operations, such as MT2701
> doesn't have commit register, needs to disable double buffer
> before writing register, and needs to select manual mode
> and use PWM_PERIOD/PWM_HIGH_WIDTH.
> 
> Signed-off-by: Weiqing Kong 
> ---
>  drivers/pwm/pwm-mtk-disp.c | 99 
> +-
>  1 file changed, 80 insertions(+), 19 deletions(-)

Applied. This had a few inconsistencies in how things were parameterized
and I fixed those up. Please check that everything still works as
expected.

Thanks,
Thierry


signature.asc
Description: PGP signature

[PATCH] phy: sun4i-usb: Use spinlock to guard phyctl register access

[Chen-Yu Tsai]

The musb driver calls into this phy driver to disable/enable squelch
detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb:
Add a sunxi specific function for setting squelch-detect"). This
function in turn calls sun4i_usb_phy_write, which uses a mutex to
guard the common access register. Unfortunately musb does this
in atomic context, which results in the following warning with lock
debugging enabled:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: kworker/0:2
CPU: 0 PID: 96 Comm: kworker/0:2 Not tainted 4.8.0-rc4-00181-gd502f8ad1c3e #13
Hardware name: Allwinner sun8i Family
Workqueue: events musb_deassert_reset
[] (unwind_backtrace) from [] (show_stack+0xb/0xc)
[] (show_stack) from [] (dump_stack+0x67/0x74)
[] (dump_stack) from [] (mutex_lock+0x15/0x2c)
[] (mutex_lock) from [] (sun4i_usb_phy_write+0x39/0xec)
[] (sun4i_usb_phy_write) from [] 
(musb_port_reset+0xfb/0x184)
[] (musb_port_reset) from [] (musb_deassert_reset+0x1f/0x2c)
[] (musb_deassert_reset) from [] 
(process_one_work+0x129/0x2b8)
[] (process_one_work) from [] (worker_thread+0xf3/0x424)
[] (worker_thread) from [] (kthread+0xa1/0xb8)
[] (kthread) from [] (ret_from_fork+0x11/0x20)

Since the register access is mmio, we can use a spinlock to guard this
specific access, rather than the mutex that guards the entire phy.

Fixes: ba4bdc9e1dc0 ("PHY: sunxi: Add driver for sunxi usb phy")
Cc: Hans de Goede 
Cc: sta...@vger.kernel.org
Signed-off-by: Chen-Yu Tsai 
---
 drivers/phy/phy-sun4i-usb.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index fcf4d95ecc6d..ae4ac5457c64 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -115,6 +116,7 @@ struct sun4i_usb_phy_data {
const struct sun4i_usb_phy_cfg *cfg;
enum usb_dr_mode dr_mode;
struct mutex mutex;
+   spinlock_t reg_lock; /* guard access to phyctl reg */
struct sun4i_usb_phy {
struct phy *phy;
void __iomem *pmu;
@@ -183,7 +185,7 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, 
u32 addr, u32 data,
void __iomem *phyctl = phy_data->base + phy_data->cfg->phyctl_offset;
int i;
 
-   mutex_lock(&phy_data->mutex);
+   spin_lock(&phy_data->reg_lock);
 
if (phy_data->cfg->type == sun8i_a33_phy ||
phy_data->cfg->type == sun50i_a64_phy) {
@@ -221,7 +223,8 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, 
u32 addr, u32 data,
 
data >>= 1;
}
-   mutex_unlock(&phy_data->mutex);
+
+   spin_unlock(&phy_data->reg_lock);
 }
 
 static void sun4i_usb_phy_passby(struct sun4i_usb_phy *phy, int enable)
@@ -583,6 +586,7 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return -ENOMEM;
 
mutex_init(&data->mutex);
+   spin_lock_init(&data->reg_lock);
INIT_DELAYED_WORK(&data->detect, sun4i_usb_phy0_id_vbus_det_scan);
dev_set_drvdata(dev, data);
data->cfg = of_device_get_match_data(dev);
-- 
2.9.3

Re: [PATCH] [media] pci: constify snd_pcm_ops structures

[Julia Lawall]

On Thu, 8 Sep 2016, Andrey Utkin wrote:

> Thanks for looking into this.
> I have tested that it compiles and passes checks (C=2) cleanly after
> this patch.
>
> Acked-by: Andrey Utkin 
>
> While we're at it, what about constification of
> *-core.c:static struct pci_driver *_pci_driver = {
> *-video.c:static struct vb2_ops *_video_qops = {
> *-video.c:static struct video_device *_video_template = {
>
> in drivers/media/pci/? Also there are even more similar entries not
> constified yet in drivers/media/, however I may be underestimating
> complexity of making semantic rules for catching that all.

I will check on these.  Thanks for the suggestion.

julia

Re: bcache vs bcachefs

[Theodore Ts'o]

On Wed, Sep 07, 2016 at 07:55:52AM -0800, Kent Overstreet wrote:
> That said, I'm not advocating people rush out to throw bcachefs on their 
> servers
> or use it without backups yet, it's still young and needs more widespread
> testing.

Hi Kent!

Have you started using xfstests to stress test bcachefs yet?

You may be interested in reading through this presentation, especially
the last slide.  :-)

   https://thunk.org/gce-xfstests

- Ted

[PATCH V6 3/3] stm: Mark the functions of writing buffer with notrace

[Chunyan Zhang]

If CONFIG_STM_FTRACE is selected, Function trace data can be writen
to sink via STM, all functions that related to writing data packets
to STM should be marked 'notrace' to avoid being traced by Ftrace,
otherwise the program would stall into an endless loop.

Signed-off-by: Chunyan Zhang 
Acked-by: Steven Rostedt 
---
 drivers/hwtracing/coresight/coresight-stm.c |  2 +-
 drivers/hwtracing/intel_th/sth.c| 11 +++
 drivers/hwtracing/stm/core.c|  7 ---
 drivers/hwtracing/stm/dummy_stm.c   |  2 +-
 include/linux/stm.h |  4 ++--
 5 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-stm.c 
b/drivers/hwtracing/coresight/coresight-stm.c
index 73be58a..345c81e 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -386,7 +386,7 @@ static long stm_generic_set_options(struct stm_data 
*stm_data,
return 0;
 }
 
-static ssize_t stm_generic_packet(struct stm_data *stm_data,
+static ssize_t notrace stm_generic_packet(struct stm_data *stm_data,
  unsigned int master,
  unsigned int channel,
  unsigned int packet,
diff --git a/drivers/hwtracing/intel_th/sth.c b/drivers/hwtracing/intel_th/sth.c
index e1aee61..b034446 100644
--- a/drivers/hwtracing/intel_th/sth.c
+++ b/drivers/hwtracing/intel_th/sth.c
@@ -67,10 +67,13 @@ static void sth_iowrite(void __iomem *dest, const unsigned 
char *payload,
}
 }
 
-static ssize_t sth_stm_packet(struct stm_data *stm_data, unsigned int master,
- unsigned int channel, unsigned int packet,
- unsigned int flags, unsigned int size,
- const unsigned char *payload)
+static ssize_t notrace sth_stm_packet(struct stm_data *stm_data,
+ unsigned int master,
+ unsigned int channel,
+ unsigned int packet,
+ unsigned int flags,
+ unsigned int size,
+ const unsigned char *payload)
 {
struct sth_device *sth = container_of(stm_data, struct sth_device, stm);
struct intel_th_channel __iomem *out =
diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
index 51f81d6..37d3bcb 100644
--- a/drivers/hwtracing/stm/core.c
+++ b/drivers/hwtracing/stm/core.c
@@ -425,7 +425,7 @@ static int stm_file_assign(struct stm_file *stmf, char *id, 
unsigned int width)
return ret;
 }
 
-static ssize_t stm_write(struct stm_data *data, unsigned int master,
+static ssize_t notrace stm_write(struct stm_data *data, unsigned int master,
  unsigned int channel, const char *buf, size_t count)
 {
unsigned int flags = STP_PACKET_TIMESTAMPED;
@@ -1121,8 +1121,9 @@ void stm_source_unregister_device(struct stm_source_data 
*data)
 }
 EXPORT_SYMBOL_GPL(stm_source_unregister_device);
 
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
-const char *buf, size_t count)
+int notrace stm_source_write(struct stm_source_data *data,
+unsigned int chan,
+const char *buf, size_t count)
 {
struct stm_source_device *src = data->src;
struct stm_device *stm;
diff --git a/drivers/hwtracing/stm/dummy_stm.c 
b/drivers/hwtracing/stm/dummy_stm.c
index a86612d..c5f94ca 100644
--- a/drivers/hwtracing/stm/dummy_stm.c
+++ b/drivers/hwtracing/stm/dummy_stm.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 
-static ssize_t
+static ssize_t notrace
 dummy_stm_packet(struct stm_data *stm_data, unsigned int master,
 unsigned int channel, unsigned int packet, unsigned int flags,
 unsigned int size, const unsigned char *payload)
diff --git a/include/linux/stm.h b/include/linux/stm.h
index 8369d8a..210ff22 100644
--- a/include/linux/stm.h
+++ b/include/linux/stm.h
@@ -133,7 +133,7 @@ int stm_source_register_device(struct device *parent,
   struct stm_source_data *data);
 void stm_source_unregister_device(struct stm_source_data *data);
 
-int stm_source_write(struct stm_source_data *data, unsigned int chan,
-const char *buf, size_t count);
+int notrace stm_source_write(struct stm_source_data *data, unsigned int chan,
+const char *buf, size_t count);
 
 #endif /* _STM_H_ */
-- 
2.7.4

[PATCH V6 2/3] stm class: ftrace: Add ftrace-export-over-stm driver

[Chunyan Zhang]

This patch adds a driver that models itself as an stm_source.  Once the stm
device and stm_source have been linked via sysfs, the driver registers
itself as a trace_export and everything passed to the interface from Ftrace
subsystem will end up in the STM trace engine.

Signed-off-by: Chunyan Zhang 
---
 drivers/hwtracing/stm/Kconfig  | 11 ++
 drivers/hwtracing/stm/Makefile |  2 +
 drivers/hwtracing/stm/ftrace.c | 88 ++
 3 files changed, 101 insertions(+)
 create mode 100644 drivers/hwtracing/stm/ftrace.c

diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig
index 847a39b..b34ea96 100644
--- a/drivers/hwtracing/stm/Kconfig
+++ b/drivers/hwtracing/stm/Kconfig
@@ -39,4 +39,15 @@ config STM_SOURCE_HEARTBEAT
  If you want to send heartbeat messages over STM devices,
  say Y.
 
+config STM_SOURCE_FTRACE
+   tristate "Copy the output from kernel Ftrace to STM engine"
+   depends on TRACING
+   help
+ This option can be used to copy the output from kernel Ftrace
+ to STM engine. Enabling this option will introduce a slight
+ timing effect.
+
+ If you want to send kernel Ftrace messages over STM devices,
+ say Y.
+
 endif
diff --git a/drivers/hwtracing/stm/Makefile b/drivers/hwtracing/stm/Makefile
index a9ce3d4..3abd84c 100644
--- a/drivers/hwtracing/stm/Makefile
+++ b/drivers/hwtracing/stm/Makefile
@@ -6,6 +6,8 @@ obj-$(CONFIG_STM_DUMMY) += dummy_stm.o
 
 obj-$(CONFIG_STM_SOURCE_CONSOLE)   += stm_console.o
 obj-$(CONFIG_STM_SOURCE_HEARTBEAT) += stm_heartbeat.o
+obj-$(CONFIG_STM_SOURCE_FTRACE)+= stm_ftrace.o
 
 stm_console-y  := console.o
 stm_heartbeat-y:= heartbeat.o
+stm_ftrace-y   := ftrace.o
diff --git a/drivers/hwtracing/stm/ftrace.c b/drivers/hwtracing/stm/ftrace.c
new file mode 100644
index 000..e652bae
--- /dev/null
+++ b/drivers/hwtracing/stm/ftrace.c
@@ -0,0 +1,88 @@
+/*
+ * Simple kernel driver to link kernel Ftrace and an STM device
+ * Copyright (c) 2016, Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * STM Ftrace will be registered as a trace_export.
+ */
+
+#include 
+#include 
+#include 
+
+#define STM_FTRACE_NR_CHANNELS 1
+#define STM_FTRACE_CHAN 0
+
+static int stm_ftrace_link(struct stm_source_data *data);
+static void stm_ftrace_unlink(struct stm_source_data *data);
+
+static struct stm_ftrace {
+   struct stm_source_data  data;
+   struct trace_export ftrace;
+} stm_ftrace = {
+   .data   = {
+   .name   = "ftrace",
+   .nr_chans   = STM_FTRACE_NR_CHANNELS,
+   .link   = stm_ftrace_link,
+   .unlink = stm_ftrace_unlink,
+   },
+};
+
+/**
+ * stm_ftrace_write() - write data to STM via 'stm_ftrace' source
+ * @buf:   buffer containing the data packet
+ * @len:   length of the data packet
+ */
+static void notrace
+stm_ftrace_write(const char *buf, unsigned int len)
+{
+   stm_source_write(&stm_ftrace.data, STM_FTRACE_CHAN, buf, len);
+}
+
+static int stm_ftrace_link(struct stm_source_data *data)
+{
+   struct stm_ftrace *sf = container_of(data, struct stm_ftrace, data);
+
+   sf->ftrace.write = stm_ftrace_write;
+   sf->ftrace.next = NULL;
+
+   return register_ftrace_export(&sf->ftrace);
+}
+
+static void stm_ftrace_unlink(struct stm_source_data *data)
+{
+   struct stm_ftrace *sc = container_of(data, struct stm_ftrace, data);
+
+   unregister_ftrace_export(&sc->ftrace);
+}
+
+static int __init stm_ftrace_init(void)
+{
+   int ret;
+
+   ret = stm_source_register_device(NULL, &stm_ftrace.data);
+   if (ret)
+   pr_err("Failed to register stm_source - ftrace.\n");
+
+   return ret;
+}
+
+static void __exit stm_ftrace_exit(void)
+{
+   stm_source_unregister_device(&stm_ftrace.data);
+}
+
+module_init(stm_ftrace_init);
+module_exit(stm_ftrace_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("stm_ftrace driver");
+MODULE_AUTHOR("Chunyan Zhang ");
-- 
2.7.4

[PATCH V6 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

[Chunyan Zhang]

Currently Function traces can be only exported to ring buffer, this
patch added trace_export concept which can process traces and export
them to a registered destination as an addition to the current only
output of Ftrace - i.e. ring buffer.

In this way, if we want Function traces to be sent to other destination
rather than ring buffer only, we just need to register a new
trace_export and implement its own .write() function for writing traces
to storage.

With this patch, only Function trace (trace type is TRACE_FN)
is supported.

Signed-off-by: Chunyan Zhang 
---
 include/linux/trace.h |  33 +
 kernel/trace/trace.c  | 132 +-
 2 files changed, 164 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/trace.h

diff --git a/include/linux/trace.h b/include/linux/trace.h
new file mode 100644
index 000..dd28cd1
--- /dev/null
+++ b/include/linux/trace.h
@@ -0,0 +1,33 @@
+#ifndef _LINUX_TRACE_H
+#define _LINUX_TRACE_H
+
+#include 
+struct trace_array;
+
+#ifdef CONFIG_TRACING
+/*
+ * The trace export - an export of Ftrace. The trace_export can process
+ * traces and export them to a registered destination as an addition to
+ * the current only output of Ftrace - i.e. ring buffer.
+ *
+ * If you want traces to be sent to some other place rather than
+ * ring buffer only, just need to register a new trace_export and
+ * implement its own .commit() callback or just directly use
+ * 'trace_generic_commit()' and hooks up its own .write() function
+ * for writing traces to the storage.
+ *
+ * next- pointer to the next trace_export
+ * write   - copy traces which have been delt with ->commit() to
+ *   the destination
+ */
+struct trace_export {
+   struct trace_export __rcu   *next;
+   void (*write)(const char *, unsigned int);
+};
+
+int register_ftrace_export(struct trace_export *export);
+int unregister_ftrace_export(struct trace_export *export);
+
+#endif /* CONFIG_TRACING */
+
+#endif /* _LINUX_TRACE_H */
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index dade4c9..81e8923 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "trace.h"
@@ -2128,6 +2129,132 @@ void trace_buffer_unlock_commit_regs(struct trace_array 
*tr,
ftrace_trace_userstack(buffer, flags, pc);
 }
 
+static void
+trace_process_export(struct trace_export *export,
+  struct ring_buffer_event *event)
+{
+   struct trace_entry *entry;
+   unsigned int size = 0;
+
+   entry = ring_buffer_event_data(event);
+
+   size = ring_buffer_event_length(event);
+
+   if (export->write)
+   export->write((char *)entry, size);
+}
+
+static DEFINE_MUTEX(ftrace_export_lock);
+
+static struct trace_export __rcu *ftrace_exports_list __read_mostly;
+
+static DEFINE_STATIC_KEY_FALSE(ftrace_exports_enabled);
+
+static inline void ftrace_exports_enable(void)
+{
+   static_branch_enable(&ftrace_exports_enabled);
+}
+
+static inline void ftrace_exports_disable(void)
+{
+   static_branch_disable(&ftrace_exports_enabled);
+}
+
+void ftrace_exports(struct ring_buffer_event *event)
+{
+   struct trace_export *export;
+
+   preempt_disable_notrace();
+
+   export = rcu_dereference_raw_notrace(ftrace_exports_list);
+   while (export) {
+   trace_process_export(export, event);
+   export = rcu_dereference_raw_notrace(export->next);
+   }
+
+   preempt_enable_notrace();
+}
+
+static inline void
+add_trace_export(struct trace_export **list, struct trace_export *export)
+{
+   rcu_assign_pointer(export->next, *list);
+   /*
+* We are entering export into the list but another
+* CPU might be walking that list. We need to make sure
+* the export->next pointer is valid before another CPU sees
+* the export pointer included into the list.
+*/
+   rcu_assign_pointer(*list, export);
+}
+
+static inline int
+rm_trace_export(struct trace_export **list, struct trace_export *export)
+{
+   struct trace_export **p;
+
+   for (p = list; *p != NULL; p = &(*p)->next)
+   if (*p == export)
+   break;
+
+   if (*p != export)
+   return -1;
+
+   rcu_assign_pointer(*p, (*p)->next);
+
+   return 0;
+}
+
+static inline void
+add_ftrace_export(struct trace_export **list, struct trace_export *export)
+{
+   if (*list == NULL)
+   ftrace_exports_enable();
+
+   add_trace_export(list, export);
+}
+
+static inline int
+rm_ftrace_export(struct trace_export **list, struct trace_export *export)
+{
+   int ret;
+
+   ret = rm_trace_export(list, export);
+   if (*list == NULL)
+   ftrace_exports_disable();
+
+   return ret;
+}
+
+int register_ftrace_export(struct trace_export *export)
+{
+   if (WARN_ON_ONCE(!export->writ

[PATCH V6 0/3] Integration of function trace with System Trace IP blocks

[Chunyan Zhang]

IP blocks allowing a variety of trace sources to log debugging
information to a pre-defined area have been introduced on a couple of
architecture [1][2]. These system trace blocks (also known as STM)
typically follow the MIPI STPv2 protocol [3] and provide a system wide
logging facility to any device, running a kernel or not, with access
to the block's log entry port(s).  Since each trace message has a
timestamp, it is possible to correlate events happening in the entire
system rather than being confined to the logging facility of a single
entity.

This patchset is trying to use STM IP blocks to store function tracing
information produced by Ftrace and I'm taking the Function trace
(trace type is TRACE_FN) as the example in this patchset, but other
types of traces also can be supported.

Logging information generated by the Ftrace subsystem to STM and gathered
in the sink device can be used in conjunction with trace data from other
board components, also collected in the same trace sink.  

This example is using ARM coresight STM but the same would apply to any
other architecture wishing to do the same.

Comments would be greatly appreciated.

Thanks,
Chunyan

[1]. https://lwn.net/Articles/674746/
[2]. http://lxr.free-electrons.com/source/drivers/hwtracing/intel_th/
[3]. http://mipi.org/specifications/debug#STP

Changes from v5:
* Addressed comments from Steven Rostedt:
  - Removed .commit() from trace_export;
  - Changed to directly call trace_process_export() instead of 
trace_export::commit();
  - Used 'ring_buffer_event_length(event)' instead to get the trace size;
  - Removed trace_export pointer from trace_array structure.
* Revised commit message a little to make the description more accurate.

Changes from v4:
* Addressed comments from Steven Rostedt:
  - Removed 'inline' annotations from the function which is called via function 
pointer;
  - Removed useless components from structure trace_export;
  - Added '__rcu' annotation to the RCU variables;
  - Used 'rcu_assign_pointer' to do every RCU assignment;
  - Added WARN_ON_ONCE() when the .write() is not assigned;
  - In order to reduce the overhead caused by adding this feature, this 
revision used an
global array instead of a big "if statement" to get the size of trace entry 
according
to the trace type.
  - In order to keep the current logic unchanged, made ftrace_exports() only 
being called if
there's something have been added, i.e. if trace_export to stm_ftrace has 
been added in
this patchset.

Changes from v3:
* Addressed comments from Steven Rostedt:
  - Added comments for the element 'name' and 'next' of trace_export;
  - Changed to use RCU functions instead of mutex in function callback;
  - Moved the check for name to register trace_export function;
* Renamed 'trace_function_exports' to 'trace_exports' since its
  implementation is not only for function_trace;  The similar changes on
  'add_trace_export' and 'rm_trace_export'.

Changes from v2:
* Rebased on v4.8-rc1.
* Added trace_export class, and make traces can be exported to not only
ring buffer but also other area such as STM.
* Made stm_ftrace as an trace_export.
* More detailed changes are described in change log of each patch.

Changes from v1:
* Addressed comments from Alexander Shishkin:
 - Modified some ambiguous change logs.
 - Decoupled stm_ftrace and trace_output interface to STM.
 - Changed the file name from stm_ftrace.c to stm/ftrace.c.
 - Implemented link/unlink hooks for stm_ftrace.
* Removed useless header file include from stm/ftrace.c
* Added Acked-by from Steven Rostedt on 4/4.

Chunyan Zhang (3):
  tracing: add a possibility of exporting function trace to other places
instead of ring buffer only
  stm class: ftrace: Add ftrace-export-over-stm driver
  stm: Mark the functions of writing buffer with notrace

 drivers/hwtracing/coresight/coresight-stm.c |   2 +-
 drivers/hwtracing/intel_th/sth.c|  11 ++-
 drivers/hwtracing/stm/Kconfig   |  11 +++
 drivers/hwtracing/stm/Makefile  |   2 +
 drivers/hwtracing/stm/core.c|   7 +-
 drivers/hwtracing/stm/dummy_stm.c   |   2 +-
 drivers/hwtracing/stm/ftrace.c  |  88 +++
 include/linux/stm.h |   4 +-
 include/linux/trace.h   |  33 +++
 kernel/trace/trace.c| 132 +++-
 10 files changed, 280 insertions(+), 12 deletions(-)
 create mode 100644 drivers/hwtracing/stm/ftrace.c
 create mode 100644 include/linux/trace.h

-- 
2.7.4

RE: [PATCH net-next 0/3] r8152: configuration setting

[Hayes Wang]

David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, September 08, 2016 8:38 AM
[...]
> By forcing a certain mode via a Kconfig value, you are basically making it
> impossible for distributions to do something reasonable here.

The request is always from some manufacturers, not end users.
They always ask the driver to control everything. And I don't
think the end user knows or cares about how the device is set.
That is why I try to satisfy them via Kconfig.

I think you have rejected this way. I would think if there
is any other method. Thanks.

Best Regards,
Hayes

Re: linux-next: Tree for Sep 7 (kernel/trace/trace_hwlat.c)

[Steven Rostedt]

On Thu, 8 Sep 2016 07:42:01 +1000
Stephen Rothwell  wrote:

> > Link:
> > http://lkml.kernel.org/r/20160907175258.1f17a...@canb.auug.org.au  
> 
> That is not the reporting email ... Randy's was a reply to that one
> with message id
> "".
> 

Strange, I wonder how I got that email. I cut and pasted it from the
email itself, perhaps I picked "In-Reply-To" by accident.

-- Steve

Re: linux-next: Tree for Sep 7 (kernel/trace/trace_hwlat.c)

[Steven Rostedt]

On Wed, 7 Sep 2016 13:55:47 -0700
Randy Dunlap  wrote:
 
> Yes, that works. Thanks.
> 
> Acked-by: Randy Dunlap 

Hmm, would "Tested-by" be a more appropriate tag?

-- Steve

Re: [RFC] zram: support page-based parallel write

[Minchan Kim]

Hi Sergey,

On Thu, Sep 08, 2016 at 10:34:44AM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
> 
> sorry, I don't have enough time at the moment to review it in details
> due to some urgent issues I'm working on.  can this wait?

Why not.

I need a time to complete the work for removing RFC tag, too.
I just posted incomplete code to discuss the direction, approach
with big design level, not a code detail level at this moment.

As waiting your time, I will enhance code qualitiy so you cannot see
the mess when you finally have a time to review. :)

> 
> 
> I was looking at loop.c awhile ago and was considering to do something
> similar to what they have done; but it never happened.
> 
> 
> I'm a bit 'surprised' that the performance has just 2x, whilst there
> are 4x processing threads. I'd rather expect it to be close to 4x... hm.

Me, too.
It seems it's related to work distribution to CPUs but not investigated
in detail.

> 
> 
> On (09/06/16 16:24), Minchan Kim wrote:
> [..]
> > +static void worker_wake_up(void)
> > +{
> > +   if (workers.nr_running * NR_BATCH_PAGES < workers.nr_req) {
> > +   int nr_wakeup = (workers.nr_req + NR_BATCH_PAGES) /
> > +   NR_BATCH_PAGES - workers.nr_running;
> > +
> > +   WARN_ON(!nr_wakeup);
> > +   wake_up_nr(&workers.req_wait, nr_wakeup);
> > }
> > +}
> 
> this seems to be quite complicated. use a wq perhaps? yes, there is a

Sure, It's So mess. I'm reconsidering now and finally should have
better way.

About wq, as you can guess by my function naming, I tried wq model first
for a while. It had several issues but can't say because I should know
wq internal detail to tell you exactly something but right now the time
is not allowed. Anyway, most important part with going thread model to me
is the job's completion time is totally unbounded.
While a thread is handling request, another context is queueing the request
endlessly. For this case, thread model is more proper, I think.

> common concern with the wq that all of the workers can stall during OOM,
> but you already have 2 kmalloc()-s in IO path (when adding a new request),
> so low memory condition concerns are out of sight here, I assume.

Yes, it's no problem because the logic have a fallback mechanism which
handle IO request synchronously if async logic is failed by some reason
(mostly -ENOMEM).

> 
> > +static int __zram_make_async_request(struct zram *zram, struct bio *bio)
> > +{
> > +   int offset;
> > +   u32 index;
> > +   struct bio_vec bvec;
> > +   struct bvec_iter iter;
> > +   LIST_HEAD(page_list);
> > +   struct bio_request *bio_req;
> > +   unsigned int nr_pages = 0;
> > +   bool write = op_is_write(bio_op(bio));
> > +
> > +   index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
> > +   offset = (bio->bi_iter.bi_sector &
> > + (SECTORS_PER_PAGE - 1)) << SECTOR_SHIFT;
> > +
> > +   bio_req = kmalloc(sizeof(*bio_req), GFP_NOIO);
> > +   if (!bio_req)
> > +   return 1;
> > +
> > +   /*
> > +* Keep bi_vcnt to complete bio handling when all of pages
> > +* in the bio are handled.
> > +*/
> > +   bio_req->bio = bio;
> > +   atomic_set(&bio_req->nr_pages, 0);
> > +
> > +   bio_for_each_segment(bvec, bio, iter) {
> > +   int max_transfer_size = PAGE_SIZE - offset;
> > +
> > +   if (bvec.bv_len > max_transfer_size) {
> > +   /*
> > +* zram_bvec_rw() can only make operation on a single
> > +* zram page. Split the bio vector.
> > +*/
> > +   struct bio_vec bv;
> > +
> > +   bv.bv_page = bvec.bv_page;
> > +   bv.bv_len = max_transfer_size;
> > +   bv.bv_offset = bvec.bv_offset;
> > +
> > +   if (queue_page_request_list(zram, bio_req, &bv,
> > +   index, offset, write, &page_list))
> > +   goto out;
> > +   nr_pages++;
> > +
> > +   bv.bv_len = bvec.bv_len - max_transfer_size;
> > +   bv.bv_offset += max_transfer_size;
> > +   if (queue_page_request_list(zram, bio_req, &bv,
> > +   index + 1, 0, write, &page_list))
> > +   goto out;
> > +   nr_pages++;
> > +   } else
> > +   if (queue_page_request_list(zram, bio_req, &bvec,
> > +   index, offset, write, &page_list))
> > +   goto out;
> > +   nr_pages++;
>   ^^
> + else {
>   if (queue_page_request_list(zram, bio_req, &bvec...
>   .
>   nr_pages++;
> + }

Thanks but it's wrong too. :)

The logic shoud be this way.

else {
if (queue_page_request_list)
goto out
nr_pages++
}

I will fix it

Re: [PATCH] kbuild/builddeb: Fix !CONFIG_GCC_PLUGINS build

[Michal Marek]

Dne 3.9.2016 v 21:58 Borislav Petkov napsal(a):
> From: Borislav Petkov 
> 
> When building a bindeb-pkg target into an object output dir, i.e., O=, I
> get:
> 
>   find: `scripts/gcc-plugins': No such file or directory
>   /mnt/kernel/kernel/linux-2.6/scripts/package/Makefile:97: recipe for target 
> 'bindeb-pkg' failed
>   make[3]: *** [bindeb-pkg] Error 1
>   /mnt/kernel/kernel/linux-2.6/Makefile:1310: recipe for target 'bindeb-pkg' 
> failed
>   ...
> 
> Check whether CONFIG_GCC_PLUGINS is enabled before collecting .so plugin
> names.

A fix has already been submitted by Kees Cook. I took your patch as a
reminder to submit my rc-fixes branch to Linus :).

Thanks,
Michal

RE: [PATCH net-next 0/3] r8152: configuration setting

[Hayes Wang]

Bjørn Mork [mailto:bj...@mork.no]
> Sent: Wednesday, September 07, 2016 9:51 PM
[...]
> So this adds a lot of code to work around the issues you introduced by
> unnecessarily blacklisting the CDC ECM configuration earlier, and still
> makes the r8152 driver handle the device even in ECM mode.

I suggest to use vendor mode only, but some people ask me to
submit such patches. If these patches are rejected, I have
enough reasons to tell them it is unacceptable rather than
I don't do it.

> Just remove the completely unnecessary blacklist, and let the cdc_ether
> driver handle the device if the user selects the ECM configuration.
> That't how the USB system works.  There is no need for any code in r8152
> to do that.

The pure cdc_ether driver couldn't change the speed of the
ethernet, because it doesn't know how to access the PHY of
the device. Therefore, I add relative code in r8152 driver.

Best Regards,
Hayes

[PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

[Anshuman Khandual]

Each individual node in the system has a ZONELIST_FALLBACK zonelist
and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
order of zones during memory allocations. Sometimes it helps to dump
these zonelists to see the priority order of various zones in them.

Particularly platforms which support memory hotplug into previously
non existing zones (at boot), this interface helps in visualizing
which all zonelists of the system at what priority level, the new
hot added memory ends up in. POWER is such a platform where all the
memory detected during boot time remains with ZONE_DMA for good but
then hot plug process can actually get new memory into ZONE_MOVABLE.
So having a way to get the snapshot of the zonelists on the system
after memory or node hot[un]plug is desirable. This change adds one
new sysfs interface (/sys/devices/system/memory/system_zone_details)
which will fetch and dump this information.

Example zonelist information from a KVM guest.

[NODE (0)]
ZONELIST_FALLBACK
(0) (node 0) (DMA 0xc0006300)
(1) (node 1) (DMA 0xc0016300)
(2) (node 2) (DMA 0xc0026300)
(3) (node 3) (DMA 0xc003ffdba300)
ZONELIST_NOFALLBACK
(0) (node 0) (DMA 0xc0006300)
[NODE (1)]
ZONELIST_FALLBACK
(0) (node 1) (DMA 0xc0016300)
(1) (node 2) (DMA 0xc0026300)
(2) (node 3) (DMA 0xc003ffdba300)
(3) (node 0) (DMA 0xc0006300)
ZONELIST_NOFALLBACK
(0) (node 1) (DMA 0xc0016300)
[NODE (2)]
ZONELIST_FALLBACK
(0) (node 2) (DMA 0xc0026300)
(1) (node 3) (DMA 0xc003ffdba300)
(2) (node 0) (DMA 0xc0006300)
(3) (node 1) (DMA 0xc0016300)
ZONELIST_NOFALLBACK
(0) (node 2) (DMA 0xc0026300)
[NODE (3)]
ZONELIST_FALLBACK
(0) (node 3) (DMA 0xc003ffdba300)
(1) (node 0) (DMA 0xc0006300)
(2) (node 1) (DMA 0xc0016300)
(3) (node 2) (DMA 0xc0026300)
ZONELIST_NOFALLBACK
(0) (node 3) (DMA 0xc003ffdba300)

Signed-off-by: Anshuman Khandual 
---
Changes in V4:
- Explicitly included mmzone.h header inside page_alloc.c
- Changed the kernel address printing from %lx to %pK

Changes in V3:
- Moved all these new sysfs code inside CONFIG_NUMA

Changes in V2:
- Added more details into the commit message
- Added sysfs interface file details into the commit message
- Added ../ABI/testing/sysfs-system-zone-details file

 .../ABI/testing/sysfs-system-zone-details  |  9 
 drivers/base/memory.c  | 52 ++
 mm/page_alloc.c|  1 +
 3 files changed, 62 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-system-zone-details

diff --git a/Documentation/ABI/testing/sysfs-system-zone-details 
b/Documentation/ABI/testing/sysfs-system-zone-details
new file mode 100644
index 000..9c13b2e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-system-zone-details
@@ -0,0 +1,9 @@
+What:  /sys/devices/system/memory/system_zone_details
+Date:  Sep 2016
+KernelVersion: 4.8
+Contact:   khand...@linux.vnet.ibm.com
+Description:
+   This read only file dumps the zonelist and it's constituent
+   zones information for both ZONELIST_FALLBACK and ZONELIST_
+   NOFALLBACK zonelists for each online node of the system at
+   any given point of time.
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index dc75de9..c7ab991 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -442,7 +442,56 @@ print_block_size(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "%lx\n", get_memory_block_size());
 }
 
+#ifdef CONFIG_NUMA
+static ssize_t dump_zonelist(char *buf, struct zonelist *zonelist)
+{
+   unsigned int i;
+   ssize_t count = 0;
+
+   for (i = 0; zonelist->_zonerefs[i].zone; i++) {
+   count += sprintf(buf + count,
+   "\t\t(%d) (node %d) (%-7s 0x%pK)\n", i,
+   zonelist->_zonerefs[i].zone->zone_pgdat->node_id,
+   zone_names[zonelist->_zonerefs[i].zone_idx],
+   (void *) zonelist->_zonerefs[i].zone);
+   }
+   return count;
+}
+
+static ssize_t dump_zonelists(char *buf)
+{
+   struct zonelist *zonelist;
+   unsigned int node;
+   ssize_t count = 0;
+
+   for_each_online_node(node) {
+   zonelist = &(NODE_DATA(node)->
+   node_zonelists[ZONELIST_FALLBACK]);
+   count += sprintf(buf + count, "[NODE (

[GIT PULL] Thermal management updates for v4.8-rc6

[Zhang Rui]

Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git for-rc

to receive the latest Thermal Management updates for v4.8-rc6 with
top-most commit 87260d3f7aecba9a5fadc6886c338b2a8fccfca9:

  thermal: rcar_thermal: Fix priv->zone error handling (2016-09-06
20:46:06 +0800)

on top of commit c6935931c1894ff857616ff8549b61236a19148f:

  Linux 4.8-rc5 (2016-09-04 14:31:46 -0700)

Specifics:
We have only one patch this time, which fixes a crash in rcar_thermal
driver. From Dirk Behme.

thanks,
rui


Dirk Behme (1):
  thermal: rcar_thermal: Fix priv->zone error handling

 drivers/thermal/rcar_thermal.c | 1 +
 1 file changed, 1 insertion(+)

Re: [PATCH v4] time: alarmtimer: Add the trcepoints for alarmtimer

[Baolin Wang]

Hi Thomas,

On 8 September 2016 at 00:03, Thomas Gleixner  wrote:
> On Tue, 6 Sep 2016, John Stultz wrote:
>> > Changes since v3:
>> >  - Fix the build error on S390.
>>
>> Since the original change is already applied to tip/timers/core, can
>> you provide an incremental patch (a patch against tip/timers/core)
>> that fixes the issue, rather then resending the entire patch?
>
> I zapped it from timers/core as it was the top commit. So we can redo it
> completely, but we can do it incremental as well. Whatever you prefer.

I've send out one incremental patch to fix this issue[1]. Thanks.

[1] https://lkml.org/lkml/2016/9/7/828

-- 
Baolin.wang
Best Regards

[PATCH v2] rtc: Add some dummy static inline functions

[Baolin Wang]

The patch (commit id: a0a6e06d545a753740c9d8d5ce2c4fdd3ab1c021) adding
tracepoints for alarmtimers will build failed on S390 platform, due to
S390 defconfig did not define CONFIG_RTC_LIB macro to define the
rtc_ktime_to_tm() function which is used in this patch. Thus we should
add dummy static inline functions in case CONFIG_RTC_LIB is not defined.

Signed-off-by: Baolin Wang 
Fixes: a0a6e06d545a ("time: alarmtimer: Add tracepoints for alarmtimers")
---
Changes since v1:
 - Modify the commit log.
---
 include/linux/rtc.h |   49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index b693ada..521f752 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -16,13 +16,60 @@
 #include 
 #include 
 
+#ifdef CONFIG_RTC_LIB
 extern int rtc_month_days(unsigned int month, unsigned int year);
-extern int rtc_year_days(unsigned int day, unsigned int month, unsigned int 
year);
+extern int rtc_year_days(unsigned int day, unsigned int month,
+unsigned int year);
 extern int rtc_valid_tm(struct rtc_time *tm);
 extern time64_t rtc_tm_to_time64(struct rtc_time *tm);
 extern void rtc_time64_to_tm(time64_t time, struct rtc_time *tm);
 ktime_t rtc_tm_to_ktime(struct rtc_time tm);
 struct rtc_time rtc_ktime_to_tm(ktime_t kt);
+#else
+static inline int rtc_month_days(unsigned int month, unsigned int year)
+{
+   return 0;
+}
+
+static inline int rtc_year_days(unsigned int day, unsigned int month,
+   unsigned int year)
+{
+   return 0;
+}
+
+static inline int rtc_valid_tm(struct rtc_time *tm)
+{
+   return 0;
+}
+
+static inline time64_t rtc_tm_to_time64(struct rtc_time *tm)
+{
+   time64_t ret;
+
+   memset(&ret, 0, sizeof(time64_t));
+   return ret;
+}
+
+static inline void rtc_time64_to_tm(time64_t time, struct rtc_time *tm)
+{
+}
+
+static inline ktime_t rtc_tm_to_ktime(struct rtc_time tm)
+{
+   ktime_t ret;
+
+   memset(&ret, 0, sizeof(ktime_t));
+   return ret;
+}
+
+static inline struct rtc_time rtc_ktime_to_tm(ktime_t kt)
+{
+   struct rtc_time ret;
+
+   memset(&ret, 0, sizeof(struct rtc_time));
+   return ret;
+}
+#endif
 
 /*
  * rtc_tm_sub - Return the difference in seconds.
-- 
1.7.9.5

[PATCH v5 3/3] usb: dwc2: Properly account for the force mode delays

[John Youn]

When a force mode bit is set and the IDDIG debounce filter is enabled,
there is a delay for the forced mode to take effect. This delay is due
to the IDDIG debounce filter and is variable depending on the platform's
PHY clock speed. To account for this delay we can poll for the expected
mode.

On a clear force mode, since we don't know what mode to poll for, delay
for a fixed 100 ms. This is the maximum delay based on the slowest PHY
clock speed.

Tested-by: Stefan Wahren 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/core.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index a3068e0..fa9b26b 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -395,9 +395,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
  * Checks are done in this function to determine whether doing a force
  * would be valid or not.
  *
- * If a force is done, it requires a 25ms delay to take effect.
- *
- * Returns true if the mode was forced.
+ * If a force is done, it requires a IDDIG debounce filter delay if
+ * the filter is configured and enabled. We poll the current mode of
+ * the controller to account for this delay.
  */
 static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
 {
@@ -432,12 +432,18 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, 
bool host)
gusbcfg |= set;
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
 
-   msleep(25);
+   dwc2_wait_for_mode(hsotg, host);
return true;
 }
 
-/*
- * Clears the force mode bits.
+/**
+ * dwc2_clear_force_mode() - Clears the force mode bits.
+ *
+ * After clearing the bits, wait up to 100 ms to account for any
+ * potential IDDIG filter delay. We can't know if we expect this delay
+ * or not because the value of the connector ID status is affected by
+ * the force mode. We only need to call this once during probe if
+ * dr_mode == OTG.
  */
 static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
 {
@@ -448,11 +454,8 @@ static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
 
-   /*
-* NOTE: This long sleep is _very_ important, otherwise the core will
-* not stay in host mode after a connector ID change!
-*/
-   msleep(25);
+   if (dwc2_iddig_filter_enabled(hsotg))
+   usleep_range(10, 11);
 }
 
 /*
@@ -475,12 +478,6 @@ void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg)
 __func__, hsotg->dr_mode);
break;
}
-
-   /*
-* NOTE: This is required for some rockchip soc based
-* platforms.
-*/
-   msleep(50);
 }
 
 /*
-- 
2.9.0

[PATCH v5 0/3] usb: dwc2: Fix core reset and force mode delays

[John Youn]

This series accounts for the delay from the IDDIG debounce filter when
switching modes. This delay is a function of the PHY clock speed and
can range from 5-50 ms. This delay must be taken into account on core
reset and force modes. A full explanation is provided in the patch
commit log and code comments.

This revision of the series increases the IDDIG delay to 100 ms. Some
rockchip platforms seem to timeout even with 50 ms so I have doubled
this.

Appreciate any testing on RK3188 platforms.

v5:
* Added Stefan Wahren's tested-by
* Dropped RFT

v4:
* Increased the IDDIG delay to 110ms.
* Removed tested-by for patch 2 since I have changed the delays.

v3:
* Added tested-bys for patch 1-2
* Fixed an issue where a function was not returning a value
* Dropped patch 4

v2:
* Broke up the last patch of the original series

Regards,
John

John Youn (3):
  usb: dwc2: gadget: Only initialize device if in device mode
  usb: dwc2: Add delay to core soft reset
  usb: dwc2: Properly account for the force mode delays

 drivers/usb/dwc2/core.c   | 126 +++---
 drivers/usb/dwc2/core.h   |   1 +
 drivers/usb/dwc2/gadget.c |   7 ++-
 drivers/usb/dwc2/hw.h |   1 +
 4 files changed, 116 insertions(+), 19 deletions(-)

-- 
2.9.0

[PATCH v5 2/3] usb: dwc2: Add delay to core soft reset

[John Youn]

Add a delay to the core soft reset function to account for the IDDIG
debounce filter.

If the current mode is host, either due to the force mode bit being
set (which persists after core reset) or the connector id pin, a core
soft reset will temporarily reset the mode to device and a delay from
the IDDIG debounce filter will occur before going back to host mode.

Tested-by: Stefan Wahren 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/core.c | 95 +
 drivers/usb/dwc2/core.h |  1 +
 drivers/usb/dwc2/hw.h   |  1 +
 3 files changed, 97 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 4135a5f..a3068e0 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -238,6 +238,77 @@ int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg)
return ret;
 }
 
+/**
+ * dwc2_wait_for_mode() - Waits for the controller mode.
+ * @hsotg: Programming view of the DWC_otg controller.
+ * @host_mode: If true, waits for host mode, otherwise device mode.
+ */
+static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
+  bool host_mode)
+{
+   ktime_t start;
+   ktime_t end;
+   unsigned int timeout = 110;
+
+   dev_vdbg(hsotg->dev, "Waiting for %s mode\n",
+host_mode ? "host" : "device");
+
+   start = ktime_get();
+
+   while (1) {
+   s64 ms;
+
+   if (dwc2_is_host_mode(hsotg) == host_mode) {
+   dev_vdbg(hsotg->dev, "%s mode set\n",
+host_mode ? "Host" : "Device");
+   break;
+   }
+
+   end = ktime_get();
+   ms = ktime_to_ms(ktime_sub(end, start));
+
+   if (ms >= (s64)timeout) {
+   dev_warn(hsotg->dev, "%s: Couldn't set %s mode\n",
+__func__, host_mode ? "host" : "device");
+   break;
+   }
+
+   usleep_range(1000, 2000);
+   }
+}
+
+/**
+ * dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
+ * filter is enabled.
+ */
+static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
+{
+   u32 gsnpsid;
+   u32 ghwcfg4;
+
+   if (!dwc2_hw_is_otg(hsotg))
+   return false;
+
+   /* Check if core configuration includes the IDDIG filter. */
+   ghwcfg4 = dwc2_readl(hsotg->regs + GHWCFG4);
+   if (!(ghwcfg4 & GHWCFG4_IDDIG_FILT_EN))
+   return false;
+
+   /*
+* Check if the IDDIG debounce filter is bypassed. Available
+* in core version >= 3.10a.
+*/
+   gsnpsid = dwc2_readl(hsotg->regs + GSNPSID);
+   if (gsnpsid >= DWC2_CORE_REV_3_10a) {
+   u32 gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+
+   if (gotgctl & GOTGCTL_DBNCE_FLTR_BYPASS)
+   return false;
+   }
+
+   return true;
+}
+
 /*
  * Do core a soft reset of the core.  Be careful with this because it
  * resets all the internal state machines of the core.
@@ -246,9 +317,30 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 {
u32 greset;
int count = 0;
+   bool wait_for_host_mode = false;
 
dev_vdbg(hsotg->dev, "%s()\n", __func__);
 
+   /*
+* If the current mode is host, either due to the force mode
+* bit being set (which persists after core reset) or the
+* connector id pin, a core soft reset will temporarily reset
+* the mode to device. A delay from the IDDIG debounce filter
+* will occur before going back to host mode.
+*
+* Determine whether we will go back into host mode after a
+* reset and account for this delay after the reset.
+*/
+   if (dwc2_iddig_filter_enabled(hsotg)) {
+   u32 gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+   u32 gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+
+   if (!(gotgctl & GOTGCTL_CONID_B) ||
+   (gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+   wait_for_host_mode = true;
+   }
+   }
+
/* Core Soft Reset */
greset = dwc2_readl(hsotg->regs + GRSTCTL);
greset |= GRSTCTL_CSFTRST;
@@ -277,6 +369,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
 
+   if (wait_for_host_mode)
+   dwc2_wait_for_mode(hsotg, true);
+
return 0;
 }
 
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 78526ee..466c220 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -882,6 +882,7 @@ struct dwc2_hsotg {
 #define DWC2_CORE_REV_2_92a0x4f54292a
 #define DWC2_CORE_REV_2_94a0x4f54294a
 #define DWC2_CORE_REV_3_00a0x4f54300a
+#define DWC2_CORE_REV_3_10a0x4f54310a
 
 #if IS_ENABLED(CONFIG_USB_DWC2_HOST) || IS_ENABLED(CONFIG_USB_DWC2_DUAL_ROLE)
union dwc2_hcd_intern

[PATCH v5 1/3] usb: dwc2: gadget: Only initialize device if in device mode

[John Youn]

In dwc2_hsotg_udc_start(), don't initialize the controller for device
mode unless we are actually in device mode.

Tested-by: Heiko Stuebner 
Tested-by: Stefan Wahren 
Signed-off-by: John Youn 
---
 drivers/usb/dwc2/gadget.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 94bd19a..4cd6403 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3466,8 +3466,11 @@ static int dwc2_hsotg_udc_start(struct usb_gadget 
*gadget,
otg_set_peripheral(hsotg->uphy->otg, &hsotg->gadget);
 
spin_lock_irqsave(&hsotg->lock, flags);
-   dwc2_hsotg_init(hsotg);
-   dwc2_hsotg_core_init_disconnected(hsotg, false);
+   if (dwc2_hw_is_device(hsotg)) {
+   dwc2_hsotg_init(hsotg);
+   dwc2_hsotg_core_init_disconnected(hsotg, false);
+   }
+
hsotg->enabled = 0;
spin_unlock_irqrestore(&hsotg->lock, flags);
 
-- 
2.9.0

Re: [RFC] zram: support page-based parallel write

[Minchan Kim]

Hello,

On Tue, Sep 06, 2016 at 10:22:20AM +0200, Andreas Mohr wrote:
> On Tue, Sep 06, 2016 at 04:24:17PM +0900, Minchan Kim wrote:
> > @@ -1464,6 +1908,9 @@ static int __init zram_init(void)
> > num_devices--;
> > }
> >  
> > +   if (create_workers())
> > +   goto out_error;
> > +
> > return 0;
> >  
> >  out_error:
> > @@ -1474,6 +1921,7 @@ static int __init zram_init(void)
> >  static void __exit zram_exit(void)
> >  {
> > destroy_devices();
> > +   destroy_workers();
> >  }
> 
> 
> Asymmetry --> "BUG".
> 
> ...right?

destory_workers checks workers list so if it's empty, it doesn
nothing. Anyway, I am chaning thread management model now so
it should be changed, too. :)

> 
> (I have to admit that current implementation structure
> is not easy to follow,
> thus I'm not fully sure)
> 
> 
> Thanks for working in this important area!

Thanks for the interest.

Re: [PATCH 1/7] [v2] dt-bindings: fsl: updates bindings for some SoC-specific devices

[Shawn Guo]

On Mon, Sep 05, 2016 at 06:01:29PM +0800, shh@gmail.com wrote:
> From: Shaohui Xie 
> 
> SCFG and DCFG are SoC-specific devices can be found on SoCs like LS1021A,
> LS1043A and LS1046A, this patch updates bindings for SCFG and DCFG to
> reflect more SoCs.
> 
> Signed-off-by: Shaohui Xie 
> ---
> changes in V2:
> new patch.
> 
>  Documentation/devicetree/bindings/arm/fsl.txt | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/fsl.txt 
> b/Documentation/devicetree/bindings/arm/fsl.txt
> index dbbc095..6f92d0b 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.txt
> +++ b/Documentation/devicetree/bindings/arm/fsl.txt
> @@ -97,7 +97,7 @@ Freescale LS1021A Platform Device Tree Bindings
>  Required root node compatible properties:
>- compatible = "fsl,ls1021a";
>  
> -Freescale LS1021A SoC-specific Device Tree Bindings
> +Freescale SoC-specific Device Tree Bindings
>  ---
>  
>  Freescale SCFG
> @@ -105,7 +105,10 @@ Freescale SCFG
>  configuration and status registers for the chip. Such as getting PEX port
>  status.
>Required properties:
> -  - compatible: should be "fsl,ls1021a-scfg"
> +  - compatible: Should contain a chip-specific compatible string,
> + Chip-specific strings are of the form "fsl,-scfg", such as:
> + "fsl,ls1021a-scfg"

Per Documentation/devicetree/bindings/submitting-patches.txt, the known
values of "" should be documented.

Shawn

> +
>- reg: should contain base address and length of SCFG memory-mapped 
> registers
>  
>  Example:
> @@ -119,7 +122,10 @@ Freescale DCFG
>  configuration and status for the device. Such as setting the secondary
>  core start address and release the secondary core from holdoff and startup.
>Required properties:
> -  - compatible: should be "fsl,ls1021a-dcfg"
> +  - compatible: Should contain a chip-specific compatible string,
> + Chip-specific strings are of the form "fsl,-dcfg", such as:
> + "fsl,ls1021a-dcfg"
> +
>- reg : should contain base address and length of DCFG memory-mapped 
> registers
>  
>  Example:
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] MAINTAINERS: update my maintainership status of f2fs

[Chao Yu]

Sorry, +Cc f2fs & kernel mailing list.

On 2016/9/8 10:27, Chao Yu wrote:
> Update my maintainership of f2fs to maintainer instead of reviewer.
> 
> Signed-off-by: Chao Yu 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0bbe4b1..97abd05 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5061,7 +5061,7 @@ F:  include/linux/fscrypto.h
>  F2FS FILE SYSTEM
>  M:   Jaegeuk Kim 
>  M:   Changman Lee 
> -R:   Chao Yu 
> +M:   Chao Yu 
>  L:   linux-f2fs-de...@lists.sourceforge.net
>  W:   http://en.wikipedia.org/wiki/F2FS
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
> 

Re: [PATCH] ubifs: compress lines for immediate return

[Richard Weinberger]

Heiko,

On 05.09.2016 08:35, Heiko Schocher wrote:
> I think yes ...
> 
>> Is this part of a tree-wide cleanup?
> 
> Yes, and I thought it is worth to change this part in linux too.

Agreed. Can you please resend with a proper change log and (more important)
a correct sob-chain? From: and first Signed-of-by: should be Masahiro Yamada 

followed by a Signed-of-by: you.

Thanks,
//richard

Re: [PATCH] [media] pci: constify snd_pcm_ops structures

[Andrey Utkin]

Thanks for looking into this.
I have tested that it compiles and passes checks (C=2) cleanly after 
this patch.

Acked-by: Andrey Utkin 

While we're at it, what about constification of
*-core.c:static struct pci_driver *_pci_driver = {
*-video.c:static struct vb2_ops *_video_qops = {
*-video.c:static struct video_device *_video_template = {

in drivers/media/pci/? Also there are even more similar entries not
constified yet in drivers/media/, however I may be underestimating
complexity of making semantic rules for catching that all.

Re: [PATCH] sched/core: simpler function for sched_exec migration

[chengchao]

Oled, thank you for moving this patch on.

on 09/07/2016 08:35 PM, Oleg Nesterov wrote:
> On 09/07, chengchao wrote:
>>
>> Oleg, thank you very much.
>>
>> on 09/06/2016 11:22 PM, Oleg Nesterov wrote:
>>> On 09/06, chengchao wrote:

 the key point is for CONFIG_PREEMPT_NONE=y,
 ...
 it is too much overhead for one task(fork()+exec()), isn't it?
>>>
>>> Yes, yes, I see, this is suboptimal. Not sure we actually do care,
>>> but yes, perhaps another helper which migrates the current task makes
>>> sense, I dunno.
>>
>> for CONFIG_PREEMPT_NONE=y, this patch wants the stopper thread can migrate 
>> the current
>> successfully instead of doing nothing.
> 
> I understand the intent. But I am not sure this optimization makes
> sense.
> 

For CONFIG_PREEMPT_NONE=y, when sched_exec() needs migration, sched_exec() calls
stop_one_cpu(task_cpu(p), migration_cpu_stop, &arg).

If stopper thread can not migrate for us,why should we call stop_one_cpu() 
here? 
It just makes the task TASK_UNINTERRUPTIBLE, wakes up the stopper thread, 
executes the 
migration_cpu_stop, and the stopper thread wakes up the task.

But in fact, all above works are almost unuseful, the reason is that the 
migration_cpu_stop
doesn't migrate for us. why? the migration_cpu_stop() needs the task is 
TASK_ON_RQ_QUEUED 
before it calls __migrate_task().

This patch can make the task TASK_RUNNING instead of TASK_UNINTERRUPTIBLE,
so the migration_cpu_stop() can migrate happily.

Does this optimization make sense now?

Any different opinions are always welcome.

>> int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, void *arg)
>> {
>> struct cpu_stop_done done;
>> struct cpu_stop_work work = { .fn = fn, .arg = arg, .done = &done };
>>
>> cpu_stop_init_done(&done, 1);
>> if (!cpu_stop_queue_work(cpu, &work))
>> return -ENOENT;
>>
>> #if defined(CONFIG_PREEMPT_NONE)
>> /*
>>  * let the stopper thread runs as soon as possible,
>>  * and keep current TASK_RUNNING.
>>  */
>>  scheudle();
>> #endif
>> wait_for_completion(&done.completion);
>> return done.ret;
>> }
> 
> Agreed this looks better, although I'd suggest _cond_resche().
> 
> Again, I am not sure this makes sense, I leave this to maintainers.
> 

You have done much works for this patch. Thanks again. 

> Oleg.
> 
> 

[PATCH] clocksource/fsl: Fix errata A-007728 for flextimer

[Meng Yi]

If the FTM counter reaches the FTM_MOD value between the reading of the
TOF bit and the writing of 0 to the TOF bit, the process of clearing the
TOF bit does not work as expected when FTMx_CONF[NUMTOF] != 0 and the
current TOF count is less than FTMx_CONF[NUMTOF]. If the above condition
is met, the TOF bit remains set. If the TOF interrupt is enabled
(FTMx_SC[TOIE] = 1), the TOF interrupt also remains asserted.

Above is the errata discription

The workaround is clearing TOF bit until it is cleaned(FTM counter doesn't
always reache the FTM_MOD anyway),which may cost some cycles.

Signed-off-by: Meng Yi 
---
 drivers/clocksource/fsl_ftm_timer.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 738515b..ade26e5 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -83,11 +83,10 @@ static inline void ftm_counter_disable(void __iomem *base)
 
 static inline void ftm_irq_acknowledge(void __iomem *base)
 {
-   u32 val;
-
-   val = ftm_readl(base + FTM_SC);
-   val &= ~FTM_SC_TOF;
-   ftm_writel(val, base + FTM_SC);
+   /*read and clean the FTM_SC_TOF bit until its cleared*/
+   while (FTM_SC_TOF & ftm_readl(base + FTM_SC))
+   ftm_writel(ftm_readl(base + FTM_SC) & (~FTM_SC_TOF),
+  base + FTM_SC);
 }
 
 static inline void ftm_irq_enable(void __iomem *base)
-- 
2.1.0.27.g96db324

Re: [PATCH] powernv: Restore SPRs correctly upon wake up from hypervisor state loss

[Shreyas B. Prabhu]

Hi Gautham,

Thanks for fixing this.

On Wed, Sep 7, 2016 at 1:16 AM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> pnv_wakeup_tb_loss function currently expects the cr4 to be "eq" if
> the CPU is waking up from a complete hypervisor state loss. Hence, it
> currently restores the SPR contents only if cr4 is "eq".
>
> However, after the commit bcef83a00dc4 ("powerpc/powernv: Add platform
> support for stop instruction"), on ISA_V300 CPUs, the function
> pnv_restore_hyp_resource sets cr4 to contain the result of the
> comparison between state the CPU has woken up and the first deepest
> stop state before calling pnv_wakeup_tb_loss.
>
> Thus if the CPU woke up from a state that is deeper than the first
> deepest stop state, cr4 have "gt" set and hence, pnv_wakeup_tb_loss
> will fail to restore the SPRs on waking up from such a state.
>
> Fix the code in pnv_wakeup_tb_loss to restore the SPR states when cr4 is
> "eq" or "gt".
>
> Fixes: Commit bcef83a00dc4 ("powerpc/powernv: Add platform support for
> stop instruction")
>
> Cc: Vaidyanathan Srinivasan 
> Cc: Michael Neuling 
> Cc: Michael Ellerman 
> Cc: Shreyas B. Prabhu 
> Signed-off-by: Gautham R. Shenoy 
> ---

Reviewed-by: Shreyas B. Prabhu 


Thanks,
Shreyas