Re: [PATCH v3 00/13] Krait clocks + Krait CPUfreq

[Pavel Machek]

On Fri 2015-03-20 23:45:19, Stephen Boyd wrote:
> These patches provide cpufreq scaling on devices with Krait CPUs.
> In Krait CPU designs there's one PLL and two muxes per CPU, allowing
> us to switch CPU frequencies independently.
> 
>secondary
>+-++
>| QSB |---+|\
>+-+   || |-+
>  |+---|/  |
>  ||   +   |
>+-+   ||   |
>| PLL |+---+   |   primary
>+-+|  || +
>   |  |+-|\   +--+
>+---+  |  |  | \  |  |
>| HFPLL |--+-|  |-| CPU0 |
>+---+  |  || |  | |  |
>   |  || +-+ | /  +--+
>   |  |+-| / 2 |-|/
>   |  |  +-+ +
>   |  | secondary
>   |  |+
>   |  +|\
>   |   | |-+
>   +---|/  |   primary
>   +   | +
>   +-|\   +--+
>+---+| \  |  |
>| HFPLL ||  |-| CPU1 |
>+---+  | |  | |  |
>   | +-+ | /  +--+
>   +-| / 2 |-|/
> +-+ +

And actually this picture should go to Documentation/ somewhere...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/13] Krait clocks + Krait CPUfreq

[Pavel Machek]

Hi!

On Fri 2015-03-20 23:45:19, Stephen Boyd wrote:
> These patches provide cpufreq scaling on devices with Krait CPUs.
> In Krait CPU designs there's one PLL and two muxes per CPU, allowing
> us to switch CPU frequencies independently.
> 
>secondary
>+-++
>| QSB |---+|\
>+-+   || |-+
>  |+---|/  |
>  ||   +   |
>+-+   ||   |
>| PLL |+---+   |   primary
>+-+|  || +
>   |  |+-|\   +--+
>+---+  |  |  | \  |  |
>| HFPLL |--+-|  |-| CPU0 |
>+---+  |  || |  | |  |
>   |  || +-+ | /  +--+
>   |  |+-| / 2 |-|/
>   |  |  +-+ +
>   |  | secondary
>   |  |+
>   |  +|\
>   |   | |-+
>   +---|/  |   primary
>   +   | +
>   +-|\   +--+
>+---+  v | \  |  |
>| HFPLL ||  |-| CPU1 |
>+---+  | |  | |  |
>   | +-+ | /  +--+
>   +-| / 2 |-|/
> +-+ +

Nice ascii art :-). There should be "+" at place marked by "v" :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 1/2] mfd/axp20x: add support for extcon cell

[Ramakrishna Pallala]

This patch adds the mfd cell info for axp288 extcon device.

Signed-off-by: Ramakrishna Pallala 
---
 drivers/mfd/axp20x.c   |   28 
 include/linux/mfd/axp20x.h |5 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 0acbe52..a569721 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -290,6 +290,29 @@ static struct resource axp288_adc_resources[] = {
},
 };
 
+static struct resource axp288_extcon_resources[] = {
+   {
+   .start = AXP288_IRQ_VBUS_FALL,
+   .end   = AXP288_IRQ_VBUS_FALL,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_VBUS_RISE,
+   .end   = AXP288_IRQ_VBUS_RISE,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_MV_CHNG,
+   .end   = AXP288_IRQ_MV_CHNG,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_BC_USB_CHNG,
+   .end   = AXP288_IRQ_BC_USB_CHNG,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
 static struct resource axp288_charger_resources[] = {
{
.start = AXP288_IRQ_OV,
@@ -345,6 +368,11 @@ static struct mfd_cell axp288_cells[] = {
.resources = axp288_adc_resources,
},
{
+   .name = "axp288_extcon",
+   .num_resources = ARRAY_SIZE(axp288_extcon_resources),
+   .resources = axp288_extcon_resources,
+   },
+   {
.name = "axp288_charger",
.num_resources = ARRAY_SIZE(axp288_charger_resources),
.resources = axp288_charger_resources,
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index dfabd6d..4ed8071 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -275,4 +275,9 @@ struct axp20x_fg_pdata {
int thermistor_curve[MAX_THERM_CURVE_SIZE][2];
 };
 
+struct axp288_extcon_pdata {
+   /* GPIO pin control to switch D+/D- lines b/w PMIC and SOC */
+   struct gpio_desc *gpio_mux_cntl;
+};
+
 #endif /* __LINUX_MFD_AXP20X_H */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 2/2] extcon-axp288: Add axp288 extcon driver support

[Ramakrishna Pallala]

This patch adds the extcon support for AXP288 PMIC which
has the BC1.2 charger detection capability. Additionally
it also adds the USB mux switching support b/w SOC and PMIC
based on GPIO control.

Signed-off-by: Ramakrishna Pallala 
---
 drivers/extcon/Kconfig |7 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-axp288.c |  479 
 3 files changed, 487 insertions(+)
 create mode 100644 drivers/extcon/extcon-axp288.c

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..b8627f7 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
  Silicon Mitus SM5502. The SM5502 is a USB port accessory
  detector and switch.
 
+config EXTCON_AXP288
+   tristate "AXP288 EXTCON support"
+   depends on MFD_AXP20X && USB_PHY
+   help
+ Say Y here to enable support for USB peripheral detection
+ and USB MUX switching by AXP288 PMIC.
+
 endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..832ad79 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
 obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
 obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
new file mode 100644
index 000..2e75d45
--- /dev/null
+++ b/drivers/extcon/extcon-axp288.c
@@ -0,0 +1,479 @@
+/*
+ * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ * Ramakrishna Pallala 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AXP288_PS_STAT_REG 0x00
+#define PS_STAT_VBUS_TRIGGER   (1 << 0)
+#define PS_STAT_BAT_CHRG_DIR   (1 << 2)
+#define PS_STAT_VBUS_ABOVE_VHOLD   (1 << 3)
+#define PS_STAT_VBUS_VALID (1 << 4)
+#define PS_STAT_VBUS_PRESENT   (1 << 5)
+
+#define AXP288_BC_GLOBAL_REG   0x2c
+#define BC_GLOBAL_RUN  (1 << 0)
+#define BC_GLOBAL_DET_STAT (1 << 2)
+#define BC_GLOBAL_DBP_TOUT (1 << 3)
+#define BC_GLOBAL_VLGC_COM_SEL (1 << 4)
+#define BC_GLOBAL_DCD_TOUT_MASK0x60
+#define BC_GLOBAL_DCD_TOUT_300MS   0x0
+#define BC_GLOBAL_DCD_TOUT_100MS   0x1
+#define BC_GLOBAL_DCD_TOUT_500MS   0x2
+#define BC_GLOBAL_DCD_TOUT_900MS   0x3
+#define BC_GLOBAL_DCD_DET_SEL  (1 << 7)
+
+#define AXP288_BC_VBUS_CNTL_REG0x2d
+#define VBUS_CNTL_DPDM_PD_EN   (1 << 4)
+#define VBUS_CNTL_DPDM_FD_EN   (1 << 5)
+#define VBUS_CNTL_FIRST_PO_STAT(1 << 6)
+
+#define AXP288_BC_USB_STAT_REG 0x2e
+#define USB_STAT_BUS_STAT_MASK 0x0f
+#define USB_STAT_BUS_STAT_OFFSET   0
+#define USB_STAT_BUS_STAT_ATHD 0x0
+#define USB_STAT_BUS_STAT_CONN 0x1
+#define USB_STAT_BUS_STAT_SUSP 0x2
+#define USB_STAT_BUS_STAT_CONF 0x3
+#define USB_STAT_USB_SS_MODE   (1 << 4)
+#define USB_STAT_DEAD_BAT_DET  (1 << 6)
+#define USB_STAT_DBP_UNCFG (1 << 7)
+
+#define AXP288_BC_DET_STAT_REG 0x2f
+#define DET_STAT_MASK  0xe0
+#define DET_STAT_OFFSET5
+#define DET_STAT_SDP   0x1
+#define DET_STAT_CDP   0x2
+#define DET_STAT_DCP   0x3
+
+#define AXP288_PS_BOOT_REASON_REG  0x2
+
+#define AXP288_PWRSRC_IRQ_CFG_REG  0x40
+#define PWRSRC_IRQ_CFG_MASK0x1c
+
+#define AXP288_BC12_IRQ_CFG_REG0x45
+#define BC12_IRQ_CFG_MASK  0x2
+
+#define AXP288_PWRSRC_INTR_NUM 4
+
+#define AXP288_DRV_NAME"axp288_extcon"
+
+#define AXP288_EXTCON_CABLE_SDP"Slow-charger"
+#define AXP288_EXTCON_CABLE_CDP"Charge-downstream"
+#define AXP288_EXTCON_CABLE_DCP"Fast-charger"
+
+#define EXTCON_GPIO_MUX_SEL_PMIC   0
+#define EXTCON_GPIO_MUX_SEL_SOC1
+
+enum {
+   VBUS_FALLING_IRQ = 0,
+   VBUS_RISING_IRQ,
+   MV_CHNG_IRQ,
+   BC_USB_CHNG_IRQ,
+};
+
+static const 

[PATCH v1 0/2] Add extcon support for AXP288 PMIC

[Ramakrishna Pallala]

This patch series adds the support for axp288 extcon driver
and also adds the cell info for extcon device in axp20x mfd driver.

Ramakrishna Pallala (2):
  mfd/axp20x: add support for extcon cell
  extcon-axp288: Add axp288 extcon driver support

 drivers/extcon/Kconfig |7 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-axp288.c |  479 
 drivers/mfd/axp20x.c   |   28 +++
 include/linux/mfd/axp20x.h |5 +
 5 files changed, 520 insertions(+)
 create mode 100644 drivers/extcon/extcon-axp288.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] perf: annotate: make it respect -i option.

[Wang Nan]

There is a bug in perf annotate that it doesn't respect user provided
'-i'/'--input' option:

 # perf record ls
   [ perf record: Woken up 1 times to write data ]
   [ perf record: Captured and wrote 0.001 MB perf.data (8 samples) ]
 # mv ./perf.data ./perf.data.new
 # perf annotate -i ./perf.data.new  --stdio
   failed to open perf.data: No such file or directory  (try 'perf record' 
first)

This patch fix it by setting file path after option parsing, like
what 'perf report' does.

Signed-off-by: Wang Nan 
---
 tools/perf/builtin-annotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 71bf745..929f83c 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -283,7 +283,6 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
},
};
struct perf_data_file file = {
-   .path  = input_name,
.mode  = PERF_DATA_MODE_READ,
};
const struct option options[] = {
@@ -342,6 +341,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
setup_browser(true);
 
+   file.path  = input_name,
annotate.session = perf_session__new(, false, );
if (annotate.session == NULL)
return -1;
-- 
1.8.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] arm64: add kdump support

[Pratyush Anand]

On Thursday 02 April 2015 11:07 AM, AKASHI Takahiro wrote:

Pratyush,

On 04/02/2015 01:58 PM, Pratyush Anand wrote:



On Thursday 02 April 2015 04:57 AM, AKASHI Takahiro wrote:

Please try my latest kexec-tools in my linaro repo (branch name is
kdump/v0.11)
and let me know the result.


Thanks a lot.. Just fetched your repo and found v.0.11.

With this crash kernel loaded successfully, if I do not use initrd.

With following I still see Overlapping memory segments

kexec -p  /home/panand/work/kernel/bsa2_kdump/vmlinux
--initrd=/boot/initramfs-3.19.0.bz1198945+.img --append="$( cat
/proc/cmdline ) maxcpus=1 mem=64M reset_devices"


How big is your initrd?
If it is good small, please tell me segments info, or messages from
add_segment_phys_virt()
for all the segments.



add_segment_phys_virt: 0dcd0b90 - 0dcd0f90 (0400) -> 
0040c3ff - 0040c400 (0001)
add_segment_phys_virt: 03ff88c10010 - 03ff8984a010 (00c3a000) -> 
0040c008 - 0040c131 (0129)
add_segment_phys_virt: 0dcd53c0 - 0dcd96b8 (42f8) -> 
0040c000 - 0040c001 (0001)
add_segment_phys_virt: 03ff87360010 - 03ff88bfcc2f (0189cc1f) -> 
0040c001 - 0040c18b (018a)

Overlapping memory segments at 0x40c18b
sort_segments failed

Why do we try to fit dtb just after crash_reserved_mem.start. Should n't 
it should start after crash_reserved_mem.start + arm64_mem.text_offset + 
arm64_mem.image_size



I tried following and it works perfectly:

diff --git a/kexec/arch/arm64/crashdump-arm64.c 
b/kexec/arch/arm64/crashdump-arm64.c

index 41266f294589..75f4e4d269ca 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct 
kexec_info *info)

 off_t locate_dtb_in_crashmem(struct kexec_info *info, off_t dtb_size)
 {
return locate_hole(info, dtb_size, 128UL * 1024,
-   crash_reserved_mem.start, crash_reserved_mem.end, 1);
+   crash_reserved_mem.start + arm64_mem.text_offset +
+   arm64_mem.image_size, crash_reserved_mem.end, 1);
 }

With this changes new allocations are:
add_segment_phys_virt: 10350b90 - 10350f90 (0400) -> 
0040c3ff - 0040c400 (0001)
add_segment_phys_virt: 03ff7ad70010 - 03ff7b9aa010 (00c3a000) -> 
0040c008 - 0040c131 (0129)
add_segment_phys_virt: 103553c0 - 103596b8 (42f8) -> 
0040c136 - 0040c137 (0001)
add_segment_phys_virt: 03ff794c0010 - 03ff7ad5cc2f (0189cc1f) -> 
0040c137 - 0040c2c1 (018a)
add_segment_phys_virt: 103596c0 - 10360190 (6ad0) -> 
0040c2c1 - 0040c2c2 (0001)



Crash kernel loaded upon panic.

~Pratyush
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sched: Improve load balancing in the presence of idle CPUs

[Jason Low]

On Wed, 2015-04-01 at 18:04 +0100, Morten Rasmussen wrote:
> On Wed, Apr 01, 2015 at 07:49:56AM +0100, Preeti U Murthy wrote:

> > I am sorry I don't quite get this. Can you please elaborate?
> 
> I think the scenario is that we are in nohz_idle_balance() and decide to
> bail out because we have pulled some tasks, but before leaving
> nohz_idle_balance() we want to check if more balancing is necessary
> using nohz_kick_needed() and potentially kick somebody to continue.

Also, below is an example patch.

(Without the conversion to idle_cpu(), the check for rq->idle_balance
would not be accurate anymore)

---
 kernel/sched/fair.c |   17 ++---
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fdae26e..7749a14 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7620,6 +7620,8 @@ out:
 }
 
 #ifdef CONFIG_NO_HZ_COMMON
+static inline bool nohz_kick_needed(struct rq *rq);
+
 /*
  * In CONFIG_NO_HZ_COMMON case, the idle balance kickee will do the
  * rebalancing for all the cpus for whom scheduler ticks are stopped.
@@ -7629,6 +7631,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum 
cpu_idle_type idle)
int this_cpu = this_rq->cpu;
struct rq *rq;
int balance_cpu;
+   bool done_balancing = false;
 
if (idle != CPU_IDLE ||
!test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu)))
@@ -7644,7 +7647,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum 
cpu_idle_type idle)
 * balancing owner will pick it up.
 */
if (need_resched())
-   break;
+   goto end;
 
rq = cpu_rq(balance_cpu);
 
@@ -7663,9 +7666,12 @@ static void nohz_idle_balance(struct rq *this_rq, enum 
cpu_idle_type idle)
if (time_after(this_rq->next_balance, rq->next_balance))
this_rq->next_balance = rq->next_balance;
}
+   done_balancing = true;
nohz.next_balance = this_rq->next_balance;
 end:
clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
+   if (!done_balancing && nohz_kick_needed(this_rq))
+   nohz_balancer_kick();
 }
 
 /*
@@ -7687,7 +7693,7 @@ static inline bool nohz_kick_needed(struct rq *rq)
int nr_busy, cpu = rq->cpu;
bool kick = false;
 
-   if (unlikely(rq->idle_balance))
+   if (unlikely(idle_cpu(cpu)))
return false;
 
/*
@@ -7757,16 +7763,13 @@ static void run_rebalance_domains(struct softirq_action 
*h)
enum cpu_idle_type idle = this_rq->idle_balance ?
CPU_IDLE : CPU_NOT_IDLE;
 
+   rebalance_domains(this_rq, idle);
/*
 * If this cpu has a pending nohz_balance_kick, then do the
 * balancing on behalf of the other idle cpus whose ticks are
-* stopped. Do nohz_idle_balance *before* rebalance_domains to
-* give the idle cpus a chance to load balance. Else we may
-* load balance only within the local sched_domain hierarchy
-* and abort nohz_idle_balance altogether if we pull some load.
+* stopped.
 */
nohz_idle_balance(this_rq, idle);
-   rebalance_domains(this_rq, idle);
 }
 
 /*
-- 
1.7.2.5



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Concerns about "mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support"

[James Bottomley]

On Thu, 2015-04-02 at 16:39 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2015-02-19 at 21:45 -0800, James Bottomley wrote:
> 
> > Ben, this is legal by design.  It was specifically designed for the
> > aic79xx SCSI card, but can be used for a variety of other reasons.  The
> > aic79xx hardware problem was that the DMA engine could address the whole
> > of memory (it had two address modes, a 39 bit one and a 64 bit one) but
> > the script engine that runs the mailboxes only had a 32 bit activation
> > register (the activating write points at the physical address of the
> > script to begin executing).  This meant that the scripts that run in
> > memory had to be in the first 4GB of physical memory, hence the split
> > mask.  The DMA mask specifies that the card can transfer from anywhere
> > in physical memory, but the consistent_dma_mask says that the consistent
> > allocation used to get scripts memory must come from the lower 4GB.
> 
> So looking at that again...
> 
> This is interesting ... basically any driver using a different mask has
> been broken on powerpc for basically ever. The whole concept was poorly
> designed, for example,  the set_consistent_mask isn't a dma_map_ops
> unlike everything else.
> 
> In some cases, what we want is convey a base+offset information to
> drivers but we can't do that.
> 
> This stuff cannot work with setups like a lot of our iommus where we
> have a remapped region at the bottom of the DMA address space and a
> bypass (direct map) region high up.
> 
> Basically, we can fix it, at least for most platforms, but it will be
> hard, invasive, *and* will need to go to stable. Grmbl.

Well, it was originally a hack for altix, because they had no regions
below 4GB and had to specifically manufacture them.  As you know, in
Linux, if Intel doesn't need it, no-one cares and the implementation
bitrots.

> We'll have to replace our "direct" DMA ops (which just apply an offset)
> which we use for devices that set a 64-bit mask on platform that support
> a bypass window, with some smart-ass hybrid variant that selectively
> shoot stuff up to the bypass window or down via the iommu remapped based
> on the applicable mask for a given operation.
> 
> It would be nice if we could come up with a way to inform the driver
> that we support that sort of "bypass" region with an offset. That would
> allow drivers that have that 64-bit base + 32-bit offset scheme to work
> much more efficiently for us. The driver could configure the base to be
> our "bypass window offset", and we could use ZONE_DMA32 for consistent
> DMAs.
> 
> It would also help us with things like some GPUs that can only do 40-bit
> DMA (which won't allow them to reach our bypass region normally) but do
> have a way to configure the generated top bits of all DMA addresses in
> some fixed register.
> 
> Any idea what such an interface might look like ?

Why doesn't the API we have today work (modulo a better implementation)?
A consistent mask specifies a wide range of possible locations for your
bypass region.  You just have to select one and attach it somehow and
remember to use it for consistent allocations.  As long as
set_consistent_mask becomes a dma op, it should all work, right?

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] arm64: add kdump support

[Pratyush Anand]

On Thursday 02 April 2015 11:07 AM, AKASHI Takahiro wrote:

Pratyush,

On 04/02/2015 01:58 PM, Pratyush Anand wrote:



On Thursday 02 April 2015 04:57 AM, AKASHI Takahiro wrote:

Please try my latest kexec-tools in my linaro repo (branch name is
kdump/v0.11)
and let me know the result.


Thanks a lot.. Just fetched your repo and found v.0.11.

With this crash kernel loaded successfully, if I do not use initrd.

With following I still see Overlapping memory segments

kexec -p  /home/panand/work/kernel/bsa2_kdump/vmlinux
--initrd=/boot/initramfs-3.19.0.bz1198945+.img --append=$( cat
/proc/cmdline ) maxcpus=1 mem=64M reset_devices


How big is your initrd?
If it is good small, please tell me segments info, or messages from
add_segment_phys_virt()
for all the segments.



add_segment_phys_virt: 0dcd0b90 - 0dcd0f90 (0400) - 
0040c3ff - 0040c400 (0001)
add_segment_phys_virt: 03ff88c10010 - 03ff8984a010 (00c3a000) - 
0040c008 - 0040c131 (0129)
add_segment_phys_virt: 0dcd53c0 - 0dcd96b8 (42f8) - 
0040c000 - 0040c001 (0001)
add_segment_phys_virt: 03ff87360010 - 03ff88bfcc2f (0189cc1f) - 
0040c001 - 0040c18b (018a)

Overlapping memory segments at 0x40c18b
sort_segments failed

Why do we try to fit dtb just after crash_reserved_mem.start. Should n't 
it should start after crash_reserved_mem.start + arm64_mem.text_offset + 
arm64_mem.image_size



I tried following and it works perfectly:

diff --git a/kexec/arch/arm64/crashdump-arm64.c 
b/kexec/arch/arm64/crashdump-arm64.c

index 41266f294589..75f4e4d269ca 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct 
kexec_info *info)

 off_t locate_dtb_in_crashmem(struct kexec_info *info, off_t dtb_size)
 {
return locate_hole(info, dtb_size, 128UL * 1024,
-   crash_reserved_mem.start, crash_reserved_mem.end, 1);
+   crash_reserved_mem.start + arm64_mem.text_offset +
+   arm64_mem.image_size, crash_reserved_mem.end, 1);
 }

With this changes new allocations are:
add_segment_phys_virt: 10350b90 - 10350f90 (0400) - 
0040c3ff - 0040c400 (0001)
add_segment_phys_virt: 03ff7ad70010 - 03ff7b9aa010 (00c3a000) - 
0040c008 - 0040c131 (0129)
add_segment_phys_virt: 103553c0 - 103596b8 (42f8) - 
0040c136 - 0040c137 (0001)
add_segment_phys_virt: 03ff794c0010 - 03ff7ad5cc2f (0189cc1f) - 
0040c137 - 0040c2c1 (018a)
add_segment_phys_virt: 103596c0 - 10360190 (6ad0) - 
0040c2c1 - 0040c2c2 (0001)



Crash kernel loaded upon panic.

~Pratyush
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86, aperture: Check for GART before accessing GART registers

[Borislav Petkov]

On Wed, Apr 01, 2015 at 09:32:08AM -0500, Aravind Gopalakrishnan wrote:
 GART registers are not present in newer processors (Fam15h, Model 10h
 and later). So, avoid accesses to GART registers in PCI config
 space by returning early in early_gart_iommu_check() and
 gart_iommu_hole_init() if GART is not available.
 
 Refactoring the family check used in amd_nb into an inline function
 so we can use it here as well as in amd_nb.c
 
 Tested the patch on Fam10h and Fam15h Model 00h-fh and this code
 runs fine. On Fam15h Model 60h-6fh and on Fam16h, we bail early
 as they don't have GART.
 
 Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
 Reviewed-by: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
 ---
  arch/x86/include/asm/amd_nb.h | 11 +++
  arch/x86/kernel/amd_nb.c  |  4 +---
  arch/x86/kernel/aperture_64.c |  4 ++--
  3 files changed, 14 insertions(+), 5 deletions(-)

Applied, thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 06/17 v2] tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values

[Namhyung Kim]

Hi Steve,

On Wed, Apr 01, 2015 at 09:56:54PM -0400, Steven Rostedt wrote:
 From: Steven Rostedt (Red Hat) rost...@goodmis.org
 
 Several tracepoints use the helper functions __print_symbolic() or
 __print_flags() and pass in enums that do the mapping between the
 binary data stored and the value to print. This works well for reading
 the ASCII trace files, but when the data is read via userspace tools
 such as perf and trace-cmd, the conversion of the binary value to a
 human string format is lost if an enum is used, as userspace does not
 have access to what the ENUM is.
 
 For example, the tracepoint trace_tlb_flush() has:
 
  __print_symbolic(REC-reason,
 { TLB_FLUSH_ON_TASK_SWITCH, flush on task switch },
 { TLB_REMOTE_SHOOTDOWN, remote shootdown },
 { TLB_LOCAL_SHOOTDOWN, local shootdown },
 { TLB_LOCAL_MM_SHOOTDOWN, local mm shootdown })
 
 Which maps the enum values to the strings they represent. But perf and
 trace-cmd do no know what value TLB_LOCAL_MM_SHOOTDOWN is, and would
 not be able to map it.
 
 With TRACE_DEFINE_ENUM(), developers can place these in the event header
 files and ftrace will convert the enums to their values:
 
 By adding:
 
  TRACE_DEFINE_ENUM(TLB_FLUSH_ON_TASK_SWITCH);
  TRACE_DEFINE_ENUM(TLB_REMOTE_SHOOTDOWN);
  TRACE_DEFINE_ENUM(TLB_LOCAL_SHOOTDOWN);
  TRACE_DEFINE_ENUM(TLB_LOCAL_MM_SHOOTDOWN);
 
  $ cat /sys/kernel/debug/tracing/events/tlb/tlb_flush/format
 [...]
  __print_symbolic(REC-reason,
 { 0, flush on task switch },
 { 1, remote shootdown },
 { 2, local shootdown },
 { 3, local mm shootdown })
 
 The above is what userspace expects to see, and tools do not need to
 be modified to parse them.
 
 Cc: Guilherme Cox c...@computer.org
 Cc: Tony Luck tony.l...@gmail.com
 Cc: Xie XiuQi xiexi...@huawei.com
 Signed-off-by: Steven Rostedt rost...@goodmis.org


[SNIP]
 diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
 index db54dda10ccc..6b7fd0bf5d28 100644
 --- a/kernel/trace/trace_events.c
 +++ b/kernel/trace/trace_events.c
 @@ -1704,6 +1704,102 @@ __register_event(struct ftrace_event_call *call, 
 struct module *mod)
   return 0;
  }
  
 +static char *enum_replace(char *ptr, struct trace_enum_map *map, int len)
 +{
 + int rlen;
 + int elen;
 +
 + /* Find the length of the enum value as a string */
 + elen = snprintf(ptr, 0, %ld, map-enum_value);
 + /* Make sure there's enough room to replace the string with the value */
 + if (len  elen)
 + return NULL;
 +
 + snprintf(ptr, elen + 1, %ld, map-enum_value);
 +
 + /* Get the rest of the string of ptr */
 + rlen = strlen(ptr + len);
 + memmove(ptr + elen, ptr + len, rlen);
 + /* Make sure we end the new string */
 + ptr[elen + rlen] = 0;
 +
 + return ptr + elen;
 +}
 +
 +static void update_event_printk(struct ftrace_event_call *call,
 + struct trace_enum_map *map)
 +{
 + char *ptr;
 + int quote = 0;
 + int len = strlen(map-enum_string);
 +
 + for (ptr = call-print_fmt; *ptr; ptr++) {
 + if (*ptr == '\\') {
 + ptr++;
 + /* paranoid */
 + if (!*ptr)
 + break;
 + continue;
 + }
 + if (*ptr == '') {
 + quote ^= 1;
 + continue;
 + }
 + if (quote)
 + continue;
 + if (isdigit(*ptr)) {
 + /* skip numbers */
 + do {
 + ptr++;
 + } while (isalnum(*ptr) || *ptr == '_');
 + /* we went one too many */

Hmm.. it looks like to skip variable name after a number.  Shouldn't it be 

do { ptr++; } while (isdigit(*ptr));

?


 + ptr--;
 + continue;
 + }
 + if (isalpha(*ptr) || *ptr == '_') {
 + if (strncmp(map-enum_string, ptr, len) == 0 
 + !isalnum(ptr[len])  ptr[len] != '_') {
 + ptr = enum_replace(ptr, map, len);
 + /* Hmm, enum string smaller than value */
 + if (WARN_ON_ONCE(!ptr))
 + return;
 + continue;

I guess it also needs to decrease the ptr here.


 + }
 + do {
 + ptr++;
 + } while (isalnum(*ptr) || *ptr == '_');
 + /* we went one too many */
 + ptr--;
 + continue;
 + }
 + }
 +}
 +
 +void trace_event_enum_update(struct trace_enum_map *map, int len)
 +{
 + struct ftrace_event_call *call, *p;
 + const char *last_system = NULL;
 + int last_i;
 + int i;
 +
 + 

Re: [PATCH] perf: annotate: make it respect -i option.

[Namhyung Kim]

On Thu, Apr 02, 2015 at 06:04:52AM +, Wang Nan wrote:
 There is a bug in perf annotate that it doesn't respect user provided
 '-i'/'--input' option:
 
  # perf record ls
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (8 samples) ]
  # mv ./perf.data ./perf.data.new
  # perf annotate -i ./perf.data.new  --stdio
failed to open perf.data: No such file or directory  (try 'perf record' 
 first)
 
 This patch fix it by setting file path after option parsing, like
 what 'perf report' does.
 
 Signed-off-by: Wang Nan wangn...@huawei.com

I guess other commands are also suffered from this bug.. anyway,

Acked-by: Namhyung Kim namhy...@kernel.org

Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build regression in next-20150331

[Peter Zijlstra]

On Wed, Apr 01, 2015 at 11:46:10PM +0200, Rafael J. Wysocki wrote:

   ---
kernel/time/tick-internal.h |2 ++
1 file changed, 2 insertions(+)
  
   Index: linux-pm/kernel/time/tick-internal.h
   ===
   --- linux-pm.orig/kernel/time/tick-internal.h
   +++ linux-pm/kernel/time/tick-internal.h
   @@ -110,7 +110,9 @@ static inline int tick_broadcast_update_
/* Set the periodic handler in non broadcast mode */
static inline void tick_set_periodic_handler(struct clock_event_device 
   *dev, int broadcast)
{
   +#ifdef CONFIG_GENERIC_CLOCKEVENTS
   dev-event_handler = tick_handle_periodic;
   +#endif
}
#endif /* !BROADCAST */

 Peter, do you think the above is acceptable or do I need to do anything more
 sophisticated to fix this?  [The alternative would be probably to prepare an
 empty definition of tick_handle_periodic() for CONFIG_GENERIC_CLOCKEVENTS and
 move the definition of struct clock_event_device from under that Kconfig
 option.]


Does not something like the below make more sense? The entire broadcast
thing doesn't make sense if we don't have generic_clockevents.

Should we wrap more in generic_clockevents there?

---
 kernel/time/tick-internal.h |2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 2a1563a..5569e65 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -81,6 +81,7 @@ static inline int tick_check_oneshot_change(int allow_nohz) { 
return 0; }
 #endif /* !TICK_ONESHOT */
 
 /* Broadcasting support */
+#ifdef CONFIG_GENERIC_CLOCKEVENTS
 #ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
 extern int tick_device_uses_broadcast(struct clock_event_device *dev, int cpu);
 extern void tick_install_broadcast_device(struct clock_event_device *dev);
@@ -114,6 +115,7 @@ static inline void tick_set_periodic_handler(struct 
clock_event_device *dev, int
dev-event_handler = tick_handle_periodic;
 }
 #endif /* !BROADCAST */
+#endif /* GENERIC */
 
 /* Functions related to oneshot broadcasting */
 #if defined(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST)  
defined(CONFIG_TICK_ONESHOT)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] arm64: dts: exynos: Add EHCI and OHCI dt node for Exynos5433

