[PATCH] max8925_power: Use "IS_ENABLED(CONFIG_OF)" for DT code.

[Manish Badarkhe]

Instead of "#if define CONFIG_OF" use "IS_ENABLED(CONFIG_OF)"
option for DT code to avoid if-deffery in code.

Signed-off-by: Manish Badarkhe 
---
:100644 100644 b4513f2... d353fbc... M  drivers/power/max8925_power.c
 drivers/power/max8925_power.c |   14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/power/max8925_power.c b/drivers/power/max8925_power.c
index b4513f2..d353fbc 100644
--- a/drivers/power/max8925_power.c
+++ b/drivers/power/max8925_power.c
@@ -427,7 +427,6 @@ static int max8925_deinit_charger(struct max8925_power_info 
*info)
return 0;
 }
 
-#ifdef CONFIG_OF
 static struct max8925_power_pdata *
 max8925_power_dt_init(struct platform_device *pdev)
 {
@@ -468,13 +467,6 @@ max8925_power_dt_init(struct platform_device *pdev)
 
return pdata;
 }
-#else
-static struct max8925_power_pdata *
-max8925_power_dt_init(struct platform_device *pdev)
-{
-   return pdev->dev.platform_data;
-}
-#endif
 
 static int max8925_power_probe(struct platform_device *pdev)
 {
@@ -483,7 +475,11 @@ static int max8925_power_probe(struct platform_device 
*pdev)
struct max8925_power_info *info;
int ret;
 
-   pdata = max8925_power_dt_init(pdev);
+   if (IS_ENABLED(CONFIG_OF))
+   pdata = max8925_power_dt_init(pdev);
+   else
+   pdata = pdev->dev.platform_data;
+
if (!pdata) {
dev_err(>dev, "platform data isn't assigned to "
"power supply\n");
-- 
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/

Re: disabled APICs being counted as processors ?

[David Rientjes]

On Sat, 25 Jan 2014, Dave Jones wrote:

>  > > it looks like this is because..
>  > > 
>  > > [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
>  > > [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
>  > > [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
>  > > [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled)
>  > > [0.00] ACPI: LAPIC (acpi_id[0x05] lapic_id[0xff] disabled)
>  > > [0.00] ACPI: LAPIC (acpi_id[0x06] lapic_id[0xff] disabled)
>  > > [0.00] ACPI: LAPIC (acpi_id[0x07] lapic_id[0xff] disabled)
>  > > [0.00] ACPI: LAPIC (acpi_id[0x08] lapic_id[0xff] disabled)
>  > > 
>  > > Should the CPU counting code be ignoring those disabled APICs ?
>  > 
>  > Hm, so to the kernel it looks like as if those were 'possible CPUs', 
>  > in theory hotpluggable. Not sure what they are - disabled cores in an 
>  > 8-core system? Or BIOS reporting crap?
>  > 
>  > But perhaps the boot message could be improved to say something like:
>  > 
>  > > [0.00] smpboot: 8 possible processors exceeds NR_CPUS limit of 4
> 
> It's not possible though. It's an i5-4670T, in a single socket board.
> It doesn't even have hyperthreading. 
> http://ark.intel.com/products/75050/Intel-Core-i5-4670T-Processor-6M-Cache-up-to-3_30-GHz
> 

I don't think the "ACPI: LAPIC (... disabled)" lines are problematic, they 
are simply reporting the acpi processor id and apic id for processors that 
do not have their enabled flag set.  The acpi spec allows for these to 
exist without the enabled flag set when the processor isn't present at all 
because the kernel will make no attempt to use it.

That said, I think the "smpboot: 8 Processors exceeds NR_CPUS limit of 4" 
line is unnecessary since, as you said, these processors don't physically 
exist.  I betcha that's because you have CONFIG_HOTPLUG_CPU enabled and 
it's counting the disabled cpus that were found when acpi_register_lapic() 
was done.  The warning is only really meaningful for cpus in 
cpu_possible_map, which aren't set for your disabled four, in the hotplug 
case where NR_CPUS is too small.
--
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] MAINTAINERS: ADI Linux development mailing lists change to the new server.

[Sonic Zhang]

From: Sonic Zhang 

Update Blackfin arch branch maintainer's email as well.

Signed-off-by: Sonic Zhang 
---
 MAINTAINERS | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7cacc88..bd49e70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -288,36 +288,36 @@ F:sound/pci/ad1889.*
 
 AD525X ANALOG DEVICES DIGITAL POTENTIOMETERS DRIVER
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/AD5254
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/misc/ad525x_dpot.c
 
 AD5398 CURRENT REGULATOR DRIVER (AD5398/AD5821)
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/AD5398
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/regulator/ad5398.c
 
 AD714X CAPACITANCE TOUCH SENSOR DRIVER (AD7142/3/7/8/7A)
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/AD7142
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/input/misc/ad714x.c
 
 AD7877 TOUCHSCREEN DRIVER
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/AD7877
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/input/touchscreen/ad7877.c
 
 AD7879 TOUCHSCREEN DRIVER (AD7879/AD7889)
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/AD7879
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/input/touchscreen/ad7879.c
 
@@ -353,8 +353,8 @@ F:  include/media/adp1653.h
 
 ADP5520 BACKLIGHT DRIVER WITH IO EXPANDER (ADP5520/ADP5501)
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/ADP5520
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/mfd/adp5520.c
 F: drivers/video/backlight/adp5520_bl.c
@@ -364,16 +364,16 @@ F:drivers/input/keyboard/adp5520-keys.c
 
 ADP5588 QWERTY KEYPAD AND IO EXPANDER DRIVER (ADP5588/ADP5587)
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/ADP5588
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/input/keyboard/adp5588-keys.c
 F: drivers/gpio/gpio-adp5588.c
 
 ADP8860 BACKLIGHT DRIVER (ADP8860/ADP8861/ADP8863)
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/ADP8860
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/video/backlight/adp8860_bl.c
 
@@ -399,8 +399,8 @@ F:  drivers/hwmon/adt7475.c
 
 ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
 M: Michael Hennerich 
-L: device-drivers-de...@blackfin.uclinux.org
 W: http://wiki.analog.com/ADXL345
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/input/misc/adxl34x.c
 
@@ -588,9 +588,9 @@ F:  drivers/media/i2c/adv7604*
 
 ANALOG DEVICES INC ASOC CODEC DRIVERS
 M: Lars-Peter Clausen 
-L: device-drivers-de...@blackfin.uclinux.org
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 W: http://wiki.analog.com/
+W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: sound/soc/codecs/adau*
 F: sound/soc/codecs/adav*
@@ -599,7 +599,7 @@ F:  sound/soc/codecs/ssm*
 F: sound/soc/codecs/sigmadsp.*
 
 ANALOG DEVICES INC ASOC DRIVERS
-L: uclinux-dist-de...@blackfin.uclinux.org
+L: adi-buildroot-de...@lists.sourceforge.net
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
 W: http://blackfin.uclinux.org/
 S: Supported
@@ -1666,56 +1666,54 @@ F:  fs/bfs/
 F: include/uapi/linux/bfs_fs.h
 
 BLACKFIN ARCHITECTURE
-M: Mike Frysinger 
-L: uclinux-dist-de...@blackfin.uclinux.org
+M: Steven Miao 
+L: adi-buildroot-de...@lists.sourceforge.net
 W: http://blackfin.uclinux.org
 S: Supported
 F: arch/blackfin/
 
 BLACKFIN EMAC DRIVER
-L: uclinux-dist-de...@blackfin.uclinux.org
+L: adi-buildroot-de...@lists.sourceforge.net
 W: http://blackfin.uclinux.org
 S: Supported
 F: drivers/net/ethernet/adi/
 
 BLACKFIN RTC DRIVER
-M: Mike Frysinger 
-L: uclinux-dist-de...@blackfin.uclinux.org
+L: adi-buildroot-de...@lists.sourceforge.net
 W: http://blackfin.uclinux.org
 S: Supported
 F: drivers/rtc/rtc-bfin.c
 
 BLACKFIN SDH DRIVER
 M: Sonic Zhang 
-L: uclinux-dist-de...@blackfin.uclinux.org
+L: adi-buildroot-de...@lists.sourceforge.net
 W: http://blackfin.uclinux.org
 S: Supported
 F: drivers/mmc/host/bfin_sdh.c
 
 BLACKFIN SERIAL DRIVER
 M: Sonic 

Re: [PATCH 3.4 00/12] 3.4.78-stable review

[Guenter Roeck]

On 01/25/2014 07:05 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.4.78 release.
There are 12 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue Jan 28 03:04:41 UTC 2014.
Anything received after that time might be too late.



Build results are as expected, with the usual failures:
total: 119 pass: 97 skipped: 18 fail: 4

qemu tests all passed.

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

--
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 1/8] ASoC: fsl: Add VF610 soc audio card Kconfig

[li.xi...@freescale.com]

Hi Mark,

> > +config SND_SOC_VF610_SGTL5000
> > +   tristate "SoC Audio support for VF610 boards with SGTL5000"
> > +   depends on OF && I2C
> > +   select SND_SOC_FSL_SAI
> > +   select SND_SOC_SGTL5000
> > +   select SND_SIMPLE_CARD
> 
> ...for simple card since the whole idea is to support any CODEC with the
> same driver we should probably just make sure that all the individual
> drivers can be enabled in Kconfig, that way we don't have to have
> specific Kconfig entries for boards and loose some of the benefit of the
> generic card.  I sent a patch earlier exposing the OF supporting CODEC
> drivers, one for at least some of the Freescale CPU drivers was sent to
> the list recently too but there were some review comments.

I hadn't found the patches, could you tell me the titles of them please?

Thanks very much,

--
* Happy New Year *

Best Regards,
Xiubo


--
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: [Q] L1_CACHE_BYTES on flush_pfn_alias function.

[Jungseung Lee]

Not to flush some more bytes. In the scenario, they can *omit* to flush last 32 
bytes.

L1_CACHE_BYTES = 64 (ARM v7, CA9)

asm("mcrr   p15, 0, %1, %0, c14\n"
"   mcr p15, 0, %2, c7, c10, 4"
:
: "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
: "cc");
-Original Message-
From: Catalin Marinas [mailto:catalin.mari...@arm.com] 
Sent: Saturday, January 25, 2014 12:43 AM
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; 
linux-kernel@vger.kernel.org
Subject: Re: [Q] L1_CACHE_BYTES on flush_pfn_alias function.

On Fri, Jan 17, 2014 at 09:54:42AM +,wrote:
> Follow the mailing-list
> http://comments.gmane.org/gmane.linux.ports.arm.omap/31686
> 
> >>Setting the L1 cache line size larger than it actually is should be safe.
> 
> the written code expected as L1_CACHE_BYTES should be real cache line 
> size has bug.
> It looks like that flush_pfn_alias function should be fixed.

Did you actually notice any problem with flushing some more bytes? It's a 
clean+invalidate rather than invalidate, I don't see any problem.

--
Catalin

--
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/

[for-next][PATCH 1/3] tracing/README: Add event file usage to tracing mini-HOWTO

[Steven Rostedt]

From: Tom Zanussi 

It would be useful to have a cheat-sheet for everything under
tracing/events/ alongside the existing text describing the other files
in the tracing/ dir.

Add short descriptions of the directories and files under events/
along with examples, similar to the existing text for the other files
in tracing/.

Also clean up a few minor alignment problems noticed when adding the
new text.

Link: http://lkml.kernel.org/r/1389993104.3040.445.camel@empanada

Signed-off-by: Tom Zanussi 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 37 ++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 20c755e..2ced5e5 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3523,9 +3523,9 @@ static const char readme_msg[] =
 #ifdef CONFIG_DYNAMIC_FTRACE
"\n  available_filter_functions - list of functions that can be 
filtered on\n"
"  set_ftrace_filter\t- echo function name in here to only trace these 
functions\n"
-   "accepts: func_full_name, *func_end, func_begin*, 
*func_middle*\n"
-   "modules: Can select a group via module\n"
-   " Format: :mod:\n"
+   " accepts: func_full_name, *func_end, func_begin*, 
*func_middle*\n"
+   " modules: Can select a group via module\n"
+   "  Format: :mod:\n"
" example: echo :mod:ext3 > set_ftrace_filter\n"
"triggers: a command to perform when function is hit\n"
"  Format: :[:count]\n"
@@ -3573,6 +3573,37 @@ static const char readme_msg[] =
"  stack_trace_filter\t- Like set_ftrace_filter but limits what 
stack_trace traces\n"
 #endif
 #endif /* CONFIG_STACK_TRACER */
+   "  events/\t\t- Directory containing all trace event subsystems:\n"
+   "  enable\t\t- Write 0/1 to enable/disable tracing of all events\n"
+   "  events//\t- Directory containing all trace events for 
:\n"
+   "  enable\t\t- Write 0/1 to enable/disable tracing of all  
events\n"
+   "  filter\t\t- If set, only events passing filter are traced\n"
+   "  events///\t- Directory containing control files for 
:\n"
+   "  enable\t\t- Write 0/1 to enable/disable tracing of \n"
+   "  filter\t\t- If set, only events passing filter are traced\n"
+   "  trigger\t\t- If set, a command to perform when event is hit\n"
+   "Format: [:count][if ]\n"
+   "   trigger: traceon, traceoff\n"
+   "enable_event::\n"
+   "disable_event::\n"
+#ifdef CONFIG_STACKTRACE
+   "stacktrace\n"
+#endif
+#ifdef CONFIG_TRACER_SNAPSHOT
+   "snapshot\n"
+#endif
+   "   example: echo traceoff > 
events/block/block_unplug/trigger\n"
+   "echo traceoff:3 > 
events/block/block_unplug/trigger\n"
+   "echo 'enable_event:kmem:kmalloc:3 if nr_rq > 1' > 
events/block/block_unplug/trigger\n"
+   "   The first disables tracing every time block_unplug is 
hit.\n"
+   "   The second disables tracing the first 3 times block_unplug 
is hit.\n"
+   "   The third enables the kmalloc event the first 3 times 
block_unplug\n"
+   " is hit and has value of greater than 1 for the 'nr_rq' 
event field.\n"
+   "   To remove a trigger without a count:\n"
+   " echo '! > //trigger\n"
+   "   To remove a trigger with a count:\n"
+   " echo '!:0 > //trigger\n"
+   "   Filters can be ignored when removing a trigger.\n"
 ;
 
 static ssize_t
-- 
1.8.4.3


--
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/

[for-next][PATCH 3/3] tracing: Check if tracing is enabled in trace_puts()

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

If trace_puts() is used very early in boot up, it can crash the machine
if it is called before the ring buffer is allocated. If a trace_printk()
is used with no arguments, then it will be converted into a trace_puts()
and suffer the same fate.

Cc: sta...@vger.kernel.org # 3.10+
Fixes: 09ae72348ecc "tracing: Add trace_puts() for even faster trace_printk() 
tracing"
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 7857ea9..815c878 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -455,6 +455,9 @@ int __trace_puts(unsigned long ip, const char *str, int 
size)
unsigned long irq_flags;
int alloc;
 
+   if (unlikely(tracing_selftest_running || tracing_disabled))
+   return 0;
+
alloc = sizeof(*entry) + size + 2; /* possible \n added */
 
local_save_flags(irq_flags);
@@ -495,6 +498,9 @@ int __trace_bputs(unsigned long ip, const char *str)
unsigned long irq_flags;
int size = sizeof(struct bputs_entry);
 
+   if (unlikely(tracing_selftest_running || tracing_disabled))
+   return 0;
+
local_save_flags(irq_flags);
buffer = global_trace.trace_buffer.buffer;
event = trace_buffer_lock_reserve(buffer, TRACE_BPUTS, size,
-- 
1.8.4.3


--
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/

[for-next][PATCH 0/3] tracing: Update to README and a small bug fix

[Steven Rostedt]

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next

Head SHA1: 3132e107d608f8753240d82d61303c500fd515b4


Steven Rostedt (Red Hat) (2):
  tracing: Fix formatting of trace README file
  tracing: Check if tracing is enabled in trace_puts()

Tom Zanussi (1):
  tracing/README: Add event file usage to tracing mini-HOWTO


 kernel/trace/trace.c | 113 ---
 1 file changed, 81 insertions(+), 32 deletions(-)
--
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/

[for-next][PATCH 2/3] tracing: Fix formatting of trace README file

[Steven Rostedt]

From: "Steven Rostedt (Red Hat)" 

Fix the formatting of the README file in the trace debugfs to fit in
an 80 character window.

Also add a comment about the event trigger counter with regards to
traceon and traceoff.

Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace.c | 116 ---
 1 file changed, 64 insertions(+), 52 deletions(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 2ced5e5..7857ea9 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3519,91 +3519,103 @@ static const char readme_msg[] =
"  instances\t\t- Make sub-buffers with: mkdir instances/foo\n"
"\t\t\t  Remove sub-buffer with rmdir\n"
"  trace_options\t\t- Set format or modify how tracing happens\n"
-   "\t\t\t  Disable an option by adding a suffix 'no' to the option name\n"
+   "\t\t\t  Disable an option by adding a suffix 'no' to the\n"
+   "\t\t\t  option name\n"
 #ifdef CONFIG_DYNAMIC_FTRACE
"\n  available_filter_functions - list of functions that can be 
filtered on\n"
-   "  set_ftrace_filter\t- echo function name in here to only trace these 
functions\n"
-   " accepts: func_full_name, *func_end, func_begin*, 
*func_middle*\n"
-   " modules: Can select a group via module\n"
-   "  Format: :mod:\n"
-   " example: echo :mod:ext3 > set_ftrace_filter\n"
-   "triggers: a command to perform when function is hit\n"
-   "  Format: :[:count]\n"
-   " trigger: traceon, traceoff\n"
-   "  enable_event::\n"
-   "  disable_event::\n"
+   "  set_ftrace_filter\t- echo function name in here to only trace 
these\n"
+   "\t\t\t  functions\n"
+   "\t accepts: func_full_name, *func_end, func_begin*, 
*func_middle*\n"
+   "\t modules: Can select a group via module\n"
+   "\t  Format: :mod:\n"
+   "\t example: echo :mod:ext3 > set_ftrace_filter\n"
+   "\ttriggers: a command to perform when function is hit\n"
+   "\t  Format: :[:count]\n"
+   "\t trigger: traceon, traceoff\n"
+   "\t\t  enable_event::\n"
+   "\t\t  disable_event::\n"
 #ifdef CONFIG_STACKTRACE
-   "  stacktrace\n"
+   "\t\t  stacktrace\n"
 #endif
 #ifdef CONFIG_TRACER_SNAPSHOT
-   "  snapshot\n"
+   "\t\t  snapshot\n"
 #endif
-   " example: echo do_fault:traceoff > set_ftrace_filter\n"
-   "  echo do_trap:traceoff:3 > set_ftrace_filter\n"
-   " The first one will disable tracing every time do_fault is 
hit\n"
-   " The second will disable tracing at most 3 times when 
do_trap is hit\n"
-   "   The first time do trap is hit and it disables tracing, 
the counter\n"
-   "   will decrement to 2. If tracing is already disabled, 
the counter\n"
-   "   will not decrement. It only decrements when the trigger 
did work\n"
-   " To remove trigger without count:\n"
-   "   echo '!: > set_ftrace_filter\n"
-   " To remove trigger with a count:\n"
-   "   echo '!::0 > set_ftrace_filter\n"
+   "\t example: echo do_fault:traceoff > set_ftrace_filter\n"
+   "\t  echo do_trap:traceoff:3 > set_ftrace_filter\n"
+   "\t The first one will disable tracing every time do_fault is hit\n"
+   "\t The second will disable tracing at most 3 times when do_trap is 
hit\n"
+   "\t   The first time do trap is hit and it disables tracing, the\n"
+   "\t   counter will decrement to 2. If tracing is already 
disabled,\n"
+   "\t   the counter will not decrement. It only decrements when the\n"
+   "\t   trigger did work\n"
+   "\t To remove trigger without count:\n"
+   "\t   echo '!: > set_ftrace_filter\n"
+   "\t To remove trigger with a count:\n"
+   "\t   echo '!::0 > set_ftrace_filter\n"
"  set_ftrace_notrace\t- echo function name in here to never trace.\n"
-   "accepts: func_full_name, *func_end, func_begin*, 
*func_middle*\n"
-   "modules: Can select a group via module command :mod:\n"
-   "Does not accept triggers\n"
+   "\taccepts: func_full_name, *func_end, func_begin*, *func_middle*\n"
+   "\tmodules: Can select a group via module command :mod:\n"
+   "\tDoes not accept triggers\n"
 #endif /* CONFIG_DYNAMIC_FTRACE */
 #ifdef CONFIG_FUNCTION_TRACER
-   "  set_ftrace_pid\t- Write pid(s) to only function trace those pids 
(function)\n"
+   "  set_ftrace_pid\t- Write pid(s) to only function trace those pids\n"
+   "\t\t(function)\n"
 #endif
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
"  set_graph_function\t- Trace 

Re: [PATCH v3 4/4] x86, mpx: extend siginfo structure to include bound violation information

[Ren Qiaowei]

On 01/26/2014 12:22 PM, David Rientjes wrote:

On Sun, 26 Jan 2014, Qiaowei Ren wrote:


This patch adds new fields about bound violation into siginfo
structure. si_lower and si_upper are respectively lower bound
and upper bound when bound violation is caused.

These fields will be set in #BR exception handler by decoding
the user instruction and constructing the faulting pointer.
A userspace application can get violation address, lower bound
and upper bound for bound violation from this new siginfo structure.

Signed-off-by: Qiaowei Ren 


Same 32-bit warnings I reported for v2:

arch/x86/kernel/mpx.c: In function ‘do_mpx_bounds’:
arch/x86/kernel/mpx.c:407:3: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
arch/x86/kernel/mpx.c:409:3: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]

and the documentation says you explicitly want to support this config.

These types of warnings are usually indicative of real problems when
you're storing upper and lower bits in 32-bit fields after casting them
from 64-bit values.

I'm also not sure if the added fields to the generic struct siginfo can be
justified for this.

According to MPX spec, for 32-bit case, the upper 32-bits of 64-bits 
bound register are ignored, and so casting to pointer from 64-bit values 
should be not produce any problems.


Thanks,
Qiaowei
--
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, hyperv: bypass the timer_irq_works() check

[Jason Wang]

On 01/25/2014 05:20 AM, H. Peter Anvin wrote:
> On 01/23/2014 10:02 PM, Jason Wang wrote:
>> This patch bypass the timer_irq_works() check for hyperv guest since:
>>
>> - It was guaranteed to work.
>> - timer_irq_works() may fail sometime due to the lpj calibration were 
>> inaccurate
>>   in a hyperv guest or a buggy host.
>>
>> In the future, we should get the tsc frequency from hypervisor and use preset
>> lpj instead.
>>
>> Cc: K. Y. Srinivasan 
>> Cc: Haiyang Zhang 
>> Signed-off-by: Jason Wang 
> This should be in -stable, right?
>
>   -hpa
>
>

Oh, right.

Cc: 
--
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: [linux-next][PATCH] mm: slub: work around unneeded lockdep warning

[David Rientjes]

On Fri, 24 Jan 2014, Dave Hansen wrote:

> From: Dave Hansen 
> 
> The slub code does some setup during early boot in
> early_kmem_cache_node_alloc() with some local data.  There is no
> possible way that another CPU can see this data, so the slub code
> doesn't unnecessarily lock it.  However, some new lockdep asserts
> check to make sure that add_partial() _always_ has the list_lock
> held.
> 
> Just add the locking, even though it is technically unnecessary.
> 
> Signed-off-by: Dave Hansen 
> Cc: Peter Zijlstra 
> Cc: Pekka Enberg 
> Cc: Russell King 

Acked-by: David Rientjes 
--
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] slab: fix wrong retval on kmem_cache_create_memcg error path

[David Rientjes]

On Sat, 25 Jan 2014, Vladimir Davydov wrote:

> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 8e40321..499b53c 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -249,7 +249,6 @@ out_unlock:
>   name, err);
>   dump_stack();
>   }
> - return NULL;
>   }
>   return s;
>  
> @@ -257,6 +256,7 @@ out_free_cache:
>   memcg_free_cache_params(s);
>   kfree(s->name);
>   kmem_cache_free(kmem_cache, s);
> + s = NULL;
>   goto out_unlock;
>  }
>  

I thought I left spaghetti code back in my BASIC 2.0 days.  It should be 
much more readable to just do

diff --git a/mm/slab_common.c b/mm/slab_common.c
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -233,14 +233,15 @@ out_unlock:
mutex_unlock(_mutex);
put_online_cpus();
 
-   /*
-* There is no point in flooding logs with warnings or especially
-* crashing the system if we fail to create a cache for a memcg. In
-* this case we will be accounting the memcg allocation to the root
-* cgroup until we succeed to create its own cache, but it isn't that
-* critical.
-*/
-   if (err && !memcg) {
+   if (err) {
+   /*
+* There is no point in flooding logs with warnings or
+* especially crashing the system if we fail to create a cache
+* for a memcg.
+*/
+   if (memcg)
+   return NULL;
+
if (flags & SLAB_PANIC)
panic("kmem_cache_create: Failed to create slab '%s'. 
Error %d\n",
name, err);

and stop trying to remember what err, memcg, and s are in all possible 
contexts.  Sheesh.
--
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 4/4] x86, mpx: extend siginfo structure to include bound violation information

[David Rientjes]

On Sun, 26 Jan 2014, Qiaowei Ren wrote:

> This patch adds new fields about bound violation into siginfo
> structure. si_lower and si_upper are respectively lower bound
> and upper bound when bound violation is caused.
> 
> These fields will be set in #BR exception handler by decoding
> the user instruction and constructing the faulting pointer.
> A userspace application can get violation address, lower bound
> and upper bound for bound violation from this new siginfo structure.
> 
> Signed-off-by: Qiaowei Ren 

Same 32-bit warnings I reported for v2:

arch/x86/kernel/mpx.c: In function ‘do_mpx_bounds’:
arch/x86/kernel/mpx.c:407:3: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]
arch/x86/kernel/mpx.c:409:3: warning: cast to pointer from integer of different 
size [-Wint-to-pointer-cast]

and the documentation says you explicitly want to support this config.

These types of warnings are usually indicative of real problems when 
you're storing upper and lower bits in 32-bit fields after casting them 
from 64-bit values.

I'm also not sure if the added fields to the generic struct siginfo can be 
justified for this.

Re: [PATCH] x86, apic: clean up handling of boot_cpu_physical_apicid in boot process

[David Rientjes]

On Thu, 16 Jan 2014, HATAYAMA Daisuke wrote:

> Hello,
> 
> This patch deals with the issue of handling boot_cpu_physical_apicid
> in boot process I avoided in disable_cpu_apicid patch because I
> cannot guess how long it needs to take for the review of this fix.
> 
> This patch is made on top of today's x86/apic branch of tip tree.
> Its commit hash is 5b4d1dbc24bb6fd7179ada0f47be34e27e64decb
> 

This breaks with SGI 320/540:

arch/x86/platform/visws/visws_quirks.c: In function ‘MP_processor_info’:
arch/x86/platform/visws/visws_quirks.c:169:3: error: ‘bios_cpu_physical_apicid’ 
undeclared (first use in this function)
arch/x86/platform/visws/visws_quirks.c:169:3: note: each undeclared identifier 
is reported only once for each function it appears in

It makes it pretty apparent that you want a different name for the new 
variable, bios_bsp_physical_apicid is just too close to 
boot_cpu_physical_apicid that even the author of the patch missed a 
conversion.

(It's also really sad that we can't make it __initdata since it's only 
valid at boot because of the hotplug stuff.)

[patch] mm, oom: base root bonus on current usage

[David Rientjes]

A 3% of system memory bonus is sometimes too excessive in comparison to 
other processes and can yield poor results when all processes on the 
system are root and none of them use over 3% of memory.

Replace the 3% of system memory bonus with a 3% of current memory usage 
bonus.

Reported-by: Johannes Weiner 
Signed-off-by: David Rientjes 
---
 Documentation/filesystems/proc.txt | 4 ++--
 mm/oom_kill.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1386,8 +1386,8 @@ may allocate from based on an estimation of its current 
memory and swap use.
 For example, if a task is using all allowed memory, its badness score will be
 1000.  If it is using half of its allowed memory, its score will be 500.
 
-There is an additional factor included in the badness score: root
-processes are given 3% extra memory over other tasks.
+There is an additional factor included in the badness score: the current memory
+and swap usage is discounted by 3% for root processes.
 
 The amount of "allowed" memory depends on the context in which the oom killer
 was called.  If it is due to the memory assigned to the allocating task's 
cpuset
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -178,7 +178,7 @@ unsigned long oom_badness(struct task_struct *p, struct 
mem_cgroup *memcg,
 * implementation used by LSMs.
 */
if (has_capability_noaudit(p, CAP_SYS_ADMIN))
-   adj -= 30;
+   points -= (points * 3) / 100;
 
/* Normalize to oom_score_adj units */
adj *= totalpages / 1000;
--
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: [Xen-devel] [PATCH 4/4] xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.

[Konrad Rzeszutek Wilk]

"Zhang, Yang Z"  wrote:
>Konrad Rzeszutek Wilk wrote on 2013-11-09:
>> The 'read_reply' works with 'process_msg' to read of a reply in
>XenBus.
>> 'process_msg' is running from within the 'xenbus' thread. Whenever a
>> message shows up in XenBus it is put on a xs_state.reply_list list
>and
>> 'read_reply' picks it up.
>> 
>> The problem is if the backend domain or the xenstored process is
>killed.
>> In which case 'xenbus' is still awaiting - and 'read_reply' if called
>> - stuck forever waiting for the reply_list to have some contents.
>> 
>> This is normally not a problem - as the backend domain can come back
>> or the xenstored process can be restarted. However if the domain is
>in
>> process of being powered off/restarted/halted - there is no point of
>> waiting on it coming back - as we are effectively being terminated
>and
>> should not impede the progress.
>> 
>
>Hi, Konrad,
>
>Is this patch applied in Linux upstream tree? I didn't find it with
>latest Linux upstream source.
>

No. It needs rework.
>> This patch solves this problem by checking the 'system_state' value
>to
>> see if we are in heading towards death. We also make the wait
>> mechanism a bit more asynchronous.
>> 
>> Fixes-Bug: http://bugs.xenproject.org/xen/bug/8
>> Signed-off-by: Konrad Rzeszutek Wilk 
>> ---
>>  drivers/xen/xenbus/xenbus_xs.c | 24 +---
>>  1 file changed, 21 insertions(+), 3 deletions(-)
>> diff --git a/drivers/xen/xenbus/xenbus_xs.c
>> b/drivers/xen/xenbus/xenbus_xs.c index b6d5fff..4f22706 100644
>> --- a/drivers/xen/xenbus/xenbus_xs.c
>> +++ b/drivers/xen/xenbus/xenbus_xs.c
>> @@ -148,9 +148,24 @@ static void *read_reply(enum xsd_sockmsg_type
>> *type, unsigned int *len)
>> 
>>  while (list_empty(_state.reply_list)) {
>>  spin_unlock(_state.reply_lock);
>> -/* XXX FIXME: Avoid synchronous wait for response here. */
>> -wait_event(xs_state.reply_waitq, -
>> !list_empty(_state.reply_list));
>> +wait_event_timeout(xs_state.reply_waitq, +  
>>   
>> !list_empty(_state.reply_list), +
>> msecs_to_jiffies(500)); +
>> +/* + * If we are in the process of being shut-down 
>> there is +   
>*
>> no point of trying to contact XenBus - it is either + * 
>> killed
>> (xenstored application) or the other domain + * has been 
>> killed or
>is
>> unreachable. +*/ +   switch (system_state) { +   
>> case
>SYSTEM_POWER_OFF:
>> +case SYSTEM_RESTART: +  case SYSTEM_HALT: + 
>> return
>ERR_PTR(-EIO);
>> +default: +  break; +}
>>  spin_lock(_state.reply_lock);
>>  }
>> @@ -215,6 +230,9 @@ void *xenbus_dev_request_and_reply(struct
>> xsd_sockmsg *msg)
>> 
>>  mutex_unlock(_state.request_mutex);
>> +if (IS_ERR(ret))
>> +return ret;
>> +
>>  if ((msg->type == XS_TRANSACTION_END) ||
>>  ((req_msg.type == XS_TRANSACTION_START) &&
>>   (msg->type == XS_ERROR)))
>
>
>Best regards,
>Yang


--
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 1/4] x86, mpx: add documentation on Intel MPX

[Ren Qiaowei]

On 01/26/2014 11:06 AM, Randy Dunlap wrote:

On 01/26/2014 01:08 AM, Qiaowei Ren wrote:

This patch adds the Documentation/x86/intel_mpx.txt file with some
information about Intel MPX.

Signed-off-by: Qiaowei Ren 
---
  Documentation/x86/intel_mpx.txt |  226 +++
  1 files changed, 226 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/x86/intel_mpx.txt

diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt
new file mode 100644
index 000..052001c
--- /dev/null
+++ b/Documentation/x86/intel_mpx.txt
@@ -0,0 +1,226 @@
+1. Intel(R) MPX Overview
+
+
+
+Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new
+capability introduced into Intel Architecture. Intel MPX provides
+hardware features that can be used in conjunction with compiler
+changes to check memory references, for those references whose
+compile-time normal intentions are usurped at runtime due to
+buffer overflow or underflow.
+
+Two of the most important goals of Intel MPX are to provide
+this capability at very low performance overhead for newly
+compiled code, and to provide compatibility mechanisms with
+legacy software components. MPX architecture is designed


designed to


+allow a machine (i.e., the processor(s) and the OS software)
+to run both MPX enabled software and legacy software that
+is MPX unaware. In such a case, the legacy software does not
+benefit from MPX, but it also does not experience any change
+in functionality or reduction in performance.
+
+Intel(R) MPX Programming Model
+--
+
+Intel MPX introduces new registers and new instructions that
+operate on these registers. Some of the registers added are
+bounds registers which store a pointer's lower bound and upper
+bound limits. Whenever the pointer is used, the requested
+reference is checked against the pointer's associated bounds,
+thereby preventing out-of-bound memory access (such as buffer
+overflows and overruns). Out-of-bounds memory references
+initiate a #BR exception which can then be handled in an
+appropriate manner.
+
+Loading and Storing Bounds using Translation
+
+
+Intel MPX defines two instructions for load/store of the linear
+address of a pointer to a buffer, along with the bounds of the
+buffer into a paging structure of extended bounds. Specifically
+when storing extended bounds, the processor will perform address
+translation of the address where the pointer is stored to an
+address in the Bound Table (BT) to determine the store location
+of extended bounds. Loading of an extended bounds performs the
+reverse sequence.
+
+The structure in memory to load/store an extended bound is a
+4-tuple consisting of lower bound, upper bound, pointer value
+and a reserved field. Bound loads and stores access 32-bit or
+64-bit operand size according to the operation mode. Thus,
+a bound table entry is 4*32 bits in 32-bit mode and 4*64 bits
+in 64-bit mode.
+
+The linear address of a bound table is stored in a Bound
+Directory (BD) entry. And the linear address of the bound


  The linear address


+directory is derived from either BNDCFGU or BNDCFGS registers.
+Bounds in memory are stored in Bound Tables (BT) as an extended
+bound, which are accessed via Bound Directory (BD) and address
+translation performed by BNDLDX/BNDSTX instructions.
+
+Bounds Directory (BD) and Bounds Tables (BT) are stored in
+application memory and are allocated by the application (in case
+of kernel use, the structures will be in kernel memory). The
+bound directory and each instance of bound table are in contiguous
+linear memory.
+
+XSAVE/XRESTOR Support of Intel MPX State
+
+
+Enabling Intel MPX requires an OS to manage two bits in XCR0:
+  - BNDREGS for saving and restoring registers BND0-BND3,
+  - BNDCSR for saving and restoring the user-mode configuration
+(BNDCFGU) and the status register (BNDSTATUS).
+
+The reason for having two separate bits is that BND0-BND3 is


  are


+likely to be volatile state, while BNDCFGU and BNDSTATUS are not.
+Therefore, an OS has flexibility in handling these two states
+differently in saving or restoring them.
+
+For details about the Intel MPX instructions, see "Intel(R)
+Architecture Instruction Set Extensions Programming Reference".
+
+
+2. How to get the advantage of MPX


drop trailing space above.


+==
+
+
+To get the advantage of MPX, changes are required in
+the OS kernel, binutils, compiler, system libraries support.


   and system libraries support.


+
+MPX support in the GNU toolchain
+
+
+This section describes changes in GNU Binutils, GCC and Glibc
+to support MPX.
+
+The first step 

RE: [PATCH] cpufreq: Align all CPUs to the same frequency if using shared clock

[Li, Zhuangzhi]

> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Wednesday, January 22, 2014 2:43 PM
> To: Li, Zhuangzhi
> Cc: Rafael J. Wysocki; cpuf...@vger.kernel.org; linux...@vger.kernel.org;
> Linux Kernel Mailing List; Liu, Chuansheng
> Subject: Re: [PATCH] cpufreq: Align all CPUs to the same frequency if using
> shared clock
> 
> On 22 January 2014 11:56, Li, Zhuangzhi  wrote:
> > I don't think it's a real bug in bootloader, the bootloader can set
> > CPUs to different frequencies according to actually requirements(Power
> > saving first or Performance first), the CPUs freq policy are initialized in 
> > kernel,
> if the kernel want to share one CPU policy(using CPUFREQ_SHARED_TYPE_ALL
> type), it should ensure all CPUs frequencies aligned first, don't depend on 
> the
> bootloader CPUs Pre-states, then the kernel can have better compatibility.
> >
> > If the kernel uses CPUFREQ_SHARED_TYPE_ALL policy, the patch can ensure
> these:
> > 1. If all CPUs are in the same P-state, it does nothing when cpufreq
> > registering 2. If the CPUs are in different P-states, all the other CPUs are
> aligned once to current frequency of CPU0 according to the present policy.
> 
> I thought, as you are asking kernel to keep same freq on all of them, then 
> same
> should be true for bootloaders.
> 
> Otherwise it was okay.
Yes, but most of the platforms(ARM) only enable one CPU Core in bootloader 
or Bios because of multiple threads(SMP) are not supported, 
and the other Cores stay in default configuration for saving power in 
bootloader, kernel is responsible for booting up the other Cores from default 
frequencies for SMP.
Cpufreq driver need to init them to required P-state before governor active 
when using CPUFREQ_SHARED_TYPE_ALL policy.
--
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 for-3.14] mm, mempolicy: fix mempolicy printing in numa_maps

[David Rientjes]

As a result of commit 5606e3877ad8 ("mm: numa: Migrate on reference 
policy"), /proc//numa_maps prints the mempolicy for any  as 
"prefer:N" for the local node, N, of the process reading the file.

This should only be printed when the mempolicy of  is MPOL_PREFERRED 
for node N.

If the process is actually only using the default mempolicy for local node 
allocation, make sure "default" is printed as expected.

Reported-by: Robert Lippert 
Signed-off-by: David Rientjes 
---
 This affects all 3.7+ kernels and is intended for stable but will need to
 be rebased after it's merged since mpol_to_str() has subsequently
 changed.  I'll rebase and propose it separately.

 mm/mempolicy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2926,7 +2926,7 @@ void mpol_to_str(char *buffer, int maxlen, struct 
mempolicy *pol)
unsigned short mode = MPOL_DEFAULT;
unsigned short flags = 0;
 
-   if (pol && pol != _policy) {
+   if (pol && pol != _policy && !(pol->flags & MPOL_F_MORON)) {
mode = pol->mode;
flags = pol->flags;
}
--
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.4 05/12] hwmon: (coretemp) Fix truncated name of alarm attributes

[Greg Kroah-Hartman]

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

--

From: Jean Delvare 

commit 3f9aec7610b39521c7c69d754de7265f6994c194 upstream.

When the core number exceeds 9, the size of the buffer storing the
alarm attribute name is insufficient and the attribute name is
truncated. This causes libsensors to skip these attributes as the
truncated name is not recognized.

Reported-by: Andreas Hollmann 
Signed-off-by: Jean Delvare 
Signed-off-by: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/hwmon/coretemp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -53,7 +53,7 @@ MODULE_PARM_DESC(tjmax, "TjMax value in
 
 #define BASE_SYSFS_ATTR_NO 2   /* Sysfs Base attr no for coretemp */
 #define NUM_REAL_CORES 32  /* Number of Real cores per cpu */
-#define CORETEMP_NAME_LENGTH   17  /* String Length of attrs */
+#define CORETEMP_NAME_LENGTH   19  /* String Length of attrs */
 #define MAX_CORE_ATTRS 4   /* Maximum no of basic attrs */
 #define TOTAL_ATTRS(MAX_CORE_ATTRS + 1)
 #define MAX_CORE_DATA  (NUM_REAL_CORES + BASE_SYSFS_ATTR_NO)


--
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.4 00/12] 3.4.78-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.4.78 release.
There are 12 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue Jan 28 03:04:41 UTC 2014.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.78-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.4.78-rc1

Dan Carpenter 
staging: wlags49_h2: buffer overflow setting station name

Jon Medhurst 
serial: amba-pl011: use port lock to guard control register access

NeilBrown 
md/raid5: Fix possible confusion when multiple write errors occur.

NeilBrown 
md/raid10: fix two bugs in handling of known-bad-blocks.

NeilBrown 
md/raid10: fix bug when raid10 recovery fails to recover a block.

Andreas Rohner 
nilfs2: fix segctor bug that causes file system corruption

Steven Rostedt 
SELinux: Fix possible NULL pointer dereference in selinux_inode_permission()

Jean Delvare 
hwmon: (coretemp) Fix truncated name of alarm attributes

Jianguo Wu 
mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate 
successfully

Robert Richter 
perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h

Ian Abbott 
staging: comedi: 8255_pci: fix for newer PCI-DIO48H

Andy Honig 
KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368)


-

Diffstat:

 Makefile   |  4 +--
 arch/x86/kernel/cpu/perf_event_amd_ibs.c   | 53 +-
 arch/x86/kvm/lapic.c   | 24 --
 arch/x86/kvm/lapic.h   |  4 +--
 arch/x86/kvm/x86.c | 33 +--
 drivers/hwmon/coretemp.c   |  2 +-
 drivers/md/raid10.c| 12 +++
 drivers/md/raid5.c |  4 +--
 drivers/staging/comedi/drivers/cb_pcidio.c | 21 +---
 drivers/staging/wlags49_h2/wl_priv.c   |  8 +++--
 drivers/tty/serial/amba-pl011.c|  6 
 fs/nilfs2/segment.c| 10 +++---
 mm/memory-failure.c| 16 ++---
 security/selinux/hooks.c   | 20 +--
 security/selinux/include/objsec.h  |  5 ++-
 15 files changed, 133 insertions(+), 89 deletions(-)


--
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.4 04/12] mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate successfully

[Greg Kroah-Hartman]

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

--

From: Jianguo Wu 

commit a49ecbcd7b0d5a1cda7d60e03df402dd0ef76ac8 upstream.

After a successful hugetlb page migration by soft offline, the source
page will either be freed into hugepage_freelists or buddy(over-commit
page).  If page is in buddy, page_hstate(page) will be NULL.  It will
hit a NULL pointer dereference in dequeue_hwpoisoned_huge_page().

  BUG: unable to handle kernel NULL pointer dereference at 0058
  IP: [] dequeue_hwpoisoned_huge_page+0x131/0x1d0
  PGD c23762067 PUD c24be2067 PMD 0
  Oops:  [#1] SMP

So check PageHuge(page) after call migrate_pages() successfully.

[wujg: backport to 3.4:
 - adjust context
 - s/num_poisoned_pages/mce_bad_pages/]

Signed-off-by: Jianguo Wu 
Tested-by: Naoya Horiguchi 
Reviewed-by: Naoya Horiguchi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 


---
 mm/memory-failure.c |   16 
 1 file changed, 12 insertions(+), 4 deletions(-)

--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1447,10 +1447,18 @@ static int soft_offline_huge_page(struct
return ret;
}
 done:
-   if (!PageHWPoison(hpage))
-   atomic_long_add(1 << compound_trans_order(hpage), 
_bad_pages);
-   set_page_hwpoison_huge_page(hpage);
-   dequeue_hwpoisoned_huge_page(hpage);
+   /* overcommit hugetlb page will be freed to buddy */
+   if (PageHuge(hpage)) {
+   if (!PageHWPoison(hpage))
+   atomic_long_add(1 << compound_trans_order(hpage),
+   _bad_pages);
+   set_page_hwpoison_huge_page(hpage);
+   dequeue_hwpoisoned_huge_page(hpage);
+   } else {
+   SetPageHWPoison(page);
+   atomic_long_inc(_bad_pages);
+   }
+
/* keep elevated page count for bad page */
return ret;
 }


--
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.4 07/12] nilfs2: fix segctor bug that causes file system corruption

[Greg Kroah-Hartman]

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

--

From: Andreas Rohner 

commit 70f2fe3a26248724d8a5019681a869abdaf3e89a upstream.

There is a bug in the function nilfs_segctor_collect, which results in
active data being written to a segment, that is marked as clean.  It is
possible, that this segment is selected for a later segment
construction, whereby the old data is overwritten.

The problem shows itself with the following kernel log message:

  nilfs_sufile_do_cancel_free: segment 6533 must be clean

Usually a few hours later the file system gets corrupted:

  NILFS: bad btree node (blocknr=8748107): level = 0, flags = 0x0, nchildren = 0
  NILFS error (device sdc1): nilfs_bmap_last_key: broken bmap (inode 
number=114660)

The issue can be reproduced with a file system that is nearly full and
with the cleaner running, while some IO intensive task is running.
Although it is quite hard to reproduce.

This is what happens:

 1. The cleaner starts the segment construction
 2. nilfs_segctor_collect is called
 3. sc_stage is on NILFS_ST_SUFILE and segments are freed
 4. sc_stage is on NILFS_ST_DAT current segment is full
 5. nilfs_segctor_extend_segments is called, which
allocates a new segment
 6. The new segment is one of the segments freed in step 3
 7. nilfs_sufile_cancel_freev is called and produces an error message
 8. Loop around and the collection starts again
 9. sc_stage is on NILFS_ST_SUFILE and segments are freed
including the newly allocated segment, which will contain active
data and can be allocated at a later time
10. A few hours later another segment construction allocates the
segment and causes file system corruption

This can be prevented by simply reordering the statements.  If
nilfs_sufile_cancel_freev is called before nilfs_segctor_extend_segments
the freed segments are marked as dirty and cannot be allocated any more.

Signed-off-by: Andreas Rohner 
Reviewed-by: Ryusuke Konishi 
Tested-by: Andreas Rohner 
Signed-off-by: Ryusuke Konishi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nilfs2/segment.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -1436,17 +1436,19 @@ static int nilfs_segctor_collect(struct
 
nilfs_clear_logs(>sc_segbufs);
 
-   err = nilfs_segctor_extend_segments(sci, nilfs, nadd);
-   if (unlikely(err))
-   return err;
-
if (sci->sc_stage.flags & NILFS_CF_SUFREED) {
err = nilfs_sufile_cancel_freev(nilfs->ns_sufile,
sci->sc_freesegs,
sci->sc_nfreesegs,
NULL);
WARN_ON(err); /* do not happen */
+   sci->sc_stage.flags &= ~NILFS_CF_SUFREED;
}
+
+   err = nilfs_segctor_extend_segments(sci, nilfs, nadd);
+   if (unlikely(err))
+   return err;
+
nadd = min_t(int, nadd << 1, SC_MAX_SEGDELTA);
sci->sc_stage = prev_stage;
}


--
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.4 08/12] md/raid10: fix bug when raid10 recovery fails to recover a block.

[Greg Kroah-Hartman]

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

--

From: NeilBrown 

commit e8b849158508565e0cd6bc80061124afc5879160 upstream.

commit e875ecea266a543e643b19e44cf472f1412708f9
md/raid10 record bad blocks as needed during recovery.

added code to the "cannot recover this block" path to record a bad
block rather than fail the whole recovery.
Unfortunately this new case was placed *after* r10bio was freed rather
than *before*, yet it still uses r10bio.
This is will crash with a null dereference.

So move the freeing of r10bio down where it is safe.

