Re: [PATCH 1/2] arm64: kernel: Add SMC Session ID to results

[Bjorn Andersson]

On Fri 19 Aug 22:51 PDT 2016, Andy Gross wrote:

> This patch adds the SMC Session ID to the results passed back from SMC
> calls.  The Qualcomm SMC implementation provides for interrupted SMC
> functions.  When this occurs, the SMC call will return a session ID that
> is required to be used when resuming the interrupted SMC call.
> 
> Signed-off-by: Andy Gross 

This fixes the spurious remoteproc firmware authentication failures I've
seen lately.

Tested-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  arch/arm64/kernel/asm-offsets.c | 1 +
>  arch/arm64/kernel/smccc-call.S  | 1 +
>  include/linux/arm-smccc.h   | 4 +++-
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
> index 05070b7..ff38c58 100644
> --- a/arch/arm64/kernel/asm-offsets.c
> +++ b/arch/arm64/kernel/asm-offsets.c
> @@ -141,6 +141,7 @@ int main(void)
>  #endif
>DEFINE(ARM_SMCCC_RES_X0_OFFS,  offsetof(struct arm_smccc_res, a0));
>DEFINE(ARM_SMCCC_RES_X2_OFFS,  offsetof(struct arm_smccc_res, a2));
> +  DEFINE(ARM_SMCCC_RES_X6_OFFS,  offsetof(struct arm_smccc_res, a6));
>BLANK();
>DEFINE(HIBERN_PBE_ORIG,offsetof(struct pbe, orig_address));
>DEFINE(HIBERN_PBE_ADDR,offsetof(struct pbe, address));
> diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> index ae0496f..278dc9a 100644
> --- a/arch/arm64/kernel/smccc-call.S
> +++ b/arch/arm64/kernel/smccc-call.S
> @@ -20,6 +20,7 @@
>   ldr x4, [sp]
>   stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
>   stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> + str x6, [x4, #ARM_SMCCC_RES_X6_OFFS]
>   ret
>   .cfi_endproc
>   .endm
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index b5abfda..82d919f 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -63,18 +63,20 @@
>  /**
>   * struct arm_smccc_res - Result from SMC/HVC call
>   * @a0-a3 result values from registers 0 to 3
> + * @a6 Session ID register (optional)
>   */
>  struct arm_smccc_res {
>   unsigned long a0;
>   unsigned long a1;
>   unsigned long a2;
>   unsigned long a3;
> + unsigned long a6;
>  };
>  
>  /**
>   * arm_smccc_smc() - make SMC calls
>   * @a0-a7: arguments passed in registers 0 to 7
> - * @res: result values from registers 0 to 3
> + * @res: result values from registers 0 to 3 and optional register 6
>   *
>   * This function is used to make SMC calls following SMC Calling Convention.
>   * The content of the supplied param are copied to registers 0 to 7 prior
> -- 
> 1.9.1
> 

Re: [PATCH 01/10] reset: ath79: add driver Kconfig option

[Masahiro Yamada]

Hi Arnd,


2016-08-25 0:51 GMT+09:00 Arnd Bergmann :
> On Wednesday, August 24, 2016 3:28:53 PM CEST Philipp Zabel wrote:
>>  if RESET_CONTROLLER
>>
>> +config RESET_ATH79
>> +   bool "AR71xx Reset Driver" if COMPILE_TEST
>> +   default ATH79
>> +   help
>> + This enables the ATH79 reset controller driver that supports the
>> + AR71xx SoC reset controller.
>> +
>>
>
> Nice series!
>
> Just note that there is one possible problem with COMPILE_TEST
> when the platforms are enabled, as you can then disable a driver
> that is normally there, and that can in turn cause problems in
> rare cases, e.g. when the driver has a global function that is
> called from platform code. I don't know if any of the drivers
> do that, but if they do, you'd have to use
>
> config RESET_ATH79
>bool "AR71xx Reset Driver" if COMPILE_TEST && !ATH79
>default ATH79
>
> to ensure that it's impossible to disable the driver on platforms
> that require it.

Hmm,
Can we do this only when we really have to do so?
I think we should not care about such a rare case that may not happen.

Let's start with only "if COMPILE_TEST",
and take a look at it if a build error is detected.

Anyway, depending on platform code is a sign of weird implementation.

It might be better to find a potential issue rather than hide it.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] MAINTAINERS: add linux-su...@googlegroups.com as list for sunxi arch

[Maxime Ripard]

Hi,

On Thu, Aug 18, 2016 at 02:14:17PM +0200, LABBE Corentin wrote:
> All discutions about sunxi architecture is done
> on linux-su...@googlegroups.com.
> This patch add it as list on drivers for this arch.
> 
> Signed-off-by: LABBE Corentin 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a306795..6254eb1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -980,6 +980,7 @@ ARM/Allwinner sunXi SoC support
>  M:   Maxime Ripard 
>  M:   Chen-Yu Tsai 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
> +L:   linux-su...@googlegroups.com

I don't want a mailing list hosted on google groups to be added to
MAINTAINERS.

We can ask for one on kernel.org though if people feel like it's
relevant. Nobody cared for a few years, so I guess it would be a no,
but if others feel like it...

Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH 04/11] sched,x86: Enable Turbo Boost Max Technology

[Peter Zijlstra]

On Wed, Aug 24, 2016 at 08:08:54PM +0200, Ingo Molnar wrote:
> > 
> > So if we take the approach to enable this feature by default for only
> > single node system (using that as a criteria for client), will that seem
> > reasonable to you?
> 
> I suppose that would work. Peter, any objections to such an approach?

Works for me.

Thanks!

Re: [PATCH] ARM: EXYNOS: Clear OF_POPULATED flag from PMU node in IRQ init callback

[Krzysztof Kozlowski]

On Wed, Aug 24, 2016 at 12:57:29PM -0500, Rob Herring wrote:
> On Wed, Aug 24, 2016 at 12:44 PM, Krzysztof Kozlowski  wrote:
> > On Sun, Aug 21, 2016 at 03:27:45AM -0400, Javier Martinez Canillas wrote:
> >> The Exynos PMU node is an interrupt, clock and PMU (Power Management Unit)
> >> controller, and these functionalities are supported by different drivers
> >> that matches the same compatible strings.
> >>
> >> Since commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers
> >> as populated") the OF core flags interrupt controllers registered with the
> >> IRQCHIP_DECLARE() macro as OF_POPULATED, so platform devices with the same
> >> compatible string as the interrupt controller will not be registered.
> >>
> >> This prevents the PMU platform device to be registered so the Exynos PMU
> >> driver is never probed. This breaks (among other things) Suspend-to-RAM.
> >>
> >> Fix this by clearing the OF_POPULATED flag in the PMU IRQ init callback,
> >> to allow the Exynos PMU platform driver to be probed. The patch is based
> >> on Philipp Zabel's "ARM: imx6: mark GPC node as not populated after irq
> >> init to probe pm domain driver".
> >>
> >> Fixes: 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt controllers as 
> >> populated")
> >> Signed-off-by: Javier Martinez Canillas 
> >>
> >> ---
> >>
> >> This was tested on an Exynos5800 Peach Pi Chromebook with v4.8-rc2 +
> >> Philipp's patch: https://patchwork.kernel.org/patch/9271361/
> >>
> >>  arch/arm/mach-exynos/suspend.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> >>
> >> diff --git a/arch/arm/mach-exynos/suspend.c 
> >> b/arch/arm/mach-exynos/suspend.c
> >> index 3750575c73c5..06332f626565 100644
> >> --- a/arch/arm/mach-exynos/suspend.c
> >> +++ b/arch/arm/mach-exynos/suspend.c
> >> @@ -255,6 +255,12 @@ static int __init exynos_pmu_irq_init(struct 
> >> device_node *node,
> >>   return -ENOMEM;
> >>   }
> >>
> >> + /*
> >> +  * Clear the OF_POPULATED flag set in of_irq_init so that
> >> +  * later the Exynos PMU platform device won't be skipped.
> >> +  */
> >> + of_node_clear_flag(node, OF_POPULATED);
> >> +
> >
> > Looks like a proper workaround (at least till of_irq_init sets this flag
> > before calling irq_init_cb()) however I have some more doubts:
> >
> > 1. The commit 15cc2ed6dcf9 ("of/irq: Mark initialised interrupt
> > controllers as populated") might be also applied to clock CLK_OF_DECLARE
> > and the problem will appear again.
> 
> We now know what to look for...

D'oh!

If you gonna apply this to clock providers, please let us know (or apply
workaround to drivers/clk/samsung/clk-exynos-clkout.c).

> 
> > 2. We are reusing PMU compatible for irqcip, clock provider and a
> > platform driver. This is one PMU block with many features thus many
> > drivers were created. What happens if the Exynos platform driver
> > (drivers/soc/samsung/exynos-pmu.c) binds before irqchip or clk provider?
> 
> It can't. OF_DECLARE calls happen before initcalls*.
> 
> *I did find that IOMMU's are during initcalls which in my opinion is
> wrong. But I think there is some plan to fix them to support deferred
> probe and that should go away.
> 
> > Probably we should not reuse the compatible but create a new one for
> > each type of driver? How does it match DeviceTree?
> 
> No, compatible strings are for h/w blocks, not drivers. Now, if you
> need multiple platform drivers, then you should have 1 parent
> device/driver that's bound from DT, then it can create any child
> devices for specific functions.

Thanks for explanation.

For the Javier's patch itself, applied.

Best regards,
Krzysztof

Re: [PATCH v2] perf/x86/amd: Make HW_CACHE_REFERENCES and HW_CACHE_MISSES measure L2

[Peter Zijlstra]

On Wed, Aug 24, 2016 at 04:55:14PM +0200, Borislav Petkov wrote:
> On Wed, Aug 24, 2016 at 02:12:08PM +0100, Matt Fleming wrote:
> > While the Intel PMU monitors the LLC when perf enables the
> > HW_CACHE_REFERENCES and HW_CACHE_MISSES events, these events monitor
> > L1 instruction cache fetches (0x0080) and instruction cache misses
> > (0x0081) on the AMD PMU.
> > 
> > This is extremely confusing when monitoring the same workload across
> > Intel and AMD machines, since parameters like,
> > 
> >   $ perf stat -e cache-references,cache-misses
> > 
> > measure completely different things.
> > 
> > Instead, make the AMD PMU measure instruction/data cache and TLB fill
> > requests to the L2 and instruction/data cache and TLB misses in the L2
> > when HW_CACHE_REFERENCES and HW_CACHE_MISSES are enabled,
> > respectively. That way the events measure unified caches on both
> > platforms.
> 
> I'm still not really sure about this: we can't really compare L3 to L2
> access patterns - it is almost as comparing apples to oranges. Can we
> use the Intel L2 events instead?

They're not meant to be comparable between machines. I wouldn't even
compare the LLC numbers between two different Intel parts.

These events are meant to profile a workload on the machine you run them
on. Big cache-miss/ref ratios indicate you loose performance because of
the memory subsystem and or data structure layout.

And afaict AMD parts, even those that have L3, cannot provide L3 numbers
on a per task basis, so these L2 numbers are the best we have.

Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces

[Lennart Sorensen]

On Wed, Aug 24, 2016 at 08:14:44PM +0200, Thomas Petazzoni wrote:
> Depends on the network driver I believe. But with an e1000e NIC plugged
> in a PCIe slot, it indeed gets assigned as eth0, and the internal
> mvneta devices get eth1, eth2, etc.

Which of course means the change does not actually ensure the port
ordering matches the marvell documentation or u-boot.  It only handles
the relative order of the ports.  For now.

So since it doesn't actually work, maybe reverting it so it no longer
violates the dtb ordeting rule makes sense.

Doesn't mean openwrt/lede/etc don't have to deal with the ordering in
the future if async probing takes off.

-- 
Len Sorensen

Partnership Cooperation

[Sheikh Maktoum Hasher Al Maktoum]

Dear Friend,

Your contact details came to me by recommendation, I am interested in investing 
in your country and I believe you have the capabilities of providing the needed 
assistance, solutions and advise in actualizing this, Let me know if you are 
willing to understake this task for me so we can discuss more. I hope to hear 
from you soon.

Regards,
Sheikh Maktoum Hasher Al Maktoum
Chairman/Chief Executive Officer
Dubai International Holding Company.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[PATCH] clk: rockchip: mark aclk_emmc_noc as a critical clock on rk3399

[Douglas Anderson]

From: Xing Zheng 

We don't have code to handle any of the noc clocks in rk3399 and they're
all just listed as critical clocks.  Let's do the same for
aclk_emmc_noc.

Without this clock being marked as critical we have problems around
suspend/resume after commit 20c389e656a8 ("clk: rockchip: fix incorrect
aclk_emmc source gate bits on rk3399").  Before that change we were
presumably not actually gating any of these clocks because we were
setting the wrong gate.

Signed-off-by: Xing Zheng 
Signed-off-by: Douglas Anderson 
---
 drivers/clk/rockchip/clk-rk3399.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
index e445cd64952a..ede6c475b537 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -1489,6 +1489,7 @@ static const char *const rk3399_cru_critical_clocks[] 
__initconst = {
"hclk_perilp1",
"hclk_perilp1_noc",
"aclk_dmac0_perilp",
+   "aclk_emmc_noc",
"gpll_hclk_perilp1_src",
"gpll_aclk_perilp0_src",
"gpll_aclk_perihp_src",
-- 
2.8.0.rc3.226.g39d4020

[PATCH v2 0/2] KVM: s390: Fine-tuning for kvm_s390_import_bp_data()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 24 Aug 2016 20:20:02 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Improve determination of sizes
  Use memdup_user() rather than duplicating code

 arch/s390/kvm/guestdbg.c | 31 +--
 1 file changed, 13 insertions(+), 18 deletions(-)

-- 
2.9.3

Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful

[Linus Torvalds]

On Wed, Aug 24, 2016 at 2:22 PM, Peter Zijlstra  wrote:
>
> I actively disable KASLR on my dev box and feed these hex numbers into
> addr2line -ie vmlinux to find where in the function we are.
>
> Having the option to make %pB generate them works for me.

Yeah, considering that this is the only place this is used, changing
%pB sounds quite reasonable.

We could perhaps make %pB show the hex numbers and address (so pB
would expand to "[] symbolname".if

 (a) not randomizing (so the hex numbers _may_ be useful)

 (b) kptr_restrict is 0 (so the hex numbers are "safe" in the dmesg)

and fall back to just the symbolic name if either of those aren't true?

And obviously, if KALLSYMS isn't enabled, you always show hex
numbers.. That's already the case (but we might want to add the "[<>}'
markers around the hex numbers just to make the user space automation
we do have work).

Linus

Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces

[Thomas Petazzoni]

Hello,

On Wed, 24 Aug 2016 19:10:04 +0200, Ralph Sennhauser wrote:

> Going forward, as we disagree and it's basically a political decision,
> whom do we ask to rule here? Linus?

I don't think Linus will care about random issues on a random
platform :-)

The people who can take this decision are rather the maintainers of the
platform itself, or possibly the arm-soc maintainers if you still don't
like what the platform maintainers decided.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only

[Scott Branden]

Hi Bjorn,

Ray is off this week and will likely have some comments next week.

On 16-08-24 10:54 AM, Bjorn Helgaas wrote:

[+cc Ray, Scott, Jon, bcm-kernel-feedback-list]

On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote:

On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas  wrote:

On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote:

Altera PCIe IP can be configured as rootport or device and they might have
same vendor ID. It will cause the system hang issue if Altera PCIe is in
endpoint mode and work with other PCIe rootport that from other vendors.
So, add the rootport mode checking in link retrain fixup function.

Signed-off-by: Ley Foon Tan 
---
v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT
---
 drivers/pci/host/pcie-altera.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index 58eef99..33b6968 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev)
  u16 linkcap, linkstat;
  struct altera_pcie *pcie = dev->bus->sysdata;

+ if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
+ return;
+
  if (!altera_pcie_link_is_up(pcie))
  return;


Instead of making this a PCI fixup, can you make an
altera_pcie_host_init() function, call it from altera_pcie_probe(),
and do the link retrain there?  Then you wouldn't need to worry about
whether this is a Root Port or an Endpoint, plus it would make the
altera driver structure more like the other drivers.

You would call altera_pcie_host_init() before pci_scan_root_bus(), so
you wouldn't have a pci_dev yet, so you wouldn't be able to use
pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit.  But I
assume there's some device-dependent way to access it using
cra_writel()?

We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit.


Why not?  I don't mean it has to be cra_write(), but isn't there some
way you can write that bit before we scan the root bus?  It doesn't
make sense that we have to scan the bus before we can train the link.

We want to be able to tell the PCI core "all the device-specific root
complex initialization has been done, here are the config accessors
you need, please scan for devices."  I want to keep device-specific
things like this quirk directly in the driver and out of the
enumeration process.


We can use
pci_bus_find_capability() and pci_bus_read_config_word() with struct
pci_bus instead.
But this only can be called after pci_scan_root_bus().



Found
iproc_pcie_check_link() have similar implementation.


You're right, and I don't like iproc_pcie_check_link() either, for the
same reasons.

The iproc_pcie_check_link() is a little better because it's called
before enumeration:

  pci_create_root_bus()
  iproc_pcie_check_link()
  pci_scan_child_bus()

But it would be a lot better if iproc_pcie_check_link() were done
first, before pci_create_root_bus().  Then it would be more like the
structure of other drivers, and we could use pci_scan_root_bus()
instead.

Comments, iproc folks?

Bjorn



Regards,
 Scott

Re: [RFC PATCH-tip v4 10/10] locking/rwsem: Add a boot parameter to reader spinning threshold

[Waiman Long]

On 08/24/2016 12:00 AM, Davidlohr Bueso wrote:

On Thu, 18 Aug 2016, Waiman Long wrote:


The default reader spining threshold is current set to 4096. However,
the right reader spinning threshold may vary from one system to
another and among the different architectures. This patch adds a new
kernel boot parameter to modify the threshold value. This enables
better tailoring to the needs of different systems as well as for
testing purposes.


It also means that those systems could very easily be incorrectly 
tailored.

(and worse case scenario: reboot, is obviously a terrible way to get rid
of any issues). I very much disagree with exposing this sort of core 
stuff,

it should work well for everyone out of the box, not relying on users to
properly configure this.

Thanks,
Davidlohr


I also have some concern about exposing this kernel parameter as it will 
be hard to tune. That is why I put it at the end to gauge the opinion of 
others. I will leave this out when I send out the next version.


Cheers,
Longman

[PATCH 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

[Lafcadio Wluiki]

This adds a new per-task hidepid= flag that is honored by procfs when
presenting /proc to the user, in addition to the existing hidepid= mount
option. So far, hidepid= was exclusively a per-pidns setting. Locking
down a set of processes so that they cannot see other user's processes
without affecting the rest of the system thus currently requires
creation of a private PID namespace, with all the complexity it brings,
including maintaining a stub init process as PID 1 and losing the
ability to see processes of the same user on the rest of the system.

With this patch all acesss and visibility checks in procfs now
honour two fields:

a) the existing hide_pid field in the PID namespace
b) the new hide_pid in struct task_struct

Access/visibility is only granted if both fields permit it; the more
restrictive one wins. By default the new task_struct hide_pid value
defaults to 0, which means behaviour is not changed from the status quo.

Setting the per-process hide_pid value is done via a new PR_SET_HIDEPID
prctl() option which takes the same three supported values as the
hidepid= mount option. The per-process hide_pid may only be increased,
never decreased, thus ensuring that once applied, processes can never
escape such a hide_pid jail.  When a process forks it inherits its
parent's hide_pid value.

Suggested usecase: let's say nginx runs as user "www-data". After
dropping privileges it may now call:

…
prctl(PR_SET_HIDEPID, 2);
…

And from that point on neither nginx itself, nor any of its child
processes may see processes in /proc anymore that belong to a different
user than "www-data". Other services running on the same system remain
unaffected.

This should permit Linux distributions to more comprehensively lock down
their services, as it allows an isolated opt-in for hidepid= for
specific services. Previously hidepid= could only be set system-wide,
and then specific services had to be excluded by group membership,
essentially a more complex concept of opt-out.

Signed-off-by: Lafcadio Wluiki 
---
 fs/proc/array.c|  4 
 fs/proc/base.c |  6 --
 include/linux/init_task.h  |  1 +
 include/linux/sched.h  |  1 +
 include/uapi/linux/prctl.h |  4 
 kernel/fork.c  |  1 +
 kernel/sys.c   | 10 ++
 7 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 88c7de1..a0c1151 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -163,6 +163,7 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
const struct cred *cred;
pid_t ppid, tpid = 0, tgid, ngid;
unsigned int max_fds = 0;
+   int hide_pid;
 
rcu_read_lock();
ppid = pid_alive(p) ?
@@ -183,6 +184,7 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
task_lock(p);
if (p->files)
max_fds = files_fdtable(p->files)->max_fds;
+   hide_pid = p->hide_pid;
task_unlock(p);
rcu_read_unlock();
 
@@ -195,6 +197,7 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
"TracerPid:\t%d\n"
"Uid:\t%d\t%d\t%d\t%d\n"
"Gid:\t%d\t%d\t%d\t%d\n"
+   "HidePID:\t%i\n"
"FDSize:\t%d\nGroups:\t",
get_task_state(p),
tgid, ngid, pid_nr_ns(pid, ns), ppid, tpid,
@@ -206,6 +209,7 @@ static inline void task_state(struct seq_file *m, struct 
pid_namespace *ns,
from_kgid_munged(user_ns, cred->egid),
from_kgid_munged(user_ns, cred->sgid),
from_kgid_munged(user_ns, cred->fsgid),
+   hide_pid,
max_fds);
 
group_info = cred->group_info;
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 308e9a5..b24675f 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -726,7 +726,8 @@ static bool has_pid_permissions(struct pid_namespace *pid,
 struct task_struct *task,
 int hide_pid_min)
 {
-   if (pid->hide_pid < hide_pid_min)
+   if (pid->hide_pid < hide_pid_min &&
+   current->hide_pid < hide_pid_min)
return true;
if (in_group_p(pid->pid_gid))
return true;
@@ -747,7 +748,8 @@ static int proc_pid_permission(struct inode *inode, int 
mask)
put_task_struct(task);
 
if (!has_perms) {
-   if (pid->hide_pid == HIDEPID_INVISIBLE) {
+   if (pid->hide_pid == HIDEPID_INVISIBLE ||
+   current->hide_pid == HIDEPID_INVISIBLE) {
/*
 * Let's make getdents(), stat(), and open()
 * consistent with each other.  If a process
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index f8834f8..abd7a52 100644
--- a/include/linux/init_task.h
+++ 

Re: [Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

[David Vrabel]

On 03/08/16 18:22, Boris Ostrovsky wrote:
> Original version of that patch (commit a89941816726) had to be reverted
> due to Xen allocating irqs in its cpu_up ops.
> 
> The first patch moves allocations into hotplug notifiers and the second
> one restores the original patch (with minor adjustments to new hotplug
> framework)
> 
> This originally went through tip tree but after a couple of failures
> reportedby kbuild robot (due to various combinations of CONFIG_SMP and
> CONFIG_XEN_PVH) I decided to take it through Xen tree (with config problems
> hopefully finally fixed).

Applied to for-linus-4.9, thanks.

David

Re: [PATCH 2/4] firmware: qcom: scm: add iommu scm calls for pg table

[Gupta, Puja]

On 8/19/2016 8:53 AM, Stanimir Varbanov wrote:

Those two scm calls are used to get the size of secure iommu
page table and to pass physical memory address for this page
table. The calls are used by remoteproc venus driver to load
the firmware.
Do we really need these additional scm calls for venus? why can't we 
just reuse existing __qcom_scm_pas_mem_setup() call?

Signed-off-by: Stanimir Varbanov 
---
  drivers/firmware/qcom_scm-64.c | 42 ++
  drivers/firmware/qcom_scm.c| 12 
  drivers/firmware/qcom_scm.h| 11 +++
  include/linux/qcom_scm.h   |  3 +++
  4 files changed, 68 insertions(+)

diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 68484ea2aa51..ffcfbb31ae7a 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -374,3 +374,45 @@ int __qcom_scm_video_set_state(struct device *dev, u32 
state, u32 spare)
  
  	return ret ? : res.a1;

  }
+
+int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
+ size_t *size)
+{
+   struct qcom_scm_desc desc = {0};
+   struct arm_smccc_res res;
+   int ret;
+
+   desc.args[0] = spare;
+   desc.arginfo = QCOM_SCM_ARGS(1);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_MP,
+   QCOM_SCM_IOMMU_SECURE_PTBL_SIZE, , );
+
+   if (size)
+   *size = res.a1;
+
+   return ret ? : res.a2;
+}
+
+int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr, u32 size,
+ u32 spare)
+{
+   struct qcom_scm_desc desc = {0};
+   struct arm_smccc_res res;
+   int ret;
+
+   desc.args[0] = addr;
+   desc.args[1] = size;
+   desc.args[2] = spare;
+   desc.arginfo = QCOM_SCM_ARGS(3, QCOM_SCM_RW, QCOM_SCM_VAL,
+QCOM_SCM_VAL);
+
+   ret = qcom_scm_call(dev, QCOM_SCM_SVC_MP,
+   QCOM_SCM_IOMMU_SECURE_PTBL_INIT, , );
+
+   /* the pg table has been initialized already, ignore the error */
+   if (ret == -EPERM)
+   ret = 0;
+
+   return ret;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 3b0e31c48639..aa77d31b885c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -333,6 +333,18 @@ int qcom_scm_video_set_state(u32 state, u32 spare)
  }
  EXPORT_SYMBOL(qcom_scm_video_set_state);
  
+int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size)

+{
+   return __qcom_scm_iommu_secure_ptbl_size(__scm->dev, spare, size);
+}
+EXPORT_SYMBOL(qcom_scm_iommu_secure_ptbl_size);
+
+int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare)
+{
+   return __qcom_scm_iommu_secure_ptbl_init(__scm->dev, addr, size, spare);
+}
+EXPORT_SYMBOL(qcom_scm_iommu_secure_ptbl_init);
+
  static int qcom_scm_probe(struct platform_device *pdev)
  {
struct qcom_scm *scm;
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 4830559b2639..edeb0038e5fc 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -58,8 +58,17 @@ extern int  __qcom_scm_pas_auth_and_reset(struct device 
*dev, u32 peripheral);
  extern int  __qcom_scm_pas_shutdown(struct device *dev, u32 peripheral);
  extern int  __qcom_scm_pas_mss_reset(struct device *dev, bool reset);
  
+#define QCOM_SCM_SVC_MP			0xc

+#define QCOM_SCM_IOMMU_SECURE_PTBL_SIZE3
+#define QCOM_SCM_IOMMU_SECURE_PTBL_INIT4
+extern int __qcom_scm_iommu_secure_ptbl_size(struct device *dev, u32 spare,
+size_t *size);
+extern int __qcom_scm_iommu_secure_ptbl_init(struct device *dev, u64 addr,
+u32 size, u32 spare);
+
  /* common error codes */
  #define QCOM_SCM_V2_EBUSY -12
+#define QCOM_SCM_NOT_PERMITTED -8
  #define QCOM_SCM_ENOMEM   -5
  #define QCOM_SCM_EOPNOTSUPP   -4
  #define QCOM_SCM_EINVAL_ADDR  -3
@@ -81,6 +90,8 @@ static inline int qcom_scm_remap_error(int err)
return -ENOMEM;
case QCOM_SCM_V2_EBUSY:
return -EBUSY;
+   case QCOM_SCM_NOT_PERMITTED:
+   return -EPERM;
}
return -EINVAL;
  }
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 2ece81a6b078..a8fb98c36cce 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -48,4 +48,7 @@ extern u32 qcom_scm_get_version(void);
  
  extern int qcom_scm_video_set_state(u32 state, u32 spare);
  
+extern int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size);