[Chanwoo Choi]

From: Jaewon Kim jaewon02@samsung.com

This patch adds EHCI and OHCI device tree node
to usb USB2.0 Host and HSCI(High Speed Inter-Chip) function.

Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 43 ++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index faea1c6..8a1875d 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -916,6 +916,49 @@
io-channel-ranges;
status = disabled;
};
+
+   ehci: usb@1551 {
+   compatible = samsung,exynos4210-ehci;
+   reg = 0x1551 0x1000;
+   interrupts = 0 230 0;
+   clocks = cmu_fsys CLK_ACLK_USBHOST20;
+   clock-names = usbhost;
+   #address-cells = 1;
+   #size-cells = 0;
+   status = disabled;
+
+   port@0 {
+   reg = 0;
+   phys = usb2_phy 0;
+   status = disabled;
+   };
+   port@1 {
+   reg = 1;
+   phys = usb2_phy 1;
+   status = disabled;
+   };
+   };
+
+   ohci: usb@1552 {
+   compatible = samsung,exynos4210-ohci;
+   reg = 0x1552 0x1000;
+   interrupts = 0 230 0;
+   clocks = cmu_fsys CLK_ACLK_USBHOST20;
+   clock-names = usbhost;
+   #address-cells = 1;
+   #size-cells = 0;
+   status = disabled;
+   };
+
+   usb2_phy: usb2phy@1553 {
+   compatible = samsung,exynos5433-usb2-phy;
+   reg = 0x1553 0x100;
+   samsung,pmureg-phandle = pmu_system_controller;
+   clocks = cmu_fsys CLK_ACLK_USBHOST20, xxti;
+   clock-names = phy, ref;
+   #phy-cells = 1;
+   status = disabled;
+   };
};
 
timer {
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] arm64: dts: exynos: Add USB Device dt node for Exynos5433

[Chanwoo Choi]

From: Jaewon Kim jaewon02@samsung.com

This patch adds USB DRD(Dual Role Device) and PHY
device tree node to use USB Device.

Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 8a1875d..b460f5f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -959,6 +959,53 @@
#phy-cells = 1;
status = disabled;
};
+
+   usbdrd30: usb@1540 {
+   compatible = samsung,exynos5250-dwusb3;
+   clocks = cmu_fsys CLK_ACLK_USBDRD30,
+   cmu_fsys CLK_SCLK_USBDRD30;
+   clock-names = usbdrd30, usbdrd30_susp_clk;
+   assigned-clocks =
+   cmu_fsys CLK_MOUT_SCLK_USBDRD30_USER,
+   cmu_top CLK_MOUT_SCLK_USBDRD30,
+   cmu_top CLK_DIV_SCLK_USBDRD30;
+   assigned-clock-parents =
+   cmu_top CLK_SCLK_USBDRD30_FSYS,
+   cmu_top CLK_MOUT_BUS_PLL_USER;
+   assigned-clock-rates = 0, 0, 6670;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   status = disabled;
+
+   dwc3 {
+   compatible = snps,dwc3;
+   reg = 0x1540 0x1;
+   interrupts = 0 231 0;
+   phys = usbdrd30_phy 0, usbdrd30_phy 1;
+   phy-names = usb2-phy, usb3-phy;
+   };
+
+   };
+
+   usbdrd30_phy: phy@1550 {
+   compatible = samsung,exynos5433-usbdrd-phy;
+   reg = 0x1550 0x100;
+   clocks = cmu_fsys CLK_ACLK_USBDRD30, xxti,
+   cmu_fsys CLK_PHYCLK_USBDRD30_UDRD30_PHYCLOCK,
+   cmu_fsys 
CLK_PHYCLK_USBDRD30_UDRD30_PIPE_PCLK,
+   cmu_fsys CLK_SCLK_USBDRD30;
+   clock-names = phy, ref, phy_utmi, phy_pipe, 
itp;
+   assigned-clocks =
+   cmu_fsys 
CLK_MOUT_PHYCLK_USBDRD30_UDRD30_PIPE_PCLK_USER,
+   cmu_fsys 
CLK_MOUT_PHYCLK_USBDRD30_UDRD30_PHYCLOCK_USER;
+   assigned-clock-parents =
+   cmu_fsys 
CLK_PHYCLK_USBDRD30_UDRD30_PIPE_PCLK_PHY,
+   cmu_fsys 
CLK_PHYCLK_USBDRD30_UDRD30_PHYCLOCK_PHY;
+   #phy-cells = 1;
+   samsung,pmu-syscon = pmu_system_controller;
+   status = disabled;
+   };
};
 
timer {
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/2] perf scripting cleanups

[Jiri Olsa]

On Thu, Apr 02, 2015 at 05:16:09PM +0900, Namhyung Kim wrote:
 On Wed, Apr 01, 2015 at 01:36:48PM -0300, Arnaldo Carvalho de Melo wrote:
  Hi David, Jiri,
  
  Please take a look if it is ok for you guys
  
  Adrian, there is another thing:
  
db_export__sample(tables-dbe, event, sample, evsel, al-thread, al);
  
  In tools/perf/util/scripting-engines/trace-event-python.c has this 
  redundancy
  as well, see the (al-thread, al), I'll probably remove that extra thread 
  parm
  there if you don't have any other subtle use for that...
 
 For both patches,
 
 Acked-by: Namhyung Kim namhy...@kernel.org

looks ok for me too

Acked-by: Jiri Olsa jo...@kernel.org


jirka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/6] arm64: dts: exynos: Add USB/PWM/UART3/reboot dt node for Exynos5433 SoC

[Chanwoo Choi]

This patch-set add the following devicetree to support USB/PWM/UART3/reboot.
- USB 3.0 DRD (Dual Role Device) and host
- PWM (Pulse Width Modulation)
- UART3
- System reboot

Depend on:

This patch-set have the dependnecy on following patch[1] to support USB 3.0
Host and DRD (Dual Role Device) for Exynos5433 SoC. This patch[1] was merged
by Kishon Vijay Abraham I (GENERIC PHY FRAMEWORK maintainer).
[1] https://lkml.org/lkml/2015/3/25/984
: [PATCH RESEND] phy: exynos5-usbdrd: Add to support for Exynos5433 SoC

Beomho Seo (1):
  arm64: dts: exynos: Add UART3 dt node for Exynos5433 SoC

Jaewon Kim (4):
  arm64: dts: exynos: Add EHCI and OHCI dt node for Exynos5433
  arm64: dts: exynos: Add USB Device dt node for Exynos5433
  arm64: dts: exynos: Add USB3.0 Host dt node for Exynos5433
  arm64: dts: exynos: Add PWM dt node and pinctrl for Exynos5433 SoC

Joonyoung Shim (1):
  arm64: dts: exynos: add reboot node for exynos5433

 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  35 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 167 +
 2 files changed, 202 insertions(+)

-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sched: Improve load balancing in the presence of idle CPUs

[Morten Rasmussen]

On Thu, Apr 02, 2015 at 04:30:34AM +0100, Jason Low wrote:
 On Wed, 2015-04-01 at 18:04 +0100, Morten Rasmussen wrote:
  On Wed, Apr 01, 2015 at 07:49:56AM +0100, Preeti U Murthy wrote:
   
   On 04/01/2015 12:24 AM, Jason Low wrote:
On Tue, 2015-03-31 at 14:07 +0530, Preeti U Murthy wrote:
Hi Jason,
   
On 03/31/2015 12:25 AM, Jason Low wrote:
Hi Preeti,
   
I noticed that another commit 4a725627f21d converted the check in
nohz_kick_needed() from idle_cpu() to rq-idle_balance, causing a
potentially outdated value to be used if this cpu is able to pull 
tasks
using rebalance_domains(), and nohz_kick_needed() directly returning
false.
   
I see that rebalance_domains() will be run at the end of the scheduler
tick interrupt handling. trigger_load_balance() only sets the softirq,
it does not call rebalance_domains() immediately. So the call graph
would be:

Oh right, since that only sets the softirq, this wouldn't be the issue,
though we would need these changes if we were to incorporate any sort of
nohz_kick_needed() logic into the nohz_idle_balance() code path correct?
   
   I am sorry I don't quite get this. Can you please elaborate?
  
  I think the scenario is that we are in nohz_idle_balance() and decide to
  bail out because we have pulled some tasks, but before leaving
  nohz_idle_balance() we want to check if more balancing is necessary
  using nohz_kick_needed() and potentially kick somebody to continue.
 
  Note that the balance cpu is currently skipped in nohz_idle_balance(),
  but if it wasn't the scenario would be possible.
 
 This scenario would also be possible if we call rebalance_domains()
 first again.

Yes.

 I'm wondering if adding the nohz_kick_needed(), ect... in
 nohz_idle_balance() can address the 10 second latency issue while still
 calling rebalance_domains() first, since it seems more ideal to try
 balancing on the current awake CPU first, as you also have mentioned

I believe it could. That is where I was going with the chain-of-kicks
idea. I think the main cause of the unacceptable you are observing is
due to nohz_kicks only being issued at the tick. So if the balancer
pulls for itself first and bails out the next kick won't be issued until
the next tick or even multiple ticks later depending on
nohz.next_balance.

I haven't figured out if there is a reason for delaying the next
nohz_idle_balance() though. 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] perf report: segfault when annotate kernel module.

[Wang Nan]

Hi folks,

I hit a segfault when try to analysis a perf.data generated in an aarch 64 
board.
I tried execute perf report on x86 and arm64, both of them hit similar segfault:

 $ perf report -i ./buggy/perf.data --objdump=/path/to/aarch64-oe-linux-objdump 
--kallsyms /path/to/kallsyms

perf: Segmentation fault
 backtrace 
/home/user/perf[0x503478]
/lib64/libc.so.6(+0x3545f)[0x7f5e6944b45f]
/home/user/perf[0x499b56]
/home/user/perf(dso__load_kallsyms+0x13c)[0x49b56c]
/home/user/perf(dso__load+0x72e)[0x49c21e]
/home/user/perf(map__load+0x6e)[0x4ae9ee]
/home/user/perf(thread__find_addr_map+0x24c)[0x47deec]
/home/user/perf(perf_event__preprocess_sample+0x88)[0x47e238]
/home/user/perf[0x43ad02]
/home/user/perf[0x4b55bc]
/home/user/perf(ordered_events__flush+0x1a9)[0x4b58c9]
/home/user/perf(perf_session__process_events+0x407)[0x4b42d7]
/home/user/perf(cmd_report+0xf11)[0x43bfc1]
/home/user/perf[0x474702]
/home/user/perf(main+0x5f5)[0x42de95]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x7f5e69437bd4]
/home/user/perf[0x42dfc4]

I did some debugging and found the problem is raised at dso__load_kcore:

static int dso__load_kcore(struct dso *dso, struct map *map,
   const char *kallsyms_filename)
{
struct map_groups *kmaps = map__kmap(map)-kmaps;// kmap is NULL 
here
struct machine *machine = kmaps-machine;// segfault.
...
}

Then I realised that if a struct map is created by machine__new_module with 
map__new2,
the map__kmap(map) is never set. However, if I set

map-map_ip = map-unmap_ip = identity__map_ip;
kmap = map__kmap(map);
kmap-kmaps = machine-kmaps;

in machine__new_module like in __machine__create_kernel_maps, I hit another 
problem:

*** Error in `/home/user/perf': free(): invalid next size (normal): 
0x02411a60 ***
=== Backtrace: =
/lib64/libc.so.6(+0x6eeef)[0x7f2ed502feef]
/lib64/libc.so.6(+0x78cae)[0x7f2ed5039cae]
/lib64/libc.so.6(+0x79987)[0x7f2ed503a987]
/home/user/perf(dso__data_fd+0x456)[0x496be6]
/home/user/perf(dso__type+0x1a)[0x4987ea]
/home/user/perf(vdso__dso_findnew+0x7d)[0x4d2cbd]
/home/user/perf(map__new+0x2c3)[0x4ae7c3]
/home/user/perf[0x4a90fa]
/home/user/perf(machine__process_mmap2_event+0xc1)[0x4acbf1]
/home/user/perf[0x4b1fec]
/home/user/perf(perf_session__process_events+0x3bf)[0x4b45ff]
/home/user/perf(cmd_report+0xf12)[0x43bfc2]
/home/user/perf[0x474703]
/home/user/perf(main+0x5f6)[0x42de96]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f2ed4fe2bd5]
/home/user/perf[0x42dfc5]
=== Memory map: 
...

Does anyone has any idea on it?

Thank you!

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 -next 11/11] serial: 8250_early: Remove setup_early_serial8250_console()

[Yinghai Lu]

On Wed, Apr 1, 2015 at 8:22 PM, Peter Hurley pe...@hurleysoftware.com wrote:
 The documented behavior of console=ttyS options, to which your
 quote refers, clearly states:

 Default is 9600n8.

drivers/tty/serial/8250/8250_early.c:early_serial8250_setup
still have calling to probe_baud, but it is not triggered.

Here is root cause.
The gap between entries in earlycon_table cause
iteration fail to find next entry, so uart8250 handler is
not called proplerly.

attached patch fix the problem.

Thanks

Yinghai
Subject: [PATCH] serial: Fix earlycon section iteration

Found when booting with console=uart8250,io,0x3f8
the kernel will revert baud rate to 9600 instead of keeping 115200.

root causes: The gap between entries in earlycon_table cause
iteration fail to find next entry, so uart8250 handler is
not called proplerly.

commit d2fd6810a823 (tty/serial: convert 8250 to generic earlycon)
add two entries into earlycon_table.
 EARLYCON_DECLARE(uart8250, early_serial8250_setup);
 EARLYCON_DECLARE(uart, early_serial8250_setup);

and according to System.map, earlycon_uart is before earlycon_uart8250.
  832049a0 t __earlycon_uart
  832049c0 t __earlycon_uart8250
And offset between two entries is 0x20.

commit 470ca0de69fe (serial: earlycon: Enable earlycon without command line param)
setup_earlycon() will loop __earlycon_table with pointer to earlycon_id,
	for (match = __earlycon_table; match-name[0]; match++) {
   size_t len = strlen(match-name);

   if (strncmp(buf, match-name, len))
   continue;

but match size (size of struct earlycon_id) is only 0x18.  so will point to
wrong place for next match and will get random result.

Make the earlycon_table section have pointer to earlycon_id struct instead.

Fixes: commit 470ca0de69fe (serial: earlycon: Enable earlycon without command line param)
Signed-off-by: Yinghai Lu ying...@kernel.org

---
 drivers/tty/serial/earlycon.c |   13 +++--
 include/asm-generic/vmlinux.lds.h |8 
 include/linux/serial_core.h   |8 +---
 3 files changed, 16 insertions(+), 13 deletions(-)

Index: linux-2.6/include/linux/serial_core.h
===
--- linux-2.6.orig/include/linux/serial_core.h
+++ linux-2.6/include/linux/serial_core.h
@@ -349,10 +349,12 @@ extern int of_setup_earlycon(unsigned lo
 			 int (*setup)(struct earlycon_device *, const char *));
 
 #define EARLYCON_DECLARE(_name, func)	\
-	static const struct earlycon_id __earlycon_##_name		\
-		__used __section(__earlycon_table)			\
+	static struct earlycon_id __earlycon_##_name __initdata	\
 		 = { .name  = __stringify(_name),			\
-		 .setup = func  }
+		 .setup = func  };	\
+	static struct earlycon_id *__p_earlycon_##_name	__used		\
+		__aligned(sizeof(struct earlycon_id *))			\
+		__section(__earlycon_table) = { __earlycon_##_name }
 
 #define OF_EARLYCON_DECLARE(name, compat, fn)\
 	_OF_DECLARE(earlycon, name, compat, fn, void *)
Index: linux-2.6/drivers/tty/serial/earlycon.c
===
--- linux-2.6.orig/drivers/tty/serial/earlycon.c
+++ linux-2.6/drivers/tty/serial/earlycon.c
@@ -37,9 +37,8 @@ static struct earlycon_device early_cons
 	.con = early_con,
 };
 
-extern struct earlycon_id __earlycon_table[];
-static const struct earlycon_id __earlycon_table_sentinel
-	__used __section(__earlycon_table_end);
+extern struct earlycon_id *__start_earlycon_table[];
+extern struct earlycon_id *__stop_earlycon_table[];
 
 static const struct of_device_id __earlycon_of_table_sentinel
 	__used __section(__earlycon_of_table_end);
@@ -103,7 +102,7 @@ static int __init parse_options(struct e
 	return 0;
 }
 
-static int __init register_earlycon(char *buf, const struct earlycon_id *match)
+static int __init register_earlycon(char *buf, struct earlycon_id *match)
 {
 	int err;
 	struct uart_port *port = early_console_dev.port;
@@ -147,7 +146,7 @@ static int __init register_earlycon(char
  */
 int __init setup_earlycon(char *buf)
 {
-	const struct earlycon_id *match;
+	struct earlycon_id **pmatch;
 
 	if (!buf || !buf[0])
 		return -EINVAL;
@@ -155,7 +154,9 @@ int __init setup_earlycon(char *buf)
 	if (early_con.flags  CON_ENABLED)
 		return -EALREADY;
 
-	for (match = __earlycon_table; match-name[0]; match++) {
+	for (pmatch = __start_earlycon_table; pmatch  __stop_earlycon_table;
+	 pmatch++) {
+		struct earlycon_id *match = *pmatch;
 		size_t len = strlen(match-name);
 
 		if (strncmp(buf, match-name, len))
Index: linux-2.6/include/asm-generic/vmlinux.lds.h
===
--- linux-2.6.orig/include/asm-generic/vmlinux.lds.h
+++ linux-2.6/include/asm-generic/vmlinux.lds.h
@@ -151,10 +151,10 @@
 #endif
 
 #ifdef CONFIG_SERIAL_EARLYCON
-#define EARLYCON_TABLE() . = ALIGN(8);\
-			 VMLINUX_SYMBOL(__earlycon_table) = .;	\
-			 

Re: sched: Improve load balancing in the presence of idle CPUs

[Morten Rasmussen]

On Thu, Apr 02, 2015 at 06:59:07AM +0100, Jason Low wrote:
 On Wed, 2015-04-01 at 18:04 +0100, Morten Rasmussen wrote:
  On Wed, Apr 01, 2015 at 07:49:56AM +0100, Preeti U Murthy wrote:
 
   I am sorry I don't quite get this. Can you please elaborate?
  
  I think the scenario is that we are in nohz_idle_balance() and decide to
  bail out because we have pulled some tasks, but before leaving
  nohz_idle_balance() we want to check if more balancing is necessary
  using nohz_kick_needed() and potentially kick somebody to continue.
 
 Also, below is an example patch.
 
 (Without the conversion to idle_cpu(), the check for rq-idle_balance
 would not be accurate anymore)
 
 ---
  kernel/sched/fair.c |   17 ++---
  1 files changed, 10 insertions(+), 7 deletions(-)
 
 diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
 index fdae26e..7749a14 100644
 --- a/kernel/sched/fair.c
 +++ b/kernel/sched/fair.c
 @@ -7620,6 +7620,8 @@ out:
  }
  
  #ifdef CONFIG_NO_HZ_COMMON
 +static inline bool nohz_kick_needed(struct rq *rq);
 +
  /*
   * In CONFIG_NO_HZ_COMMON case, the idle balance kickee will do the
   * rebalancing for all the cpus for whom scheduler ticks are stopped.
 @@ -7629,6 +7631,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum 
 cpu_idle_type idle)
   int this_cpu = this_rq-cpu;
   struct rq *rq;
   int balance_cpu;
 + bool done_balancing = false;
  
   if (idle != CPU_IDLE ||
   !test_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu)))
 @@ -7644,7 +7647,7 @@ static void nohz_idle_balance(struct rq *this_rq, enum 
 cpu_idle_type idle)
* balancing owner will pick it up.
*/
   if (need_resched())
 - break;
 + goto end;
  
   rq = cpu_rq(balance_cpu);
  
 @@ -7663,9 +7666,12 @@ static void nohz_idle_balance(struct rq *this_rq, enum 
 cpu_idle_type idle)
   if (time_after(this_rq-next_balance, rq-next_balance))
   this_rq-next_balance = rq-next_balance;
   }
 + done_balancing = true;
   nohz.next_balance = this_rq-next_balance;
  end:
   clear_bit(NOHZ_BALANCE_KICK, nohz_flags(this_cpu));
 + if (!done_balancing  nohz_kick_needed(this_rq))
 + nohz_balancer_kick();
  }
  
  /*
 @@ -7687,7 +7693,7 @@ static inline bool nohz_kick_needed(struct rq *rq)
   int nr_busy, cpu = rq-cpu;
   bool kick = false;
  
 - if (unlikely(rq-idle_balance))
 + if (unlikely(idle_cpu(cpu)))
   return false;
  
 /*
 @@ -7757,16 +7763,13 @@ static void run_rebalance_domains(struct 
 softirq_action *h)
   enum cpu_idle_type idle = this_rq-idle_balance ?
   CPU_IDLE : CPU_NOT_IDLE;
  
 + rebalance_domains(this_rq, idle);
   /*
* If this cpu has a pending nohz_balance_kick, then do the
* balancing on behalf of the other idle cpus whose ticks are
 -  * stopped. Do nohz_idle_balance *before* rebalance_domains to
 -  * give the idle cpus a chance to load balance. Else we may
 -  * load balance only within the local sched_domain hierarchy
 -  * and abort nohz_idle_balance altogether if we pull some load.
 +  * stopped.
*/
   nohz_idle_balance(this_rq, idle);
 - rebalance_domains(this_rq, idle);
  }

I think this should reduce the latency Preeti is seeing and avoid
unnecessary wake-ups, however, it may not be quite as aggressive in
spreading tasks quickly. It will stop the chain-of-kicks as soon as the
balancer cpu has pulled only one task. The source cpu may still be
having two tasks and other cpus may still have more than two tasks
running.

Depending on how bad it is, we could consider kicking another cpu if the
imbalance is still significant after the balancer cpu has pulled a task.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: Show clock rate instead of return value

[Chanwoo Choi]

This patch shows the current clock rate instead of return value
when clk_set_rate() return fail because log message means the clock rate.

Cc: Mike Turquette mturque...@linaro.org
Cc: Stephen Boyd sb...@codeaurora.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
 drivers/clk/clk-conf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-conf.c b/drivers/clk/clk-conf.c
index aad4796..fb1ee65 100644
--- a/drivers/clk/clk-conf.c
+++ b/drivers/clk/clk-conf.c
@@ -107,8 +107,8 @@ static int __set_clk_rates(struct device_node *node, bool 
clk_supplier)
 
rc = clk_set_rate(clk, rate);
if (rc  0)
-   pr_err(clk: couldn't set %s clock rate: %d\n,
-  __clk_get_name(clk), rc);
+   pr_err(clk: couldn't set %s clock rate: %ld\n,
+  __clk_get_name(clk), clk_get_rate(clk));
clk_put(clk);
}
index++;
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 1/2] mfd/axp20x: add support for extcon cell

[Lee Jones]

On Thu, 02 Apr 2015, Ramakrishna Pallala wrote:

 This patch adds the mfd cell info for axp288 extcon device.
 
 Signed-off-by: Ramakrishna Pallala ramakrishna.pall...@intel.com
 ---
  drivers/mfd/axp20x.c   |   28 
  include/linux/mfd/axp20x.h |5 +
  2 files changed, 33 insertions(+)

[...]

 diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
 index dfabd6d..4ed8071 100644
 --- a/include/linux/mfd/axp20x.h
 +++ b/include/linux/mfd/axp20x.h
 @@ -275,4 +275,9 @@ struct axp20x_fg_pdata {
   int thermistor_curve[MAX_THERM_CURVE_SIZE][2];
  };
  
 +struct axp288_extcon_pdata {
 + /* GPIO pin control to switch D+/D- lines b/w PMIC and SOC */
 + struct gpio_desc *gpio_mux_cntl;
 +};

This chunk of code is unrelated to this patch.

... and does it need to be in a struct of its own?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LKP] [timer] 17cdf560f27: +4.0% boot-meminfo.VmallocUsed

[Peter Zijlstra]

On Thu, Apr 02, 2015 at 09:06:09AM +0800, Huang Ying wrote:
 FYI, we noticed the below changes on
 
 git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git 
 timer/alloc_tvec_statically
 commit 17cdf560f2727f687ab159707d0aa591f8a2f82d (timer: Allocate per-cpu 
 tvec_base's statically)
 
 
 testbox/testcase/testparams: lkp-sbx04/boot/performance-1
 
 c5e77f5216abdd1d  17cdf560f2727f687ab159707d  
   --  
  %stddev %change %stddev
  \  |\  
 410996 ±  0%  +4.0% 427412 ±  0%  boot-meminfo.VmallocUsed
 
 testbox/testcase/testparams: wsm/boot/performance-1
 
 c5e77f5216abdd1d  17cdf560f2727f687ab159707d  
   --  
  85712 ±  0%  +2.4%  87772 ±  0%  boot-meminfo.VmallocUsed
 
 testbox/testcase/testparams: lkp-snb01/boot/performance-1
 
 c5e77f5216abdd1d  17cdf560f2727f687ab159707d  
   --  
 447001 ±  0%  -1.0% 442558 ±  0%  boot-slabinfo.num_objs
 125616 ±  5% -13.5% 108720 ±  4%  boot-meminfo.DirectMap4k
 347196 ±  0%  +4.7% 363612 ±  0%  boot-meminfo.VmallocUsed
 

well, duh.. it changes a dynamic allocation into a static per-cpu one.
What did you expect?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ARM: EXYNOS: Get current parent clock for power domain on/off

[Krzysztof Kozlowski]

Using a fixed (by DTS) parent for clocks when turning on the power domain
may introduce issues in other drivers. For example when such driver
changes the parent during runtime and expects that he is the only place
of such change.

Do not rely entirely on DTS providing the fixed parent for such clocks.
Instead if pclkN clock name is missing, grab a current parent of clock
with clk_get_parent().

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 8 +---
 arch/arm/mach-exynos/pm_domains.c | 9 ++---
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5da38c5ed476..0fc1312f6fd5 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -19,9 +19,11 @@ Optional Properties:
domains.
 - clock-names: The following clocks can be specified:
- oscclk: Oscillator clock.
-   - pclkN, clkN: Pairs of parent of input clock and input clock to the
-   devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
-   are supported currently.
+   - pclkN, clkN: Input clocks (clkN) to the devices in this power domain.
+   Optionally with parrents (pclkN). If such parent is provided
+   it will be used for reparenting the given clock when domain
+   is turned on. Otherwise the parent before power down will be
+   used. Maximum of 4 pairs (N = 0 to 3) are supported currently.
- asbN: Clocks required by asynchronous bridges (ASB) present in
the power domain. These clock should be enabled during power
domain on/off operations.
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index cbe56b35aea0..c55bcf52a6ad 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -37,6 +37,7 @@ struct exynos_pm_domain {
struct clk *oscclk;
struct clk *clk[MAX_CLK_PER_DOMAIN];
struct clk *pclk[MAX_CLK_PER_DOMAIN];
+   unsigned int pclk_dynamic:MAX_CLK_PER_DOMAIN;
struct clk *asb_clk[MAX_CLK_PER_DOMAIN];
 };
 
@@ -62,6 +63,9 @@ static int exynos_pd_power(struct generic_pm_domain *domain, 
bool power_on)
for (i = 0; i  MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd-clk[i]))
break;
+   /* If parent was not set in DT, save current parent */
+   if (pd-pclk_dynamic  (1  i))
+   pd-pclk[i] = clk_get_parent(pd-clk[i]);
if (clk_set_parent(pd-clk[i], pd-oscclk))
pr_err(%s: error setting oscclk as parent to 
clock %d\n,
pd-name, i);
@@ -164,9 +168,8 @@ static __init int exynos4_pm_init_power_domain(void)
snprintf(clk_name, sizeof(clk_name), pclk%d, i);
pd-pclk[i] = clk_get(dev, clk_name);
if (IS_ERR(pd-pclk[i])) {
-   clk_put(pd-clk[i]);
-   pd-clk[i] = ERR_PTR(-EINVAL);
-   break;
+   pd-pclk_dynamic |= (1  i);
+   pd-pclk[i] = clk_get_parent(pd-clk[i]);
}
}
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] ARM: dts: Use last parent for clocks during power domain on/off

[Krzysztof Kozlowski]

Replace fixed parent with last parent (obtained with clk_get_parent())
of clocks for devices in mfc and disp power domains. This should improve
behavior if such clocks were reparented by the drivers and new parents
are different than those specified in DTS.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index c7a44ee0ce06..b9b99305991b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -264,9 +264,8 @@
mfc_pd: power-domain@10044060 {
compatible = samsung,exynos4210-pd;
reg = 0x10044060 0x20;
-   clocks = clock CLK_FIN_PLL, clock CLK_MOUT_SW_ACLK333,
-   clock CLK_MOUT_USER_ACLK333;
-   clock-names = oscclk, pclk0, clk0;
+   clocks = clock CLK_FIN_PLL, clock CLK_MOUT_USER_ACLK333;
+   clock-names = oscclk, clk0;
#power-domain-cells = 0;
};
 
@@ -280,16 +279,12 @@
compatible = samsung,exynos4210-pd;
reg = 0x100440C0 0x20;
#power-domain-cells = 0;
-   clocks = clock CLK_FIN_PLL, clock CLK_MOUT_SW_ACLK200,
+   clocks = clock CLK_FIN_PLL,
 clock CLK_MOUT_USER_ACLK200_DISP1,
-clock CLK_MOUT_SW_ACLK300,
 clock CLK_MOUT_USER_ACLK300_DISP1,
-clock CLK_MOUT_SW_ACLK400,
 clock CLK_MOUT_USER_ACLK400_DISP1,
 clock CLK_FIMD1, clock CLK_MIXER;
-   clock-names = oscclk, pclk0, clk0,
- pclk1, clk1, pclk2, clk2,
- asb0, asb1;
+   clock-names = oscclk, clk0, clk1, clk2, asb0, asb1;
};
 
pinctrl_0: pinctrl@1340 {
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/5] regulator: Introduce property to flag drms

[Mark Brown]

On Wed, Apr 01, 2015 at 03:55:43PM -0700, Bjorn Andersson wrote:
 Introduce regulator-allow-drms to make it possible for board
 configuration to enable drms for regulators.

I don't think this is a good name, nobody unfamiliar with a fairly
obscure feature in the Linux regulator API is going to know what DRMS
means.  Something like change-load might be clearer.


signature.asc
Description: Digital signature

Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups

[Jean Delvare]

Le Thursday 02 April 2015 à 01:23 -0700, Christoph Hellwig a écrit :
 The class ids are a hardware defintion, not a kernel API.  Just use the
 definitions from libpci, or copy over the kernel header if you prefer
 it over the libpci definutions.

I agree with Christoph, such defines would better come from
pciutils-devel, not the kernel.

-- 
Jean Delvare
SUSE L3 Support

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Qemu-devel] [PATCH v4 11/15] target-s390x: New QMP command query-cpu-model

[Michael Mueller]

On Wed, 1 Apr 2015 20:05:24 -0300
Eduardo Habkost ehabk...@redhat.com wrote:

   
   If you don't want to encode that knowledge in libvirt or other
   management software for s390, it looks like you need something like a
   stable-abi-safe field on CpuDefinitionInfo?  
  
  Exactly that fulfills the name field for s390 already in my view.
  
  And cpu model none just means that QEMU does not manage the cpu model. 
  That's also
  the reason why I initially returned an empty [] model and not none. 
  This somewhat
  convinces me to go back to this approach...  
 
 I understand the reasons for your approach and it seems to work for
 s390, but the only problem I see is that you are adding an additional
 (undocumented?) s390-specific constraint to the semantics of
 query-cpu-models: that the model name will appear on the list only if it
 can be safely migratable. This may prevent us from unifying CPU model
 code into generic code later.

I agree that an aliases is something different compared with the CPU model none 
as
there is a CPU class representing it. And thus, when implicitly or explicitly 
selected,
shall be presented in the CPU definition list as well. If I would set 
runnable to
false as it now (bad), it would be sorted out by the considered for migration 
test but it
would be misleading as it is always runnable. Though an additional field like 
migrate-able
could express that characteristic.

 
 But if we add a simple stable-abi-safe field to the list (even if s390
 set it to to true for all models and omit aliases and none in this
 first version), we will have clearer semantics that can still be
 honoured by other architectures (and by generic code) later.

To be honest I currently don't right get the idea that you follow with that
stable-abi-save field... But eventually yes (I wrote this before the section 
above)

The stable-abi-save field means: Take me into account for whatever kind of
CPU model related comparison you perform between two running QEMU instances as I
represent a well defined aspect.

Thus CPU model none will be { name: none, runnable: true, 
stable-abi-save: false } and
the aliases can be represented as { name: alias, runnable: true|false, 
stable-abi-save:
false } in the s390 case, right?

Michael


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] clk: Provide always-on clock support

[Lee Jones]

On Thu, 02 Apr 2015, Jassi Brar wrote:

 On Wed, Apr 1, 2015 at 7:12 AM, Michael Turquette mturque...@linaro.org 
 wrote:
  Quoting Jassi Brar (2015-03-02 02:28:44)
  On 2 March 2015 at 15:48, Lee Jones lee.jo...@linaro.org wrote:
   On Mon, 02 Mar 2015, Jassi Brar wrote:
  
   On Mon, Mar 2, 2015 at 2:06 PM, Lee Jones lee.jo...@linaro.org wrote:
On Sat, 28 Feb 2015, Jassi Brar wrote:
   
On 28 February 2015 at 02:44, Lee Jones lee.jo...@linaro.org wrote:
 Lots of platforms contain clocks which if turned off would prove 
 fatal.
 The only way to recover from these catastrophic failures is to 
 restart
 the board(s).  Now, when a clock is registered with the framework 
 it is
 compared against a list of provided always-on clock names which 
 must be
 kept ungated.  If it matches, we enable the existing 
 CLK_IGNORE_UNUSED
 flag, which will prevent the common clk framework from attempting 
 to
 gate it during the clk_disable_unused() procedure.

If a clock is critical on a certain board, it could be got+enabled
during early boot so there is always a user.
   
I tried this.  There was push-back from the DT maintainers.
   
  
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/324417.html
   
   Thanks, I wasn't aware of the history.
  
To be able to do that from DT, maybe add a new, say, CLK_ALWAYS_ON
flag could be made to initialize the clock with one phantom user
already. Or just reuse the CLK_IGNORE_UNUSED?
   
How is that different to what this set is doing?
   
   The phantom user - that's there but none can see it.
  
   How about?
  
   +   of_property_for_each_string(np, clock-always-on, prop, 
   clkname) {
   +   clk = __clk_lookup(clkname);
   +   if (!clk)
   +   continue;
   +
   +   clk-core-enable_count = 1;
   +   clk-core-prepare_count = 1;
   +   }
  
   This is only fractionally different from the current implementation.
  
   I believe the current way it slightly nicer, as we don't have to fake
   the user count.
  
  Well... the user is indeed there, isn't it? It's just not known to
  Linux. So 'fake' isn't most applicable here.
  Otherwise you might have to stub out some existing and future
  functions for CLK_IGNORE_UNUSED. And how do we explain to userspace
  which would see power drawn but no user of the clock?
 
  Jassi,
 
  This is broken. What if the parent of this clock has
  {enable,prepare}_count of zero? The way we propagate these refcounts up
  the tree would fall over.
 
 Yeah it needs to be done at higher level,
 - clk-core-enable_count = 1;
 - clk-core-prepare_count = 1;
 + clk_prepare_enable(clk);

FYI: https://lkml.org/lkml/2015/4/1/267

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] efivarfs: Ensure VariableName is NUL-terminated

[Ross Lagerwall]

Some buggy firmware implementations update VariableNameSize on success
such that it does not include the final NUL character which results in
garbage in the efivarfs name entries.  Use kzalloc on the efivar_entry
(as is done in efivars.c) to ensure that the name is always
NUL-terminated.

The buggy firmware is:
BIOS Information
Vendor: Intel Corp.
Version: S1200RP.86B.02.02.0005.102320140911
Release Date: 10/23/2014
BIOS Revision: 4.6
System Information
Manufacturer: Intel Corporation
Product Name: S1200RP_SE

Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com
---
 fs/efivarfs/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c
index ddbce42..acf9a67 100644
--- a/fs/efivarfs/super.c
+++ b/fs/efivarfs/super.c
@@ -121,7 +121,7 @@ static int efivarfs_callback(efi_char16_t *name16, 
efi_guid_t vendor,
int len, i;
int err = -ENOMEM;
 
-   entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
if (!entry)
return err;
 
-- 
2.1.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Apr 2

[Stephen Rothwell]

Hi all,

There will be no linux-next releases on Friday or Monday (mainly due to
hot cross buns and chocolate eggs :-)).

Changes since 20150401:

*crickets*

Non-merge commits (relative to Linus' tree): 7955
 7152 files changed, 327404 insertions(+), 153265 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (d4039314d0b1 Merge tag 'iommu-fixes-v4.0-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1)
Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify)
Merging arm-current/fixes (8defb3367fcd ARM: 8320/1: fix integer overflow in 
ELF_ET_DYN_BASE)
Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet 
bridging)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1)
Merging powerpc-merge-mpe/fixes (d52356e7f48e powerpc: fix memory corruption by 
pnv_alloc_idle_core_states)
Merging sparc/master (90a5a895cc8b Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging net/master (f5f321c43150 Merge tag 
'wireless-drivers-for-davem-2015-04-01' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers)
Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in 
xfrm_lookup())
Merging sound-current/for-linus (af95b41426e0 ALSA: hda - Add one more node in 
the EAPD supporting candidate list)
Merging pci-current/for-linus (bc3b5b47c80d PCI: cpcihp: Add missing curly 
braces in cpci_configure_slot())
Merging wireless-drivers/master (69628cd0652a Merge tag 
'iwlwifi-for-kalle-2015-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (bc465aa9d045 Linux 4.0-rc5)
Merging tty.current/tty-linus (8e4934c6d6c6 tty: serial: fsl_lpuart: clear 
receive flag on FIFO flush)
Merging usb.current/usb-linus (d3a3d28f1c7e Merge tag 'usb-serial-4.0-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (65582a7f4ce5 usb: isp1760: fix spin unlock in 
the error path of isp1760_udc_start)
Merging usb-serial-fixes/usb-linus (b229a0f840f7 USB: ftdi_sio: Use jtag quirk 
for SNAP Connect E10)
Merging staging.current/staging-linus (dce5bdfe8fc1 Merge tag 
'iio-fixes-for-4.0d' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (bc465aa9d045 Linux 4.0-rc5)
Merging input-current/for-linus (33096777519a Input: define 
INPUT_PROP_ACCELEROMETER behavior)
Merging crypto-current/master (ccfe8c3f7e52 crypto: aesni - fix memory usage in 
GCM decryption)
Merging ide/master (b314acaccd7e Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging devicetree-current/devicetree/merge (41d9489319f2 drivers/of: Add empty 
ranges quirk for PA-Semi)
Merging rr-fixes/fixes (f47689345931 lguest: update help text.)
Merging vfio-fixes/for-linus (ec76f4007079 vfio-pci: Add missing break to 
enable VFIO_PCI_ERR_IRQ_INDEX)
Merging kselftest-fixes/fixes (67d8712dcc70 selftests: Fix build failures when 

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

[Peter Zijlstra]

On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote:
 Ingo suggested that the timekeeping debugging variables
 recently added should not be global, and should be tied
 to the timekeeper's read_base.

But why? its the same hardware clock for both tkr's. Surely if one goes
funny the other will too.

It doesn't make sense to duplicate this.

 I'm a little hesitant here, since the tkr structure
 has been carefully designed to fit in a cacheline.
 However, these additions are all at the end of the
 structure and are conditionally compiled.

That.

  include/linux/timekeeper_internal.h | 18 +-
  kernel/time/timekeeping.c   | 33 ++---
  2 files changed, 27 insertions(+), 24 deletions(-)
 
 diff --git a/include/linux/timekeeper_internal.h 
 b/include/linux/timekeeper_internal.h
 index fb86963..9b33027 100644
 --- a/include/linux/timekeeper_internal.h
 +++ b/include/linux/timekeeper_internal.h
 @@ -20,9 +20,13 @@
   * @shift:   Shift value for scaled math conversion
   * @xtime_nsec: Shifted (fractional) nano seconds offset for readout
   * @base:ktime_t (nanoseconds) base time for readout
 + * @last_warning:   Warning ratelimiter (DEBUG_TIMEKEEPING)
 + * @underflow_seen: Underflow warning flag (DEBUG_TIMEKEEPING)
 + * @overflow_seen:  Overflow warning flag (DEBUG_TIMEKEEPING)
   *
   * This struct has size 56 byte on 64 bit. Together with a seqcount it
 - * occupies a single 64byte cache line.
 + * occupies a single 64byte cache line (when DEBUG_TIMEKEEPING is not
 + * enabled).
   *
   * The struct is separate from struct timekeeper as it is also used
   * for a fast NMI safe accessors.
 @@ -36,6 +40,18 @@ struct tk_read_base {
   u32 shift;
   u64 xtime_nsec;
   ktime_t base;
 +#ifdef CONFIG_DEBUG_TIMEKEEPING
 + longlast_warning;
 + /*
 +  * These simple flag variables are managed
 +  * without locks, which is racy, but ok since
 +  * we don't really care about being super
 +  * precise about how many events were seen,
 +  * just that a problem was observed.
 +  */
 + int underflow_seen;
 + int overflow_seen;
 +#endif
  };

Yeah, so what is the likelyhood of a distro blanked enabling that debug?

I really don't like this much.

Also, you're now lacking a call to timekeeping_check_update(tkr_raw),
you update stats there but have no way to report on them.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] arm64: add kdump support

[AKASHI Takahiro]

On 04/02/2015 03:01 PM, Pratyush Anand wrote:



On Thursday 02 April 2015 11:07 AM, AKASHI Takahiro wrote:

Pratyush,

On 04/02/2015 01:58 PM, Pratyush Anand wrote:



On Thursday 02 April 2015 04:57 AM, AKASHI Takahiro wrote:

Please try my latest kexec-tools in my linaro repo (branch name is
kdump/v0.11)
and let me know the result.


Thanks a lot.. Just fetched your repo and found v.0.11.

With this crash kernel loaded successfully, if I do not use initrd.

With following I still see Overlapping memory segments

kexec -p  /home/panand/work/kernel/bsa2_kdump/vmlinux
--initrd=/boot/initramfs-3.19.0.bz1198945+.img --append=$( cat
/proc/cmdline ) maxcpus=1 mem=64M reset_devices


How big is your initrd?
If it is good small, please tell me segments info, or messages from
add_segment_phys_virt()
for all the segments.



add_segment_phys_virt: 0dcd0b90 - 0dcd0f90 (0400) - 
0040c3ff - 0040c400 (0001)
add_segment_phys_virt: 03ff88c10010 - 03ff8984a010 (00c3a000) - 
0040c008 - 0040c131 (0129)
add_segment_phys_virt: 0dcd53c0 - 0dcd96b8 (42f8) - 
0040c000 - 0040c001 (0001)
add_segment_phys_virt: 03ff87360010 - 03ff88bfcc2f (0189cc1f) - 
0040c001 - 0040c18b (018a)
Overlapping memory segments at 0x40c18b
sort_segments failed

Why do we try to fit dtb just after crash_reserved_mem.start. Should n't it 
should start after crash_reserved_mem.start
+ arm64_mem.text_offset + arm64_mem.image_size


Yeah, worth considering :)

-Takahiro AKASHI



I tried following and it works perfectly:

diff --git a/kexec/arch/arm64/crashdump-arm64.c 
b/kexec/arch/arm64/crashdump-arm64.c
index 41266f294589..75f4e4d269ca 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct 
kexec_info *info)
  off_t locate_dtb_in_crashmem(struct kexec_info *info, off_t dtb_size)
  {
 return locate_hole(info, dtb_size, 128UL * 1024,
-   crash_reserved_mem.start, crash_reserved_mem.end, 1);
+   crash_reserved_mem.start + arm64_mem.text_offset +
+   arm64_mem.image_size, crash_reserved_mem.end, 1);
  }

With this changes new allocations are:
add_segment_phys_virt: 10350b90 - 10350f90 (0400) - 
0040c3ff - 0040c400 (0001)
add_segment_phys_virt: 03ff7ad70010 - 03ff7b9aa010 (00c3a000) - 
0040c008 - 0040c131 (0129)
add_segment_phys_virt: 103553c0 - 103596b8 (42f8) - 
0040c136 - 0040c137 (0001)
add_segment_phys_virt: 03ff794c0010 - 03ff7ad5cc2f (0189cc1f) - 
0040c137 - 0040c2c1 (018a)
add_segment_phys_virt: 103596c0 - 10360190 (6ad0) - 
0040c2c1 - 0040c2c2 (0001)


Crash kernel loaded upon panic.

~Pratyush

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ASoC: atmel-pcm-dma: increase buffer_bytes_max

[Alexandre Belloni]

On 01/04/2015 at 21:33:42 +0100, Mark Brown wrote :
 On Mon, Mar 30, 2015 at 09:40:37PM +0200, Alexandre Belloni wrote:
  atmel-pcm-dma is not limited to a buffer size of 64kB like atmel-pcm-pdc.
  Increase buffer_bytes_max to 512kB to allow for higher bit rates (i.e. 
  32bps at
  192kHz) to work correctly. By default, keep the prealloc at 64kB.
 
 Applied, but please look into Lars' suggestion - we should be able to
 just figure everything out from the DMA controller.

This is definitively on the TODO list.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/9] Documentation: nbd: Add list of module parameters

[Markus Pargmann]

Add a list of available module parameters as attachment to the
documentation.

Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 Documentation/blockdev/nbd.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/blockdev/nbd.txt b/Documentation/blockdev/nbd.txt
index 337946bd460e..db242ea2bce8 100644
--- a/Documentation/blockdev/nbd.txt
+++ b/Documentation/blockdev/nbd.txt
@@ -19,3 +19,13 @@ The nbd kernel module need only be installed on the client
 system, as the nbd-server is completely in userspace. In fact,
 the nbd-server has been successfully ported to other operating
 systems, including Windows.
+
+A) NBD parameters
+-
+
+max_part
+   Number of partitions per device (default: 0).
+
+nbds_max
+   Number of block devices that should be initialized (default: 16).
+
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] perf tools: unify perf_event_attr printing

[Ingo Molnar]

* Peter Zijlstra pet...@infradead.org wrote:

 With some feedback from Jolsa, who showed me how to trigger the actual
 outputs.
 
 ---
 
 Subject: perf, tools: Merge all perf_event_attr print functions
 From: Peter Zijlstra pet...@infradead.org
 Date: Tue Mar 31 13:01:54 CEST 2015
 
 Currently there's 3 (that I found) different and incomplete
 implementations of printing perf_event_attr.
 
 This is quite silly. Merge the lot.
 
 While this patch does not retain the exact form all printing that I
 found is debug output and thus it should not be critical.
 
 Also, I cannot find a single print_event_desc() caller.
 
 Pre:
 
 $ perf record -vv -e cycles -- sleep 1
 
 perf_event_attr:
   type0
   size104
   config  0
   sample_period   4000
   sample_freq 4000
   sample_type 0x107
   read_format 0
   disabled1inherit 1
   pinned  0exclusive   0
   exclude_user0exclude_kernel  0
   exclude_hv  0exclude_idle0
   mmap1comm1
   mmap2   1comm_exec   1
   freq1inherit_stat0
   enable_on_exec  1task1
   watermark   0precise_ip  0
   mmap_data   0sample_id_all   1
   exclude_host0exclude_guest   1
   excl.callchain_kern 0excl.callchain_user 0
   wakeup_events   0
   wakeup_watermark0
   bp_type 0
   bp_addr 0
   config1 0
   bp_len  0
   config2 0
   branch_sample_type  0
   sample_regs_user0
   sample_stack_user   0
   sample_regs_intr0
 
 
 $ perf evlist  -vv
 cycles: sample_freq=4000, size: 104, sample_type: IP|TID|TIME|PERIOD,
 disabled: 1, inherit: 1, mmap: 1, mmap2: 1, comm: 1, comm_exec: 1,
 freq: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest:
 1
 
 Post:
 
 $ ./perf record -vv -e cycles -- sleep 1 
 
 perf_event_attr:
   size 112
   { sample_period, sample_freq }   4000
   sample_type  IP|TID|TIME|PERIOD
   disabled 1
   inherit  1
   mmap 1
   comm 1
   freq 1
   enable_on_exec   1
   task 1
   sample_id_all1
   exclude_guest1
   mmap21
   comm_exec1
 
 
 $ ./perf evlist  -vv
 cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type:
 IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq:
 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1,
 mmap2: 1, comm_exec: 1
 
 Cc: a...@redhat.com
 Cc: jo...@redhat.com
 Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
 ---
  tools/perf/util/Build  |1 
  tools/perf/util/evsel.c|  181 
 ++---
  tools/perf/util/header.c   |   34 ++-
  tools/perf/util/print_attr.h   |   69 +++
  tools/perf/util/print_helper.c |   52 +++
  tools/perf/util/print_helper.h |7 +
  6 files changed, 170 insertions(+), 174 deletions(-)

Acked-by: Ingo Molnar mi...@kernel.org

Thanks,

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/9] nbd: Remove kernel internal header

[Markus Pargmann]

The header is not included anywhere. Remove it and include the private
nbd_device struct in nbd.c.

Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 drivers/block/nbd.c | 22 ++
 include/linux/nbd.h | 46 --
 2 files changed, 22 insertions(+), 46 deletions(-)
 delete mode 100644 include/linux/nbd.h

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 4bc2a5cb9935..58c2b20ad17b 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -38,6 +38,28 @@
 
 #include linux/nbd.h
 
+struct nbd_device {
+   int flags;
+   int harderror;  /* Code of hard error   */
+   struct socket * sock;   /* If == NULL, device is not ready, yet */
+   int magic;
+
+   spinlock_t queue_lock;
+   struct list_head queue_head;/* Requests waiting result */
+   struct request *active_req;
+   wait_queue_head_t active_wq;
+   struct list_head waiting_queue; /* Requests to be sent */
+   wait_queue_head_t waiting_wq;
+
+   struct mutex tx_lock;
+   struct gendisk *disk;
+   int blksize;
+   u64 bytesize;
+   pid_t pid; /* pid of nbd-client, if attached */
+   int xmit_timeout;
+   int disconnect; /* a disconnect has been requested by user */
+};
+
 #define NBD_MAGIC 0x68797548
 
 #ifdef NDEBUG
diff --git a/include/linux/nbd.h b/include/linux/nbd.h
deleted file mode 100644
index f62f78aef4ac..
--- a/include/linux/nbd.h
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * 1999 Copyright (C) Pavel Machek, pa...@ucw.cz. This code is GPL.
- * 1999/11/04 Copyright (C) 1999 VMware, Inc. (Regis HPReg Duchesne)
- *Made nbd_end_request() use the io_request_lock
- * 2001 Copyright (C) Steven Whitehouse
- *New nbd_end_request() for compatibility with new linux block
- *layer code.
- * 2003/06/24 Louis D. Langholtz l...@aros.net
- *Removed unneeded blksize_bits field from nbd_device struct.
- *Cleanup PARANOIA usage  code.
- * 2004/02/19 Paul Clements
- *Removed PARANOIA, plus various cleanup and comments
- */
-#ifndef LINUX_NBD_H
-#define LINUX_NBD_H
-
-
-#include linux/wait.h
-#include linux/mutex.h
-#include uapi/linux/nbd.h
-
-struct request;
-
-struct nbd_device {
-   int flags;
-   int harderror;  /* Code of hard error   */
-   struct socket * sock;   /* If == NULL, device is not ready, yet */
-   int magic;
-
-   spinlock_t queue_lock;
-   struct list_head queue_head;/* Requests waiting result */
-   struct request *active_req;
-   wait_queue_head_t active_wq;
-   struct list_head waiting_queue; /* Requests to be sent */
-   wait_queue_head_t waiting_wq;
-
-   struct mutex tx_lock;
-   struct gendisk *disk;
-   int blksize;
-   u64 bytesize;
-   pid_t pid; /* pid of nbd-client, if attached */
-   int xmit_timeout;
-   int disconnect; /* a disconnect has been requested by user */
-};
-
-#endif
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] arm64: dts: exynos: Add UART3 dt node for Exynos5433 SoC

[Chanwoo Choi]

From: Beomho Seo beomho@samsung.com

This patch adds the UART3 devicetree node for Exynos5433 SoC. The UART3 device
is included in AUD_DOMAIN.

Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Beomho Seo beomho@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  7 +++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 
 2 files changed, 19 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
index 49be038..f2d7a39 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -83,6 +83,13 @@
samsung,pin-pud = 1;
samsung,pin-drv = 0;
};
+
+   uart_aud_bus: uart-aud-bus {
+   samsung,pins = gpz1-3, gpz1-2, gpz1-1, gpz1-0;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
 };
 
 pinctrl_cpif {
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index baeec299..f179c60 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -475,6 +475,18 @@
status = disabled;
};
 
+   serial_3: serial@1146 {
+   compatible = samsung,exynos5433-uart;
+   reg = 0x1146 0x100;
+   interrupts = 0 67 0;
+   clocks = cmu_aud CLK_PCLK_AUD_UART,
+cmu_aud CLK_SCLK_AUD_UART;
+   clock-names = uart, clk_uart_baud0;
+   pinctrl-names = default;
+   pinctrl-0 = uart_aud_bus;
+   status = disabled;
+   };
+
i2s0: i2s0@1144 {
compatible = samsung,exynos7-i2s;
reg = 0x1144 0x100;
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] SQUASHME: Fixes to e820 handling of pmem

[Ingo Molnar]

* Christoph Hellwig h...@lst.de wrote:

 On Wed, Apr 01, 2015 at 05:25:22PM +0300, Boaz Harrosh wrote:
  pfn = PFN_DOWN(ei-addr + ei-size);
   
  -   switch (ei-type) {
  -   case E820_RAM:
  -   case E820_PRAM:
  -   case E820_RESERVED_KERN:
  -   break;
  -   default:
  +   if (ei-type != E820_RAM  ei-type != E820_RESERVED_KERN)
  register_nosave_region(PFN_UP(ei-addr), pfn);
  -   }
 
 I guess this makes sense - if the content is persistent already we don't need
 to save it.
 
  -   if (e820.map[i].type != E820_RESERVED || res-start  
  (1ULL20)) {
  -   if (e820.map[i].type != E820_PRAM)
  -   res-flags |= IORESOURCE_BUSY;
  +   if (((e820.map[i].type != E820_RESERVED) 
  +(e820.map[i].type != E820_PRAM)) ||
  +res-start  (1ULL20)) {
 
 So now we also trigger for PRAM regions under 1ULL20, was that the
 intentional change?  Honestly I don't really understand this 1ULL20
 magic here even for the existing case.  Guess this is magic from the
 old ISA PC days?  
 
  +   res-flags |= IORESOURCE_BUSY;
 
 Guess this is the real change, and I'd love to understand why this 
 makes a difference for you.  IORESOURCE_BUSY is checked almost 
 never, and is intented to mean it's a driver mapping.

So assuming this works on your test setup I'm inclined to squash 
Boaz's fixes into the original patch, assuming you see no outright bug 
in them. Anything else can be done as delta improvements.

Agreed?

Thanks,

Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] dt: paz00: define nvec as child of i2c bus

[Marc Dietrich]

Am Mittwoch, 1. April 2015, 11:28:32 schrieb Stephen Warren:
 On 03/31/2015 09:46 AM, Andrey Danin wrote:
  On 31.03.2015 17:09, Stephen Warren wrote:
  On 03/31/2015 12:40 AM, Andrey Danin wrote:
  Hi,
  
  Thanks for the review.
  
  On 03.02.2015 0:20, Stephen Warren wrote:

[ snipped old patch parts ]

  diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
  b/arch/arm/boot/dts/tegra20-paz00.dts
  
  -nvec@7000c500 {
  -compatible = nvidia,nvec;
  -reg = 0x7000c500 0x100;
  -interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
  -#address-cells = 1;
  -#size-cells = 0;
  +i2c@7000c500 {
  +status = okay;
  
clock-frequency = 8;
  
  -request-gpios = gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH;
  -slave-addr = 138;
  -clocks = tegra_car TEGRA20_CLK_I2C3,
  - tegra_car TEGRA20_CLK_PLL_P_OUT3;
  -clock-names = div-clk, fast-clk;
  -resets = tegra_car 67;
  -reset-names = i2c;
  +
  +nvec: nvec@45 {
  
  This doesn't feel correct. There's nothing here to indicate that this
  child device is a slave that is implemented by the host SoC rather than
  something external attached to the I2C bus.
  
  Perhaps you can get away with this, since the driver for nvidia,nvec
  only calls I2C APIs suitable for internal slaves rather than external
  slaves? Even so though, I think the distinction needs to be clearly
  marked in the DT so that any generic code outside the NVEC driver that
  parses the DT can determine the difference.
  
  I would recommend the I2C controller having #address-cells=2 with
  cell
  0 being 0==master,1==slave, cell 1 being the I2C address. The I2C
  driver
  would need to support #address-cells=1 for backwards-compatibility.

Stephen, we haven't used your suggestion because Wolfram disliked the idea in 
e.g. http://lkml.iu.edu/hypermail/linux/kernel/1409.1/03446.html

  Driver (nvec in this case) can decide what mode should it use according
  to compatible value. Is it not enough ?
  
  No, I don't think so.
  
  The I2C binding model is that each child of an I2C controller represents
  a device attached to the bus. which SW will communicate with using the
  I2C controller as master and the device as a slave. If there's no
  explicit representation of child-vs-slave in the DT, how does the I2C
  core know whether a particular node is intended to be accessed as a
  master or slave?
  
  Device driver registers itself via slave API. Bus driver calls
  appropriate callback function when needed.
  If device driver decides to access hardware via master API, then it can
  do it.
  
  Am I missing something ?
  
  In other words, without an explicit communicate with this device or
  implement this device as a slave flag, how could DT contain:
  
  i2c-controller {
  
   ...
   master@1a {
   
   compatible = foo,device;
   reg = 0x1a 1;
   
   };
   slave@1a {
   
   compatible = foo,device-slave;
   reg = 0x1a 1;
   
   };
  
  };
  
  where:
  
  - foo,device means: instantiate a driver to communicate with a device
  of this type.
  
  - foo,device-slave means: instantiate a driver to act as this I2C
  device.
  
  Sure it's possible for the drivers for those two nodes to simply use the
  I2C subsystem's master or slave APIs, but I suspect DT content would
  confuse the I2C core into thinking that two I2C devices with the same
  address had been represented in DT, and the I2C core would refuse to
  instantiate one of them. The solution here is for the reg value to
  encode a master vs. slave flag, so the I2C core can allow both a
  master and a slave for each address.
  
  If there is one device, then it must be one node. If there is two
  devices then it looks incorrect to me to have two devices with the same
  address. Does I2C allow two devices with same address ?
 
 One of the nodes is to indicate that the kernel should implement the
 slave mode device and one is to indicate that the kernel should
 implement the master mode device. Those two devices/nodes have
 completely different semantics, so while they share the I2C bus address
 they don't represent the same thing.
 
 Admittedly it would be uncommon to do this, since it'd be using the I2C
 bus in loopback mode. However, I don't see why we should set out to
 prevent that.

We are sitting between the chairs currently. I hope Wolfram can further 
comment on this.

Having a generic loopback slave driver which just echos all messages it 
received back to the master (on the same controller or a different one) would 
be nice IMHO. 

  I can imagine this:
  - we have hardware with I2C device. This device can act as master or as
  slave
  - we have device driver, that can work in one, other or both modes.
  
  If we want to force master or slave mode, we can use flags (for combined
  mode we can use two nodes, but it looks weird).
  If we want to let 

[PATCH] drivers: staging: rtl8723au: fix warning: cast to restricted __le16

[Piotr Witoslawski]

Signed-off-by: Piotr Witoslawski pwi...@gmail.com
---
 drivers/staging/rtl8723au/hal/rtl8723au_xmit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8723au/hal/rtl8723au_xmit.c 
b/drivers/staging/rtl8723au/hal/rtl8723au_xmit.c
index 1759487..256958e 100644
--- a/drivers/staging/rtl8723au/hal/rtl8723au_xmit.c
+++ b/drivers/staging/rtl8723au/hal/rtl8723au_xmit.c
@@ -51,7 +51,8 @@ static void rtl8192cu_cal_txdesc_chksum(struct tx_desc
*ptxdesc)
ptxdesc-txdw7 = cpu_to_le32(0x);
 
for (index = 0 ; index  count ; index++)
-   checksum = checksum ^ le16_to_cpu(*(usPtr + index));
+   checksum = checksum ^ le16_to_cpu(
+   *(__le16 *)(usPtr + index));
 
ptxdesc-txdw7 |= cpu_to_le32(0xchecksum);
 }
-- 
2.0.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/9] nbd: Remove fixme that was already fixed

[Markus Pargmann]

On Thu, Apr 02, 2015 at 02:05:34AM -0700, Christoph Hellwig wrote:
 On Thu, Apr 02, 2015 at 10:11:39AM +0200, Markus Pargmann wrote:
  +/*
  + * Forcibly shutdown the socket causing all listeners to error
  + */
   static void sock_shutdown(struct nbd_device *nbd, int lock)
   {
  -   /* Forcibly shutdown the socket causing all listeners
  -* to error
  -*
  -* FIXME: This code is duplicated from sys_shutdown, but
  -* there should be a more generic interface rather than
  -* calling socket ops directly here */
  if (lock)
  mutex_lock(nbd-tx_lock);
  if (nbd-sock) {
 
 Please also kill the conditional locking here in a future patch by
 moving it into the caller.

Yes, thanks. I will make a patch for that.

Best Regards,

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: Digital signature

[slave-dma:for-linus 26/28] drivers/dma/xgene-dma.c:396:25: sparse: incorrect type in assignment (different base types)

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git 
for-linus
head:   fe90ced9e9d7bdba75ccae83100ae656807a6261
commit: 9f2fd0dfa594d857fbdaeda523ff7a46f16567f5 [26/28] dmaengine: Add support 
for APM X-Gene SoC DMA engine driver
reproduce:
  # apt-get install sparse
  git checkout 9f2fd0dfa594d857fbdaeda523ff7a46f16567f5
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by )

 drivers/dma/xgene-dma.c:396:25: sparse: incorrect type in assignment 
 (different base types)
   drivers/dma/xgene-dma.c:396:25:expected unsigned long long [unsigned] 
[long] [long long] [usertype] noident
   drivers/dma/xgene-dma.c:396:25:got restricted __le64 [usertype] noident
 drivers/dma/xgene-dma.c:818:26: sparse: cast to restricted __le64
 drivers/dma/xgene-dma.c:818:26: sparse: cast to restricted __le64
 drivers/dma/xgene-dma.c:1626:5: sparse: symbol 'xgene_dma_init_ring_mngr' 
 was not declared. Should it be static?
   drivers/dma/xgene-dma.c:2088:1: sparse: symbol 
'__UNIQUE_ID_author__COUNTER__' has multiple initializers (originally 
initialized at drivers/dma/xgene-dma.c:2087)

Please review and possibly fold the followup patch.

vim +396 drivers/dma/xgene-dma.c

   380  [ERR_DESC_SRC_INT] = HFB reading src link address error,
   381  };
   382  
   383  static bool is_pq_enabled(struct xgene_dma *pdma)
   384  {
   385  u32 val;
   386  
   387  val = ioread32(pdma-csr_efuse + XGENE_SOC_JTAG1_SHADOW);
   388  return !(val  XGENE_DMA_PQ_DISABLE_MASK);
   389  }
   390  
   391  static void xgene_dma_cpu_to_le64(u64 *desc, int count)
   392  {
   393  int i;
   394  
   395  for (i = 0; i  count; i++)
  396  desc[i] = cpu_to_le64(desc[i]);
   397  }
   398  
   399  static u16 xgene_dma_encode_len(u32 len)
   400  {
   401  return (len  XGENE_DMA_MAX_BYTE_CNT) ?
   402  len : XGENE_DMA_16K_BUFFER_LEN_CODE;
   403  }
   404  

---
0-DAY kernel test infrastructureOpen Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH slave-dma] dmaengine: xgene_dma_init_ring_mngr() can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu fengguang...@intel.com
---
 xgene-dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index 2383528..aa61935 100755
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -1623,7 +1623,7 @@ static void xgene_dma_init_hw(struct xgene_dma *pdma)
 XGENE_DMA_DEV_ID_RD(val), XGENE_DMA_MAX_CHANNEL);
 }
 
-int xgene_dma_init_ring_mngr(struct xgene_dma *pdma)
+static int xgene_dma_init_ring_mngr(struct xgene_dma *pdma)
 {
if (ioread32(pdma-csr_ring + XGENE_DMA_RING_CLKEN) 
(!ioread32(pdma-csr_ring + XGENE_DMA_RING_SRST)))
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 1/2] mfd/axp20x: add support for extcon cell

[Ramakrishna Pallala]

This patch adds the mfd cell info for axp288 extcon device.

Signed-off-by: Ramakrishna Pallala ramakrishna.pall...@intel.com
---
 drivers/mfd/axp20x.c   |   28 
 include/linux/mfd/axp20x.h |5 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 0acbe52..a569721 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -290,6 +290,29 @@ static struct resource axp288_adc_resources[] = {
},
 };
 
+static struct resource axp288_extcon_resources[] = {
+   {
+   .start = AXP288_IRQ_VBUS_FALL,
+   .end   = AXP288_IRQ_VBUS_FALL,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_VBUS_RISE,
+   .end   = AXP288_IRQ_VBUS_RISE,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_MV_CHNG,
+   .end   = AXP288_IRQ_MV_CHNG,
+   .flags = IORESOURCE_IRQ,
+   },
+   {
+   .start = AXP288_IRQ_BC_USB_CHNG,
+   .end   = AXP288_IRQ_BC_USB_CHNG,
+   .flags = IORESOURCE_IRQ,
+   },
+};
+
 static struct resource axp288_charger_resources[] = {
{
.start = AXP288_IRQ_OV,
@@ -345,6 +368,11 @@ static struct mfd_cell axp288_cells[] = {
.resources = axp288_adc_resources,
},
{
+   .name = axp288_extcon,
+   .num_resources = ARRAY_SIZE(axp288_extcon_resources),
+   .resources = axp288_extcon_resources,
+   },
+   {
.name = axp288_charger,
.num_resources = ARRAY_SIZE(axp288_charger_resources),
.resources = axp288_charger_resources,
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index dfabd6d..4ed8071 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -275,4 +275,9 @@ struct axp20x_fg_pdata {
int thermistor_curve[MAX_THERM_CURVE_SIZE][2];
 };
 
+struct axp288_extcon_pdata {
+   /* GPIO pin control to switch D+/D- lines b/w PMIC and SOC */
+   struct gpio_desc *gpio_mux_cntl;
+};
+
 #endif /* __LINUX_MFD_AXP20X_H */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH urgent v2] x86, asm: Disable opportunistic SYSRET if regs-flags has TF set

[Borislav Petkov]

On Wed, Apr 01, 2015 at 02:26:34PM -0700, Andy Lutomirski wrote:
 When I wrote the opportunistic SYSRET code, I missed an important
 difference between SYSRET and IRET.  Both instructions are capable
 of setting EFLAGS.TF, but they behave differently when doing so.
 IRET will not issue a #DB trap after execution when it sets TF This
 is critical -- otherwise you'd never be able to make forward
 progress when returning to userspace.  SYSRET, on the other hand,
 will trap with #DB immediately after returning to CPL3, and the next
 instruction will never execute.
 
 This breaks anything that opportunistically SYSRETs to a user
 context with TF set.  For example, running this code with TF set and
 a SIGTRAP handler loaded never gets past post_nop.
 
   extern unsigned char post_nop[];
   asm volatile (pushfq\n\t
 popq %%r11\n\t
 nop\n\t
 post_nop:
 : : c (post_nop) : r11);
 
 In my defense, I can't find this documented in the AMD or Intel
 manual.
 
 Fix it by using IRET to restore TF.
 
 Fixes: 2a23c6b8a9c4 x86_64, entry: Use sysret to return to userspace when 
 possible
 Signed-off-by: Andy Lutomirski l...@kernel.org
 ---
 
 This affects 4.0-rc as well as -tip.  A full test case lives here:
 
 https://git.kernel.org/cgit/linux/kernel/git/luto/misc-tests.git/
 
 It's called single_step_syscall_64.
 
 On Intel systems, the 32-bit version of that test fails for unrelated
 reasons, but that's not a regression, and fixing it will be much more
 intrusive.
 
 Changes from v1:
  - Remove mention of testl from changelog.
  - Improve comment per Denys' suggestion.
 
 arch/x86/kernel/entry_64.S | 16 +++-
  1 file changed, 15 insertions(+), 1 deletion(-)
 
 diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
 index 750c6efcb718..537716380959 100644
 --- a/arch/x86/kernel/entry_64.S
 +++ b/arch/x86/kernel/entry_64.S
 @@ -715,7 +715,21 @@ retint_swapgs:   /* return to user-space */
   cmpq %r11,EFLAGS(%rsp)  /* R11 == RFLAGS */
   jne opportunistic_sysret_failed
  
 - testq $X86_EFLAGS_RF,%r11   /* sysret can't restore RF */
 + /*
 +  * SYSRET can't restore RF.  SYSRET can restore TF, but unlike IRET,
 +  * restoring TF results in a trap from userspace immediately after
 +  * SYSRET.  This would cause an infinite loop whenever #DB happens
 +  * with register state that satisfies the opportunistic SYSRET
 +  * conditions.  For example, single-stepping this user code:
 +  *
 +  *   movq $stuck_here,%rcx
 +  *   pushfq
 +  *   popq %r11
 +  *   stuck_here:
 +  *
 +  * would never get past stuck_here.
 +  */
 + testq $(X86_EFLAGS_RF|X86_EFLAGS_TF),%r11
   jnz opportunistic_sysret_failed
  
   /* nothing to check for RSP */

Acked-by: Borislav Petkov b...@suse.de

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: cma: add trace events for CMA allocations and freeings

[Joonsoo Kim]

Hello,

On Wed, Apr 01, 2015 at 04:31:43PM +0300, Stefan Strogin wrote:
 Add trace events for cma_alloc() and cma_release().
 
 The cma_alloc tracepoint is used both for successful and failed allocations,
 in case of allocation failure pfn=-1UL is stored and printed.
 
 Signed-off-by: Stefan Strogin stefan.stro...@gmail.com
 ---
 
 Took out from the patch set mm: cma: add some debug information for CMA v4
 (http://thread.gmane.org/gmane.linux.kernel.mm/129903) because of probable
 uselessness of the rest of the patches.

I think that patch 5/5 in previous submission is handy and
simple to merge. Although we can calculate it by using bitmap,
it would be good to get that information(used size and maxchunk size)
directly.


 @@ -414,6 +416,8 @@ struct page *cma_alloc(struct cma *cma, unsigned int 
 count, unsigned int align)
   start = bitmap_no + mask + 1;
   }
  
 + trace_cma_alloc(page ? pfn : -1UL, page, count);
 +

I think that tracing align is also useful.
Is there any reason not to include it?

Thanks.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] configfs: init configfs module earlier at boot time

[Daniel Baluta]

On Wed, Mar 18, 2015 at 9:56 PM, Daniel Baluta daniel.bal...@intel.com wrote:
 We need this earlier in the boot process to allow various subsystems
 to use configfs (e.g Industrial IIO).

 Also, debugfs is at core_initcall level and configfs should be on
 the same level from infrastructure point of view.

 Suggested-by: Lars-Peter Clausen l...@metafoo.de
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
 First time I miscopied Joel's email address.

  fs/configfs/mount.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/fs/configfs/mount.c b/fs/configfs/mount.c
 index da94e41..5373567 100644
 --- a/fs/configfs/mount.c
 +++ b/fs/configfs/mount.c
 @@ -173,5 +173,5 @@ MODULE_LICENSE(GPL);
  MODULE_VERSION(0.0.2);
  MODULE_DESCRIPTION(Simple RAM filesystem for user driven kernel subsystem 
 configuration.);

 -module_init(configfs_init);
 +core_initcall(configfs_init);
  module_exit(configfs_exit);
 --


Hi Joel,

Did you get any chance to look into this? I am not sure
exactly who should take this, so I'm adding Greg.

The original patch can also be found here:

https://lkml.org/lkml/2015/3/18/751

Daniel.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rhashtable] [ INFO: suspicious RCU usage. ]

[Thomas Graf]

On 04/02/15 at 12:29pm, Herbert Xu wrote:
 On Thu, Apr 02, 2015 at 12:11:35PM +0800, Fengguang Wu wrote:
  
  Yes it is contained in next-20150401 which is bad:
  
  # extra tests on tree/branch next/master
  git bisect  bad e954104e2b634b42811dad8d502cbf240f206df2  # 21:22  0-   
60  Add linux-next specific files for 20150401
  
  The dmesg there is
  
  [1.149409] test_firmware: interface ready
  [1.150293] Running resizable hashtable tests...
  [1.151209]   Adding 2048 keys
  [1.152069] [ cut here ]
  [1.152978] WARNING: CPU: 0 PID: 1 at lib/rhashtable.c:409 
  rhashtable_insert_rehash+0x9d/0x1d0()
 
 I see.  This is actually a completely different problem.
 
 ---8---
 test_rhashtable: Remove bogus max_size setting
 
 Now that resizing is completely automatic, we need to remove
 the max_size setting or the test will fail.
 
 Reported-by: Fengguang Wu fengguang...@intel.com
 Signed-off-by: Herbert Xu herb...@gondor.apana.org.au

Acked-by: Thomas Graf tg...@suug.ch

Had the same fix queued up in an upcoming series ;-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rtc-linux] [PATCH] rtc: Use more standard kernel logging styles

[Krzysztof Kozlowski]

2015-04-01 18:12 GMT+02:00 Joe Perches j...@perches.com:
 Neaten the logging a bit by adding #define pr_fmt

 Miscellanea:

 o Remove __FILE__/__func__ uses
 o Coalesce formats adding missing spaces
 o Align arguments
 o (rtc-cmos) Integrated 2 consecutive messages

 Signed-off-by: Joe Perches j...@perches.com

Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com

[Tested on Arndale Octa (rtc-s5m) and Trats2 (rtc-max77686)]
Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] phy: phy-rcar-gen2: Fix USBHS_UGSTS_LOCK value

[Yoshihiro Shimoda]

According to the technical update (No. TN-RCS-B011A/E), the UGSTS LOCK
bit location is bit 8, not bits 1 and 0. It also says that the register
address offset of UGSTS is 0x88, not 0x90.
So, this patch fixes the USBHS_UGSTS_LOCK value and some comments.

Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com
---
 drivers/phy/phy-rcar-gen2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-rcar-gen2.c b/drivers/phy/phy-rcar-gen2.c
index 778276a..97d45f4 100644
--- a/drivers/phy/phy-rcar-gen2.c
+++ b/drivers/phy/phy-rcar-gen2.c
@@ -23,7 +23,7 @@
 #define USBHS_LPSTS0x02
 #define USBHS_UGCTRL   0x80
 #define USBHS_UGCTRL2  0x84
-#define USBHS_UGSTS0x88/* The manuals have 0x90 */
+#define USBHS_UGSTS0x88/* From technical update */
 
 /* Low Power Status register (LPSTS) */
 #define USBHS_LPSTS_SUSPM  0x4000
@@ -41,7 +41,7 @@
 #define USBHS_UGCTRL2_USB0SEL_HS_USB   0x0030
 
 /* USB General status register (UGSTS) */
-#define USBHS_UGSTS_LOCK   0x0300 /* The manuals have 0x3 */
+#define USBHS_UGSTS_LOCK   0x0100 /* From technical update */
 
 #define PHYS_PER_CHANNEL   2
 
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v1 1/2] mfd/axp20x: add support for extcon cell

[Pallala, Ramakrishna]

Hi,

  diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
  index dfabd6d..4ed8071 100644
  --- a/include/linux/mfd/axp20x.h
  +++ b/include/linux/mfd/axp20x.h
  @@ -275,4 +275,9 @@ struct axp20x_fg_pdata {
  int thermistor_curve[MAX_THERM_CURVE_SIZE][2];
   };
 
  +struct axp288_extcon_pdata {
  +   /* GPIO pin control to switch D+/D- lines b/w PMIC and SOC */
  +   struct gpio_desc *gpio_mux_cntl;
  +};
 
 This chunk of code is unrelated to this patch.
As it's axp20x.h file change I added it here...if you don’t feel logical to 
have it in the patch I can move this to patch 2/2.


 ... and does it need to be in a struct of its own?
Yes, I am planning to add another gpio control for VBUS boost.

Thanks,
Ram
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH v3 0/4] clk: st: New always-on clock domain

[Geert Uytterhoeven]

Hi Lee,

On Thu, Mar 26, 2015 at 8:38 PM, Lee Jones lee.jo...@linaro.org wrote:
 On Thu, 26 Mar 2015, Geert Uytterhoeven wrote:
 On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones lee.jo...@linaro.org wrote:
  On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
  On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones lee.jo...@linaro.org wrote:
   On Fri, 06 Mar 2015, Mike Turquette wrote:
   This approach looks fine to me. In practice I think it is restricted to
   hardware blocks that don't exist in DT yet (e.g. no driver, in the case
   of your interconnect) and that restriction is probably for the best.
  
   Agreed.
 
  I think this restriction should be documented in the DT binding more 
  clearly,
  as adding a clk-always-on node prohibits you from handling the clock
  correctly in
  the future.
 
  Would you mind taking the time to explain what you think those
  limitations are?

 If you add a clk-always-on node, the clock will always on using that DT.
 That will still be true later, when you get a better understanding of the
 hardware, and might discover you're gonna need a driver for the currently
 hidden core component that's driven by the clock, and may want to manage
 that clock.

 So I have two points here.

 First point; I think you're looking at an older version of my set.
 The newer one can be found at [1] and no longer uses 'always-on'
 nodes.  Instead the 'clk-always-on' property is applied to the
 provider.  See the documentation patch [2] for more details.

Thanks, I was indeed looking at an old version.
Still, that doesn't change that the clock to not be disabled in specified
explicitly from DT.

 Second point; this binding is _not_ to be used as a hack because the
 hardware isn't understood.  Genuine uses are for clocks that must not
 be turned off ever, else bad things will happen.  If the hardware is
 not understood, use 'clk-disable-unused' on the kernel cmdline
 instead.

[...]

 (The same is true for devices where the current driver isn't aware of the
  clock, and shouldn't be, but you still need to enable the clock until the
  driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr.
  https://www.marc.info/?l=linux-pmm=142670617929493w=3 (good, now
  we have a bidirectional link between these two threads :-) Using a
  clk-always-on property there instead of adding a reference to the clock
  in the existing GIC device node would be just lying.)

 If this clock should _genuinely_ be always-on, then use my new
 binding in the clock controller node and the Clk framework will not
 turn it off.

It's supposed to be on when the application ARM core(s) is/are running.
Many SoCs also have smaller cores (SH, Cortex R or M), intended to
run a real-time OS. If the RT core is in charge, it may decide to shut down
the application ARM core(s), incl. supposedly always-on modules like
the ARM GIC.

I couldn't find a detailed block diagram of the STiH4xx SoCs, but at least
STiH416 has an ST proprietary multi-compartmental security IP and DRM
processor.

 [1] https://lkml.org/lkml/2015/2/27/548
 [2] https://lkml.org/lkml/2015/2/27/551

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mmotm 2015-04-01-14-54 uploaded

[Vladimir Murzin]

On 01/04/15 22:55, a...@linux-foundation.org wrote:
 * mm-move-memtest-under-mm.patch
 * mm-move-memtest-under-mm-fix.patch

It was noticed by Paul Bolle (and his clever bot) that patch above
simply disables MEMTEST altogether [1]. Could you fold fix for that, please?

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ea369dd..cd6d74b 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1810,7 +1810,7 @@ config TEST_UDELAY

 config MEMTEST
bool Memtest
-   depends on MEMBLOCK
+   depends on HAVE_MEMBLOCK
---help---
  This option adds a kernel parameter 'memtest', which allows memtest
  to be set.
--

[1] https://lkml.org/lkml/2015/3/20/119

Thanks
Vladimir

 * memtest-use-phys_addr_t-for-physical-addresses.patch
 * arm64-add-support-for-memtest.patch
 * arm-add-support-for-memtest.patch
 * kconfig-memtest-update-number-of-test-patterns-up-to-17.patch
 * documentation-update-arch-list-in-the-memtest-entry.patch

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] sched/deadline: fix try to pull pinned dl tasks in pull algorithm

[Wanpeng Li]

Function pick_next_earliest_dl_task is used to pick earliest and pushable 
dl task from overloaded cpus in pull algorithm, however, it traverses 
runqueue rbtree instead of pushable task rbtree which is also ordered by 
tasks' deadlines. This will result in getting no candidates from overloaded 
cpus if all the dl tasks on the overloaded cpus are pinned. This patch fix 
it by traversing pushable task rbtree which is also ordered by tasks' 
deadlines.

Signed-off-by: Wanpeng Li wanpeng...@linux.intel.com
---
 kernel/sched/deadline.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 5e95145..04e3f5b 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1230,6 +1230,33 @@ next_node:
return NULL;
 }
 
+/*
+ * Return the earliest pushable rq's task, which is suitable to be executed
+ * on the cpu, NULL otherwse
+ */
+static struct task_struct *pick_earliest_pushable_dl_task(struct rq *rq,
+   int cpu)
+{
+   struct rb_node *next_node = rq-dl.pushable_dl_tasks_leftmost;
+   struct task_struct *p = NULL;
+
+   if (!has_pushable_dl_tasks(rq))
+   return NULL;
+
+next_node:
+   if (next_node) {
+   p = rb_entry(next_node, struct task_struct, pushable_dl_tasks);
+
+   if (pick_dl_task(rq, p, cpu))
+   return p;
+
+   next_node = rb_next(next_node);
+   goto next_node;
+   }
+
+   return NULL;
+}
+
 static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
 
 static int find_later_rq(struct task_struct *task)
@@ -1514,7 +1541,7 @@ static int pull_dl_task(struct rq *this_rq)
if (src_rq-dl.dl_nr_running = 1)
goto skip;
 
-   p = pick_next_earliest_dl_task(src_rq, this_cpu);
+   p = pick_earliest_pushable_dl_task(src_rq, this_cpu);
 
/*
 * We found a task to be pulled if:
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

[Peter Zijlstra]

On Thu, Apr 02, 2015 at 10:36:47AM +0200, Peter Zijlstra wrote:
 Sure, struct timekeeper would work, the debug code already references
 the global tk_core to access that.

While looking at that, the comment near tk_core says:

/*
 * The most important data for readout fits into a single 64 byte
 * cache line.
 */

I feel that should be qualified somewhat, this is only true for
MONOTONIC (ktime_get()), any other time base ends up on more lines.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] sched/deadline: reduce rq lock contention by eliminating locking of non-feasible target

[Wanpeng Li]

This patch adds check that prevents futile attempts to move dl tasks to
a CPU with active tasks of equal or earlier deadline. The same behavior as
commit 80e3d87b2c55 (sched/rt: Reduce rq lock contention by eliminating
locking of non-feasible target) for rt class.

Signed-off-by: Wanpeng Li wanpeng...@linux.intel.com
---
 kernel/sched/deadline.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 37425fd..e72194f 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1012,7 +1012,9 @@ select_task_rq_dl(struct task_struct *p, int cpu, int 
sd_flag, int flags)
(p-nr_cpus_allowed  1)) {
int target = find_later_rq(p);
 
-   if (target != -1)
+   if (target != -1 
+   dl_time_before(p-dl.deadline,
+   cpu_rq(target)-dl.earliest_dl.curr))
cpu = target;
}
rcu_read_unlock();
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] perf tools: unify perf_event_attr printing

[Adrian Hunter]

On 01/04/15 19:52, Jiri Olsa wrote:
 On Wed, Apr 01, 2015 at 06:26:38PM +0200, Peter Zijlstra wrote:

 With some feedback from Jolsa, who showed me how to trigger the actual
 outputs.
 
 adding Adrian to CC as he's the original author AFAIK

I wanted a compact format, and the omission of null/zero values achieves that.

But personally I think the include approach is too ugly. I would just
add a function instead. Something like:

#define p_unsigned(val) snprintf(value_buf, BUF_SIZE, %PRIu64, 
(uint64_t)(val))

#define PRINT_ATTRN(name, field, print) \
if (!skip_zero || attr-field) {\
snprintf(name_buf, BUF_SIZE, name); \
print(attr-field); \
prt(name_buf, value_buf, priv); \
}

#define PRINT_ATTR(field, print) PRINT_ATTRN(#field, field, print)

typedef int (*attr_print_cb_t)(const char *name, const char *value, void *priv);

int perf_event_attr__print(struct perf_event_attr *attr, attr_print_cb_t prt, 
bool skip_zero, void *priv)
{
char name_buf[BUF_SIZE];
char value_buf[BUF_SIZE];
int err;

PRINT_ATTR(type, p_unsigned);

etc

return 0;
}


Then it calling it looks like:


static int perf_event_attr__fprintf_one(const char *name, const char *value, 
void *priv)
{
size_t *ret = priv;

*ret += fprintf(fp,   %-32s %s\n, name, value);
return 0;
}

static size_t perf_event_attr__fprintf(struct perf_event_attr *attr, FILE *fp)
{
size_t ret = 0;

ret += fprintf(fp, %.60s\n, graph_dotted_line);
ret += fprintf(fp, perf_event_attr:\n);

perf_event_attr__print(attr, perf_event_attr__fprintf_one, true, ret);

ret += fprintf(fp, %.60s\n, graph_dotted_line);

return ret;
}


 
 jirka
 

 ---

 Subject: perf, tools: Merge all perf_event_attr print functions
 From: Peter Zijlstra pet...@infradead.org
 Date: Tue Mar 31 13:01:54 CEST 2015

 Currently there's 3 (that I found) different and incomplete
 implementations of printing perf_event_attr.

 This is quite silly. Merge the lot.

 While this patch does not retain the exact form all printing that I
 found is debug output and thus it should not be critical.

 Also, I cannot find a single print_event_desc() caller.

 Pre:

 $ perf record -vv -e cycles -- sleep 1
 
 perf_event_attr:
   type0
   size104
   config  0
   sample_period   4000
   sample_freq 4000
   sample_type 0x107
   read_format 0
   disabled1inherit 1
   pinned  0exclusive   0
   exclude_user0exclude_kernel  0
   exclude_hv  0exclude_idle0
   mmap1comm1
   mmap2   1comm_exec   1
   freq1inherit_stat0
   enable_on_exec  1task1
   watermark   0precise_ip  0
   mmap_data   0sample_id_all   1
   exclude_host0exclude_guest   1
   excl.callchain_kern 0excl.callchain_user 0
   wakeup_events   0
   wakeup_watermark0
   bp_type 0
   bp_addr 0
   config1 0
   bp_len  0
   config2 0
   branch_sample_type  0
   sample_regs_user0
   sample_stack_user   0
   sample_regs_intr0
 

 $ perf evlist  -vv
 cycles: sample_freq=4000, size: 104, sample_type: IP|TID|TIME|PERIOD,
 disabled: 1, inherit: 1, mmap: 1, mmap2: 1, comm: 1, comm_exec: 1,
 freq: 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest:
 1

 Post:

 $ ./perf record -vv -e cycles -- sleep 1 
 
 perf_event_attr:
   size 112
   { sample_period, sample_freq }   4000
   sample_type  IP|TID|TIME|PERIOD
   disabled 1
   inherit  1
   mmap 1
   comm 1
   freq 1
   enable_on_exec   1
   task 1
   sample_id_all1
   exclude_guest1
   mmap21
   comm_exec1
 

 $ ./perf evlist  -vv
 cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type:
 IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq:
 1, enable_on_exec: 1, task: 1, sample_id_all: 1, exclude_guest: 1,
 mmap2: 1, comm_exec: 1

 Cc: a...@redhat.com
 Cc: jo...@redhat.com
 Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
 ---
  tools/perf/util/Build  |1 
  tools/perf/util/evsel.c   

Re: [PATCH] SQUASHME: Fixes to e820 handling of pmem

[Christoph Hellwig]

On Thu, Apr 02, 2015 at 11:37:40AM +0200, Ingo Molnar wrote:
 So assuming this works on your test setup I'm inclined to squash 
 Boaz's fixes into the original patch, assuming you see no outright bug 
 in them. Anything else can be done as delta improvements.

It looks sensible, but I'd really like to understand the changes a bit
better.  In the meantime I'll test them on my setup.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] drm:msm: Initial Add Writeback Support

[Paul Bolle]

A few nits follow.

On Wed, 2015-04-01 at 17:12 -0400, Jilai Wang wrote:
 --- a/drivers/gpu/drm/msm/Kconfig
 +++ b/drivers/gpu/drm/msm/Kconfig

 +config DRM_MSM_WB
 + bool Enable writeback support for MSM modesetting driver
 + depends on DRM_MSM
 + depends on VIDEO_V4L2
 + select VIDEOBUF2_CORE
 + default y
 + help
 +   Choose this option if you have a need to support writeback
 +   connector.

DRM_MSM_WB is a bool symbol...

 --- a/drivers/gpu/drm/msm/Makefile
 +++ b/drivers/gpu/drm/msm/Makefile
 
 +msm-$(CONFIG_DRM_MSM_WB) += \
 + mdp/mdp5/mdp5_wb_encoder.o \
 + mdp/mdp_wb/mdp_wb.o \
 + mdp/mdp_wb/mdp_wb_connector.o \
 + mdp/mdp_wb/mdp_wb_v4l2.o

so mdp_wb_v4l2.o will never be part of a module.

 --- /dev/null
 +++ b/drivers/gpu/drm/msm/mdp/mdp_wb/mdp_wb_v4l2.c

 +#include linux/module.h

This include is needed mostly for module_param(), right?

 +#define MSM_WB_MODULE_NAME msm_wb

MSM_WB_DRIVER_NAME? But see below.

 +static unsigned debug;
 +module_param(debug, uint, 0644);

debug is basically a boolean type of flag. Would
static bool debug;
module_param(debug, bool, 0644);

work?

 +MODULE_PARM_DESC(debug, activates debug info);

No one is ever going to see this description.

 +#define dprintk(dev, level, fmt, arg...) \
 + v4l2_dbg(level, debug, dev-v4l2_dev, fmt, ## arg)

All instances of dprintk() that I found had level set to 1, so the above
could be simplified a bit:
#define dprintk(dev, fmt, arg...) \
v4l2_dbg(1, debug, dev-v4l2_dev, fmt, ## arg)

But perhaps pr_debug() and the dynamic debug facility could be used
instead of module_param(), dprintk() and v4l2_dbg(). Not sure which
approach is easier.

 +static const struct v4l2_file_operations msm_wb_v4l2_fops = {
 + .owner = THIS_MODULE,

THIS_MODULE will basically be equivalent to NULL.

 + .open = v4l2_fh_open,
 + .release = vb2_fop_release,
 + .poll = vb2_fop_poll,
 + .unlocked_ioctl = video_ioctl2,
 +};

 +int msm_wb_v4l2_init(struct msm_wb *wb)
 +{
 + struct msm_wb_v4l2_dev *dev;
 + struct video_device *vfd;
 + struct vb2_queue *q;
 + int ret;
 +
 + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
 + if (!dev)
 + return -ENOMEM;
 +
 + snprintf(dev-v4l2_dev.name, sizeof(dev-v4l2_dev.name),
 + %s, MSM_WB_MODULE_NAME);

It looks like you can actually drop the #define and merge the last two
arguments to snprintf() into just msm_wb.

 + ret = v4l2_device_register(NULL, dev-v4l2_dev);
 + if (ret)
 + goto free_dev;
 +
 + /* default ARGB 640x480 */
 + dev-fmt = get_format(V4L2_PIX_FMT_RGB32);
 + dev-width = 640;
 + dev-height = 480;
 +
 + /* initialize queue */
 + q = dev-vb_vidq;
 + q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
 + q-io_modes = VB2_DMABUF;
 + q-drv_priv = dev;
 + q-buf_struct_size = sizeof(struct msm_wb_v4l2_buffer);
 + q-ops = msm_wb_vb2_ops;
 + q-mem_ops = msm_wb_vb2_mem_ops;
 + q-timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
 +
 + ret = vb2_queue_init(q);
 + if (ret)
 + goto unreg_dev;
 +
 + mutex_init(dev-mutex);
 +
 + vfd = dev-vdev;
 + *vfd = msm_wb_v4l2_template;
 + vfd-debug = debug;

I couldn't find a member of struct video_device named debug. Where does
that come from? Because, as far as I can see, this won't compile.

 + vfd-v4l2_dev = dev-v4l2_dev;
 + vfd-queue = q;
 +
 + /*
 +  * Provide a mutex to v4l2 core. It will be used to protect
 +  * all fops and v4l2 ioctls.
 +  */
 + vfd-lock = dev-mutex;
 + video_set_drvdata(vfd, dev);
 +
 + ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
 + if (ret  0)
 + goto unreg_dev;
 +
 + dev-wb = wb;
 + wb-wb_v4l2 = dev;
 + v4l2_info(dev-v4l2_dev, V4L2 device registered as %s\n,
 +   video_device_node_name(vfd));
 +
 + return 0;
 +
 +unreg_dev:
 + v4l2_device_unregister(dev-v4l2_dev);
 +free_dev:
 + kfree(dev);
 + return ret;
 +}


Paul Bolle

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 2/2] extcon-axp288: Add axp288 extcon driver support

[Ramakrishna Pallala]

This patch adds the extcon support for AXP288 PMIC which
has the BC1.2 charger detection capability. Additionally
it also adds the USB mux switching support b/w SOC and PMIC
based on GPIO control.

Signed-off-by: Ramakrishna Pallala ramakrishna.pall...@intel.com
---
 drivers/extcon/Kconfig |7 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-axp288.c |  479 
 3 files changed, 487 insertions(+)
 create mode 100644 drivers/extcon/extcon-axp288.c

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..b8627f7 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
  Silicon Mitus SM5502. The SM5502 is a USB port accessory
  detector and switch.
 
+config EXTCON_AXP288
+   tristate AXP288 EXTCON support
+   depends on MFD_AXP20X  USB_PHY
+   help
+ Say Y here to enable support for USB peripheral detection
+ and USB MUX switching by AXP288 PMIC.
+
 endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..832ad79 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
 obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
 obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
new file mode 100644
index 000..2e75d45
--- /dev/null
+++ b/drivers/extcon/extcon-axp288.c
@@ -0,0 +1,479 @@
+/*
+ * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ * Ramakrishna Pallala ramakrishna.pall...@intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/property.h
+#include linux/usb/phy.h
+#include linux/notifier.h
+#include linux/extcon.h
+#include linux/regmap.h
+#include linux/gpio.h
+#include linux/gpio/consumer.h
+#include linux/mfd/axp20x.h
+
+#define AXP288_PS_STAT_REG 0x00
+#define PS_STAT_VBUS_TRIGGER   (1  0)
+#define PS_STAT_BAT_CHRG_DIR   (1  2)
+#define PS_STAT_VBUS_ABOVE_VHOLD   (1  3)
+#define PS_STAT_VBUS_VALID (1  4)
+#define PS_STAT_VBUS_PRESENT   (1  5)
+
+#define AXP288_BC_GLOBAL_REG   0x2c
+#define BC_GLOBAL_RUN  (1  0)
+#define BC_GLOBAL_DET_STAT (1  2)
+#define BC_GLOBAL_DBP_TOUT (1  3)
+#define BC_GLOBAL_VLGC_COM_SEL (1  4)
+#define BC_GLOBAL_DCD_TOUT_MASK0x60
+#define BC_GLOBAL_DCD_TOUT_300MS   0x0
+#define BC_GLOBAL_DCD_TOUT_100MS   0x1
+#define BC_GLOBAL_DCD_TOUT_500MS   0x2
+#define BC_GLOBAL_DCD_TOUT_900MS   0x3
+#define BC_GLOBAL_DCD_DET_SEL  (1  7)
+
+#define AXP288_BC_VBUS_CNTL_REG0x2d
+#define VBUS_CNTL_DPDM_PD_EN   (1  4)
+#define VBUS_CNTL_DPDM_FD_EN   (1  5)
+#define VBUS_CNTL_FIRST_PO_STAT(1  6)
+
+#define AXP288_BC_USB_STAT_REG 0x2e
+#define USB_STAT_BUS_STAT_MASK 0x0f
+#define USB_STAT_BUS_STAT_OFFSET   0
+#define USB_STAT_BUS_STAT_ATHD 0x0
+#define USB_STAT_BUS_STAT_CONN 0x1
+#define USB_STAT_BUS_STAT_SUSP 0x2
+#define USB_STAT_BUS_STAT_CONF 0x3
+#define USB_STAT_USB_SS_MODE   (1  4)
+#define USB_STAT_DEAD_BAT_DET  (1  6)
+#define USB_STAT_DBP_UNCFG (1  7)
+
+#define AXP288_BC_DET_STAT_REG 0x2f
+#define DET_STAT_MASK  0xe0
+#define DET_STAT_OFFSET5
+#define DET_STAT_SDP   0x1
+#define DET_STAT_CDP   0x2
+#define DET_STAT_DCP   0x3
+
+#define AXP288_PS_BOOT_REASON_REG  0x2
+
+#define AXP288_PWRSRC_IRQ_CFG_REG  0x40
+#define PWRSRC_IRQ_CFG_MASK0x1c
+
+#define AXP288_BC12_IRQ_CFG_REG0x45
+#define BC12_IRQ_CFG_MASK  0x2
+
+#define AXP288_PWRSRC_INTR_NUM 4
+
+#define AXP288_DRV_NAMEaxp288_extcon
+
+#define AXP288_EXTCON_CABLE_SDPSlow-charger
+#define AXP288_EXTCON_CABLE_CDPCharge-downstream
+#define AXP288_EXTCON_CABLE_DCP

[PATCH] perf: annotate: make it respect -i option.

[Wang Nan]

There is a bug in perf annotate that it doesn't respect user provided
'-i'/'--input' option:

 # perf record ls
   [ perf record: Woken up 1 times to write data ]
   [ perf record: Captured and wrote 0.001 MB perf.data (8 samples) ]
 # mv ./perf.data ./perf.data.new
 # perf annotate -i ./perf.data.new  --stdio
   failed to open perf.data: No such file or directory  (try 'perf record' 
first)

This patch fix it by setting file path after option parsing, like
what 'perf report' does.

Signed-off-by: Wang Nan wangn...@huawei.com
---
 tools/perf/builtin-annotate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 71bf745..929f83c 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -283,7 +283,6 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
},
};
struct perf_data_file file = {
-   .path  = input_name,
.mode  = PERF_DATA_MODE_READ,
};
const struct option options[] = {
@@ -342,6 +341,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
 
setup_browser(true);
 
+   file.path  = input_name,
annotate.session = perf_session__new(file, false, annotate.tool);
if (annotate.session == NULL)
return -1;
-- 
1.8.3.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 0/2] Add extcon support for AXP288 PMIC

[Ramakrishna Pallala]

This patch series adds the support for axp288 extcon driver
and also adds the cell info for extcon device in axp20x mfd driver.

Ramakrishna Pallala (2):
  mfd/axp20x: add support for extcon cell
  extcon-axp288: Add axp288 extcon driver support

 drivers/extcon/Kconfig |7 +
 drivers/extcon/Makefile|1 +
 drivers/extcon/extcon-axp288.c |  479 
 drivers/mfd/axp20x.c   |   28 +++
 include/linux/mfd/axp20x.h |5 +
 5 files changed, 520 insertions(+)
 create mode 100644 drivers/extcon/extcon-axp288.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next V3 13/23] ptp: igb: convert to the 64 bit get/set time methods.

[Richard Cochran]

On Thu, Apr 02, 2015 at 12:06:56AM +, Keller, Jacob E wrote:
 I don't know how kernel would fix this. Usually macros like PRI64d are used 
 but I am not sure those are defined for the kernel builds

Davem fixed it by casting to (long long).

Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cpusets: Make cpus_allowed and mems_allowed masks hotplug invariant

[Preeti U Murthy]

Hi Tejun, Peter,

On 10/09/2014 06:36 PM, Tejun Heo wrote:
 On Thu, Oct 09, 2014 at 01:50:52PM +0530, Preeti U Murthy wrote:
 However what remains to be answered is that the V2 of cgroup design -
 the default hierarchy, tracks hotplug operations for children cgroups as
 well. Tejun, Li, will not the concerns that Peter raised above hold for
 the default hierarchy as well?
 
 I don't think the legacy one is a good design.  Kernel shouldn't lose
 configurations in an irreversible way and the legacy one is also
 making random cpuset flips by migrating tasks upwards anyway.  In
 terms of hotunplug behavior, the legacy and unified ones behave the
 same.  The only difference is that the configuration is independent of
 the current state and the configured behavior is restored when the
 cpus come back.  The other side is that the legacy hierarchy behavior
 simply can't be allowed when the hierarchy is shared among multiple
 controllers as in the unified hierarchy.  It affects all other
 controllers attached to the hierarchy.

We have a use case currently, which needs this to be fixed one way or
the other. While running in a virtualized setup, there may be a need to
hotplug in resources to VMs at runtime. This includes CPUs and Memory.
Due to the behavior of the legacy hierarchy, the new CPUs never get
used. This is not even a scenario where we hot-unplugged CPUs and ask
for it to be plugged back again. Its a case where the workloads running
within a VM are in need of more resources than they began with.

 
 That said, we can't change the behavior on the legacy one.  It's a
 very userland visible behavior.  We simply can't change it, so

By ensuring that the user configured cpusets are untouched, I don't see
how we affect userspace adversely. The expectation usually is that the
kernel keeps track of the user configurations. If anything we would be
fixing an undesired behavior, wouldn't we?

 unfortunately you're stuck with it at least on the legacy hierarchy.

Given that we are in much need for this to be fixed and that we cannot
easily move to the default hierarchy, can you please take a look at this
patch again?

It is understandable that there are good reasons why legacy hierarchy
currently behaves this way or how we cannot drastically change its
behavior, but there is no sane way in which userspace can get around
this for the sake of genuine use cases such as the above.

Regards
Preeti U Murthy
 
 Thanks.
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes

[Lee Jones]

DT Ack please.

On Wed, 01 Apr 2015, Bjorn Andersson wrote:

 Add the regulator subnodes to the Qualcomm RPM MFD device tree bindings.
 
 Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
 ---
  Documentation/devicetree/bindings/mfd/qcom-rpm.txt | 217 
 +++--
  1 file changed, 205 insertions(+), 12 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt 
 b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
 index 85e3198..8eb1ca9 100644
 --- a/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
 +++ b/Documentation/devicetree/bindings/mfd/qcom-rpm.txt
 @@ -31,16 +31,6 @@ frequencies.
   Value type: string-array
   Definition: must be the three strings ack, err and wakeup, in 
 order
  
 -- #address-cells:
 - Usage: required
 - Value type: u32
 - Definition: must be 1
 -
 -- #size-cells:
 - Usage: required
 - Value type: u32
 - Definition: must be 0
 -
  - qcom,ipc:
   Usage: required
   Value type: prop-encoded-array
 @@ -52,6 +42,188 @@ frequencies.
   - u32 representing the ipc bit within the register
  
  
 += SUBNODES
 +
 +The RPM exposes resources to its subnodes. The below bindings specify the set
 +of valid subnodes that can operate on these resources.
 +
 +== Regulators
 +
 +Regulator notes are identified by their compatible:
 +
 +- compatible:
 + Usage: required
 + Value type: string
 + Definition: must be one of:
 + qcom,rpm-pm8058-regulators
 + qcom,rpm-pm8901-regulators
 + qcom,rpm-pm8921-regulators
 +
 +- vdd_l0_l1_lvs-supply:
 +- vdd_l2_l11_l12-supply:
 +- vdd_l3_l4_l5-supply:
 +- vdd_l6_l7-supply:
 +- vdd_l8-supply:
 +- vdd_l9-supply:
 +- vdd_l10-supply:
 +- vdd_l13_l16-supply:
 +- vdd_l14_l15-supply:
 +- vdd_l17_l18-supply:
 +- vdd_l19_l20-supply:
 +- vdd_l21-supply:
 +- vdd_l22-supply:
 +- vdd_l23_l24_l25-supply:
 +- vdd_ncp-supply:
 +- vdd_s0-supply:
 +- vdd_s1-supply:
 +- vdd_s2-supply:
 +- vdd_s3-supply:
 +- vdd_s4-supply:
 + Usage: optional (pm8058 only)
 + Value type: phandle
 + Definition: reference to regulator supplying the input pin, as
 + described in the data sheet
 +
 +- lvs0_in-supply:
 +- lvs1_in-supply:
 +- lvs2_in-supply:
 +- lvs3_in-supply:
 +- mvs_in-supply:
 +- vdd_l0-supply:
 +- vdd_l1-supply:
 +- vdd_l2-supply:
 +- vdd_l3-supply:
 +- vdd_l4-supply:
 +- vdd_l5-supply:
 +- vdd_l6-supply:
 +- vdd_s0-supply:
 +- vdd_s1-supply:
 +- vdd_s2-supply:
 +- vdd_s3-supply:
 +- vdd_s4-supply:
 + Usage: optional (pm8901 only)
 + Value type: phandle
 + Definition: reference to regulator supplying the input pin, as
 + described in the data sheet
 +
 +- vdd_l1_l2_l12_l18-supply:
 +- vdd_l3_l15_l17-supply:
 +- vdd_l4_l14-supply:
 +- vdd_l5_l8_l16-supply:
 +- vdd_l6_l7-supply:
 +- vdd_l9_l11-supply:
 +- vdd_l10_l22-supply:
 +- vdd_l21_l23_l29-supply:
 +- vdd_l24-supply:
 +- vdd_l25-supply:
 +- vdd_l26-supply:
 +- vdd_l27-supply:
 +- vdd_l28-supply:
 +- vdd_ncp-supply:
 +- vdd_s1-supply:
 +- vdd_s2-supply:
 +- vdd_s4-supply:
 +- vdd_s5-supply:
 +- vdd_s6-supply:
 +- vdd_s7-supply:
 +- vdd_s8-supply:
 +- vin_5vs-supply:
 +- vin_lvs1_3_6-supply:
 +- vin_lvs2-supply:
 +- vin_lvs4_5_7-supply:
 + Usage: optional (pm8921 only)
 + Value type: phandle
 + Definition: reference to regulator supplying the input pin, as
 + described in the data sheet
 +
 +The regulator node houses sub-nodes for each regulator within the device. 
 Each
 +sub-node is identified using the node's name, with valid values listed for 
 each
 +of the pmics below.
 +
 +pm8058:
 + l0, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15,
 + l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, s0, s1, s2, s3, s4,
 + lvs0, lvs1, ncp
 +
 +pm8901:
 + l0, l1, l2, l3, l4, l5, l6, s0, s1, s2, s3, s4, lvs0, lvs1, lvs2, lvs3,
 + mvs
 +
 +pm8921:
 + s1, s2, s3, s4, s7, s8, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
 + l12, l14, l15, l16, l17, l18, l21, l22, l23, l24, l25, l26, l27, l28,
 + l29, lvs1, lvs2, lvs3, lvs4, lvs5, lvs6, lvs7, usb-switch, hdmi-switch,
 + ncp
 +
 +The content of each sub-node is defined by the standard binding for 
 regulators -
 +see regulator.txt - with additional custom properties described below:
 +
 +=== Switch-mode Power Supply regulator custom properties
 +
 +- bias-pull-down:
 + Usage: optional
 + Value type: empty
 + Definition: enable pull down of the regulator when inactive
 +
 +- qcom,switch-mode-frequency:
 + Usage: required
 + Value type: u32
 + Definition: Frequency (Hz) of the switch-mode power supply;
 + must be one of:
 + 1920, 960, 640, 480, 384, 320,
 + 274, 240, 213, 192, 175, 160,
 + 148, 137, 128, 120
 +
 +- qcom,force-mode:
 + Usage: 

Re: [PATCH] mm/migrate: Mark unmap_and_move() noinline to avoid ICE in gcc 4.7.3

[Geert Uytterhoeven]

Hi Russell,

On Wed, Apr 1, 2015 at 11:59 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Wed, Apr 01, 2015 at 02:54:59PM -0700, Kevin Hilman wrote:
 Your patch on top of Geert's still compiles fine for me with gcc-4.7.3.
 However, I'm not sure how specific we can be on the versions.

 /me goes to test a few more compilers...   OK...

 ICE: 4.7.1, 4.7.3, 4.8.3
 OK: 4.6.3, 4.9.2, 4.9.3

 The diff below[2] on top of yours compiles fine here and at least covers
 the compilers I *know* to trigger the ICE.

 Interesting.  I'm using stock gcc 4.7.4 here, though I'm not building
 -next (only mainline + my tree + arm-soc) and it hasn't shown a problem
 yet.

Mainline doesn't fail.

 I think we need to ask the question: is the bug in stock GCC or Linaro
 GCC?  If it's not in stock GCC, then it's a GCC vendor problem :)

Can you please try -next (e.g. next-20150320)?

make bockw_defconfig
make mm/migrate.o

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v10 00/11] sched: consolidation of CPU capacity and usage

[Vincent Guittot]

On 2 April 2015 at 03:47, Wanpeng Li wanpeng...@linux.intel.com wrote:
 Hi Vincent,
 On Fri, Feb 27, 2015 at 04:54:03PM +0100, Vincent Guittot wrote:
This patchset consolidates several changes in the capacity and the usage
tracking of the CPU. It provides a frequency invariant metric of the usage of
CPUs and generally improves the accuracy of load/usage tracking in the
scheduler. The frequency invariant metric is the foundation required for the
consolidation of cpufreq and implementation of a fully invariant load 
tracking.
These are currently WIP and require several changes to the load balancer
(including how it will use and interprets load and capacity metrics) and
extensive validation. The frequency invariance is done with
arch_scale_freq_capacity and this patchset doesn't provide the backends of
the function which are architecture dependent.

As discussed at LPC14, Morten and I have consolidated our changes into a 
single
patchset to make it easier to review and merge.

During load balance, the scheduler evaluates the number of tasks that a group
of CPUs can handle. The current method assumes that tasks have a fix load of
SCHED_LOAD_SCALE and CPUs have a default capacity of SCHED_CAPACITY_SCALE.
This assumption generates wrong decision by creating ghost cores or by
removing real ones when the original capacity of CPUs is different from the
default SCHED_CAPACITY_SCALE. With this patch set, we don't try anymore to
evaluate the number of available cores based on the group_capacity but instead
we evaluate the usage of a group and compare it with its capacity.

This patchset mainly replaces the old capacity_factor method by a new one and
keeps the general policy almost unchanged. These new metrics will be also used
in later patches.

The CPU usage is based on a running time tracking version of the current
implementation of the load average tracking. I also have a version that is
based on the new implementation proposal [1] but I haven't provide the patches
and results as [1] is still under review. I can provide change above [1] to
change how CPU usage is computed and to adapt to new mecanism.

 Is there performance data for this cpu capacity and usage improvement?

I don't have data for this version but i have published figures for
previous one.
https://lkml.org/lkml/2014/8/26/288

This patchset consolidates the tracking of CPU usage and capacity for
all kind of arch and use case by improving the detection of overloaded
CPU.
Regarding the perf bench on SMP system which goals is to use all
available CPU and computing capacity , we should not see perf
improvement but we will not see perf regression too.
The difference is noticeable in mid load use case or when rt task or
irq are involved

Regards,
Vincent

 Regards,
 Wanpeng Li


Change since V9
 - add a dedicated patch for removing unused capacity_orig
 - update some comments and fix typo
 - change the condition for actively migrating task on CPU with higher 
 capacity

Change since V8
 - reorder patches

Change since V7
 - add freq invariance for usage tracking
 - add freq invariance for scale_rt
 - update comments and commits' message
 - fix init of utilization_avg_contrib
 - fix prefer_sibling

Change since V6
 - add group usage tracking
 - fix some commits' messages
 - minor fix like comments and argument order

Change since V5
 - remove patches that have been merged since v5 : patches 01, 02, 03, 04, 
 05, 07
 - update commit log and add more details on the purpose of the patches
 - fix/remove useless code with the rebase on patchset [2]
 - remove capacity_orig in sched_group_capacity as it is not used
 - move code in the right patch
 - add some helper function to factorize code

Change since V4
 - rebase to manage conflicts with changes in selection of busiest group

Change since V3:
 - add usage_avg_contrib statistic which sums the running time of tasks on a 
 rq
 - use usage_avg_contrib instead of runnable_avg_sum for cpu_utilization
 - fix replacement power by capacity
 - update some comments

Change since V2:
 - rebase on top of capacity renaming
 - fix wake_affine statistic update
 - rework nohz_kick_needed
 - optimize the active migration of a task from CPU with reduced capacity
 - rename group_activity by group_utilization and remove unused 
 total_utilization
 - repair SD_PREFER_SIBLING and use it for SMT level
 - reorder patchset to gather patches with same topics

Change since V1:
 - add 3 fixes
 - correct some commit messages
 - replace capacity computation by activity
 - take into account current cpu capacity

[1] https://lkml.org/lkml/2014/10/10/131
[2] https://lkml.org/lkml/2014/7/25/589

Morten Rasmussen (2):
  sched: Track group sched_entity usage contributions
  sched: Make sched entity usage tracking scale-invariant

Vincent Guittot (9):
  sched: add utilization_avg_contrib
  sched: remove frequency scaling from cpu_capacity
  sched: make scale_rt invariant with frequency
  sched: add per rq cpu_capacity_orig
  sched: get CPU's 

Re: [PATCH perf/core ] perf-probe: Fix to track down unnamed union/structure members

[Masami Hiramatsu]

(2015/03/09 11:15), Masami Hiramatsu wrote:
 Fix perf probe to track down unnamed union/structure members.
 perf probe did not track down the tree of unnamed union/structure
 members, since it just failed to find given name in a parent
 structure/union. To solve this issue, I've introduced 2 changes.
 
 - Fix die_find_member() to track down the type-DIE if it is
   unnamed, and if it contains the specified member, returns the
   unnamed member.
   (note that we don't return found member, since unnamed member
has the offset in the parent structure)
 - Fix convert_variable_fields() to track down the unnamed union/
   structure (one-by-one).
 
 With this patch, perf probe can access unnamed fields.
   -
   #./perf probe -nfx ./perf lock__delete ops 'locked_ops=ops-locked.ops'
   Added new event:
 probe_perf:lock__delete (on lock__delete in 
 /home/mhiramat/ksrc/linux-3/tools/perf/perf with ops 
 locked_ops=ops-locked.ops)
 
   You can now use it in all perf tools, such as:
 
   perf record -e probe_perf:lock__delete -aR sleep 1
   -
 
 The original report of this issue is: https://lkml.org/lkml/2015/3/5/431
 
 Reported-by: Arnaldo Carvalho de Melo a...@kernel.org
 Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
 ---
  tools/perf/util/dwarf-aux.c|   14 ++
  tools/perf/util/probe-finder.c |8 +++-
  2 files changed, 17 insertions(+), 5 deletions(-)
 
 diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c
 index 780b2bc..c34e024 100644
 --- a/tools/perf/util/dwarf-aux.c
 +++ b/tools/perf/util/dwarf-aux.c
 @@ -801,10 +801,16 @@ static int __die_find_member_cb(Dwarf_Die *die_mem, 
 void *data)
  {
   const char *name = data;
  
 - if ((dwarf_tag(die_mem) == DW_TAG_member) 
 - die_compare_name(die_mem, name))
 - return DIE_FIND_CB_END;
 -
 + if (dwarf_tag(die_mem) == DW_TAG_member) {
 + if (die_compare_name(die_mem, name))
 + return DIE_FIND_CB_END;
 + else if (!dwarf_diename(die_mem)) { /* Unnamed structure */
 + Dwarf_Die type_die, tmp_die;
 + if (die_get_type(die_mem, type_die) 
 + die_find_member(type_die, name, tmp_die))
 + return DIE_FIND_CB_END;
 + }
 + }
   return DIE_FIND_CB_SIBLING;
  }
  
 diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
 index 46f009a..3898eba 100644
 --- a/tools/perf/util/probe-finder.c
 +++ b/tools/perf/util/probe-finder.c
 @@ -460,7 +460,8 @@ static int convert_variable_fields(Dwarf_Die *vr_die, 
 const char *varname,
   nor array.\n, varname);
   return -EINVAL;
   }
 - if (field-ref) {
 + /* While prcessing unnamed field, we don't care about this */
 + if (field-ref  !dwarf_diename(vr_die)) {
  ^^ Oops! this should be inverted!
I've missed to include a local fix to this patch...

Thank you,

   pr_err(Semantic error: %s must be referred by '.'\n,
  field-name);
   return -EINVAL;
 @@ -491,6 +492,11 @@ static int convert_variable_fields(Dwarf_Die *vr_die, 
 const char *varname,
   }
   ref-offset += (long)offs;
  
 + /* If this member is unnamed, we need to reuse this field */
 + if (!dwarf_diename(die_mem))
 + return convert_variable_fields(die_mem, varname, field,
 + ref, die_mem);
 +
  next:
   /* Converting next field */
   if (field-next)
 
 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups

[Michael S. Tsirkin]

On Thu, Apr 02, 2015 at 09:44:24AM +0200, Jean Delvare wrote:
 It could be that a small subset of pci_ids.h could be shared with
 user-space. I'm thinking of classes, because that list is short and
 stable, so we can give some stability guarantees. But I don't know if
 the user-space projects you quoted actually use that, so even that may
 not be worth it.
 
 -- 
 Jean Delvare
 SUSE L3 Support

Yes, class IDs is the part that's duplicated across multiple
userspace projects.

So exporting it is exactly what v2 of the patch did:
mid.gmane.org/1427714755-16873-1-git-send-email-...@redhat.com

Please review that.

-- 
MST
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [STLinux Kernel] [PATCH 2/4] ARM: sti: stih410-clocks: Identify critical clocks as always-on

[Peter Griffin]

Hi Lee,

On Fri, 27 Feb 2015, Lee Jones wrote:

 Lots of platforms contain clocks which if turned off would prove fatal.
 The only way to recover is to restart the board(s).  This driver takes
 references to clocks which are required to be always-on in order to
 prevent the common clk framework from trying to turn them off during
 the clk_disabled_unused() procedure.
 In this patch we are identifying clocks, which if gated would render
 the STiH410 development board unserviceable.

Can you also add clk_s_c0_flexgen CLK_PROC_STFE to the list of always
on clocks for stih407 and stih410?

This clock is slightly unusual in that the clock doesn't need to be on
at boot, but once enabled by the kernel, can't be disabled without causing
the system to hang.

So slightly different from the others, but I would prefer to keep balanced
enable/disable calls in the tsin driver, in case this (bug?) goes away
on future SoC's.

regards,

Peter.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/9] nbd: Restructure debugging prints

[Markus Pargmann]

dprintk has some name collisions with other frameworks and drivers. It
is also not necessary to have these custom debug print filters. Dynamic
debug offers the same amount of filtered debugging.

This patch replaces all dprintks with dev_dbg(). It also removes the
ioctl dprintk which prints the ingoing ioctls which should be
replaceable by strace or similar stuff.

Signed-off-by: Markus Pargmann m...@pengutronix.de
Acked-by: Pavel Machek pa...@ucw.cz
---

Notes:
Changes in v2:
 - The device name was written twice in each print. This is fixed by 
removing
   the explicit print of the disk name.
 - dev_dbg() in do_nbd_request() was moved to have a valid nbd pointer

 drivers/block/nbd.c | 88 ++---
 1 file changed, 22 insertions(+), 66 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 13c8371cbf4c..217b570dd7a5 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -63,21 +63,6 @@ struct nbd_device {
 
 #define NBD_MAGIC 0x68797548
 
-#ifdef NDEBUG
-#define dprintk(flags, fmt...)
-#else /* NDEBUG */
-#define dprintk(flags, fmt...) do { \
-   if (debugflags  (flags)) printk(KERN_DEBUG fmt); \
-} while (0)
-#define DBG_IOCTL   0x0004
-#define DBG_INIT0x0010
-#define DBG_EXIT0x0020
-#define DBG_BLKDEV  0x0100
-#define DBG_RX  0x0200
-#define DBG_TX  0x0400
-static unsigned int debugflags;
-#endif /* NDEBUG */
-
 static unsigned int nbds_max = 16;
 static struct nbd_device *nbd_dev;
 static int max_part;
@@ -94,25 +79,9 @@ static int max_part;
  */
 static DEFINE_SPINLOCK(nbd_lock);
 
-#ifndef NDEBUG
-static const char *ioctl_cmd_to_ascii(int cmd)
+static inline struct device *nbd_to_dev(struct nbd_device *nbd)
 {
-   switch (cmd) {
-   case NBD_SET_SOCK: return set-sock;
-   case NBD_SET_BLKSIZE: return set-blksize;
-   case NBD_SET_SIZE: return set-size;
-   case NBD_SET_TIMEOUT: return set-timeout;
-   case NBD_SET_FLAGS: return set-flags;
-   case NBD_DO_IT: return do-it;
-   case NBD_CLEAR_SOCK: return clear-sock;
-   case NBD_CLEAR_QUE: return clear-que;
-   case NBD_PRINT_DEBUG: return print-debug;
-   case NBD_SET_SIZE_BLOCKS: return set-size-blocks;
-   case NBD_DISCONNECT: return disconnect;
-   case BLKROSET: return set-read-only;
-   case BLKFLSBUF: return flush-buffer-cache;
-   }
-   return unknown;
+   return disk_to_dev(nbd-disk);
 }
 
 static const char *nbdcmd_to_ascii(int cmd)
@@ -126,16 +95,15 @@ static const char *nbdcmd_to_ascii(int cmd)
}
return invalid;
 }
-#endif /* NDEBUG */
 
-static void nbd_end_request(struct request *req)
+static void nbd_end_request(struct nbd_device *nbd, struct request *req)
 {
int error = req-errors ? -EIO : 0;
struct request_queue *q = req-q;
unsigned long flags;
 
-   dprintk(DBG_BLKDEV, %s: request %p: %s\n, req-rq_disk-disk_name,
-   req, error ? failed : done);
+   dev_dbg(nbd_to_dev(nbd), request %p: %s\n, req,
+   error ? failed : done);
 
spin_lock_irqsave(q-queue_lock, flags);
__blk_end_request_all(req, error);
@@ -276,11 +244,9 @@ static int nbd_send_req(struct nbd_device *nbd, struct 
request *req)
}
memcpy(request.handle, req, sizeof(req));
 
-   dprintk(DBG_TX, %s: request %p: sending control (%s@%llu,%uB)\n,
-   nbd-disk-disk_name, req,
-   nbdcmd_to_ascii(nbd_cmd(req)),
-   (unsigned long long)blk_rq_pos(req)  9,
-   blk_rq_bytes(req));
+   dev_dbg(nbd_to_dev(nbd), request %p: sending control (%s@%llu,%uB)\n,
+   req, nbdcmd_to_ascii(nbd_cmd(req)),
+   (unsigned long long)blk_rq_pos(req)  9, blk_rq_bytes(req));
result = sock_xmit(nbd, 1, request, sizeof(request),
(nbd_cmd(req) == NBD_CMD_WRITE) ? MSG_MORE : 0);
if (result = 0) {
@@ -300,8 +266,8 @@ static int nbd_send_req(struct nbd_device *nbd, struct 
request *req)
flags = 0;
if (!rq_iter_last(bvec, iter))
flags = MSG_MORE;
-   dprintk(DBG_TX, %s: request %p: sending %d bytes 
data\n,
-   nbd-disk-disk_name, req, bvec.bv_len);
+   dev_dbg(nbd_to_dev(nbd), request %p: sending %d bytes 
data\n,
+   req, bvec.bv_len);
result = sock_send_bvec(nbd, bvec, flags);
if (result = 0) {
dev_err(disk_to_dev(nbd-disk),
@@ -394,8 +360,7 @@ static struct request *nbd_read_stat(struct nbd_device *nbd)
return req;
}
 
-   dprintk(DBG_RX, %s: request %p: got reply\n,
-   nbd-disk-disk_name, req);
+   dev_dbg(nbd_to_dev(nbd), request %p: got 

Re: [STLinux Kernel] [PATCH 0/4] clk: Provide support for always-on clocks

[Peter Griffin]

Hi Lee,

On Fri, 27 Feb 2015, Lee Jones wrote:

 Some hardware contains bunches of clocks which must never be
 turned off.  If drivers a) fail to obtain a reference to any
 of these or b) give up a previously obtained reference
 during suspend, the common clk framework will attempt to
 disable them and a platform can fail irrecoverably as a
 result.  Usually the only way to recover from these failures
 is to reboot.
 
 To avoid either of these two scenarios from catastrophically
 disabling an otherwise perfectly healthy running system,
 clocks can be identified as always-on using this property
 from inside a clocksource's node.  The CLK_IGNORE_UNUSED
 flag will be applied to each clock instance named in this
 property, thus preventing them from being shut down by the
 framework.

Great stuff.

One minor comment is that assuming this works on stih407 and stih410
to the extent that the platform can now boot without clk_ignore_unused
kenel parameter then you should have an additional patch to remove
clk_ignore_unused from the default bootargs in stih407-b2120.dts and
stih410-b2120.dts files.

Maxime - Is it possible for you to test this series on stih418-b2199 as
a well? As it could most likely also be removed from stih418-b2199.dts file
to, but neither Lee or myself have the hardware to test.

Apart from that, for the series: -
 Acked-by: Peter Griffin peter.grif...@linaro.org

regards,

Peter.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/9] Documentation: nbd: Reformat to allow more documentation

[Markus Pargmann]

Reformat the existing documentation to have more structure. This allows
for more documentation seperated from the existing paragraphs.

Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 Documentation/blockdev/nbd.txt | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/Documentation/blockdev/nbd.txt b/Documentation/blockdev/nbd.txt
index 271e607304da..337946bd460e 100644
--- a/Documentation/blockdev/nbd.txt
+++ b/Documentation/blockdev/nbd.txt
@@ -1,17 +1,21 @@
-  Network Block Device (TCP version)
-   
-   What is it: With this compiled in the kernel (or as a module), Linux
-   can use a remote server as one of its block devices. So every time
-   the client computer wants to read, e.g., /dev/nb0, it sends a
-   request over TCP to the server, which will reply with the data read.
-   This can be used for stations with low disk space (or even diskless)
-   to borrow disk space from another computer.
-   Unlike NFS, it is possible to put any filesystem on it, etc.
+Network Block Device (TCP version)
+==
 
-   For more information, or to download the nbd-client and nbd-server
-   tools, go to http://nbd.sf.net/.
+1) Overview
+---
 
-   The nbd kernel module need only be installed on the client
-   system, as the nbd-server is completely in userspace. In fact,
-   the nbd-server has been successfully ported to other operating
-   systems, including Windows.
+What is it: With this compiled in the kernel (or as a module), Linux
+can use a remote server as one of its block devices. So every time
+the client computer wants to read, e.g., /dev/nb0, it sends a
+request over TCP to the server, which will reply with the data read.
+This can be used for stations with low disk space (or even diskless)
+to borrow disk space from another computer.
+Unlike NFS, it is possible to put any filesystem on it, etc.
+
+For more information, or to download the nbd-client and nbd-server
+tools, go to http://nbd.sf.net/.
+
+The nbd kernel module need only be installed on the client
+system, as the nbd-server is completely in userspace. In fact,
+the nbd-server has been successfully ported to other operating
+systems, including Windows.
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/9] nbd: Remove fixme that was already fixed

[Markus Pargmann]

The mentioned problem is not present anymore.

Signed-off-by: Markus Pargmann m...@pengutronix.de
---
 drivers/block/nbd.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 217b570dd7a5..6e7a7b06efcb 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -110,14 +110,11 @@ static void nbd_end_request(struct nbd_device *nbd, 
struct request *req)
spin_unlock_irqrestore(q-queue_lock, flags);
 }
 
+/*
+ * Forcibly shutdown the socket causing all listeners to error
+ */
 static void sock_shutdown(struct nbd_device *nbd, int lock)
 {
-   /* Forcibly shutdown the socket causing all listeners
-* to error
-*
-* FIXME: This code is duplicated from sys_shutdown, but
-* there should be a more generic interface rather than
-* calling socket ops directly here */
if (lock)
mutex_lock(nbd-tx_lock);
if (nbd-sock) {
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 9/9] nbd: Return error pointer directly

[Markus Pargmann]

Signed-off-by: Markus Pargmann m...@pengutronix.de
Acked-by: Pavel Machek pa...@ucw.cz
---

Notes:
Changes in v2:
 - Remove unnecessary brackets

 drivers/block/nbd.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index e41fb4ccf39a..bd8f4caf53bd 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -285,7 +285,7 @@ static struct request *nbd_find_request(struct nbd_device 
*nbd,
 
err = wait_event_interruptible(nbd-active_wq, nbd-active_req != xreq);
if (unlikely(err))
-   goto out;
+   return ERR_PTR(err);
 
spin_lock(nbd-queue_lock);
list_for_each_entry_safe(req, tmp, nbd-queue_head, queuelist) {
@@ -297,10 +297,7 @@ static struct request *nbd_find_request(struct nbd_device 
*nbd,
}
spin_unlock(nbd-queue_lock);
 
-   err = -ENOENT;
-
-out:
-   return ERR_PTR(err);
+   return ERR_PTR(-ENOENT);
 }
 
 static inline int sock_recv_bvec(struct nbd_device *nbd, struct bio_vec *bvec)
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/9] nbd: Return error code directly

[Markus Pargmann]

By returning the error code directly, we can avoid the jump label
error_out.

Signed-off-by: Markus Pargmann m...@pengutronix.de
Acked-by: Pavel Machek pa...@ucw.cz
---
 drivers/block/nbd.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 6e7a7b06efcb..e41fb4ccf39a 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -249,7 +249,7 @@ static int nbd_send_req(struct nbd_device *nbd, struct 
request *req)
if (result = 0) {
dev_err(disk_to_dev(nbd-disk),
Send control failed (result %d)\n, result);
-   goto error_out;
+   return -EIO;
}
 
if (nbd_cmd(req) == NBD_CMD_WRITE) {
@@ -270,14 +270,11 @@ static int nbd_send_req(struct nbd_device *nbd, struct 
request *req)
dev_err(disk_to_dev(nbd-disk),
Send data failed (result %d)\n,
result);
-   goto error_out;
+   return -EIO;
}
}
}
return 0;
-
-error_out:
-   return -EIO;
 }
 
 static struct request *nbd_find_request(struct nbd_device *nbd,
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 0/2] perf scripting cleanups

[Namhyung Kim]

On Wed, Apr 01, 2015 at 01:36:48PM -0300, Arnaldo Carvalho de Melo wrote:
 Hi David, Jiri,
 
   Please take a look if it is ok for you guys
 
 Adrian, there is another thing:
 
   db_export__sample(tables-dbe, event, sample, evsel, al-thread, al);
 
 In tools/perf/util/scripting-engines/trace-event-python.c has this redundancy
 as well, see the (al-thread, al), I'll probably remove that extra thread parm
 there if you don't have any other subtle use for that...

For both patches,

Acked-by: Namhyung Kim namhy...@kernel.org

Thanks,
Namhyung
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups

[Christoph Hellwig]

The class ids are a hardware defintion, not a kernel API.  Just use the
definitions from libpci, or copy over the kernel header if you prefer
it over the libpci definutions.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

[Peter Zijlstra]

On Thu, Apr 02, 2015 at 09:51:51AM +0200, Ingo Molnar wrote:
 
 * Peter Zijlstra pet...@infradead.org wrote:
 
  On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote:
   Ingo suggested that the timekeeping debugging variables
   recently added should not be global, and should be tied
   to the timekeeper's read_base.
  
  But why? its the same hardware clock for both tkr's. Surely if one goes
  funny the other will too.
  
  It doesn't make sense to duplicate this.
 
 Well, could it be moved to the timekeeper data structure? What I was 
 opposed to was making it super-global, after all the (nice) effort we 
 made to tidy up global data structures in this area.

Sure, struct timekeeper would work, the debug code already references
the global tk_core to access that.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] arm64: dts: exynos: add reboot node for exynos5433

[Chanwoo Choi]

From: Joonyoung Shim jy0922.s...@samsung.com

This patch adds the reboot node which uses the syscon-reboot driver.

Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.co
Acked-by: Inki Dae inki@samsung.com
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index f179c60..f2d6b18 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -94,6 +94,13 @@
cpu_on = 0xC403;
};
 
+   reboot: syscon-reboot {
+   compatible = syscon-reboot;
+   regmap = pmu_system_controller;
+   offset = 0x400;
+   mask = 0x1;
+   };
+
soc: soc {
compatible = simple-bus;
#address-cells = 1;
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] arm64: dts: exynos: Add PWM dt node and pinctrl for Exynos5433 SoC

[Chanwoo Choi]

From: Jaewon Kim jaewon02@samsung.com

This patch adds PWM(Pulsle Width Modulation) device tree node
to support for PWM Timer on Exynos5433 SoC.

Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 28 ++
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++
 2 files changed, 40 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
index c56bbf8..49be038 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -581,6 +581,34 @@
samsung,pin-drv = 0;
};
 
+   pwm0_out: pwm0-out {
+   samsung,pins = gpd2-4;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   pwm1_out: pwm1-out {
+   samsung,pins = gpd2-5;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   pwm2_out: pwm2-out {
+   samsung,pins = gpd2-6;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   pwm3_out: pwm3-out {
+   samsung,pins = gpd2-7;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
spi1_bus: spi1-bus {
samsung,pins = gpd6-2, gpd6-4, gpd6-5;
samsung,pin-function = 2;
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 9cca236..baeec299 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1052,6 +1052,18 @@
phy-names = usb2-phy, usb3-phy;
};
};
+
+   pwm: pwm@14dd {
+   compatible = samsung,exynos4210-pwm;
+   reg = 0x14dd 0x100;
+   interrupts = 0 416 0, 0 417 0,
+0 418 0, 0 419 0, 0 420 0;
+   samsung,pwm-outputs = 0, 1, 2, 3;
+   clocks = cmu_peric CLK_PCLK_PWM;
+   clock-names = timers;
+   #pwm-cells = 3;
+   status = disabled;
+   };
};
 
timer {
-- 
1.8.5.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

memory: jz4780-nemc: Dependency on undefined Kconfig option

[Valentin Rothberg]

Hi Alex,

your commit (memory: jz4780-nemc: driver for the NEMC on JZ4780
SoCs) sets MACH_JZ4780 as Kconfig dependency for the JZ4780_NEMC
driver.

+config JZ4780_NEMC
[...]
+   depends on MACH_JZ4780

MACH_JZ4780 is not defined in Kconfig, so that JZ4780_NEMC is always
false and the driver cannot be compiled.

Is there a patch queued somewhere that adds the missing Kconfig option?

I detected this issue with scripts/checkkconfigsymbols.py by diffing
yesterday's and today's linux-next tree.

Kind regards,
 Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[git pull] Please pull mpe/linux.git powerpc-4.0-4 tag

[Michael Ellerman]

Hi Linus,

Please pull one powerpc fix for 4.0:

The following changes since commit e42391cd048809d903291d07f86ed3934ce138e9:

  Linux 4.0-rc6 (2015-03-29 15:26:31 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-4.0-4

for you to fetch changes up to d52356e7f48e400ca258c6763a232a92fa82ff68:

  powerpc: fix memory corruption by pnv_alloc_idle_core_states (2015-04-01 
12:05:44 +1100)


powerpc fixes for 4.0 # 3

 - fix memory corruption by pnv_alloc_idle_core_states


Jan Stancek (1):
  powerpc: fix memory corruption by pnv_alloc_idle_core_states

 arch/powerpc/include/asm/cputhreads.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)




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

Re: Concerns about mpt2sas: Added Reply Descriptor Post Queue (RDPQ) Array support

[James Bottomley]

On Thu, 2015-04-02 at 16:39 +1100, Benjamin Herrenschmidt wrote:
 On Thu, 2015-02-19 at 21:45 -0800, James Bottomley wrote:
 
  Ben, this is legal by design.  It was specifically designed for the
  aic79xx SCSI card, but can be used for a variety of other reasons.  The
  aic79xx hardware problem was that the DMA engine could address the whole
  of memory (it had two address modes, a 39 bit one and a 64 bit one) but
  the script engine that runs the mailboxes only had a 32 bit activation
  register (the activating write points at the physical address of the
  script to begin executing).  This meant that the scripts that run in
  memory had to be in the first 4GB of physical memory, hence the split
  mask.  The DMA mask specifies that the card can transfer from anywhere
  in physical memory, but the consistent_dma_mask says that the consistent
  allocation used to get scripts memory must come from the lower 4GB.
 
 So looking at that again...
 
 This is interesting ... basically any driver using a different mask has
 been broken on powerpc for basically ever. The whole concept was poorly
 designed, for example,  the set_consistent_mask isn't a dma_map_ops
 unlike everything else.
 
 In some cases, what we want is convey a base+offset information to
 drivers but we can't do that.
 
 This stuff cannot work with setups like a lot of our iommus where we
 have a remapped region at the bottom of the DMA address space and a
 bypass (direct map) region high up.
 
 Basically, we can fix it, at least for most platforms, but it will be
 hard, invasive, *and* will need to go to stable. Grmbl.

Well, it was originally a hack for altix, because they had no regions
below 4GB and had to specifically manufacture them.  As you know, in
Linux, if Intel doesn't need it, no-one cares and the implementation
bitrots.

 We'll have to replace our direct DMA ops (which just apply an offset)
 which we use for devices that set a 64-bit mask on platform that support
 a bypass window, with some smart-ass hybrid variant that selectively
 shoot stuff up to the bypass window or down via the iommu remapped based
 on the applicable mask for a given operation.
 
 It would be nice if we could come up with a way to inform the driver
 that we support that sort of bypass region with an offset. That would
 allow drivers that have that 64-bit base + 32-bit offset scheme to work
 much more efficiently for us. The driver could configure the base to be
 our bypass window offset, and we could use ZONE_DMA32 for consistent
 DMAs.
 
 It would also help us with things like some GPUs that can only do 40-bit
 DMA (which won't allow them to reach our bypass region normally) but do
 have a way to configure the generated top bits of all DMA addresses in
 some fixed register.
 
 Any idea what such an interface might look like ?

Why doesn't the API we have today work (modulo a better implementation)?
A consistent mask specifies a wide range of possible locations for your
bypass region.  You just have to select one and attach it somehow and
remember to use it for consistent allocations.  As long as
set_consistent_mask becomes a dma op, it should all work, right?

James


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH urgent] x86, asm: Disable opportunistic SYSRET if regs-flags has TF set

[Borislav Petkov]

On Wed, Apr 01, 2015 at 11:18:16PM +0200, Denys Vlasenko wrote:
 On 04/01/2015 09:25 PM, Andy Lutomirski wrote:
  Fix it by using IRET to restore TF.  Since it's late, I'm keeping
  this minimal and keeping testq instead of switching to testl.
 
 Changing to testl here wins nothing.

Except less data (a dword) being shuffled and tracked for dependencies
in the machine instead of qword.

 Since r11 is used, REX prefix will be encoded anyway.

As a future cleanup, one could use one of the old, i.e. not-extended
registers to save 2 bytes per insn (REX pfx and ModRM) but one has to
remember to do

mov %rax, %r11

in the end.

And yep, it should preferrably be %rax as we have opcode 0xa9 which
tests an immediate and RAX and saves us the ModRM as we don't need to
specify a register.

orig:
 a42:   49 f7 c3 00 00 01 00test   $0x1,%r11
 a49:   75 41   jnea8c opportunistic_sysret_failed

Andy:
 a42:   49 f7 c3 00 01 01 00test   $0x10100,%r11
 a49:   75 41   jnea8c opportunistic_sysret_failed

testl:
 a42:   41 f7 c3 00 01 01 00test   $0x10100,%r11d
 a49:   75 41   jnea8c opportunistic_sysret_failed

%rax:
 a42:   a9 00 01 01 00  test   $0x10100,%eax
 a47:   75 41   jnea8a opportunistic_sysret_failed

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] allow constant folding in msecs_to_jiffies where possible for gcc

[Nicholas Mc Guire]

A number of cleanup patches where switching var * HZ / 1000
constructs to msecs_to_jiffies(var) to ensure that all corener
cases are handled properly. The downside of this though is that
it now uses a function call and also was not performing
constant folding where it was originally possible.

msecs_to_jiffies() will calculate jiffies even if constants are
passed in that could be handled by constant folding at compile time
using __builtin_constant_p() gcc can optimize the constant case
again.

Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---

reported by Aaron Sierra asie...@xes-inc.com
solution suggested by Joe Perches j...@perches.com

Patch is against 4.0-rc6 (localversion-next is -next-20150401)

Boot tested on x86 64 only

 kernel/time/time.c |   39 ---
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/kernel/time/time.c b/kernel/time/time.c
index 2c85b77..8cb550a 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -496,15 +496,14 @@ EXPORT_SYMBOL(ns_to_timespec64);
  *   the input value by a factor or dividing it with a factor
  *
  * We must also be careful about 32-bit overflows.
+ *
+ * msecs_to_jiffies() will check for the passed in value being constant
+ * via __builtin_constant_p() allowing gcc to eliminate most of the code
+ * __msecs_to_jiffies() will be called if the value passed does not allow
+ * gcc to do constant folding.
  */
-unsigned long msecs_to_jiffies(const unsigned int m)
+static unsigned long __msecs_to_jiffies(const unsigned int m)
 {
-   /*
-* Negative value, means infinite timeout:
-*/
-   if ((int)m  0)
-   return MAX_JIFFY_OFFSET;
-
 #if HZ = MSEC_PER_SEC  !(MSEC_PER_SEC % HZ)
/*
 * HZ is equal to or smaller than 1000, and 1000 is a nice
@@ -537,6 +536,32 @@ unsigned long msecs_to_jiffies(const unsigned int m)
 MSEC_TO_HZ_SHR32;
 #endif
 }
+
+unsigned long msecs_to_jiffies(const unsigned int m)
+{
+   /*
+* Negative value, means infinite timeout:
+*/
+   if ((int)m  0)
+   return MAX_JIFFY_OFFSET;
+
+   if (__builtin_constant_p(m)) {
+#if HZ = MSEC_PER_SEC  !(MSEC_PER_SEC % HZ)
+   return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ);
+#elif HZ  MSEC_PER_SEC  !(HZ % MSEC_PER_SEC)
+   if (m  jiffies_to_msecs(MAX_JIFFY_OFFSET))
+   return MAX_JIFFY_OFFSET;
+   return m * (HZ / MSEC_PER_SEC);
+#else
+   if (HZ  MSEC_PER_SEC  m  jiffies_to_msecs(MAX_JIFFY_OFFSET))
+   return MAX_JIFFY_OFFSET;
+
+   return (MSEC_TO_HZ_MUL32 * m + MSEC_TO_HZ_ADJ32)
+MSEC_TO_HZ_SHR32;
+#endif
+   } else
+   return __msecs_to_jiffies(m);
+}
 EXPORT_SYMBOL(msecs_to_jiffies);
 
 unsigned long usecs_to_jiffies(const unsigned int u)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] selftests/mount: output error messages when mount test fail

[Zhang Zhen]

Without this patch, if /proc/self/uid_map is not exist,
the mount test case will fail and no any prompting.

After applied this patch, the case will prompt why it fail.
Just as follows:
root@kernel-host:/opt/kernel make -C tools/testing/selftests TARGETS=mount 
run_tests
make: Entering directory `/opt/kernel/tools/testing/selftests'
for TARGET in mount; do \
make -C $TARGET; \
done;
make[1]: Entering directory `/opt/kernel/tools/testing/selftests/mount'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/opt/kernel/tools/testing/selftests/mount'
for TARGET in mount; do \
make -C $TARGET run_tests; \
done;
make[1]: Entering directory `/opt/kernel/tools/testing/selftests/mount'
ERROR: No /proc/self/uid_map exist
make[1]: Leaving directory `/opt/kernel/tools/testing/selftests/mount'
make: Leaving directory `/opt/kernel/tools/testing/selftests'