Fixes: e875ecea266a543e643b19e44cf472f1412708f9
Reported-by: Damian Nowak 
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid10.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2943,10 +2943,6 @@ static sector_t sync_request(struct mdde
if (j == conf->copies) {
/* Cannot recover, so abort the recovery or
 * record a bad block */
-   put_buf(r10_bio);
-   if (rb2)
-   atomic_dec(>remaining);
-   r10_bio = rb2;
if (any_working) {
/* problem is that there are bad blocks
 * on other device(s)
@@ -2978,6 +2974,10 @@ static sector_t sync_request(struct mdde
mirror->recovery_disabled
= mddev->recovery_disabled;
}
+   put_buf(r10_bio);
+   if (rb2)
+   atomic_dec(>remaining);
+   r10_bio = rb2;
break;
}
}


--
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.4 06/12] SELinux: Fix possible NULL pointer dereference in selinux_inode_permission()

[Greg Kroah-Hartman]

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

--

From: Steven Rostedt 

commit 3dc91d4338d698ce77832985f9cb183d8eeaf6be upstream.

While running stress tests on adding and deleting ftrace instances I hit
this bug:

  BUG: unable to handle kernel NULL pointer dereference at 0020
  IP: selinux_inode_permission+0x85/0x160
  PGD 63681067 PUD 7ddbe067 PMD 0
  Oops:  [#1] PREEMPT
  CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 
3.13.0-rc4-test-00033-gd2a6dde-dirty #20
  Hardware name:  /DG965MQ, BIOS 
MQ96510J.86A.0372.2006.0605.1717 06/05/2006
  task: 880078375800 ti: 88007ddb task.ti: 88007ddb
  RIP: 0010:[]  [] 
selinux_inode_permission+0x85/0x160
  RSP: 0018:88007ddb1c48  EFLAGS: 00010246
  RAX:  RBX: 0080 RCX: 88006dd43840
  RDX: 0001 RSI: 0081 RDI: 88006ee46000
  RBP: 88007ddb1c88 R08:  R09: 88007ddb1c54
  R10: 6e6576652f6f6f66 R11: 0003 R12: 
  R13: 0081 R14: 88006ee46000 R15: 
  FS:  7f217b5b6700() GS:81e21000() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033^M
  CR2: 0020 CR3: 6a0fe000 CR4: 07f0
  Call Trace:
security_inode_permission+0x1c/0x30
__inode_permission+0x41/0xa0
inode_permission+0x18/0x50
link_path_walk+0x66/0x920
path_openat+0xa6/0x6c0
do_filp_open+0x43/0xa0
do_sys_open+0x146/0x240
SyS_open+0x1e/0x20
system_call_fastpath+0x16/0x1b
  Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 
f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 
48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
  RIP  selinux_inode_permission+0x85/0x160
  CR2: 0020

Investigating, I found that the inode->i_security was NULL, and the
dereference of it caused the oops.

in selinux_inode_permission():

isec = inode->i_security;

rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, );

Note, the crash came from stressing the deletion and reading of debugfs
files.  I was not able to recreate this via normal files.  But I'm not
sure they are safe.  It may just be that the race window is much harder
to hit.

What seems to have happened (and what I have traced), is the file is
being opened at the same time the file or directory is being deleted.
As the dentry and inode locks are not held during the path walk, nor is
the inodes ref counts being incremented, there is nothing saving these
structures from being discarded except for an rcu_read_lock().

The rcu_read_lock() protects against freeing of the inode, but it does
not protect freeing of the inode_security_struct.  Now if the freeing of
the i_security happens with a call_rcu(), and the i_security field of
the inode is not changed (it gets freed as the inode gets freed) then
there will be no issue here.  (Linus Torvalds suggested not setting the
field to NULL such that we do not need to check if it is NULL in the
permission check).

Note, this is a hack, but it fixes the problem at hand.  A real fix is
to restructure the destroy_inode() to call all the destructor handlers
from the RCU callback.  But that is a major job to do, and requires a
lot of work.  For now, we just band-aid this bug with this fix (it
works), and work on a more maintainable solution in the future.

Link: http://lkml.kernel.org/r/20140109101932.0508d...@gandalf.local.home
Link: http://lkml.kernel.org/r/20140109182756.17aba...@gandalf.local.home

Signed-off-by: Steven Rostedt 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

---
 security/selinux/hooks.c  |   20 ++--
 security/selinux/include/objsec.h |5 -
 2 files changed, 22 insertions(+), 3 deletions(-)

--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -218,6 +218,14 @@ static int inode_alloc_security(struct i
return 0;
 }
 
+static void inode_free_rcu(struct rcu_head *head)
+{
+   struct inode_security_struct *isec;
+
+   isec = container_of(head, struct inode_security_struct, rcu);
+   kmem_cache_free(sel_inode_cache, isec);
+}
+
 static void inode_free_security(struct inode *inode)
 {
struct inode_security_struct *isec = inode->i_security;
@@ -228,8 +236,16 @@ static void inode_free_security(struct i
list_del_init(>list);
spin_unlock(>isec_lock);
 
-   inode->i_security = NULL;
-   kmem_cache_free(sel_inode_cache, isec);
+   /*
+* The inode may still be referenced in a path walk and
+* a call to selinux_inode_permission() can be made
+* after inode_free_security() is called. Ideally, the VFS
+* wouldn't do this, but fixing that is a much harder
+* job. For now, simply free the i_security via RCU, and
+* leave the current 

Re: [PATCH v3 1/4] x86, mpx: add documentation on Intel MPX

[Randy Dunlap]

On 01/26/2014 01:08 AM, Qiaowei Ren wrote:
> This patch adds the Documentation/x86/intel_mpx.txt file with some
> information about Intel MPX.
> 
> Signed-off-by: Qiaowei Ren 
> ---
>  Documentation/x86/intel_mpx.txt |  226 
> +++
>  1 files changed, 226 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/x86/intel_mpx.txt
> 
> diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt
> new file mode 100644
> index 000..052001c
> --- /dev/null
> +++ b/Documentation/x86/intel_mpx.txt
> @@ -0,0 +1,226 @@
> +1. Intel(R) MPX Overview
> +
> +
> +
> +Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new
> +capability introduced into Intel Architecture. Intel MPX provides
> +hardware features that can be used in conjunction with compiler
> +changes to check memory references, for those references whose
> +compile-time normal intentions are usurped at runtime due to
> +buffer overflow or underflow.
> +
> +Two of the most important goals of Intel MPX are to provide
> +this capability at very low performance overhead for newly
> +compiled code, and to provide compatibility mechanisms with
> +legacy software components. MPX architecture is designed

   designed to

> +allow a machine (i.e., the processor(s) and the OS software)
> +to run both MPX enabled software and legacy software that
> +is MPX unaware. In such a case, the legacy software does not
> +benefit from MPX, but it also does not experience any change
> +in functionality or reduction in performance.
> +
> +Intel(R) MPX Programming Model
> +--
> +
> +Intel MPX introduces new registers and new instructions that
> +operate on these registers. Some of the registers added are
> +bounds registers which store a pointer's lower bound and upper
> +bound limits. Whenever the pointer is used, the requested
> +reference is checked against the pointer's associated bounds,
> +thereby preventing out-of-bound memory access (such as buffer
> +overflows and overruns). Out-of-bounds memory references
> +initiate a #BR exception which can then be handled in an
> +appropriate manner.
> +
> +Loading and Storing Bounds using Translation
> +
> +
> +Intel MPX defines two instructions for load/store of the linear
> +address of a pointer to a buffer, along with the bounds of the
> +buffer into a paging structure of extended bounds. Specifically
> +when storing extended bounds, the processor will perform address
> +translation of the address where the pointer is stored to an
> +address in the Bound Table (BT) to determine the store location
> +of extended bounds. Loading of an extended bounds performs the
> +reverse sequence.
> +
> +The structure in memory to load/store an extended bound is a
> +4-tuple consisting of lower bound, upper bound, pointer value
> +and a reserved field. Bound loads and stores access 32-bit or
> +64-bit operand size according to the operation mode. Thus,
> +a bound table entry is 4*32 bits in 32-bit mode and 4*64 bits
> +in 64-bit mode.
> +
> +The linear address of a bound table is stored in a Bound
> +Directory (BD) entry. And the linear address of the bound

 The linear address

> +directory is derived from either BNDCFGU or BNDCFGS registers.
> +Bounds in memory are stored in Bound Tables (BT) as an extended
> +bound, which are accessed via Bound Directory (BD) and address
> +translation performed by BNDLDX/BNDSTX instructions.
> +
> +Bounds Directory (BD) and Bounds Tables (BT) are stored in
> +application memory and are allocated by the application (in case
> +of kernel use, the structures will be in kernel memory). The
> +bound directory and each instance of bound table are in contiguous
> +linear memory.
> +
> +XSAVE/XRESTOR Support of Intel MPX State
> +
> +
> +Enabling Intel MPX requires an OS to manage two bits in XCR0:
> +  - BNDREGS for saving and restoring registers BND0-BND3,
> +  - BNDCSR for saving and restoring the user-mode configuration
> +(BNDCFGU) and the status register (BNDSTATUS).
> +
> +The reason for having two separate bits is that BND0-BND3 is

 are

> +likely to be volatile state, while BNDCFGU and BNDSTATUS are not.
> +Therefore, an OS has flexibility in handling these two states
> +differently in saving or restoring them.
> +
> +For details about the Intel MPX instructions, see "Intel(R)
> +Architecture Instruction Set Extensions Programming Reference".
> +
> +
> +2. How to get the advantage of MPX 

drop trailing space above.

> +==
> +
> +
> +To get the advantage of MPX, changes are required in
> +the OS kernel, binutils, compiler, system libraries support.

  and system libraries support.

> +
> +MPX support in 

[PATCH 3.4 09/12] md/raid10: fix two bugs in handling of known-bad-blocks.

[Greg Kroah-Hartman]

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

--

From: NeilBrown 

commit b50c259e25d9260b9108dc0c2964c26e5ecbe1c1 upstream.

If we discover a bad block when reading we split the request and
potentially read some of it from a different device.

The code path of this has two bugs in RAID10.
1/ we get a spin_lock with _irq, but unlock without _irq!!
2/ The calculation of 'sectors_handled' is wrong, as can be clearly
   seen by comparison with raid1.c

This leads to at least 2 warnings and a probable crash is a RAID10
ever had known bad blocks.

Fixes: 856e08e23762dfb92ffc68fd0a8d228f9e152160
Reported-by: Damian Nowak 
URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid10.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1117,7 +1117,7 @@ read_again:
/* Could not read all from this device, so we will
 * need another r10_bio.
 */
-   sectors_handled = (r10_bio->sectors + max_sectors
+   sectors_handled = (r10_bio->sector + max_sectors
   - bio->bi_sector);
r10_bio->sectors = max_sectors;
spin_lock_irq(>device_lock);
@@ -1125,7 +1125,7 @@ read_again:
bio->bi_phys_segments = 2;
else
bio->bi_phys_segments++;
-   spin_unlock(>device_lock);
+   spin_unlock_irq(>device_lock);
/* Cannot call generic_make_request directly
 * as that will be queued in __generic_make_request
 * and subsequent mempool_alloc might block


--
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.4 02/12] staging: comedi: 8255_pci: fix for newer PCI-DIO48H

[Greg Kroah-Hartman]

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

--

From: Ian Abbott 

commit 0283f7a100882684ad32b768f9f1ad81658a0b92 upstream.

At some point, Measurement Computing / ComputerBoards redesigned the
PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip.
This meant they had to put their hardware registers in the PCI BAR 2
region instead of PCI BAR 1.  Unfortunately, they kept the same PCI
device ID for the new design.  This means the driver recognizes the
newer cards, but doesn't work (and is likely to screw up the local
configuration registers of the PLX chip) because it's using the wrong
region.

Since  the PCI subvendor and subdevice IDs were both zero on the old
design, but are the same as the vendor and device on the new design, we
can tell the old design and new design apart easily enough.  Split the
existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new
entries, referenced by different entries in the PCI device ID table
`pci_8255_pci_table[]`.  Use the same board name for both entries.

Signed-off-by: Ian Abbott 
Acked-by: H Hartley Sweeten 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/staging/comedi/drivers/cb_pcidio.c |   21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

--- a/drivers/staging/comedi/drivers/cb_pcidio.c
+++ b/drivers/staging/comedi/drivers/cb_pcidio.c
@@ -56,10 +56,6 @@ struct pcidio_board {
const char *name;   /*  name of the board */
int dev_id;
int n_8255; /*  number of 8255 chips on board */
-
-   /*  indices of base address regions */
-   int pcicontroler_badrindex;
-   int dioregs_badrindex;
 };
 
 static const struct pcidio_board pcidio_boards[] = {
@@ -67,22 +63,16 @@ static const struct pcidio_board pcidio_
 .name = "pci-dio24",
 .dev_id = 0x0028,
 .n_8255 = 1,
-.pcicontroler_badrindex = 1,
-.dioregs_badrindex = 2,
 },
{
 .name = "pci-dio24h",
 .dev_id = 0x0014,
 .n_8255 = 1,
-.pcicontroler_badrindex = 1,
-.dioregs_badrindex = 2,
 },
{
 .name = "pci-dio48h",
 .dev_id = 0x000b,
 .n_8255 = 2,
-.pcicontroler_badrindex = 0,
-.dioregs_badrindex = 1,
 },
 };
 
@@ -239,10 +229,15 @@ found:
if (comedi_pci_enable(pcidev, thisboard->name))
return -EIO;
 
-   devpriv->dio_reg_base
-   =
+   /*
+* Use PCI BAR 2 region if non-zero length, else use PCI BAR 1 region.
+* PCI BAR 1 is only used for older PCI-DIO48H boards.  At some point
+* the PCI-DIO48H was redesigned to use the same PCI interface chip
+* (and same PCI BAR region) as the other boards.
+*/
+   devpriv->dio_reg_base =
pci_resource_start(devpriv->pci_dev,
-  pcidio_boards[index].dioregs_badrindex);
+  (pci_resource_len(pcidev, 2) ? 2 : 1));
 
 /*
  * Allocate the subdevice structures.  alloc_subdevice() is a


--
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.4 01/12] KVM: x86: Convert vapic synchronization to _cached functions (CVE-2013-6368)

[Greg Kroah-Hartman]

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

--

From: Andy Honig 

commit fda4e2e85589191b123d31cdc21fd33ee70f50fd upstream.

In kvm_lapic_sync_from_vapic and kvm_lapic_sync_to_vapic there is the
potential to corrupt kernel memory if userspace provides an address that
is at the end of a page.  This patches concerts those functions to use
kvm_write_guest_cached and kvm_read_guest_cached.  It also checks the
vapic_address specified by userspace during ioctl processing and returns
an error to userspace if the address is not a valid GPA.

This is generally not guest triggerable, because the required write is
done by firmware that runs before the guest.  Also, it only affects AMD
processors and oldish Intel that do not have the FlexPriority feature
(unless you disable FlexPriority, of course; then newer processors are
also affected).

Fixes: b93463aa59d6 ('KVM: Accelerated apic support')

Reported-by: Andrew Honig 
Cc: sta...@vger.kernel.org
Signed-off-by: Andrew Honig 
Signed-off-by: Paolo Bonzini 
[ lizf: backported to 3.4: based on Paolo's backport hints for <3.10 ]
Signed-off-by: Li Zefan 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kvm/lapic.c |   24 ++--
 arch/x86/kvm/lapic.h |4 ++--
 arch/x86/kvm/x86.c   |   33 +
 3 files changed, 17 insertions(+), 44 deletions(-)

--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1278,14 +1278,12 @@ void __kvm_migrate_apic_timer(struct kvm
 void kvm_lapic_sync_from_vapic(struct kvm_vcpu *vcpu)
 {
u32 data;
-   void *vapic;
 
if (!irqchip_in_kernel(vcpu->kvm) || !vcpu->arch.apic->vapic_addr)
return;
 
-   vapic = kmap_atomic(vcpu->arch.apic->vapic_page);
-   data = *(u32 *)(vapic + offset_in_page(vcpu->arch.apic->vapic_addr));
-   kunmap_atomic(vapic);
+   kvm_read_guest_cached(vcpu->kvm, >arch.apic->vapic_cache, ,
+ sizeof(u32));
 
apic_set_tpr(vcpu->arch.apic, data & 0xff);
 }
@@ -1295,7 +1293,6 @@ void kvm_lapic_sync_to_vapic(struct kvm_
u32 data, tpr;
int max_irr, max_isr;
struct kvm_lapic *apic;
-   void *vapic;
 
if (!irqchip_in_kernel(vcpu->kvm) || !vcpu->arch.apic->vapic_addr)
return;
@@ -1310,17 +1307,24 @@ void kvm_lapic_sync_to_vapic(struct kvm_
max_isr = 0;
data = (tpr & 0xff) | ((max_isr & 0xf0) << 8) | (max_irr << 24);
 
-   vapic = kmap_atomic(vcpu->arch.apic->vapic_page);
-   *(u32 *)(vapic + offset_in_page(vcpu->arch.apic->vapic_addr)) = data;
-   kunmap_atomic(vapic);
+   kvm_write_guest_cached(vcpu->kvm, >arch.apic->vapic_cache, ,
+  sizeof(u32));
 }
 
-void kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr)
+int kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr)
 {
if (!irqchip_in_kernel(vcpu->kvm))
-   return;
+   return -EINVAL;
+
+   if (vapic_addr) {
+   if (kvm_gfn_to_hva_cache_init(vcpu->kvm,
+   >arch.apic->vapic_cache,
+   vapic_addr, sizeof(u32)))
+   return -EINVAL;
+   }
 
vcpu->arch.apic->vapic_addr = vapic_addr;
+   return 0;
 }
 
 int kvm_x2apic_msr_write(struct kvm_vcpu *vcpu, u32 msr, u64 data)
--- a/arch/x86/kvm/lapic.h
+++ b/arch/x86/kvm/lapic.h
@@ -15,7 +15,7 @@ struct kvm_lapic {
bool irr_pending;
void *regs;
gpa_t vapic_addr;
-   struct page *vapic_page;
+   struct gfn_to_hva_cache vapic_cache;
 };
 int kvm_create_lapic(struct kvm_vcpu *vcpu);
 void kvm_free_lapic(struct kvm_vcpu *vcpu);
@@ -46,7 +46,7 @@ int kvm_lapic_find_highest_irr(struct kv
 u64 kvm_get_lapic_tscdeadline_msr(struct kvm_vcpu *vcpu);
 void kvm_set_lapic_tscdeadline_msr(struct kvm_vcpu *vcpu, u64 data);
 
-void kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr);
+int kvm_lapic_set_vapic_addr(struct kvm_vcpu *vcpu, gpa_t vapic_addr);
 void kvm_lapic_sync_from_vapic(struct kvm_vcpu *vcpu);
 void kvm_lapic_sync_to_vapic(struct kvm_vcpu *vcpu);
 
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2728,8 +2728,7 @@ long kvm_arch_vcpu_ioctl(struct file *fi
r = -EFAULT;
if (copy_from_user(, argp, sizeof va))
goto out;
-   r = 0;
-   kvm_lapic_set_vapic_addr(vcpu, va.vapic_addr);
+   r = kvm_lapic_set_vapic_addr(vcpu, va.vapic_addr);
break;
}
case KVM_X86_SETUP_MCE: {
@@ -5075,33 +5074,6 @@ static void post_kvm_run_save(struct kvm
!kvm_event_needs_reinjection(vcpu);
 }
 
-static void vapic_enter(struct kvm_vcpu *vcpu)
-{
-   struct kvm_lapic *apic = vcpu->arch.apic;
-   struct page *page;
-
-   if (!apic || !apic->vapic_addr)
-   return;
-
-   

[PATCH 3.4 11/12] serial: amba-pl011: use port lock to guard control register access

[Greg Kroah-Hartman]

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

--

From: Jon Medhurst 

commit fe43390702a1b5741fdf217063b05c7612b38303 upstream.

When the pl011 is being used for a console, pl011_console_write forces
the control register (CR) to enable the UART for transmission and then
restores this to the original value afterwards. It does this while
holding the port lock.

Unfortunately, when the uart is started or shutdown - say in response to
userland using the serial device for a terminal - then this updates the
control register without any locking.

This means we can have

  pl011_console_write   Save CR
  pl011_startup Initialise CR, e.g. enable receive
  pl011_console_write   Restore old CR with receive not enabled

this result is a serial port which doesn't respond to any input.

A similar race in reverse could happen when the device is shutdown.

We can fix these problems by taking the port lock when updating CR.

Signed-off-by: Jon Medhurst 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/tty/serial/amba-pl011.c |6 ++
 1 file changed, 6 insertions(+)

--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -1413,6 +1413,8 @@ static int pl011_startup(struct uart_por
/*
 * Provoke TX FIFO interrupt into asserting.
 */
+   spin_lock_irq(>port.lock);
+
cr = UART01x_CR_UARTEN | UART011_CR_TXE | UART011_CR_LBE;
writew(cr, uap->port.membase + UART011_CR);
writew(0, uap->port.membase + UART011_FBRD);
@@ -1437,6 +1439,8 @@ static int pl011_startup(struct uart_por
cr |= UART01x_CR_UARTEN | UART011_CR_RXE | UART011_CR_TXE;
writew(cr, uap->port.membase + UART011_CR);
 
+   spin_unlock_irq(>port.lock);
+
/*
 * initialise the old status of the modem signals
 */
@@ -1516,11 +1520,13 @@ static void pl011_shutdown(struct uart_p
 * it during startup().
 */
uap->autorts = false;
+   spin_lock_irq(>port.lock);
cr = readw(uap->port.membase + UART011_CR);
uap->old_cr = cr;
cr &= UART011_CR_RTS | UART011_CR_DTR;
cr |= UART01x_CR_UARTEN | UART011_CR_TXE;
writew(cr, uap->port.membase + UART011_CR);
+   spin_unlock_irq(>port.lock);
 
/*
 * disable break condition and fifos


--
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.4 10/12] md/raid5: Fix possible confusion when multiple write errors occur.

[Greg Kroah-Hartman]

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

--

From: NeilBrown 

commit 1cc03eb93245e63b0b7a7832165efdc52e25b4e6 upstream.

commit 5d8c71f9e5fbdd95650be00294d238e27a363b5c
md: raid5 crash during degradation

Fixed a crash in an overly simplistic way which could leave
R5_WriteError or R5_MadeGood set in the stripe cache for devices
for which it is no longer relevant.
When those devices are removed and spares added the flags are still
set and can cause incorrect behaviour.

commit 14a75d3e07c784c004b4b44b34af996b8e4ac453
md/raid5: preferentially read from replacement device if possible.

Fixed the same bug if a more effective way, so we can now revert
the original commit.

Reported-and-tested-by: Alexander Lyakas 
Fixes: 5d8c71f9e5fbdd95650be00294d238e27a363b5c
Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/raid5.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3238,7 +3238,7 @@ static void analyse_stripe(struct stripe
 */
set_bit(R5_Insync, >flags);
 
-   if (rdev && test_bit(R5_WriteError, >flags)) {
+   if (test_bit(R5_WriteError, >flags)) {
/* This flag does not apply to '.replacement'
 * only to .rdev, so make sure to check that*/
struct md_rdev *rdev2 = rcu_dereference(
@@ -3251,7 +3251,7 @@ static void analyse_stripe(struct stripe
} else
clear_bit(R5_WriteError, >flags);
}
-   if (rdev && test_bit(R5_MadeGood, >flags)) {
+   if (test_bit(R5_MadeGood, >flags)) {
/* This flag does not apply to '.replacement'
 * only to .rdev, so make sure to check that*/
struct md_rdev *rdev2 = rcu_dereference(


--
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.4 12/12] staging: wlags49_h2: buffer overflow setting station name

[Greg Kroah-Hartman]

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

--

From: Dan Carpenter 

commit b5e2f339865fb443107e5b10603e53bbc92dc054 upstream.

We need to check the length parameter before doing the memcpy().  I've
actually changed it to strlcpy() as well so that it's NUL terminated.

You need CAP_NET_ADMIN to trigger these so it's not the end of the
world.

[XiuQi: Backported to 3.4: Adjust context]

Reported-by: Nico Golde 
Reported-by: Fabian Yamaguchi 
Signed-off-by: Dan Carpenter 
Signed-off-by: Linus Torvalds 
Signed-off-by: Xie XiuQi 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/staging/wlags49_h2/wl_priv.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/drivers/staging/wlags49_h2/wl_priv.c
+++ b/drivers/staging/wlags49_h2/wl_priv.c
@@ -570,6 +570,7 @@ int wvlan_uil_put_info( struct uilreq *u
ltv_t   *pLtv;
bool_t  ltvAllocated = FALSE;
ENCSTRCTsEncryption;
+   size_t  len;
 
 #ifdef USE_WDS
hcf_16  hcfPort  = HCF_PORT_0;
@@ -686,7 +687,8 @@ int wvlan_uil_put_info( struct uilreq *u
break;
case CFG_CNF_OWN_NAME:
memset( lp->StationName, 0, sizeof( 
lp->StationName ));
-   memcpy( (void *)lp->StationName, (void 
*)>u.u8[2], (size_t)pLtv->u.u16[0]);
+   len = min_t(size_t, pLtv->u.u16[0], 
sizeof(lp->StationName));
+   strlcpy(lp->StationName, 
>u.u8[2], len);
pLtv->u.u16[0] = CNV_INT_TO_LITTLE( 
pLtv->u.u16[0] );
break;
case CFG_CNF_LOAD_BALANCING:
@@ -1800,6 +1802,7 @@ int wvlan_set_station_nickname(struct ne
 {
 struct wl_private *lp = wl_priv(dev);
 unsigned long flags;
+   size_t len;
 int ret = 0;

/**/
 
@@ -1811,7 +1814,8 @@ int wvlan_set_station_nickname(struct ne
 
 memset( lp->StationName, 0, sizeof( lp->StationName ));
 
-memcpy( lp->StationName, extra, wrqu->data.length);
+   len = min_t(size_t, wrqu->data.length, sizeof(lp->StationName));
+   strlcpy(lp->StationName, extra, len);
 
 /* Commit the adapter parameters */
 wl_apply( lp );


--
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.4 03/12] perf/x86/amd/ibs: Fix waking up from S3 for AMD family 10h

[Greg Kroah-Hartman]

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

--

From: Robert Richter 

commit bee09ed91cacdbffdbcd3b05de8409c77ec9fcd6 upstream.

On AMD family 10h we see following error messages while waking up from
S3 for all non-boot CPUs leading to a failed IBS initialization:

 Enabling non-boot CPUs ...
 smpboot: Booting Node 0 Processor 1 APIC 0x1
 [Firmware Bug]: cpu 1, try to use APIC500 (LVT offset 0) for vector 0x400, but 
the register is already in use for vector 0xf9 on another cpu
 perf: IBS APIC setup failed on cpu #1
 process: Switch to broadcast mode on CPU1
 CPU1 is up
 ...
 ACPI: Waking up from system sleep state S3

Reason for this is that during suspend the LVT offset for the IBS
vector gets lost and needs to be reinialized while resuming.

The offset is read from the IBSCTL msr. On family 10h the offset needs
to be 1 as offset 0 is used for the MCE threshold interrupt, but
firmware assings it for IBS to 0 too. The kernel needs to reprogram
the vector. The msr is a readonly node msr, but a new value can be
written via pci config space access. The reinitialization is
implemented for family 10h in setup_ibs_ctl() which is forced during
IBS setup.

This patch fixes IBS setup after waking up from S3 by adding
resume/supend hooks for the boot cpu which does the offset
reinitialization.

Marking it as stable to let distros pick up this fix.

Signed-off-by: Robert Richter 
Signed-off-by: Peter Zijlstra 
Cc: Linus Torvalds 
Link: 
http://lkml.kernel.org/r/1389797849-5565-1-git-send-email-rric@gmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/cpu/perf_event_amd_ibs.c |   53 ++-
 1 file changed, 45 insertions(+), 8 deletions(-)

--- a/arch/x86/kernel/cpu/perf_event_amd_ibs.c
+++ b/arch/x86/kernel/cpu/perf_event_amd_ibs.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -209,6 +210,18 @@ out:
return ret;
 }
 
+static void ibs_eilvt_setup(void)
+{
+   /*
+* Force LVT offset assignment for family 10h: The offsets are
+* not assigned by the BIOS for this family, so the OS is
+* responsible for doing it. If the OS assignment fails, fall
+* back to BIOS settings and try to setup this.
+*/
+   if (boot_cpu_data.x86 == 0x10)
+   force_ibs_eilvt_setup();
+}
+
 static inline int get_ibs_lvt_offset(void)
 {
u64 val;
@@ -244,6 +257,36 @@ static void clear_APIC_ibs(void *dummy)
setup_APIC_eilvt(offset, 0, APIC_EILVT_MSG_FIX, 1);
 }
 
+#ifdef CONFIG_PM
+
+static int perf_ibs_suspend(void)
+{
+   clear_APIC_ibs(NULL);
+   return 0;
+}
+
+static void perf_ibs_resume(void)
+{
+   ibs_eilvt_setup();
+   setup_APIC_ibs(NULL);
+}
+
+static struct syscore_ops perf_ibs_syscore_ops = {
+   .resume = perf_ibs_resume,
+   .suspend= perf_ibs_suspend,
+};
+
+static void perf_ibs_pm_init(void)
+{
+   register_syscore_ops(_ibs_syscore_ops);
+}
+
+#else
+
+static inline void perf_ibs_pm_init(void) { }
+
+#endif
+
 static int __cpuinit
 perf_ibs_cpu_notifier(struct notifier_block *self, unsigned long action, void 
*hcpu)
 {
@@ -270,18 +313,12 @@ static __init int amd_ibs_init(void)
if (!caps)
return -ENODEV; /* ibs not supported by the cpu */
 
-   /*
-* Force LVT offset assignment for family 10h: The offsets are
-* not assigned by the BIOS for this family, so the OS is
-* responsible for doing it. If the OS assignment fails, fall
-* back to BIOS settings and try to setup this.
-*/
-   if (boot_cpu_data.x86 == 0x10)
-   force_ibs_eilvt_setup();
+   ibs_eilvt_setup();
 
if (!ibs_eilvt_valid())
goto out;
 
+   perf_ibs_pm_init();
get_online_cpus();
ibs_caps = caps;
/* make ibs_caps visible to other cpus: */


--
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] of: make of_get_phy_mode parse 'phy-connection-type'

[Florian Fainelli]

Le 16/11/2013 04:24, Grant Likely a écrit :

On Fri, 15 Nov 2013 06:23:32 +, Florian Fainelli  
wrote:

Per the ePAPR v1.1 specification, 'phy-connection-type' is the canonical
property name for describing an Ethernet to PHY connection type. Make
sure that of_get_phy_mode() also attempts to parse that property and
update the comments mentioning 'phy-mode' to also include
'phy-connection-type'.

Acked-by: Grant Likely 
Signed-off-by: Florian Fainelli 


Applied, thanks


Grant, where is that patch, and will it be part of a pull request to 3.14?

Thanks!



g.


---
Changes since v2:
- reworked the error condition to look nicer per Grant's suggestion
- added Grant's Acked-by tag
- fixed a typo in the commit message on "mentioning"

  drivers/of/of_net.c | 11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c
index 8f9be2e..651e249 100644
--- a/drivers/of/of_net.c
+++ b/drivers/of/of_net.c
@@ -13,8 +13,8 @@

  /**
   * It maps 'enum phy_interface_t' found in include/linux/phy.h
- * into the device tree binding of 'phy-mode', so that Ethernet
- * device driver can get phy interface from device tree.
+ * into the device tree binding of 'phy-mode' or 'phy-connection-type',
+ * so that Ethernet device driver can get phy interface from device tree.
   */
  static const char *phy_modes[] = {
[PHY_INTERFACE_MODE_NA] = "",
@@ -36,8 +36,9 @@ static const char *phy_modes[] = {
   * of_get_phy_mode - Get phy mode for given device_node
   * @np:   Pointer to the given device_node
   *
- * The function gets phy interface string from property 'phy-mode',
- * and return its index in phy_modes table, or errno in error case.
+ * The function gets phy interface string from property 'phy-mode' or
+ * 'phy-connection-type', and return its index in phy_modes table, or errno in
+ * error case.
   */
  int of_get_phy_mode(struct device_node *np)
  {
@@ -46,6 +47,8 @@ int of_get_phy_mode(struct device_node *np)

err = of_property_read_string(np, "phy-mode", );
if (err < 0)
+   err = of_property_read_string(np, "phy-connection-type", );
+   if (err < 0)
return err;

for (i = 0; i < ARRAY_SIZE(phy_modes); i++)
--
1.8.3.2





--
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] MMC updates for 3.14-rc1

[Chris Ball]

Hi Linus,

This is a new email address for me, but you still have a signed path
to it.  (This pull request updates MAINTAINERS with the new address.)

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git 
tags/mmc-updates-for-3.14-rc1

to receive the MMC merge for 3.14.  These patches have been tested in
linux-next, and there's a trivial MAINTAINERS conflict with the
resolution below.  Thanks.

diff --cc MAINTAINERS
index 1912139,518bf71..000
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -1406,9 -1371,7 +1406,10 @@@ T: git git://git.xilinx.com/linux-xlnx.
  S:Supported
  F:arch/arm/mach-zynq/
  F:drivers/cpuidle/cpuidle-zynq.c
 +N:zynq
 +N:xilinx
 +F:drivers/clocksource/cadence_ttc_timer.c
+ F:drivers/mmc/host/sdhci-of-arasan.c
  
  ARM SMMU DRIVER
  M:Will Deacon 


The following changes since commit 0e4b0743bbe5807535ba1b0389281f9a4c1b2bb7:

  Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2013-11-26 11:18:37 
-0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git 
tags/mmc-updates-for-3.14-rc1

for you to fetch changes up to 945be38caa287b177b8c17ffaae7754cab6a658f:

  mmc: sdhci-pci: Fix possibility of chip->fixes being null (2014-01-23 
10:52:53 -0500)


MMC highlights for 3.14:

Core:
 - Avoid get_cd() on cards marked nonremovable.

Drivers:
 - arasan: New driver for controllers found in e.g. Xilinx Zynq SoC.
 - dwmmc: Support Hisilicon K3 SoC controllers.
 - esdhc-imx: Support for HS200 mode, DDR modes on MX6, runtime PM.
 - sdhci-pci: Support O2Micro/BayHubTech controllers used in laptops
   like Lenovo ThinkPad W540, Dell Latitude E5440, Dell Latitude E6540.
 - tegra: Support Tegra124 SoCs.


Adam Lee (2):
  mmc: sdhci-pci: break out definitions to header file
  mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts

Adrian Hunter (3):
  mmc: sdhci: Allow for long command timeouts
  mmc: sdhci-pci: Fix BYT sd card getting stuck in runtime suspend
  mmc: sdhci-pci: Fix possibility of chip->fixes being null

Aisheng Dong (1):
  mmc: sdhci: fix lockdep error in tuning routine

Alexandre Belloni (1):
  mmc: atmel-mci: add vmmc-supply support

Bing Zhao (1):
  mmc: sdio: add a quirk for broken SDIO_CCCR_INTx polling

Chris Ball (1):
  MAINTAINERS: mmc: Update Chris Ball's email address.

Chuansheng Liu (1):
  mmc: sdhci: Setting the host->mrq to NULL before executing tuning

David Cohen (2):
  mmc: sdhci: add quirk for broken HS200 support
  mmc: sdhci-pci: add broken HS200 quirk for Intel Merrifield

Dong Aisheng (13):
  mmc: sdhci: clear auto cmd setting bits for no data cmds
  mmc: sdhci-esdhc-imx: add SDHCI_TRANSFER_MODE read function
  mmc: sdhci-esdhc-imx: fix cpas over write issue
  mmc: sdhci-esdhc-imx: add MMC_CAP_1_8V_DDR for mx6
  mmc: core: mmc DDR mode should not depend on UHS_DDR50
  mmc: sdhci-esdhc-imx: add eMMC HS200 mode support
  mmc: sdhci-pltfm: export pltfm suspend/resume api
  mmc: sdhci-esdhc-imx: tuning bits should not be cleared during reset
  mmc: esdhc-imx: clearing SDHCI_CTRL_EXEC_TUNING should not affect other 
bits
  mmc: sdhci-esdhc-imx: fix runtime pm unbalance issue
  mmc: sdhci-esdhc-imx: add runtime pm support
  mmc: sdhci-esdhc-imx: fix access hardirq-unsafe lock in atomic context
  mmc: sdhci-esdhc-imx: fix warning during module remove function

Fabio Estevam (1):
  mmc: sdhci-esdhc-imx: Use NULL instead of zero

Guennadi Liakhovetski (1):
  mmc: tmio: remove myself as a maintainer

Kuninori Morimoto (6):
  mmc: tmio: don't overwrite caps2
  mmc: tmio: use -EPROBE_DEFER if driver can't find regulator
  mmc: tmio: bus_shift become tmio_mmc_data member
  mmc: tmio: add new TMIO_MMC_HAVE_HIGH_REG flags
  mmc: SDHI: add SoC specific workaround via HW version
  mmc: tmio: fixup compile error

Laurent Pinchart (5):
  mmc: sh_mobile_sdhi: Convert to clk_prepare/unprepare
  mmc: sh_mmcif: Factorize DMA channel request and configuration code
  mmc: sh_mmcif: Fix compilation warning on 64-bit platforms
  mmc: sdhi: Enable driver compilation with COMPILE_TEST
  mmc: sh_mmcif: Enable driver compilation with COMPILE_TEST

Ludovic Desroches (1):
  mmc: atmel-mci: fix timeout errors in SDIO mode when using DMA

Mika Westerberg (1):
  mmc: sdhci-acpi: add new ACPI ID

Ray Jui (1):
  mmc: fix host release issue after discard operation

Sascha Hauer (6):
  mmc: Do not call get_cd for non removable cards
  mmc: mxs: use standard flag for non-removable status
  mmc: mxs: use standard flag for broken card detection
  mmc: mxs: use standard flag for cd inverted
  mmc: mxs: use mmc_gpio_get_ro for detecting read-only 

[PATCH v3 4/4] x86, mpx: extend siginfo structure to include bound violation information

[Qiaowei Ren]

This patch adds new fields about bound violation into siginfo
structure. si_lower and si_upper are respectively lower bound
and upper bound when bound violation is caused.

These fields will be set in #BR exception handler by decoding
the user instruction and constructing the faulting pointer.
A userspace application can get violation address, lower bound
and upper bound for bound violation from this new siginfo structure.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/include/asm/mpx.h |   19 +++
 arch/x86/kernel/mpx.c  |  287 
 arch/x86/kernel/traps.c|6 +
 include/uapi/asm-generic/siginfo.h |9 +-
 kernel/signal.c|4 +
 5 files changed, 324 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index 9652e9e..e099573 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 
@@ -30,6 +31,22 @@
 
 #endif
 
+struct mpx_insn {
+   struct insn_field rex_prefix;   /* REX prefix */
+   struct insn_field modrm;
+   struct insn_field sib;
+   struct insn_field displacement;
+
+   unsigned char addr_bytes;   /* effective address size */
+   unsigned char limit;
+   unsigned char x86_64;
+
+   const unsigned char *kaddr; /* kernel address of insn to analyze */
+   const unsigned char *next_byte;
+};
+
+#define MAX_MPX_INSN_SIZE  15
+
 typedef union {
struct {
unsigned long ignored:MPX_IGN_BITS;
@@ -40,5 +57,7 @@ typedef union {
 } mpx_addr;
 
 void do_mpx_bt_fault(struct xsave_struct *xsave_buf);
+void do_mpx_bounds(struct pt_regs *regs, siginfo_t *info,
+   struct xsave_struct *xsave_buf);
 
 #endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
index 9e91178..983abf7 100644
--- a/arch/x86/kernel/mpx.c
+++ b/arch/x86/kernel/mpx.c
@@ -91,6 +91,269 @@ int mpx_release(struct task_struct *tsk)
return 0;
 }
 
+typedef enum {REG_TYPE_RM, REG_TYPE_INDEX, REG_TYPE_BASE} reg_type_t;
+static unsigned long get_reg(struct mpx_insn *insn, struct pt_regs *regs,
+reg_type_t type)
+{
+   int regno = 0;
+   unsigned char modrm = (unsigned char)insn->modrm.value;
+   unsigned char sib = (unsigned char)insn->sib.value;
+
+   static const int regoff[] = {
+   offsetof(struct pt_regs, ax),
+   offsetof(struct pt_regs, cx),
+   offsetof(struct pt_regs, dx),
+   offsetof(struct pt_regs, bx),
+   offsetof(struct pt_regs, sp),
+   offsetof(struct pt_regs, bp),
+   offsetof(struct pt_regs, si),
+   offsetof(struct pt_regs, di),
+#ifdef CONFIG_X86_64
+   offsetof(struct pt_regs, r8),
+   offsetof(struct pt_regs, r9),
+   offsetof(struct pt_regs, r10),
+   offsetof(struct pt_regs, r11),
+   offsetof(struct pt_regs, r12),
+   offsetof(struct pt_regs, r13),
+   offsetof(struct pt_regs, r14),
+   offsetof(struct pt_regs, r15),
+#endif
+   };
+
+   switch (type) {
+   case REG_TYPE_RM:
+   regno = X86_MODRM_RM(modrm);
+   if (X86_REX_B(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   case REG_TYPE_INDEX:
+   regno = X86_SIB_INDEX(sib);
+   if (X86_REX_X(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   case REG_TYPE_BASE:
+   regno = X86_SIB_BASE(sib);
+   if (X86_REX_B(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   default:
+   break;
+   }
+
+   return regs_get_register(regs, regoff[regno]);
+}
+
+/*
+ * return the address being referenced be instruction
+ * for rm=3 returning the content of the rm reg
+ * for rm!=3 calculates the address using SIB and Disp
+ */
+static unsigned long get_addr_ref(struct mpx_insn *insn, struct pt_regs *regs)
+{
+   unsigned long addr;
+   unsigned long base;
+   unsigned long indx;
+   unsigned char modrm = (unsigned char)insn->modrm.value;
+   unsigned char sib = (unsigned char)insn->sib.value;
+
+   if (X86_MODRM_MOD(modrm) == 3) {
+   addr = get_reg(insn, regs, REG_TYPE_RM);
+   } else {
+   if (insn->sib.nbytes) {
+   base = get_reg(insn, regs, REG_TYPE_BASE);
+   indx = get_reg(insn, regs, REG_TYPE_INDEX);
+   addr = base + indx * (1 << X86_SIB_SCALE(sib));
+   } else {
+   addr = get_reg(insn, regs, REG_TYPE_RM);
+   }
+   addr += insn->displacement.value;
+   }
+
+   return addr;
+}
+
+/* Verify next 

[PATCH v3 3/4] x86, mpx: add prctl commands PR_MPX_INIT, PR_MPX_RELEASE

[Qiaowei Ren]

This patch adds the PR_MPX_INIT and PR_MPX_RELEASE prctl()
commands on the x86 platform. These commands can be used to
init and release MPX related resource.

A MMU notifier will be registered during PR_MPX_INIT
command execution. So the bound tables can be automatically
deallocated when one memory area is unmapped.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/Kconfig |4 ++
 arch/x86/include/asm/mpx.h   |9 
 arch/x86/include/asm/processor.h |   16 +++
 arch/x86/kernel/mpx.c|   84 ++
 include/uapi/linux/prctl.h   |6 +++
 kernel/sys.c |   12 +
 6 files changed, 131 insertions(+), 0 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cd18b83..28916e1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -236,6 +236,10 @@ config HAVE_INTEL_TXT
def_bool y
depends on INTEL_IOMMU && ACPI
 
+config HAVE_INTEL_MPX
+   def_bool y
+   select MMU_NOTIFIER
+
 config X86_32_SMP
def_bool y
depends on X86_32 && SMP
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index d074153..9652e9e 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -30,6 +30,15 @@
 
 #endif
 
+typedef union {
+   struct {
+   unsigned long ignored:MPX_IGN_BITS;
+   unsigned long l2index:MPX_L2_BITS;
+   unsigned long l1index:MPX_L1_BITS;
+   };
+   unsigned long addr;
+} mpx_addr;
+
 void do_mpx_bt_fault(struct xsave_struct *xsave_buf);
 
 #endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index fdedd38..5962413 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -943,6 +943,22 @@ extern void start_thread(struct pt_regs *regs, unsigned 
long new_ip,
 extern int get_tsc_mode(unsigned long adr);
 extern int set_tsc_mode(unsigned int val);
 
+#ifdef CONFIG_HAVE_INTEL_MPX
+
+/* Init/release a process' MPX related resource */
+#define MPX_INIT(tsk)  mpx_init((tsk))
+#define MPX_RELEASE(tsk)   mpx_release((tsk))
+
+extern int mpx_init(struct task_struct *tsk);
+extern int mpx_release(struct task_struct *tsk);
+
+#else /* CONFIG_HAVE_INTEL_MPX */
+
+#define MPX_INIT(tsk)  (-EINVAL)
+#define MPX_RELEASE(tsk)   (-EINVAL)
+
+#endif /* CONFIG_HAVE_INTEL_MPX */
+
 extern u16 amd_get_nb_id(int cpu);
 
 static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
index e055e0e..9e91178 100644
--- a/arch/x86/kernel/mpx.c
+++ b/arch/x86/kernel/mpx.c
@@ -1,5 +1,7 @@
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -7,6 +9,88 @@
 #include 
 #include 
 
+static struct mmu_notifier mpx_mn;
+
+static void mpx_invl_range_end(struct mmu_notifier *mn,
+   struct mm_struct *mm,
+   unsigned long start, unsigned long end)
+{
+   struct xsave_struct *xsave_buf;
+   unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
+   unsigned long bt_addr;
+   unsigned long bd_base;
+   unsigned long bd_entry, bde_start, bde_end;
+   mpx_addr lap;
+
+   pgd_t *pgd;
+   pud_t *pud;
+   pmd_t *pmd;
+   pte_t *pte;
+
+   /* ignore swap notifications */
+   pgd = pgd_offset(mm, start);
+   pud = pud_offset(pgd, start);
+   pmd = pmd_offset(pud, start);
+   pte = pte_offset_kernel(pmd, start);
+   if (!pte_present(*pte) && !pte_none(*pte) && !pte_file(*pte))
+   return;
+
+   /* get bound directory base address */
+   fpu_xsave(>thread.fpu);
+   xsave_buf = &(current->thread.fpu.state->xsave);
+   bd_base = xsave_buf->bndcsr.cfg_reg_u & MPX_BNDCFG_ADDR_MASK;
+
+   /* get related bde range */
+   lap.addr = start;
+   bde_start = bd_base + (lap.l1index << MPX_L1_SHIFT);
+
+   lap.addr = end;
+   if (lap.ignored || lap.l2index)
+   bde_end = bd_base + (lap.l1indexmm);
+
+   return 0;
+}
+
 static bool allocate_bt(unsigned long bd_entry)
 {
unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index 289760f..19ab881 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -149,4 +149,10 @@
 
 #define PR_GET_TID_ADDRESS 40
 
+/*
+ * Init/release MPX related resource.
+ */
+#define PR_MPX_INIT41
+#define PR_MPX_RELEASE 42
+
 #endif /* _LINUX_PRCTL_H */
diff --git a/kernel/sys.c b/kernel/sys.c
index c723113..0334d03 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -91,6 +91,12 @@
 #ifndef SET_TSC_CTL
 # define 

[PATCH v3 0/4] Intel MPX support

[Qiaowei Ren]

This patchset adds support for the Memory Protection Extensions
(MPX) feature found in future Intel processors.

MPX can be used in conjunction with compiler changes to check memory
references, for those references whose compile-time normal intentions
are usurped at runtime due to buffer overflow or underflow.

MPX provides this capability at very low performance overhead for
newly compiled code, and provides compatibility mechanisms with legacy
software components. MPX architecture is designed allow a machine to
run both MPX enabled software and legacy software that is MPX unaware.
In such a case, the legacy software does not benefit from MPX, but it
also does not experience any change in functionality or reduction in
performance.

More information about Intel MPX can be found in "Intel(R) Architecture
Instruction Set Extensions Programming Reference".

To get the advantage of MPX, changes are required in the OS kernel,
binutils, compiler, system libraries support.

New GCC option -fmpx is introduced to utilize MPX instructions.
Currently GCC compiler sources with MPX support is available in a
separate branch in common GCC SVN repository. See GCC SVN page
(http://gcc.gnu.org/svn.html) for details.

To have the full protection, we had to add MPX instrumentation to all
the necessary Glibc routines (e.g. memcpy) written on assembler, and
compile Glibc with the MPX enabled GCC compiler. Currently MPX enabled
Glibc source can be found in Glibc git repository.

Enabling an application to use MPX will generally not require source
code updates but there is some runtime code, which is responsible for
configuring and enabling MPX, needed in order to make use of MPX.
For most applications this runtime support will be available by linking
to a library supplied by the compiler or possibly it will come directly
from the OS once OS versions that support MPX are available.

MPX kernel code, namely this patchset, has mainly the 2 responsibilities:
provide handlers for bounds faults (#BR), and manage bounds memory.

Currently no hardware with MPX ISA is available but it is always
possible to use SDE (Intel(R) software Development Emulator) instead,
which can be downloaded from
http://software.intel.com/en-us/articles/intel-software-development-emulator


Changes since v1:
  * check to see if #BR occurred in userspace or kernel space.
  * use generic structure and macro as much as possible when
decode mpx instructions.

Changes since v2:
  * fix some compile warnings.
  * update documentation.

Qiaowei Ren (4):
  x86, mpx: add documentation on Intel MPX
  x86, mpx: hook #BR exception handler to allocate bound tables
  x86, mpx: add prctl commands PR_MPX_INIT, PR_MPX_RELEASE
  x86, mpx: extend siginfo structure to include bound violation
information

 Documentation/x86/intel_mpx.txt|  226 
 arch/x86/Kconfig   |4 +
 arch/x86/include/asm/mpx.h |   63 ++
 arch/x86/include/asm/processor.h   |   16 ++
 arch/x86/kernel/Makefile   |1 +
 arch/x86/kernel/mpx.c  |  415 
 arch/x86/kernel/traps.c|   61 +-
 include/uapi/asm-generic/siginfo.h |9 +-
 include/uapi/linux/prctl.h |6 +
 kernel/signal.c|4 +
 kernel/sys.c   |   12 +
 11 files changed, 815 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/x86/intel_mpx.txt
 create mode 100644 arch/x86/include/asm/mpx.h
 create mode 100644 arch/x86/kernel/mpx.c

--
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 v3 2/4] x86, mpx: hook #BR exception handler to allocate bound tables

[Qiaowei Ren]

An access to an invalid bound directory entry will cause a #BR
exception. This patch hook #BR exception handler to allocate
one bound table and bind it with that buond directory entry.

This will avoid the need of forwarding the #BR exception
to the user space when bound directory has invalid entry.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/include/asm/mpx.h |   35 
 arch/x86/kernel/Makefile   |1 +
 arch/x86/kernel/mpx.c  |   44 +++
 arch/x86/kernel/traps.c|   55 +++-
 4 files changed, 134 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/include/asm/mpx.h
 create mode 100644 arch/x86/kernel/mpx.c

diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
new file mode 100644
index 000..d074153
--- /dev/null
+++ b/arch/x86/include/asm/mpx.h
@@ -0,0 +1,35 @@
+#ifndef _ASM_X86_MPX_H
+#define _ASM_X86_MPX_H
+
+#include 
+#include 
+
+#ifdef CONFIG_X86_64
+
+#define MPX_L1_BITS28
+#define MPX_L1_SHIFT   3
+#define MPX_L2_BITS17
+#define MPX_L2_SHIFT   5
+#define MPX_IGN_BITS   3
+#define MPX_L2_NODE_ADDR_MASK  0xfff8UL
+
+#define MPX_BNDSTA_ADDR_MASK   0xfffcUL
+#define MPX_BNDCFG_ADDR_MASK   0xf000UL
+
+#else
+
+#define MPX_L1_BITS20
+#define MPX_L1_SHIFT   2
+#define MPX_L2_BITS10
+#define MPX_L2_SHIFT   4
+#define MPX_IGN_BITS   2
+#define MPX_L2_NODE_ADDR_MASK  0xfffcUL
+
+#define MPX_BNDSTA_ADDR_MASK   0xfffcUL
+#define MPX_BNDCFG_ADDR_MASK   0xf000UL
+
+#endif
+
+void do_mpx_bt_fault(struct xsave_struct *xsave_buf);
+
+#endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index cb648c8..becb970 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_PREEMPT) += preempt.o
 
 obj-y  += process.o
 obj-y  += i387.o xsave.o
+obj-y  += mpx.o
 obj-y  += ptrace.o
 obj-$(CONFIG_X86_32)   += tls.o
 obj-$(CONFIG_IA32_EMULATION)   += tls.o
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
new file mode 100644
index 000..e055e0e
--- /dev/null
+++ b/arch/x86/kernel/mpx.c
@@ -0,0 +1,44 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool allocate_bt(unsigned long bd_entry)
+{
+   unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
+   unsigned long bt_addr, old_val = 0;
+
+   bt_addr = sys_mmap_pgoff(0, bt_size, PROT_READ | PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE | MAP_POPULATE, -1, 0);
+   if (bt_addr == -1) {
+   pr_err("L2 Node Allocation Failed at L1 addr %lx\n",
+   bd_entry);
+   return false;
+   }
+   bt_addr = (bt_addr & MPX_L2_NODE_ADDR_MASK) | 0x01;
+
+   user_atomic_cmpxchg_inatomic(_val,
+   (long __user *)bd_entry, 0, bt_addr);
+   if (old_val)
+   vm_munmap(bt_addr & MPX_L2_NODE_ADDR_MASK, bt_size);
+
+   return true;
+}
+
+void do_mpx_bt_fault(struct xsave_struct *xsave_buf)
+{
+   unsigned long status;
+   unsigned long bd_entry, bd_base;
+   unsigned long bd_size = 1UL << (MPX_L1_BITS+MPX_L1_SHIFT);
+
+   bd_base = xsave_buf->bndcsr.cfg_reg_u & MPX_BNDCFG_ADDR_MASK;
+   status = xsave_buf->bndcsr.status_reg;
+
+   bd_entry = status & MPX_BNDSTA_ADDR_MASK;
+   if ((bd_entry >= bd_base) && (bd_entry < bd_base + bd_size))
+   allocate_bt(bd_entry);
+}
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 57409f6..6b284a4 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -213,7 +214,6 @@ dotraplinkage void do_##name(struct pt_regs *regs, long 
error_code) \
 
 DO_ERROR_INFO(X86_TRAP_DE, SIGFPE,  "divide error",
divide_error,FPE_INTDIV, regs->ip )
 DO_ERROR (X86_TRAP_OF, SIGSEGV, "overflow",
overflow  )
-DO_ERROR (X86_TRAP_BR, SIGSEGV, "bounds",  bounds  
  )
 DO_ERROR_INFO(X86_TRAP_UD, SIGILL,  "invalid opcode",  
invalid_op,  ILL_ILLOPN, regs->ip )
 DO_ERROR (X86_TRAP_OLD_MF, SIGFPE,  "coprocessor segment overrun", 
coprocessor_segment_overrun   )
 DO_ERROR (X86_TRAP_TS, SIGSEGV, "invalid TSS", 
invalid_TSS   )
@@ -263,6 +263,59 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, 
long error_code)
 }
 #endif
 
+dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
+{
+   enum ctx_state prev_state;
+   unsigned long 

[PATCH v3 1/4] x86, mpx: add documentation on Intel MPX

[Qiaowei Ren]

This patch adds the Documentation/x86/intel_mpx.txt file with some
information about Intel MPX.

Signed-off-by: Qiaowei Ren 
---
 Documentation/x86/intel_mpx.txt |  226 +++
 1 files changed, 226 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/x86/intel_mpx.txt

diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt
new file mode 100644
index 000..052001c
--- /dev/null
+++ b/Documentation/x86/intel_mpx.txt
@@ -0,0 +1,226 @@
+1. Intel(R) MPX Overview
+
+
+
+Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new
+capability introduced into Intel Architecture. Intel MPX provides
+hardware features that can be used in conjunction with compiler
+changes to check memory references, for those references whose
+compile-time normal intentions are usurped at runtime due to
+buffer overflow or underflow.
+
+Two of the most important goals of Intel MPX are to provide
+this capability at very low performance overhead for newly
+compiled code, and to provide compatibility mechanisms with
+legacy software components. MPX architecture is designed
+allow a machine (i.e., the processor(s) and the OS software)
+to run both MPX enabled software and legacy software that
+is MPX unaware. In such a case, the legacy software does not
+benefit from MPX, but it also does not experience any change
+in functionality or reduction in performance.
+
+Intel(R) MPX Programming Model
+--
+
+Intel MPX introduces new registers and new instructions that
+operate on these registers. Some of the registers added are
+bounds registers which store a pointer's lower bound and upper
+bound limits. Whenever the pointer is used, the requested
+reference is checked against the pointer's associated bounds,
+thereby preventing out-of-bound memory access (such as buffer
+overflows and overruns). Out-of-bounds memory references
+initiate a #BR exception which can then be handled in an
+appropriate manner.
+
+Loading and Storing Bounds using Translation
+
+
+Intel MPX defines two instructions for load/store of the linear
+address of a pointer to a buffer, along with the bounds of the
+buffer into a paging structure of extended bounds. Specifically
+when storing extended bounds, the processor will perform address
+translation of the address where the pointer is stored to an
+address in the Bound Table (BT) to determine the store location
+of extended bounds. Loading of an extended bounds performs the
+reverse sequence.
+
+The structure in memory to load/store an extended bound is a
+4-tuple consisting of lower bound, upper bound, pointer value
+and a reserved field. Bound loads and stores access 32-bit or
+64-bit operand size according to the operation mode. Thus,
+a bound table entry is 4*32 bits in 32-bit mode and 4*64 bits
+in 64-bit mode.
+
+The linear address of a bound table is stored in a Bound
+Directory (BD) entry. And the linear address of the bound
+directory is derived from either BNDCFGU or BNDCFGS registers.
+Bounds in memory are stored in Bound Tables (BT) as an extended
+bound, which are accessed via Bound Directory (BD) and address
+translation performed by BNDLDX/BNDSTX instructions.
+
+Bounds Directory (BD) and Bounds Tables (BT) are stored in
+application memory and are allocated by the application (in case
+of kernel use, the structures will be in kernel memory). The
+bound directory and each instance of bound table are in contiguous
+linear memory.
+
+XSAVE/XRESTOR Support of Intel MPX State
+
+
+Enabling Intel MPX requires an OS to manage two bits in XCR0:
+  - BNDREGS for saving and restoring registers BND0-BND3,
+  - BNDCSR for saving and restoring the user-mode configuration
+(BNDCFGU) and the status register (BNDSTATUS).
+
+The reason for having two separate bits is that BND0-BND3 is
+likely to be volatile state, while BNDCFGU and BNDSTATUS are not.
+Therefore, an OS has flexibility in handling these two states
+differently in saving or restoring them.
+
+For details about the Intel MPX instructions, see "Intel(R)
+Architecture Instruction Set Extensions Programming Reference".
+
+
+2. How to get the advantage of MPX 
+==
+
+
+To get the advantage of MPX, changes are required in
+the OS kernel, binutils, compiler, system libraries support.
+
+MPX support in the GNU toolchain
+
+
+This section describes changes in GNU Binutils, GCC and Glibc
+to support MPX.
+
+The first step of MPX support is to implement support for new
+hardware features in binutils and the GCC.
+
+The second step is implementation of MPX instrumentation pass
+in the GCC compiler which is responsible for instrumenting all
+memory accesses with pointer checks. Compiler changes for runtime
+bound checks include:
+
+  * Bounds creation for statically allocated objects, objects
+

RE: [Xen-devel] [PATCH 4/4] xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.

[Zhang, Yang Z]

Konrad Rzeszutek Wilk wrote on 2013-11-09:
> The 'read_reply' works with 'process_msg' to read of a reply in XenBus.
> 'process_msg' is running from within the 'xenbus' thread. Whenever a
> message shows up in XenBus it is put on a xs_state.reply_list list and
> 'read_reply' picks it up.
> 
> The problem is if the backend domain or the xenstored process is killed.
> In which case 'xenbus' is still awaiting - and 'read_reply' if called
> - stuck forever waiting for the reply_list to have some contents.
> 
> This is normally not a problem - as the backend domain can come back
> or the xenstored process can be restarted. However if the domain is in
> process of being powered off/restarted/halted - there is no point of
> waiting on it coming back - as we are effectively being terminated and
> should not impede the progress.
> 

Hi, Konrad,

Is this patch applied in Linux upstream tree? I didn't find it with latest 
Linux upstream source.

> This patch solves this problem by checking the 'system_state' value to
> see if we are in heading towards death. We also make the wait
> mechanism a bit more asynchronous.
> 
> Fixes-Bug: http://bugs.xenproject.org/xen/bug/8
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/xen/xenbus/xenbus_xs.c | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> diff --git a/drivers/xen/xenbus/xenbus_xs.c
> b/drivers/xen/xenbus/xenbus_xs.c index b6d5fff..4f22706 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -148,9 +148,24 @@ static void *read_reply(enum xsd_sockmsg_type
> *type, unsigned int *len)
> 
>   while (list_empty(_state.reply_list)) {
>   spin_unlock(_state.reply_lock);
> - /* XXX FIXME: Avoid synchronous wait for response here. */
> - wait_event(xs_state.reply_waitq, -
> !list_empty(_state.reply_list));
> + wait_event_timeout(xs_state.reply_waitq, +  
>   
> !list_empty(_state.reply_list), + 
> msecs_to_jiffies(500)); +
> + /* + * If we are in the process of being shut-down 
> there is +*
> no point of trying to contact XenBus - it is either +  * killed
> (xenstored application) or the other domain +  * has been killed or is
> unreachable. + */ +   switch (system_state) { +   
> case SYSTEM_POWER_OFF:
> + case SYSTEM_RESTART: +  case SYSTEM_HALT: + 
> return ERR_PTR(-EIO);
> + default: +  break; +}
>   spin_lock(_state.reply_lock);
>   }
> @@ -215,6 +230,9 @@ void *xenbus_dev_request_and_reply(struct
> xsd_sockmsg *msg)
> 
>   mutex_unlock(_state.request_mutex);
> + if (IS_ERR(ret))
> + return ret;
> +
>   if ((msg->type == XS_TRANSACTION_END) ||
>   ((req_msg.type == XS_TRANSACTION_START) &&
>(msg->type == XS_ERROR)))


Best regards,
Yang


--
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/4] clk: mvebu: fix clk init order

[Ezequiel Garcia]

Hi Emilio,

Thanks for your help with this.

On Sat, Jan 25, 2014 at 07:11:07PM -0300, Emilio López wrote:
[..]
> >
> > Ok, I'll look if using of_clk_get_parent_name will help here. But again,
> > I can see that clk-gating driver gets registered before core-clk driver.
> > There may be no code to give you the parent name at that time.
> 
> After looking at some of the armada*.dtsi, I see you don't list the 
> clock names on the coreclk node, so of_clk_get_parent_name may not be of 
> much value after all.
> 

IIRC, we faced a similar issue with the Core Divider clock and solved it by
specifying the clock names in the DT.

I meant to complete the core and gating clocks in a similar way
(providing names on the DT), but apparently (as discussed with Gregory Clement)
Mike Turquette and others are planning to remove the clock names from
the DT entirely.

Can you guys explain about this plan a bit further? Or do you think we
should specify the names on the DT for all the clocks instead?

Notice that the latter would remove lots of strings from the kernel
itself (right?)
-- 
Ezequiel García, 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/

Re: [PATCH 4/4] power_supply: bq24261 charger driver

[Pavel Machek]

Hi!

> +++ b/drivers/power/Makefile
> @@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735)   += bq24735-charger.o
>  obj-$(CONFIG_POWER_AVS)  += avs/
>  obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
>  obj-$(CONFIG_CHARGER_TPS65090)   += tps65090-charger.o
> +obj-$(CONFIG_BQ24261_CHARGER)+= bq24261_charger.o
>  obj-$(CONFIG_POWER_RESET)+= reset/

Spot two inconsistencies.

> + if (ret < 0)
> + dev_err(>client->dev,
> + "Error (%d) in reading status register(0x00)\n",
> + ret);

If you have code indented 10 levels like this, you are
doing something wrong.

Check codingstyle.

Maybe Rafael should be cced on the series?
Pavel
--
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] power_supply: Introduce PSE compliant algorithm

[Pavel Machek]

Hi!


> +config POWER_SUPPLY_CHARGING_ALGO_PSE
> + bool "PSE compliant charging algorithm"
> + help
> +   Say Y here to select PSE compliant charging algorithm. As per PSE
> +   standard the battery characteristics and thereby the charging rates

It would be good to explain PSE here.

> +#define MAINT_EXIT_OFFSET 50  /* mv */

mV

> +/* PSE Modified Algo Structure */
> +/* Parameters defining the charging range */
> +struct psy_ps_temp_chg_table {
> + /* upper temperature limit for each zone */
> + short int temp_up_lim;
> + /* charge current and voltage */
> + short int full_chrg_vol;
> + short int full_chrg_cur;

It would be good to add units here. And vowels.

> + /* type of battery */
> + u16 battery_type;
> + u16 capacity;
> + u16 voltage_max;
> + /* charge termination current */
> + u16 chrg_term_ma;
> + /* Low battery level voltage */
> + u16 low_batt_mv;
> + /* upper and lower temperature limits on discharging */
> + u8 disch_tmp_ul;
> + u8 disch_tmp_ll;

tmp sounds like temporary, not temperature. just use full words.

Add units. And u8 is probably not right type for temperature.


> + /* number of temperature monitoring ranges */
> + u16 temp_mon_ranges;
> + struct psy_ps_temp_chg_table temp_mon_range[BATT_TEMP_NR_RNG];
> + /* Lowest temperature supported */
> + short int temp_low_lim;

Add units.

Also check multiline comment codingstyle.
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 2/2] thermal,rcar_thermal: Add dependency on HAS_IOMEM

[Richard Weinberger]

Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with 
COMPILE_TEST)
broke build on archs wihout io memory.

On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.

drivers/thermal/rcar_thermal.c:404: undefined reference to 
`devm_ioremap_resource'
drivers/thermal/rcar_thermal.c:426: undefined reference to 
`devm_ioremap_resource'

Signed-off-by: Richard Weinberger 
---
 drivers/thermal/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 35c0664..88efa8f 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -136,6 +136,7 @@ config SPEAR_THERMAL
 config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
+   depends on HAS_IO_MEM
help
  Enable this to plug the R-Car thermal sensor driver into the Linux
  thermal framework.
-- 
1.8.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 1/2] phy,phy-bcm-kona-usb2.c: Add dependency on HAS_IOMEM

[Richard Weinberger]

On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.

drivers/phy/phy-bcm-kona-usb2.c:114: undefined reference to 
`devm_ioremap_resource'

Signed-off-by: Richard Weinberger 
---
 drivers/phy/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index afa2354..79e3c70 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -61,6 +61,7 @@ config PHY_EXYNOS_DP_VIDEO
 config BCM_KONA_USB2_PHY
tristate "Broadcom Kona USB2 PHY Driver"
depends on GENERIC_PHY
+   depends on HAS_IOMEM
help
  Enable this to support the Broadcom Kona USB 2.0 PHY.
 
-- 
1.8.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: [kernel 3.13.0-06058-g2d08cd0] Strange ACPI error messages

[Rafael J. Wysocki]

On Saturday, January 25, 2014 02:18:17 PM Henrique de Moraes Holschuh wrote:
> On Sat, 25 Jan 2014, Rafael J. Wysocki wrote:
> > On Saturday, January 25, 2014 02:53:24 PM Rafael J. Wysocki wrote:
> > > On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
> > > > Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
> > > > 
> > > > ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
> > > > ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
> > > > ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
> > > > ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
> > > > 
> > > > I don't have CPUs 4..7! Error messages regarding not existing
> > > > CPUs should not be displayed.
> > > > kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
> > > > 
> > > > This is a regression. I never saw this messages before.
> > > 
> > > Does your system show any other suspicious symptoms or are you worried 
> > > about
> > > those messages only?
> > 
> > Gerry, this is your commit b981513f806d (ACPI / scan: bail out early if 
> > failed
> > to parse APIC ID for CPU).  Apparently, the BIOS has room for 4 CPUs more 
> > than
> > there actually are in the system.  Maybe we can reduce the log level of 
> > those
> > messages to avoid ringing bells unnecessarily?
> 
> It is standard practice (at least in SuperMicro boxes, but I've also seen it
> elsewhere) for the BIOS to have ACPI tables mentioning all cores supported
> by the biggest core-count CPU topology possible by the motherboard.  The
> cores you don't have are reported as if they were hotpluggable but absent,
> even if they will *never* show up at runtime.  Meh.
> 
> So yes, such warnings will get annoying *very* quickly.

Well, what about using acpi_handle_debug() in there, then?

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: [kernel 3.13.0-06058-g2d08cd0] Strange ACPI error messages

[Rafael J. Wysocki]

On Saturday, January 25, 2014 05:32:19 PM Jörg Otte wrote:
> 2014-01-25 Rafael J. Wysocki :
> > On Saturday, January 25, 2014 11:03:09 AM Jörg Otte wrote:
> >> Kernel 3.13.0-06058-g2d08cd0 displays following errors on the console:
> >>
> >> ACPI: \_PR_.CPU4: failed to get CPU APIC ID.
> >> ACPI: \_PR_.CPU5: failed to get CPU APIC ID.
> >> ACPI: \_PR_.CPU6: failed to get CPU APIC ID.
> >> ACPI: \_PR_.CPU7: failed to get CPU APIC ID.
> >>
> >> I don't have CPUs 4..7! Error messages regarding not existing
> >> CPUs should not be displayed.
> >> kernel 3.13.0-05617-g3aacd62 and before did'nt show this messages.
> >>
> >> This is a regression. I never saw this messages before.
> >
> > Does your system show any other suspicious symptoms or are you worried about
> > those messages only?
> >
> > Rafael
> >
> 
> what's looking badly is this:
> 
> ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_]
> (20131218/hwxface-580)
> ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_]
> (20131218/hwxface-580)

That means your BIOS doesn't support system sleep states S1 and S2, but we
should be able to suppress those messages I think.

> and this:
> 
> acpi PNP0A08:00: _OSC: OS supports [ASPM ClockPM Segments MSI]
>  \_SB_.PCI0:_OSC invalid UUID
>  _OSC request data:1 1e 0
> acpi PNP0A08:00: _OSC failed (AE_ERROR); disabling ASPM

That means the BIOS doesn't want to grant the kernel control of extended
PCIe features on your system.

> but these messages are not new.

They indicate things that are not supported by the BIOS, but I agree that the
messages are a bit cryptic.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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/4] clk: mvebu: fix clk init order

[Emilio López]

Sebastian,

El 25/01/14 18:44, Sebastian Hesselbarth escribió:

On 01/25/2014 10:32 PM, Emilio López wrote:

El 25/01/14 15:19, Sebastian Hesselbarth escribió:

This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.


The framework should be able to deal with unordered registration. I am
not very familiar with the mvebu driver though, do you have a valid
reason to require a specific order?


Emilio,

I rather think that everthing registered with CLK_OF_DECLARE cannot
deal with unordered registration. The callback passed to CLK_OF_DECLARE
has to have void as return value, so there is no way to pass errors,
e.g. -EPROBE_DEFER, back to of_clk_init.


Indeed. What I meant is that the framework works fine if you first 
register a child clock that refers to a not yet registered parent, and 
then register the parent. The registration need not be strictly ordered.



The reason for this ordering is that the clock gates depend on core
clocks. It is always that way, so merging both init functions isn't
that odd.


If your only dependency is the parent name, and you can use DT or 
something else to get it, then you don't need to enforce an order.



Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
registered before core clocks driver. Unfortunately, we cannot
return -EPROBE_DEFER in drivers initialized by clk_of_init.


Why would you need to do so? After a quick inspection on the code, I see
you may have problems on mvebu_clk_gating_setup() when getting the
default parent clock name, but I believe you could solve it in an easier
way by using of_clk_get_parent_name().


Ok, I'll look if using of_clk_get_parent_name will help here. But again,
I can see that clk-gating driver gets registered before core-clk driver.
There may be no code to give you the parent name at that time.


After looking at some of the armada*.dtsi, I see you don't list the 
clock names on the coreclk node, so of_clk_get_parent_name may not be of 
much value after all.


Cheers,

Emilio
--
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/

WaitForMultipleObjects/etc. In Kernel

[Network Nut]

Hi All,

This is my first post to anything Linux, so if there is a better mailing
list, please let me know.

I think that the facility by which a thread can block while waiting for any
of several synchronization primitives (*mutex*, *semaphore*, *event*,
*waitable
timer*)...is not only "nice to have", but fundamental to complex (clean)
multi-threaded programming. Of course, this facility is available on
Windows as *WaitForMultipleObjects *with all the associated functions.

That said, I have a C++ project on Windows that is nearly 100% portable.
The part that is not portable is mostly the synchronization elements. Every
year or so I take a cursory look at Linux's (Unix's) synchronization model,
and the process thread model, and...I guess you have heard it before - it's
simply not the same.

I have also seen various attempts on the web to create wrapper functions
that provide a Windows synchro API on Linux, but again, the result is never
quite the same. IBM, in their attempt and exposition, admits this. It is
clear, at least to me, that if one wants true ability to wait for any of
the various synchronization objects simultaneously, there needs to be
deliberate, explicit kernel support.

I was wondering:

   1. What is the likelihood that the guardians of the kernel would even
   allow something so fundamentally different inside?
   2. My gut feeling is that adding such support would fundamentally change


   other aspects of Linux. For example, I am vaguely familiar with asio, but
   to do it the way it was done in Windows...

Finally, this is not a situation where the end-game is having a kernel of
my own that has such support. Support would need to be pre-existing for the
users of my project.

Please note that I am not a Windows bigot trying to impose a
Microsoft-centric world-view on Linux. I think this facility transcends any
particular OS, and I feel that it is merely fortunate coincidence that the
Microsoft (DEC) engineers had the inclination to do it.

-Nut

--
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/4] clk: mvebu: fix clk init order

[Emilio López]

Hello Sebastian,

El 25/01/14 15:19, Sebastian Hesselbarth escribió:

This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.


The framework should be able to deal with unordered registration. I am 
not very familiar with the mvebu driver though, do you have a valid 
reason to require a specific order?



Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
registered before core clocks driver. Unfortunately, we cannot
return -EPROBE_DEFER in drivers initialized by clk_of_init.


Why would you need to do so? After a quick inspection on the code, I see 
you may have problems on mvebu_clk_gating_setup() when getting the 
default parent clock name, but I believe you could solve it in an easier 
way by using of_clk_get_parent_name().


Cheers,

Emilio
--
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] perf: design.txt: remove mention of set_perf_event_pending

[Baruch Siach]

set_perf_event_pending() was removed in e360adbe (irq_work: Add generic hardirq
context callbacks)

Signed-off-by: Baruch Siach 
---
Resending with lkml added to Cc.
---
 tools/perf/design.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/design.txt b/tools/perf/design.txt
index 67e5d0cace85..63a0e6f04a01 100644
--- a/tools/perf/design.txt
+++ b/tools/perf/design.txt
@@ -454,7 +454,6 @@ So to start with, in order to add HAVE_PERF_EVENTS to your 
Kconfig, you
 will need at least this:
- asm/perf_event.h - a basic stub will suffice at first
- support for atomic64 types (and associated helper functions)
-   - set_perf_event_pending() implemented
 
 If your architecture does have hardware capabilities, you can override the
 weak stub hw_perf_event_init() to register hardware counters.
-- 
1.8.5.2

--
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] misc: genwqe: Fix potential memory leak when pinning memory

[Christian Engelmayer]

Fix a memory leak in the genwqe_pin_mem() error path as called by
ioctl GENWQE_PIN_MEM. In case there is an error encountered when
mapping memory, the already allocated dma_mapping struct needs to
be freed correctly.

Detected by Coverity: CID 1162606.

Signed-off-by: Christian Engelmayer 
---
 drivers/misc/genwqe/card_dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/misc/genwqe/card_dev.c b/drivers/misc/genwqe/card_dev.c
index 8f8a6b3..2c2c9cc 100644
--- a/drivers/misc/genwqe/card_dev.c
+++ b/drivers/misc/genwqe/card_dev.c
@@ -787,6 +787,7 @@ static int genwqe_pin_mem(struct genwqe_file *cfile, struct 
genwqe_mem *m)
if (rc != 0) {
dev_err(_dev->dev,
"[%s] genwqe_user_vmap rc=%d\n", __func__, rc);
+   kfree(dma_map);
return rc;
}
 
-- 
1.8.3.2
--
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/4] clk: mvebu: fix clk init order

[Sebastian Hesselbarth]

On 01/25/2014 10:32 PM, Emilio López wrote:

El 25/01/14 15:19, Sebastian Hesselbarth escribió:

This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.


The framework should be able to deal with unordered registration. I am
not very familiar with the mvebu driver though, do you have a valid
reason to require a specific order?


Emilio,

I rather think that everthing registered with CLK_OF_DECLARE cannot
deal with unordered registration. The callback passed to CLK_OF_DECLARE
has to have void as return value, so there is no way to pass errors,
e.g. -EPROBE_DEFER, back to of_clk_init.

The reason for this ordering is that the clock gates depend on core
clocks. It is always that way, so merging both init functions isn't
that odd.


Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
registered before core clocks driver. Unfortunately, we cannot
return -EPROBE_DEFER in drivers initialized by clk_of_init.


Why would you need to do so? After a quick inspection on the code, I see
you may have problems on mvebu_clk_gating_setup() when getting the
default parent clock name, but I believe you could solve it in an easier
way by using of_clk_get_parent_name().


Ok, I'll look if using of_clk_get_parent_name will help here. But again,
I can see that clk-gating driver gets registered before core-clk driver.
There may be no code to give you the parent name at that time.

Sebastian

--
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] of: add vendor prefix for Honeywell

[Marek Belisko]

Signed-off-by: Marek Belisko 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 3f900cd..b14c617 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -40,6 +40,7 @@ gmt   Global Mixed-mode Technology, Inc.
 gumstixGumstix, Inc.
 haoyu  Haoyu Microelectronic Co. Ltd.
 hisilicon  Hisilicon Limited.
+honeywell  Honeywell
 hp Hewlett Packard
 ibmInternational Business Machines (IBM)
 idtIntegrated Device Technologies, Inc.
-- 
1.8.3.2

--
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: [ANNOUNCE] 3.12.8-rt11

[Mike Galbraith]

On Sat, 2014-01-25 at 14:45 +0100, Sebastian Andrzej Siewior wrote: 
> Dear RT folks!
> 
> I'm pleased to announce the v3.12.8-rt11 patch set.
> 
> Changes since v3.12.8-rt10
> - The "do not to raise the timer softirq unconditionally" resulted a few
>   boot lockups on a few boxes. Steven found the problem and sent a fix.
>   Thank you Steven.

That fix _appears_ to have fixed up the runtime lockups I was hitting on
64 core box as well.  I don't have nohz_full enabled atm, but the nmi
watchdog was reliably barking either way, and while box could remain up
for quite a while, it should have died by now.  I'll let it grind away
for the rest of the weekend.

-Mike

--
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] ARM: dts: omap3-gta04: Fix mmc1 properties.

[Marek Belisko]

Does not have an aux supply, and must be non-removable.

Otherwise it is removed during suspend and filesystem gets confused.

Signed-off-by: NeilBrown 
---
 arch/arm/boot/dts/omap3-gta04.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index e315675..6011151 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -149,8 +149,8 @@
pinctrl-names = "default";
pinctrl-0 = <_pins>;
vmmc-supply = <>;
-   vmmc_aux-supply = <>;
bus-width = <4>;
+   ti,non-removable;
 };
 
  {
-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Enable mmc2 for wifi.

[Marek Belisko]

From: NeilBrown 

This requires vaux4.

Reset line isn't used yet, so wifi isn't reliable.
But it does work once per boot.

Signed-off-by: NeilBrown 
---
 arch/arm/boot/dts/omap3-gta04.dts | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 6011151..7e09410 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -79,6 +79,11 @@
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <>;
+   vaux4: regulator-vaux4 {
+   compatible = "ti,twl4030-vaux4";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <315>;
+   };
};
 };
 
@@ -154,7 +159,9 @@
 };
 
  {
-   status = "disabled";
+   vmmc-supply = <>;
+   bus-width = <4>;
+   ti,non-removable;
 };
 
  {
-- 
1.8.3.2

--
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/9] ARM: dts: omap3-gta04: Various devicetree updates.

[Marek Belisko]

This pathes fix some wrong property issues and add some new devices to
devicetree. This was tested on linux-next (next-20140124).

Marek Belisko (6):
  ARM: dts: omap3-gta04: Fix mmc1 properties.
  ARM: dts: omap3-gta04: Add basic sound support.
  ARM: dts: omap3-gta04: Add twl4030 charger.
  ARM: dts: omap3-gta04: Add touchscreen properties.
  ARM: dts: omap3-gta04: Add support for magnetometer.
  ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid
problems with booting.

NeilBrown (3):
  ARM: dts: omap3-gta04: Fix 'aux' gpio key flags.
  ARM: dts: omap3-gta04: Add bma180 accelerometer.
  ARM: dts: omap3-gta04: Enable mmc2 for wifi.

 arch/arm/boot/dts/omap3-gta04.dts | 58 ---
 1 file changed, 54 insertions(+), 4 deletions(-)

-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Add twl4030 charger.

[Marek Belisko]

Signed-off-by: Marek Belisko 
---
 arch/arm/boot/dts/omap3-gta04.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index a924a843..f72e408 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -198,3 +198,7 @@
pinctrl-0 = <_pins>;
 };
 
+ {
+   bb_uvolt = <320>;
+   bb_uamp = <150>;
+};
-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Add bma180 accelerometer.

[Marek Belisko]

From: NeilBrown 

Signed-off-by: NeilBrown 
---
 arch/arm/boot/dts/omap3-gta04.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 9d37184..e315675 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -94,6 +94,14 @@
reg = <0x77>;
};
 
+   /* accelerometer */
+   bma180@41 {
+   compatible = "bosch,bma180";
+   reg = <0x41>;
+   interrupt-parent = <>;
+   interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+   };
+
/* leds */
tca6507@45 {
compatible = "ti,tca6507";
-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Add basic sound support.

[Marek Belisko]

Signed-off-by: NeilBrown 
---
 arch/arm/boot/dts/omap3-gta04.dts | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 7e09410..a924a843 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -36,6 +36,14 @@
gpio-key,wakeup;
};
};
+
+   sound {
+   compatible = "ti,omap-twl4030";
+   ti,model = "gta04";
+
+   ti,mcbsp = <>;
+   ti,codec = <_audio>;
+   };
 };
 
 _pmx_core {
@@ -79,6 +87,13 @@
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <>;
+
+   twl_audio: audio {
+   compatible = "ti,twl4030-audio";
+   codec {
+   };
+   };
+
vaux4: regulator-vaux4 {
compatible = "ti,twl4030-vaux4";
regulator-min-microvolt = <280>;
-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting.

[Marek Belisko]

Without that change booting leads to crash with more warnings like below:
[0.284454] omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
[0.284484] omap_hwmod: uart4: cannot _init_clocks
[0.284484] [ cut here ]
[0.284545] WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2543 
_init+0x300/0x3e4()
[0.284545] omap_hwmod: uart4: couldn't init clocks
[0.284576] Modules linked in:
[0.284606] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
3.13.0-next-20140124-00020-gd2aefec-dirty #26
[0.284637] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[0.284667] [] (show_stack) from [] 
(dump_stack+0x7c/0x94)
[0.284729] [] (dump_stack) from [] 
(warn_slowpath_common+0x6c/0x90)
[0.284729] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[0.284759] [] (warn_slowpath_fmt) from [] 
(_init+0x300/0x3e4)
[0.284790] [] (_init) from [] 
(__omap_hwmod_setup_all+0x40/0x8c)
[0.284820] [] (__omap_hwmod_setup_all) from [] 
(do_one_initcall+0xe8/0x14c)
[0.284851] [] (do_one_initcall) from [] 
(kernel_init_freeable+0x104/0x1c8)
[0.284881] [] (kernel_init_freeable) from [] 
(kernel_init+0x8/0x118)
[0.284912] [] (kernel_init) from [] 
(ret_from_fork+0x14/0x2c)
[0.285064] ---[ end trace 63de210ad43b627d ]---

Reference:
https://lkml.org/lkml/2013/10/8/553

Signed-off-by: Marek Belisko 
---
 arch/arm/boot/dts/omap3-gta04.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index ea1b94d..998fe1e 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -13,7 +13,7 @@
 
 / {
model = "OMAP3 GTA04";
-   compatible = "ti,omap3-gta04", "ti,omap3";
+   compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
 
cpus {
cpu@0 {
-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Add support for magnetometer.

[Marek Belisko]

Signed-off-by: NeilBrown 
---
 arch/arm/boot/dts/omap3-gta04.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index 151ed3b..ea1b94d 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -100,6 +100,12 @@
regulator-max-microvolt = <315>;
};
};
+
+   /* compass aka magnetometer */
+   hmc5843@1e {
+   compatible = "honeywell,hmc5843";
+   reg = <0x1e>;
+   };
 };
 
 #include "twl4030.dtsi"
-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Fix 'aux' gpio key flags.

[Marek Belisko]

From: NeilBrown 

It should be ACTIVE_HIGH.

Signed-off-by: NeilBrown 
---
 arch/arm/boot/dts/omap3-gta04.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index b9b55c9..9d37184 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -32,7 +32,7 @@
aux-button {
label = "aux";
linux,code = <169>;
-   gpios = < 7 GPIO_ACTIVE_LOW>;
+   gpios = < 7 GPIO_ACTIVE_HIGH>;
gpio-key,wakeup;
};
};
-- 
1.8.3.2

--
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] ARM: dts: omap3-gta04: Add touchscreen properties.

[Marek Belisko]

Signed-off-by: Marek Belisko 
---
 arch/arm/boot/dts/omap3-gta04.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-gta04.dts 
b/arch/arm/boot/dts/omap3-gta04.dts
index f72e408..151ed3b 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -150,6 +150,16 @@
reg = <0x4>;
};
};
+
+   /* touchscreen */
+   tsc2007@48 {
+   compatible = "ti,tsc2007";
+   reg = <0x48>;
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   ti,x-plate-ohms = <600>;
+   };
 };
 
  {
-- 
1.8.3.2

--
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] intel_idle: Add CPU model 54 (Atom N2000 series)

[Jan Kiszka]

From: Jan Kiszka 

Add CPU ID for Atom N2600/N2800 processors. Datasheets indicate support
for this, detailed information about potential quirks or limitations are
missing, though. So we just reuse the definition for the previous ATOM
series. Tests on N2800 systems showed that this addition is fine an can
reduce power consumption by about 0.25 W (personally confirmed on Intel
DN2800MT).

Signed-off-by: Jan Kiszka 
---
 drivers/idle/intel_idle.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 797ed29..6467fc9 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -503,6 +503,7 @@ static const struct x86_cpu_id intel_idle_ids[] = {
ICPU(0x2f, idle_cpu_nehalem),
ICPU(0x2a, idle_cpu_snb),
ICPU(0x2d, idle_cpu_snb),
+   ICPU(0x36, idle_cpu_atom),
ICPU(0x3a, idle_cpu_ivb),
ICPU(0x3e, idle_cpu_ivb),
ICPU(0x3c, idle_cpu_hsw),




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 0/5] ia64 ski emulator patches

[Mikael Pettersson]

Mikulas Patocka writes:
 > 
 > 
 > On Sat, 25 Jan 2014, Mikael Pettersson wrote:
 > 
 > > My ski patches are in 
 > > 
 > > for now.  I'll post the kernel patches to linux-ia64 @ vger in a few 
 > > minutes.
 > > 
 > > /Mikael
 > 
 > Thanks for the patches.
 > 
 > Isn't this subject to races? - could it lock up if the signal happens just 
 > before the pause syscall?
 > 
 > +case SSC_HALT_LIGHT:
 > +  /* Sleep until SIGIO or SIGALRM is received; this relies on
 > +keyboard/ethernet input being detected via SIGIO, and the
 > +ITC now being emulated via setitimer() and SIGALRM.  */
 > +  pause ();
 > +  break;
 > +

Thanks for the review. You're right, the pause mustn't happen if
itc_itimer_fired == 1.  Let me ponder this for a while...

/Mikael
--
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: [Xen-devel] [PATCH] xen-blkback: fix memory leak when persistent grants are used

[Matt Wilson]

On Fri, Jan 24, 2014 at 03:36:22PM +, Ian Campbell wrote:
> On Fri, 2014-01-24 at 09:21 +, Ian Campbell wrote:
> > On Thu, 2014-01-23 at 11:28 -0800, Matt Wilson wrote:
> > > From: Matt Rushton 
> > > 
> > > Currently shrink_free_pagepool() is called before the pages used for
> > > persistent grants are released via free_persistent_gnts(). This
> > > results in a memory leak when a VBD that uses persistent grants is
> > > torn down.
> > 
> > This may well be the explanation for the memory leak I was observing on
> > ARM last night. I'll give it a go and let you know.
> 
> Results are a bit inconclusive unfortunately, it seems like I am seeing
> some other leak too (or instead).
> 
> Totally unscientifically it does seem to be leaking more slowly than
> before, so perhaps this patch has helped, but nothing conclusive I'm
> afraid.

Testing here looks good. I don't know if perhaps something else is
going on with ARM...

> I don't think that quite qualifies for a Tested-by though, sorry.

How about an Acked-by? ;-)

--msw

> Ian. 
> 
> > 
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: "Roger Pau Monné" 
> > > Cc: Ian Campbell 
> > > Cc: David Vrabel 
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: xen-de...@lists.xen.org
> > > Cc: Anthony Liguori 
> > > Signed-off-by: Matt Rushton 
> > > Signed-off-by: Matt Wilson 
> > > ---
> > >  drivers/block/xen-blkback/blkback.c |6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/block/xen-blkback/blkback.c 
> > > b/drivers/block/xen-blkback/blkback.c
> > > index 6620b73..30ef7b3 100644
> > > --- a/drivers/block/xen-blkback/blkback.c
> > > +++ b/drivers/block/xen-blkback/blkback.c
> > > @@ -625,9 +625,6 @@ purge_gnt_list:
> > >   print_stats(blkif);
> > >   }
> > >  
> > > - /* Since we are shutting down remove all pages from the buffer */
> > > - shrink_free_pagepool(blkif, 0 /* All */);
> > > -
> > >   /* Free all persistent grant pages */
> > >   if (!RB_EMPTY_ROOT(>persistent_gnts))
> > >   free_persistent_gnts(blkif, >persistent_gnts,
> > > @@ -636,6 +633,9 @@ purge_gnt_list:
> > >   BUG_ON(!RB_EMPTY_ROOT(>persistent_gnts));
> > >   blkif->persistent_gnt_c = 0;
> > >  
> > > + /* Since we are shutting down remove all pages from the buffer */
> > > + shrink_free_pagepool(blkif, 0 /* All */);
> > > +
> > >   if (log_stats)
> > >   print_stats(blkif);
> > >  
> > 
> > 
> > 
> > ___
> > Xen-devel mailing list
> > xen-de...@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> 
--
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 TAKE 3] clk: si5351: remove variant from platform_data

[Sebastian Hesselbarth]

Commit 9807362bfe1748d9bb48eecb9261f1b1aaafea1c
  "clk: si5351: declare all device IDs for module loading"
removed the common i2c_device_id and introduced new ones for each variant
of the clock generator. Instead of exploiting that information in the driver,
it still depends on platform_data passing the chips .variant.

This removes the now redundant .variant from the platform_data and puts it in
i2c_device_id's .driver_data instead.

Signed-off-by: Sebastian Hesselbarth 
---
Mike,

this is the patch I mentioned during ARM summit ;). Still applies to
pre-v3.14-rc1 cleanly. Maybe it is time to take it now?

Cc: Mike Turquette 
Cc: Jason Cooper 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/clk-si5351.c |   28 
 drivers/clk/clk-si5351.h |   14 ++
 include/linux/platform_data/si5351.h |   16 
 3 files changed, 26 insertions(+), 32 deletions(-)

diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index c50e837..b95aa09 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -,11 +,11 @@ static const struct of_device_id si5351_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, si5351_dt_ids);
 
-static int si5351_dt_parse(struct i2c_client *client)
+static int si5351_dt_parse(struct i2c_client *client,
+  enum si5351_variant variant)
 {
struct device_node *child, *np = client->dev.of_node;
struct si5351_platform_data *pdata;
-   const struct of_device_id *match;
struct property *prop;
const __be32 *p;
int num = 0;
@@ -1124,15 +1124,10 @@ static int si5351_dt_parse(struct i2c_client *client)
if (np == NULL)
return 0;
 
-   match = of_match_node(si5351_dt_ids, np);
-   if (match == NULL)
-   return -EINVAL;
-
pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
 
-   pdata->variant = (enum si5351_variant)match->data;
pdata->clk_xtal = of_clk_get(np, 0);
if (!IS_ERR(pdata->clk_xtal))
clk_put(pdata->clk_xtal);
@@ -1163,7 +1158,7 @@ static int si5351_dt_parse(struct i2c_client *client)
pdata->pll_src[num] = SI5351_PLL_SRC_XTAL;
break;
case 1:
-   if (pdata->variant != SI5351_VARIANT_C) {
+   if (variant != SI5351_VARIANT_C) {
dev_err(>dev,
"invalid parent %d for pll %d\n",
val, num);
@@ -1187,7 +1182,7 @@ static int si5351_dt_parse(struct i2c_client *client)
}
 
if (num >= 8 ||
-   (pdata->variant == SI5351_VARIANT_A3 && num >= 3)) {
+   (variant == SI5351_VARIANT_A3 && num >= 3)) {
dev_err(>dev, "invalid clkout %d\n", num);
return -EINVAL;
}
@@ -1226,7 +1221,7 @@ static int si5351_dt_parse(struct i2c_client *client)
SI5351_CLKOUT_SRC_XTAL;
break;
case 3:
-   if (pdata->variant != SI5351_VARIANT_C) {
+   if (variant != SI5351_VARIANT_C) {
dev_err(>dev,
"invalid parent %d for clkout 
%d\n",
val, num);
@@ -1307,6 +1302,7 @@ static int si5351_dt_parse(struct i2c_client *client)
 static int si5351_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
+   enum si5351_variant variant = (enum si5351_variant)id->driver_data;
struct si5351_platform_data *pdata;
struct si5351_driver_data *drvdata;
struct clk_init_data init;
@@ -1315,7 +1311,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
u8 num_parents, num_clocks;
int ret, n;
 
-   ret = si5351_dt_parse(client);
+   ret = si5351_dt_parse(client, variant);
if (ret)
return ret;
 
@@ -1331,7 +1327,7 @@ static int si5351_i2c_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, drvdata);
drvdata->client = client;
-   drvdata->variant = pdata->variant;
+   drvdata->variant = variant;
drvdata->pxtal = pdata->clk_xtal;
drvdata->pclkin = pdata->clk_clkin;
 
@@ -1568,10 +1564,10 @@ static int si5351_i2c_probe(struct i2c_client *client,
 }
 
 static const struct i2c_device_id si5351_i2c_ids[] = {
-   { "si5351a", 0 },
-   { "si5351a-msop", 0 },
-   { "si5351b", 0 },
-   { "si5351c", 0 },
+   { "si5351a", SI5351_VARIANT_A },
+   { "si5351a-msop", SI5351_VARIANT_A3 },
+   { "si5351b", 

Re: [PATCH 0/5] ia64 ski emulator patches

[Mikulas Patocka]

On Sat, 25 Jan 2014, Mikael Pettersson wrote:

> My ski patches are in 
> 
> for now.  I'll post the kernel patches to linux-ia64 @ vger in a few minutes.
> 
> /Mikael

Thanks for the patches.

Isn't this subject to races? - could it lock up if the signal happens just 
before the pause syscall?

+case SSC_HALT_LIGHT:
+  /* Sleep until SIGIO or SIGALRM is received; this relies on
+keyboard/ethernet input being detected via SIGIO, and the
+ITC now being emulated via setitimer() and SIGALRM.  */
+  pause ();
+  break;
+

Mikulas
--
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] usb: phy: Quiet unable to find transceiver message

[Josh Boyer]

On Sat, Jan 25, 2014 at 10:37 AM, Alan Stern  wrote:
> On Sat, 25 Jan 2014, Josh Boyer wrote:
>
>> commit 1ae5799ef6317 ("usb: hcd: Initialize USB phy if needed") allows
>> the USB layer to initialize external PHYs if needed.  However, a PHY is
>> not needed in all cases.  The usb_get_phy_device function will print
>> an error message, "unable to find transceiver" but everything still
>> functions normally.
>>
>> Drop the severity of this message to pr_debug.
>>
>> Signed-off-by: Josh Boyer 
>> ---
>>  drivers/usb/phy/phy.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
>> index e6f61e4..c7fe880 100644
>> --- a/drivers/usb/phy/phy.c
>> +++ b/drivers/usb/phy/phy.c
>> @@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev, u8 
>> index)
>>
>>   phy = __usb_find_phy_dev(dev, _bind_list, index);
>>   if (IS_ERR(phy) || !try_module_get(phy->dev->driver->owner)) {
>> - pr_err("unable to find transceiver\n");
>> + pr_debug("unable to find transceiver\n");
>>   goto err0;
>>   }
>
> Wouldn't it make more sense to change this to dev_debug?  As it stands,
> the user has no idea which device is lacking a transceiver.

Quite possibly, yes.  I'm not overly familiar with the subsystem and
was just writing up what Felipe suggested.

> (The same is probably true for other log messages in this source file.)

I don't disagree, but I'd rather someone with more experience in the
USB subsystem do that kind of broader audit/change.  I'd be happy to
test.

josh
--
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] virtio_balloon: don't call virtio_has_feature() twice on init_vqs()

[Leandro Dorileo]

Cchange init_vqs() to avoid calling twice the virtio_has_feature()
- attempting to find out if VIRTIO_BALLOON_F_STATS_VQ feature was negotiated -
consequently we prevent unnecessarily running the drivers' feature_table more
than needed.

Signed-off-by: Leandro Dorileo 
---
 drivers/virtio/virtio_balloon.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 34bdaba..41771c1 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -320,19 +320,21 @@ static int init_vqs(struct virtio_balloon *vb)
vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request 
};
const char *names[] = { "inflate", "deflate", "stats" };
int err, nvqs;
+   bool stats;
 
/*
 * We expect two virtqueues: inflate and deflate, and
 * optionally stat.
 */
-   nvqs = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ) ? 3 : 2;
+   stats = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ);
+   nvqs = stats ? 3 : 2;
err = vb->vdev->config->find_vqs(vb->vdev, nvqs, vqs, callbacks, names);
if (err)
return err;
 
vb->inflate_vq = vqs[0];
vb->deflate_vq = vqs[1];
-   if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
+   if (stats) {
struct scatterlist sg;
vb->stats_vq = vqs[2];
 
-- 
1.8.5.3

--
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 V2 1/4] pci: APM X-Gene PCIe controller driver

[Arnd Bergmann]

On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar  wrote:
> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann  wrote:
> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:

> >>
> >>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32 
> >>> *lanes)
> >>> +{
> >>> + void *csr_base = port->csr_base;
> >>> + u32 val32;
> >>> + u64 start_time, time;
> >>> +
> >>> + /*
> >>> +  * A component enters the LTSSM Detect state within
> >>> +  * 20ms of the end of fundamental core reset.
> >>> +  */
> >>> + msleep(XGENE_LTSSM_DETECT_WAIT);
> >>> + port->link_up = 0;
> >>> + start_time = jiffies;
> >>> + do {
> >>> + val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
> >>> + if (val32 & LINK_UP_MASK) {
> >>> + port->link_up = 1;
> >>> + port->link_speed = PIPE_PHY_RATE_RD(val32);
> >>> + val32 = readl(csr_base + BRIDGE_STATUS_0);
> >>> + *lanes = val32 >> 26;
> >>> + }
> >>> + time = jiffies_to_msecs(jiffies - start_time);
> >>> + } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
> >>> +}
> >>
> >> Maybe another msleep() in the loop? It seems weird to first do an
> >> unconditional sleep but then busy-wait for the result.
> >
> > ok.
> 
> This loop can execute for maximum 4 msec. So putting msleep(1) won't
> get us much.
 
4 msec is still quite a long time for a busy loop that can be spent doing
useful work in another thread.

> >>
> >> Another general note: Your "compatible" strings are rather unspecific.
> >> Do you have a version number for this IP block? I suppose that it's related
> >> to one that has been used in other chips before, or will be used in future
> >> chips, if it's not actually licensed from some other company.
> >
> > I will have to check this.
> >
> 
> We have decided to stick with current compatible string for now.

Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
product and you won't be doing any new chips based on the same hardware
components?

Arnd
--
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] Input: i8042-io - Exclude mips platforms when allocating/deallocating IO regions.

[Raghu Gandham]

The standard IO regions are already reserved by the platform code on most MIPS
devices(malta, cobalt, sni). The Commit 197a1e96c8be5b6005145af3a4c0e45e2d651444
("Input: i8042-io - fix up region handling on MIPS") introduced a bug on these
MIPS platforms causing i8042 driver to fail when trying to reserve IO ports.
Prior to the above mentioned commit request_region is skipped on MIPS but
release_region is called.

This patch reverts commit 197a1e96c8be5b6005145af3a4c0e45e2d651444 and also
avoids calling release_region for MIPS.

Signed-off-by: Raghu Gandham 
Reviewed-by: Steven J. Hill 
---
 drivers/input/serio/i8042-io.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
index a5eed2a..a09bb72 100644
--- a/drivers/input/serio/i8042-io.h
+++ b/drivers/input/serio/i8042-io.h
@@ -76,7 +76,7 @@ static inline int i8042_platform_init(void)
if (check_legacy_ioport(I8042_DATA_REG))
return -ENODEV;
 #endif
-#if !defined(__sh__) && !defined(__alpha__)
+#if !defined(__sh__) && !defined(__alpha__) && !defined(__mips__)
if (!request_region(I8042_DATA_REG, 16, "i8042"))
return -EBUSY;
 #endif
@@ -87,7 +87,7 @@ static inline int i8042_platform_init(void)
 
 static inline void i8042_platform_exit(void)
 {
-#if !defined(__sh__) && !defined(__alpha__)
+#if !defined(__sh__) && !defined(__alpha__) && !defined(__mips__)
release_region(I8042_DATA_REG, 16);
 #endif
 }
-- 
1.8.5.2


--
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 01/11] devicetree: binding: add missing Marvell Dove SoC documentation

[Sebastian Hesselbarth]

Marvell Dove SoC binding was not documented, yet. Add the documentation
and also describe Global Configuration register node in it.

Signed-off-by: Sebastian Hesselbarth 
---
I chose not to send this to each DT maintainer but devicetree ml only.
Is that right or wrong now?

Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 .../devicetree/bindings/arm/marvell,dove.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell,dove.txt

diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt 
b/Documentation/devicetree/bindings/arm/marvell,dove.txt
new file mode 100644
index ..aaaf64c56e44
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,dove.txt
@@ -0,0 +1,22 @@
+Marvell Dove Platforms Device Tree Bindings
+---
+
+Boards with a Marvell Dove SoC shall have the following properties:
+
+Required root node property:
+- compatible: must contain "marvell,dove";
+
+* Global Configuration registers
+
+Global Configuration registers of Dove SoC are shared by a syscon node.
+
+Required properties:
+- compatible: must contain "marvell,dove-global-config" and "syscon".
+- reg: base address and size of the Global Configuration registers.
+
+Example:
+
+gconf: global-config@e802c {
+   compatible = "marvell,dove-global-config", "syscon";
+   reg = <0xe802c 0x14>;
+};
-- 
1.8.5.2

--
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 05/11] pinctrl: mvebu: fix misdesigned resource allocation

[Sebastian Hesselbarth]

Allocating the pinctrl resource in common pinctrl-mvebu was a misdesign,
as it does not allow SoC specific parts to access the allocated resource.
This moves resource allocation from mvebu_pinctrl_probe to SoC specific
_probe functions and passes the base address to common pinctrl driver
instead.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-armada-370.c |  9 -
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c  |  9 -
 drivers/pinctrl/mvebu/pinctrl-dove.c   | 10 +-
 drivers/pinctrl/mvebu/pinctrl-kirkwood.c   | 10 +-
 drivers/pinctrl/mvebu/pinctrl-mvebu.c  | 14 ++
 drivers/pinctrl/mvebu/pinctrl-mvebu.h  |  2 +-
 6 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-370.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
index ae1f760cbdd2..4f6a65b32f06 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-370.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-370.c
@@ -385,6 +385,13 @@ static struct pinctrl_gpio_range 
mv88f6710_mpp_gpio_ranges[] = {
 static int armada_370_pinctrl_probe(struct platform_device *pdev)
 {
struct mvebu_pinctrl_soc_info *soc = _370_pinctrl_info;
+   struct resource *res;
+   void __iomem *base;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
 
soc->variant = 0; /* no variants for Armada 370 */
soc->controls = mv88f6710_mpp_controls;
@@ -396,7 +403,7 @@ static int armada_370_pinctrl_probe(struct platform_device 
*pdev)
 
pdev->dev.platform_data = soc;
 
-   return mvebu_pinctrl_probe(pdev);
+   return mvebu_pinctrl_probe(pdev, base);
 }
 
 static int armada_370_pinctrl_remove(struct platform_device *pdev)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
index 843a51f9d129..e4be7ab4c948 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-xp.c
@@ -399,10 +399,17 @@ static int armada_xp_pinctrl_probe(struct platform_device 
*pdev)
struct mvebu_pinctrl_soc_info *soc = _xp_pinctrl_info;
const struct of_device_id *match =
of_match_device(armada_xp_pinctrl_of_match, >dev);
+   struct resource *res;
+   void __iomem *base;
 
if (!match)
return -ENODEV;
 
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
soc->variant = (unsigned) match->data & 0xff;
 
switch (soc->variant) {
@@ -443,7 +450,7 @@ static int armada_xp_pinctrl_probe(struct platform_device 
*pdev)
 
pdev->dev.platform_data = soc;
 
-   return mvebu_pinctrl_probe(pdev);
+   return mvebu_pinctrl_probe(pdev, base);
 }
 
 static int armada_xp_pinctrl_remove(struct platform_device *pdev)
diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c 
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 47268393af34..f4141e60a52b 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -776,6 +776,14 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
 {
const struct of_device_id *match =
of_match_device(dove_pinctrl_of_match, >dev);
+   struct resource *res;
+   void __iomem *base;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
pdev->dev.platform_data = (void *)match->data;
 
/*
@@ -789,7 +797,7 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
}
clk_prepare_enable(clk);
 
-   return mvebu_pinctrl_probe(pdev);
+   return mvebu_pinctrl_probe(pdev, base);
 }
 
 static int dove_pinctrl_remove(struct platform_device *pdev)
diff --git a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c 
b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
index 6b504b5935a5..e515288bde35 100644
--- a/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
+++ b/drivers/pinctrl/mvebu/pinctrl-kirkwood.c
@@ -458,8 +458,16 @@ static int kirkwood_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(kirkwood_pinctrl_of_match, >dev);
+   struct resource *res;
+   void __iomem *base;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
pdev->dev.platform_data = (void *)match->data;
-   return mvebu_pinctrl_probe(pdev);
+   return mvebu_pinctrl_probe(pdev, base);
 }
 
 static int 

[PATCH 00/11] pinctrl: mvebu: remove hardcoded addresses from Dove pinctrl

[Sebastian Hesselbarth]

This patch set is one required step for Dove to hop into mach-mvebu.
Until now, pinctrl-dove was hardcoding some registers that do not
directly belong to MPP core registers. This is not compatible with
what we want for mach-mvebu.

This patch set removes all hardcoded addresses from pinctrl-dove
by either requesting additional resources or requesting a syscon
provided regmap for global config registers. As this changes existing
driver to DT binding relationship, all additional resources are
probed in a backward compatible way. If the corresponding resource
cannot be found, we derive it from the existing pinctrl resource
and warn about the old DTB firmware.

Patch 1 and 2 add or update binding documentation for dove, global
config syscon, and pinctrl-dove. The latter also documents missing reg
property requirement for other mvebu pinctrl nodes.

Patch 3 and 4 add the new pinctrl reg property values and global config
register syscon to exisiting dove.dtsi.

Patch 5 fixes a misdesign of common mvebu pinctrl driver, that
requested the resource instead of getting it from the SoC specific
driver stub.

Patches 6 and 7 now add requests to the new resources in a backward
compatible way, while patches 8-11 make use of those resources.

At the end, there is no more hardcoded addresses in pinctrl-dove.

The patch set is based on pre-v3.14-rc1 mainline. I suggest to take
this in as v3.15 stuff. Since more Dove/mach-mvebu related patches
will likely follow, Jason should prepare a topic branch for LinusW
to pull from?

It has been boot tested on Dove and compile tested only for Kirkwood,
Armada 370 and XP.

Sebastian Hesselbarth (11):
  devicetree: binding: add missing Marvell Dove SoC documentation
  devicetree: bindings: update MVEBU pinctrl binding documentation
  ARM: dove: add additional pinctrl registers
  ARM: dove: add global-config register node
  pinctrl: mvebu: fix misdesigned resource allocation
  pinctrl: mvebu: dove: request additional resources
  pinctrl: mvebu: dove: request syscon regmap for global registers
  pinctrl: mvebu: dove: use remapped mpp base registers
  pinctrl: mvebu: dove: use remapped mpp4 register
  pinctrl: mvebu: dove: use remapped pmu_mpp registers
  pinctrl: mvebu: dove: use global register regmap

 .../devicetree/bindings/arm/marvell,dove.txt   |  22 ++
 .../pinctrl/marvell,armada-370-pinctrl.txt |   1 +
 .../bindings/pinctrl/marvell,armada-xp-pinctrl.txt |   1 +
 .../bindings/pinctrl/marvell,dove-pinctrl.txt  |   1 +
 .../bindings/pinctrl/marvell,kirkwood-pinctrl.txt  |   1 +
 .../bindings/pinctrl/marvell,mvebu-pinctrl.txt |   2 +-
 arch/arm/boot/dts/dove.dtsi|  10 +-
 drivers/pinctrl/mvebu/Kconfig  |   1 +
 drivers/pinctrl/mvebu/pinctrl-armada-370.c |   9 +-
 drivers/pinctrl/mvebu/pinctrl-armada-xp.c  |   9 +-
 drivers/pinctrl/mvebu/pinctrl-dove.c   | 298 +
 drivers/pinctrl/mvebu/pinctrl-kirkwood.c   |  10 +-
 drivers/pinctrl/mvebu/pinctrl-mvebu.c  |  14 +-
 drivers/pinctrl/mvebu/pinctrl-mvebu.h  |   2 +-
 14 files changed, 254 insertions(+), 127 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell,dove.txt

---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Russell King 
Cc: Linus Walleij 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
-- 
1.8.5.2

--
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 06/11] pinctrl: mvebu: dove: request additional resources

[Sebastian Hesselbarth]

Dove pinctrl also requires additional registers to control all pins.
This patch requests resources for mpp4 and pmu-mpp register ranges.
As this changes DT to driver requirements, fallback to hardcoded
resources, if the corresponding DT regs have not been set.
Also, WARN about old DT binding usage to encourage users to update
their DTBs.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-dove.c | 52 +++-
 1 file changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c 
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index f4141e60a52b..3f34975c441f 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -22,6 +22,11 @@
 
 #include "pinctrl-mvebu.h"
 
+/* Internal registers can be configured at any 1 MiB aligned address */
+#define INT_REGS_MASK  ~(SZ_1M - 1)
+#define MPP4_REGS_OFFS 0xd0440
+#define PMU_REGS_OFFS  0xd802c
+
 #define DOVE_SB_REGS_VIRT_BASE IOMEM(0xfde0)
 #define DOVE_MPP_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0200)
 #define DOVE_PMU_MPP_GENERAL_CTRL  (DOVE_MPP_VIRT_BASE + 0x10)
@@ -55,6 +60,10 @@
 
 #define CONFIG_PMU BIT(4)
 
+static void __iomem *mpp_base;
+static void __iomem *mpp4_base;
+static void __iomem *pmu_base;
+
 static int dove_pmu_mpp_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 unsigned long *config)
 {
@@ -776,13 +785,42 @@ static int dove_pinctrl_probe(struct platform_device 
*pdev)
 {
const struct of_device_id *match =
of_match_device(dove_pinctrl_of_match, >dev);
-   struct resource *res;
-   void __iomem *base;
+   struct resource *mpp_res, *res;
+   struct resource res_fallback;
+
+   mpp_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mpp_base = devm_ioremap_resource(>dev, mpp_res);
+   if (IS_ERR(mpp_base))
+   return PTR_ERR(mpp_base);
+
+   /* prepare fallback resource */
+   memcpy(_fallback, mpp_res, sizeof(struct resource));
+   res_fallback.start = 0;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res) {
+   dev_warn(>dev, "falling back to hardcoded MPP4 
resource\n");
+   adjust_resource(_fallback,
+   (mpp_res->start & INT_REGS_MASK) + MPP4_REGS_OFFS, 0x4);
+   res = _fallback;
+   }
+   mpp4_base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(mpp4_base))
+   return PTR_ERR(mpp4_base);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   if (!res) {
+   dev_warn(>dev, "falling back to hardcoded PMU 
resource\n");
+   adjust_resource(_fallback,
+   (mpp_res->start & INT_REGS_MASK) + PMU_REGS_OFFS, 0x8);
+   res = _fallback;
+   }
+   pmu_base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(pmu_base))
+   return PTR_ERR(pmu_base);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   base = devm_ioremap_resource(>dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   /* Warn on any missing DT resource */
+   WARN(res_fallback.start, "Missing pinctrl regs in DTB. Please update 
your firmware.\n");
 
pdev->dev.platform_data = (void *)match->data;
 
@@ -797,7 +835,7 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
}
clk_prepare_enable(clk);
 
-   return mvebu_pinctrl_probe(pdev, base);
+   return mvebu_pinctrl_probe(pdev, mpp_base);
 }
 
 static int dove_pinctrl_remove(struct platform_device *pdev)
-- 
1.8.5.2

--
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 02/11] devicetree: bindings: update MVEBU pinctrl binding documentation

[Sebastian Hesselbarth]

Dove pinctrl binding now requires three different reg properties. This
updates corresponding binding and example accordingly. While at it, also
document reg property as required for the other MVEBU SoC pinctrl nodes.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 .../devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt  | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt  | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt  | 1 +
 Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt | 2 +-
 5 files changed, 5 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
index 01ef408e205f..adda2a8d1d52 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
@@ -5,6 +5,7 @@ part and usage.
 
 Required properties:
 - compatible: "marvell,88f6710-pinctrl"
+- reg: register specifier of MPP registers
 
 Available mpp pins/groups and functions:
 Note: brackets (x) are not part of the mpp name for marvell,function and given
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
index bfa0a2e5e0cb..373dbccd7ab0 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -6,6 +6,7 @@ part and usage.
 Required properties:
 - compatible: "marvell,mv78230-pinctrl", "marvell,mv78260-pinctrl",
   "marvell,mv78460-pinctrl"
+- reg: register specifier of MPP registers
 
 This driver supports all Armada XP variants, i.e. mv78230, mv78260, and 
mv78460.
 
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
index 50ec3512a292..cf52477cc7ee 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
@@ -6,6 +6,7 @@ part and usage.
 Required properties:
 - compatible: "marvell,dove-pinctrl"
 - clocks: (optional) phandle of pdma clock
+- reg: register specifiers of MPP, MPP4, and PMU MPP registers
 
 Available mpp pins/groups and functions:
 Note: brackets (x) are not part of the mpp name for marvell,function and given
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
index 95daf6335c37..730444a9a4de 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
@@ -8,6 +8,7 @@ Required properties:
   "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
   "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
   "marvell,98dx4122-pinctrl"
+- reg: register specifier of MPP registers
 
 This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x.
 It also support the 88f6281-based variant in the 98dx412x Bobcat SoCs.
diff --git 
a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
index 0a26c3aa4e6d..0c09f4eb2af0 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
@@ -37,7 +37,7 @@ uart1: serial@12100 {
 
 pinctrl: pinctrl@d0200 {
compatible = "marvell,dove-pinctrl";
-   reg = <0xd0200 0x20>;
+   reg = <0xd0200 0x14>, <0xd0440 0x04>, <0xd802c 0x08>;
 
pmx_uart1_sw: pmx-uart1-sw {
marvell,pins = "mpp_uart1";
-- 
1.8.5.2

--
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 07/11] pinctrl: mvebu: dove: request syscon regmap for global registers

[Sebastian Hesselbarth]

Dove pinctrl uses some global config registers to control pins.
This patch requests a syscon regmap for those registers. As this
changes DT to driver requirements, fallback to a self-registered
regmap with hardcoded resources, if the corresponding syscon DT
node is missing. Also, WARN about old DT binding usage to encourage
users to update their DTBs.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/Kconfig|  1 +
 drivers/pinctrl/mvebu/pinctrl-dove.c | 27 +++
 2 files changed, 28 insertions(+)

diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig
index 366fa541ee91..8dc4948c1202 100644
--- a/drivers/pinctrl/mvebu/Kconfig
+++ b/drivers/pinctrl/mvebu/Kconfig
@@ -8,6 +8,7 @@ config PINCTRL_MVEBU
 config PINCTRL_DOVE
bool
select PINCTRL_MVEBU
+   select MFD_SYSCON
 
 config PINCTRL_KIRKWOOD
bool
diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c 
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 3f34975c441f..d2ad130ba21e 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -18,7 +18,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "pinctrl-mvebu.h"
 
@@ -26,6 +28,7 @@
 #define INT_REGS_MASK  ~(SZ_1M - 1)
 #define MPP4_REGS_OFFS 0xd0440
 #define PMU_REGS_OFFS  0xd802c
+#define GC_REGS_OFFS   0xe802c
 
 #define DOVE_SB_REGS_VIRT_BASE IOMEM(0xfde0)
 #define DOVE_MPP_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0200)
@@ -63,6 +66,7 @@
 static void __iomem *mpp_base;
 static void __iomem *mpp4_base;
 static void __iomem *pmu_base;
+static struct regmap *gconfmap;
 
 static int dove_pmu_mpp_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 unsigned long *config)
@@ -781,6 +785,13 @@ static struct of_device_id dove_pinctrl_of_match[] = {
{ }
 };
 
+static struct regmap_config gc_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 32,
+   .reg_stride = 4,
+   .max_register = 5,
+};
+
 static int dove_pinctrl_probe(struct platform_device *pdev)
 {
const struct of_device_id *match =
@@ -819,6 +830,22 @@ static int dove_pinctrl_probe(struct platform_device *pdev)
if (IS_ERR(pmu_base))
return PTR_ERR(pmu_base);
 
+   gconfmap = 
syscon_regmap_lookup_by_compatible("marvell,dove-global-config");
+   if (IS_ERR(gconfmap)) {
+   void __iomem *gc_base;
+
+   dev_warn(>dev, "falling back to hardcoded global 
registers\n");
+   adjust_resource(_fallback,
+   (mpp_res->start & INT_REGS_MASK) + GC_REGS_OFFS, 0x14);
+   gc_base = devm_ioremap_resource(>dev, _fallback);
+   if (IS_ERR(gc_base))
+   return PTR_ERR(gc_base);
+   gconfmap = devm_regmap_init_mmio(>dev,
+gc_base, _regmap_config);
+   if (IS_ERR(gconfmap))
+   return PTR_ERR(gconfmap);
+   }
+
/* Warn on any missing DT resource */
WARN(res_fallback.start, "Missing pinctrl regs in DTB. Please update 
your firmware.\n");
 
-- 
1.8.5.2

--
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 03/11] ARM: dove: add additional pinctrl registers

[Sebastian Hesselbarth]

Dove pinctrl used additional registers to control MPPs. This patch first
increases existing pinctrl reg property by one register, and then adds
two new ranges for MPP4 and PMU MPP registers.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Russell King 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 8de1031233ae..69405e00f2c8 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -392,7 +392,9 @@
 
pinctrl: pin-ctrl@d0200 {
compatible = "marvell,dove-pinctrl";
-   reg = <0xd0200 0x10>;
+   reg = <0xd0200 0x14>,
+ <0xd0440 0x04>,
+ <0xd802c 0x08>;
clocks = <_clk 22>;
 
pmx_gpio_0: pmx-gpio-0 {
-- 
1.8.5.2

--
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 - v3.10.27] sit: Bad list pointer

[Steven Rostedt]

On 3.10.27, loading and then unloading the sit module gives me the
following bug:

[   35.400878] sit: IPv6 over IPv4 tunneling driver
[   36.959308] [ cut here ]
[   36.963983] WARNING: at 
/home/rostedt/work/git/linux-rt.git/lib/list_debug.c:59 
__list_del_entry+0xa1/0xd0()
[   36.973874] list_del corruption. prev->next should be 88011656d070, but 
was 880115fe5ea8
[   36.982684] Modules linked in: sit(-) ip_tunnel tunnel4 bnep lockd bluetooth 
nf_conntrack_ipv4 ip6t_REJECT nf_defrag_ipv4 nf_conntrack_ipv6 nf_defrag_ipv6 
xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_intel snd_hda_codec tpm_infineon snd_hwdep hp_wmi 
rfkill tpm_tis tpm coretemp snd_seq lpc_ich snd_seq_device snd_pcm 
sparse_keymap uinput serio_raw pcspkr mfd_core tpm_bios i2c_i801 microcode wmi 
snd_page_alloc snd_timer snd soundcore i915 e1000e i2c_algo_bit ptp 
drm_kms_helper crc32c_intel drm pps_core i2c_core video sunrpc
[   37.034430] CPU: 0 PID: 1071 Comm: rmmod Not tainted 3.10.27-test #143
[   37.040972] Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS 
K01 v02.05 05/07/2012
[   37.049962]  81a10e78 880115fe5d18 8161b3c7 
880115fe5d58
[   37.057439]  8104b2a0 880115fe5dd8 880115fe5df8 
88011656d070
[   37.064911]  0080 0018 880115cb4000 
880115fe5db8
[   37.072405] Call Trace:
[   37.074869]  [] dump_stack+0x19/0x1b
[   37.080031]  [] warn_slowpath_common+0x70/0xa0
[   37.086051]  [] warn_slowpath_fmt+0x46/0x50
[   37.091814]  [] __list_del_entry+0xa1/0xd0
[   37.097491]  [] unregister_netdevice_queue+0x35/0xa0
[   37.104036]  [] sit_exit_net+0xc2/0xf0 [sit]
[   37.109893]  [] ops_exit_list.isra.4+0x38/0x60
[   37.115917]  [] unregister_pernet_operations+0x70/0xb0
[   37.122633]  [] unregister_pernet_device+0x2e/0x60
[   37.129005]  [] sit_cleanup+0x2d/0x7be [sit]
[   37.134864]  [] SyS_delete_module+0x19e/0x2a0
[   37.140801]  [] tracesys+0xdd/0xe2
[   37.145779] ---[ end trace e45e22e840e55d00 ]---
[   37.150427] [ cut here ]

Investigating differences between 3.10.27 and newer kernels, I found
that the below change is not there. It was part of commit 205983c43700
"sit: allow to use rtnl ops on fb tunnel" which happens to be
backported to 3.10 but in 3.10 backport commit 20300db1bd1b9 this part
of the commit is missing.

When I add this change, the removing of the module no longer gives this
bug.

Signed-off-by: Steven Rostedt 

diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 0491264..02300e8 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1592,7 +1592,6 @@ static void __net_exit sit_exit_net(struct net *net)
 
rtnl_lock();
sit_destroy_tunnels(sitn, );
-   unregister_netdevice_queue(sitn->fb_tunnel_dev, );
unregister_netdevice_many();
rtnl_unlock();
 }
--
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 09/11] pinctrl: mvebu: dove: use remapped mpp4 register

[Sebastian Hesselbarth]

Now that we have an ioremapped mpp4 register, get rid of hardcoded
physical addresses. While at it, also remove DOVE_ prefix from those
macros.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-dove.c | 54 +++-
 1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c 
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 79106e7ecdd0..0c7616e086b2 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -46,18 +46,20 @@
 #define  DOVE_AU1_SPDIFO_GPIO_EN   BIT(1)
 #define  DOVE_NAND_GPIO_EN BIT(0)
 #define DOVE_GPIO_LO_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0400)
-#define DOVE_MPP_CTRL4_VIRT_BASE   (DOVE_GPIO_LO_VIRT_BASE + 0x40)
-#define  DOVE_SPI_GPIO_SEL BIT(5)
-#define  DOVE_UART1_GPIO_SEL   BIT(4)
-#define  DOVE_AU1_GPIO_SEL BIT(3)
-#define  DOVE_CAM_GPIO_SEL BIT(2)
-#define  DOVE_SD1_GPIO_SEL BIT(1)
-#define  DOVE_SD0_GPIO_SEL BIT(0)
 
 /* MPP Base registers */
 #define PMU_MPP_GENERAL_CTRL   0x10
 #define  AU0_AC97_SEL  BIT(16)
 
+/* MPP Control 4 register */
+#define MPP_CTRL4  0x40
+#define  SPI_GPIO_SEL  BIT(5)
+#define  UART1_GPIO_SELBIT(4)
+#define  AU1_GPIO_SEL  BIT(3)
+#define  CAM_GPIO_SEL  BIT(2)
+#define  SD1_GPIO_SEL  BIT(1)
+#define  SD0_GPIO_SEL  BIT(0)
+
 #define MPPS_PER_REG   8
 #define MPP_BITS   4
 #define MPP_MASK   0xf
@@ -117,24 +119,24 @@ static int dove_pmu_mpp_ctrl_set(struct mvebu_mpp_ctrl 
*ctrl,
 static int dove_mpp4_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
  unsigned long *config)
 {
-   unsigned long mpp4 = readl(DOVE_MPP_CTRL4_VIRT_BASE);
+   unsigned long mpp4 = readl(mpp4_base + MPP_CTRL4);
unsigned long mask;
 
switch (ctrl->pid) {
case 24: /* mpp_camera */
-   mask = DOVE_CAM_GPIO_SEL;
+   mask = CAM_GPIO_SEL;
break;
case 40: /* mpp_sdio0 */
-   mask = DOVE_SD0_GPIO_SEL;
+   mask = SD0_GPIO_SEL;
break;
case 46: /* mpp_sdio1 */
-   mask = DOVE_SD1_GPIO_SEL;
+   mask = SD1_GPIO_SEL;
break;
case 58: /* mpp_spi0 */
-   mask = DOVE_SPI_GPIO_SEL;
+   mask = SPI_GPIO_SEL;
break;
case 62: /* mpp_uart1 */
-   mask = DOVE_UART1_GPIO_SEL;
+   mask = UART1_GPIO_SEL;
break;
default:
return -EINVAL;
@@ -148,24 +150,24 @@ static int dove_mpp4_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 static int dove_mpp4_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
  unsigned long config)
 {
-   unsigned long mpp4 = readl(DOVE_MPP_CTRL4_VIRT_BASE);
+   unsigned long mpp4 = readl(mpp4_base + MPP_CTRL4);
unsigned long mask;
 
switch (ctrl->pid) {
case 24: /* mpp_camera */
-   mask = DOVE_CAM_GPIO_SEL;
+   mask = CAM_GPIO_SEL;
break;
case 40: /* mpp_sdio0 */
-   mask = DOVE_SD0_GPIO_SEL;
+   mask = SD0_GPIO_SEL;
break;
case 46: /* mpp_sdio1 */
-   mask = DOVE_SD1_GPIO_SEL;
+   mask = SD1_GPIO_SEL;
break;
case 58: /* mpp_spi0 */
-   mask = DOVE_SPI_GPIO_SEL;
+   mask = SPI_GPIO_SEL;
break;
case 62: /* mpp_uart1 */
-   mask = DOVE_UART1_GPIO_SEL;
+   mask = UART1_GPIO_SEL;
break;
default:
return -EINVAL;
@@ -175,7 +177,7 @@ static int dove_mpp4_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
if (config)
mpp4 |= mask;
 
-   writel(mpp4, DOVE_MPP_CTRL4_VIRT_BASE);
+   writel(mpp4, mpp4_base + MPP_CTRL4);
 
return 0;
 }
@@ -230,13 +232,13 @@ static int dove_audio0_ctrl_set(struct mvebu_mpp_ctrl 
*ctrl,
 static int dove_audio1_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
unsigned long *config)
 {
-   unsigned long mpp4 = readl(DOVE_MPP_CTRL4_VIRT_BASE);
+   unsigned long mpp4 = readl(mpp4_base + MPP_CTRL4);
unsigned long sspc1 = readl(DOVE_SSP_CTRL_STATUS_1);
unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
 
*config = 0;
-   if (mpp4 & DOVE_AU1_GPIO_SEL)
+   if (mpp4 & AU1_GPIO_SEL)
*config |= BIT(3);
if (sspc1 & DOVE_SSP_ON_AU1)
*config |= BIT(2);
@@ -257,7 +259,7 @@ static int dove_audio1_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 static int 

[PATCH 08/11] pinctrl: mvebu: dove: use remapped mpp base registers

[Sebastian Hesselbarth]

Now that we have ioremapped mpp base registers, get rid of hardcoded
physical addresses. While at it, also remove DOVE_ prefix from those
macros.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-dove.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c 
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index d2ad130ba21e..79106e7ecdd0 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -31,9 +31,6 @@
 #define GC_REGS_OFFS   0xe802c
 
 #define DOVE_SB_REGS_VIRT_BASE IOMEM(0xfde0)
-#define DOVE_MPP_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0200)
-#define DOVE_PMU_MPP_GENERAL_CTRL  (DOVE_MPP_VIRT_BASE + 0x10)
-#define  DOVE_AU0_AC97_SEL BIT(16)
 #define DOVE_PMU_SIGNAL_SELECT_0   (DOVE_SB_REGS_VIRT_BASE + 0xd802C)
 #define DOVE_PMU_SIGNAL_SELECT_1   (DOVE_SB_REGS_VIRT_BASE + 0xd8030)
 #define DOVE_GLOBAL_CONFIG_1   (DOVE_SB_REGS_VIRT_BASE + 0xe802C)
@@ -57,6 +54,10 @@
 #define  DOVE_SD1_GPIO_SEL BIT(1)
 #define  DOVE_SD0_GPIO_SEL BIT(0)
 
+/* MPP Base registers */
+#define PMU_MPP_GENERAL_CTRL   0x10
+#define  AU0_AC97_SEL  BIT(16)
+
 #define MPPS_PER_REG   8
 #define MPP_BITS   4
 #define MPP_MASK   0xf
@@ -73,7 +74,7 @@ static int dove_pmu_mpp_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 {
unsigned off = (ctrl->pid / MPPS_PER_REG) * MPP_BITS;
unsigned shift = (ctrl->pid % MPPS_PER_REG) * MPP_BITS;
-   unsigned long pmu = readl(DOVE_PMU_MPP_GENERAL_CTRL);
+   unsigned long pmu = readl(mpp_base + PMU_MPP_GENERAL_CTRL);
unsigned long func;
 
if (pmu & (1 << ctrl->pid)) {
@@ -81,7 +82,7 @@ static int dove_pmu_mpp_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
*config = (func >> shift) & MPP_MASK;
*config |= CONFIG_PMU;
} else {
-   func = readl(DOVE_MPP_VIRT_BASE + off);
+   func = readl(mpp_base + off);
*config = (func >> shift) & MPP_MASK;
}
return 0;
@@ -92,21 +93,23 @@ static int dove_pmu_mpp_ctrl_set(struct mvebu_mpp_ctrl 
*ctrl,
 {
unsigned off = (ctrl->pid / MPPS_PER_REG) * MPP_BITS;
unsigned shift = (ctrl->pid % MPPS_PER_REG) * MPP_BITS;
-   unsigned long pmu = readl(DOVE_PMU_MPP_GENERAL_CTRL);
+   unsigned long pmu = readl(mpp_base + PMU_MPP_GENERAL_CTRL);
unsigned long func;
 
if (config & CONFIG_PMU) {
-   writel(pmu | (1 << ctrl->pid), DOVE_PMU_MPP_GENERAL_CTRL);
+   writel(pmu | (1 << ctrl->pid),
+  mpp_base + PMU_MPP_GENERAL_CTRL);
func = readl(DOVE_PMU_SIGNAL_SELECT_0 + off);
func &= ~(MPP_MASK << shift);
func |= (config & MPP_MASK) << shift;
writel(func, DOVE_PMU_SIGNAL_SELECT_0 + off);
} else {
-   writel(pmu & ~(1 << ctrl->pid), DOVE_PMU_MPP_GENERAL_CTRL);
-   func = readl(DOVE_MPP_VIRT_BASE + off);
+   writel(pmu & ~(1 << ctrl->pid),
+  mpp_base + PMU_MPP_GENERAL_CTRL);
+   func = readl(mpp_base + off);
func &= ~(MPP_MASK << shift);
func |= (config & MPP_MASK) << shift;
-   writel(func, DOVE_MPP_VIRT_BASE + off);
+   writel(func, mpp_base + off);
}
return 0;
 }
@@ -204,9 +207,9 @@ static int dove_nand_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
 static int dove_audio0_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
unsigned long *config)
 {
-   unsigned long pmu = readl(DOVE_PMU_MPP_GENERAL_CTRL);
+   unsigned long pmu = readl(mpp_base + PMU_MPP_GENERAL_CTRL);
 
-   *config = ((pmu & DOVE_AU0_AC97_SEL) != 0);
+   *config = ((pmu & AU0_AC97_SEL) != 0);
 
return 0;
 }
@@ -214,12 +217,12 @@ static int dove_audio0_ctrl_get(struct mvebu_mpp_ctrl 
*ctrl,
 static int dove_audio0_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
unsigned long config)
 {
-   unsigned long pmu = readl(DOVE_PMU_MPP_GENERAL_CTRL);
+   unsigned long pmu = readl(mpp_base + PMU_MPP_GENERAL_CTRL);
 
-   pmu &= ~DOVE_AU0_AC97_SEL;
+   pmu &= ~AU0_AC97_SEL;
if (config)
-   pmu |= DOVE_AU0_AC97_SEL;
-   writel(pmu, DOVE_PMU_MPP_GENERAL_CTRL);
+   pmu |= AU0_AC97_SEL;
+   writel(pmu, mpp_base + PMU_MPP_GENERAL_CTRL);
 
return 0;
 }
-- 
1.8.5.2

--
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 11/11] pinctrl: mvebu: dove: use global register regmap

[Sebastian Hesselbarth]

Now that we have a regmap for global registers, get rid of the last
remaining hardcoded physical addresses. While at it, also remove
DOVE_ prefix from those macros.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-dove.c | 128 ---
 1 file changed, 60 insertions(+), 68 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c 
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 32cb3bbf2e18..90b6e7279ff9 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -30,21 +30,6 @@
 #define PMU_REGS_OFFS  0xd802c
 #define GC_REGS_OFFS   0xe802c
 
-#define DOVE_SB_REGS_VIRT_BASE IOMEM(0xfde0)
-#define DOVE_GLOBAL_CONFIG_1   (DOVE_SB_REGS_VIRT_BASE + 0xe802C)
-#define DOVE_GLOBAL_CONFIG_1   (DOVE_SB_REGS_VIRT_BASE + 0xe802C)
-#define  DOVE_TWSI_ENABLE_OPTION1  BIT(7)
-#define DOVE_GLOBAL_CONFIG_2   (DOVE_SB_REGS_VIRT_BASE + 0xe8030)
-#define  DOVE_TWSI_ENABLE_OPTION2  BIT(20)
-#define  DOVE_TWSI_ENABLE_OPTION3  BIT(21)
-#define  DOVE_TWSI_OPTION3_GPIOBIT(22)
-#define DOVE_SSP_CTRL_STATUS_1 (DOVE_SB_REGS_VIRT_BASE + 0xe8034)
-#define  DOVE_SSP_ON_AU1   BIT(0)
-#define DOVE_MPP_GENERAL_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xe803c)
-#define  DOVE_AU1_SPDIFO_GPIO_EN   BIT(1)
-#define  DOVE_NAND_GPIO_EN BIT(0)
-#define DOVE_GPIO_LO_VIRT_BASE (DOVE_SB_REGS_VIRT_BASE + 0xd0400)
-
 /* MPP Base registers */
 #define PMU_MPP_GENERAL_CTRL   0x10
 #define  AU0_AC97_SEL  BIT(16)
@@ -62,6 +47,19 @@
 #define PMU_SIGNAL_SELECT_00x00
 #define PMU_SIGNAL_SELECT_10x04
 
+/* Global Config regmap registers */
+#define GLOBAL_CONFIG_10
+#define  TWSI_ENABLE_OPTION1   BIT(7)
+#define GLOBAL_CONFIG_21
+#define  TWSI_ENABLE_OPTION2   BIT(20)
+#define  TWSI_ENABLE_OPTION3   BIT(21)
+#define  TWSI_OPTION3_GPIO BIT(22)
+#define SSP_CTRL_STATUS_1  2
+#define  SSP_ON_AU1BIT(0)
+#define MPP_GENERAL_CONFIG 4
+#define  AU1_SPDIFO_GPIO_ENBIT(1)
+#define  NAND_GPIO_EN  BIT(0)
+
 #define MPPS_PER_REG   8
 #define MPP_BITS   4
 #define MPP_MASK   0xf
@@ -187,9 +185,10 @@ static int dove_mpp4_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
 static int dove_nand_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
  unsigned long *config)
 {
-   unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
+   unsigned int gmpp;
 
-   *config = ((gmpp & DOVE_NAND_GPIO_EN) != 0);
+   regmap_read(gconfmap, MPP_GENERAL_CONFIG, );
+   *config = ((gmpp & NAND_GPIO_EN) != 0);
 
return 0;
 }
@@ -197,14 +196,9 @@ static int dove_nand_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
 static int dove_nand_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
  unsigned long config)
 {
-   unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
-
-   gmpp &= ~DOVE_NAND_GPIO_EN;
-   if (config)
-   gmpp |= DOVE_NAND_GPIO_EN;
-
-   writel(gmpp, DOVE_MPP_GENERAL_VIRT_BASE);
-
+   regmap_update_bits(gconfmap, MPP_GENERAL_CONFIG,
+  NAND_GPIO_EN,
+  (config) ? NAND_GPIO_EN : 0);
return 0;
 }
 
@@ -234,19 +228,23 @@ static int dove_audio0_ctrl_set(struct mvebu_mpp_ctrl 
*ctrl,
 static int dove_audio1_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
unsigned long *config)
 {
-   unsigned long mpp4 = readl(mpp4_base + MPP_CTRL4);
-   unsigned long sspc1 = readl(DOVE_SSP_CTRL_STATUS_1);
-   unsigned long gmpp = readl(DOVE_MPP_GENERAL_VIRT_BASE);
-   unsigned long gcfg2 = readl(DOVE_GLOBAL_CONFIG_2);
+   unsigned int mpp4 = readl(mpp4_base + MPP_CTRL4);
+   unsigned int sspc1;
+   unsigned int gmpp;
+   unsigned int gcfg2;
+
+   regmap_read(gconfmap, SSP_CTRL_STATUS_1, );
+   regmap_read(gconfmap, MPP_GENERAL_CONFIG, );
+   regmap_read(gconfmap, GLOBAL_CONFIG_2, );
 
*config = 0;
if (mpp4 & AU1_GPIO_SEL)
*config |= BIT(3);
-   if (sspc1 & DOVE_SSP_ON_AU1)
+   if (sspc1 & SSP_ON_AU1)
*config |= BIT(2);
-   if (gmpp & DOVE_AU1_SPDIFO_GPIO_EN)
+   if (gmpp & AU1_SPDIFO_GPIO_EN)
*config |= BIT(1);
-   if (gcfg2 & DOVE_TWSI_OPTION3_GPIO)
+   if (gcfg2 & TWSI_OPTION3_GPIO)
*config |= BIT(0);
 
/* SSP/TWSI only if I2S1 not set*/
@@ -261,32 +259,22 @@ static int dove_audio1_ctrl_get(struct mvebu_mpp_ctrl 
*ctrl,
 static int dove_audio1_ctrl_set(struct mvebu_mpp_ctrl *ctrl,
unsigned long config)
 {
-   unsigned long mpp4 = readl(mpp4_base + MPP_CTRL4);
-   unsigned long sspc1 = 

[PATCH 04/11] ARM: dove: add global-config register node

[Sebastian Hesselbarth]

We share global config registers by syscon node, add it to dove.dtsi.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Russell King 
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 arch/arm/boot/dts/dove.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 69405e00f2c8..fb289d83b76d 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -618,6 +618,12 @@
interrupts = <5>;
};
 
+   gconf: global-config@e802c {
+   compatible = "marvell,dove-global-config",
+"syscon";
+   reg = <0xe802c 0x14>;
+   };
+
gpio2: gpio-ctrl@e8400 {
compatible = "marvell,orion-gpio";
#gpio-cells = <2>;
-- 
1.8.5.2

--
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 10/11] pinctrl: mvebu: dove: use remapped pmu_mpp registers

[Sebastian Hesselbarth]

Now that we have ioremapped pmu_mpp registers, get rid of hardcoded
physical addresses. While at it, also remove DOVE_ prefix from those
macros.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Linus Walleij 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/pinctrl/mvebu/pinctrl-dove.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-dove.c 
b/drivers/pinctrl/mvebu/pinctrl-dove.c
index 0c7616e086b2..32cb3bbf2e18 100644
--- a/drivers/pinctrl/mvebu/pinctrl-dove.c
+++ b/drivers/pinctrl/mvebu/pinctrl-dove.c
@@ -31,8 +31,6 @@
 #define GC_REGS_OFFS   0xe802c
 
 #define DOVE_SB_REGS_VIRT_BASE IOMEM(0xfde0)
-#define DOVE_PMU_SIGNAL_SELECT_0   (DOVE_SB_REGS_VIRT_BASE + 0xd802C)
-#define DOVE_PMU_SIGNAL_SELECT_1   (DOVE_SB_REGS_VIRT_BASE + 0xd8030)
 #define DOVE_GLOBAL_CONFIG_1   (DOVE_SB_REGS_VIRT_BASE + 0xe802C)
 #define DOVE_GLOBAL_CONFIG_1   (DOVE_SB_REGS_VIRT_BASE + 0xe802C)
 #define  DOVE_TWSI_ENABLE_OPTION1  BIT(7)
@@ -60,6 +58,10 @@
 #define  SD1_GPIO_SEL  BIT(1)
 #define  SD0_GPIO_SEL  BIT(0)
 
+/* PMU Signal Select registers */
+#define PMU_SIGNAL_SELECT_00x00
+#define PMU_SIGNAL_SELECT_10x04
+
 #define MPPS_PER_REG   8
 #define MPP_BITS   4
 #define MPP_MASK   0xf
@@ -80,7 +82,7 @@ static int dove_pmu_mpp_ctrl_get(struct mvebu_mpp_ctrl *ctrl,
unsigned long func;
 
if (pmu & (1 << ctrl->pid)) {
-   func = readl(DOVE_PMU_SIGNAL_SELECT_0 + off);
+   func = readl(pmu_base + PMU_SIGNAL_SELECT_0 + off);
*config = (func >> shift) & MPP_MASK;
*config |= CONFIG_PMU;
} else {
@@ -101,10 +103,10 @@ static int dove_pmu_mpp_ctrl_set(struct mvebu_mpp_ctrl 
*ctrl,
if (config & CONFIG_PMU) {
writel(pmu | (1 << ctrl->pid),
   mpp_base + PMU_MPP_GENERAL_CTRL);
-   func = readl(DOVE_PMU_SIGNAL_SELECT_0 + off);
+   func = readl(pmu_base + PMU_SIGNAL_SELECT_0 + off);
func &= ~(MPP_MASK << shift);
func |= (config & MPP_MASK) << shift;
-   writel(func, DOVE_PMU_SIGNAL_SELECT_0 + off);
+   writel(func, pmu_base + PMU_SIGNAL_SELECT_0 + off);
} else {
writel(pmu & ~(1 << ctrl->pid),
   mpp_base + PMU_MPP_GENERAL_CTRL);
-- 
1.8.5.2

--
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/4] clk: mvebu: fix clk init order

[Sebastian Hesselbarth]

This patch set fixes clk init order that went upside-down with
v3.14. I haven't really investigated what caused this, but I assume
it is related with DT node reordering by addresses.

Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
registered before core clocks driver. Unfortunately, we cannot
return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
init order for our drivers is always core clocks before clock gating,
we maintain init order ourselves by hooking CLK_OF_DECLARE to one
init function that will register core clocks before clock gating
driver.

This patch is based on pre-v3.14-rc1 mainline and should go in as
fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
I suggest Jason picks it up as a topic branch.

The patches have been boot tested on Dove and compile-tested only
for Kirkwood, Armada 370 and XP.

Sebastian Hesselbarth (4):
  clk: mvebu: armada-370: maintain clock init order
  clk: mvebu: armada-xp: maintain clock init order
  clk: mvebu: dove: maintain clock init order
  clk: mvebu: kirkwood: maintain clock init order

 drivers/clk/mvebu/armada-370.c | 21 ++---
 drivers/clk/mvebu/armada-xp.c  | 20 +---
 drivers/clk/mvebu/dove.c   | 19 +--
 drivers/clk/mvebu/kirkwood.c   | 34 --
 4 files changed, 44 insertions(+), 50 deletions(-)

---
Cc: Mike Turquette 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Thomas Petazzoni 
Cc: Ezequiel Garcia 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
-- 
1.8.5.2

--
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/4] clk: mvebu: armada-370: maintain clock init order

[Sebastian Hesselbarth]

Init order of CLK_OF_DECLARE'd drivers depends on compile order.
Unfortunately, clk_of_init does not allow drivers to return errors,
e.g. -EPROBE_DEFER if parent clocks have not been registered, yet.

To avoid init order woes for MVEBU clock drivers, we take care of
proper init order ourselves. This patch joins core-clk and gating-clk
init to maintain proper init order.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Mike Turquette 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Thomas Petazzoni 
Cc: Ezequiel Garcia 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/mvebu/armada-370.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/mvebu/armada-370.c b/drivers/clk/mvebu/armada-370.c
index 81a202d12a7a..bef198a83863 100644
--- a/drivers/clk/mvebu/armada-370.c
+++ b/drivers/clk/mvebu/armada-370.c
@@ -141,13 +141,6 @@ static const struct coreclk_soc_desc a370_coreclks = {
.num_ratios = ARRAY_SIZE(a370_coreclk_ratios),
 };
 
-static void __init a370_coreclk_init(struct device_node *np)
-{
-   mvebu_coreclk_setup(np, _coreclks);
-}
-CLK_OF_DECLARE(a370_core_clk, "marvell,armada-370-core-clock",
-  a370_coreclk_init);
-
 /*
  * Clock Gating Control
  */
@@ -168,9 +161,15 @@ static const struct clk_gating_soc_desc a370_gating_desc[] 
__initconst = {
{ }
 };
 
-static void __init a370_clk_gating_init(struct device_node *np)
+static void __init a370_clk_init(struct device_node *np)
 {
-   mvebu_clk_gating_setup(np, a370_gating_desc);
+   struct device_node *cgnp =
+   of_find_compatible_node(NULL, NULL, 
"marvell,armada-370-gating-clock");
+
+   mvebu_coreclk_setup(np, _coreclks);
+
+   if (cgnp)
+   mvebu_clk_gating_setup(cgnp, a370_gating_desc);
 }
-CLK_OF_DECLARE(a370_clk_gating, "marvell,armada-370-gating-clock",
-  a370_clk_gating_init);
+CLK_OF_DECLARE(a370_clk, "marvell,armada-370-core-clock", a370_clk_init);
+
-- 
1.8.5.2

--
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/4] clk: mvebu: dove: maintain clock init order

[Sebastian Hesselbarth]

Init order of CLK_OF_DECLARE'd drivers depends on compile order.
Unfortunately, clk_of_init does not allow drivers to return errors,
e.g. -EPROBE_DEFER if parent clocks have not been registered, yet.

To avoid init order woes for MVEBU clock drivers, we take care of
proper init order ourselves. This patch joins core-clk and gating-clk
init to maintain proper init order.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Mike Turquette 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Thomas Petazzoni 
Cc: Ezequiel Garcia 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/mvebu/dove.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/mvebu/dove.c b/drivers/clk/mvebu/dove.c
index 38aee1e3f242..b8c2424ac926 100644
--- a/drivers/clk/mvebu/dove.c
+++ b/drivers/clk/mvebu/dove.c
@@ -154,12 +154,6 @@ static const struct coreclk_soc_desc dove_coreclks = {
.num_ratios = ARRAY_SIZE(dove_coreclk_ratios),
 };
 
-static void __init dove_coreclk_init(struct device_node *np)
-{
-   mvebu_coreclk_setup(np, _coreclks);
-}
-CLK_OF_DECLARE(dove_core_clk, "marvell,dove-core-clock", dove_coreclk_init);
-
 /*
  * Clock Gating Control
  */
@@ -186,9 +180,14 @@ static const struct clk_gating_soc_desc dove_gating_desc[] 
__initconst = {
{ }
 };
 
-static void __init dove_clk_gating_init(struct device_node *np)
+static void __init dove_clk_init(struct device_node *np)
 {
-   mvebu_clk_gating_setup(np, dove_gating_desc);
+   struct device_node *cgnp =
+   of_find_compatible_node(NULL, NULL, 
"marvell,dove-gating-clock");
+
+   mvebu_coreclk_setup(np, _coreclks);
+
+   if (cgnp)
+   mvebu_clk_gating_setup(cgnp, dove_gating_desc);
 }
-CLK_OF_DECLARE(dove_clk_gating, "marvell,dove-gating-clock",
-  dove_clk_gating_init);
+CLK_OF_DECLARE(dove_clk, "marvell,dove-core-clock", dove_clk_init);
-- 
1.8.5.2

--
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/4] clk: mvebu: armada-xp: maintain clock init order

[Sebastian Hesselbarth]

Init order of CLK_OF_DECLARE'd drivers depends on compile order.
Unfortunately, clk_of_init does not allow drivers to return errors,
e.g. -EPROBE_DEFER if parent clocks have not been registered, yet.

To avoid init order woes for MVEBU clock drivers, we take care of
proper init order ourselves. This patch joins core-clk and gating-clk
init to maintain proper init order.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Mike Turquette 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Thomas Petazzoni 
Cc: Ezequiel Garcia 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/mvebu/armada-xp.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/mvebu/armada-xp.c b/drivers/clk/mvebu/armada-xp.c
index 9922c4475aa8..b3094315a3c0 100644
--- a/drivers/clk/mvebu/armada-xp.c
+++ b/drivers/clk/mvebu/armada-xp.c
@@ -158,13 +158,6 @@ static const struct coreclk_soc_desc axp_coreclks = {
.num_ratios = ARRAY_SIZE(axp_coreclk_ratios),
 };
 
-static void __init axp_coreclk_init(struct device_node *np)
-{
-   mvebu_coreclk_setup(np, _coreclks);
-}
-CLK_OF_DECLARE(axp_core_clk, "marvell,armada-xp-core-clock",
-  axp_coreclk_init);
-
 /*
  * Clock Gating Control
  */
@@ -202,9 +195,14 @@ static const struct clk_gating_soc_desc axp_gating_desc[] 
__initconst = {
{ }
 };
 
-static void __init axp_clk_gating_init(struct device_node *np)
+static void __init axp_clk_init(struct device_node *np)
 {
-   mvebu_clk_gating_setup(np, axp_gating_desc);
+   struct device_node *cgnp =
+   of_find_compatible_node(NULL, NULL, 
"marvell,armada-xp-gating-clock");
+
+   mvebu_coreclk_setup(np, _coreclks);
+
+   if (cgnp)
+   mvebu_clk_gating_setup(cgnp, axp_gating_desc);
 }
-CLK_OF_DECLARE(axp_clk_gating, "marvell,armada-xp-gating-clock",
-  axp_clk_gating_init);
+CLK_OF_DECLARE(axp_clk, "marvell,armada-xp-core-clock", axp_clk_init);
-- 
1.8.5.2

--
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/4] clk: mvebu: kirkwood: maintain clock init order

[Sebastian Hesselbarth]

Init order of CLK_OF_DECLARE'd drivers depends on compile order.
Unfortunately, clk_of_init does not allow drivers to return errors,
e.g. -EPROBE_DEFER if parent clocks have not been registered, yet.

To avoid init order woes for MVEBU clock drivers, we take care of
proper init order ourselves. This patch joins core-clk and gating-clk
init to maintain proper init order.

Signed-off-by: Sebastian Hesselbarth 
---
Cc: Mike Turquette 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Thomas Petazzoni 
Cc: Ezequiel Garcia 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/clk/mvebu/kirkwood.c | 34 --
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/clk/mvebu/kirkwood.c b/drivers/clk/mvebu/kirkwood.c
index 2636a55f29f9..ddb666a86500 100644
--- a/drivers/clk/mvebu/kirkwood.c
+++ b/drivers/clk/mvebu/kirkwood.c
@@ -193,13 +193,6 @@ static const struct coreclk_soc_desc kirkwood_coreclks = {
.num_ratios = ARRAY_SIZE(kirkwood_coreclk_ratios),
 };
 
-static void __init kirkwood_coreclk_init(struct device_node *np)
-{
-   mvebu_coreclk_setup(np, _coreclks);
-}
-CLK_OF_DECLARE(kirkwood_core_clk, "marvell,kirkwood-core-clock",
-  kirkwood_coreclk_init);
-
 static const struct coreclk_soc_desc mv88f6180_coreclks = {
.get_tclk_freq = kirkwood_get_tclk_freq,
.get_cpu_freq = mv88f6180_get_cpu_freq,
@@ -208,13 +201,6 @@ static const struct coreclk_soc_desc mv88f6180_coreclks = {
.num_ratios = ARRAY_SIZE(kirkwood_coreclk_ratios),
 };
 
-static void __init mv88f6180_coreclk_init(struct device_node *np)
-{
-   mvebu_coreclk_setup(np, _coreclks);
-}
-CLK_OF_DECLARE(mv88f6180_core_clk, "marvell,mv88f6180-core-clock",
-  mv88f6180_coreclk_init);
-
 /*
  * Clock Gating Control
  */
@@ -239,9 +225,21 @@ static const struct clk_gating_soc_desc 
kirkwood_gating_desc[] __initconst = {
{ }
 };
 
-static void __init kirkwood_clk_gating_init(struct device_node *np)
+static void __init kirkwood_clk_init(struct device_node *np)
 {
-   mvebu_clk_gating_setup(np, kirkwood_gating_desc);
+   struct device_node *cgnp =
+   of_find_compatible_node(NULL, NULL, 
"marvell,kirkwood-gating-clock");
+
+
+   if (of_device_is_compatible(np, "marvell,mv88f6180-core-clock"))
+   mvebu_coreclk_setup(np, _coreclks);
+   else
+   mvebu_coreclk_setup(np, _coreclks);
+
+   if (cgnp)
+   mvebu_clk_gating_setup(cgnp, kirkwood_gating_desc);
 }
-CLK_OF_DECLARE(kirkwood_clk_gating, "marvell,kirkwood-gating-clock",
-  kirkwood_clk_gating_init);
+CLK_OF_DECLARE(kirkwood_clk, "marvell,kirkwood-core-clock",
+  kirkwood_clk_init);
+CLK_OF_DECLARE(mv88f6180_clk, "marvell,mv88f6180-core-clock",
+  kirkwood_clk_init);
-- 
1.8.5.2

--
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/2] x86, microcode: Add option to allow downgrading of microcode

[Andi Kleen]

On Sat, Jan 25, 2014 at 02:35:58PM -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 24 Jan 2014, Andi Kleen wrote:
> > For testing purposes it can be useful to downgrade microcode.
> > Normally the driver only allows upgrading.
> 
> The code is not prepared to work correctly when downgrading is allowed, in
> the presence of shadowed microcode.  When a firmware request results in more

As I wrote it's only for testing purposes when you know what you're doing
(typically with a special micro code file)

Your whole argument is irrelevant, as it only applies to normal users
who should never use this option.

> Also, since you're going to mess with this, why don't you implement the
> correct semanthics for microcode with the sign bit set?  Making it signed
> actually makes the current code behaviour worse.
> 
> Refer to: http://lkml.org/lkml/2011/3/21/522

I don't think it makes it worse. In fact I'm essentially implementing
Burt's request "for explicit user action" with the new override option.

Anyways I suppose your rant killed the patch anyways. Congratulations!

-Andi
--
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] regulator: fixed: Use devm_regulator_register

[Manish Badarkhe]

Use "devm_regulator_register" instead of "regulator_register"
which simplifies the code.

Signed-off-by: Manish Badarkhe 
---
:100644 100644 5ea64b9... 6d32341... M  drivers/regulator/fixed.c
 drivers/regulator/fixed.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 5ea64b9..6d32341 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -186,7 +186,8 @@ static int reg_fixed_voltage_probe(struct platform_device 
*pdev)
cfg.driver_data = drvdata;
cfg.of_node = pdev->dev.of_node;
 
-   drvdata->dev = regulator_register(>desc, );
+   drvdata->dev = devm_regulator_register(>dev, >desc,
+  );
if (IS_ERR(drvdata->dev)) {
ret = PTR_ERR(drvdata->dev);
dev_err(>dev, "Failed to register regulator: %d\n", ret);
@@ -212,7 +213,6 @@ static int reg_fixed_voltage_remove(struct platform_device 
*pdev)
 {
struct fixed_voltage_data *drvdata = platform_get_drvdata(pdev);
 
-   regulator_unregister(drvdata->dev);
kfree(drvdata->desc.supply_name);
kfree(drvdata->desc.name);
 
-- 
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/

RE: [PATCH 0/5] ia64 ski emulator patches

[Mikael Pettersson]

Luck, Tony writes:
 > Mikulas:
 > >> Here I'm sending some ia64 patches to make it work in the ski emulator. 
 > >> This has been broken for a long time.
 > 
 > Thanks - There are questions from time to time on how to test ia64
 > for those people who do not have hardware.
 > 
 > Mikael:
 > > Thanks.  I've recently started running 3.x kernels on ia64 via ski,
 > > but I'm getting random kernel crashes with 3.13.  I'll give your
 > > patches a try shortly.
 > 
 > Let me know how that goes - I haven't used ski in a decade and
 > have quite forgotten how to set it up.

It seems my kernel crashes were due to using gcc-4.8.2 to compile ski,
going back to gcc-4.7.3 for ski, and gcc-4.3.6 for cross-compiling
the kernel, gives me a solid emulated system.

 > > I've written a few patches to improve other aspects of running the
 > > kernel on ski:
 > > - kernel patch to turn PAL_HALT_LIGHT into a new SSC_HALT_LIGHT,
 > >   and a corresponing ski patch to pause() on SSC_HALT_LIGHT; this
 > >   together with the fixed-frequency ITC patch allows ski to idle
 > >   with very low host CPU overhead when the guest kernel idles
 > > - kernel patch to bump the RAM size from 130MB to 2GB
 > >
 > > I'd be happy to share these patches if there's interest in them.
 > 
 > It seems that there are at least two of you out there - so I'm happy
 > to take kernel patches that make things better.  Not sure where the
 > ski patches go - is someone maintaining that?

The ski project on sourceforge seems dead, nothing have been posted
on its mailing list since 2008, and the web interface for browsing
the source repo is broken.  Red Hat, Gentoo, and Debian package ski
with a few common build fixes, but that's it.

/Mikael
--
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: Freeing of dev->p

[Greg Kroah-Hartman]

On Wed, Jan 22, 2014 at 08:29:11AM +0100, Jean Delvare wrote:
> Hi Greg,
> 
> On Fri, 10 Jan 2014 07:24:02 -0800, Greg Kroah-Hartman wrote:
> > On Fri, Jan 10, 2014 at 03:39:07PM +0100, Jean Delvare wrote:
> > > (...)
> > > Then I suppose we could inline both functions
> > > again, for performance. Well, put in short, really revering
> > > b4028437876866aba4747a655ede00f892089e14 would be the way to go IMHO.
> > >
> > > Really, while I understand your envy to protect driver core internals
> > > from unwanted access, the cost here was simply too high IMHO, both in
> > > terms of getting things right and performance. Some drivers are calling
> > > dev_get_drvdata() directly or indirectly repeatedly at run-time. They
> > > had no reason not to as this used to be so fast, and now it is no
> > > longer an inline function, it has conditionals and a double pointer
> > > indirection...
> > > 
> > > Plus, I can't think of anything really bad that could result from
> > > accessing driver_data directly, contrary to the other members of struct
> > > device_private.
> > 
> > (...)
> > 
> > Thanks for the detailed response, I think I'll just revert most of that
> > patch and see if it's still workable.
> 
> Any news on this?

Stuck with dealing with merge-window issues and conferences, don't
worry, this isn't lost, it's still on my todo list...

thanks for your patience,

greg k-h
--
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: Linux 3.10.28

[Greg KH]

diff --git a/Makefile b/Makefile
index 09675a57059c..addf1b007fe3 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 10
-SUBLEVEL = 27
+SUBLEVEL = 28
 EXTRAVERSION =
 NAME = TOSSUG Baby Fish
 
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 4fb074c446bf..163b160c69e9 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
crash_save_cpu(, smp_processor_id());
flush_cache_all();
 
+   set_cpu_online(smp_processor_id(), false);
atomic_dec(_for_crash_ipi);
while (1)
cpu_relax();
diff --git a/arch/arm/mach-highbank/highbank.c 
b/arch/arm/mach-highbank/highbank.c
index e7df2dd43a40..5ed19e88874b 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -68,6 +68,7 @@ void highbank_set_cpu_jump(int cpu, void *jump_addr)
 #ifdef CONFIG_CACHE_L2X0
 static void highbank_l2x0_disable(void)
 {
+   outer_flush_all();
/* Disable PL310 L2 Cache controller */
highbank_smc1(0x102, 0x0);
 }
diff --git a/arch/arm/mach-omap2/omap4-common.c 
b/arch/arm/mach-omap2/omap4-common.c
index 13b27ffaf45e..ab99ab8fce8a 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -162,6 +162,7 @@ void __iomem *omap4_get_l2cache_base(void)
 
 static void omap4_l2x0_disable(void)
 {
+   outer_flush_all();
/* Disable PL310 L2 Cache controller */
omap_smc1(0x102, 0x0);
 }
diff --git a/arch/x86/kernel/cpu/perf_event_amd_ibs.c 
b/arch/x86/kernel/cpu/perf_event_amd_ibs.c
index 5f0581e713c2..b46601ada813 100644
--- a/arch/x86/kernel/cpu/perf_event_amd_ibs.c
+++ b/arch/x86/kernel/cpu/perf_event_amd_ibs.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -816,6 +817,18 @@ out:
return ret;
 }
 
+static void ibs_eilvt_setup(void)
+{
+   /*
+* Force LVT offset assignment for family 10h: The offsets are
+* not assigned by the BIOS for this family, so the OS is
+* responsible for doing it. If the OS assignment fails, fall
+* back to BIOS settings and try to setup this.
+*/
+   if (boot_cpu_data.x86 == 0x10)
+   force_ibs_eilvt_setup();
+}
+
 static inline int get_ibs_lvt_offset(void)
 {
u64 val;
@@ -851,6 +864,36 @@ static void clear_APIC_ibs(void *dummy)
setup_APIC_eilvt(offset, 0, APIC_EILVT_MSG_FIX, 1);
 }
 
+#ifdef CONFIG_PM
+
+static int perf_ibs_suspend(void)
+{
+   clear_APIC_ibs(NULL);
+   return 0;
+}
+
+static void perf_ibs_resume(void)
+{
+   ibs_eilvt_setup();
+   setup_APIC_ibs(NULL);
+}
+
+static struct syscore_ops perf_ibs_syscore_ops = {
+   .resume = perf_ibs_resume,
+   .suspend= perf_ibs_suspend,
+};
+
+static void perf_ibs_pm_init(void)
+{
+   register_syscore_ops(_ibs_syscore_ops);
+}
+
+#else
+
+static inline void perf_ibs_pm_init(void) { }
+
+#endif
+
 static int __cpuinit
 perf_ibs_cpu_notifier(struct notifier_block *self, unsigned long action, void 
*hcpu)
 {
@@ -877,18 +920,12 @@ static __init int amd_ibs_init(void)
if (!caps)
return -ENODEV; /* ibs not supported by the cpu */
 
-   /*
-* Force LVT offset assignment for family 10h: The offsets are
-* not assigned by the BIOS for this family, so the OS is
-* responsible for doing it. If the OS assignment fails, fall
-* back to BIOS settings and try to setup this.
-*/
-   if (boot_cpu_data.x86 == 0x10)
-   force_ibs_eilvt_setup();
+   ibs_eilvt_setup();
 
if (!ibs_eilvt_valid())
goto out;
 
+   perf_ibs_pm_init();
get_online_cpus();
ibs_caps = caps;
/* make ibs_caps visible to other cpus: */
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 8f3e2dec1df3..94e52cf064b0 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -1075,7 +1075,7 @@ ENTRY(ftrace_caller)
pushl $0/* Pass NULL as regs pointer */
movl 4*4(%esp), %eax
movl 0x4(%ebp), %edx
-   leal function_trace_op, %ecx
+   movl function_trace_op, %ecx
subl $MCOUNT_INSN_SIZE, %eax
 
 .globl ftrace_call
@@ -1133,7 +1133,7 @@ ENTRY(ftrace_regs_caller)
movl 12*4(%esp), %eax   /* Load ip (1st parameter) */
subl $MCOUNT_INSN_SIZE, %eax/* Adjust ip */
movl 0x4(%ebp), %edx/* Load parent ip (2nd parameter) */
-   leal function_trace_op, %ecx /* Save ftrace_pos in 3rd parameter */
+   movl function_trace_op, %ecx /* Save ftrace_pos in 3rd parameter */
pushl %esp  /* Save pt_regs as 4th parameter */
 
 GLOBAL(ftrace_regs_call)
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 727208941030..7ac938a4bfab 100644
--- a/arch/x86/kernel/entry_64.S
+++