+extern int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare);
+
  #endif

Puja

Re: [PATCH v2 0/6] Intel Integrated Sensor Hub Support (ISH)

[Srinivas Pandruvada]

On Wed, 2016-08-24 at 12:16 -0400, Grant Likely wrote:
> On Tue, Jul 5, 2016 at 8:42 AM, Grant Likely 
> wrote:
> > 
> > 
> > On 22/06/16 06:40, Srinivas Pandruvada wrote:
> > > 
> > > 
> > > Change log
> > > v2:
> > > - Overview in documentation show analogy with usbhid
> > > implementation
> > > - sparse errors for statics. Also pointed by Jiri
> > > - Clearly marking exported function header file. Clean up all
> > > exports
> > > unused inteface functions
> > > - Changed to tristate from boolean as pointed by Jiri:
> > > this required remove/unload functions
> > > - Prevent crash when ISH enabled on non supported platform
> > > - Break client.c to smaller part by seprating buffer allocations
> > > - move bus register/unregister to ishtp module
> > > - There is only one config symbol INTEL_ISH_HID, removed silent
> > > config for TRANSPORT and IPC
> > 
> > Tested-by: Grant Likely 
> > 
> > On an HP Spectre x360 laptop using v4.7-rc5.
> 
> Hey Srinivas. Any progress on this patch series?
Unless someone has major objection, they can land up in 4.9.
They will go through two different trees, I can ping you once I see all
patches in linux-next.

Thanks,
Srinivas


> 
> g.

Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful

[Josh Poimboeuf]

On Wed, Aug 24, 2016 at 10:28:38AM -0700, Joe Perches wrote:
> On Wed, 2016-08-24 at 11:50 -0500, Josh Poimboeuf wrote:
> > Change printk_stack_address() to be useful when called by an unwinder
> > outside the context of dump_trace().
> > 
> > Specifically:
> > 
> > - printk_stack_address()'s 'data' argument is always used as the log
> >   level string.  Make that explicit.
> 
> If this is true, and I'm not sure it is as I believe
> there are static strings emitted like EOE and IRQ,
> shouldn't this bubble up through the calling tree?
>
> > - Call touch_nmi_watchdog().
> []
> > diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
> []
> > @@ -26,10 +26,11 @@ int kstack_depth_to_print = 3 * STACKSLOTS_PER_LINE;
> >  static int die_counter;
> >  
> >  static void printk_stack_address(unsigned long address, int reliable,
> > -   void *data)
> > +    char *log_lvl)
> >  {
> > +   touch_nmi_watchdog();
> >     printk("%s [<%p>] %s%pB\n",
> > -   (char *)data, (void *)address, reliable ? "" : "? ",
> > +   log_lvl, (void *)address, reliable ? "" : "? ",
> >     (void *)address);
> >  }
> >  
> > @@ -148,7 +149,6 @@ static int print_trace_stack(void *data, char *name)
> >   */
> >  static int print_trace_address(void *data, unsigned long addr, int 
> > reliable)
> >  {
> > -   touch_nmi_watchdog();
> >     printk_stack_address(addr, reliable, data);
> >     return 0;
> >  }
> 
> like for data here?

This function needs to keep its 'void *data' argument because it's a
callback for stacktrace_ops, so it has to conform to the callback
interface.  'data' is used for passing a pointer to an opaque data
structure to the callback.

Also this is the only caller of printk_stack_address(), so there's
nowhere else to bubble it up to.

-- 
Josh

Re: [Regression?] Commit cb4f71c429 deliberately changes order of network interfaces

[Lennart Sorensen]

On Wed, Aug 24, 2016 at 01:10:23PM -0400, Lennart Sorensen wrote:
> Well certainly doing udevtrigger -n -v I see no ethernet devices (but
> lots of other things).  Looking in sysfs it is possible to dereive which
> ethX belongs to which port based on the directory names, but that's
> probably not the most convinient manner to deal with it.

OK, udev DOES work:

# udevadm info -p /sys/class/net/eth0
P: /devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0
E: DEVPATH=/devices/platform/soc/soc:internal-regs/f1034000.ethernet/net/eth0
E: IFINDEX=2
E: INTERFACE=eth0
E: SUBSYSTEM=net

# udevadm info -p /sys/class/net/eth1
P: /devices/platform/soc/soc:internal-regs/f107.ethernet/net/eth1
E: DEVPATH=/devices/platform/soc/soc:internal-regs/f107.ethernet/net/eth1
E: IFINDEX=3
E: INTERFACE=eth1
E: SUBSYSTEM=net

So it isn't hopeless.

-- 
Len Sorensen

[PATCH v2 2/2] KVM: s390: Use memdup_user() rather than duplicating code

[SF Markus Elfring]

From: Markus Elfring <elfr...@users.sourceforge.net>
Date: Wed, 24 Aug 2016 20:10:09 +0200

* Reuse existing functionality from memdup_user() instead of keeping
  duplicate source code.

  This issue was detected by using the Coccinelle software.

* Return directly if this copy operation failed.

Reviewed-by: David Hildenbrand <d...@linux.vnet.ibm.com>
Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
---

v2: Rebased on source files from "Linux next-20160824".

 arch/s390/kvm/guestdbg.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/arch/s390/kvm/guestdbg.c b/arch/s390/kvm/guestdbg.c
index 70b71ac..d7c6a7f 100644
--- a/arch/s390/kvm/guestdbg.c
+++ b/arch/s390/kvm/guestdbg.c
@@ -216,20 +216,10 @@ int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
else if (dbg->arch.nr_hw_bp > MAX_BP_COUNT)
return -EINVAL;
 
-   bp_data = kmalloc_array(dbg->arch.nr_hw_bp,
-   sizeof(*bp_data),
-   GFP_KERNEL);
-   if (!bp_data) {
-   ret = -ENOMEM;
-   goto error;
-   }
-
-   if (copy_from_user(bp_data,
-  dbg->arch.hw_bp,
-  sizeof(*bp_data) * dbg->arch.nr_hw_bp)) {
-   ret = -EFAULT;
-   goto error;
-   }
+   bp_data = memdup_user(dbg->arch.hw_bp,
+ sizeof(*bp_data) * dbg->arch.nr_hw_bp);
+   if (IS_ERR(bp_data))
+   return PTR_ERR(bp_data);
 