Signed-off-by: Zhang Zhen zhenzhang.zh...@huawei.com
---
 tools/testing/selftests/mount/Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/mount/Makefile 
b/tools/testing/selftests/mount/Makefile
index a5b367f..b3266db 100644
--- a/tools/testing/selftests/mount/Makefile
+++ b/tools/testing/selftests/mount/Makefile
@@ -8,7 +8,12 @@ unprivileged-remount-test: unprivileged-remount-test.c
 include ../lib.mk

 TEST_PROGS := unprivileged-remount-test
-override RUN_TESTS := if [ -f /proc/self/uid_map ] ; then 
./unprivileged-remount-test ; fi
+override RUN_TESTS :=  @if [ -f /proc/self/uid_map ] ; \
+   then\
+   ./unprivileged-remount-test ; \
+   else\
+   echo ERROR: No /proc/self/uid_map exist ; \
+   fi
 override EMIT_TESTS := echo $(RUN_TESTS)

 clean:
-- 
1.8.5.5


.




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH perf/core v2] perf-probe: Fix to track down unnamed union/structure members

[Masami Hiramatsu]

Fix perf probe to track down unnamed union/structure members.
perf probe did not track down the tree of unnamed union/structure
members, since it just failed to find given name in a parent
structure/union. To solve this issue, I've introduced 2 changes.

- Fix die_find_member() to track down the type-DIE if it is
  unnamed, and if it contains the specified member, returns the
  unnamed member.
  (note that we don't return found member, since unnamed member
   has the offset in the parent structure)
- Fix convert_variable_fields() to track down the unnamed union/
  structure (one-by-one).

With this patch, perf probe can access unnamed fields.
  -
  #./perf probe -nfx ./perf lock__delete ops 'locked_ops=ops-locked.ops'
  Added new event:
probe_perf:lock__delete (on lock__delete in 
/home/mhiramat/ksrc/linux-3/tools/perf/perf with ops locked_ops=ops-locked.ops)

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

  perf record -e probe_perf:lock__delete -aR sleep 1
  -

The original report of this issue is: https://lkml.org/lkml/2015/3/5/431

Reported-by: Arnaldo Carvalho de Melo a...@kernel.org
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
 tools/perf/util/dwarf-aux.c|   14 ++
 tools/perf/util/probe-finder.c |8 +++-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c
index 780b2bc..c34e024 100644
--- a/tools/perf/util/dwarf-aux.c
+++ b/tools/perf/util/dwarf-aux.c
@@ -801,10 +801,16 @@ static int __die_find_member_cb(Dwarf_Die *die_mem, void 
*data)
 {
const char *name = data;
 
-   if ((dwarf_tag(die_mem) == DW_TAG_member) 
-   die_compare_name(die_mem, name))
-   return DIE_FIND_CB_END;
-
+   if (dwarf_tag(die_mem) == DW_TAG_member) {
+   if (die_compare_name(die_mem, name))
+   return DIE_FIND_CB_END;
+   else if (!dwarf_diename(die_mem)) { /* Unnamed structure */
+   Dwarf_Die type_die, tmp_die;
+   if (die_get_type(die_mem, type_die) 
+   die_find_member(type_die, name, tmp_die))
+   return DIE_FIND_CB_END;
+   }
+   }
return DIE_FIND_CB_SIBLING;
 }
 
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 46f009a..7831e2d 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -460,7 +460,8 @@ static int convert_variable_fields(Dwarf_Die *vr_die, const 
char *varname,
nor array.\n, varname);
return -EINVAL;
}
-   if (field-ref) {
+   /* While prcessing unnamed field, we don't care about this */
+   if (field-ref  dwarf_diename(vr_die)) {
pr_err(Semantic error: %s must be referred by '.'\n,
   field-name);
return -EINVAL;
@@ -491,6 +492,11 @@ static int convert_variable_fields(Dwarf_Die *vr_die, 
const char *varname,
}
ref-offset += (long)offs;
 
+   /* If this member is unnamed, we need to reuse this field */
+   if (!dwarf_diename(die_mem))
+   return convert_variable_fields(die_mem, varname, field,
+   ref, die_mem);
+
 next:
/* Converting next field */
if (field-next)

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/86] pci: export pci_ids.h and related cleanups

[Jean Delvare]

Hi Michael, Bjorn and all,

On Sun, 29 Mar 2015 15:36:55 +0200, Michael S. Tsirkin wrote:
 The macros in pci_ids.h are pretty useful for userspace
 using the pci sysfs interface, e.g. to decode class
 device and vendor sysfs files.
 
 At the moment userspace is forced to duplicate these macros (e.g. QEMU does
 this, so does gpxe, seabios, etc), it is better to export them in
 /usr/include/linux/pci_ids.h so everyone can just include this header.
 
 This patchset is structured as follows:
 1. include/linux/pci_ids.h is moved to include/uapi/linux/pci_ids.h;
a stub file is created in include/linux/pci_ids.h to avoid breaking
bisect
 2. all users are converted to use the new header
 3. include/linux/pci_ids.h is removed
 4. cleanups for several issues detected during step 2
 
 The patchset was built on several architectures (mips/ppc/x86),
 boot-tested on x86 only - build seems sufficient for this kind of
 change.
 
 I think the pci tree is the most appropriate for this patchset.
 Please review it, and consider for 4.1.

I've been thinking some more about the whole move and I'm not so sure
it is a good idea. I don't think that pci_ids.h qualifies as a stable
API for user-space.

1* For one thing, the header of that file says:

 *  Do not add new entries to this file unless the definitions
 *  are shared between multiple drivers.

which implies that some IDs will never make it into the file, even if
some user-space tool would benefit from it.

2* For another, we have sometimes removed definitions from that file,
see commits 7ee4910ab31c4b1fafb7e4f273cbe9340ac953aa,
fee8bf4b74e37bfeb8998a349cb788680eb3f634 or
26e8220adb0aec43b7acafa0f1431760eee28522 for recent examples of this.
So user-space tools can't assume that an ID being present in that file
one day will stay there forever.

3* Also IDs are being added over time, so if you build a recent version
of a tool with an old kernel, the most recent IDs may not be there.

This all implies that user-space tools will have to keep defining the
IDs they use for compatibility anyway. So I don't quite see what good
will come from this move. This is a large and intrusive patch set, you
would need a significant benefit to justify its cost. I can't see that.

I think it would only make (some) sense to declare pci_ids.h a
user-space API if we change the rules: all IDs must go in pci_ids.h
again, and IDs that go there can no longer be removed. But that's a big
change (there was a reason for the current rule) and that doesn't even
address point 3 above. So I seriously doubt it's worth it.

Just because some user-space tools give symbolic names to PCI IDs isn't
a sufficient reason to export the kernel's pci_ids.h to user-space. I
mean, linux/kernel.h defines the ARRAY_SIZE macro, and many many
user-space projects have a similar macro because it's very useful. That
doesn't mean that the kernel should export it. Same goes for a
countless list of utility macros, linked list management etc, most of
that is reimplemented in various user-space libraries and utilities but
it is certainly not the kernel's responsibility to provide the
implementation.

Kernel/user-space API should be limited to what is required, not what
is possible or what looks convenient. Remember it comes with big
constraints, so as a general rule it must stay as small as possible.

It could be that a small subset of pci_ids.h could be shared with
user-space. I'm thinking of classes, because that list is short and
stable, so we can give some stability guarantees. But I don't know if
the user-space projects you quoted actually use that, so even that may
not be worth it.

-- 
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PULL] NBD patches for 4.1