for (i = 0; i < dbg->arch.nr_hw_bp; i++) {
switch (bp_data[i].type) {
-- 
2.9.3

[PATCH v2 1/2] KVM: s390: Improve determination of sizes in kvm_s390_import_bp_data()

[SF Markus Elfring]

From: Markus Elfring <elfr...@users.sourceforge.net>
Date: Wed, 24 Aug 2016 19:45:23 +0200

* A multiplication for the size determination of a memory allocation
  indicated that an array data structure should be processed.
  Thus reuse the corresponding function "kmalloc_array".

  Suggested-by: Paolo Bonzini <pbonz...@redhat.com>

  This issue was detected also by using the Coccinelle software.

* Replace the specification of data structures by pointer dereferences
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.

* Delete the local variable "size" which became unnecessary with
  this refactoring.

Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
---

v2: Rebased on source files from "Linux next-20160824".
Advices were integrated from source code review.

 arch/s390/kvm/guestdbg.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/arch/s390/kvm/guestdbg.c b/arch/s390/kvm/guestdbg.c
index d1f8241..70b71ac 100644
--- a/arch/s390/kvm/guestdbg.c
+++ b/arch/s390/kvm/guestdbg.c
@@ -206,7 +206,7 @@ static int __import_wp_info(struct kvm_vcpu *vcpu,
 int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
struct kvm_guest_debug *dbg)
 {
-   int ret = 0, nr_wp = 0, nr_bp = 0, i, size;
+   int ret = 0, nr_wp = 0, nr_bp = 0, i;
struct kvm_hw_breakpoint *bp_data = NULL;
struct kvm_hw_wp_info_arch *wp_info = NULL;
struct kvm_hw_bp_info_arch *bp_info = NULL;
@@ -216,14 +216,17 @@ int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
else if (dbg->arch.nr_hw_bp > MAX_BP_COUNT)
return -EINVAL;
 
-   size = dbg->arch.nr_hw_bp * sizeof(struct kvm_hw_breakpoint);
-   bp_data = kmalloc(size, GFP_KERNEL);
+   bp_data = kmalloc_array(dbg->arch.nr_hw_bp,
+   sizeof(*bp_data),
+   GFP_KERNEL);
if (!bp_data) {
ret = -ENOMEM;
goto error;
}
 
-   if (copy_from_user(bp_data, dbg->arch.hw_bp, size)) {
+   if (copy_from_user(bp_data,
+  dbg->arch.hw_bp,
+  sizeof(*bp_data) * dbg->arch.nr_hw_bp)) {
ret = -EFAULT;
goto error;
}
@@ -241,17 +244,19 @@ int kvm_s390_import_bp_data(struct kvm_vcpu *vcpu,
}
}
 
-   size = nr_wp * sizeof(struct kvm_hw_wp_info_arch);
-   if (size > 0) {
-   wp_info = kmalloc(size, GFP_KERNEL);
+   if (nr_wp > 0) {
+   wp_info = kmalloc_array(nr_wp,
+   sizeof(*wp_info),
+   GFP_KERNEL);
if (!wp_info) {
ret = -ENOMEM;
goto error;
}
}
-   size = nr_bp * sizeof(struct kvm_hw_bp_info_arch);
-   if (size > 0) {
-   bp_info = kmalloc(size, GFP_KERNEL);
+   if (nr_bp > 0) {
+   bp_info = kmalloc_array(nr_bp,
+   sizeof(*bp_info),
+   GFP_KERNEL);
if (!bp_info) {
ret = -ENOMEM;
goto error;
-- 
2.9.3

Re: [PATCH] phy: request shared IRQ

[Sergei Shtylyov]

Hello.

On 08/24/2016 08:53 PM, Xander Huff wrote:


From: Nathan Sullivan 

On hardware with multiple PHY devices hooked up to the same IRQ line, allow
them to share it.


   Note that it had been allowed until my (erroneous?) commit 
33c133cc7598e60976a069344910d63e56cc4401 ("phy: IRQ cannot be shared"), so I'd 
like this commit just reverted instead...
   I'm not sure now what was the reason I concluded that the IRQ sharing was 
impossible... most probably I thought that the kernel IRQ handling code exited 
the loop over the IRQ actions once IRQ_HANDLED was returned -- which is 
obviously not so in reality...



Signed-off-by: Nathan Sullivan 
Signed-off-by: Xander Huff 
Acked-by: Ben Shelton 
Acked-by: Jaeden Amero 

[...]

MBR, Sergei

Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful

[Peter Zijlstra]

On Wed, Aug 24, 2016 at 02:03:58PM -0400, Linus Torvalds wrote:

> 
> For the non-kallsyms case we _could_ also just make the '%pB' format
> add the [<>] markers back in case somebody still uses the user-space
> kallsyms script that looks up hex numbers.
> 
> Right now the hex numbers are not only useless in stack dumps (since
> you can't look up symbols using them anyway thanks to randomization),
> they are noise that makes the stack traces harder to read. So let's
> just remove them?

I actively disable KASLR on my dev box and feed these hex numbers into
addr2line -ie vmlinux to find where in the function we are.

Having the option to make %pB generate them works for me.

Re: [PATCH v4 6/7] arm64: dts: add Pine64 support

[Maxime Ripard]

Hi,

On Mon, Aug 08, 2016 at 06:21:48PM +0100, Andre Przywara wrote:
> The Pine64 is a cost-efficient development board based on the
> Allwinner A64 SoC.
> There are three models: the basic version with Fast Ethernet and
> 512 MB of DRAM (Pine64) and two Pine64+ versions, which both
> feature Gigabit Ethernet and additional connectors for touchscreens
> and a camera. Or as my son put it: "Those are smaller and these are
> missing." ;-)
> The two Pine64+ models just differ in the amount of DRAM
> (1GB vs. 2GB). Since U-Boot will figure out the right size for us and
> patches the DT accordingly we just need to provide one DT for the
> Pine64+.
> 
> [Maxime: Removed the common DTSI and include directly the pine64 DTS]
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm64/boot/dts/Makefile   |  1 +
>  arch/arm64/boot/dts/allwinner/Makefile |  5 ++
>  .../boot/dts/allwinner/sun50i-a64-pine64-plus.dts  | 48 ++
>  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 74 
> ++
>  4 files changed, 128 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/allwinner/Makefile
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
>  create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> 
> diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
> index 6e199c9..ddcbf5a 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -1,4 +1,5 @@
>  dts-dirs += al
> +dts-dirs += allwinner
>  dts-dirs += altera
>  dts-dirs += amd
>  dts-dirs += amlogic
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile 
> b/arch/arm64/boot/dts/allwinner/Makefile
> new file mode 100644
> index 000..1e29a5a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -0,0 +1,5 @@
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +
> +always   := $(dtb-y)
> +subdir-y := $(dts-dirs)
> +clean-files  := *.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> new file mode 100644
> index 000..e369e83
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-plus.dts
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library 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 library 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "sun50i-a64-pine64.dts"
> +
> +/ {
> + model = "Pine64+";
> + compatible = "pine64,pine64-plus", "allwinner,sun50i-a64";
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> new file mode 100644
> index 000..077a56f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -0,0 +1,74 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your 

[PATCH] net: macb: Increase DMA buffer size

[Xander Huff]

From: Nathan Sullivan 

In recent testing with the RT patchset, we have seen cases where the
transmit ring can fill even with up to 200 txbds in the ring.  Increase
the size of the DMA rings to avoid overruns.

Signed-off-by: Nathan Sullivan 
Acked-by: Ben Shelton 
Acked-by: Jaeden Amero 
Natinst-ReviewBoard-ID: 83662
---
 drivers/net/ethernet/cadence/macb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cadence/macb.c 
b/drivers/net/ethernet/cadence/macb.c
index 3256839..86a8e20 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -35,12 +35,12 @@
 
 #include "macb.h"
 
-#define MACB_RX_BUFFER_SIZE128
+#define MACB_RX_BUFFER_SIZE1536
 #define RX_BUFFER_MULTIPLE 64  /* bytes */
 #define RX_RING_SIZE   512 /* must be power of 2 */
 #define RX_RING_BYTES  (sizeof(struct macb_dma_desc) * RX_RING_SIZE)
 
-#define TX_RING_SIZE   128 /* must be power of 2 */
+#define TX_RING_SIZE   512 /* must be power of 2 */
 #define TX_RING_BYTES  (sizeof(struct macb_dma_desc) * TX_RING_SIZE)
 
 /* level of occupied TX descriptors under which we wake up TX process */
-- 
1.9.1

Re: [PATCH v2] mm: memcontrol: avoid unused function warning

[Michal Hocko]

On Wed 24-08-16 12:23:00, Arnd Bergmann wrote:
> A bugfix in v4.8-rc2 introduced a harmless warning when CONFIG_MEMCG_SWAP
> is disabled but CONFIG_MEMCG is enabled:
> 
> mm/memcontrol.c:4085:27: error: 'mem_cgroup_id_get_online' defined but not 
> used [-Werror=unused-function]
>  static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
> 
> This moves the function inside of the #ifdef block that hides the
> calling function, to avoid the warning.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 1f47b61fb407 ("mm: memcontrol: fix swap counter leak on swapout from 
> offline cgroup")
> Acked-by: Michal Hocko 
> Acked-by: Vladimir Davydov 

Thanks a lot for respinning this Arnd!

> ---
>  mm/memcontrol.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> This is the alternative to the original patch, as suggested by Michal Hocko.
> Andrew, please pick whichever version you like better.
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 2ff0289ad061..9a6a51a7c416 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4082,24 +4082,6 @@ static void mem_cgroup_id_get_many(struct mem_cgroup 
> *memcg, unsigned int n)
>   atomic_add(n, >id.ref);
>  }
>  
> -static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
> -{
> - while (!atomic_inc_not_zero(>id.ref)) {
> - /*
> -  * The root cgroup cannot be destroyed, so it's refcount must
> -  * always be >= 1.
> -  */
> - if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
> - VM_BUG_ON(1);
> - break;
> - }
> - memcg = parent_mem_cgroup(memcg);
> - if (!memcg)
> - memcg = root_mem_cgroup;
> - }
> - return memcg;
> -}
> -
>  static void mem_cgroup_id_put_many(struct mem_cgroup *memcg, unsigned int n)
>  {
>   if (atomic_sub_and_test(n, >id.ref)) {
> @@ -5821,6 +5803,24 @@ static int __init mem_cgroup_init(void)
>  subsys_initcall(mem_cgroup_init);
>  
>  #ifdef CONFIG_MEMCG_SWAP
> +static struct mem_cgroup *mem_cgroup_id_get_online(struct mem_cgroup *memcg)
> +{
> + while (!atomic_inc_not_zero(>id.ref)) {
> + /*
> +  * The root cgroup cannot be destroyed, so it's refcount must
> +  * always be >= 1.
> +  */
> + if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
> + VM_BUG_ON(1);
> + break;
> + }
> + memcg = parent_mem_cgroup(memcg);
> + if (!memcg)
> + memcg = root_mem_cgroup;
> + }
> + return memcg;
> +}
> +
>  /**
>   * mem_cgroup_swapout - transfer a memsw charge to swap
>   * @page: page whose memsw charge to transfer
> -- 
> 2.9.0

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 2/2] reset: uniphier: use of_device_get_match_data() to get matched data

[Philipp Zabel]

Hi Masahiro,

Am Mittwoch, den 24.08.2016, 15:40 +0900 schrieb Masahiro Yamada:
> Use of_device_get_match_data() instead of of_match_node().  With
> this, we can retrieve the .data field of the OF match table more
> easily.  No more need to define (or declare) the match table before
> the probe callback.  I prefer to collect boilerplates at the bottom
> of the file, so moved it below.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/reset/reset-uniphier.c | 81 
> +-
>  1 file changed, 40 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index 41c62af..9b3f2cd 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -285,6 +286,45 @@ static const struct reset_control_ops uniphier_reset_ops 
> = {
>   .status = uniphier_reset_status,
>  };
>  
> +static int uniphier_reset_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct uniphier_reset_priv *priv;
> + const struct uniphier_reset_data *p, *data;
> + struct regmap *regmap;
> + struct device_node *parent;
> + unsigned int nr_resets = 0;
> +
> + data = of_device_get_match_data(dev);
> + WARN_ON(!data);

I know right now this can't happen anyway, but you did return -EINVAL
here before. Maybe use:

if (WARN_ON(!data))
return -EINVAL;

instead? I can fix it up if you agree.

> + parent = of_get_parent(dev->of_node); /* parent should be syscon node */
> + regmap = syscon_node_to_regmap(parent);
> + of_node_put(parent);
> + if (IS_ERR(regmap)) {
> + dev_err(dev, "failed to get regmap (error %ld)\n",
> + PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + for (p = data; p->id != UNIPHIER_RESET_ID_END; p++)

If in the future somebody forgets to set OF match data, this would be a
NULL pointer dereference.

regards
Philipp

Re: [PATCH 1/2] reset: uniphier: add static qualifier to probe function

[Philipp Zabel]

Am Mittwoch, den 24.08.2016, 15:40 +0900 schrieb Masahiro Yamada:
> I missed this in the initial commit.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/reset/reset-uniphier.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index 9de071f..41c62af 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -385,7 +385,7 @@ static const struct of_device_id uniphier_reset_match[] = 
> {
>  };
>  MODULE_DEVICE_TABLE(of, uniphier_reset_match);
>  
> -int uniphier_reset_probe(struct platform_device *pdev)
> +static int uniphier_reset_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
>   const struct of_device_id *match;

Thanks, I've squashed this into the original commit.

regards
Philipp

Re: [PATCH 1/3] perf/x86/intel/bts: Fix confused ordering of PMU callbacks

[Alexander Shishkin]

Alexander Shishkin  writes:

> The intel_bts driver is using a cpu-local 'started' variable to order
> callbacks and PMIs and make sure that AUX transactions don't get messed
> up. However, the ordering rules in regard to this variable is a complete
> mess, which recently resulted in perf_fuzzer-triggered warnings and
> panics.
>
> The general ordering rule that is patch is enforcing is that this
> cpu-local variable be set only when the cpu-local AUX transaction is
> active; consequently, this variable is to be checked before the AUX
> related bits can be touched.
>
> Signed-off-by: Alexander Shishkin 

Ok, this one is broken, please disregard.

Regards,
--
Alex

Re: [PATCH 4/7] pinctrl: samsung: Add GPFx support of Exynos5433

[Chanwoo Choi]

Hi Tomasz,

I'm sorry for delay reply.

On 2016년 08월 19일 20:31, Tomasz Figa wrote:
> Hi Chanwoo,
> 
> 2016-08-19 18:07 GMT+09:00 Chanwoo Choi :
>> Hi Tomasz Figa,
>>
>> Due to wrong setting of email client,
>> your reply is deleted on my email client at the company.
> 
> I used Gmail (in plain text mode) to reply, was that related?

The mistake depend on my filer setting of mail client.

> 
>> I'm so sorry. So, I add your comment on below and then
>> I reply the detailed description.
> 
> No problem. Thanks for description.
> 
>>
>> On 2016년 08월 16일 15:27, Chanwoo Choi wrote:
>>> From: Joonyoung Shim 
>>>
>>> This patch add the support of GPFx pin of Exynos5433 SoC. Exynos5433 has
>>> different memory map of GPFx from previous Exynos SoC. Exynos GPIO has
>>> following register to control gpio funciton. Usually, all registers of GPIO
>>> are included in same domain.
>>> - CON / DAT / PUD / DRV / CONPDN / PUDPDN
>>> - EINT_CON/ EINT_FLTCON0, EINT_FLTCON1 / EINT_MASK / EINT_PEND
>>>
>>> But, GPFx are included in two domain as following. So, this patch supports
>>> the GPFx pin which handle the on separate two domains.
>>> - ALIVE domain : CON / DAT / PUD / DRV / CONPDN / PUDPDN
>>> - IMEM domain  : EINT_CON/ EINT_FLTCON0, EINT_FLTCON1 / EINT_MASK / 
>>> EINT_PEND
>>
>> -
>> I'm afraid I don't get anything from the description above. Could you
>> describe the layout of registers in memory map and IRQ routing of the
>> pins?
>>
>> Best regards,
>> Tomasz
>> --
>>
>> On this patch, I'm sorry that I described the wrong information about GFP1~5.
>> I explained the memory map of GPF[1-5] the oppositely. Following compositions
>> are correct.
>> - ALIVE : WEINT_FLTCONx, WEINT_MASK, WEING_PEND
>> - IMEM : CON, DAT, PUD, DRV, CONPDN, PUDPDN
>> And, I add the memory map for GPF[1~5][2] and the wakeup interrupt 
>> information[1].
>>
>> [1] Memory map for GPF1~5
>> [ALIVE]
>> WEINT_GPA0_CON : 0x1058_ (ALIVE) + (0x0700 = 0x0700 + 0x0)
>> WEINT_GPA1_CON : 0x1058_ (ALIVE) + (0x0704 = 0x0700 + 0x4)
>> WEINT_GPA2_CON : 0x1058_ (ALIVE) + (0x0708 = 0x0700 + 0x8)
>> WEINT_GPA3_CON : 0x1058_ (ALIVE) + (0x070C = 0x0700 + 0xC)
>>
>> WEINT_GPF1_CON : 0x1058_ (ALIVE) + (0x1704 = 0x0700 + 0x1004)
>> WEINT_GPF2_CON : 0x1058_ (ALIVE) + (0x1708 = 0x0700 + 0x1008)
>> WEINT_GPF3_CON : 0x1058_ (ALIVE) + (0x170C = 0x0700 + 0x100C)
>> WEINT_GPF4_CON : 0x1058_ (ALIVE) + (0x1710 = 0x0700 + 0x10010)
>> WEINT_GPF5_CON : 0x1058_ (ALIVE) + (0x1714 = 0x0700 + 0x1014)
>>
>> WEINT_GPF[x]_MASK : 0x1058_ (ALIVE) + (0x1900 + (x * 4))
>> WEINT_GPF[x]_PEND : 0x1058_ (ALIVE) + (0x1A00 + (x * 4))
>> (x : 1 ~ 5)
>>
>> [IMEM]
>> GPF1_CON  : 0X1109_ (IMEM) + 0x0020
>> GPF1_DAT   : 0X1109_ (IMEM) + 0x0024
>> GPF1_PUD  : 0X1109_ (IMEM) + 0x0028
>> GPF1_DRV  : 0X1109_ (IMEM) + 0x002C
>> GPF1_CONPDN  : 0X1109_ (IMEM) + 0x0030
>> GPF1_PUDPDN  : 0X1109_ (IMEM) + 0x0034
>>
>> GPF2_CON : 0X1109_ (IMEM) + 0x0040
>> ...
>> GPF3_CON : 0X1109_ (IMEM) + 0x0060
>> ...
>> GPF4_CON : 0X1109_ (IMEM) + 0x0080
>> ...
>> GPF5_CON : 0X1109_ (IMEM) + 0x00A0
>>
>> [2] Interrput pin information
>> - the total number of wakeup external IRQ is 64.
>> --
>> domain| gpio : nr  | wakeup interrput name   | SPI number   |
>> ---
>> ALIVE | GPA0 : 8 | INTREQ__EINT[0~7] | SPI[0] ~ SPI[7]   |
>> ALIVE | GPA1 : 8 | INTREQ__EINT[8~15]   | SPI[8] ~ SPI[15] |
>> ALIVE | GPA2 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPA3 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ---
>> ALIVE | GPF1 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF2 : 4 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF3 : 4 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF4 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ALIVE | GPF5 : 8 | INTREQ__EINT_16_63 | SPI[16]   |
>> ---
>>
>> In summary,
>> If gpf[1-5] handle the CON/DAT/PUD/DRV register,
>> the driver will use the drvdata->ext_base (IMEM base address)
>> instead of drvdata->virt_base(ALIVE base address)
>> because the CON/DAT/PUD/DRV register of gpf[1-5] are included
>> in the IMEM domain.
>>
>> If gpf[1-5] handle the WEINT_* register,
>> the driver will use the drvdata->virt_base(ALIVE base address)
>> because the WEINT_* registers of gpf[1-5] are included in the ALIVE domain.
> 
> Okay, so Krzysztof's suggestion doesn't apply because it's not the
> eint base which is 

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

[Eric Dumazet]

On Wed, 2016-08-24 at 12:36 +0200, Christophe Leroy wrote:
> Initially, a NAPI TX routine has been implemented separately from
> NAPI RX, as done on the freescale/gianfar driver.
> 
> By merging NAPI RX and NAPI TX, we reduce the amount of TX completion
> interrupts.
> 
> Handling of the budget in association with TX interrupts is based on
> indications provided at https://wiki.linuxfoundation.org/networking/napi
> 
> At the same time, we fix an issue in the handling of fep->tx_free:
> 
> It is only when fep->tx_free goes up to MAX_SKB_FRAGS that
> we need to wake up the queue. There is no need to call
> netif_wake_queue() at every packet successfully transmitted.
> 
> Signed-off-by: Christophe Leroy 
> ---
>  .../net/ethernet/freescale/fs_enet/fs_enet-main.c  | 259 
> +
>  drivers/net/ethernet/freescale/fs_enet/fs_enet.h   |  16 +-
>  drivers/net/ethernet/freescale/fs_enet/mac-fcc.c   |  57 ++---
>  drivers/net/ethernet/freescale/fs_enet/mac-fec.c   |  57 ++---
>  drivers/net/ethernet/freescale/fs_enet/mac-scc.c   |  57 ++---
>  5 files changed, 153 insertions(+), 293 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c 
> b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> index 61fd486..7cd3ef9 100644
> --- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> +++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> @@ -79,8 +79,8 @@ static void skb_align(struct sk_buff *skb, int align)
>   skb_reserve(skb, align - off);
>  }
>  
> -/* NAPI receive function */
> -static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
> +/* NAPI function */
> +static int fs_enet_napi(struct napi_struct *napi, int budget)
>  {
>   struct fs_enet_private *fep = container_of(napi, struct 
> fs_enet_private, napi);
>   struct net_device *dev = fep->ndev;
> @@ -90,9 +90,100 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int 
> budget)
>   int received = 0;
>   u16 pkt_len, sc;
>   int curidx;
> + int dirtyidx, do_wake, do_restart;
>  
> - if (budget <= 0)
> - return received;
> + spin_lock(>tx_lock);
> + bdp = fep->dirty_tx;
> +
> + /* clear status bits for napi*/
> + (*fep->ops->napi_clear_event)(dev);
> +
> + do_wake = do_restart = 0;
> + while (((sc = CBDR_SC(bdp)) & BD_ENET_TX_READY) == 0) {

I am afraid you could live lock here on SMP.

You should make sure you do not loop forever, not assuming cpu is faster
than NIC.



> + dirtyidx = bdp - fep->tx_bd_base;
> +
> + if (fep->tx_free == fep->tx_ring)
> + break;
> +
> + skb = fep->tx_skbuff[dirtyidx];
> +
> + /*
> +  * Check for errors.
> +  */
> + if (sc & (BD_ENET_TX_HB | BD_ENET_TX_LC |
> +   BD_ENET_TX_RL | BD_ENET_TX_UN | BD_ENET_TX_CSL)) {
> +
> + if (sc & BD_ENET_TX_HB) /* No heartbeat */
> + fep->stats.tx_heartbeat_errors++;
> + if (sc & BD_ENET_TX_LC) /* Late collision */
> + fep->stats.tx_window_errors++;
> + if (sc & BD_ENET_TX_RL) /* Retrans limit */
> + fep->stats.tx_aborted_errors++;
> + if (sc & BD_ENET_TX_UN) /* Underrun */
> + fep->stats.tx_fifo_errors++;
> + if (sc & BD_ENET_TX_CSL)/* Carrier lost */
> + fep->stats.tx_carrier_errors++;
> +
> + if (sc & (BD_ENET_TX_LC | BD_ENET_TX_RL | 
> BD_ENET_TX_UN)) {
> + fep->stats.tx_errors++;
> + do_restart = 1;
> + }
> + } else
> + fep->stats.tx_packets++;
> +
> + if (sc & BD_ENET_TX_READY) {
> + dev_warn(fep->dev,
> +  "HEY! Enet xmit interrupt and TX_READY.\n");
> + }
> +
> + /*
> +  * Deferred means some collisions occurred during transmit,
> +  * but we eventually sent the packet OK.
> +  */
> + if (sc & BD_ENET_TX_DEF)
> + fep->stats.collisions++;
> +
> + /* unmap */
> + if (fep->mapped_as_page[dirtyidx])
> + dma_unmap_page(fep->dev, CBDR_BUFADDR(bdp),
> +CBDR_DATLEN(bdp), DMA_TO_DEVICE);
> + else
> + dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
> +  CBDR_DATLEN(bdp), DMA_TO_DEVICE);
> +
> + /*
> +  * Free the sk buffer associated with this last transmit.
> +  */
> + if (skb) {
> + dev_kfree_skb(skb);
> + fep->tx_skbuff[dirtyidx] = NULL;
> + 

[PATCH 04/10] reset: meson: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Neil Armstrong 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 8e33de2..fdf942d 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -34,6 +34,12 @@ config RESET_LPC18XX
  This enables the LPC18xx/43 reset driver that supports the reset
  controllers on AR71xx SoCs.
 
+config RESET_MESON
+   bool "Meson Reset Driver" if COMPILE_TEST
+   default ARCH_MESON
+   help
+ This enables the reset driver for Amlogic Meson SoCs.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 25aa05a..1408cba 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
-obj-$(CONFIG_ARCH_MESON) += reset-meson.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
+obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 07/10] reset: stm32: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Maxime Coquelin 
Cc: Gabriel Fernandez 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 354e281..3a54a66 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -55,6 +55,12 @@ config RESET_SOCFPGA
help
  This enables the reset driver for Altera SoC FPGAs.
 
+config RESET_STM32
+   bool "STM32 Reset Driver" if COMPILE_TEST
+   default ARCH_STM32
+   help
+ This enables the RCC reset controller driver for STM32 MCUs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 61e4c64..6276f82 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
+obj-$(CONFIG_RESET_STM32) += reset-stm32.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 09/10] reset: zynq: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Moritz Fischer 
Cc: Michal Simek 
Cc: Sören Brinkmann 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 17030e2..86b49a2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -67,6 +67,12 @@ config RESET_SUNXI
help
  This enables the reset driver for Allwinner SoCs.
 
+config RESET_ZYNQ
+   bool "ZYNQ Reset Driver" if COMPILE_TEST
+   default ARCH_ZYNQ
+   help
+ This enables the reset driver for Xilinx Zynq FPGAs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4a163c7..56f90ea 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
-obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
@@ -13,3 +12,4 @@ obj-$(CONFIG_RESET_STM32) += reset-stm32.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
+obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
-- 
2.8.1

[PATCH 01/10] reset: ath79: add driver Kconfig option

[Philipp Zabel]

Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Alban Bedel 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 7 +++
 drivers/reset/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 7dfe8d8..9da0507 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -14,6 +14,13 @@ menuconfig RESET_CONTROLLER
 
 if RESET_CONTROLLER
 
+config RESET_ATH79
+   bool "AR71xx Reset Driver" if COMPILE_TEST
+   default ATH79
+   help
+ This enables the ATH79 reset controller driver that supports the
+ AR71xx SoC reset controller.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 9b45dcf..e3fc337 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
-obj-$(CONFIG_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1

[PATCH 10/10] reset: hi6220: allow to compile test driver on other architectures

[Philipp Zabel]

Also remove the RESET_CONTROLLER dependency, this Kconfig file is
included inside the menuconfig already.

Cc: Chen Feng 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/hisilicon/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
index 26bf95a..1ff8b0c 100644
--- a/drivers/reset/hisilicon/Kconfig
+++ b/drivers/reset/hisilicon/Kconfig
@@ -1,5 +1,6 @@
 config COMMON_RESET_HI6220
tristate "Hi6220 Reset Driver"
-   depends on (ARCH_HISI && RESET_CONTROLLER)
+   depends on ARCH_HISI || COMPILE_TEST
+   default ARCH_HISI
help
  Build the Hisilicon Hi6220 reset driver.
-- 
2.8.1

[PATCH] arm64: dts: hikey: extend default cma size to 128MB

[Guodong Xu]

To support display in Debian on HiKey, cma heap is used to allocate
graphic buffers. The default size of CMA is 16 MB which is not enought.

Increase the default CMA size to 128 MB.

cc: Rob Herring 
cc: Fathi Boudra 
cc: John Stultz 
cc: Xinliang Liu 
Signed-off-by: Guodong Xu 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 4a51058..abb3434 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -45,6 +45,20 @@
  <0x 0x2200 0x 0x1c00>;
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* global autoconfigured region for contiguous allocations */
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x 0x0800>;
+   linux,cma-default;
+   };
+   };
+
pstore: pstore@0x21f0 {
no-map;
reg = <0x0 0x21f0 0x0 0x0010>;  /* pstore/ramoops 
buffer */
-- 
1.9.1

Re: [PATCHv6 1/3] usb: USB Type-C connector class

[Vincent Palatin]

Sorry if I'm making redundant comments with previous discussions, I
might have missed a few threads.


On Mon, Aug 22, 2016 at 2:05 PM, Heikki Krogerus
 wrote:
> The purpose of USB Type-C connector class is to provide
> unified interface for the user space to get the status and
> basic information about USB Type-C connectors on a system,
> control over data role swapping, and when the port supports
> USB Power Delivery, also control over power role swapping
> and Alternate Modes.
>
> Signed-off-by: Heikki Krogerus 
> ---
>  Documentation/ABI/testing/sysfs-class-typec |  199 +
>  Documentation/usb/typec.txt |  103 +++
>  MAINTAINERS |9 +
>  drivers/usb/Kconfig |2 +
>  drivers/usb/Makefile|2 +
>  drivers/usb/typec/Kconfig   |7 +
>  drivers/usb/typec/Makefile  |1 +
>  drivers/usb/typec/typec.c   | 1090 
> +++
>  include/linux/usb/typec.h   |  260 +++
>  9 files changed, 1673 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-typec
>  create mode 100644 Documentation/usb/typec.txt
>  create mode 100644 drivers/usb/typec/Kconfig
>  create mode 100644 drivers/usb/typec/Makefile
>  create mode 100644 drivers/usb/typec/typec.c
>  create mode 100644 include/linux/usb/typec.h
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> b/Documentation/ABI/testing/sysfs-class-typec
> new file mode 100644
> index 000..e6179d3
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -0,0 +1,199 @@
> +USB Type-C port devices (eg. /sys/class/typec/usbc0/)
> +
> +What:  /sys/class/typec//current_data_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current USB data role the port is operating in. This
> +   attribute can be used for requesting data role swapping on the
> +   port.

role swapping is sometimes a long operation. maybe we need to say
explicitly whether the 'write' is synchronous and returns when the
swap has succeeded / failed or asynchronous (and requires polling
current_data_role afterwards to know the result ?)


> +
> +   Valid values:
> +   - host
> +   - device

the USB workgroup has settled for DFP/UFP rather than host/device ?


> +
> +What:  /sys/class/typec//current_power_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current power role of the port. This attribute can be used
> +   to request power role swap on the port when the port supports

ditto


> +   USB Power Delivery.
> +
> +   Valid values:
> +   - source
> +   - sink
> +
> +What:  /sys/class/typec//current_vconn_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows the current VCONN role of the port. This attribute can 
> be
> +   used to request VCONN role swap on the port when the port
> +   supports USB Power Delivery.
> +
> +   Valid values are:
> +   - source
> +   - sink


either we are currently sourcing vconn or not, but even if you are
not, you are probably not a vconn sink either (ie only vconn-powered
accessory are, your usual linux-powered laptop/phone is probably not)


> +
> +What:  /sys/class/typec//power_operation_mode
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows the current power operational mode the port is in.
> +
> +   Valid values:
> +   - USB - Normal power levels defined in USB specifications
> +   - BC1.2 - Power levels defined in Battery Charging 
> Specification
> + v1.2
> +   - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
> +   specification.
> +   - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
> +   specification.
> +- USB Power Delivery - The voltages and currents defined in 
> USB
> +  Power Delivery specification
> +
> +What:  /sys/class/typec//preferred_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The user space can notify the driver about the preferred role.
> +   It should be handled as enabling of Try.SRC or Try.SNK, as
> +   defined in USB Type-C specification, in the port drivers. 

Re: [PATCH v3 1/5] ARM: dts: exynos: Enable HDMI for Arndale Octa board

[Krzysztof Kozlowski]

On Wed, Aug 24, 2016 at 10:07:15PM +0900, Milo Kim wrote:
> * GPIO for HDMI hot plug detect
>   GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
>   single ended.
> 
> * Enable HDMI block in Exynos5420
>   HDMI VDD and PLL consume 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator
>   requires 1.8V LDO7 (PVDD_ANAIP_1V8).
> 
> * Support HDMI display data channel
>   I2C #2 is assigned for the HDMI DDC. It enables the EDID access.
> 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: Rob Herring 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim 
> ---
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
> b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> index 39a3b81..2fb5708 100644
> --- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> +++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
> @@ -70,6 +70,19 @@
>   status = "disabled";
>  };
>

First of all - it looks like these DTS patches do not depend on DRM
part, do they?

> + {
> + hpd-gpios = < 7 GPIO_OPEN_SOURCE>;

Are you sure it is open-source type?

> + vdd_osc-supply = <_reg>;
> + vdd_pll-supply = <_reg>;
> + vdd-supply = <_reg>;
> + ddc = <_2>;
> + status = "okay";
> +};
> +
> +_2 {
> + status = "okay";

Hm, what is connected here? Please put it in alphabetical order (so
after hsi2c_4).

Best regards,
Krzysztof

Re: [PATCH 7/8] PCI: exynos: make host support explicitly non-modular

[Krzysztof Kozlowski]

On Mon, Aug 22, 2016 at 05:59:47PM -0400, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/pci/host/Kconfig:config PCI_EXYNOS
> drivers/pci/host/Kconfig:   bool "Samsung Exynos PCIe controller"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the couple traces of modular infrastructure use, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> Note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
> 
> Cc: Jingoo Han 
> Cc: Bjorn Helgaas 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: linux-...@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 
> ---
>  drivers/pci/host/pci-exynos.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful

[Josh Poimboeuf]

On Wed, Aug 24, 2016 at 12:07:06PM -0700, Joe Perches wrote:
> On Wed, 2016-08-24 at 13:43 -0500, Josh Poimboeuf wrote:
> > On Wed, Aug 24, 2016 at 10:28:38AM -0700, Joe Perches wrote:
> > > On Wed, 2016-08-24 at 11:50 -0500, Josh Poimboeuf wrote:
> > > > Change printk_stack_address() to be useful when called by an unwinder
> > > > outside the context of dump_trace().
> > > > 
> > > > Specifically:
> > > > 
> > > > - printk_stack_address()'s 'data' argument is always used as the log
> > > >   level string.  Make that explicit.
> []
> > > If this is true, and I'm not sure it is as I believe
> > > there are static strings emitted like EOE and IRQ,
> > > shouldn't this bubble up through the calling tree?
> 
> > []
> > This function needs to keep its 'void *data' argument because it's a
> > callback for stacktrace_ops, so it has to conform to the callback
> > interface.  'data' is used for passing a pointer to an opaque data
> > structure to the callback.
> > 
> > Also this is the only caller of printk_stack_address(), so there's
> > nowhere else to bubble it up to.
> 
> And that shows that print_stack_address(data is not always a log level.
> ie: walk_stack uses it to print a string not a log level.

Hm, can you be more specific?  As far as I can tell, here's the only
possible call path to print_trace_address() and printk_stack_address():

show_trace_log_lvl()
  dump_trace()  // ops is print_trace_op
print_context_stack()   // ops->walk_stack
  print_trace_address() // ops->address
  printk_stack_address()

So 'data' is a sneaky way to pass 'log_lvl' from show_trace_log_lvl() to
print_trace_address(), without dump_trace() and print_context_stack()
knowing what it is, because they're used in other places where 'data'
means something else.

-- 
Josh

[PATCH] mm, swap: Add swap_cluster_list

[Huang, Ying]

From: Huang Ying 

This is a code clean up patch without functionality changes.  The
swap_cluster_list data structure and its operations are introduced to
provide some better encapsulation for the free cluster and discard
cluster list operations.  This avoid some code duplication, improved
the code readability, and reduced the total line number.

Cc: Tim Chen 
Cc: Hugh Dickins 
Cc: Shaohua Li 
Cc: Rik van Riel 
Acked-by: Minchan Kim 
Signed-off-by: "Huang, Ying" 
---
 include/linux/swap.h |  11 +++--
 mm/swapfile.c| 131 ---
 2 files changed, 68 insertions(+), 74 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index b17cc48..ed41bec 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -191,6 +191,11 @@ struct percpu_cluster {
unsigned int next; /* Likely next allocation offset */
 };
 
+struct swap_cluster_list {
+   struct swap_cluster_info head;
+   struct swap_cluster_info tail;
+};
+
 /*
  * The in-memory structure used to track swap areas.
  */
@@ -203,8 +208,7 @@ struct swap_info_struct {
unsigned intmax;/* extent of the swap_map */
unsigned char *swap_map;/* vmalloc'ed array of usage counts */
struct swap_cluster_info *cluster_info; /* cluster info. Only for SSD */
-   struct swap_cluster_info free_cluster_head; /* free cluster list head */
-   struct swap_cluster_info free_cluster_tail; /* free cluster list tail */
+   struct swap_cluster_list free_clusters; /* free clusters list */
unsigned int lowest_bit;/* index of first free in swap_map */
unsigned int highest_bit;   /* index of last free in swap_map */
unsigned int pages; /* total of usable pages of swap */
@@ -235,8 +239,7 @@ struct swap_info_struct {
 * first.
 */
struct work_struct discard_work; /* discard worker */
-   struct swap_cluster_info discard_cluster_head; /* list head of discard 
clusters */
-   struct swap_cluster_info discard_cluster_tail; /* list tail of discard 
clusters */
+   struct swap_cluster_list discard_clusters; /* discard clusters list */
 };
 
 /* linux/mm/workingset.c */
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 78cfa29..f9892a3 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -257,6 +257,52 @@ static inline void cluster_set_null(struct 
swap_cluster_info *info)
info->data = 0;
 }
 
+static inline bool cluster_list_empty(struct swap_cluster_list *list)
+{
+   return cluster_is_null(>head);
+}
+
+static inline unsigned int cluster_list_first(struct swap_cluster_list *list)
+{
+   return cluster_next(>head);
+}
+
+static void cluster_list_init(struct swap_cluster_list *list)
+{
+   cluster_set_null(>head);
+   cluster_set_null(>tail);
+}
+
+static void cluster_list_add_tail(struct swap_cluster_list *list,
+ struct swap_cluster_info *ci,
+ unsigned int idx)
+{
+   if (cluster_list_empty(list)) {
+   cluster_set_next_flag(>head, idx, 0);
+   cluster_set_next_flag(>tail, idx, 0);
+   } else {
+   unsigned int tail = cluster_next(>tail);
+   cluster_set_next([tail], idx);
+   cluster_set_next_flag(>tail, idx, 0);
+   }
+}
+
+static unsigned int cluster_list_del_first(struct swap_cluster_list *list,
+  struct swap_cluster_info *ci)
+{
+   unsigned int idx;
+
+   idx = cluster_next(>head);
+   if (cluster_next(>tail) == idx) {
+   cluster_set_null(>head);
+   cluster_set_null(>tail);
+   } else
+   cluster_set_next_flag(>head,
+ cluster_next([idx]), 0);
+
+   return idx;
+}
+
 /* Add a cluster to discard list and schedule it to do discard */
 static void swap_cluster_schedule_discard(struct swap_info_struct *si,
unsigned int idx)
@@ -270,17 +316,7 @@ static void swap_cluster_schedule_discard(struct 
swap_info_struct *si,
memset(si->swap_map + idx * SWAPFILE_CLUSTER,
SWAP_MAP_BAD, SWAPFILE_CLUSTER);
 
-   if (cluster_is_null(>discard_cluster_head)) {
-   cluster_set_next_flag(>discard_cluster_head,
-   idx, 0);
-   cluster_set_next_flag(>discard_cluster_tail,
-   idx, 0);
-   } else {
-   unsigned int tail = cluster_next(>discard_cluster_tail);
-   cluster_set_next(>cluster_info[tail], idx);
-   cluster_set_next_flag(>discard_cluster_tail,
-   

Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful

[Josh Poimboeuf]

On Wed, Aug 24, 2016 at 02:37:21PM -0400, Linus Torvalds wrote:
> On Wed, Aug 24, 2016 at 2:22 PM, Peter Zijlstra  wrote:
> >
> > I actively disable KASLR on my dev box and feed these hex numbers into
> > addr2line -ie vmlinux to find where in the function we are.
> >
> > Having the option to make %pB generate them works for me.
> 
> Yeah, considering that this is the only place this is used, changing
> %pB sounds quite reasonable.

There's now another use of '%pB' in proc_pid_stack() in the tip tree: I
changed it to '%pB' from '%pS'.  But I think the modified '%pB' would
work there as well.

> We could perhaps make %pB show the hex numbers and address (so pB
> would expand to "[] symbolname".if
> 
>  (a) not randomizing (so the hex numbers _may_ be useful)
> 
>  (b) kptr_restrict is 0 (so the hex numbers are "safe" in the dmesg)
> 
> and fall back to just the symbolic name if either of those aren't true?

Do we really need to check for both?  '%pK' only checks kptr_restrict.
I'd think we should be consistent with that.  And maybe there are some
scenarios where the actual text addresses provide useful debug
information if KASLR is enabled and kptr_restrict is zero.

> And obviously, if KALLSYMS isn't enabled, you always show hex
> numbers.. That's already the case (but we might want to add the "[<>}'
> markers around the hex numbers just to make the user space automation
> we do have work).

Even if kptr_restrict is set?

-- 
Josh

Re: [PATCH 1/2] ARM: dts: sun8i: Add dts file for inet-d978_rev2 tablets

[Maxime Ripard]

Hi,

On Tue, Aug 23, 2016 at 02:44:50PM +0800, Icenowy Zheng wrote:
> The inet-d978_rev2 is a pcb used in generic A33 based tablets. It features
> volume buttons, micro-usb otg, headphone connector and a power button.
> 
> On the board a Realtek RTL8723BS SDIO Wi-Fi module are soldered, and there
> is also a accompanied board which has a Goodix GT9271 soldered.
> 
> As this board is desired to create tablets with a Home key dealed by
> GT9271, a LED is present at the front panel at the position of the
> Home key.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/Makefile |  1 +
>  arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 87 
> ++
>  2 files changed, 88 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..d1812a0 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -782,6 +782,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>   sun8i-a23-q8-tablet.dtb \
>   sun8i-a33-et-q8-v1.6.dtb \
>   sun8i-a33-ga10h-v1.1.dtb \
> + sun8i-a33-inet-d978-rev2.dtb \
>   sun8i-a33-ippo-q8h-v1.2.dtb \
>   sun8i-a33-q8-tablet.dtb \
>   sun8i-a33-sinlinx-sina33.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts 
> b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> new file mode 100644
> index 000..78823d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> @@ -0,0 +1,87 @@
> +/*
> + * Copyright 2015 Hans de Goede 

I guess you are the author too :)

> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-a33.dtsi"
> +#include "sun8i-reference-design-tablet.dtsi"
> +
> +/ {
> + model = "INet-D978 Rev 02";
> + compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pin_d978>;
> +
> + home {
> + label = "d978:home";

This is not the proper format for the led labels.

It's supposed to be ::

> + gpios = <_pio 0 5 GPIO_ACTIVE_HIGH>; /* PL5 */
> + };
> + };
> +};
> +
> +_pins_a {
> + allwinner,pull = ;
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + vmmc-supply = <_dldo1>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + rtl8723bs: sdio_wifi@1 {
> + reg = <1>;
> + };

Don't you need an alias to this node to have the MAC address set?

Thanks,
Maxime

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


signature.asc
Description: PGP signature

Capturing crash with 4.6.0 and above kernel does not work

[Himanshu Madhani]

Hello list,

I am wondering if anybody has issue capturing crash dump with the 4.6.0 and 
above kenrel.

I have a system, when booted in 4.5.7 kernel is able to capture crash dump.
However, when I boot this system in 4.6.4 and 4.7.2 kernel, crash dump is not 
able to capture any crash. 

I am still facing same issue with 4.8.0-rc2+ kernel and from the error at the 
command prompt, 
it seems like kexec is ignoring “crashkenrel” parameter. 

I added below information in 
https://bugzilla.kernel.org/show_bug.cgi?id=119291. 

# uname -r
4.8.0-rc2+

# cat /proc/cmdline 
ro root=/dev/mapper/vg_dut4110-lv_root rd_NO_LUKS  KEYBOARDTYPE=pc KEYTABLE=us 
LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=512M 
rd_LVM_LV=vg_dut4110/lv_swap rd_LVM_LV=vg_dut4110/lv_root rd_NO_DM rhgb quiet

# service kdump status
Kdump is not operational

# service kdump start
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Starting kdump:[FAILED]

message file confirms that kexec was not able to start the service 

Aug 15 10:41:17 dut4110 kdump: kexec: failed to load kdump kernel
Aug 15 10:41:17 dut4110 kdump: failed to start up

Note, that same option is able to load kdump service for 4.5.7 kernel.  

I can provide any details needed to help resolve this issue. 

Thanks,
- Himanshu

Re: [PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

On Wed, Aug 24, 2016 at 08:01:52PM +0100, Marc Zyngier wrote:
> On Wed, 24 Aug 2016 13:40:01 -0400
> Rich Felker  wrote:
> 
> [...]
> 
> > > IIUC, there is a problem with the interrupt controller where
> the per irq
> > > line are not working correctly. Is that correct ?  
> > 
> > I don't think that's a correct characterization. Rather the percpu
> > infrastructure just means something completely different from what you
> > would expect it to mean. It has nothing to do with the hardware but
> > rather with kernel-internal choice of whether to do percpu devid
> > mapping inside the irq infrastructure, and the choice at the
> > irq-requester side of whether to do this is required to match the
> > irqchip driver's choice. I explained this better in another email
> > which I could dig up if necessary, but the essence is that
> > request_percpu_irq is a misnamed and unusably broken API.

For reference, here's the thread I was referring to:

https://lkml.org/lkml/2016/7/15/585

> Or just one that simply doesn't fit your needs, because other
> architectures have different semantics than the ones you take for
> granted?

I don't think so. The choice of whether to have the irq layer or the
driver's irq handler be responsible for handling a percpu pointer has
nothing to do with the hardware.

Perhaps the intent was that the irqchip driver always knows whether a
given hwirq[-range] is associated with per-cpu events or global events
for which it doesn't matter what cpu they're delivered on. In this
case, the situations where you may want percpu dev_id mapping line up
with some property of the hardware. However that need not be the case,
and it's not when the choice of irq is programmable.

> > > Regarding Marc Zyngier comments about the irq controller driver being
> > > almost empty, I'm wondering if something in the irq controller driver
> > > which shouldn't be added before submitting this timer driver with SMP
> > > support (eg. irq domain ?).  
> > 
> > I don't think so. At most I could make the driver hard-code the percpu
> > devid model for certain irqs, but that _does not reflect_ anything
> > about the hardware. Rather it just reflects bad kernel internals. It
> 
> I'd appreciate it if instead of ranting about how broken the kernel is,
> you'd submit a patch fixing it, since you seem to have spotted
> something that we haven't in several years of using that code on a
> couple of ARM-related platforms.

I didn't intend for this to be a rant. I'm not demanding that it be
changed; I'm only objecting to being asked to make the driver use a
framework that it doesn't need and that can't model what needs to be
done. But I'm happy to discuss whether you would be open to such a
change, and if so, to write and submit a patch. The ideas for what it
would involve are in the linked email, quoted here:

   "... This is because the irq controller driver must, at irqdomain
mapping time, decide whether to register the handler as
handle_percpu_devid_irq (which interprets dev_id as a __percpu
pointer and remaps it for the local cpu before invoking the
driver's handler) or one of the other handlers that does not
perform any percpu remapping.

The right way for this to work would be for
handle_irq_event_percpu to be responsible for the remapping, but
do it conditionally on whether the irq was requested via
request_irq or request_percpu_irq."

Do you disagree with this assessment?

Rich

Re: [PATCH 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board

[Maxime Ripard]

Hi,

On Tue, Aug 23, 2016 at 02:44:51PM +0800, Icenowy Zheng wrote:
> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
> on iNet D978 Rev2 board.
> 
> Enable the UART1 to make it possible to use the modified hciattach by
> Realtek to drive the BT part of RTL8723BS.
> 
> Signed-off-by: Icenowy Zheng 

I guess you could fold that patch into the previous one.

> ---
>  arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts 
> b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> index 78823d8..3ac22d4 100644
> --- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
> @@ -48,6 +48,10 @@
>   model = "INet-D978 Rev 02";
>   compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
>  
> + aliases {
> + serial1 = 
> + };
> +

Is there any other UART in the system?

The alias is not supposed to be about the controller index, but the
index in the board, meaning that if you only have a single UART, that
would be serial0.

Thanks!
Maxime

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


signature.asc
Description: PGP signature

Re: [PATCH] ALSA: snd-aoa: enable sound on PowerBook G4 12"

[Johannes Berg]

On Wed, 2016-08-24 at 20:57 +0300, Aaro Koskinen wrote:
> Enable sound on PowerBook G4 12".

Looks good to me, I assume you tested it and it works :)

johannes

> Signed-off-by: Aaro Koskinen 
> ---
>  sound/aoa/fabrics/layout.c   | 8 
>  sound/aoa/soundbus/i2sbus/core.c | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/aoa/fabrics/layout.c b/sound/aoa/fabrics/layout.c
> index 8f71f7e..edc8681 100644
> --- a/sound/aoa/fabrics/layout.c
> +++ b/sound/aoa/fabrics/layout.c
> @@ -112,6 +112,7 @@ MODULE_ALIAS("sound-layout-100");
>  
>  MODULE_ALIAS("aoa-device-id-14");
>  MODULE_ALIAS("aoa-device-id-22");
> +MODULE_ALIAS("aoa-device-id-31");
>  MODULE_ALIAS("aoa-device-id-35");
>  MODULE_ALIAS("aoa-device-id-44");
>  
> @@ -362,6 +363,13 @@ static struct layout layouts[] = {
>   .connections = tas_connections_nolineout,
>     },
>   },
> + /* PowerBook6,1 */
> + { .device_id = 31,
> +   .codecs[0] = {
> + .name = "tas",
> + .connections = tas_connections_nolineout,
> +   },
> + },
>   /* PowerBook6,5 */
>   { .device_id = 44,
>     .codecs[0] = {
> diff --git a/sound/aoa/soundbus/i2sbus/core.c
> b/sound/aoa/soundbus/i2sbus/core.c
> index 1cbf210..000b585 100644
> --- a/sound/aoa/soundbus/i2sbus/core.c
> +++ b/sound/aoa/soundbus/i2sbus/core.c
> @@ -197,7 +197,7 @@ static int i2sbus_add_dev(struct macio_dev
> *macio,
>    * so restrict to those we do handle for
> now.
>    */
>   if (id && (*id == 22 || *id == 14 || *id ==
> 35 ||
> -    *id == 44)) {
> +    *id == 31 || *id == 44)) {
>   snprintf(dev->sound.modalias, 32,
>    "aoa-device-id-%d", *id);
>   ok = 1;

[GIT PULL] UBI/UBIFS fixes for 4.8-rc4

[Richard Weinberger]

Linus,

The following changes since commit 7a1dcf6adaa7cc4b8cd93a3883267497a77b1051:

  Merge tag 'usercopy-v4.8-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux (2016-08-23 14:32:38 
-0400)

are available in the git repository at:

  git://git.infradead.org/linux-ubifs.git tags/upstream-4.8-rc4

for you to fetch changes up to 17ce1eb0b64eb27d4f9180daae7495fa022c7b0d:

  ubifs: Fix xattr generic handler usage (2016-08-23 23:02:52 +0200)


This pull requests contains fixes for two issues in UBI and UBIFS:
1. Wrong UBIFS assertion.
2. A UBIFS xattr regression.


Richard Weinberger (1):
  ubifs: Fix xattr generic handler usage

Vincent Stehlé (1):
  ubifs: Fix assertion in layout_in_gaps()

 fs/ubifs/tnc_commit.c | 2 +-
 fs/ubifs/xattr.c  | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

Re: [PATCH 0/6] Apple device properties

[Matt Fleming]

On Mon, 22 Aug, at 11:58:50AM, Lukas Wunner wrote:
> By the way, arch/x86/Kconfig says that "it is not possible to boot a
> mixed-mode enabled kernel via the EFI boot stub - a bootloader that
> supports the EFI handover protocol must be used".
> 
> Is this still correct? With all the mixed-mode support in head_64.S
> and eboot.c, I'm wondering what's missing?

Yes, that's still correct.

The EFI boot stub technically refers to the feature of having the
firmware load the kernel directly, without the use of a boot loader.

In that scenario you need the kernel and firmware to agree on a CPU
mode since the kernel has no way to figure out if it needs to switch
or not. Nor does it have a direct way to figure out what bitness the
firmware is.

[ Yes, technically we could add code to the EFI stub to detect the
  current mode and perform the switch, we just don't have anything
  like that right now ]

Re: [RFC][PATCH 3/3] locking/mutex: Add lock handoff to avoid starvation

[Waiman Long]

On 08/23/2016 04:32 PM, Peter Zijlstra wrote:

On Tue, Aug 23, 2016 at 03:47:53PM -0400, Waiman Long wrote:

On 08/23/2016 08:46 AM, Peter Zijlstra wrote:

N
@@ -573,8 +600,14 @@ __mutex_lock_common(struct mutex *lock,
schedule_preempt_disabled();
spin_lock_mutex(>wait_lock, flags);

+   if (__mutex_owner(lock) == current)
+   break;
+
if (__mutex_trylock(lock))
break;
+
+   if (__mutex_waiter_is_first(lock,))
+   __mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
}
__set_task_state(task, TASK_RUNNING);



You may want to think about doing some spinning while the owner is active
instead of going back to sleep again here.

For sure; I just didn't bother pulling in your patches. I didn't want to
sink in more time in case people really hated on 1/3 ;-)


I think there is race in how the handoff is being done.

CPU 0   CPU 1   CPU 2

-   -   -

__mutex_lock_common:mutex_optimistic_spin:

  __mutex_trylock()

mutex_unlock:

  if (owner&  


 MUTEX_FLAG_HANDOFF)

  owner&= 0x3;

   __mutex_trylock();

 owner = CPU2;

  __mutex_set_flag(lock,

MUTEX_FLAG_HANDOFF)

__mutex_unlock_slowpath:

__mutex_handoff:

  owner = CPU0;


Now both CPUs 1 and 2 think they have the lock. One way to fix that is
to check if the owner is still the original lock holder (CPU 0) before
doing the handoff, like:

--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -97,6 +97,8 @@ static void __mutex_handoff(struct mutex *lock, struct 
task_st

for (;;) {
unsigned long old, new;

+   if ((owner & ~MUTEX_FLAG_ALL) != current)
+   break;
new = (owner & MUTEX_FLAG_WAITERS);
new |= (unsigned long)task;

I also think that the MUTEX_FLAG_HANDOFF bit needs to be cleared if the list
is empty.

@@ -614,7 +633,7 @@ __mutex_lock_common(struct mutex *lock, long state, 
unsigned

mutex_remove_waiter(lock, , task);
/* set it to 0 if there are no waiters left: */
if (likely(list_empty(>wait_list)))
-   __mutex_clear_flag(lock, MUTEX_FLAG_WAITERS);
+   __mutex_clear_flag(lock, 
MUTEX_FLAG_WAITERS|MUTEX_FLAG_HANDOFF);


Or we should try to reset the handoff bit after the while loop exit if 
the bit is still set.


Cheers,
Longman

Direct cash Loans Offer!!!!

[Direct Cash Loans Pty]

Good News,

Direct cash Loans is currently giving out loan at 3.5% interest rate. 

Kindly forward the following details your ID Number, Full Names, Occupation, 
Monthly Income, Type of loan , telephone number and email address via email to 
this email:  directcashloans_d...@webmail.co.za 

View attached document for more information about our special loan offer or 
call : +27(0)622 539 768  for more information.

Commission earners can also apply. 


Regards, 

Lydia Smith (Mrs) 

Loan Application Unit/Risk Supervisor.


Direct Cash Loan Low Rate Offer.docx
Description: MS-Word 2007 document

Re: [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller

[Mirza Krak]

2016-08-24 17:56 GMT+02:00 Jon Hunter :
+
>> +Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap 
>> the
>> +controllers with a simple-bus node since they are all connected to the same
>> +chip-select (CS4), in this example external address decoding is provided:
>> +
>> +gmi@7009 {
>> + compatible = "nvidia,tegra20-gmi";
>> + reg = <0x70009000 0x1000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + clocks = <_car TEGRA20_CLK_NOR>;
>> + clock-names = "gmi";
>> + resets = <_car 42>;
>> + reset-names = "gmi";
>> + ranges = <4 0x4800 0x7ff>;
>> +
>> + status = "disabled";
>> +
>> + bus@4 {
>> + compatible = "simple-bus";
>> + reg = <4>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 4 0x40100>;
>
> Does this work? I tried to add an example like this and I got ...
>
> Warning (reg_format): "reg" property in /gmi@70009000/bus@4 has invalid
> length (4 bytes) (#address-cells == 1, #size-cells == 1)

Shoot, to get rid of the warning it should be

reg = <4 0 >;

But it works either way.

>
> I am wondering if we should just following the arm,pl172 example and
> have ...
>
> cs4 {
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> nvidia,snor-cs = <4>;
> nvidia,snor-mux-mode;
> nvidia,snor-adv-inv;
>
> can@0 {
> reg = <0 0x100>;
> ...
> };
>
> ...
> };
>

That means to go back to V1 really (almost :)). Which I do not mind.
Will give it a test run.

But I am a little hesitant if will be any better/cleaner. In your example above:

can@0 {
 reg = <0 0x100>;
 ...
};

Would this really translate correctly? In the pl172 example they have
multiple ranges and address with "flash@0,0" which a range defined in
parent node. "can@0" does not have valid match in parent node in our
example. So I probably need add some more logic for it to properly
translate.

I have an idea which is following:

gmi@7009 {
 status = "okay";
 #address-cells = <2>;
 #size-cells = <1>;
 ranges = <4 0 0x4800 0x0004>;

 cs4 {
 compatible = "simple-bus";
 #address-cells = <2>;
 #size-cells = <1>;
 ranges;

 nvidia,snor-cs = <4>;
 nvidia,snor-mux-mode;
 nvidia,snor-adv-inv;

 can@0 {
 compatible = "nxp,sja1000";
 reg = <4 0 0x100>;
 ...
 };


 can@4 {
 compatible = "nxp,sja1000";
 reg = <4 0x4 0x100>;
 ...
 };
 };
};

Do not know if above will work at all (not able to test at current
location), anyway I will play around with it some more and get back to
you.

Best Regards
Mirza

Re: [PATCH v4 3/3] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Maxime Ripard]

On Mon, Aug 22, 2016 at 11:29:59PM +0200, Rask Ingemann Lambertsen wrote:
> On Mon, Aug 22, 2016 at 08:57:45PM +0200, Maxime Ripard wrote:
> > Hi,
> > 
> > On Sat, Aug 13, 2016 at 12:03:57AM +0200, Rask Ingemann Lambertsen wrote:
> > > The Suncip CX-A99 board is found in at least four brands of TV boxes.
> > > It features an Allwinner A80 SOC, with either 2 GiB DDR3 DRAM and
> > > 16 GB eMMC or 4 GiB DDR3 DRAM and 32 GB eMMC, as well as several support
> > > chips for Ethernet, wireless networking, video output, SATA and power
> > > management. For details, see the linux-sunxi page about the board
> > > .
> > > 
> > > This patch only adds support for the SD and eMMC storage, real-time clock,
> > > USB 2.0 ports (and by extension the SATA port), the UART port and the 
> > > LEDs.
> > > All of this relies on the boot loader to leave those parts powered up, as
> > > I'm still working on a driver for the AXP808 PMIC.
> > > 
> > > Signed-off-by: Rask Ingemann Lambertsen 
> > 
> > It looks mostly good, but I have a couple of comments though, see below.
> > 
> > > ---
> > > 
> > > Although the vendor U-Boot lets you boot the kernel on one of the
> > > Cortex-A15 cores, the kernel gpio-regulator driver currently glitches
> > > the GPIO lines to the OZ80120 regulator such that the system crashes
> > > during startup. This part needs further work to be useful.
> > 
> > So it doesn't power the CPU through one of the AXP regulators?
> > Interesting design.
> 
> The Cortex-A7 cores are powered by the dcdca regulator on the AXP 808 PMIC.
> Right now, I'm using the AXP 806 driver that Chen-Yu Tsai posted to drive
> the AXP 808 and so far, it looks good.

Ok.

> > > + leds {
> > > + compatible = "gpio-leds";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins_cx_a99>;
> > > +
> > > + blue {
> > > + gpios = < 6 10 GPIO_ACTIVE_HIGH>;   /* PG10 */
> > > + label = "cx-a99:blue:normal";
> > > + default-state = "on";
> > > + };
> > > +
> > > + red {
> > > + gpios = < 6 11 GPIO_ACTIVE_HIGH>;   /* PG11 */
> > > + label = "cx-a99:red:standby";
> > 
> > The last part of the label should be the function.
> 
> I'm not sure what else to label them. They form a bi-colour LED emitting
> through the front of the device. The stock OS lights the blue LED when
> the device is powered on and lights the red LED when the device is
> suspended. There is no label on the front of the device telling what the
> colours mean. Documentation/devicetree/bindings/leds/common.txt and
> Documentation/devicetree/bindings/leds/leds-gpio.txt don't provide much in
> the way of examples. Suggestions are welcome.

H. status for both then?

> [snip]
> > > +
> > > +/* Each GPIO controls VBUS for a port on the GL850G hub connected to 
> > > ehci0;
> > > + * PL7 for port 1, the USB connector closest to the 12 V power 
> > > connector, and
> > > + * PL8 for port 2, the USB connector next to the (micro)SD card slot.
> > > + * Note: The regulators are not chained like this in reality, but
> > > + * regulator-fixed doesn't support a gpio list, and 
> > > allwinner,sun9i-a80-usb-phy
> > > + * doesn't support more than one supply, so this will have to do (for 
> > > now).
> > > + */
> > > +_usb1_vbus {
> > > + pinctrl-0 = <_vbus_r_pin_cx_a99>;
> > > + gpio = <_pio 0 7 GPIO_ACTIVE_HIGH>;   /* PL7 */
> > > + status = "okay";
> > > +};
> > > +
> > > +_usb2_vbus {
> > > + pinctrl-0 = <_vbus_r_pin_cx_a99>;
> > > + gpio = <_pio 0 8 GPIO_ACTIVE_HIGH>;   /* PL8 */
> > 
> > I'd really prefer it to be modelled properly, and not attached to the
> > wrong device.
> > 
> > I have some work pending to allow multiple regulators in the same
> > property, but that won't be ready soon.
> > 
> > For the time being, I would suggest having two usb1 regulators
> > defined, each with their respective GPIOs, and one set to always on
> > (and keep that great comment).
> 
> Will do if I don't come up with something better. I gave it a shot to
> describe the hub as a child of ehci0 with a child node for each of the
> two ports, but it didn't work.
> 
> Also, using the phy-supply property for the vbus-supply is an ugly hack,
> in the first place, isn't it? Shouldn't it be more like this?
> 
>  {
>   phy-supply = <_vcc33_usbh>;
> };
> 
>  {
>   vcc-supply = <_vdd09_usbh>;
>   phy = <>;
> 
>   hub@1 {
>   port@1 {
>   vbus-supply = <_usb1_vbus>;
>   }
> 
>   port@2 {
>   vbus-supply = <_usb2_vbus>;
>   }
>   };
> };

It looks great to me. I'm not really sure how happy the DT maintainers
are going to be about it, and how easy it would be to support without
breaking the existing users.

> It would generally be great to be able to describe regulators that should
> be kept in sync, 

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Thierry Reding]

On Wed, Aug 24, 2016 at 05:34:55PM +0530, Vinay Simha wrote:
> thierry,
> 
> this is the reference pinouts of the panel
> http://www.tonylabs.com/wp-content/uploads/LT070ME05000-pinouts.jpg

I can't open that file.

> as you suggest , i will change the vcc-supply,
> 
>  - iovcc-supply: phandle of the regulator that supplies power to
>   the IOVCC voltage input (1.8 V)
> 
> will keep the other two(vddp-supply, dcdc_en-supply) remaining same.

"dcdc_en" sounds to me like it should be a GPIO rather than a regulator.

According to this datasheet:


http://kb.52solution.com/data/uploads/2016/04/07/3172846545705cc22d050e.pdf

the input voltages are indeed VDD, VDDp and IOVCC, though with slightly
larger tolerances than the previous datasheet. VDD and VDDp can both go
from 3.0 V to 5.0 V. DCDC_EN is indeed an additional GPIO to enable the
VDDp supply.

I think you'd need something along these lines:

- vdd-supply: LED power supply (3.0-5.0 V)
- vddp-supply: power IC supply (3.0-5.0 V)
- iovcc-supply: LCM power supply (1.8 V)
- dcdc-en-gpios: power IC supply enable
- led-en-gpios: LED backlight enable

Or perhaps your vddp-supply should be a regulator that's controlled by
the GPIO that you'd put in dcdc-en-gpios. That might work better. That
would leave only led-en-gpios as the only enable GPIOs property, so it
would be okay to keep the name "enable-gpios", I guess.

Thierry

> On Wed, Aug 24, 2016 at 5:15 PM, Thierry Reding
>  wrote:
> > On Sun, Jul 31, 2016 at 08:45:21PM +0530, Vinay Simha BN wrote:
> >> 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
> >> ---
> >>  .../bindings/display/panel/jdi,lt070me05000.txt| 57 
> >> ++
> >>  1 file changed, 57 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..613b76f
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> >> @@ -0,0 +1,57 @@
> >> +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)
> >> +- dcdc_en-supply: phandle of the regulator that provides the supply 
> >> voltage
> >> +  Power IC supply enable, High active
> >> +- vcc-supply: phandle of the regulator that provides the supply voltage
> >> +  IOVCC , power supply for LCM (1.8V)
> >
> > I was just going to apply this and wanted to add some information about
> > how many lanes the panel uses, so I looked at the datasheet linked to in
> > patch 4/4:
> >
> > http://panelone.net/en/7-0-inch/JDI_LT070ME05000_7.0_inch-datasheet
> >
> > and noticed that the power supplies in the binding here don't match the
> > ones listed in the datasheet. Granted, the datasheet is somewhat meager,
> > but it lists the following three input voltages:
> >
> > - IOVCC at 1.8 V
> > - VDD at 3.0 V
> > - VDDP at 3.0 V
> >
> > This matches in part what the above binding describes, but it's not
> > quite right, so I'm wondering if the name for dcdc_en-supply came from
> > the board schematics and reflects the name of the rail on the board
> > design that provides this rather than the input voltage on the panel.
> >
> > I think we should follow the names in the panel datasheet so that people
> > can more easily reference the correct regulators when using this panel
> > on a different board. I'd suggest:
> >
> > - iovcc-supply: phandle of the regulator that supplies power to
> >   the IOVCC voltage input (1.8 V)
> > - vdd-supply: phandle of the regulator that supplies power to
> >   the VDD voltage input (3.0 V)
> > - vddp-supply: phandle of the regulator that supplies power to
> >   the VDDP voltage input (3.0 V)
> >
> > Any objections?
> >
> > Thierry
> 
> 
> 
> -- 
> regards,
> vinaysimha


signature.asc
Description: PGP signature

Re: [PATCH v2 7/8] hisi_sas: add TMF success check

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> When a tmf is issued, various response codes can be
> returned from the target. For a query tmf the
> response may be TMF_RESP_FUNC_COMPLETE or
> TMF_RESP_FUNC_SUCC.
> Add a condition for TMF_RESP_FUNC_SUCC to
> hisi_sas_exec_internal_tmf_task().
> This affects query tmf, as the result is success
> the returned value was for failure.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 73f581f..85c73d3 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -744,6 +744,12 @@ static int hisi_sas_exec_internal_tmf_task(struct 
> domain_device *device,
>   }
>  
>   if (task->task_status.resp == SAS_TASK_COMPLETE &&
> + task->task_status.stat == TMF_RESP_FUNC_SUCC) {
> + res = TMF_RESP_FUNC_SUCC;
> + break;
> + }
> +
> + if (task->task_status.resp == SAS_TASK_COMPLETE &&
> task->task_status.stat == SAS_DATA_UNDERRUN) {
>   /* no error, but return the number of bytes of
>* underrun
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 6/8] hisi_sas: fail tmf task prep when port detached

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> When the port is detached we cannot execute a TMF,
> as there can be no device attached to the port.
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 280a19d..73f581f 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -204,7 +204,7 @@ static int hisi_sas_task_prep(struct sas_task *task, 
> struct hisi_hba *hisi_hba,
>   return rc;
>   }
>   port = device->port->lldd_port;
> - if (port && !port->port_attached && !tmf) {
> + if (port && !port->port_attached) {
>   if (sas_protocol_ata(task->task_proto)) {
>   struct task_status_struct *ts = >task_status;
>  
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[tip:x86/asm] ftrace/x86: Implement HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

[tip-bot for Josh Poimboeuf]

Commit-ID:  471bd10f5e2880bd91a2627d887f6062494cfe9c
Gitweb: http://git.kernel.org/tip/471bd10f5e2880bd91a2627d887f6062494cfe9c
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:53:00 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:15 +0200

ftrace/x86: Implement HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

Use the more reliable version of ftrace_graph_ret_addr() so we no longer
have to worry about the unwinder getting out of sync with the function
graph ret_stack index, which can happen if the unwinder skips any frames
before calling ftrace_graph_ret_addr().

This fixes this issue (and several others like it):

  $ cat /proc/self/stack
  [] save_stack_trace_tsk+0x22/0x40
  [] proc_pid_stack+0xb9/0x110
  [] proc_single_show+0x54/0x80
  [] seq_read+0x108/0x3e0
  [] __vfs_read+0x37/0x140
  [] vfs_read+0x99/0x140
  [] SyS_read+0x58/0xc0
  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
  [] 0x

  $ echo function_graph > /sys/kernel/debug/tracing/current_tracer

  $ cat /proc/self/stack
  [] return_to_handler+0x0/0x27
  [] print_context_stack+0xfc/0x100
  [] return_to_handler+0x0/0x27
  [] dump_trace+0x12b/0x350
  [] return_to_handler+0x0/0x27
  [] save_stack_trace_tsk+0x22/0x40
  [] return_to_handler+0x0/0x27
  [] proc_pid_stack+0xb9/0x110
  [] return_to_handler+0x0/0x27
  [] proc_single_show+0x54/0x80
  [] return_to_handler+0x0/0x27
  [] seq_read+0x108/0x3e0
  [] return_to_handler+0x0/0x27
  [] __vfs_read+0x37/0x140
  [] return_to_handler+0x0/0x27
  [] vfs_read+0x99/0x140
  [] 0x

Enabling function graph tracing causes the stack trace to change in two
ways:

First, the real call addresses are confusingly interspersed with
'return_to_handler' addresses.  This issue will be fixed by the next
patch.

Second, the stack trace is offset by two frames, because the unwinder
skipped the first two frames and got out of sync with the ret_stack
index.  This patch fixes this issue.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/a6d623e36f8d08f9a17bd74d804d201177a23afd.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/ftrace.h | 2 ++
 arch/x86/kernel/ftrace.c  | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 37f67cb..eccd0ac 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -14,6 +14,8 @@
 #define ARCH_SUPPORTS_FTRACE_OPS 1
 #endif
 
+#define HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
+
 #ifndef __ASSEMBLY__
 extern void mcount(void);
 extern atomic_t modifying_ftrace_code;
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index ae3b1fb..8639bb2 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -1029,7 +1029,7 @@ void prepare_ftrace_return(unsigned long self_addr, 
unsigned long *parent,
}
 
if (ftrace_push_return_trace(old, self_addr, ,
-frame_pointer, NULL) == -EBUSY) {
+frame_pointer, parent) == -EBUSY) {
*parent = old;
return;
}

[tip:x86/asm] sched/x86: Pass kernel thread parameters in 'struct fork_frame'

[tip-bot for Brian Gerst]

Commit-ID:  616d24835eeafa8ef3466479db028abfdfc77531
Gitweb: http://git.kernel.org/tip/616d24835eeafa8ef3466479db028abfdfc77531
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:20 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:50 +0200

sched/x86: Pass kernel thread parameters in 'struct fork_frame'

Instead of setting up a fake pt_regs context, put the kernel thread
function pointer and arg into the unused callee-restored registers
of 'struct fork_frame'.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-6-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/entry_32.S| 31 +++
 arch/x86/entry/entry_64.S| 37 +
 arch/x86/include/asm/switch_to.h |  2 ++
 arch/x86/kernel/process_32.c | 18 --
 arch/x86/kernel/process_64.c | 12 +++-
 5 files changed, 41 insertions(+), 59 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index bf8f221..b75a8bc 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -240,35 +240,34 @@ END(__switch_to_asm)
  * A newly forked process directly context switches into this address.
  *
  * eax: prev task we switched from
+ * ebx: kernel thread func (NULL for user thread)
+ * edi: kernel thread arg
  */
 ENTRY(ret_from_fork)
pushl   %eax
callschedule_tail
popl%eax
 
+   testl   %ebx, %ebx
+   jnz 1f  /* kernel threads are uncommon */
+
+2:
/* When we fork, we trace the syscall return in the child, too. */
movl%esp, %eax
callsyscall_return_slowpath
jmp restore_all
-END(ret_from_fork)
-
-ENTRY(ret_from_kernel_thread)
-   pushl   %eax
-   callschedule_tail
-   popl%eax
-   movlPT_EBP(%esp), %eax
-   call*PT_EBX(%esp)
-   movl$0, PT_EAX(%esp)
 
+   /* kernel thread */
+1: movl%edi, %eax
+   call*%ebx
/*
-* Kernel threads return to userspace as if returning from a syscall.
-* We should check whether anything actually uses this path and, if so,
-* consider switching it over to ret_from_fork.
+* A kernel thread is allowed to return here after successfully
+* calling do_execve().  Exit to userspace to complete the execve()
+* syscall.
 */
-   movl%esp, %eax
-   callsyscall_return_slowpath
-   jmp restore_all
-ENDPROC(ret_from_kernel_thread)
+   movl$0, PT_EAX(%esp)
+   jmp 2b
+END(ret_from_fork)
 
 /*
  * Return to user mode is not as complex as all this looks,
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index c1af8ac..c0373d6 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -407,37 +407,34 @@ END(__switch_to_asm)
  * A newly forked process directly context switches into this address.
  *
  * rax: prev task we switched from
+ * rbx: kernel thread func (NULL for user thread)
+ * r12: kernel thread arg
  */
 ENTRY(ret_from_fork)
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
 
-   testb   $3, CS(%rsp)/* from kernel_thread? */
-   jnz 1f
-
-   /*
-* We came from kernel_thread.  This code path is quite twisted, and
-* someone should clean it up.
-*
-* copy_thread_tls stashes the function pointer in RBX and the
-* parameter to be passed in RBP.  The called function is permitted
-* to call do_execve and thereby jump to user mode.
-*/
-   movqRBP(%rsp), %rdi
-   call*RBX(%rsp)
-   movl$0, RAX(%rsp)
-
-   /*
-* Fall through as though we're exiting a syscall.  This makes a
-* twisted sort of sense if we just called do_execve.
-*/
+   testq   %rbx, %rbx  /* from kernel_thread? */
+   jnz 1f  /* kernel threads are uncommon 
*/
 
-1:
+2:
movq%rsp, %rdi
callsyscall_return_slowpath /* returns with IRQs disabled */
TRACE_IRQS_ON   /* user mode is traced as IRQS on */
SWAPGS
jmp restore_regs_and_iret
+
+1:
+   /* kernel thread */
+   movq%r12, %rdi
+   call*%rbx
+   /*
+* A kernel thread is allowed to return here after successfully
+* calling do_execve().  Exit to userspace to complete 

[tip:x86/asm] sched/x86: Add 'struct inactive_task_frame' to better document the sleeping task stack frame

[tip-bot for Brian Gerst]

Commit-ID:  7b32aeadbc95d4a41402c1c0da6aa3ab51af4c10
Gitweb: http://git.kernel.org/tip/7b32aeadbc95d4a41402c1c0da6aa3ab51af4c10
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:18 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:27:41 +0200

sched/x86: Add 'struct inactive_task_frame' to better document the sleeping 
task stack frame

Add 'struct inactive_task_frame', which defines the layout of the stack for
a sleeping process.  For now, the only defined field is the BP register
(frame pointer).

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-4-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/stacktrace.h | 4 ++--
 arch/x86/include/asm/switch_to.h  | 5 +
 arch/x86/kernel/kgdb.c| 3 ++-
 arch/x86/kernel/process.c | 3 ++-
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/stacktrace.h 
b/arch/x86/include/asm/stacktrace.h
index 0944218..7646fb2 100644
--- a/arch/x86/include/asm/stacktrace.h
+++ b/arch/x86/include/asm/stacktrace.h
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 
 extern int kstack_depth_to_print;
 
@@ -70,8 +71,7 @@ stack_frame(struct task_struct *task, struct pt_regs *regs)
return bp;
}
 
-   /* bp is the last reg pushed by switch_to */
-   return *(unsigned long *)task->thread.sp;
+   return ((struct inactive_task_frame *)task->thread.sp)->bp;
 }
 #else
 static inline unsigned long
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 14e4b20..ec689c6 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -30,6 +30,11 @@ static inline void prepare_switch_to(struct task_struct 
*prev,
 #endif
 }
 
+/* data that is pointed to by thread.sp */
+struct inactive_task_frame {
+   unsigned long bp;
+};
+
 #ifdef CONFIG_X86_32
 
 #ifdef CONFIG_CC_STACKPROTECTOR
diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 5e3f294..8e36f24 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dbg_reg_def_t dbg_reg_def[DBG_MAX_REG_NUM] =
 {
@@ -166,7 +167,7 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_DX]= 0;
gdb_regs[GDB_SI]= 0;
gdb_regs[GDB_DI]= 0;
-   gdb_regs[GDB_BP]= *(unsigned long *)p->thread.sp;
+   gdb_regs[GDB_BP]= ((struct inactive_task_frame 
*)p->thread.sp)->bp;
 #ifdef CONFIG_X86_32
gdb_regs[GDB_DS]= __KERNEL_DS;
gdb_regs[GDB_ES]= __KERNEL_DS;
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 62c0b0e..0115a4a 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -556,7 +557,7 @@ unsigned long get_wchan(struct task_struct *p)
if (sp < bottom || sp > top)
return 0;
 
-   fp = READ_ONCE_NOCHECK(*(unsigned long *)sp);
+   fp = READ_ONCE_NOCHECK(((struct inactive_task_frame *)sp)->bp);
do {
if (fp < bottom || fp > top)
return 0;

Re: [PATCH] hw_random: omap3-rom-rng.c: Remove obsoleted functions

[Herbert Xu]

On Sat, Aug 20, 2016 at 09:31:06PM +0530, PrasannaKumar Muralidharan wrote:
> Remove omap3_rom_rng_data_present method as it was returning 1 always.
> Use .read callback instead of .data_read callback. This avoids use of
> obsolete callbacks.
> 
> This patch is not tested with hardware as I don't have access to it.
> 
> Signed-off-by: PrasannaKumar Muralidharan 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Jani Nikula]

On Wed, 24 Aug 2016, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
>   drivers/gpu/drm/i915/intel_display.c
>
> between commits from the drm-intel-fixes tree (some of which are
> cherry-picked from the drm-intel tree) and teh same and other commits
> from the drm-inte tree.  These are just going to cause new conflicts
> every time you touch this file again in either tree (which happens a
> lot :-().
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider only putting
> the fix patches into the drm-intel-fixes tree and then getting them
> into the drm-intel tree by merging the -fixes tree instead of
> cherry-picking them the other way.

We used to do that, but switched to the current model instead. The main
reason was that we wanted our development branch to always get the fixes
first, without delay. We have several committers, and we want to make it
efficient and hassle free for them to get fixes applied.

The drm-intel tree is a fast moving target. If we fix something in
-fixes, there's no guarantee the fix applies to -next. It is more
important that we get the fix in -next, and all future kernels. If the
fix is important for current and stable kernels, we can do the
backport. This way, we can always resolve conflicts with the code in
-next, and be sure it contains all the fixes. If only -fixes had the
fixes, we'd have nightmare conflict resolutions trying to ensure none of
the fixes get dropped while merging.

Finally, you don't always know in advance whether the patch should be
applied to -next or -fixes. We'd end up with cherry-picks like this
anyway. Now we can do QA on the fixes in -next, and choose the ones to
backport.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

[Mark Hounschell]

On 08/18/2016 09:59 AM, Greg Kroah-Hartman wrote:

4.7-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Kosina 

commit ff06db1efb2ad6db06eb5b99b88a0c15a9cc9b0e upstream.

Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
this is being used setfdprm userspace for ioctl-only open().

Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
modes, while still keeping the original O_NDELAY bug fixed.

Reported-by: Wim Osterholt 
Tested-by: Wim Osterholt 
Signed-off-by: Jiri Kosina 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/block/floppy.c |   21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3663,11 +3663,6 @@ 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) {
@@ -3711,13 +3706,15 @@ static int floppy_open(struct block_devi
if (UFDCS->rawcmd == 1)
UFDCS->rawcmd = 2;

-   UDRS->last_checked = 0;
-   clear_bit(FD_OPEN_SHOULD_FAIL_BIT, >flags);
-   check_disk_change(bdev);
-   if (test_bit(FD_DISK_CHANGED_BIT, >flags))
-   goto out;
-   if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, >flags))
-   goto out;
+   if (mode & (FMODE_READ|FMODE_WRITE)) {
+   UDRS->last_checked = 0;
+   clear_bit(FD_OPEN_SHOULD_FAIL_BIT, >flags);
+   check_disk_change(bdev);
+   if (test_bit(FD_DISK_CHANGED_BIT, >flags))
+   goto out;
+   if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, >flags))
+   goto out;
+   }

res = -EROFS;






I have a problem with this patch. It only fixes one of the regressions 
caused by the original change to the floppy driver. It does not address 
the user land breakage of removing the NODELAY flag checks.


Thanks
Mark

[PATCH] reset: warn on invalid input to reset_control_reset/assert/deassert/status

[Philipp Zabel]

Instead of potentially crashing, dump a backtrace and return -EINVAL if
rstc is NULL or an error code.

Signed-off-by: Philipp Zabel 
---
 drivers/reset/core.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 395dc9c..b8ae1db 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -138,7 +138,8 @@ EXPORT_SYMBOL_GPL(devm_reset_controller_register);
  */
 int reset_control_reset(struct reset_control *rstc)
 {
-   if (WARN_ON(rstc->shared))
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)) ||
+   WARN_ON(rstc->shared))
return -EINVAL;
 
if (rstc->rcdev->ops->reset)
@@ -161,6 +162,9 @@ EXPORT_SYMBOL_GPL(reset_control_reset);
  */
 int reset_control_assert(struct reset_control *rstc)
 {
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)))
+   return -EINVAL;
+
if (!rstc->rcdev->ops->assert)
return -ENOTSUPP;
 
@@ -184,6 +188,9 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
  */
 int reset_control_deassert(struct reset_control *rstc)
 {
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)))
+   return -EINVAL;
+
if (!rstc->rcdev->ops->deassert)
return -ENOTSUPP;
 
@@ -204,6 +211,9 @@ EXPORT_SYMBOL_GPL(reset_control_deassert);
  */
 int reset_control_status(struct reset_control *rstc)
 {
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)))
+   return -EINVAL;
+
if (rstc->rcdev->ops->status)
return rstc->rcdev->ops->status(rstc->rcdev, rstc->id);
 
-- 
2.8.1

[tip:x86/asm] sched/x86/64, kgdb: Clear GDB_PS on 64-bit

[tip-bot for Brian Gerst]

Commit-ID:  163630191ecb0dd9e4146d3c910045aba1cfeec1
Gitweb: http://git.kernel.org/tip/163630191ecb0dd9e4146d3c910045aba1cfeec1
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:17 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:27:40 +0200

sched/x86/64, kgdb: Clear GDB_PS on 64-bit

switch_to() no longer saves EFLAGS, so it's bogus to look for it on the
stack.  Set it to zero like 32-bit.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jason Wessel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-3-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/kgdb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index fe649a5..5e3f294 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -176,7 +176,7 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_FS]= 0x;
gdb_regs[GDB_GS]= 0x;
 #else
-   gdb_regs32[GDB_PS]  = *(unsigned long *)(p->thread.sp + 8);
+   gdb_regs32[GDB_PS]  = 0;
gdb_regs32[GDB_CS]  = __KERNEL_CS;
gdb_regs32[GDB_SS]  = __KERNEL_DS;
gdb_regs[GDB_R8]= 0;

[tip:x86/asm] x86/dumpstack/ftrace: Don't print unreliable addresses in print_context_stack_bp()

[tip-bot for Josh Poimboeuf]

Commit-ID:  13e25bab7e51bdd4ba7df1ef2388961294bb565e
Gitweb: http://git.kernel.org/tip/13e25bab7e51bdd4ba7df1ef2388961294bb565e
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:53:02 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:15 +0200

x86/dumpstack/ftrace: Don't print unreliable addresses in 
print_context_stack_bp()

When function graph tracing is enabled, print_context_stack_bp() can
report return_to_handler() as an unreliable address, which is confusing
and misleading: return_to_handler() is really only useful as a hint for
debugging, whereas print_context_stack_bp() users only care about the
actual 'reliable' call path.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/c51aef578d8027791b38d2ad9bac0c7f499fde91.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 6aad8d4..01072e9 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -126,8 +126,6 @@ print_context_stack_bp(struct task_struct *task,
break;
 
real_addr = ftrace_graph_ret_addr(task, graph, addr, retp);
-   if (real_addr != addr && ops->address(data, addr, 0))
-   break;
if (ops->address(data, real_addr, 1))
break;
 

[tip:x86/asm] sched/x86/32, kgdb: Don't use thread.ip in sleeping_thread_to_gdb_regs()

[tip-bot for Brian Gerst]

Commit-ID:  4e047aa7f267c3449b6d323510d35864829aca70
Gitweb: http://git.kernel.org/tip/4e047aa7f267c3449b6d323510d35864829aca70
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:16 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:27:40 +0200

sched/x86/32, kgdb: Don't use thread.ip in sleeping_thread_to_gdb_regs()

Match 64-bit and set gdb_regs[GDB_PC] to zero.  thread.ip is always the
same point in the scheduler (except for newly forked processes), and will
be removed in a future patch.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jason Wessel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-2-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/kgdb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 04cde52..fe649a5 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -172,7 +172,6 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_ES]= __KERNEL_DS;
gdb_regs[GDB_PS]= 0;
gdb_regs[GDB_CS]= __KERNEL_CS;
-   gdb_regs[GDB_PC]= p->thread.ip;
gdb_regs[GDB_SS]= __KERNEL_DS;
gdb_regs[GDB_FS]= 0x;
gdb_regs[GDB_GS]= 0x;
@@ -180,7 +179,6 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs32[GDB_PS]  = *(unsigned long *)(p->thread.sp + 8);
gdb_regs32[GDB_CS]  = __KERNEL_CS;
gdb_regs32[GDB_SS]  = __KERNEL_DS;
-   gdb_regs[GDB_PC]= 0;
gdb_regs[GDB_R8]= 0;
gdb_regs[GDB_R9]= 0;
gdb_regs[GDB_R10]   = 0;
@@ -190,6 +188,7 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_R14]   = 0;
gdb_regs[GDB_R15]   = 0;
 #endif
+   gdb_regs[GDB_PC]= 0;
gdb_regs[GDB_SP]= p->thread.sp;
 }
 

Re: [RFC PATCH 0/3] UART slave device bus

[One Thousand Gnomes]

> So you mean if I do "hciconfig hci0 down", then the uart-bus should
> "down" the tty and only on "hciconfig hci0 up" it should "up" the
> tty? I would expect a uart-bus slave-device takes control of the
> device ("up" it) on probe. It's hardwired anyway.

Today you can switch stacks at runtime, you can switch between the kernel
stack and debug tools at runtime. Breaking that is a regression.

> Also what should happen if old userspace use hciattach while
> uart-bus slave-device doesn't have control over it? Do you

You would either use the old hciattach in which case you wouldn't be able
to manage it via a new API while attached, or the new API in which case
you wouldn't be able to manage it via the old interface while it was
being used directly.

> Or do you suggest to register hci1 and one cannot use hci0? I guess
> this breaks even more devices, as the device number changes.

Device numbers are dynamic anyway. Plug a USB adapter in and if it beats
your onboard adapter to registration then the order changes.

> So yes, from your point of view there is a regression, just because
> it's working automatically. So let's just not convert existing boards
> with working hciattach based bluetooth devices. New devices can use

>From a distribution point of view that would be a nightmare.

> the uart-bus, as it's not a regression for them and Nokia N series
> can also do it, since they have no working bluetooth at all at the
> moment.

The Nokia N series is a weird corner case.

> > In many cases you'll also still need the tty interface to do
> > things like firmware upgrades.  
> 
> I would expect the uart-slave driver to know how to do firmware
> updates. Actually most bluetooth chips are initialized by uploading
> a firmware to them.

Usually no - you don't want a ton of kernel code for flashing adapters
when they have built in firmware (similar issue for 3G modems)

> And there are definitely uart drivers not caring about having a tty
> device. Nokia's vendor driver for their bluetooth protocol contains
> a custom omap-serial driver combined with the actual bluetooth
> driver. There is nothing related to the tty framework. I think the
> same would work for the other hardwired bluetooth chips perfectly
> fine.

That means having two different omap serial drivers to maintain which is
not ideal.

To me there are four different things

1. bluetooth devices "just work". That can be user space (eg it seems to
just work on my Fedora boxes and bluetooth enumeration is being done via
user space, or may be via kernel enumeration, or a mix. PPP is an
existing example of this - serial port PPP is an ldisc but ports that are
not UART like speak directly to the PPP layer as network adapters.

2. Sideband controls and power management, where we need to give the
tty_port a child device and power it up/down properly and have the
tty_port hooks to do so based upon the ldisc protocol state machine when
talking stuff like NMEA or HCI.

3. The special case UART power saving features/hacks like GPIO snooping,
again with the right hooks

4. Whether it's useful to be able to create a tty device in kernel and
attach that to stuff with no userspace involved.

All are independent.

Alan

Re: [PATCH v2 1/2] pinctrl: meson-gxbb: add pins for PWM

[Linus Walleij]

On Tue, Aug 23, 2016 at 1:25 PM, Neil Armstrong  wrote:

> Add support for PWM pins, for EE and AO domains.
>
> Signed-off-by: Neil Armstrong 

Patch applied!

Yours,
Linus Walleij

Re: [RFC PATCH 2/4] perf-probe: Add offline output directory option

[Arnaldo Carvalho de Melo]

Em Wed, Aug 24, 2016 at 02:58:12PM +0900, Masami Hiramatsu escreveu:
> Add offline output direcrtory option. This allows user to
> store probe event definition in offline output directory.

In such cases you should show it in action, like I am doing now to test
this patch:

  [root@jouet ~]# perf probe --outdir=my_probes do_open
  kprobe_events file does not exist - please rebuild kernel with 
CONFIG_KPROBE_EVENTS.
Error: Failed to add events.
  [root@jouet ~]# 

Oops, misleading error message, probably I need to first do a mkdir:

  [root@jouet ~]# mkdir my_probes
  [root@jouet ~]# perf probe --outdir=my_probes do_open
  Added new event:
probe:do_open(on do_open)

  You can now use it in all perf tools, such as:

  perf record -e probe:do_open -aR sleep 1

  [root@jouet ~]# ls -la my_probes
  total 12
  drwxr-xr-x.  2 root root 4096 Aug 24 09:47 .
  dr-xr-x---. 31 root root 4096 Aug 24 09:47 ..
  -rw-r--r--.  1 root root   30 Aug 24 09:47 kprobe_events
  [root@jouet ~]# cat my_probes/kprobe_events 
  p:probe/do_open _text+3481584
  [root@jouet ~]# 

Wouldn't it be better to call it some other name and imply --dry-run? "outdir"
seems too vague. Perhaps --definition and instead have it run like:

  # perf probe --definition do_open
  p:probe/do_open _text+3481584
  #

Then one could even use it to redirect it to a file, tee + file and even test 
it as:

  # perf probe --definition do_open > /sys/kernel/debug/tracing/kprobe_events
  #

For debugging:

  # perf probe --definition do_open | tee 
/sys/kernel/debug/tracing/kprobe_events

:-)

I picked "--kprobes" first, but that would left out e.g. uprobes, then I
thought about --event, but also sounds vague, read
Documentation/trace/kprobetrace.txt and saw this bit:

 ---
Usage examples
--
To add a probe as a new event, write a new definition to kprobe_events
as below.

  echo 'p:myprobe do_sys_open dfd=%ax filename=%dx flags=%cx mode=+4($stack)' > 
/sys/kernel/debug/tracing/kprobe_events
 ---

So you used "definition" for that string, might as well be consistent and use
it here as well.

Also please fix the OPT_STRING string, it should start with a capital
letter:

--max-probes   Set how many probe points can be found for a probe.
--no-inlines  Don't search inlined functions
--outdir 
  path to offline output directory
--range   Show variables location range in scope (with --vars 
only)


See how it stands out? All the others start with a capital letter.

I applied the first patch, totally trivial.

- Arnaldo
 
> Signed-off-by: Masami Hiramatsu 
> ---
>  tools/perf/builtin-probe.c|2 ++
>  tools/perf/util/probe-event.h |1 +
>  tools/perf/util/probe-file.c  |   19 ---
>  3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
> index ee5b421..5b45ec8 100644
> --- a/tools/perf/builtin-probe.c
> +++ b/tools/perf/builtin-probe.c
> @@ -517,6 +517,8 @@ __cmd_probe(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>   "Show variables location range in scope (with --vars only)"),
>   OPT_STRING('k', "vmlinux", _conf.vmlinux_name,
>  "file", "vmlinux pathname"),
> + OPT_STRING(0, "outdir", _conf.output_dir,
> + "directory", "path to offline output directory"),
>   OPT_STRING('s', "source", _conf.source_prefix,
>  "directory", "path to kernel source"),
>   OPT_BOOLEAN('\0', "no-inlines", _conf.no_inlines,
> diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
> index f4f45db..75b572a 100644
> --- a/tools/perf/util/probe-event.h
> +++ b/tools/perf/util/probe-event.h
> @@ -14,6 +14,7 @@ struct probe_conf {
>   boolno_inlines;
>   boolcache;
>   int max_probes;
> + const char  *output_dir;
>  };
>  extern struct probe_conf probe_conf;
>  extern bool probe_event_dry_run;
> diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
> index 6f931e4..41db430 100644
> --- a/tools/perf/util/probe-file.c
> +++ b/tools/perf/util/probe-file.c
> @@ -73,16 +73,25 @@ static void print_both_open_warning(int kerr, int uerr)
>  static int open_probe_events(const char *trace_file, bool readwrite)
>  {
>   char buf[PATH_MAX];
> + const char *tracing_dir = tracing_path;
> + int oflag = 0;
> + mode_t mode = 0;
>   int ret;
>  
> + if (probe_conf.output_dir) {
> + tracing_dir = probe_conf.output_dir;
> + oflag = O_CREAT;
> + mode = 0644;
> + }
> +
>   ret = e_snprintf(buf, PATH_MAX, "%s/%s",
> -  tracing_path, trace_file);
> +  tracing_dir, trace_file);
>   if (ret >= 0) {
>   pr_debug("Opening %s write=%d\n", buf, readwrite);
>   if (readwrite && !probe_event_dry_run)
> - 

Re: [PATCH] hw_random: Improve description of the ->read() interface

[Herbert Xu]

On Thu, Aug 18, 2016 at 01:37:21PM +0100, Daniel Thompson wrote:
> Currently, very few RNG drivers support single byte reads using the
> ->read() interface. Of the 14 drivers in drivers/char/hw_random that
> support this interface only three of these actually support max == 1.
> The other behaviours vary between return 0, return 2, return 4 and return
> -EIO).
> 
> This is not a problem in practice because the core hw_random code never
> performs a read shorter than 16 bytes. The documentation for this function
> already contrains the alignment of the buffer pointer, so let's also
> guarantee that the buffer is at least as large as its alignment.
> 
> This constraint is intended to be the weakest guarantee neccessary to
> allow driver writers to safely simplify their code.
> 
> Signed-off-by: Daniel Thompson 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [BUGFIX, 1/2] brcmfmac: Check rtnl_lock is locked when removing interface

[Kalle Valo]

mhira...@kernel.org wrote:
> Check rtnl_lock is locked in brcmf_p2p_ifp_removed() by passing
> rtnl_locked flag. Actually the caller brcmf_del_if() checks whether
> the rtnl_lock is locked, but doesn't pass it to brcmf_p2p_ifp_removed().
> 
> Without this fix, wpa_supplicant goes softlockup with rtnl_lock
> holding (this means all other process using netlink are locked up too)
> 
> e.g.
> [ 4495.876627] INFO: task wpa_supplicant:7307 blocked for more than 10 
> seconds.
> [ 4495.876632]   Tainted: GW   4.8.0-rc1+ #8
> [ 4495.876635] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 4495.876638] wpa_supplicant  D 974c647b39a0 0  7307  1 
> 0x
> [ 4495.876644]  974c647b39a0  974c 
> 974c7dc59c58
> [ 4495.876651]  974c6b7417c0 974c645017c0 974c647b4000 
> 86f16c08
> [ 4495.876657]  974c645017c0 0246  
> 974c647b39b8
> [ 4495.876664] Call Trace:
> [ 4495.876671]  [] schedule+0x3c/0x90
> [ 4495.876676]  [] schedule_preempt_disabled+0x15/0x20
> [ 4495.876682]  [] mutex_lock_nested+0x176/0x3b0
> [ 4495.876686]  [] ? rtnl_lock+0x17/0x20
> [ 4495.876690]  [] rtnl_lock+0x17/0x20
> [ 4495.876720]  [] brcmf_p2p_ifp_removed+0x4d/0x70 
> [brcmfmac]
> [ 4495.876741]  [] brcmf_remove_interface+0x196/0x1b0 
> [brcmfmac]
> [ 4495.876760]  [] brcmf_p2p_del_vif+0x111/0x220 [brcmfmac]
> [ 4495.876777]  [] brcmf_cfg80211_del_iface+0x21b/0x270 
> [brcmfmac]
> [ 4495.876820]  [] nl80211_del_interface+0xfe/0x3a0 
> [cfg80211]
> [ 4495.876825]  [] genl_family_rcv_msg+0x1b5/0x370
> [ 4495.876832]  [] ? trace_hardirqs_on+0xd/0x10
> [ 4495.876836]  [] genl_rcv_msg+0x7d/0xb0
> [ 4495.876839]  [] ? genl_family_rcv_msg+0x370/0x370
> [ 4495.876846]  [] netlink_rcv_skb+0x97/0xb0
> [ 4495.876849]  [] genl_rcv+0x28/0x40
> [ 4495.876854]  [] netlink_unicast+0x1d3/0x2f0
> [ 4495.876860]  [] ? netlink_unicast+0x14b/0x2f0
> [ 4495.876866]  [] netlink_sendmsg+0x2eb/0x3a0
> [ 4495.876870]  [] sock_sendmsg+0x38/0x50
> [ 4495.876874]  [] ___sys_sendmsg+0x27f/0x290
> [ 4495.876882]  [] ? mntput_no_expire+0x5/0x3f0
> [ 4495.876888]  [] ? mntput_no_expire+0x8e/0x3f0
> [ 4495.876894]  [] ? mntput_no_expire+0x5/0x3f0
> [ 4495.876899]  [] ? mntput+0x24/0x40
> [ 4495.876904]  [] ? __fput+0x190/0x200
> [ 4495.876909]  [] __sys_sendmsg+0x45/0x80
> [ 4495.876914]  [] SyS_sendmsg+0x12/0x20
> [ 4495.876918]  [] entry_SYSCALL_64_fastpath+0x23/0xc1
> [ 4495.876924]  [] ? trace_hardirqs_off_caller+0x1f/0xc0
> 
> Signed-off-by: Masami Hiramatsu 
> Acked-by: Rafał Miłecki 

Thanks, 2 patches applied to wireless-drivers.git:

15dacf880e49 brcmfmac: Check rtnl_lock is locked when removing interface
b64abcb7dae6 brcmfmac: Change vif_event_lock to spinlock

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9280681/

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

[Eric Dumazet]

On Wed, 2016-08-24 at 06:07 -0700, Eric Dumazet wrote:

> I am afraid you could live lock here on SMP.
> 
> You should make sure you do not loop forever, not assuming cpu is faster
> than NIC.

You are protected by the tx_lock spinlock, but this is fragile as you
could very well remove this spinlock in the future to get lockless
transmit, like many other drivers.

[PATCH v3 5/5] gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer

[Milo Kim]

The helper, devm_regulator_bulk_get() initializes the consumer as NULL,
so this code can be ignored.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 249cb23..4e17877f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1669,10 +1669,9 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
if (ret)
return ret;
 
-   for (i = 0; i < ARRAY_SIZE(supply); ++i) {
+   for (i = 0; i < ARRAY_SIZE(supply); ++i)
hdata->regul_bulk[i].supply = supply[i];
-   hdata->regul_bulk[i].consumer = NULL;
-   }
+
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), 
hdata->regul_bulk);
if (ret) {
if (ret != -EPROBE_DEFER)
-- 
1.9.1

[PATCH v3 4/5] gpu: drm: exynos_hdmi: Move PHY logic into single function

[Milo Kim]

Paring DT properties and getting PHY IO (memory mapped or I2C) in one function.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 63 +++-
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8d99b5d..249cb23 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1790,16 +1790,44 @@ static int hdmi_get_ddc_adapter(struct hdmi_context 
*hdata)
return 0;
 }
 
-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static int hdmi_get_phy_io(struct hdmi_context *hdata)
 {
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+   struct device_node *np;
+   int ret = 0;
+
+   np = of_find_compatible_node(NULL, NULL, compatible_str);
+   if (!np) {
+   np = of_parse_phandle(hdata->dev->of_node, "phy", 0);
+   if (!np) {
+   DRM_ERROR("Failed to find hdmiphy node in device 
tree\n");
+   return -ENODEV;
+   }
+   }
+
+   if (hdata->drv_data->is_apb_phy) {
+   hdata->regs_hdmiphy = of_iomap(np, 0);
+   if (!hdata->regs_hdmiphy) {
+   DRM_ERROR("failed to ioremap hdmi phy\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+   } else {
+   hdata->hdmiphy_port = of_find_i2c_device_by_node(np);
+   if (!hdata->hdmiphy_port) {
+   DRM_ERROR("Failed to get hdmi phy i2c client\n");
+   ret = -EPROBE_DEFER;
+   goto out;
+   }
+   }
 
-   return of_find_compatible_node(NULL, NULL, compatible_str);
+out:
+   of_node_put(np);
+   return ret;
 }
 
 static int hdmi_probe(struct platform_device *pdev)
 {
-   struct device_node *phy_node;
struct device *dev = >dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1833,34 +1861,9 @@ static int hdmi_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   phy_node = hdmi_legacy_phy_dt_binding(dev);
-   if (phy_node)
-   goto out_get_phy_port;
-
-   phy_node = of_parse_phandle(dev->of_node, "phy", 0);
-   if (!phy_node) {
-   DRM_ERROR("Failed to find hdmiphy node in device tree\n");
-   ret = -ENODEV;
+   ret = hdmi_get_phy_io(hdata);
+   if (ret)
goto err_ddc;
-   }
-   of_node_put(dev->of_node);
-
-out_get_phy_port:
-   if (hdata->drv_data->is_apb_phy) {
-   hdata->regs_hdmiphy = of_iomap(phy_node, 0);
-   if (!hdata->regs_hdmiphy) {
-   DRM_ERROR("failed to ioremap hdmi phy\n");
-   ret = -ENOMEM;
-   goto err_ddc;
-   }
-   } else {
-   hdata->hdmiphy_port = of_find_i2c_device_by_node(phy_node);
-   if (!hdata->hdmiphy_port) {
-   DRM_ERROR("Failed to get hdmi phy i2c client\n");
-   ret = -EPROBE_DEFER;
-   goto err_ddc;
-   }
-   }
 
INIT_DELAYED_WORK(>hotplug_work, hdmi_hotplug_work_func);
 
-- 
1.9.1

[PATCH v2] Documentation: devicetree: changesets do locking on their own meanwhile

[Wolfram Sang]

Since commit 183223770ae862 ("drivers/of: Export OF changeset functions"),
the mentioned functions do all necessary locking.

Signed-off-by: Wolfram Sang 
Fixes: 183223770ae862 ("drivers/of: Export OF changeset functions")
---

V2: corrected the "Fixes" tag

 Documentation/devicetree/changesets.txt | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/changesets.txt 
b/Documentation/devicetree/changesets.txt
index 935ba5acc34e6c..cb488eeb635372 100644
--- a/Documentation/devicetree/changesets.txt
+++ b/Documentation/devicetree/changesets.txt
@@ -21,20 +21,11 @@ a set of changes. No changes to the active tree are made at 
this point.
 All the change operations are recorded in the of_changeset 'entries'
 list.
 
-3. mutex_lock(of_mutex) - starts a changeset; The global of_mutex
-ensures there can only be one editor at a time.
-
-4. of_changeset_apply() - Apply the changes to the tree. Either the
+3. of_changeset_apply() - Apply the changes to the tree. Either the
 entire changeset will get applied, or if there is an error the tree will
-be restored to the previous state
-
-5. mutex_unlock(of_mutex) - All operations complete, release the mutex
+be restored to the previous state. The core ensures proper serialization
+through locking. An unlocked version __of_changeset_apply is available,
+if needed.
 
 If a successfully applied changeset needs to be removed, it can be done
-with the following sequence.
-
-1. mutex_lock(of_mutex)
-
-2. of_changeset_revert()
-
-3. mutex_unlock(of_mutex)
+with of_changeset_revert().
-- 
2.9.3

[PATCH] usbnet: ax88179_178a: Add support for writing the EEPROM

[Alban Bedel]

Implement the .set_eeprom callback to allow setting the MAC address
as well as a few other parameters. Note that the EEPROM must have a
correct PID/VID checksum set otherwise the SROM is used and reads
return the SROM content.

Signed-off-by: Alban Bedel 
---
 drivers/net/usb/ax88179_178a.c | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c16081a..e6a986303dad 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -28,6 +28,7 @@
 
 #define AX88179_PHY_ID 0x03
 #define AX_EEPROM_LEN  0x100
+#define AX_EEPROM_BLOCK0x40u
 #define AX88179_EEPROM_MAGIC   0x17900b95
 #define AX_MCAST_FLTSIZE   8
 #define AX_MAX_MCAST   64
@@ -43,6 +44,7 @@
 #define AX_ACCESS_PHY  0x02
 #define AX_ACCESS_EEPROM   0x04
 #define AX_ACCESS_EFUS 0x05
+#define AX_RELOAD_EEPROM   0x06
 #define AX_PAUSE_WATERLVL_HIGH 0x54
 #define AX_PAUSE_WATERLVL_LOW  0x55
 
@@ -620,6 +622,60 @@ ax88179_get_eeprom(struct net_device *net, struct 
ethtool_eeprom *eeprom,
return 0;
 }
 
+static int
+ax88179_set_eeprom(struct net_device *net, struct ethtool_eeprom *eeprom,
+  u8 *data)
+{
+   struct usbnet *dev = netdev_priv(net);
+   unsigned int offset = eeprom->offset;
+   unsigned int len = eeprom->len;
+   int i, err = 0;
+   u8 *block;
+
+   /* The EEPROM data must be aligned on blocks of 64 bytes */
+   if ((offset % AX_EEPROM_BLOCK) || (len % AX_EEPROM_BLOCK)) {
+   offset = eeprom->offset / AX_EEPROM_BLOCK * AX_EEPROM_BLOCK;
+   len = eeprom->len + eeprom->offset - offset;
+   len = DIV_ROUND_UP(len, AX_EEPROM_BLOCK) * AX_EEPROM_BLOCK;
+
+   block = kmalloc(len, GFP_KERNEL);
+   if (!block)
+   return -ENOMEM;
+
+   /* Copy the current data, we could skip some but KISS */
+   for (i = 0; i < len; i += AX_EEPROM_BLOCK) {
+   err = __ax88179_read_cmd(dev, AX_ACCESS_EEPROM,
+(offset + i) >> 1,
+AX_EEPROM_BLOCK >> 1,
+AX_EEPROM_BLOCK,
+[i], 0);
+   if (err < 0) {
+   kfree(block);
+   return err;
+   }
+   }
+   memcpy(block + eeprom->offset - offset, data, eeprom->len);
+   } else {
+   block = data;
+   }
+
+   for (i = 0; err >= 0 && i < len; i += AX_EEPROM_BLOCK) {
+   err = ax88179_write_cmd(dev, AX_ACCESS_EEPROM,
+   (offset + i) >> 1,
+   AX_EEPROM_BLOCK >> 1,
+   AX_EEPROM_BLOCK, [i]);
+   }
+
+   if (block != data)
+   kfree(block);
+
+   /* Reload the EEPROM */
+   if (err >= 0)
+   err = ax88179_write_cmd(dev, AX_RELOAD_EEPROM, 0, 0, 0, NULL);
+
+   return err < 0 ? err : 0;
+}
+
 static int ax88179_get_settings(struct net_device *net, struct ethtool_cmd 
*cmd)
 {
struct usbnet *dev = netdev_priv(net);
@@ -826,6 +882,7 @@ static const struct ethtool_ops ax88179_ethtool_ops = {
.set_wol= ax88179_set_wol,
.get_eeprom_len = ax88179_get_eeprom_len,
.get_eeprom = ax88179_get_eeprom,
+   .set_eeprom = ax88179_set_eeprom,
.get_settings   = ax88179_get_settings,
.set_settings   = ax88179_set_settings,
.get_eee= ax88179_get_eee,
-- 
2.9.3

Re: [PATCH] net: phy: micrel: remove suspend/resume

[Christophe Leroy]

Le 23/08/2016 à 21:03, Florian Fainelli a écrit :

+others,

On 08/23/2016 04:13 AM, Christophe Leroy wrote:

In ERRATA DS8700A dated 05 May 2016, Microship recommends to
not use software power down mode on KSZ8041 family.


s/Microship/Microchip/


They say they have no plan to fix this ERRATA in future releases.


The errata applies to specific revisions, is this revision present in
the lower 4 bits of the MII_PHYSID2 register such that it could be used
to key the disabling of the power down?


It doesn't seem clear to me how this could/should be handled.

According to the documentation, all variants have the same ID 0x0022151x 
with revision x. A3 has ID 0x00221512 and A4 has 0x00221513.
According to the doc, the KSZ8041RNLI should has same ID. But according 
to micrel driver, it has ID 0x00221537. And the buggy revision of that 
one is rev A. Is it what the 7 means ?


The ERRATA applies to KSZ8041NL revision A4 and to KSZ8041NL-AM revision 
A3. My understanding it that both variants have ID 0x0022151x, ie 
KSZ8041NL-AM revision A3 has ID 0x00221512 and KSZ8041NL revision A4 has 
ID 0x00221513. But KSZ8041NL revision A3 also has ID 0x00221512 and the 
ERRATA doesn't apply to it.


So what can be done really ? Only apply the fix to ID 0x00221513 (which 
is what I need as I have KSZ8041NL revision A4 on my boards) ? Or apply 
it for all KSZ8041 and KSZ8041RNLI to be on the safe side ?


Christophe






http://ww1.microchip.com/downloads/en/DeviceDoc/8700A.pdf

Signed-off-by: Christophe Leroy 
---
 drivers/net/phy/micrel.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 053e879..f456c55 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -837,8 +837,6 @@ static struct phy_driver ksphy_driver[] = {
.get_sset_count = kszphy_get_sset_count,
.get_strings= kszphy_get_strings,
.get_stats  = kszphy_get_stats,
-   .suspend= genphy_suspend,
-   .resume = genphy_resume,
 }, {
.phy_id = PHY_ID_KSZ8041RNLI,
.phy_id_mask= MICREL_PHY_ID_MASK,
@@ -856,8 +854,6 @@ static struct phy_driver ksphy_driver[] = {
.get_sset_count = kszphy_get_sset_count,
.get_strings= kszphy_get_strings,
.get_stats  = kszphy_get_stats,
-   .suspend= genphy_suspend,
-   .resume = genphy_resume,
 }, {
.phy_id = PHY_ID_KSZ8051,
.phy_id_mask= MICREL_PHY_ID_MASK,

Re: [PATCH 1/3] perf/x86/intel/bts: Fix confused ordering of PMU callbacks

[Alexander Shishkin]

Alexander Shishkin  writes:

> Alexander Shishkin  writes:
>
>> Signed-off-by: Alexander Shishkin 
>
> Ok, this one is broken, please disregard.

Vince, can you try the following (with the other two in this series)?

---

>From 68713194b3df8e565c4d319a80e9e7338fa1ec13 Mon Sep 17 00:00:00 2001
From: Alexander Shishkin 
Date: Tue, 23 Aug 2016 10:50:57 +0300
Subject: [PATCH] perf/x86/intel/bts: Fix confused ordering of PMU callbacks

The intel_bts driver is using a cpu-local 'started' variable to order
callbacks and PMIs and make sure that AUX transactions don't get messed
up. However, the ordering rules in regard to this variable is a complete
mess, which recently resulted in perf_fuzzer-triggered warnings and
panics.

The general ordering rule that is patch is enforcing is that this
cpu-local variable be set only when the cpu-local AUX transaction is
active; consequently, this variable is to be checked before the AUX
related bits can be touched.

Signed-off-by: Alexander Shishkin 
---
 arch/x86/events/intel/bts.c | 119 +++-
 1 file changed, 96 insertions(+), 23 deletions(-)

diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
index 0a6e393a2e..13ce76e895 100644
--- a/arch/x86/events/intel/bts.c
+++ b/arch/x86/events/intel/bts.c
@@ -31,7 +31,18 @@
 struct bts_ctx {
struct perf_output_handle   handle;
struct debug_store  ds_back;
-   int started;
+   local_t pmi_pending;
+   int state;
+};
+
+/* BTS context states: */
+enum {
+   /* no ongoing AUX transactions */
+   BTS_STATE_STOPPED = 0,
+   /* AUX transaction is on, BTS tracing is disabled */
+   BTS_STATE_INACTIVE,
+   /* AUX transaction is on, BTS tracing is running */
+   BTS_STATE_ACTIVE,
 };
 
 static DEFINE_PER_CPU(struct bts_ctx, bts_ctx);
@@ -191,6 +202,9 @@ static void bts_update(struct bts_ctx *bts)
if (ds->bts_index >= ds->bts_absolute_maximum)
local_inc(>lost);
 
+   if (ds->bts_index >= ds->bts_interrupt_threshold)
+   local_inc(>pmi_pending);
+
/*
 * old and head are always in the same physical buffer, so we
 * can subtract them to get the data size.
@@ -204,6 +218,16 @@ static void bts_update(struct bts_ctx *bts)
 static int
 bts_buffer_reset(struct bts_buffer *buf, struct perf_output_handle *handle);
 
+/*
+ * Ordering PMU callbacks wrt themselves and the PMI is done by means
+ * of bts::state, which:
+ *  - is set when bts::handle::event is valid, that is, between
+ *perf_aux_output_begin() and perf_aux_output_end();
+ *  - is zero otherwise;
+ *  - is ordered against bts::handle::event with a local barrier to
+ *enforce CPU ordering.
+ */
+
 static void __bts_event_start(struct perf_event *event)
 {
struct bts_ctx *bts = this_cpu_ptr(_ctx);
@@ -221,10 +245,13 @@ static void __bts_event_start(struct perf_event *event)
 
/*
 * local barrier to make sure that ds configuration made it
-* before we enable BTS
+* before we enable BTS and bts::state goes ACTIVE
 */
wmb();
 
+   /* INACTIVE/STOPPED -> ACTIVE */
+   WRITE_ONCE(bts->state, BTS_STATE_ACTIVE);
+
intel_pmu_enable_bts(config);
 
 }
@@ -251,9 +278,6 @@ static void bts_event_start(struct perf_event *event, int 
flags)
 
__bts_event_start(event);
 
-   /* PMI handler: this counter is running and likely generating PMIs */
-   ACCESS_ONCE(bts->started) = 1;
-
return;
 
 fail_end_stop:
@@ -265,28 +289,36 @@ fail_stop:
 
 static void __bts_event_stop(struct perf_event *event)
 {
+   struct bts_ctx *bts = this_cpu_ptr(_ctx);
+
+   /* ACTIVE -> INACTIVE */
+   WRITE_ONCE(bts->state, BTS_STATE_INACTIVE);
+
/*
 * No extra synchronization is mandated by the documentation to have
 * BTS data stores globally visible.
 */
intel_pmu_disable_bts();
-
-   if (event->hw.state & PERF_HES_STOPPED)
-   return;
-
-   ACCESS_ONCE(event->hw.state) |= PERF_HES_STOPPED;
 }
 
 static void bts_event_stop(struct perf_event *event, int flags)
 {
struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
struct bts_ctx *bts = this_cpu_ptr(_ctx);
-   struct bts_buffer *buf = perf_get_aux(>handle);
+   struct bts_buffer *buf;
+
+   if (READ_ONCE(bts->state) == BTS_STATE_ACTIVE)
+   __bts_event_stop(event);
+
+   /*
+* order buf (handle::event load) against bts::state store;
+* matches wmb() in intel_bts_interrupt()
+*/
+   mb();
 
-   /* PMI handler: don't restart this counter 

Re: [PATCH] drm/tegra: Fix window[0] base address corruption

[Thierry Reding]

On Sun, Aug 21, 2016 at 11:57:58AM +0300, Dmitry Osipenko wrote:
> Window uses shared stride for UV planes and tegra_dc_window struct
> defines array of 2 strides per window. That's not taken in account
> during setting up of the window addresses and strides, resulting in
> out-of-bounds write of the 3-rd (non-existent) V plane stride that
> overwrites Y plane base address.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/dc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Applied and added a comment to the code why it is safe to do this.

Thanks,
Thierry


signature.asc
Description: PGP signature

Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

[Lukas Wunner]

On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> People reported that they can not do a poweroff nor a
> suspend to ram on their Mac Pro 11. After some investigations
> it was found that, once the PCI bridge :00:1c.0 reassigns its
> mm windows to ([mem 0x7fa0-0x7fbf] and
> [mem 0x7fc0-0x7fdf 64bit pref]), the region of ACPI
> io resource 0x1804 becomes unaccessible immediately, where the
> ACPI Sleep register is located, as a result neither poweroff(S5)
> nor suspend to ram(S3) works.

To provide a bit more context:

The root port in question (:00:1c.0) is not listed in the DSDT.
On macOS, only devices present in the ACPI namespace are incorporated
into the I/O Kit registry. Consequently macOS pretends that this root
port doesn't exist. It's not listed in the "ioreg -l" output and thus
no driver is attached to this device.

So what we're dealing with is sloppiness on the part of Apple:
Some engineer probably forgot to disable this unused root port
and they didn't notice it during testing because their OS ignores
such devices.

We could in principle achieve the same behaviour by adding a PCI
device only if it has an ACPI companion, perhaps quirk this only
to Macs. I'm not sure if that's the right thing to do though.
What if they hide devices from macOS but we want to access them
on Linux?

What's really odd is that changing *memory* windows affects
accessibility of *I/O ports*.

One theory would be that I/O ports are somehow mapped into memory.
The GPIO pins of Intel chipsets are usually accessible through
I/O ports, but I've recently looked at the DSDT of the newest
MacBook9,1 (2016) and it looks like they're now accessed through
SystemMemory instead of SystemIO. Perhaps someone at Intel knows
about these intricacies of their chipsets.

If I/O ports are indeed mapped into memory, we need to find a way
to identify and reserve that region. So while this patch seems
like a workable and sufficiently small fix, it might mask a larger
underlying issue. It's certainly a problem though that these
machines currently cannot power off or suspend.

FWIW, we have a somewhat similar issue with the Apple gmux
(a microcontroller built into dual GPU MacBook Pros). That chip
is attached to the LPC bus and accessed through I/O ports.
It turns out that once VGA IO is locked to the discrete GPU
using vgaarb, gmux' I/O ports suddenly become inaccessible.
Apparently its I/O ports are routed to the secondary PCI bus
to which the discrete GPU is connected, and no longer to the
root bus on which the LPC bridge resides. However gmux' I/O ports
are in the 0x700-0x7ff range, whereas the VGA registers are in
the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
of Intel chipsets with regards to I/O accessibility.

Best regards,

Lukas

> 
> As suggested by Bjorn, further testing shows that, there is an
> unreported device may be (using) conflict with above aperture,
> which brings unpredictable result such as the failure of accessing
> the io port, which blocks the poweroff(S5). Besides if we reassign
> the memory aperture to the other place, the poweroff works again.
> 
> As we do not find any resource declared in _CRS which contain above
> memory aperture, and Mac OS does not use this pci bridge neither, we
> choose a simple workaround to clear the hotplug flag(suggested by
> Yinghai Lu), thus do not allocate any resource for this pci bridge,
> and thereby no conflict anymore.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> Cc: Bjorn Helgaas 
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Signed-off-by: Chen Yu 
> ---
>  drivers/pci/quirks.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 37ff015..04bbdba 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2776,6 +2776,26 @@ static void quirk_hotplug_bridge(struct pci_dev *dev)
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge);
>  
>  /*
> + * Apple: Avoid programming the memory/io aperture of 00:1c.0
> + *
> + * BIOS does not declare any resource for 00:1c.0, but with
> + * hotplug flag set, thus the OS allocates:
> + * [mem 0x7fa0 - 0x7fbf]
> + * [mem 0x7fc0-0x7fdf 64bit pref]
> + * which is conflict with an unreported device, which
> + * causes unpredictable result such as accessing io port.
> + * So clear the hotplug flag to work around it.
> + */
> +static void quirk_apple_mbp_poweroff(struct pci_dev *dev)
> +{
> + if (dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,4") ||
> + dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,5"))
> + dev->is_hotplug_bridge = 0;
> +}
> +
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
> quirk_apple_mbp_poweroff);
> +
> +/*
>   * This is a quirk for the Ricoh MMC controller found as a part of
>   * some mulifunction chips.
>  
> -- 
> 2.7.4
> 

Re: [RESEND] [PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings

[Vinay Simha]

if we do not set the polarity to 8mA, panel will have gibberish display.
(information to set 8mA is available only in
nexus7-msm-flo-3.4-lollipop-release_dsi kernel nx7 release)

i will add this
reset-gpios = <_pinmux 54 GPIO_ACTIVE_LOW>;

On Wed, Aug 24, 2016 at 5:26 PM, Thierry Reding
 wrote:
> On Sun, Jul 31, 2016 at 08:45:21PM +0530, Vinay Simha BN wrote:
> [...]
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt 
>> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> [...]
>> +- 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
>> +- enable-gpios: phandle of gpio for enable line
>> +  LED_EN, LED backlight enable, High active
>
> This is a little confusing. Shouldn't we rather completely omit any
> mention of the polarity of these and let the board design handle this?
>
> If the reset is low active, then I'd expect that to be reflected in the
> GPIO specifier of the reset-gpios property, like so:
>
> panel@0 {
> ...
> reset-gpios = <_pinmux 54 GPIO_ACTIVE_LOW>;
> ...
> };
>
> With that a driver can simply deal with a high active reset, which it
> currently doesn't. The problem with the current description is that it
> is unclear who's to deal with the polarity. In order for this to work
> properly with the current driver you'll have to specify the GPIO as
> GPIO_ACTIVE_HIGH, which is not what the binding says it should be.
>
> Thierry



-- 
regards,
vinaysimha

Applied "ASoC: samsung: i2s: Add missing clk_disable_unprepare() on error in samsung_i2s_probe()" to the asoc tree

[Mark Brown]

The patch

   ASoC: samsung: i2s: Add missing clk_disable_unprepare() on error in 
samsung_i2s_probe()

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From fd61576fdda88c9677f9ea62e6f32997ce39daea Mon Sep 17 00:00:00 2001
From: Wei Yongjun 
Date: Tue, 23 Aug 2016 15:16:42 +
Subject: [PATCH] ASoC: samsung: i2s: Add missing clk_disable_unprepare() on
 error in samsung_i2s_probe()

Add the missing clk_disable_unprepare() before return
from samsung_i2s_probe() in the error handling case.

Signed-off-by: Wei Yongjun 
Acked-by: Sylwester Nawrocki 
Signed-off-by: Mark Brown 
---
 sound/soc/samsung/i2s.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index fa3ff03d97d5..7e32cf4581f8 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -1318,7 +1318,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
sec_dai = i2s_alloc_dai(pdev, true);
if (!sec_dai) {
dev_err(>dev, "Unable to alloc I2S_sec\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err_disable_clk;
}
 
sec_dai->lock = _dai->spinlock;
@@ -1342,7 +1343,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 
if (i2s_pdata && i2s_pdata->cfg_gpio && i2s_pdata->cfg_gpio(pdev)) {
dev_err(>dev, "Unable to configure gpio\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_disable_clk;
}
 
ret = devm_snd_soc_register_component(_dai->pdev->dev,
@@ -1366,6 +1368,8 @@ static int samsung_i2s_probe(struct platform_device *pdev)
 err_free_dai:
if (sec_dai)
i2s_free_sec_dai(sec_dai);
+err_disable_clk:
+   clk_disable_unprepare(pri_dai->clk);
return ret;
 }
 
-- 
2.8.1

Re: [PATCH v2 5/8] hisi_sas: add v2 hw slot complete internal abort support

[Hannes Reinecke]

On 08/24/2016 01:05 PM, John Garry wrote:
> Add code in slot_complete_v2_hw() to deal with the
> slots which have completed due to internal abort.
> 
> The status codes have the following meaning:
> - STAT_IO_ABORTED: the IO has been aborted due to
> internal abort, whether by device or individual
> abort command
> - STAT_IO_COMPLETE: internal abort command has
> completed successfully for device or individual
> abort command
> - STAT_IO_NO_DEVICE: internal abort command has
> completed for device but cannot find any IO
> - STAT_IO_NOT_VALID: internal abort command has
> completed for single command but could not
> find the command
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
> b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
> index fec1675..bf9b693 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
> @@ -227,6 +227,13 @@
>  #define CMPLT_HDR_RSPNS_XFRD_MSK (0x1 << CMPLT_HDR_RSPNS_XFRD_OFF)
>  #define CMPLT_HDR_ERX_OFF12
>  #define CMPLT_HDR_ERX_MSK(0x1 << CMPLT_HDR_ERX_OFF)
> +#define CMPLT_HDR_ABORT_STAT_OFF 13
> +#define CMPLT_HDR_ABORT_STAT_MSK (0x7 << CMPLT_HDR_ABORT_STAT_OFF)
> +/* abort_stat */
> +#define STAT_IO_NOT_VALID0x1
> +#define STAT_IO_NO_DEVICE0x2
> +#define STAT_IO_COMPLETE 0x3
> +#define STAT_IO_ABORTED  0x4
>  /* dw1 */
>  #define CMPLT_HDR_IPTT_OFF   0
>  #define CMPLT_HDR_IPTT_MSK   (0x << CMPLT_HDR_IPTT_OFF)
> @@ -1569,6 +1576,30 @@ slot_complete_v2_hw(struct hisi_hba *hisi_hba, struct 
> hisi_sas_slot *slot,
>   goto out;
>   }
>  
> + /* Use SAS+TMF status codes */
> + switch ((complete_hdr->dw0 & CMPLT_HDR_ABORT_STAT_MSK)
> + >> CMPLT_HDR_ABORT_STAT_OFF) {
> + case STAT_IO_ABORTED:
> + /* this io has been aborted by abort command */
> + ts->stat = SAS_ABORTED_TASK;
> + goto out;
> + case STAT_IO_COMPLETE:
> + /* internal abort command complete */
> + ts->stat = TMF_RESP_FUNC_COMPLETE;
> + goto out;
> + case STAT_IO_NO_DEVICE:
> + ts->stat = TMF_RESP_FUNC_COMPLETE;
> + goto out;
> + case STAT_IO_NOT_VALID:
> + /* abort single io, controller don't find
> +  * the io need to abort
> +  */
> + ts->stat = TMF_RESP_FUNC_FAILED;
> + goto out;
Hmm. This will cause the SCSI EH to kick in.
And then, according to the description abort has succeeded, it's just
that for some reason the associated command couldn't be found.
So couldn't this be due to a race condition, and the command has in fact
been aborted correctly (and the code is just too slow acknowledging it)?

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[tip:x86/asm] dma-api: Teach the "DMA-from-stack" check about vmapped stacks

[tip-bot for Andy Lutomirski]

Commit-ID:  b4a0f533e5976cb1a79f31d6152e1d322d79b7f1
Gitweb: http://git.kernel.org/tip/b4a0f533e5976cb1a79f31d6152e1d322d79b7f1
Author: Andy Lutomirski 
AuthorDate: Thu, 11 Aug 2016 02:35:22 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:11:41 +0200

dma-api: Teach the "DMA-from-stack" check about vmapped stacks

If we're using CONFIG_VMAP_STACK=y and we manage to point an sg entry
at the stack, then either the sg page will be in highmem or sg_virt()
will return the direct-map alias.  In neither case will the existing
check_for_stack() implementation realize that it's a stack page.

Fix it by explicitly checking for stack pages.

This has no effect by itself.  It's broken out for ease of review.

Signed-off-by: Andy Lutomirski 
Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/448460622731312298bf19dcbacb1606e75de7a9.1470907718.git.l...@kernel.org
[ Minor edits. ]
Signed-off-by: Ingo Molnar 
---
 lib/dma-debug.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index fcfa193..06f02f6 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1164,11 +1165,32 @@ static void check_unmap(struct dma_debug_entry *ref)
put_hash_bucket(bucket, );
 }
 
-static void check_for_stack(struct device *dev, void *addr)
+static void check_for_stack(struct device *dev,
+   struct page *page, size_t offset)
 {
-   if (object_is_on_stack(addr))
-   err_printk(dev, NULL, "DMA-API: device driver maps memory from "
-   "stack [addr=%p]\n", addr);
+   void *addr;
+   struct vm_struct *stack_vm_area = task_stack_vm_area(current);
+
+   if (!stack_vm_area) {
+   /* Stack is direct-mapped. */
+   if (PageHighMem(page))
+   return;
+   addr = page_address(page) + offset;
+   if (object_is_on_stack(addr))
+   err_printk(dev, NULL, "DMA-API: device driver maps 
memory from stack [addr=%p]\n", addr);
+   } else {
+   /* Stack is vmalloced. */
+   int i;
+
+   for (i = 0; i < stack_vm_area->nr_pages; i++) {
+   if (page != stack_vm_area->pages[i])
+   continue;
+
+   addr = (u8 *)current->stack + i * PAGE_SIZE + offset;
+   err_printk(dev, NULL, "DMA-API: device driver maps 
memory from stack [probable addr=%p]\n", addr);
+   break;
+   }
+   }
 }
 
 static inline bool overlap(void *addr, unsigned long len, void *start, void 
*end)
@@ -1291,10 +1313,11 @@ void debug_dma_map_page(struct device *dev, struct page 
*page, size_t offset,
if (map_single)
entry->type = dma_debug_single;
 
+   check_for_stack(dev, page, offset);
+
if (!PageHighMem(page)) {
void *addr = page_address(page) + offset;
 
-   check_for_stack(dev, addr);
check_for_illegal_area(dev, addr, size);
}
 
@@ -1386,8 +1409,9 @@ void debug_dma_map_sg(struct device *dev, struct 
scatterlist *sg,
entry->sg_call_ents   = nents;
entry->sg_mapped_ents = mapped_ents;
 
+   check_for_stack(dev, sg_page(s), s->offset);
+
if (!PageHighMem(sg_page(s))) {
-   check_for_stack(dev, sg_virt(s));
check_for_illegal_area(dev, sg_virt(s), sg_dma_len(s));
}
 

Re: [RFC PATCH 4/4] perf-probe: Support probing on offline cross-arch binary

[Arnaldo Carvalho de Melo]

Em Wed, Aug 24, 2016 at 02:58:41PM +0900, Masami Hiramatsu escreveu:
> Support probing on offline cross-architecture binary by
> adding getting the target machine arch from ELF and
> choose correct register string for the machine.
> 
> Here is an example:
>   -
>   $ mkdir tracing

No need for the sudo here, right?

>   $ sudo perf probe --outdir=./tracing --vmlinux=./vmlinux-arm \
> do_sys_open '$vars'

Going with the --definition (or any other name that spits out what needs
to go to kprobes_events, this could be further short circuited, ie.:

  $ perf probe --vmlinux=./vmlinux-arm do_sys_open '$vars'
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32 flags=%r6:s32 
mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  $

Because in this case clearly the probe is not for the running kernel,
thus we could imply that this is to generate probes for running on
some other place.

Also perhaps even this could be made shorter:

  $ perf probe vmlinux-arm do_sys_open '$vars'
  p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32 flags=%r6:s32 
mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
  $

As it can easily figure out the first argument _is_ a vmlinux :-)

- Arnaldo


>   Added new event:
>   probe:do_sys_open(on do_sys_open with $vars)
> 
>   You can now use it in all perf tools, such as:
> 
>   perf record -e probe:do_sys_open -aR sleep 1
> 
>   $ cat tracing/kprobe_events
>   p:probe/do_sys_open _text+1282292 dfd=%r5:s32 filename=%r1:u32
>flags=%r6:s32 mode=%r3:u16 op=-60(%sp) fd=%r4:s32 tmp=%r7:u32
>   -
> Here, we can get probe/do_sys_open event by "copy & paste" from
> ./tracing/kprobe_events to target-machine's debugfs/tracing/kprobe_events
> 
> To make sure it is correct:
>   -
>   $ nm vmlinux-arm | grep "T _text"
>   80008000 T _text
>   $ nm vmlinux-arm | grep "T do_sys_open"
>   801410f4 T do_sys_open
>   $ expr `printf "%d + %d" 0x80008000 1282292`
>   2148798708
>   $ printf "%x\n" 2148798708
>   801410f4
>   -
> So "_text+12882292" indicates do_sys_open on the target binary correctly.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  tools/perf/arch/arm/include/dwarf-regs-table.h |9 +++
>  tools/perf/arch/arm64/include/dwarf-regs-table.h   |   13 +
>  tools/perf/arch/powerpc/include/dwarf-regs-table.h |   27 ++
>  tools/perf/arch/s390/include/dwarf-regs-table.h|8 +++
>  tools/perf/arch/sh/include/dwarf-regs-table.h  |   25 +
>  tools/perf/arch/sparc/include/dwarf-regs-table.h   |   18 +++
>  tools/perf/arch/x86/include/dwarf-regs-table.h |   14 +
>  tools/perf/arch/xtensa/include/dwarf-regs-table.h  |8 +++
>  tools/perf/util/Build  |1 
>  tools/perf/util/dwarf-regs.c   |   55 
> 
>  tools/perf/util/include/dwarf-regs.h   |6 ++
>  tools/perf/util/probe-finder.c |   27 ++
>  tools/perf/util/probe-finder.h |1 
>  13 files changed, 201 insertions(+), 11 deletions(-)
>  create mode 100644 tools/perf/arch/arm/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/arm64/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/powerpc/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/s390/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/sh/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/sparc/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/x86/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/arch/xtensa/include/dwarf-regs-table.h
>  create mode 100644 tools/perf/util/dwarf-regs.c
> 
> diff --git a/tools/perf/arch/arm/include/dwarf-regs-table.h 
> b/tools/perf/arch/arm/include/dwarf-regs-table.h
> new file mode 100644
> index 000..f298d03
> --- /dev/null
> +++ b/tools/perf/arch/arm/include/dwarf-regs-table.h
> @@ -0,0 +1,9 @@
> +#ifdef DEFINE_DWARF_REGSTR_TABLE
> +/* This is included in perf/util/dwarf-regs.c */
> +
> +static const char * const arm_regstr_tbl[] = {
> + "%r0", "%r1", "%r2", "%r3", "%r4",
> + "%r5", "%r6", "%r7", "%r8", "%r9", "%r10",
> + "%fp", "%ip", "%sp", "%lr", "%pc",
> +};
> +#endif
> diff --git a/tools/perf/arch/arm64/include/dwarf-regs-table.h 
> b/tools/perf/arch/arm64/include/dwarf-regs-table.h
> new file mode 100644
> index 000..2675936
> --- /dev/null
> +++ b/tools/perf/arch/arm64/include/dwarf-regs-table.h
> @@ -0,0 +1,13 @@
> +#ifdef DEFINE_DWARF_REGSTR_TABLE
> +/* This is included in perf/util/dwarf-regs.c */
> +
> +static const char * const aarch64_regstr_tbl[] = {
> + "%r0", "%r1", "%r2", "%r3", "%r4",
> + "%r5", "%r6", "%r7", "%r8", "%r9",
> + "%r10", "%r11", "%r12", "%r13", "%r14",
> + "%r15", "%r16", "%r17", "%r18", "%r19",
> + "%r20", "%r21", "%r22", "%r23", "%r24",
> + "%r25", "%r26", "%r27", "%r28", "%r29",
> + "%lr", "%sp",
> +};
> +#endif
> diff --git 

[tip:x86/asm] x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

[tip-bot for Andy Lutomirski]

Commit-ID:  e37e43a497d5a8b7c0cc1736d56986f432c394c9
Gitweb: http://git.kernel.org/tip/e37e43a497d5a8b7c0cc1736d56986f432c394c9
Author: Andy Lutomirski 
AuthorDate: Thu, 11 Aug 2016 02:35:23 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:11:42 +0200

x86/mm/64: Enable vmapped stacks (CONFIG_HAVE_ARCH_VMAP_STACK=y)

This allows x86_64 kernels to enable vmapped stacks by setting
HAVE_ARCH_VMAP_STACK=y - which enables the CONFIG_VMAP_STACK=y
high level Kconfig option.

There are a couple of interesting bits:

First, x86 lazily faults in top-level paging entries for the vmalloc
area.  This won't work if we get a page fault while trying to access
the stack: the CPU will promote it to a double-fault and we'll die.
To avoid this problem, probe the new stack when switching stacks and
forcibly populate the pgd entry for the stack when switching mms.

Second, once we have guard pages around the stack, we'll want to
detect and handle stack overflow.

I didn't enable it on x86_32.  We'd need to rework the double-fault
code a bit and I'm concerned about running out of vmalloc virtual
addresses under some workloads.

This patch, by itself, will behave somewhat erratically when the
stack overflows while RSP is still more than a few tens of bytes
above the bottom of the stack.  Specifically, we'll get #PF and make
it to no_context and them oops without reliably triggering a
double-fault, and no_context doesn't know about stack overflows.
The next patch will improve that case.

Thank you to Nadav and Brian for helping me pay enough attention to
the SDM to hopefully get this right.

Signed-off-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Nadav Amit 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/c88f3e2920b18e6cc621d772a04a62c06869037e.1470907718.git.l...@kernel.org
[ Minor edits. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig |  1 +
 arch/x86/include/asm/switch_to.h | 28 +-
 arch/x86/kernel/traps.c  | 61 
 arch/x86/mm/tlb.c| 15 ++
 4 files changed, 104 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..21a6d0e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -94,6 +94,7 @@ config X86
select HAVE_ARCH_TRANSPARENT_HUGEPAGE
select HAVE_ARCH_WITHIN_STACK_FRAMES
select HAVE_EBPF_JITif X86_64
+   select HAVE_ARCH_VMAP_STACK if X86_64
select HAVE_CC_STACKPROTECTOR
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 8f321a1..14e4b20 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -8,6 +8,28 @@ struct tss_struct;
 void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
  struct tss_struct *tss);
 
+/* This runs runs on the previous thread's stack. */
+static inline void prepare_switch_to(struct task_struct *prev,
+struct task_struct *next)
+{
+#ifdef CONFIG_VMAP_STACK
+   /*
+* If we switch to a stack that has a top-level paging entry
+* that is not present in the current mm, the resulting #PF will
+* will be promoted to a double-fault and we'll panic.  Probe
+* the new stack now so that vmalloc_fault can fix up the page
+* tables if needed.  This can only happen if we use a stack
+* in vmap space.
+*
+* We assume that the stack is aligned so that it never spans
+* more than one top-level paging entry.
+*
+* To minimize cache pollution, just follow the stack pointer.
+*/
+   READ_ONCE(*(unsigned char *)next->thread.sp);
+#endif
+}
+
 #ifdef CONFIG_X86_32
 
 #ifdef CONFIG_CC_STACKPROTECTOR
@@ -39,6 +61,8 @@ do {  
\
 */ \
unsigned long ebx, ecx, edx, esi, edi;  \
\
+   prepare_switch_to(prev, next);  \
+   \
asm volatile("pushl %%ebp\n\t"  /* saveEBP   */ \
 "movl %%esp,%[prev_sp]\n\t"/* saveESP   */ \
 "movl %[next_sp],%%esp\n\t"/* restore ESP   */ \
@@ -103,7 +127,9 @@ do { 

[tip:x86/asm] fork: Add generic vmalloced stack support

[tip-bot for Andy Lutomirski]

Commit-ID:  ba14a194a434ccc8f733e263ad2ce941e35e5787
Gitweb: http://git.kernel.org/tip/ba14a194a434ccc8f733e263ad2ce941e35e5787
Author: Andy Lutomirski 
AuthorDate: Thu, 11 Aug 2016 02:35:21 -0700
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:11:41 +0200

fork: Add generic vmalloced stack support

If CONFIG_VMAP_STACK=y is selected, kernel stacks are allocated with
__vmalloc_node_range().

Grsecurity has had a similar feature (called GRKERNSEC_KSTACKOVERFLOW=y)
for a long time.

Signed-off-by: Andy Lutomirski 
Acked-by: Michal Hocko 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Dmitry Vyukov 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/14c07d4fd173a5b117f51e8b939f9f4323e39899.1470907718.git.l...@kernel.org
[ Minor edits. ]
Signed-off-by: Ingo Molnar 
---
 arch/Kconfig| 34 +
 arch/ia64/include/asm/thread_info.h |  2 +-
 include/linux/sched.h   | 15 ++
 kernel/fork.c   | 96 +
 4 files changed, 126 insertions(+), 21 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index e9c9334..9ecf9f6 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -707,4 +707,38 @@ config ARCH_NO_COHERENT_DMA_MMAP
 config CPU_NO_EFFICIENT_FFS
def_bool n
 
+config HAVE_ARCH_VMAP_STACK
+   def_bool n
+   help
+ An arch should select this symbol if it can support kernel stacks
+ in vmalloc space.  This means:
+
+ - vmalloc space must be large enough to hold many kernel stacks.
+   This may rule out many 32-bit architectures.
+
+ - Stacks in vmalloc space need to work reliably.  For example, if
+   vmap page tables are created on demand, either this mechanism
+   needs to work while the stack points to a virtual address with
+   unpopulated page tables or arch code (switch_to() and switch_mm(),
+   most likely) needs to ensure that the stack's page table entries
+   are populated before running on a possibly unpopulated stack.
+
+ - If the stack overflows into a guard page, something reasonable
+   should happen.  The definition of "reasonable" is flexible, but
+   instantly rebooting without logging anything would be unfriendly.
+
+config VMAP_STACK
+   default y
+   bool "Use a virtually-mapped stack"
+   depends on HAVE_ARCH_VMAP_STACK && !KASAN
+   ---help---
+ Enable this if you want the use virtually-mapped kernel stacks
+ with guard pages.  This causes kernel stack overflows to be
+ caught immediately rather than causing difficult-to-diagnose
+ corruption.
+
+ This is presently incompatible with KASAN because KASAN expects
+ the stack to map directly to the KASAN shadow map using a formula
+ that is incorrect if the stack is in vmalloc space.
+
 source "kernel/gcov/Kconfig"
diff --git a/arch/ia64/include/asm/thread_info.h 
b/arch/ia64/include/asm/thread_info.h
index 29bd597..c702642 100644
--- a/arch/ia64/include/asm/thread_info.h
+++ b/arch/ia64/include/asm/thread_info.h
@@ -56,7 +56,7 @@ struct thread_info {
 #define alloc_thread_stack_node(tsk, node) ((unsigned long *) 0)
 #define task_thread_info(tsk)  ((struct thread_info *) 0)
 #endif
-#define free_thread_stack(ti)  /* nothing */
+#define free_thread_stack(tsk) /* nothing */
 #define task_stack_page(tsk)   ((void *)(tsk))
 
 #define __HAVE_THREAD_FUNCTIONS
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 62c68e5..20f9f47 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1923,6 +1923,9 @@ struct task_struct {
 #ifdef CONFIG_MMU
struct task_struct *oom_reaper_list;
 #endif
+#ifdef CONFIG_VMAP_STACK
+   struct vm_struct *stack_vm_area;
+#endif
 /* CPU-specific state of this task */
struct thread_struct thread;
 /*
@@ -1939,6 +1942,18 @@ extern int arch_task_struct_size __read_mostly;
 # define arch_task_struct_size (sizeof(struct task_struct))
 #endif
 
+#ifdef CONFIG_VMAP_STACK
+static inline struct vm_struct *task_stack_vm_area(const struct task_struct *t)
+{
+   return t->stack_vm_area;
+}
+#else
+static inline struct vm_struct *task_stack_vm_area(const struct task_struct *t)
+{
+   return NULL;
+}
+#endif
+
 /* Future-safe accessor for struct task_struct's cpus_allowed. */
 #define tsk_cpus_allowed(tsk) (&(tsk)->cpus_allowed)
 
diff --git a/kernel/fork.c b/kernel/fork.c
index 52e725d..9b85f6b 100644

[tip:x86/asm] ftrace: Only allocate the ret_stack 'fp' field when needed

[tip-bot for Josh Poimboeuf]

Commit-ID:  daa460a88c09b26b68e8b017de589c217e901afb
Gitweb: http://git.kernel.org/tip/daa460a88c09b26b68e8b017de589c217e901afb
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:56 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:14 +0200

ftrace: Only allocate the ret_stack 'fp' field when needed

This saves some memory when HAVE_FUNCTION_GRAPH_FP_TEST isn't defined.
On x86_64 with newer versions of gcc which have -mfentry, it saves 400
bytes per task.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/5c7747d9ea7b5cb47ef0a8ce8a6cea6bf7aa94bf.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 include/linux/ftrace.h   | 2 ++
 kernel/trace/trace_functions_graph.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 7d565af..4ad9ccc 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -795,7 +795,9 @@ struct ftrace_ret_stack {
unsigned long func;
unsigned long long calltime;
unsigned long long subtime;
+#ifdef HAVE_FUNCTION_GRAPH_FP_TEST
unsigned long fp;
+#endif
 };
 
 /*
diff --git a/kernel/trace/trace_functions_graph.c 
b/kernel/trace/trace_functions_graph.c
index fc173cd..0e03ed0 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -171,7 +171,9 @@ ftrace_push_return_trace(unsigned long ret, unsigned long 
func, int *depth,
current->ret_stack[index].func = func;
current->ret_stack[index].calltime = calltime;
current->ret_stack[index].subtime = 0;
+#ifdef HAVE_FUNCTION_GRAPH_FP_TEST
current->ret_stack[index].fp = frame_pointer;
+#endif
*depth = current->curr_ret_stack;
 
return 0;

[tip:x86/asm] ftrace: Add return address pointer to ftrace_ret_stack

[tip-bot for Josh Poimboeuf]

Commit-ID:  9a7c348ba6a46f6270d4fe49577649dad5664fe7
Gitweb: http://git.kernel.org/tip/9a7c348ba6a46f6270d4fe49577649dad5664fe7
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:57 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:14 +0200

ftrace: Add return address pointer to ftrace_ret_stack

Storing this value will help prevent unwinders from getting out of sync
with the function graph tracer ret_stack.  Now instead of needing a
stateful iterator, they can compare the return address pointer to find
the right ret_stack entry.

Note that an array of 50 ftrace_ret_stack structs is allocated for every
task.  So when an arch implements this, it will add either 200 or 400
bytes of memory usage per task (depending on whether it's a 32-bit or
64-bit platform).

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/a95cfcc39e8f26b89a430c56926af0bb217bc0a1.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 Documentation/trace/ftrace-design.txt | 11 +++
 arch/arm/kernel/ftrace.c  |  2 +-
 arch/arm64/kernel/ftrace.c|  2 +-
 arch/blackfin/kernel/ftrace.c |  2 +-
 arch/microblaze/kernel/ftrace.c   |  2 +-
 arch/mips/kernel/ftrace.c |  4 ++--
 arch/parisc/kernel/ftrace.c   |  2 +-
 arch/powerpc/kernel/ftrace.c  |  3 ++-
 arch/s390/kernel/ftrace.c |  3 ++-
 arch/sh/kernel/ftrace.c   |  2 +-
 arch/sparc/kernel/ftrace.c|  2 +-
 arch/tile/kernel/ftrace.c |  2 +-
 arch/x86/kernel/ftrace.c  |  2 +-
 include/linux/ftrace.h|  5 -
 kernel/trace/trace_functions_graph.c  |  5 -
 15 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/Documentation/trace/ftrace-design.txt 
b/Documentation/trace/ftrace-design.txt
index dd5f916..a273dd0 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -203,6 +203,17 @@ along to ftrace_push_return_trace() instead of a stub 
value of 0.
 
 Similarly, when you call ftrace_return_to_handler(), pass it the frame pointer.
 
+HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
+
+
+An arch may pass in a pointer to the return address on the stack.  This
+prevents potential stack unwinding issues where the unwinder gets out of
+sync with ret_stack and the wrong addresses are reported by
+ftrace_graph_ret_addr().
+
+Adding support for it is easy: just define the macro in asm/ftrace.h and
+pass the return address pointer as the 'retp' argument to
+ftrace_push_return_trace().
 
 HAVE_FTRACE_NMI_ENTER
 -
diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
index 709ee1d..3f17594 100644
--- a/arch/arm/kernel/ftrace.c
+++ b/arch/arm/kernel/ftrace.c
@@ -218,7 +218,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr,
}
 
err = ftrace_push_return_trace(old, self_addr, ,
-  frame_pointer);
+  frame_pointer, NULL);
if (err == -EBUSY) {
*parent = old;
return;
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index ebecf9a..40ad08a 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -138,7 +138,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr,
return;
 
err = ftrace_push_return_trace(old, self_addr, ,
-  frame_pointer);
+  frame_pointer, NULL);
if (err == -EBUSY)
return;
else
diff --git a/arch/blackfin/kernel/ftrace.c b/arch/blackfin/kernel/ftrace.c
index 095de0f..8dad758 100644
--- a/arch/blackfin/kernel/ftrace.c
+++ b/arch/blackfin/kernel/ftrace.c
@@ -107,7 +107,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned 
long self_addr,
return;
 
if (ftrace_push_return_trace(*parent, self_addr, ,
-frame_pointer) == -EBUSY)
+frame_pointer, NULL) == -EBUSY)
return;
 
trace.func = self_addr;
diff --git a/arch/microblaze/kernel/ftrace.c b/arch/microblaze/kernel/ftrace.c
index 

[tip:locking/core] locking/hung_task: Show all locks

[tip-bot for Vegard Nossum]

Commit-ID:  b2d4c2edb2e4f89aaf85449dee3b87fbf0f8a4d4
Gitweb: http://git.kernel.org/tip/b2d4c2edb2e4f89aaf85449dee3b87fbf0f8a4d4
Author: Vegard Nossum 
AuthorDate: Thu, 18 Aug 2016 18:41:00 +0200
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:16:13 +0200

locking/hung_task: Show all locks

When we get a hung task it can often be valuable to see _all_ the held
locks on the system (in case we are being blocked on trying to acquire
one), e.g. with this patch we can immediately see where the problem is
below:

INFO: task trinity-c3:14933 blocked for more than 120 seconds.
  Not tainted 4.8.0-rc1+ #135
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
trinity-c3  D 88010c16fc88 0 14933  1 0x00080004
 88010c16fc88 3b9aca00  0296
 776cdf88 88011a520ae0 88011a520b08 88011a520198
 867d7f00 88011942c080 880116841580 88010c168000
Call Trace:
 [] schedule+0x77/0x230
 [] __lock_sock+0x129/0x250
 [] ? __sk_destruct+0x450/0x450
 [] ? wake_bit_function+0x2e0/0x2e0
 [] lock_sock_nested+0xeb/0x120
 [] irda_setsockopt+0x65/0xb40
 [] SyS_setsockopt+0x139/0x230
 [] ? SyS_recv+0x20/0x20
 [] ? trace_event_raw_event_sys_enter+0xb90/0xb90
 [] ? __this_cpu_preempt_check+0x13/0x20
 [] ? __context_tracking_exit.part.3+0x30/0x1b0
 [] ? SyS_recv+0x20/0x20
 [] do_syscall_64+0x1b3/0x4b0
 [] entry_SYSCALL64_slow_path+0x25/0x25

Showing all locks held in the system:
2 locks held by khungtaskd/563:
 #0:  (rcu_read_lock){..}, at: [] watchdog+0x106/0x910
 #1:  (tasklist_lock){..}, at: [] 
debug_show_all_locks+0x74/0x360
1 lock held by trinity-c0/19280:
 #0:  (sk_lock-AF_IRDA){..}, at: [] 
irda_accept+0x176/0x10f0
1 lock held by trinity-c0/12865:
 #0:  (sk_lock-AF_IRDA){..}, at: [] 
irda_accept+0x176/0x10f0

Signed-off-by: Vegard Nossum 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Mandeep Singh Baines 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471538460-7505-1-git-send-email-vegard.nos...@oracle.com
Signed-off-by: Ingo Molnar 
---
 kernel/hung_task.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index d234022..432c3d7 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -117,7 +117,7 @@ static void check_hung_task(struct task_struct *t, unsigned 
long timeout)
pr_err("\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\""
" disables this message.\n");
sched_show_task(t);
-   debug_show_held_locks(t);
+   debug_show_all_locks();
 
touch_nmi_watchdog();
 

[tip:x86/asm] x86/dumpstack/ftrace: Mark function graph handler function as unreliable

[tip-bot for Josh Poimboeuf]

Commit-ID:  6f727b84e23421721025f4eb1b4f6cea1d4d723a
Gitweb: http://git.kernel.org/tip/6f727b84e23421721025f4eb1b4f6cea1d4d723a
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:53:01 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:15 +0200

x86/dumpstack/ftrace: Mark function graph handler function as unreliable

When function graph tracing is enabled for a function, its return
address on the stack is replaced with the address of an ftrace handler
(return_to_handler).

Currently 'return_to_handler' can be reported as reliable.  That's not
ideal, and can actually be misleading.  When saving or dumping the
stack, you normally only care about what led up to that point (the call
path), rather than what will happen in the future (the return path).

That's especially true in the non-oops stack trace case, which isn't
used for debugging.  For example, in a perf profiling operation,
reporting return_to_handler() in the trace would just be confusing.

And in the oops case, where debugging is important, "unreliable" is also
more appropriate there because it serves as a hint that graph tracing
was involved, instead of trying to imply that return_to_handler() was
the real caller.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/f8af15749c7d632d3e7f815995831d5b7f82950d.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 9bf3d02..6aad8d4 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -87,12 +87,21 @@ print_context_stack(struct task_struct *task,
bp = (unsigned long) frame;
}
 
-   ops->address(data, addr, reliable);
-
+   /*
+* When function graph tracing is enabled for a
+* function, its return address on the stack is
+* replaced with the address of an ftrace handler
+* (return_to_handler).  In that case, before printing
+* the "real" address, we want to print the handler
+* address as an "unreliable" hint that function graph
+* tracing was involved.
+*/
real_addr = ftrace_graph_ret_addr(task, graph, addr,
  stack);
if (real_addr != addr)
-   ops->address(data, real_addr, 1);
+   ops->address(data, addr, 0);
+
+   ops->address(data, real_addr, reliable);
}
stack++;
}
@@ -116,12 +125,11 @@ print_context_stack_bp(struct task_struct *task,
if (!__kernel_text_address(addr))
break;
 
-   if (ops->address(data, addr, 1))
-   break;
-
real_addr = ftrace_graph_ret_addr(task, graph, addr, retp);
-   if (real_addr != addr)
-   ops->address(data, real_addr, 1);
+   if (real_addr != addr && ops->address(data, addr, 0))
+   break;
+   if (ops->address(data, real_addr, 1))
+   break;
 
frame = frame->next_frame;
retp = >return_address;

[tip:x86/asm] x86/dumpstack/ftrace: Convert dump_trace() callbacks to use ftrace_graph_ret_addr()

[tip-bot for Josh Poimboeuf]

Commit-ID:  408fe5de2f2767059a9561e0ae6d4385d1b39dac
Gitweb: http://git.kernel.org/tip/408fe5de2f2767059a9561e0ae6d4385d1b39dac
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:59 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:14 +0200

x86/dumpstack/ftrace: Convert dump_trace() callbacks to use 
ftrace_graph_ret_addr()

Convert print_context_stack() and print_context_stack_bp() to use the
arch-independent ftrace_graph_ret_addr() helper.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/56ec97cafc1bf2e34d1119e6443d897db406da86.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 65 +++--
 1 file changed, 22 insertions(+), 43 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 5f49c04..9bf3d02 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -38,38 +38,6 @@ void printk_address(unsigned long address)
pr_cont(" [<%p>] %pS\n", (void *)address, (void *)address);
 }
 
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-static void
-print_ftrace_graph_addr(unsigned long addr, void *data,
-   const struct stacktrace_ops *ops,
-   struct task_struct *task, int *graph)
-{
-   unsigned long ret_addr;
-   int index;
-
-   if (addr != (unsigned long)return_to_handler)
-   return;
-
-   index = task->curr_ret_stack;
-
-   if (!task->ret_stack || index < *graph)
-   return;
-
-   index -= *graph;
-   ret_addr = task->ret_stack[index].ret;
-
-   ops->address(data, ret_addr, 1);
-
-   (*graph)++;
-}
-#else
-static inline void
-print_ftrace_graph_addr(unsigned long addr, void *data,
-   const struct stacktrace_ops *ops,
-   struct task_struct *task, int *graph)
-{ }
-#endif
-
 /*
  * x86-64 can have up to three kernel stacks:
  * process stack
@@ -107,18 +75,24 @@ print_context_stack(struct task_struct *task,
stack = (unsigned long *)task_stack_page(task);
 
while (valid_stack_ptr(task, stack, sizeof(*stack), end)) {
-   unsigned long addr;
+   unsigned long addr = *stack;
 
-   addr = *stack;
if (__kernel_text_address(addr)) {
+   unsigned long real_addr;
+   int reliable = 0;
+
if ((unsigned long) stack == bp + sizeof(long)) {
-   ops->address(data, addr, 1);
+   reliable = 1;
frame = frame->next_frame;
bp = (unsigned long) frame;
-   } else {
-   ops->address(data, addr, 0);
}
-   print_ftrace_graph_addr(addr, data, ops, task, graph);
+
+   ops->address(data, addr, reliable);
+
+   real_addr = ftrace_graph_ret_addr(task, graph, addr,
+ stack);
+   if (real_addr != addr)
+   ops->address(data, real_addr, 1);
}
stack++;
}
@@ -133,19 +107,24 @@ print_context_stack_bp(struct task_struct *task,
   unsigned long *end, int *graph)
 {
struct stack_frame *frame = (struct stack_frame *)bp;
-   unsigned long *ret_addr = >return_address;
+   unsigned long *retp = >return_address;
 
-   while (valid_stack_ptr(task, ret_addr, sizeof(*ret_addr), end)) {
-   unsigned long addr = *ret_addr;
+   while (valid_stack_ptr(task, retp, sizeof(*retp), end)) {
+   unsigned long addr = *retp;
+   unsigned long real_addr;
 
if (!__kernel_text_address(addr))
break;
 
if (ops->address(data, addr, 1))
break;
+
+   real_addr = ftrace_graph_ret_addr(task, graph, addr, retp);
+   if (real_addr != addr)
+   ops->address(data, real_addr, 1);
+
frame = frame->next_frame;
-   ret_addr = >return_address;
-   

Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name

[LABBE Corentin]

On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> > The driver name is displayed each time differently.
> > This patch make use of the same name everywhere.
> > 
> > Signed-off-by: LABBE Corentin 
> > ---
> >  drivers/char/hw_random/amd-rng.c | 13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/char/hw_random/amd-rng.c 
> > b/drivers/char/hw_random/amd-rng.c
> > index d0042f5..d0a806a 100644
> > --- a/drivers/char/hw_random/amd-rng.c
> > +++ b/drivers/char/hw_random/amd-rng.c
> > @@ -31,7 +31,7 @@
> >  #include 
> >  #include 
> >  
> > -#define PFXKBUILD_MODNAME ": "
> > +#define DRV_NAME "AMD768-HWRNG"
> >  
> >  /*
> >   * Data for PCI driver interface
> > @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> >  }
> >  
> >  static struct hwrng amd_rng = {
> > -   .name   = "amd",
> > +   .name   = DRV_NAME,
> 
> Hmm, this changes a sysfs-exported name which has the potential
> to break user-space.  So I think you'd need to a stronger argument
> to do it other than just cleaning it up.
> 

amd is really really too generic.

But if you still NACK that (and I understand perfectly why), I will update my 
series.

Regards

Re: Why do we need reset_control_get_optional() ?

[Philipp Zabel]

Am Dienstag, den 16.08.2016, 18:41 +0900 schrieb Masahiro Yamada:
> Hi Arnd,
>
> 2016-08-06 0:35 GMT+09:00 Arnd Bergmann :
> 
> >
> > config RESET_FOO
> > bool "FOO reset controller" if COMPILE_TEST && !ARCH_FOO
> > default ARCH_FOO
> >
> > then I think we get both: you won't be able to turn it off
> > but also get the build testing.
>
> This looks good to me, too.
> I do not know if we need "&& !ARCH_FOO", though.
> 
> When we are compile-testing, we do not care if it works on run-time,
> so perhaps it makes sense to allow to enable/disable RESET_FOO
> regardless ARCH_FOO.

I'll send a few patches to add the Kconfig symbols. Turning around the
RESET_CONTROLLER selection can be done in a second step.

regards
Philipp

[PATCH v2 2/7] Documentation: bindings: Add Exynos5433 PMU compatible

[Chanwoo Choi]

This patch adds the exynos5433 PMU compatible to support the access
of PMU (Power Management Unit) block.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 2d6356d8daf4..bf5fc59a6938 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
   - "samsung,exynos5260-pmu" - for Exynos5260 SoC.
   - "samsung,exynos5410-pmu" - for Exynos5410 SoC,
   - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+  - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
   - "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
 
-- 
1.9.1

[PATCH v2 5/7] arm64: dts: exynos: Add dts files for Samsung Exynos5433 64bit SoC

[Chanwoo Choi]

This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octa-core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.

This patch includes following Device Tree node to support Exynos5433 SoC:
1. Octa cores for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1

2. Clock controller node
- CMU_TOP   : clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
- CMU_CPIF  : clocks for LLI (Low Latency Interface)
- CMU_MIF   : clocks for DRAM Memory Controller
- CMU_PERIC : clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS
- CMU_PERIS : clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC
- CMU_FSYS  : clocks for USB/UFS/SDMMC/TSI/PDMA
- CMU_G2D   : clocks for G2D/MDMA
- CMU_DISP  : clocks for DECON/HDMI/DSIM/MIXER
- CMU_AUD   : clocks for Cortex-A5/BUS/AUDIO
- CMU_BUS{0|1|2} : clocks for global data buses and global peripheral buses
- CMU_G3D   : clocks for 3D Graphics Engine
- CMU_GSCL  : clocks for GSCALER
- CMU_APOLLO: clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor,
  CoreSight and L2 cache controller.
- CMU_MSCL  : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC   : clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC  : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP   : clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0  : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1  : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.

3. pinctrl node for GPIO
- alive/aud/cpif/ese/finger/fsys/imem/nfc/peric/touch pad

4. Timer
- ARM architecture timer (armv8-timer)
- MCT (Multi Core Timer) timer

5. Interrupt controller (GIC-400)

6. BUS devices
- HS-I2C (High-Speed I2C) device
- SPI (Serial Peripheral Interface) device

7. Sound devices
- I2S bus
- LPASS (Low Power Audio Subsystem)

8. Power management devices
- CPUFREQ for for Cortex-A53/A57
- TMU (Thermal Management Unit) for Cortex-A53/A57, G3D, ISP

9. Display controller devices
- DECON (Display and enhancement controller) for panel output
- DSI (Display Serial Interface)
- MIC (Mobile Image Compressor)

10. USB
- USB 3.0 DRD (Dual Role Device) controller
- USB 3.0 Host controller

11. Storage devices
- MSHC (Mobile Stoarage Host Controller)

12. Misc devices
- UART device
- ADC (Analog Digital Converter)
- PWM (Pulse Width Modulation)
- ADMA (Advanced DMA) and PDMA (Peripheral DMA)

Signed-off-by: Chanwoo Choi 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Jonghwa Lee 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Inha Song 
Signed-off-by: Ingi kim 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Sylwester Nawrocki 
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  792 
 .../dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi |   23 +
 .../dts/exynos/exynos5433-tmu-sensor-conf.dtsi |   22 +
 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi |  306 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1327 
 5 files changed, 2470 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
 create mode 100644 
arch/arm64/boot/dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
new file mode 100644
index ..409bfb488b0b
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -0,0 +1,792 @@
+/*
+ * Samsung's Exynos5433 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Chanwoo Choi 
+ *
+ * Samsung's Exynos5433 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define PIN_PULL_NONE  0
+#define PIN_PULL_DOWN  1
+#define PIN_PULL_UP3
+
+#define PIN_DRV_LV10
+#define 

[PATCH v2 4/7] pinctrl: samsung: Add GPF support for Exynos5433

[Chanwoo Choi]

From: Joonyoung Shim 

This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
to support the multiple memory map because the registers of GPFx are located
in the different domain.

Cc: Linus Walleij 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Tomasz Figa 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: Kukjin Kim 
Cc: linux-g...@vger.kernel.org
Signed-off-by: Joonyoung Shim 
Signed-off-by: Chanwoo Choi 
[robh : Acked for binding documentation]
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 1 +
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 37bc692445d4..499fb3484915 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -19,6 +19,7 @@ Required Properties:
   - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller.
   - "samsung,exynos5410-pinctrl": for Exynos5410 compatible pin-controller.
   - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller.
+  - "samsung,exynos5433-pinctrl": for Exynos5433 compatible pin-controller.
   - "samsung,exynos7-pinctrl": for Exynos7 compatible pin-controller.
 
 - reg: Base address of the pin controller hardware module and length of
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 12fa9d3f1113..b9605b8282be 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1360,6 +1360,11 @@ static const struct samsung_pin_bank_data 
exynos5433_pin_banks0[] = {
EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
+   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x020, "gpf1", 0x1004, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x040, "gpf2", 0x1008, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x060, "gpf3", 0x100c, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x080, "gpf4", 0x1010, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x0a0, "gpf5", 0x1014, 1, 0),
 };
 
 /* pin banks of exynos5433 pin-controller - AUD */
@@ -1441,6 +1446,7 @@ const struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+   .nr_ext_resources = 1,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos5433_pin_banks1,
-- 
1.9.1

[PATCH v2 0/7] arm64: dts: Add the dts file for Exynos5433 and TM/TM2E board

[Chanwoo Choi]

This patchset adds the Device Tree file for Samsung 64-bit Exynos5433 SoC
and TM/TM2E board based on Exynos5433. The Exynos5433 has Octa-core CPUs
(quad Cortex-A57 and quad Cortex-A53). The TM2 and TM2E are the Samsung board
based on Exynos5433 SoC.

I sent the Exynos5433 patches[2]. But it was not merged because of sending
the only SoC dtsi patch without board patches. So, I again send the Exynos5433
SoC patches with TM2/TM2E board dts files.

When making the patches, I get the guide from Krzysztof (Exynos SoC maintainer).
The maintainer requires that already developed and verified work should merge
them as one patch. So, this patchset include only three patches for Exynos5433
dtsi, TM2 dts and TM2E dts file.

I tested the display controller by using the modetest tool.
But, Samsung s6e3ha2 panel driver has not yet posted. So, the TM2 dts file
don't include the panel Device Tree node. I'll post the s6e3ha2 panel driver
on separate patch with a dt patch.

Changes from v1:
(https://lkml.org/lkml/2016/8/16/61)
- Merge the cpufreq patch for exynos5433[3] on PM/cpufreq tree.
- Add new patch to support the multiple IORESOURCE_MAP for samsung pinctrl 
driver.
- Drop the SYSMMU Device-Tree node which will be posted by Marek Szyprowski.
- Fix the code clean issue by Krzysztof Kozlowski and Rob Herring's comment.
- Delete the unnecessary alias from exynos5433-tm2.dts.
- Expand the range of cooling level of CPU device.
- Update the binding method of 'Exynos5433 audio subsystem'

Depends on:
This patchset are based on v4.8-rc3[1] and TM2 sound patches[2].

[1] v4.8-rc3
[2] http://lkml.org/lkml/2015/3/17/843
  : [PATCH v7 0/9] arm64: Add the support for new Exynos5433 SoC
[3] https://lkml.org/lkml/2016/8/16/64
  : [PATCH 3/7] cpufreq: dt: Add exynos5433 compatible to use generic cpufreq 
driver

Chanwoo Choi (6):
  clocksource: exynos_mct: Add the support for ARM64
  Documentation: bindings: Add Exynos5433 PMU compatible
  pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
  arm64: dts: exynos: Add dts files for Samsung Exynos5433 64bit SoC
  arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board
  arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board

Joonyoung Shim (1):
  pinctrl: samsung: Add GPF support for Exynos5433

 .../devicetree/bindings/arm/samsung/pmu.txt|1 +
 .../bindings/arm/samsung/samsung-boards.txt|2 +
 .../bindings/pinctrl/samsung-pinctrl.txt   |   18 +
 arch/arm64/boot/dts/exynos/Makefile|5 +-
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  792 
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  985 +++
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts |   41 +
 .../dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi |   23 +
 .../dts/exynos/exynos5433-tmu-sensor-conf.dtsi |   22 +
 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi |  306 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1327 
 drivers/clocksource/Kconfig|2 +-
 drivers/clocksource/exynos_mct.c   |4 +
 drivers/pinctrl/samsung/pinctrl-exynos.c   |   52 +-
 drivers/pinctrl/samsung/pinctrl-exynos.h   |   47 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c  |   55 +-
 drivers/pinctrl/samsung/pinctrl-samsung.h  |7 +-
 17 files changed, 3646 insertions(+), 43 deletions(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
 create mode 100644 
arch/arm64/boot/dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi

-- 
1.9.1