[Markus Pargmann]

Hi Jens,

This pull request contains some NBD cleanups.

The documentation was updated to be extensible for future features and the
module parameters were added.

NBD had an internal header located at include/linux/nbd.h which was only used
by nbd.c. So I moved the header content from include/ to the top of nbd.c.

The debugging prints of nbd which contained a basic filter functionality were
replaced by dev_dbg(). This removes the ability to filter by categories. But it
is now possible to use dynamic debugging.

The other patches are some small simplifications.

Best Regards,

Markus


The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:

  Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/mpa/linux-nbd.git tags/nbd-for-4.1

for you to fetch changes up to b824817aed32f1851ee0a7318dfcc76cabcb3069:

  nbd: Return error pointer directly (2015-04-01 13:07:28 +0200)


nbd cleanups for 4.1 based on v4.0-rc3


Markus Pargmann (9):
  Documentation: nbd: Reformat to allow more documentation
  Documentation: nbd: Add list of module parameters
  nbd: Remove kernel internal header
  nbd: Replace kthread_create with kthread_run
  nbd: Fix device bytesize type
  nbd: Restructure debugging prints
  nbd: Remove fixme that was already fixed
  nbd: Return error code directly
  nbd: Return error pointer directly

 Documentation/blockdev/nbd.txt |  48 +-
 drivers/block/nbd.c| 140 -
 include/linux/nbd.h|  46 --
 3 files changed, 86 insertions(+), 148 deletions(-)
 delete mode 100644 include/linux/nbd.h

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/9] nbd: Replace kthread_create with kthread_run

[Markus Pargmann]

kthread_run includes the wake_up_process() call, so instead of
kthread_create() followed by wake_up_process() we can use this macro.

Signed-off-by: Markus Pargmann m...@pengutronix.de
Acked-by: Pavel Machek pa...@ucw.cz
---
 drivers/block/nbd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 58c2b20ad17b..c07160c25a94 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -728,13 +728,13 @@ static int __nbd_ioctl(struct block_device *bdev, struct 
nbd_device *nbd,
else
blk_queue_flush(nbd-disk-queue, 0);
 
-   thread = kthread_create(nbd_thread, nbd, %s,
-   nbd-disk-disk_name);
+   thread = kthread_run(nbd_thread, nbd, %s,
+nbd-disk-disk_name);
if (IS_ERR(thread)) {
mutex_lock(nbd-tx_lock);
return PTR_ERR(thread);
}
-   wake_up_process(thread);
+
error = nbd_do_it(nbd);
kthread_stop(thread);
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/9] nbd: Fix device bytesize type

[Markus Pargmann]

The block subsystem uses loff_t to store the device size. Change the
type for nbd_device bytesize to loff_t.

Signed-off-by: Markus Pargmann m...@pengutronix.de
Acked-by: Pavel Machek pa...@ucw.cz
---
 drivers/block/nbd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index c07160c25a94..13c8371cbf4c 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -32,6 +32,7 @@
 #include net/sock.h
 #include linux/net.h
 #include linux/kthread.h
+#include linux/types.h
 
 #include asm/uaccess.h
 #include asm/types.h
@@ -54,7 +55,7 @@ struct nbd_device {
struct mutex tx_lock;
struct gendisk *disk;
int blksize;
-   u64 bytesize;
+   loff_t bytesize;
pid_t pid; /* pid of nbd-client, if attached */
int xmit_timeout;
int disconnect; /* a disconnect has been requested by user */
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 0/3] dmaengine: APM X-Gene SoC DMA engine driver support

[Vinod Koul]

On Wed, Mar 18, 2015 at 07:17:33PM +0530, Rameshwar Prasad Sahu wrote:
 This patch set implements the APM X-Gene SoC DMA driver support to offload
 the DMA operations such as memory copy(memcpy), scatter gather memory copy,
 raid5 xor and raid6 p+q.
Applied, now

Thanks
-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/9] nbd: Remove fixme that was already fixed

[Christoph Hellwig]

On Thu, Apr 02, 2015 at 10:11:39AM +0200, Markus Pargmann wrote:
 +/*
 + * Forcibly shutdown the socket causing all listeners to error
 + */
  static void sock_shutdown(struct nbd_device *nbd, int lock)
  {
 - /* Forcibly shutdown the socket causing all listeners
 -  * to error
 -  *
 -  * FIXME: This code is duplicated from sys_shutdown, but
 -  * there should be a more generic interface rather than
 -  * calling socket ops directly here */
   if (lock)
   mutex_lock(nbd-tx_lock);
   if (nbd-sock) {

Please also kill the conditional locking here in a future patch by
moving it into the caller.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH drm] drm/vgem: vgem_gem_dumb_map() can be static

[Fengguang Wu]

On Wed, Apr 01, 2015 at 08:04:55PM -0700, Joe Perches wrote:
 On Thu, 2015-04-02 at 10:59 +0800, kbuild test robot wrote:
  Signed-off-by: Fengguang Wu fengguang...@intel.com
 []
  diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
  b/drivers/gpu/drm/vgem/vgem_drv.c
 []
  @@ -195,7 +195,7 @@ static int vgem_gem_dumb_create(struct drm_file *file, 
  struct drm_device *dev,
  return 0;
   }
   
  -int vgem_gem_dumb_map(struct drm_file *file, struct drm_device *dev,
  +static int vgem_gem_dumb_map(struct drm_file *file, struct drm_device *dev,
uint32_t handle, uint64_t *offset)
 
 Hello Fengguang.
 
 When you or your robot does these, can you please
 make sure the entire statement is indented properly?

OK, added it to the TODO list. Sorry for the inconvenience!

Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 02/17 v2] tracing: Add TRACE_SYSTEM_VAR to kvm-s390

[Cornelia Huck]

On Wed, 01 Apr 2015 21:56:50 -0400
Steven Rostedt rost...@goodmis.org wrote:

 From: Steven Rostedt (Red Hat) rost...@goodmis.org
 
 New code will require TRACE_SYSTEM to be a valid C variable name,
 but some tracepoints have TRACE_SYSTEM with '-' and not '_', so
 it can not be used. Instead, add a TRACE_SYSTEM_VAR that can
 give the tracing infrastructure a unique name for the trace system.
 
 Cc: Martin Schwidefsky schwidef...@de.ibm.com
 Cc: Heiko Carstens heiko.carst...@de.ibm.com
 Cc: David Hildenbrand d...@linux.vnet.ibm.com
 Cc: Cornelia Huck cornelia.h...@de.ibm.com
 Cc: Christian Borntraeger borntrae...@de.ibm.com
 Signed-off-by: Steven Rostedt rost...@goodmis.org
 ---
  arch/s390/kvm/trace-s390.h | 7 +++
  1 file changed, 7 insertions(+)

Acked-by: Cornelia Huck cornelia.h...@de.ibm.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 00/12] mm: page_alloc: improve OOM mechanism and policy

[Michal Hocko]

On Thu 02-04-15 08:39:02, Dave Chinner wrote:
 On Wed, Apr 01, 2015 at 05:19:20PM +0200, Michal Hocko wrote:
  On Mon 30-03-15 11:32:40, Dave Chinner wrote:
   On Fri, Mar 27, 2015 at 11:05:09AM -0400, Johannes Weiner wrote:
  [...]
GFP_NOFS sites are currently one of the sites that can deadlock inside
the allocator, even though many of them seem to have fallback code.
My reasoning here is that if you *have* an exit strategy for failing
allocations that is smarter than hanging, we should probably use that.
   
   We already do that for allocations where we can handle failure in
   GFP_NOFS conditions. It is, however, somewhat useless if we can't
   tell the allocator to try really hard if we've already had a failure
   and we are already in memory reclaim conditions (e.g. a shrinker
   trying to clean dirty objects so they can be reclaimed).
   
   From that perspective, I think that this patch set aims force us
   away from handling fallbacks ourselves because a) it makes GFP_NOFS
   more likely to fail, and b) provides no mechanism to try harder
   when we really need the allocation to succeed.
  
  You can ask for this try harder by __GFP_HIGH flag. Would that help
  in your fallback case?
 
 That dips into GFP_ATOMIC reserves, right? What is the impact on the
 GFP_ATOMIC allocations that need it?

Yes the memory reserve is shared but the flag would be used only after
previous GFP_NOFS allocation has failed which means that that the system
is close to the OOM and chances for GFP_ATOMIC allocations (which are
GFP_NOWAIT and cannot perform any reclaim) success are quite low already.

 We typically see network cards fail GFP_ATOMIC allocations before XFS
 starts complaining about allocation failures, so i suspect that this
 might just make things worse rather than better...

My understanding is that GFP_ATOMIC allocation would fallback to
GFP_WAIT type of allocation in the deferred context in the networking
code. There would be some performance hit but again we are talking
about close to OOM conditions here.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/