Re: [Suggestion] [x86]: Compiler Option Os is better on latest x86

[Ling Ma]

Hi Ingo,

By netperf we did double check on older Nehalem platform too as below:

O2 NHM
 Performance counter stats for 'netperf' (3 runs):

   3779.262214 task-clock#0.378 CPUs utilized
  ( +-  0.37% )
47,580 context-switches  #0.013 M/sec
  ( +-  0.59% )
 0 cpu-migrations#0.000 K/sec
   321 page-faults   #0.085 K/sec
  ( +-  0.18% )
 8,885,976,365 cycles#2.351 GHz
  ( +-  0.37% )
 4,572,094,199 stalled-cycles-frontend   #   51.45% frontend
cycles idle ( +-  1.27% )
 1,347,935,497 stalled-cycles-backend#   15.17% backend
cycles idle ( +-  2.02% )
 6,564,928,770 instructions  #0.74  insns per cycle
 #0.70  stalled cycles
per insn  ( +-  0.33% )
 1,196,254,990 branches  #  316.531 M/sec
  ( +-  0.33% )
 6,434,145 branch-misses #0.54% of all
branches  ( +-  0.42% )

  10.009993130 seconds time elapsed
  ( +-  0.04% )

 87380  16384  1638410.0016727.94


Os NHM

 Performance counter stats for 'netperf' (3 runs):

   3793.965782 task-clock#0.379 CPUs utilized
  ( +-  0.24% )
59,124 context-switches  #0.016 M/sec
  ( +-  0.02% )
 0 cpu-migrations#0.000 K/sec
   321 page-faults   #0.085 K/sec
  ( +-  0.21% )
 8,878,307,926 cycles#2.340 GHz
  ( +-  0.25% )
 4,717,512,228 stalled-cycles-frontend   #   53.14% frontend
cycles idle ( +-  0.56% )
 1,612,028,376 stalled-cycles-backend#   18.16% backend
cycles idle ( +-  0.58% )
 6,273,760,790 instructions  #0.71  insns per cycle
 #0.75  stalled cycles
per insn  ( +-  0.02% )
 1,144,007,254 branches  #  301.533 M/sec
  ( +-  0.02% )
11,348,742 branch-misses #0.99% of all
branches  ( +-  0.66% )

  10.006341837 seconds time elapsed
  ( +-  0.00% )

 During the same time IPC from O2 is 0.74, 0.71 from Os, so the
performance is improved by 4%

The above result verified our thought, O2 is better than Os on Nehalem
because Nehalem use legacy instruction fetch, and -falign-functions,
-falign-jumps, -falign-loops, -falign-labels are useful to improve
frontend throuput and Os is good for Sandy Bridge resulted from
decoded cache.

Any comments are appreciate.

Thanks & Best Wish for coming year!
Ling

2012/12/31, ling.ma.prog...@gmail.com :
> From: Ma Ling 
>
>   Currently we use O2 as compiler option for better performance,
> although it will enlarge code size, in modern CPUs larger instructon
> and unified cache, sophisticated instruction prefetch weaken instruction
> cache miss, meanwhile flags such as -falign-functions, -falign-jumps,
> -falign-loops, -falign-labels are very helpful to improve CPU front-end
> throughput because CPU fetch instruction by 16 aligned–bytes code block
> per cycle.
>
>   In order to save power and get higher performance, Sandy Bridge
> starts to introduce decoded-cache, instructions will be kept in it
> after decode stage. When CPU refetches the instruction, decoded cache could
> provide 32 aligned-bytes instruction block, instead of 16 bytes from
> I-cache,
> fewer branch miss penalty resulted from shorter pipeline. It requires hot
> code should be put into decoded cache as possible we can. Sandy Bridge,
> Ivy Bridge, and Haswell all implemented this feature, Os-Optimize for size
> should be better than O2 on them.
>
> Based on above reasons, we compiled linux kernel 3.6.9 with O2 and Os
> respectively. The results show Os improve performance netperf 4.8%,
> 2.7% for volano as below
>
> O2 + netperf
> Performance counter stats for 'netperf' (3 runs):
>
>5416.157986 task-clock#0.541 CPUs utilized
> ( +-  0.19% )
>348,249 context-switches  #0.064 M/sec
> ( +-  0.17% )
>  0 CPU-migrations#0.000 M/sec
> ( +-  0.00% )
>353 page-faults   #0.000 M/sec
> ( +-  0.16% )
> 13,166,254,384 cycles#2.431 GHz
> ( +-  0.18% )
>  8,827,499,807 stalled-cycles-frontend   #   67.05% frontend cycles idle
> ( +-  0.29% )
>  5,951,234,060 stalled-cycles-backend#   45.20% backend  cycles idle
> ( +-  0.44% )
>  8,122,481,914 instructions  #0.62  insns per cycle
>  #1.09  stalled cycles per
> insn  ( +-  0.17% )
>  1,415,864,138 branches  #  261.415 M/sec
> ( +-  0.17% )
> 16,975,308 branch-misses #1.20% of all branches
> 

Re: [PATCH] staging:iio:adis16260: select IIO_ADIS_LIB to fix build error

[Yuanhan Liu]

On Mon, Dec 31, 2012 at 08:16:10AM +0100, Lars-Peter Clausen wrote:
> On 12/31/2012 06:36 AM, Yuanhan Liu wrote:
> > Commit 9d5e9fdf turned the code to use adis library, so it depends on
> > adis lib. But it forgot to select it at Kconfig file. Thus if adis is
> > not enabled, it will produce following build errros(catched by Fengguang's
> > 0-DAY kernel build testing system):
> >   ERROR: "adis_initial_startup" [drivers/staging/iio/gyro/adis16260.ko] 
> > undefined!
> >   ERROR: "adis_init" [drivers/staging/iio/gyro/adis16260.ko] undefined!
> >   ERROR: "adis_write_reg" [drivers/staging/iio/gyro/adis16260.ko] undefined!
> >   ERROR: "adis_read_reg" [drivers/staging/iio/gyro/adis16260.ko] undefined!
> >   ERROR: "adis_single_conversion" [drivers/staging/iio/gyro/adis16260.ko] 
> > undefined!
> > 
> > Selecting IIO_ADIS_LIB at Kconfig file fixes this issue.
> > 
> > Reported-by: Fengguang Wu 
> > Cc: Lars-Peter Clausen 
> > Cc: Jonathan Cameron 
> > Cc: Greg Kroah-Hartman 
> > Signed-off-by: Yuanhan Liu 
> 
> Hi,
> 
> Thanks. But I already sent a similar patch some time ago. See
> http://www.spinics.net/lists/linux-iio/msg07128.html


Got it, and sorry for the duplicate patch.

--yliu
--
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 06/27] nohz: Basic full dynticks interface

[Li Zhong]

On Sat, 2012-12-29 at 17:42 +0100, Frederic Weisbecker wrote:
> Start with a very simple interface to define full dynticks CPU:
> use a boot time option defined cpumask through the "full_nohz="
> kernel parameter.
> 
> Make sure you keep at least one CPU outside this range to handle
> the timekeeping.
> 
> Also full_nohz= must match rcu_nocb= value.
> 
> Suggested-by: Paul E. McKenney 
> Signed-off-by: Frederic Weisbecker 
> Cc: Alessio Igor Bogani 
> Cc: Andrew Morton 
> Cc: Chris Metcalf 
> Cc: Christoph Lameter 
> Cc: Geoff Levand 
> Cc: Gilad Ben Yossef 
> Cc: Hakan Akkan 
> Cc: Ingo Molnar 
> Cc: Paul E. McKenney 
> Cc: Paul Gortmaker 
> Cc: Peter Zijlstra 
> Cc: Steven Rostedt 
> Cc: Thomas Gleixner 
> ---
>  include/linux/tick.h |7 +++
>  kernel/time/Kconfig  |9 +
>  kernel/time/tick-sched.c |   23 +++
>  3 files changed, 39 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index 553272e..2d4f6f0 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -157,6 +157,13 @@ static inline u64 get_cpu_idle_time_us(int cpu, u64 
> *unused) { return -1; }
>  static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
>  # endif /* !NO_HZ */
> 
> +#ifdef CONFIG_NO_HZ_FULL
> +int tick_nohz_full_cpu(int cpu);
> +#else
> +static inline int tick_nohz_full_cpu(int cpu) { return 0; }
> +#endif
> +
> +
>  # ifdef CONFIG_CPU_IDLE_GOV_MENU
>  extern void menu_hrtimer_cancel(void);
>  # else
> diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
> index 8601f0d..dc6381d 100644
> --- a/kernel/time/Kconfig
> +++ b/kernel/time/Kconfig
> @@ -70,6 +70,15 @@ config NO_HZ
> only trigger on an as-needed basis both when the system is
> busy and when the system is idle.
> 
> +config NO_HZ_FULL
> +   bool "Full tickless system"
> +   depends on NO_HZ && RCU_USER_QS && VIRT_CPU_ACCOUNTING_GEN && 
> RCU_NOCB_CPU && SMP

Does that mean for archs like PPC64, which HAVE_VIRT_CPU_ACCOUNTING, to
get NO_HZ_FULL supported, we need to use VIRT_CPU_ACCOUTING_GEN instead
of VIRT_CPU_ACCOUNTING_NATIVE? ( I think the two, *_NATIVE and *_GEN,
shouldn't be both enabled at the same time? )

When I tried it on a ppc64 machine, it seems that after I select
VIRT_CPU_ACCOUNTING, VIRT_CPU_ACCOUNTING_NATIVE is automatically
selected. And I have no way to enable VIRT_CPU_ACCOUTING_GEN, or disable
VIRT_CPU_ACCOUNTING_NATIVE. It seems that's because these two don't have
a configuration name (input prompt).

> +   select CONTEXT_TRACKING_FORCE
> +   help
> + Try to be tickless everywhere, not just in idle. (You need
> +  to fill up the full_nohz_mask boot parameter).

Maybe it is better to use the name of the boot parameter full_nohz here
than the name of the mask variable used in the code? 

Thanks, Zhong

> +
> +
>  config HIGH_RES_TIMERS
>   bool "High Resolution Timer Support"
>   depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
> diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> index ad0e6fa..fac9ba4 100644
> --- a/kernel/time/tick-sched.c
> +++ b/kernel/time/tick-sched.c
> @@ -142,6 +142,29 @@ static void tick_sched_handle(struct tick_sched *ts, 
> struct pt_regs *regs)
>   profile_tick(CPU_PROFILING);
>  }
> 
> +#ifdef CONFIG_NO_HZ_FULL
> +static cpumask_var_t full_nohz_mask;
> +bool have_full_nohz_mask;
> +
> +int tick_nohz_full_cpu(int cpu)
> +{
> + if (!have_full_nohz_mask)
> + return 0;
> +
> + return cpumask_test_cpu(cpu, full_nohz_mask);
> +}
> +
> +/* Parse the boot-time nohz CPU list from the kernel parameters. */
> +static int __init tick_nohz_full_setup(char *str)
> +{
> + alloc_bootmem_cpumask_var(_nohz_mask);
> + have_full_nohz_mask = true;
> + cpulist_parse(str, full_nohz_mask);
> + return 1;
> +}
> +__setup("full_nohz=", tick_nohz_full_setup);
> +#endif
> +
>  /*
>   * NOHZ - aka dynamic tick functionality
>   */


--
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] staging:iio:adis16260: select IIO_ADIS_LIB to fix build error

[Lars-Peter Clausen]

On 12/31/2012 06:36 AM, Yuanhan Liu wrote:
> Commit 9d5e9fdf turned the code to use adis library, so it depends on
> adis lib. But it forgot to select it at Kconfig file. Thus if adis is
> not enabled, it will produce following build errros(catched by Fengguang's
> 0-DAY kernel build testing system):
>   ERROR: "adis_initial_startup" [drivers/staging/iio/gyro/adis16260.ko] 
> undefined!
>   ERROR: "adis_init" [drivers/staging/iio/gyro/adis16260.ko] undefined!
>   ERROR: "adis_write_reg" [drivers/staging/iio/gyro/adis16260.ko] undefined!
>   ERROR: "adis_read_reg" [drivers/staging/iio/gyro/adis16260.ko] undefined!
>   ERROR: "adis_single_conversion" [drivers/staging/iio/gyro/adis16260.ko] 
> undefined!
> 
> Selecting IIO_ADIS_LIB at Kconfig file fixes this issue.
> 
> Reported-by: Fengguang Wu 
> Cc: Lars-Peter Clausen 
> Cc: Jonathan Cameron 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Yuanhan Liu 

Hi,

Thanks. But I already sent a similar patch some time ago. See
http://www.spinics.net/lists/linux-iio/msg07128.html

- Lars

> ---
>  drivers/staging/iio/gyro/Kconfig |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/staging/iio/gyro/Kconfig 
> b/drivers/staging/iio/gyro/Kconfig
> index ea295b2..476207a 100644
> --- a/drivers/staging/iio/gyro/Kconfig
> +++ b/drivers/staging/iio/gyro/Kconfig
> @@ -27,6 +27,7 @@ config ADIS16130
>  config ADIS16260
>   tristate "Analog Devices ADIS16260 Digital Gyroscope Sensor SPI driver"
>   depends on SPI
> + select IIO_ADIS_LIB
>   select IIO_TRIGGER if IIO_BUFFER
>   select IIO_SW_RING if IIO_BUFFER
>   help

--
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 6/9] ARM: dt: tegra114: Add new SoC base, Tegra 114 SoC

[Hiroshi Doyu]

Hi Olof,

Olof Johansson  wrote @ Sat, 29 Dec 2012 07:39:13 +0100:

> On Thu, Dec 20, 2012 at 11:44:04AM +0200, Hiroshi Doyu wrote:
> > Initial support for Tegra 114 SoC. This is expected to be included in
> > the board DTS files, Tegra 114 SoC based evaluation board family.
> > 
> > Signed-off-by: Hiroshi Doyu 
> 
> Hi,
> 
> I think it could be a good idea to start documenting the cpu configuration in
> the device tree on some of these larger platforms as well, i.e. include a 
> cpus/
> hierarchy. Would you mind adding those, please?

Ok, I'll.

> It would give you the flexibility of switching over to using device
> tree to probe the number of cpus in case the platform grows yet another
> way to figure out the number of cores in the future, without having to
> update the device-trees at that time. :)
> 
> 
> -Olof
--
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 compilation failure on power7 system

[CAI Qian]

Please ignore this as this turned out some unclean bits rendered
the result unstable. It is now passed the complication testing. 

- Original Message -
> From: "CAI Qian" 
> To: "Mihai Caraman" , "Benjamin Herrenschmidt" 
> 
> Cc: sta...@vger.kernel.org, "linux-kernel" 
> Sent: Monday, December 31, 2012 11:33:19 AM
> Subject: kernel compilation failure on power7 system
> 
> Stable kernel 3.7.1 failure to compile on power7 system here,
> 
> arch/powerpc/kvm/built-in.o: In function `hdec_soon':
> /root/linux-stable/arch/powerpc/kvm/book3s_hv_rmhandlers.S:1068:
> undefined reference to `PACA_SPRG3'
> make: *** [vmlinux] Error 1
> 
> reverted this commit fixed the problem,
> -
> 0127262c01f0beb485f917c720d1d95d165dfdbf
> [PATCH] powerpc: Restore VDSO information on critical exception om
>  BookE
> 
> Critical exception on 64-bit booke uses user-visible SPRG3 as
> scratch.
> Restore VDSO information in SPRG3 on exception prolog.
> 
> Use a common sprg3 field in PACA for all powerpc64 architectures.
> -
> 
> Used this config - http://people.redhat.com/qcai/stable/config-ppc
> 
> system information here,
> # cat /proc/device-tree/model
> IBM,8231-E2B
> 
> CAI Qian
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv4 5/8] drm: tegra: Remove redundant host1x

[Terje Bergström]

On 28.12.2012 23:21, Thierry Reding wrote:
> Instead of going over this back and forth, I've decided to rewrite this
> patch from scratch the way I think it should be done. Maybe that'll make
> things clearer. I haven't tested it on real hardware yet because I don't
> have access over the holidays, but I'll post the patch once I've
> verified that it actually works. The code is based on patches 1-4 of
> this series and is meant to replace patch 5.

I'm still not happy that host1x needs to know about drm. That's just a
wrong dependency, and wrong dependencies always end up biting back. We
need to figure out solution that satisfies both mine and your
requirements and reduce complexity.

DC/HDMI/GR2D probes are using the global data only for managing the
lists "drm_clients" and "clients". "clients" list is only required after
tegra_drm_load(). "drm_clients" is required to establish driver load order.

With dummy device, we can determine the registration (and probe) order.
tegra-drm can register the drivers for DC/HDMI/GR2D devices first, and
as last the device and driver for tegra-drm.

tegra-drm probe will allocate the global data, enumerate all drivers and
add them to the clients list. If one driver is not initialized, it'll
return with -EPROBE_DEFER and will be called again later. When all this
is successful, it'll call drm_platform_init().

The advantages:
 * No management of drm_clients list
 * No mucking with drvdata
 * host1x doesn't need to know about drm
 * The global data is allocated and deallocated by tegra-drm probe and
remove, and accessed only via drm_device->dev_private
 * Much less code

Something like the attached patch - not tested, as I don't have access
to hw now, but it shows the idea. It's based on patches 1-5 in the
series, and could replace patch 5.

Terje
>From a97d475d65e68ce37c345924171dc57c5e7729ee Mon Sep 17 00:00:00 2001
From: Terje Bergstrom 
Date: Sat, 29 Dec 2012 11:43:54 +0200
Subject: [PATCH] drm: tegra: Postpone usage of global data

Change-Id: Ibfd1d4eeb267ac185de4508a1547fb009b80e93a
Signed-off-by: Terje Bergstrom 
---
 drivers/gpu/drm/tegra/dc.c   |   18 -
 drivers/gpu/drm/tegra/drm.c  |  151 +-
 drivers/gpu/drm/tegra/drm.h  |1 -
 drivers/gpu/drm/tegra/gr2d.c |7 --
 drivers/gpu/drm/tegra/hdmi.c |   18 -
 5 files changed, 47 insertions(+), 148 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 24bcd06..73056b7 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -740,7 +740,6 @@ static int tegra_dc_probe(struct platform_device *pdev)
 	struct resource *regs;
 	struct tegra_dc *dc;
 	int err;
-	struct tegradrm *tegradrm = platform_get_drvdata(pdev);
 
 	dc = devm_kzalloc(>dev, sizeof(*dc), GFP_KERNEL);
 	if (!dc)
@@ -780,7 +779,6 @@ static int tegra_dc_probe(struct platform_device *pdev)
 	INIT_LIST_HEAD(>client.list);
 	dc->client.ops = _client_ops;
 	dc->client.dev = >dev;
-	dc->client.tegradrm = tegradrm;
 
 	err = tegra_dc_rgb_probe(dc);
 	if (err < 0 && err != -ENODEV) {
@@ -788,13 +786,6 @@ static int tegra_dc_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	err = tegra_drm_register_client(tegradrm, >client);
-	if (err < 0) {
-		dev_err(>dev, "failed to register tegra drm client: %d\n",
-			err);
-		return err;
-	}
-
 	platform_set_drvdata(pdev, dc);
 
 	return 0;
@@ -803,15 +794,6 @@ static int tegra_dc_probe(struct platform_device *pdev)
 static int tegra_dc_remove(struct platform_device *pdev)
 {
 	struct tegra_dc *dc = platform_get_drvdata(pdev);
-	int err;
-
-	err = tegra_drm_unregister_client(dc->client.tegradrm,
-			>client);
-	if (err < 0) {
-		dev_err(>dev, "failed to unregister tegra_drm client: %d\n",
-			err);
-		return err;
-	}
 
 	clk_disable_unprepare(dc->clk);
 
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 637b621..520c281 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -25,12 +25,6 @@
 #define DRIVER_MINOR 0
 #define DRIVER_PATCHLEVEL 0
 
-struct tegra_drm_client_entry {
-	struct tegra_drm_client *client;
-	struct device_node *np;
-	struct list_head list;
-};
-
 static int tegra_drm_add_client(struct device *dev, void *data)
 {
 	static const char * const compat[] = {
@@ -42,102 +36,26 @@ static int tegra_drm_add_client(struct device *dev, void *data)
 		"nvidia,tegra30-gr2d"
 	};
 	struct tegradrm *tegradrm = data;
-	struct tegra_drm_client_entry *client;
+	struct tegra_drm_client *client;
 	unsigned int i;
 
+	/* Check if dev is a tegra-drm device, and add to client list */
 	for (i = 0; i < ARRAY_SIZE(compat); i++) {
 		if (of_device_is_compatible(dev->of_node, compat[i]) &&
 		of_device_is_available(dev->of_node)) {
-			client = kzalloc(sizeof(*client), GFP_KERNEL);
+			client = dev_get_drvdata(dev);
 			if (!client)
-return -ENOMEM;
+return -EPROBE_DEFER;
 
 			INIT_LIST_HEAD(>list);
-			client->np = of_node_get(dev->of_node);
 
-			

Re: [PATCH] mmc: host: dw_mmc-exynos: Add support for pinctrl

[Thomas Abraham]

On 21 December 2012 09:11, Dongjin Kim  wrote:
> This patch adds support for pin configuration using pinctrl subsystem to
> dw_mmc-exynos driver. The property 'wp-gpios' can be specified for write
> protect but 'samsung,cd-pinmux-gpio' and gpios used for clock, command and
> data lines will be ignored.
>
> -. 'pinctrl-0' should specify pin control groups (clock, comand and data
> lines) used for this controller.
> -. 'pinctrl-names' should contain only one value, 'default'.
>
> Signed-off-by: Dongjin Kim 
> ---
>  drivers/mmc/host/dw_mmc-exynos.c |   44 
> --
>  1 file changed, 28 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 4d50da6..d1c9963 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "dw_mmc.h"
>  #include "dw_mmc-pltfm.h"
> @@ -49,6 +50,7 @@ struct dw_mci_exynos_priv_data {
> u8  ciu_div;
> u32 sdr_timing;
> u32 ddr_timing;
> +   struct pinctrl  *pctrl;
>  };
>
>  static struct dw_mci_exynos_compatible {
> @@ -84,6 +86,10 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
> priv->ctrl_type = exynos_compat[idx].ctrl_type;
> }
>
> +   priv->pctrl = devm_pinctrl_get_select_default(host->dev);
> +   if (IS_ERR(priv->pctrl))
> +   dev_dbg(host->dev, "no pinctrl node\n");
> +

This could have been handled in dw_mci_exynos_setup_bus function. And
we also need to check if this patch gets merged.
https://patchwork.kernel.org/patch/1870231/. If it gets merged, this
change can be avoided.

> host->priv = priv;
> return 0;
>  }
> @@ -149,32 +155,19 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
> return ret;
>
> priv->ddr_timing = SDMMC_CLKSEL_TIMING(timing[0], timing[1], div);
> +
> return 0;
>  }
>
>  static int dw_mci_exynos_setup_bus(struct dw_mci *host,
> struct device_node *slot_np, u8 bus_width)
>  {
> +   struct dw_mci_exynos_priv_data *priv = host->priv;
> int idx, gpio, ret;
>
> if (!slot_np)
> return -EINVAL;
>
> -   /* cmd + clock + bus-width pins */
> -   for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
> -   gpio = of_get_gpio(slot_np, idx);
> -   if (!gpio_is_valid(gpio)) {
> -   dev_err(host->dev, "invalid gpio: %d\n", gpio);
> -   return -EINVAL;
> -   }
> -
> -   ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
> -   if (ret) {
> -   dev_err(host->dev, "gpio [%d] request failed\n", 
> gpio);
> -   return -EBUSY;
> -   }
> -   }
> -
> gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
> if (gpio_is_valid(gpio)) {
> if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
> @@ -185,9 +178,12 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
> host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
> }
>
> -   if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> +   if (!IS_ERR(priv->pctrl))
> return 0;
>
> +   if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> +   goto setup_bus;
> +

Why do the entire bus setup if card detection is broken?

> gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
> if (gpio_is_valid(gpio)) {
> if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
> @@ -196,6 +192,22 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
> dev_info(host->dev, "cd gpio not available");
> }
>
> + setup_bus:
> +   /* cmd + clock + bus-width pins */
> +   for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
> +   gpio = of_get_gpio(slot_np, idx);
> +   if (!gpio_is_valid(gpio)) {
> +   dev_err(host->dev, "invalid gpio: %d\n", gpio);
> +   return -EINVAL;
> +   }
> +
> +   ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
> +   if (ret) {
> +   dev_err(host->dev, "gpio [%d] request failed\n", 
> gpio);
> +   return -EBUSY;
> +   }
> +   }

This change should not have been there. If the mmc bus setup is being
done using pinctrl framework, this change can be avoided.

Thanks,
Thomas.

> +
> return 0;
>  }
>
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH 05/27] cputime: Safely read cputime of full dynticks CPUs

[Li Zhong]

On Sat, 2012-12-29 at 17:42 +0100, Frederic Weisbecker wrote:
> While remotely reading the cputime of a task running in a
> full dynticks CPU, the values stored in utime/stime fields
> of struct task_struct may be stale. Its values may be those
> of the last kernel <-> user transition time snapshot and
> we need to add the tickless time spent since this snapshot.
> 
> To fix this, flush the cputime of the dynticks CPUs on
> kernel <-> user transition and record the time / context
> where we did this. Then on top of this snapshot and the current
> time, perform the fixup on the reader side from task_times()
> accessors.
> 
> FIXME: do the same for idle and guest time.
> 
> Signed-off-by: Frederic Weisbecker 
> Cc: Alessio Igor Bogani 
> Cc: Andrew Morton 
> Cc: Chris Metcalf 
> Cc: Christoph Lameter 
> Cc: Geoff Levand 
> Cc: Gilad Ben Yossef 
> Cc: Hakan Akkan 
> Cc: Ingo Molnar 
> Cc: Paul E. McKenney 
> Cc: Paul Gortmaker 
> Cc: Peter Zijlstra 
> Cc: Steven Rostedt 
> Cc: Thomas Gleixner 
> ---
>  arch/s390/kernel/vtime.c  |6 +-
>  include/asm-generic/cputime.h |1 +
>  include/linux/hardirq.h   |4 +-
>  include/linux/init_task.h |   11 
>  include/linux/sched.h |   16 +
>  include/linux/vtime.h |   40 +++---
>  kernel/context_tracking.c |2 +-
>  kernel/fork.c |6 ++
>  kernel/sched/cputime.c|  123 
> ++---
>  kernel/softirq.c  |6 +-
>  10 files changed, 154 insertions(+), 61 deletions(-)
> 
> diff --git a/arch/s390/kernel/vtime.c b/arch/s390/kernel/vtime.c
> index e84b8b6..ce9cc5a 100644
> --- a/arch/s390/kernel/vtime.c
> +++ b/arch/s390/kernel/vtime.c
> @@ -127,7 +127,7 @@ void vtime_account_user(struct task_struct *tsk)
>   * Update process times based on virtual cpu times stored by entry.S
>   * to the lowcore fields user_timer, system_timer & steal_clock.
>   */
> -void vtime_account(struct task_struct *tsk)
> +void vtime_account_irq_enter(struct task_struct *tsk)
>  {
>   struct thread_info *ti = task_thread_info(tsk);
>   u64 timer, system;
> @@ -145,10 +145,10 @@ void vtime_account(struct task_struct *tsk)
> 
>   virt_timer_forward(system);
>  }
> -EXPORT_SYMBOL_GPL(vtime_account);
> +EXPORT_SYMBOL_GPL(vtime_account_irq_enter);
> 
>  void vtime_account_system(struct task_struct *tsk)
> -__attribute__((alias("vtime_account")));
> +__attribute__((alias("vtime_account_irq_enter")));
>  EXPORT_SYMBOL_GPL(vtime_account_system);
> 
>  void __kprobes vtime_stop_cpu(void)
> diff --git a/include/asm-generic/cputime.h b/include/asm-generic/cputime.h
> index 9a62937..3e704d5 100644
> --- a/include/asm-generic/cputime.h
> +++ b/include/asm-generic/cputime.h
> @@ -10,6 +10,7 @@ typedef unsigned long __nocast cputime_t;
>  #define cputime_to_jiffies(__ct) (__force unsigned long)(__ct)
>  #define cputime_to_scaled(__ct)  (__ct)
>  #define jiffies_to_cputime(__hz) (__force cputime_t)(__hz)
> +#define jiffies_to_scaled(__hz)  (__force cputime_t)(__hz)
> 
>  typedef u64 __nocast cputime64_t;
> 
> diff --git a/include/linux/hardirq.h b/include/linux/hardirq.h
> index 624ef3f..7105d5c 100644
> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@ -153,7 +153,7 @@ extern void rcu_nmi_exit(void);
>   */
>  #define __irq_enter()\
>   do {\
> - vtime_account_irq_enter(current);   \
> + account_irq_enter_time(current);\
>   add_preempt_count(HARDIRQ_OFFSET);  \
>   trace_hardirq_enter();  \
>   } while (0)
> @@ -169,7 +169,7 @@ extern void irq_enter(void);
>  #define __irq_exit() \
>   do {\
>   trace_hardirq_exit();   \
> - vtime_account_irq_exit(current);\
> + account_irq_exit_time(current); \
>   sub_preempt_count(HARDIRQ_OFFSET);  \
>   } while (0)
> 
> diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> index 6d087c5..a6ef59f 100644
> --- a/include/linux/init_task.h
> +++ b/include/linux/init_task.h
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #ifdef CONFIG_SMP
> @@ -141,6 +142,15 @@ extern struct task_group root_task_group;
>  # define INIT_PERF_EVENTS(tsk)
>  #endif
> 
> +#ifdef CONFIG_VIRT_CPU_ACCOUNTING_GEN
> +# define INIT_VTIME(tsk) \
> + .vtime_seqlock = __SEQLOCK_UNLOCKED(tsk.vtime_seqlock), \
> + .prev_jiffies = INITIAL_JIFFIES, /* CHECKME */  \
> + .prev_jiffies_whence = JIFFIES_SYS,
> +#else
> +# define INIT_VTIME(tsk)
> +#endif
> +
>  #define INIT_TASK_COMM "swapper"
> 
>  /*
> @@ -210,6 +220,7 @@ extern struct task_group root_task_group;
>   

[PATCH] staging:iio:adis16260: select IIO_ADIS_LIB to fix build error

[Yuanhan Liu]

Commit 9d5e9fdf turned the code to use adis library, so it depends on
adis lib. But it forgot to select it at Kconfig file. Thus if adis is
not enabled, it will produce following build errros(catched by Fengguang's
0-DAY kernel build testing system):
  ERROR: "adis_initial_startup" [drivers/staging/iio/gyro/adis16260.ko] 
undefined!
  ERROR: "adis_init" [drivers/staging/iio/gyro/adis16260.ko] undefined!
  ERROR: "adis_write_reg" [drivers/staging/iio/gyro/adis16260.ko] undefined!
  ERROR: "adis_read_reg" [drivers/staging/iio/gyro/adis16260.ko] undefined!
  ERROR: "adis_single_conversion" [drivers/staging/iio/gyro/adis16260.ko] 
undefined!

Selecting IIO_ADIS_LIB at Kconfig file fixes this issue.

Reported-by: Fengguang Wu 
Cc: Lars-Peter Clausen 
Cc: Jonathan Cameron 
Cc: Greg Kroah-Hartman 
Signed-off-by: Yuanhan Liu 
---
 drivers/staging/iio/gyro/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/staging/iio/gyro/Kconfig b/drivers/staging/iio/gyro/Kconfig
index ea295b2..476207a 100644
--- a/drivers/staging/iio/gyro/Kconfig
+++ b/drivers/staging/iio/gyro/Kconfig
@@ -27,6 +27,7 @@ config ADIS16130
 config ADIS16260
tristate "Analog Devices ADIS16260 Digital Gyroscope Sensor SPI driver"
depends on SPI
+   select IIO_ADIS_LIB
select IIO_TRIGGER if IIO_BUFFER
select IIO_SW_RING if IIO_BUFFER
help
-- 
1.7.7.6

--
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] Add support for DMI matching in calculating RTC_ALWAYS_BCD

[Nigel Cunningham]

From 037d9b44c9a18e6c2e3dedde2b8391215accc236 Mon Sep 17 00:00:00 2001
From: Nigel 
Date: Mon, 31 Dec 2012 10:58:54 +1100
Subject: [PATCH] Add support for DMI matching in calculating RTC_ALWAYS_BCD.

The Sony Vaio VPCSE15FG needs RTC_ALWAYS_BCD to be false rather than the
otherwise universal value of true. Add support for catching this model
via DMI matching.

There have been no BIOS updates for the VPCSE15FG, so I've not specified
a BIOS version in the criteria for matching.

Signed-off-by: Nigel Cunningham 
---
 arch/x86/include/asm/mc146818rtc.h |2 +-
 drivers/rtc/Makefile   |1 +
 drivers/rtc/dmi.c  |   46 


 include/linux/rtc.h|6 +
 4 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 drivers/rtc/dmi.c

diff --git a/arch/x86/include/asm/mc146818rtc.h 
b/arch/x86/include/asm/mc146818rtc.h

index d354fb7..b88f2c6 100644
--- a/arch/x86/include/asm/mc146818rtc.h
+++ b/arch/x86/include/asm/mc146818rtc.h
@@ -10,7 +10,7 @@

 #ifndef RTC_PORT
 #define RTC_PORT(x)(0x70 + (x))
-#define RTC_ALWAYS_BCD1/* RTC operates in binary mode */
+#define RTC_ALWAYS_BCD(rtc_always_bcd)/* Does the RTC operate 
in binary mode? */

 #endif

 #if defined(CONFIG_X86_32) && defined(__HAVE_ARCH_CMPXCHG)
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index c3f62c8..e008f65 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -12,6 +12,7 @@ rtc-core-y:= class.o interface.o
 rtc-core-$(CONFIG_RTC_INTF_DEV)+= rtc-dev.o
 rtc-core-$(CONFIG_RTC_INTF_PROC) += rtc-proc.o
 rtc-core-$(CONFIG_RTC_INTF_SYSFS) += rtc-sysfs.o
+rtc-core-$(CONFIG_DMI) += dmi.o

 # Keep the list ordered.

diff --git a/drivers/rtc/dmi.c b/drivers/rtc/dmi.c
new file mode 100644
index 000..609c2b5
--- /dev/null
+++ b/drivers/rtc/dmi.c
@@ -0,0 +1,46 @@
+/*
+ * RTC driver DMI matching.
+ *
+ *   Most machines using the mc146818 RTC need RTC_ALWAYS_BCD set to 1.
+ *   This file does DMI matching for the tiny number (1 so far!) of 
machines

+ *   that don't fit that mould.
+ *
+ *   (C) 2012 Nigel Cunningham 
+ *Add support for checking for the Sony Vaio VPCSE15FG.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as 
published by

+ * the Free Software Foundation.
+ *
+ * Trademarks are the property of their respective owners.
+ */
+
+#include 
+#include 
+
+int __read_mostly rtc_always_bcd;
+EXPORT_SYMBOL_GPL(rtc_always_bcd);
+
+static const struct dmi_system_id __initconst nonbcd_dmi_table[] = {
+#if defined(CONFIG_DMI) && defined(CONFIG_X86)
+{
+/* Sony VAIO VPCSE15FG */
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+DMI_MATCH(DMI_PRODUCT_NAME, "VPCSE15FG"),
+},
+},
+#endif
+{ }
+};
+
+static int __init rtc_check_always_bcd(void)
+{
+if (dmi_check_system(nonbcd_dmi_table)) {
+printk("Non BCD RTC clock detected via DMI check.\n");
+} else
+rtc_always_bcd = 1;
+
+return 0;
+}
+core_initcall(rtc_check_always_bcd);
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 9531845..0049f0f 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -164,6 +164,12 @@ extern int rtc_alarm_irq_enable(struct rtc_device 
*rtc, unsigned int enabled);

 extern int rtc_dev_update_irq_enable_emul(struct rtc_device *rtc,
 unsigned int enabled);

+#ifdef CONFIG_DMI
+extern int rtc_always_bcd;
+#else
+#define rtc_always_bcd (1)
+#endif
+
 void rtc_handle_legacy_irq(struct rtc_device *rtc, int num, int mode);
 void rtc_aie_update_irq(void *private);
 void rtc_uie_update_irq(void *private);
--
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 RESEND] ARM: dts: Add EHCI device tree node for Exynos4

[Tushar Behera]

On 12/31/2012 08:15 AM, Dongjin Kim wrote:
> This patch adds EHCI device node on device tree for Exynos4 and defines its
> default platform data, s5p_usb_phy_init and s5p_usb_phy_exit, so that those
> function can be called from the driver.
> 
> Signed-off-by: Dongjin Kim 
> ---
>  arch/arm/boot/dts/exynos4.dtsi |7 +++
>  arch/arm/mach-exynos/mach-exynos4-dt.c |9 +
>  2 files changed, 16 insertions(+)

[ ... ]

>  
> +static struct s5p_ehci_platdata s5p_ehci_platdata = {
> + .phy_init = s5p_usb_phy_init,
> + .phy_exit = s5p_usb_phy_exit,
> +};
> +

Going by the recent development on Samsung USBPHY driver, we won't need
these hooks once that patch gets accepted. [1]

Patch for adding EHCI support for EXYNOS5-DT can be found here.[2]

[1] https://patchwork.kernel.org/patch/1794651/
[2] https://patchwork.kernel.org/patch/1875491/


>  /*
>   * The following lookup table is used to override device names when devices
>   * are registered from device tree. This is temporarily added to enable
> @@ -80,6 +87,8 @@ static const struct of_dev_auxdata exynos4_auxdata_lookup[] 
> __initconst = {
>   OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_MDMA1, "dma-pl330.2", NULL),
>   OF_DEV_AUXDATA("samsung,exynos4210-tmu", EXYNOS4_PA_TMU,
>   "exynos-tmu", NULL),
> + OF_DEV_AUXDATA("samsung,exynos-ehci", EXYNOS4_PA_EHCI,
> + "s5p-ehci", _ehci_platdata),
>   {},
>  };
>  
> 


-- 
Tushar Behera
--
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: misc: Add USB3503 High-Speed Hub Controller

[Dongjin Kim]

Hi Greg,

Thanks for your reviewing.

The mode switching is required for power management, and actually it
is not tested properly yet. Therefore suspend/resume functions are
missing in the current patch but kept the switching function for the
future.

Thanks again.
Dongjin.


On Mon, Dec 31, 2012 at 12:22 PM, Greg Kroah-Hartman
 wrote:
> On Mon, Dec 31, 2012 at 11:50:54AM +0900, Dongjin Kim wrote:
>> This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC
>> upstream connectivity and three USB 2.0 downstream ports. The specification
>> can be found from 'http://www.smsc.com/index.php?tid=295=325'.
>>
>> The current version have been tested very basic features switching the modes,
>> HUB-MODE and STANDBY-MODE.
>
> What causes the modes to be switched?  From reading the driver, that
> only seems possible to do at boot/load time when the driver reads the
> platform data, right?  After that, nothing happens to the device from
> what I can tell.
>
> Is something going to cause the state of the device to change in the
> future?
>
>> + hub->mode = mode;
>> + dev_info(>dev, "switched to HUB mode\n");
>
> Can you please switch all of the dev_info() calls to dev_dbg()?  There's
> no need to tell the world what is going on in this driver, no one really
> cares.  And if they do, they can dynamically enable debugging and get
> the information then :)
>
> thanks,
>
> 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/

kernel compilation failure on power7 system

[CAI Qian]

Stable kernel 3.7.1 failure to compile on power7 system here,

arch/powerpc/kvm/built-in.o: In function `hdec_soon':
/root/linux-stable/arch/powerpc/kvm/book3s_hv_rmhandlers.S:1068: 
undefined reference to `PACA_SPRG3'
make: *** [vmlinux] Error 1

reverted this commit fixed the problem,
-
0127262c01f0beb485f917c720d1d95d165dfdbf
[PATCH] powerpc: Restore VDSO information on critical exception om
 BookE

Critical exception on 64-bit booke uses user-visible SPRG3 as scratch.
Restore VDSO information in SPRG3 on exception prolog.

Use a common sprg3 field in PACA for all powerpc64 architectures.
-

Used this config - http://people.redhat.com/qcai/stable/config-ppc

system information here,
# cat /proc/device-tree/model
IBM,8231-E2B

CAI Qian
--
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: [Suggestion] drivers/staging/tidspbridge: strcpy and strncpy, src length checking issue.

[Chen Gang]

Hi Omar Ramirez Luna:

Since you are really too busy.
  is it suitable to send a patch for it, by me ?

  no reply within a week, means it is suitable.

  :-)

gchen.


于 2012年12月14日 11:50, Chen Gang 写道:
> Hello Omar Ramirez Luna:
> 
>   in drivers/staging/tidspbridge/rmgr/proc.c:
> 
> if strlen(drv_datap->base_img) == size, will pass checking (line 397)
> the size is the full length of exec_file (line 382, line 468..469)
> strcpy causes issue: src len is strlen(drv_datap->base_img) + '\0'. (line 
> 400)
> 
> strncpy seems also has issue: need use size instead of strlen(iva_img) + 
> 1. (line 402..403)
> 
>   please help to check, thanks.
> 
> gchen.
> 
> 
>  380 static int get_exec_file(struct cfg_devnode *dev_node_obj,
>  381 struct dev_object *hdev_obj,
>  382 u32 size, char *exec_file)
>  383 {
>  384 u8 dev_type;
>  385 s32 len;
>  386 struct drv_data *drv_datap = dev_get_drvdata(bridge);
>  387 
>  388 dev_get_dev_type(hdev_obj, (u8 *) _type);
>  389 
>  390 if (!exec_file)
>  391 return -EFAULT;
>  392 
>  393 if (dev_type == DSP_UNIT) {
>  394 if (!drv_datap || !drv_datap->base_img)
>  395 return -EFAULT;
>  396 
>  397 if (strlen(drv_datap->base_img) > size)
>  398 return -EINVAL;
>  399 
>  400 strcpy(exec_file, drv_datap->base_img);
>  401 } else if (dev_type == IVA_UNIT && iva_img) {
>  402 len = strlen(iva_img);
>  403 strncpy(exec_file, iva_img, len + 1);
>  404 } else {
>  405 return -ENOENT;
>  406 }
>  407 
>  408 return 0;
>  409 }
>  410 
>  ...
> 
>  465 /* Get the default executable for this board... */
>  466 dev_get_dev_type(hdev_obj, (u8 *) _type);
>  467 p_proc_object->processor_id = dev_type;
>  468 status = get_exec_file(dev_node_obj, hdev_obj, 
> sizeof(sz_exec_file),
>  469sz_exec_file);
> 


-- 
Chen Gang

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

Re: [PATCH] USB: misc: Add USB3503 High-Speed Hub Controller

[Greg Kroah-Hartman]

On Mon, Dec 31, 2012 at 11:50:54AM +0900, Dongjin Kim wrote:
> This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC
> upstream connectivity and three USB 2.0 downstream ports. The specification
> can be found from 'http://www.smsc.com/index.php?tid=295=325'.
> 
> The current version have been tested very basic features switching the modes,
> HUB-MODE and STANDBY-MODE.

What causes the modes to be switched?  From reading the driver, that
only seems possible to do at boot/load time when the driver reads the
platform data, right?  After that, nothing happens to the device from
what I can tell.

Is something going to cause the state of the device to change in the
future?

> + hub->mode = mode;
> + dev_info(>dev, "switched to HUB mode\n");

Can you please switch all of the dev_info() calls to dev_dbg()?  There's
no need to tell the world what is going on in this driver, no one really
cares.  And if they do, they can dynamically enable debugging and get
the information then :)

thanks,

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: [PATCH] mmc: host: dw_mmc-exynos: Add support for pinctrl

[Dongjin Kim]

Hi,

Does anyone have advice on this patch?

On Sat, Dec 22, 2012 at 2:11 AM, Dongjin Kim  wrote:
> This patch adds support for pin configuration using pinctrl subsystem to
> dw_mmc-exynos driver. The property 'wp-gpios' can be specified for write
> protect but 'samsung,cd-pinmux-gpio' and gpios used for clock, command and
> data lines will be ignored.
>
> -. 'pinctrl-0' should specify pin control groups (clock, comand and data
> lines) used for this controller.
> -. 'pinctrl-names' should contain only one value, 'default'.
>
> Signed-off-by: Dongjin Kim 
> ---
>  drivers/mmc/host/dw_mmc-exynos.c |   44
> --
>  1 file changed, 28 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
> b/drivers/mmc/host/dw_mmc-exynos.c
> index 4d50da6..d1c9963 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "dw_mmc.h"
>  #include "dw_mmc-pltfm.h"
> @@ -49,6 +50,7 @@ struct dw_mci_exynos_priv_data {
> u8  ciu_div;
> u32 sdr_timing;
> u32 ddr_timing;
> +   struct pinctrl  *pctrl;
>  };
>
>  static struct dw_mci_exynos_compatible {
> @@ -84,6 +86,10 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
> priv->ctrl_type = exynos_compat[idx].ctrl_type;
> }
>
> +   priv->pctrl = devm_pinctrl_get_select_default(host->dev);
> +   if (IS_ERR(priv->pctrl))
> +   dev_dbg(host->dev, "no pinctrl node\n");
> +
> host->priv = priv;
> return 0;
>  }
> @@ -149,32 +155,19 @@ static int dw_mci_exynos_parse_dt(struct dw_mci
> *host)
> return ret;
>
> priv->ddr_timing = SDMMC_CLKSEL_TIMING(timing[0], timing[1], div);
> +
> return 0;
>  }
>
>  static int dw_mci_exynos_setup_bus(struct dw_mci *host,
> struct device_node *slot_np, u8 bus_width)
>  {
> +   struct dw_mci_exynos_priv_data *priv = host->priv;
> int idx, gpio, ret;
>
> if (!slot_np)
> return -EINVAL;
>
> -   /* cmd + clock + bus-width pins */
> -   for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
> -   gpio = of_get_gpio(slot_np, idx);
> -   if (!gpio_is_valid(gpio)) {
> -   dev_err(host->dev, "invalid gpio: %d\n", gpio);
> -   return -EINVAL;
> -   }
> -
> -   ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
> -   if (ret) {
> -   dev_err(host->dev, "gpio [%d] request failed\n",
> gpio);
> -   return -EBUSY;
> -   }
> -   }
> -
> gpio = of_get_named_gpio(slot_np, "wp-gpios", 0);
> if (gpio_is_valid(gpio)) {
> if (devm_gpio_request(host->dev, gpio, "dw-mci-wp"))
> @@ -185,9 +178,12 @@ static int dw_mci_exynos_setup_bus(struct dw_mci
> *host,
> host->pdata->quirks |= DW_MCI_QUIRK_NO_WRITE_PROTECT;
> }
>
> -   if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> +   if (!IS_ERR(priv->pctrl))
> return 0;
>
> +   if (host->pdata->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> +   goto setup_bus;
> +
> gpio = of_get_named_gpio(slot_np, "samsung,cd-pinmux-gpio", 0);
> if (gpio_is_valid(gpio)) {
> if (devm_gpio_request(host->dev, gpio, "dw-mci-cd"))
> @@ -196,6 +192,22 @@ static int dw_mci_exynos_setup_bus(struct dw_mci
> *host,
> dev_info(host->dev, "cd gpio not available");
> }
>
> + setup_bus:
> +   /* cmd + clock + bus-width pins */
> +   for (idx = 0; idx < NUM_PINS(bus_width); idx++) {
> +   gpio = of_get_gpio(slot_np, idx);
> +   if (!gpio_is_valid(gpio)) {
> +   dev_err(host->dev, "invalid gpio: %d\n", gpio);
> +   return -EINVAL;
> +   }
> +
> +   ret = devm_gpio_request(host->dev, gpio, "dw-mci-bus");
> +   if (ret) {
> +   dev_err(host->dev, "gpio [%d] request failed\n",
> gpio);
> +   return -EBUSY;
> +   }
> +   }
> +
> return 0;
>  }
>
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB: misc: Add USB3503 High-Speed Hub Controller

[Dongjin Kim]

This patch adds new driver of SMSC USB3503 USB 2.0 hub controller with HSIC
upstream connectivity and three USB 2.0 downstream ports. The specification
can be found from 'http://www.smsc.com/index.php?tid=295=325'.

The current version have been tested very basic features switching the modes,
HUB-MODE and STANDBY-MODE.

Signed-off-by: Dongjin Kim 
---
 drivers/usb/misc/Kconfig  |6 +
 drivers/usb/misc/Makefile |1 +
 drivers/usb/misc/usb3503.c|  323 +
 include/linux/platform_data/usb3503.h |   17 ++
 4 files changed, 347 insertions(+)
 create mode 100644 drivers/usb/misc/usb3503.c
 create mode 100644 include/linux/platform_data/usb3503.h

diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index fecde69..3b1a3f4 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -250,3 +250,9 @@ config USB_EZUSB_FX2
help
  Say Y here if you need EZUSB device support.
  (Cypress FX/FX2/FX2LP microcontrollers)
+
+config USB_HSIC_USB3503
+   tristate "USB3503 HSIC to USB20 Driver"
+   depends on I2C
+   help
+ This option enables support for SMSC USB3503 HSIC to USB 2.0 Driver.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 3e99a64..3e1bd70 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_USB_TRANCEVIBRATOR)  += trancevibrator.o
 obj-$(CONFIG_USB_USS720)   += uss720.o
 obj-$(CONFIG_USB_SEVSEG)   += usbsevseg.o
 obj-$(CONFIG_USB_YUREX)+= yurex.o
+obj-$(CONFIG_USB_HSIC_USB3503) += usb3503.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
new file mode 100644
index 000..f21fca9
--- /dev/null
+++ b/drivers/usb/misc/usb3503.c
@@ -0,0 +1,323 @@
+/*
+ * Driver for SMSC USB3503 USB 2.0 hub controller driver
+ *
+ * Copyright (c) 2012 Dongjin Kim (tobet...@gmail.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define USB3503_VIDL   0x00
+#define USB3503_VIDM   0x01
+#define USB3503_PIDL   0x02
+#define USB3503_PIDM   0x03
+#define USB3503_DIDL   0x04
+#define USB3503_DIDM   0x05
+
+#define USB3503_CFG1   0x06
+#define USB3503_SELF_BUS_PWR   (1 << 7)
+
+#define USB3503_CFG2   0x07
+#define USB3503_CFG3   0x08
+#define USB3503_NRD0x09
+
+#define USB3503_PDS0x0a
+#define USB3503_PORT1  (1 << 1)
+#define USB3503_PORT2  (1 << 2)
+#define USB3503_PORT3  (1 << 3)
+
+#define USB3503_SP_ILOCK   0xe7
+#define USB3503_SPILOCK_CONNECT(1 << 1)
+#define USB3503_SPILOCK_CONFIG (1 << 0)
+
+#define USB3503_CFGP   0xee
+#define USB3503_CLKSUSP(1 << 7)
+
+struct usb3503 {
+   enum usb3503_mode   mode;
+   struct i2c_client   *client;
+   int gpio_intn;
+   int gpio_reset;
+   int gpio_connect;
+};
+
+static int usb3503_write_register(struct i2c_client *client,
+   char reg, char data)
+{
+   return i2c_smbus_write_byte_data(client, reg, data);
+}
+
+static int usb3503_read_register(struct i2c_client *client, char reg)
+{
+   return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int usb3503_set_bits(struct i2c_client *client, char reg, char req)
+{
+   int err;
+
+   err = usb3503_read_register(client, reg);
+   if (err < 0)
+   return err;
+
+   err = usb3503_write_register(client, reg, err | req);
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+
+static int usb3503_clear_bits(struct i2c_client *client, char reg, char req)
+{
+   int err;
+
+   err = usb3503_read_register(client, reg);
+   if (err < 0)
+   return err;
+
+   err = usb3503_write_register(client, reg, err & ~req);
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+
+static int usb3503_reset(int gpio_reset, int state)
+{
+   if (gpio_is_valid(gpio_reset))
+   gpio_set_value(gpio_reset, state);
+
+   /* Wait RefClk 

[PATCH 1/2] add spinlock test to synchro-test module

[Michel Lespinasse]

Signed-off-by: Michel Lespinasse 

---
 kernel/synchro-test.c |   76 +
 1 files changed, 70 insertions(+), 6 deletions(-)

diff --git a/kernel/synchro-test.c b/kernel/synchro-test.c
index 76e3ad39505f..9abfa955d69e 100644
--- a/kernel/synchro-test.c
+++ b/kernel/synchro-test.c
@@ -41,6 +41,7 @@
 # define VALIDATE_OPERATORS
 #endif
 
+static int numsp;
 static int nummx;
 static int numsm, seminit = 4;
 static int numrd, numwr, numdg;
@@ -54,6 +55,9 @@ MODULE_LICENSE("GPL");
 module_param_named(v, verbose, int, 0);
 MODULE_PARM_DESC(verbose, "Verbosity");
 
+module_param_named(sp, numsp, int, 0);
+MODULE_PARM_DESC(numsp, "Number of spinlock threads");
+
 module_param_named(mx, nummx, int, 0);
 MODULE_PARM_DESC(nummx, "Number of mutex threads");
 
@@ -85,6 +89,7 @@ module_param(do_sched, int, 0);
 MODULE_PARM_DESC(do_sched, "True if each thread should schedule regularly");
 
 /* the semaphores under test */
+static spinlock_t cacheline_aligned spinlock;
 static struct mutex cacheline_aligned mutex;
 static struct semaphore cacheline_aligned sem;
 static struct rw_semaphore cacheline_aligned rwsem;
@@ -92,18 +97,21 @@ static struct rw_semaphore cacheline_aligned rwsem;
 static atomic_t cacheline_aligned do_stuff = ATOMIC_INIT(0);
 
 #ifdef VALIDATE_OPERATORS
+static atomic_t cacheline_aligned spinlocks= 
ATOMIC_INIT(0);
 static atomic_t cacheline_aligned mutexes  = ATOMIC_INIT(0);
 static atomic_t cacheline_aligned semaphores   = ATOMIC_INIT(0);
 static atomic_t cacheline_aligned readers  = ATOMIC_INIT(0);
 static atomic_t cacheline_aligned writers  = ATOMIC_INIT(0);
 #endif
 
+static unsigned int cacheline_aligned spinlocks_taken  [MAX_THREADS];
 static unsigned int cacheline_aligned mutexes_taken
[MAX_THREADS];
 static unsigned int cacheline_aligned semaphores_taken [MAX_THREADS];
 static unsigned int cacheline_aligned reads_taken  [MAX_THREADS];
 static unsigned int cacheline_aligned writes_taken [MAX_THREADS];
 static unsigned int cacheline_aligned downgrades_taken [MAX_THREADS];
 
+static struct completion cacheline_aligned sp_comp[MAX_THREADS];
 static struct completion cacheline_aligned mx_comp[MAX_THREADS];
 static struct completion cacheline_aligned sm_comp[MAX_THREADS];
 static struct completion cacheline_aligned rd_comp[MAX_THREADS];
@@ -130,6 +138,23 @@ do {   
\
 #define CHECK(var, cond, val)  do {} while(0)
 #endif
 
+static inline void do_spin_lock(unsigned int N)
+{
+   spin_lock();
+
+   ACCOUNT(spinlocks, N);
+   TRACK(spinlocks, inc);
+   CHECK(spinlocks, ==, 1);
+}
+
+static inline void do_spin_unlock(unsigned int N)
+{
+   CHECK(spinlocks, ==, 1);
+   TRACK(spinlocks, dec);
+
+   spin_unlock();
+}
+
 static inline void do_mutex_lock(unsigned int N)
 {
mutex_lock();
@@ -221,6 +246,27 @@ static inline void sched(void)
schedule();
 }
 
+static int spinlocker(void *arg)
+{
+   unsigned int N = (unsigned long) arg;
+
+   set_user_nice(current, 19);
+
+   while (atomic_read(_stuff)) {
+   do_spin_lock(N);
+   if (load)
+   udelay(load);
+   do_spin_unlock(N);
+   sched();
+   if (interval)
+   udelay(interval);
+   }
+
+   if (verbose >= 2)
+   printk("%s: done\n", current->comm);
+   complete_and_exit(_comp[N], 0);
+}
+
 static int mutexer(void *arg)
 {
unsigned int N = (unsigned long) arg;
@@ -388,9 +434,11 @@ static unsigned int total(const char *what, unsigned int 
counts[], int num)
 static int __init do_tests(void)
 {
unsigned long loop;
-   unsigned int mutex_total, sem_total, rd_total, wr_total, dg_total;
+   unsigned int spinlock_total, mutex_total, sem_total;
+   unsigned int rd_total, wr_total, dg_total;
 
-   if (nummx < 0 || nummx > MAX_THREADS ||
+   if (numsp < 0 || numsp > MAX_THREADS ||
+   nummx < 0 || nummx > MAX_THREADS ||
numsm < 0 || numsm > MAX_THREADS ||
numrd < 0 || numrd > MAX_THREADS ||
numwr < 0 || numwr > MAX_THREADS ||
@@ -404,12 +452,12 @@ static int __init do_tests(void)
return -ERANGE;
}
 
-   if ((nummx | numsm | numrd | numwr | numdg) == 0) {
+   if ((numsp | nummx | numsm | numrd | numwr | numdg) == 0) {
int num = num_online_cpus();
 
if (num > MAX_THREADS)
num = MAX_THREADS;
-   nummx = numsm = numrd = numwr = numdg = num;
+   numsp = nummx = numsm = numrd = numwr = numdg = num;
 
load = 1;
interval = 1;
@@ -420,6 +468,7 @@ static int __init do_tests(void)
   

[PATCH 0/2] extend synchro-test module to test spinlocks too

[Michel Lespinasse]

I wanted a synthetic test to help me understand the performance of Rik's
proposed spinlock proportional backoff patches, and the synchro-test
in andrew's mmotm tree looked like an obvious candidate to be extended,
so I ended up with the following couple patches.

I'm not sure whats' the back story with synchro-test though - they seem
to have been stuck in andrew's tree for a very long time now. Is there
any reason delaying their inclusion or is it just that nobody's been
pushing for them ?

Michel Lespinasse (2):
  add spinlock test to synchro-test module
  Document default load and interval values in synchro-test module

 Documentation/synchro-test.txt |4 +-
 kernel/synchro-test.c  |   76 ---
 2 files changed, 72 insertions(+), 8 deletions(-)

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

[PATCH 2/2] Document default load and interval values in synchro-test module

[Michel Lespinasse]

The synchro-test module default parameters are to keep the lock for 2uS
and wait 2uS between release and the next attempted acquisition. Having the
documentation wrong on this point was quite confusing !

Signed-off-by: Michel Lespinasse 

---
 Documentation/synchro-test.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/synchro-test.txt b/Documentation/synchro-test.txt
index 3d6cdda7bb79..554709478e1f 100644
--- a/Documentation/synchro-test.txt
+++ b/Documentation/synchro-test.txt
@@ -42,12 +42,12 @@ The available arguments are:
 
  (*) load=N
 
-   Each thread delays for N uS whilst holding the lock. The default is 0.
+   Each thread delays for N uS whilst holding the lock. The default is 2.
 
  (*) interval=N
 
Each thread delays for N uS whilst not holding the lock. The default
-   is 0.
+   is 2.
 
  (*) do_sched=1
 
-- 
1.7.7.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/

[PATCH RESEND] ARM: dts: Add EHCI device tree node for Exynos4

[Dongjin Kim]

This patch adds EHCI device node on device tree for Exynos4 and defines its
default platform data, s5p_usb_phy_init and s5p_usb_phy_exit, so that those
function can be called from the driver.

Signed-off-by: Dongjin Kim 
---
 arch/arm/boot/dts/exynos4.dtsi |7 +++
 arch/arm/mach-exynos/mach-exynos4-dt.c |9 +
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 92bca86..df1a9f0 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -140,6 +140,13 @@
status = "disabled";
};
 
+   ehci@1258 {
+   compatible = "samsung,exynos-ehci";
+   reg = <0x1258 0x100>;
+   interrupts = <0 70 0>;
+   status = "disabled";
+   };
+
serial@1380 {
compatible = "samsung,exynos4210-uart";
reg = <0x1380 0x100>;
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c 
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index 92757ff..c8a23f0 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -20,9 +21,15 @@
 
 #include 
 #include 
+#include 
 
 #include "common.h"
 
+static struct s5p_ehci_platdata s5p_ehci_platdata = {
+   .phy_init = s5p_usb_phy_init,
+   .phy_exit = s5p_usb_phy_exit,
+};
+
 /*
  * The following lookup table is used to override device names when devices
  * are registered from device tree. This is temporarily added to enable
@@ -80,6 +87,8 @@ static const struct of_dev_auxdata exynos4_auxdata_lookup[] 
__initconst = {
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_MDMA1, "dma-pl330.2", NULL),
OF_DEV_AUXDATA("samsung,exynos4210-tmu", EXYNOS4_PA_TMU,
"exynos-tmu", NULL),
+   OF_DEV_AUXDATA("samsung,exynos-ehci", EXYNOS4_PA_EHCI,
+   "s5p-ehci", _ehci_platdata),
{},
 };
 
-- 
1.7.10.4

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

[PATCH] ARM: dts: max77686: Add DTS file for max77686 PMIC

[Dongjin Kim]

This patch adds a dedicated DTS file for max77686 PMIC, supposed to be included
in a board DTS to control the power for certain consumer devices or AP with 9 
BUCKs
and 26 LDOs

Signed-off-by: Dongjin Kim 
---
 arch/arm/boot/dts/max77686.dtsi |  156 +++
 1 file changed, 156 insertions(+)
 create mode 100644 arch/arm/boot/dts/max77686.dtsi

diff --git a/arch/arm/boot/dts/max77686.dtsi b/arch/arm/boot/dts/max77686.dtsi
new file mode 100644
index 000..9484a0d
--- /dev/null
+++ b/arch/arm/boot/dts/max77686.dtsi
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2012 Dongjin Kim 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ */
+
+ {
+   compatible = "maxim,max77686";
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   voltage-regulators {
+   buck1: buck@10 {
+   regulator-compatible = "BUCK1";
+   };
+
+   buck2: buck@12 {
+   regulator-compatible = "BUCK2";
+   };
+
+   buck3: buck@1c {
+   regulator-compatible = "BUCK3";
+   };
+
+   buck4: buck@26 {
+   regulator-compatible = "BUCK4";
+   };
+
+   buck5: buck@30 {
+   regulator-compatible = "BUCK5";
+   };
+
+   buck6: buck@32 {
+   regulator-compatible = "BUCK6";
+   };
+
+   buck7: buck@34 {
+   regulator-compatible = "BUCK7";
+   };
+
+   buck8: buck@36 {
+   regulator-compatible = "BUCK8";
+   };
+
+   buck9: buck@38 {
+   regulator-compatible = "BUCK9";
+   };
+
+   ldo1: ldo@40 {
+   regulator-compatible = "LDO1";
+   };
+
+   ldo2: ldo@41 {
+   regulator-compatible = "LDO2";
+   };
+
+   ldo3: ldo@42 {
+   regulator-compatible = "LDO3";
+   };
+
+   ldo4: ldo@43 {
+   regulator-compatible = "LDO4";
+   };
+
+   ldo5: ldo@44 {
+   regulator-compatible = "LDO5";
+   };
+
+   ldo6: ldo@45 {
+   regulator-compatible = "LDO6";
+   };
+
+   ldo7: ldo@46 {
+   regulator-compatible = "LDO7";
+   };
+
+   ldo8: ldo@47 {
+   regulator-compatible = "LDO8";
+   };
+
+   ldo9: ldo@48 {
+   regulator-compatible = "LDO9";
+   };
+
+   ldo10: ldo@49 {
+   regulator-compatible = "LDO10";
+   };
+
+   ldo11: ldo@4a {
+   regulator-compatible = "LDO11";
+   };
+
+   ldo12: ldo@4b {
+   regulator-compatible = "LDO12";
+   };
+
+   ldo13: ldo@4c {
+   regulator-compatible = "LDO13";
+   };
+
+   ldo14: ldo@4d {
+   regulator-compatible = "LDO14";
+   };
+
+   ldo15: ldo@4e {
+   regulator-compatible = "LDO15";
+   };
+
+   ldo16: ldo@4f {
+   regulator-compatible = "LDO16";
+   };
+
+   ldo17: ldo@50 {
+   regulator-compatible = "LDO17";
+   };
+
+   ldo18: ldo@51 {
+   regulator-compatible = "LDO18";
+   };
+
+   ldo19: ldo@52 {
+   regulator-compatible = "LDO19";
+   };
+
+   ldo20: ldo@53 {
+   regulator-compatible = "LDO20";
+   };
+
+   ldo21: ldo@54 {
+   regulator-compatible = "LDO21";
+   };
+
+   ldo22: ldo@55 {
+   regulator-compatible = "LDO22";
+   };
+
+   ldo23: ldo@56 {
+   regulator-compatible = "LDO23";
+   };
+
+   ldo24: ldo@57 {
+   regulator-compatible = "LDO24";
+   };
+
+   ldo25: ldo@58 {
+   regulator-compatible = "LDO25";
+   };
+
+   ldo26: ldo@59 {
+   regulator-compatible = "LDO26";
+   };
+   };
+};
-- 
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 

[PATCH v3 3/4] ODROID-X: dts: Add nodes for leds based on GPIO.

[Dongjin Kim]

This patch adds GPIO connected LEDS on ODROID-X board and configure its
properties.

LED1: use 'heartbeat' trigger, blinking while the board is running.
LED2: use 'mmc0' trigger, on when mmc0 is accessing.

Signed-off-by: Dongjin Kim 
---
 arch/arm/boot/dts/exynos4412-odroidx.dts |   16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 213b152..f31529f 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -54,4 +54,20 @@
enable-active-high;
regulator-boot-on;
};
+
+   leds {
+   compatible = "gpio-leds";
+   led1 {
+   label = "led1:heart";
+   gpios = < 0 1>;
+   default-state = "on";
+   linux,default-trigger = "heartbeat";
+   };
+   led2 {
+   label = "led2:mmc0";
+   gpios = < 2 1>;
+   default-state = "on";
+   linux,default-trigger = "mmc0";
+   };
+   };
 };
-- 
1.7.10.4

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

[PATCH v3 4/4] ODROID-X: dts: Add mshc node for ODROID-X board

[Dongjin Kim]

Adding the device node to support eMMC storage on SDCARD4 ports, controlled by
Mobile Storage Host Controller.

Signed-off-by: Dongjin Kim 
---
 arch/arm/boot/dts/exynos4412-odroidx.dts |   20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index f31529f..04c482e 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -70,4 +70,24 @@
linux,default-trigger = "mmc0";
};
};
+
+   mshc@1255 {
+   pinctrl-0 = <_clk _cmd _bus4 _bus8>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   num-slots = <1>;
+   supports-highspeed;
+   broken-cd;
+   fifo-depth = <0x80>;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3 3>;
+   samsung,dw-mshc-ddr-timing = <1 2 3>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <8>;
+   };
+   };
 };
-- 
1.7.10.4

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

[PATCH v3 2/4] ODROID-X: dts: Add fixed-regulator for peripherals.

[Dongjin Kim]

This patch adds the node to support fixed voltage for peripherals like LED,
ethernet controller.

Signed-off-by: Dongjin Kim 
---
 arch/arm/boot/dts/exynos4412-odroidx.dts |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
index 4915580..213b152 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -44,4 +44,14 @@
pinctrl-names = "default";
status = "okay";
};
+
+   regulator_p3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "p3v3_en";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = < 1 1>;
+   enable-active-high;
+   regulator-boot-on;
+   };
 };
-- 
1.7.10.4

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

[PATCH v3 1/4] ODROID-X: dts: Add board dts file for ODROID-X

[Dongjin Kim]

Add initial dtb file for Hardkernel's ODROID-X board based on EXYNOS4412 SoC.

Signed-off-by: Dongjin Kim 
---
 arch/arm/boot/dts/Makefile   |1 +
 arch/arm/boot/dts/exynos4412-odroidx.dts |   47 ++
 2 files changed, 48 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos4412-odroidx.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e44da40..58381f9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
 dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
+   exynos4412-odroidx.dtb \
exynos4412-smdk4412.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts 
b/arch/arm/boot/dts/exynos4412-odroidx.dts
new file mode 100644
index 000..4915580
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
@@ -0,0 +1,47 @@
+/*
+ * Hardkernel's Exynos4412 based ODROID-X board device tree source
+ *
+ * Copyright (c) 2012 Dongjin Kim 
+ *
+ * Device tree source file for Hardkernel's ODROID-X board which is based on
+ * Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+/include/ "exynos4412.dtsi"
+
+/ {
+   model = "Hardkernel ODROID-X board based on Exynos4412";
+   compatible = "hardkernel,odroid-x", "samsung,exynos4412";
+
+   memory {
+   reg = <0x4000 0x4000>;
+   };
+
+   serial@1380 {
+   status = "okay";
+   };
+
+   serial@1381 {
+   status = "okay";
+   };
+
+   serial@1382 {
+   status = "okay";
+   };
+
+   serial@1383 {
+   status = "okay";
+   };
+
+   sdhci@1253 {
+   bus-width = <4>;
+   pinctrl-0 = <_clk _cmd _cd _bus4>;
+   pinctrl-names = "default";
+   status = "okay";
+   };
+};
-- 
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] ARM: EXYNOS5: Support Exynos5-bus devfreq driver

[Abhilash Kesavan]

On Sun, Dec 30, 2012 at 11:45 AM, Olof Johansson  wrote:
> Hi,
Hi Olof,
>> +# ppmu support
>> +
>> +obj-$(CONFIG_EXYNOS5250_PPMU)+= exynos_ppmu.o exynos5_ppmu.o
>
> Quite obvious that it's ppmu support from the file names. No need for
> a comment.
Will improve the commenting in the file.
Also, will fix the whitespace, empty lines in the file.
>
>> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
>> index 578a610..a285080 100644
>> --- a/arch/arm/mach-exynos/common.c
>> +++ b/arch/arm/mach-exynos/common.c
>> @@ -308,6 +308,31 @@ static struct map_desc exynos5_iodesc[] __initdata = {
>>   .pfn= __phys_to_pfn(EXYNOS5_PA_UART),
>>   .length = SZ_512K,
>>   .type   = MT_DEVICE,
>> + }, {
>> + .virtual= (unsigned long)S5P_VA_PPMU_CPU,
>> + .pfn= __phys_to_pfn(EXYNOS5_PA_PPMU_CPU),
>> + .length = SZ_8K,
>> + .type   = MT_DEVICE,
>> + }, {
>> + .virtual= (unsigned long)S5P_VA_PPMU_DDR_C,
>> + .pfn= __phys_to_pfn(EXYNOS5_PA_PPMU_DDR_C),
>> + .length = SZ_8K,
>> + .type   = MT_DEVICE,
>> + }, {
>> + .virtual= (unsigned long)S5P_VA_PPMU_DDR_R1,
>> + .pfn= __phys_to_pfn(EXYNOS5_PA_PPMU_DDR_R1),
>> + .length = SZ_8K,
>> + .type   = MT_DEVICE,
>> + }, {
>> + .virtual= (unsigned long)S5P_VA_PPMU_DDR_L,
>> + .pfn= __phys_to_pfn(EXYNOS5_PA_PPMU_DDR_L),
>> + .length = SZ_8K,
>> + .type   = MT_DEVICE,
>> + }, {
>> + .virtual= (unsigned long)S5P_VA_PPMU_RIGHT,
>> + .pfn= __phys_to_pfn(EXYNOS5_PA_PPMU_RIGHT),
>> + .length = SZ_8K,
>> + .type   = MT_DEVICE,
>>   },
>
> You should add the ppmu device to the device tree, and get the addresses from
> there instead (via ioremap).
>
> That way you can make this driver probe using regular methods too.
Will re-work to remove these static mappings.
>
>> +
>> +#include 
>> +#include 
>
> Can you avoid adding new mach includes for this, perhaps? We're working hard 
> on
> removing them for all platforms, even though exynos is lagging behind on it.
> Local defines that are used in just one C file can either go in that file, or
> in a header file that sits next to it instead of in the shared directory. For
> the devfreq driver, include/linux/* is a better location.
Will do.
>
>> +#define FIXED_POINT_OFFSET 8
>> +#define FIXED_POINT_MASK ((1 << FIXED_POINT_OFFSET) - 1)
>
> 0xff. Easier to read for a single entry like this.
OK

Thanks,
Abhilash
--
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 v2] input: vt8500: Add power button keypad driver

[Tony Prisk]

This patch adds support for the Power Button keypad found on
Wondermedia netbooks/tablets.

Signed-off-by: Tony Prisk 
---
v2:
Remove devicetree binding for keycode
Add dependency on OF in Kconfig
Move static variables in a struct
Remove redundant inline modifier from kpad_power_timeout()
Remove unneccessary checks against power_button_pressed. Drop variable.
Cleanup the fail path code and add a .remove function.
Change the button behaviour so that a key-released event is only generated once
the key is released, not after timeout.
*Changes tested on WM8650 tablet.

 .../bindings/input/vt8500-power-keypad.txt |   15 ++
 drivers/input/keyboard/Kconfig |   10 +
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/wmt_power_keypad.c  |  198 
 4 files changed, 224 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
 create mode 100644 drivers/input/keyboard/wmt_power_keypad.c

diff --git a/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt 
b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
new file mode 100644
index 000..63f170b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
@@ -0,0 +1,15 @@
+* Wondermedia Power Keypad device tree bindings
+
+Wondermedia SoCs have a single irq-driven power button attached to
+the power management controller.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+   - "wm,power-keypad": For all Wondermedia 8xxx-series SoCs.
+- interrupts: should be the power management controller wakeup interrupt.
+
+Example:
+   powerkey: pwrkey@0 {
+   compatible = "wm,power-keypad";
+   interrupts = <22>;
+   };
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 5a240c6..bb1e04f 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -595,6 +595,16 @@ config KEYBOARD_TWL4030
  To compile this driver as a module, choose M here: the
  module will be called twl4030_keypad.
 
+config KEYBOARD_WMT_POWER_KEYPAD
+   tristate "Wondermedia Power keypad support"
+   depends on (OF && ARCH_VT8500)
+   help
+ Say Y here to enable support for the power button keypad
+ on Wondermedia 8xxx-series SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called wmt_power_keypad.
+
 config KEYBOARD_XTKBD
tristate "XT keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..eea31af 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)+= 
tc3589x-keypad.o
 obj-$(CONFIG_KEYBOARD_TEGRA)   += tegra-kbc.o
 obj-$(CONFIG_KEYBOARD_TNETV107X)   += tnetv107x-keypad.o
 obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
+obj-$(CONFIG_KEYBOARD_WMT_POWER_KEYPAD)+= wmt_power_keypad.o
 obj-$(CONFIG_KEYBOARD_XTKBD)   += xtkbd.o
 obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/wmt_power_keypad.c 
b/drivers/input/keyboard/wmt_power_keypad.c
new file mode 100644
index 000..f3b24d8
--- /dev/null
+++ b/drivers/input/keyboard/wmt_power_keypad.c
@@ -0,0 +1,198 @@
+/* Wondermedia Power Keypad
+ *
+ * Copyright (C) 2012 Tony Prisk 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct kpad_pwr_data {
+   struct input_dev*kpad_power;
+   void __iomem*pmc_base;
+   int irq;
+   struct timer_list   timer;
+   spinlock_t  lock;
+   unsigned intkeycode;
+};
+
+static void kpad_power_timeout(unsigned long fcontext)
+{
+   struct kpad_pwr_data *data = (struct kpad_pwr_data *)fcontext;
+   u32 status;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+
+   status = readl(data->pmc_base + 0x14);
+   if (status & BIT(14)) {
+   /* Button isn't release so check again in 50ms */
+   mod_timer(>timer, jiffies + msecs_to_jiffies(50));
+   } else {
+   /* Send a button released message */
+   input_report_key(data->kpad_power, data->keycode, 0);
+   

Re: [ibm-acpi-devel] [PATCH] drivers/platform/x86/thinkpad_acpi.c: Handle HKEY event 0x6040

[Henrique de Moraes Holschuh]

On Sun, 30 Dec 2012, Richard Hartmann wrote:
> On Sun, Dec 30, 2012 at 3:00 AM, Henrique de Moraes Holschuh  > wrote:
> 
> > Acked-by: Henrique de Moraes Holschuh 
> >
> 
> Thanks for the two ACKs.
> 
> Just to make sure: From how I read the (outdated) Copyright section, you
> are the maintainer of thinkpad_acpi and thus will copy over the ACKs into
> my commit message, merge, and forward into what will become 3.9 at some
> point, correct?

Usually the subsystem maintainer picks such simple patches and ACKs directly
from the platform-driver-x86 list email, adds his signed-of-by, and
eventually sends it to Linus.

For this "obviously correct" single-code-line fix, we might even lucky
out and it could make it to 3.8, depends on his judgment.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/

[RESEND PATCH] drm/nouveau: fix init with agpgart-uninorth

[Aaro Koskinen]

Check that the AGP aperture can be mapped. This follows a similar change
done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if
the aperture can be mapped by the CPU.).

The patch fixes the following error seen on G5 iMac:

nouveau E[ DRM] failed to create kernel channel, -12

Reviewed-by: Michel Dänzer 
Signed-off-by: Aaro Koskinen 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 5614c89..69d7b1d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1276,7 +1276,7 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_mem_reg *mem)
if (drm->agp.stat == ENABLED) {
mem->bus.offset = mem->start << PAGE_SHIFT;
mem->bus.base = drm->agp.base;
-   mem->bus.is_iomem = true;
+   mem->bus.is_iomem = !dev->agp->cant_use_aperture;
}
 #endif
break;
-- 
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: kernel panic on resume from S3 - stumped

[Tim Hockin]

On Sun, Dec 30, 2012 at 2:55 PM, Rafael J. Wysocki  wrote:
> On Saturday, December 29, 2012 11:17:11 PM Tim Hockin wrote:
>> Best guess:
>>
>> With 'noapic', I see the "irq 5: nobody cared" message on resume,
>> along with 1 IRQ5 counts in /proc/interrupts (the devices claiming
>> that IRQ are quiescent).
>>
>> Without 'noapic' that must be triggering something else to go haywire,
>> perhaps the AER logic (though that is all MSI, so probably not).  I'm
>> flying blind on those boots.
>>
>> I bet that, if I can recall how to re-enable IRQ5, I'll see it
>> continuously asserting.  Chipset or BIOS bug maybe.  I don't know if I
>> had AER enabled under Lucid, so that might be the difference.
>>
>> I'll try a vanilla kernel next, maybe hack on AER a bit, to see if I
>> can make it progress.
>
> I wonder what happens if you simply disable AER for starters?
>
> There is the pci=noaer kernel command line switch for that.

That still panics on resume.  Damn.  I really think it is down to that
interrupt storm at resume.  Something somewhere is getting stuck
asserting, and we don't know how to EOI it.  PIC vs APIC is just
changing the operating mode.

Now the question is whether I am going to track through Intel errata
(more than I have already) and through chipset docs to figure out what
it could be, or just leave it at noapic.

I've already got one new PCI quirk to code up.

> Thanks,
> Rafael
>
>
>> On Sat, Dec 29, 2012 at 10:19 PM, Tim Hockin  wrote:
>> > Quick update: booting with 'noapic' on the commandline seems to make
>> > it resume successfully.
>> >
>> > The main dmesg diffs, other than the obvious "Skipping IOAPIC probe"
>> > and IRG number diffs) are:
>> >
>> > -nr_irqs_gsi: 40
>> > +nr_irqs_gsi: 16
>> >
>> > -NR_IRQS:16640 nr_irqs:776 16
>> > +NR_IRQS:16640 nr_irqs:368 16
>> >
>> > -system 00:0a: [mem 0xfec0-0xfec00fff] could not be reserved
>> > +system 00:0a: [mem 0xfec0-0xfec00fff] has been reserved
>> >
>> > and a new warning about irq 5: nobody cared (try booting with the
>> > "irqpoll" option)
>> >
>> > I'll see if I can sort out further differences, but I thought it was
>> > worth sending this new info along, anyway.
>> >
>> > It did not require 'noapic' on the Lucid (2.6.32?) kernel
>> >
>> >
>> > On Sat, Dec 29, 2012 at 9:34 PM, Tim Hockin  wrote:
>> >> Running a suspend with pm_trace set, I get:
>> >>
>> >> aer :00:03.0:pcie02: hash matches
>> >>
>> >> I don't know what magic might be needed here, though.
>> >>
>> >> I guess next step is to try to build a non-distro kernel.
>> >>
>> >> On Sat, Dec 29, 2012 at 1:57 PM, Rafael J. Wysocki  wrote:
>> >>> On Saturday, December 29, 2012 12:03:13 PM Tim Hockin wrote:
>>  4 days ago I had Ubuntu Lucid running on this computer. Suspend and
>>  resume worked flawlessly every time.
>> 
>>  Then I upgraded to Ubuntu Precise.
>> >>>
>> >>> Well, do you use a distro kernel or a kernel.org kernel?
>> >>>
>>  Suspend seems to work, but resume
>>  fails every time. The video never initializes.  By the flashing
>>  keyboard lights, I guess it's a kernel panic. It fails from the Live
>>  CD and from a fresh install.
>> 
>>  Here is my debug so far.
>> 
>>  Install all updates (3.2 kernel, nouveau driver)
>>  Reboot
>>  Try suspend = fails
>> 
>>  Install Ubuntu's linux-generic-lts-quantal (3.5 kernel, nouveau driver)
>>  Reboot
>>  Try suspend = fails
>> 
>>  Install nVidia's 304 driver
>>  Reboot
>>  Try suspend = fails
>> 
>>  From within X:
>>    echo core > /sys/power/pm_test
>>    echo mem > /sys/power/state
>>  The system acts like it is going to sleep, and then wakes up a few
>>  seconds later. dmesg shows:
>> 
>>  [ 1230.083404] [ cut here ]
>>  [ 1230.083410] WARNING: at
>>  /build/buildd/linux-lts-quantal-3.5.0/kernel/power/suspend_test.c:53
>>  suspend_test_finish+0x86/0x90()
>>  [ 1230.083411] Hardware name: To Be Filled By O.E.M.
>>  [ 1230.083412] Component: resume devices, time: 14424
>>  [ 1230.083412] Modules linked in: snd_emu10k1_synth snd_emux_synth
>>  snd_seq_virmidi snd_seq_midi_emul bnep rfcomm parport_pc ppdev
>>  nvidia(PO) snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm snd_page_alloc
>>  snd_util_mem snd_hwdep snd_seq_midi snd_rawmidi snd_seq_midi_event
>>  snd_seq snd_timer coretemp snd_seq_device kvm_intel kvm snd
>>  ghash_clmulni_intel soundcore aesni_intel btusb cryptd aes_x86_64
>>  bluetooth i7core_edac edac_core microcode mac_hid lpc_ich mxm_wmi
>>  shpchp serio_raw wmi hid_generic lp parport usbhid hid r8169
>>  pata_marvell
>>  [ 1230.083445] Pid: 3329, comm: bash Tainted: P O 3.5.0-21-generic
>>  #32~precise1-Ubuntu
>>  [ 1230.083446] Call Trace:
>>  [ 1230.083448] [] warn_slowpath_common+0x7f/0xc0
>>  [ 1230.083452] [] warn_slowpath_fmt+0x46/0x50
>>  [ 1230.083455] [] 

Re: Linus GIT (3.8.0-rc1+) -- drivers/built-in.o: In function `nouveau_acpi_edid': (.text+0x134e47): undefined reference to `acpi_video_get_edid'

[Dave Airlie]

On Mon, Dec 31, 2012 at 10:41 AM, Miles Lane  wrote:
>   LD  init/built-in.o
> drivers/built-in.o: In function `nouveau_acpi_edid':
> (.text+0x134e47): undefined reference to `acpi_video_get_edid'

Wierd not really sure why this would have just stared happening.
select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE &&
VIDEO_OUTPUT_CONTROL && INPUT

should pick ACPI_VIDEO=y from what I can see if nouveau is y, unless I
misunderstand Kconfig, which is most probable.

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

Re: [PATCH] mm: fix null pointer dereference in wait_iff_congested()

[Minchan Kim]

Hi Zlatko,

On Fri, Dec 28, 2012 at 02:29:11PM +0100, Zlatko Calusic wrote:
> On 28.12.2012 03:49, Minchan Kim wrote:
> >Hello Zlatko,
> >
> >On Fri, Dec 28, 2012 at 03:16:38AM +0100, Zlatko Calusic wrote:
> >>From: Zlatko Calusic 
> >>
> >>The unintended consequence of commit 4ae0a48b is that
> >>wait_iff_congested() can now be called with NULL struct zone*
> >>producing kernel oops like this:
> >
> >For good description, it would be better to write simple pseudo code
> >flow to show how NULL-zone pass into wait_iff_congested because
> >kswapd code flow is too complex.
> >
> >As I see the code, we have following line above wait_iff_congested.
> >
> >if (!unbalanced_zone || blah blah)
> > break;
> >
> >How can NULL unbalanced_zone reach wait_iff_congested?
> >
> 
> Hello Minchan, and thanks for the comment.
> 
> That line was there before commit 4ae0a48b got in, and you're right,

Argh, I didn't see 4ae0a48b in 3.8-rc1.

> it's what was protecting wait_iff_congested() from being called with
> NULL zone*. But then all that logic got colapsed to a simple
> pgdat_balanced() call and that's when I introduced the bug, I lost
> the protection.
> 
> What I _think_ is happening (pseudo code following...) is that after
> scanning the zone in the dma->highmem direction, and concluding that
> all zones are balanced (unbalanced_zone remains NULL!),
> wake_up(>pfmemalloc_wait) wakes up a lot of memory hungry
> processes (especially true in various aggressive test/benchmarks)
> that immediately drain and unbalance one or more zones. Then
> pgdat_balanced() call which immediately follows will be false, but
> we still have unbalanced_zone = NULL, rememeber? Oops...
> 
> But, all that is a speculation that I can't prove atm. Of course, if
> anybody thinks that's a credible explanation, I could add it as a
> commit comment, or even as a code comment, but I didn't want to be
> overly imaginative. The fix itself is simple and real.

Never mind. My confusing is caused my missing 4ae0a48b in lasest tree.
Thanks, Zlatko.

> 
> Regards,
> -- 
> Zlatko
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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/

[Update 3][PATCH] ACPI / PM: Rework the handling of devices depending on power resources

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Commit 0090def6 (ACPI: Add interface to register/unregister device
to/from power resources) made it possible to indicate to the ACPI
core that if the given device depends on any power resources, then
it should be resumed as soon as all of the power resources required
by it to transition to the D0 power state have been turned on.

Unfortunately, however, this was a mistake, because all devices
depending on power resources should be treated this way (i.e. they
should be resumed when all power resources required by their D0
state have been turned on) and the ACPI core can figure out by itself
which (physical) devices depend on what power resources.

For this reason, replace the code added by commit 0090def6 with a
new, much more straightforward, mechanism that will be used
internally by the ACPI core and remove all references to that code
from kernel subsystems using ACPI.

Signed-off-by: Rafael J. Wysocki 
---

One more update, hopefully the last one.

The previous version added devices to power resources' "dependent devices"
lists too early and they might be left on those lists inadvertently if there
were problems with registering them.  To fix this make the addition of devices
to those lists symmetrical with respect to the removal (this also simplifies
the patch slightly).

Thanks,
Rafael

---
 drivers/acpi/internal.h   |1 
 drivers/acpi/power.c  |  215 --
 drivers/acpi/scan.c   |7 +
 drivers/ata/libata-acpi.c |4 
 drivers/pci/pci-acpi.c|2 
 include/acpi/acpi_bus.h   |2 
 6 files changed, 87 insertions(+), 144 deletions(-)

Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -725,6 +725,7 @@ static int acpi_device_register(struct a
dev_err(>dev, "Error registering device\n");
goto end;
}
+   acpi_power_add_remove_device(device, true);
 
result = acpi_device_setup_files(device);
if (result)
@@ -754,7 +755,13 @@ static void acpi_device_unregister(struc
acpi_detach_data(device->handle, acpi_bus_data_handler);
 
acpi_device_remove_files(device);
+   acpi_power_add_remove_device(device, false);
device_unregister(>dev);
+   /*
+* Drop the reference counts of all power resources the device depends
+* on and turn off the ones that have no more references.
+*/
+   acpi_power_transition(device, ACPI_STATE_D3_COLD);
 }
 
 /* --
Index: linux/drivers/acpi/power.c
===
--- linux.orig/drivers/acpi/power.c
+++ linux/drivers/acpi/power.c
@@ -83,31 +83,20 @@ static struct acpi_driver acpi_power_dri
.drv.pm = _power_pm,
 };
 
-/*
- * A power managed device
- * A device may rely on multiple power resources.
- * */
-struct acpi_power_managed_device {
-   struct device *dev; /* The physical device */
-   acpi_handle *handle;
-};
-
-struct acpi_power_resource_device {
-   struct acpi_power_managed_device *device;
-   struct acpi_power_resource_device *next;
+struct acpi_power_dependent_device {
+   struct list_head node;
+   struct acpi_device *adev;
+   struct work_struct work;
 };
 
 struct acpi_power_resource {
-   struct acpi_device * device;
+   struct acpi_device *device;
+   struct list_head dependent;
acpi_bus_id name;
u32 system_level;
u32 order;
unsigned int ref_count;
struct mutex resource_lock;
-
-   /* List of devices relying on this power resource */
-   struct acpi_power_resource_device *devices;
-   struct mutex devices_lock;
 };
 
 static struct list_head acpi_power_resource_list;
@@ -207,21 +196,27 @@ static int acpi_power_get_list_state(str
return 0;
 }
 
-/* Resume the device when all power resources in _PR0 are on */
-static void acpi_power_on_device(struct acpi_power_managed_device *device)
+static void acpi_power_resume_dependent(struct work_struct *work)
 {
-   struct acpi_device *acpi_dev;
-   acpi_handle handle = device->handle;
+   struct acpi_power_dependent_device *dep;
+   struct acpi_device_physical_node *pn;
+   struct acpi_device *adev;
int state;
 
-   if (acpi_bus_get_device(handle, _dev))
+   dep = container_of(work, struct acpi_power_dependent_device, work);
+   adev = dep->adev;
+   if (acpi_power_get_inferred_state(adev, ))
return;
 
-   if(acpi_power_get_inferred_state(acpi_dev, ))
+   if (state > ACPI_STATE_D0)
return;
 
-   if (state == ACPI_STATE_D0 && pm_runtime_suspended(device->dev))
-   pm_request_resume(device->dev);
+   mutex_lock(>physical_node_lock);
+
+   list_for_each_entry(pn, >physical_node_list, 

[PATCH] ACPI / scan: Treat power resources in a special way

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Commit 1d57433 (ACPI: Separate adding ACPI device objects from
probing ACPI drivers) introduced an ACPI power resources management
regression, because it didn't ensure that the power resources
driver bind to the struct acpi_device objects corresponding
to power resources as soon as they were created.  As a result,
ACPI power management routines may attempt to access power resource
objects before they are ready to use.

To fix this problem, tell the acpi_add_single_object() in
acpi_bus_check_add() to probe the driver for objects of type
ACPI_BUS_TYPE_POWER.  This fix has been verified to work on
HP nx6325 where the problem was first observed.

Signed-off-by: Rafael J. Wysocki 
---

The commit mentioned in the changelog is in linux-next only for now, but
it's likely to go upstream in this form anyway and the fix on top of the
whole ACPI scan series is trivial.

Thanks,
Rafael

---
 drivers/acpi/scan.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -1606,7 +1606,8 @@ static acpi_status acpi_bus_check_add(ac
return AE_CTRL_DEPTH;
}
 
-   acpi_add_single_object(, handle, type, sta, false);
+   acpi_add_single_object(, handle, type, sta,
+  type == ACPI_BUS_TYPE_POWER);
if (!device)
return AE_CTRL_DEPTH;
 

--
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] input: vt8500: Add power button keypad driver

[Dmitry Torokhov]

On Mon, Dec 31, 2012 at 12:44:31PM +1300, Tony Prisk wrote:
> 
> > > + status = readl(pmc_base + 0x14);
> > > + udelay(100);
> > > + writel(status, pmc_base + 0x14);
> > > +
> > > + if (status & BIT(14)) {
> > > + if (!power_button_pressed) {
> > 
> > No need to do this check.
> > 
> The hardware generates multiple interrupts when the button is held.
> Without the !power_button_pressed, it will generate multiple pressed
> events without releases, because the timer doesn't get to finish.

Input core will filter out duplicate events anyway though...

And your current way means that timer is never adjusted, so the key will
be released and reported as pressed again if I keep holding it, which is
not correct.

Thanks.

-- 
Dmitry
--
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] input: vt8500: Add power button keypad driver

[Tony Prisk]

> > +Example:
> > +   powerkey: pwrkey@0 {
> > +   compatible = "wm,power-keypad";
> > +   interrupts = <22>;
> > +   keymap = <116>; /* KEY_POWER */
> 
> Do we really need this in DT? I'd say just having it manageable from
> userspace is enough.

Just seemed easier this way. Will be changed.

> > +config KEYBOARD_WMT_POWER_KEYPAD
> > +   tristate "Wondermedia Power keypad support"
> > +   depends on ARCH_VT8500
> 
> I'd feel safer if we added "depends on OF" as well.
ARCH_VT8500 always selects USE_OF, but I can add it as well if you think
its necessary.

> > +
> > +static void __iomem *pmc_base;
> > +static struct input_dev *kpad_power;
> > +static spinlock_t kpad_power_lock;
> > +static int power_button_pressed;
> > +static struct timer_list kpad_power_timer;
> > +static unsigned int kpad_power_code;
> 
> Maybe wrap it in a structure?
Will do.

> 
> > +
> > +static inline void kpad_power_timeout(unsigned long fcontext)
> 
> Why inline? It can't be inlined anyway since its address is used.
> 
Umm, no idea why this is inline. Will remove.

> > +{
> > +   u32 status;
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(_power_lock, flags);
> > +
> > +   status = readl(pmc_base + 0x14);
> > +
> > +   if (power_button_pressed) {
> 
> This check is useless, you won't ever get here if button hasn't been
> pressed.
> 
Hmm, correct. Will fix.

> > +   status = readl(pmc_base + 0x14);
> > +   udelay(100);
> > +   writel(status, pmc_base + 0x14);
> > +
> > +   if (status & BIT(14)) {
> > +   if (!power_button_pressed) {
> 
> No need to do this check.
> 
The hardware generates multiple interrupts when the button is held.
Without the !power_button_pressed, it will generate multiple pressed
events without releases, because the timer doesn't get to finish.

The interrupt is non-maskable.


> > +static int vt8500_pwr_kpad_probe(struct platform_device *pdev)
> > +{
> > +   struct device_node *np;
> > +   u32 status;
> > +   int err;
> > +   int irq;
> > +
> > +   np = of_find_compatible_node(NULL, NULL, "via,vt8500-pmc");
> > +   if (!np) {
> > +   dev_err(>dev, "pmc node not found\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   pmc_base = of_iomap(np, 0);
> > +   if (!pmc_base) {
> > +   dev_err(>dev, "unable to map pmc memory\n");
> > +   return -ENOMEM;
> > +   }
> > +
> > +   np = pdev->dev.of_node;
> > +   if (!np) {
> > +   dev_err(>dev, "devicenode not found\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   err = of_property_read_u32(np, "keymap", _power_code);
> > +   if (err) {
> > +   dev_warn(>dev, "defaulting to KEY_POWER\n");
> > +   kpad_power_code = KEY_POWER;
> > +   }
> > +
> > +   /* set power button to soft-power */
> > +   status = readl(pmc_base + 0x54);
> > +   writel(status | 1, pmc_base + 0x54);
> > +
> > +   /* clear any pending interrupts */
> > +   status = readl(pmc_base + 0x14);
> > +   writel(status, pmc_base + 0x14);
> > +
> > +   kpad_power = input_allocate_device();
> > +   if (!kpad_power) {
> > +   dev_err(>dev, "failed to allocate input device\n");
> > +   return -ENOMEM;
> > +   }
> > +
> > +   spin_lock_init(_power_lock);
> > +   setup_timer(_power_timer, kpad_power_timeout,
> > +  (unsigned long)kpad_power);
> > +
> > +   irq = irq_of_parse_and_map(np, 0);
> > +   err = request_irq(irq, _power_isr, 0, "pwrbtn", NULL);
> > +   if (err < 0) {
> > +   dev_err(>dev, "failed to request irq\n");
> > +   return err;
> > +   }
> > +
> > +   kpad_power->evbit[0] = BIT_MASK(EV_KEY);
> > +   set_bit(kpad_power_code, kpad_power->keybit);
> > +
> > +   kpad_power->name = "wmt_power_keypad";
> > +   kpad_power->phys = "wmt_power_keypad";
> > +   kpad_power->keycode = _power_code;
> > +   kpad_power->keycodesize = sizeof(unsigned int);
> > +   kpad_power->keycodemax = 1;
> > +
> > +   err = input_register_device(kpad_power);
> > +   if (err < 0) {
> > +   dev_err(>dev, "failed to register input device\n");
> 
> You either need to use managed resources or clean up after yourself;
> leaking memory and other resources is not nice. Given that you are using
> timer, which needs to be canceled, and I am not sure if your device
> allows enabling/disabling generating interrupts while keeping the
> interrupt handler registered, manual cleanup looks like the only option
> for you.
> 
> BTW, where is your remove() method?
Eeek. Too much turkey :) I will tidy this up and resubmit.

Thanks for the quick review.

Regards
Tony P

--
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] input: vt8500: Add power button keypad driver

[Dmitry Torokhov]

Hi Tony,

On Mon, Dec 31, 2012 at 11:01:02AM +1300, Tony Prisk wrote:
> This patch adds support for the Power Button keypad found on
> Wondermedia netbooks/tablets.
> 
> A keymap property is exposed to allowing defining the key
> event to be generated when the power button is pressed.
> 
> Signed-off-by: Tony Prisk 
> ---
>  .../bindings/input/vt8500-power-keypad.txt |   17 ++
>  drivers/input/keyboard/Kconfig |   10 ++
>  drivers/input/keyboard/Makefile|1 +
>  drivers/input/keyboard/wmt_power_keypad.c  |  174 
> 
>  4 files changed, 202 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
>  create mode 100644 drivers/input/keyboard/wmt_power_keypad.c
> 
> diff --git a/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt 
> b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
> new file mode 100644
> index 000..bae6228
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
> @@ -0,0 +1,17 @@
> +* Wondermedia Power Keypad device tree bindings
> +
> +Wondermedia SoCs have a single irq-driven power button attached to
> +the power management controller.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> +   - "wm,power-keypad": For all Wondermedia 8xxx-series SoCs.
> +- interrupts: should be the power management controller wakeup interrupt.
> +- keymap: linux keycode to generate when power button pressed.
> +
> +Example:
> + powerkey: pwrkey@0 {
> + compatible = "wm,power-keypad";
> + interrupts = <22>;
> + keymap = <116>; /* KEY_POWER */

Do we really need this in DT? I'd say just having it manageable from
userspace is enough.

> + };
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 5a240c6..c270f27 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -595,6 +595,16 @@ config KEYBOARD_TWL4030
> To compile this driver as a module, choose M here: the
> module will be called twl4030_keypad.
>  
> +config KEYBOARD_WMT_POWER_KEYPAD
> + tristate "Wondermedia Power keypad support"
> + depends on ARCH_VT8500

I'd feel safer if we added "depends on OF" as well.

> + help
> +   Say Y here to enable support for the power button keypad
> +   on Wondermedia 8xxx-series SoCs.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called wmt_power_keypad.
> +
>  config KEYBOARD_XTKBD
>   tristate "XT keyboard"
>   select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 44e7600..eea31af 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)  += 
> tc3589x-keypad.o
>  obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
>  obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
>  obj-$(CONFIG_KEYBOARD_TWL4030)   += twl4030_keypad.o
> +obj-$(CONFIG_KEYBOARD_WMT_POWER_KEYPAD)  += wmt_power_keypad.o
>  obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
>  obj-$(CONFIG_KEYBOARD_W90P910)   += w90p910_keypad.o
> diff --git a/drivers/input/keyboard/wmt_power_keypad.c 
> b/drivers/input/keyboard/wmt_power_keypad.c
> new file mode 100644
> index 000..ce8aa9a
> --- /dev/null
> +++ b/drivers/input/keyboard/wmt_power_keypad.c
> @@ -0,0 +1,174 @@
> +/* Wondermedia Power Keypad
> + *
> + * Copyright (C) 2012 Tony Prisk 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void __iomem *pmc_base;
> +static struct input_dev *kpad_power;
> +static spinlock_t kpad_power_lock;
> +static int power_button_pressed;
> +static struct timer_list kpad_power_timer;
> +static unsigned int kpad_power_code;

Maybe wrap it in a structure?

> +
> +static inline void kpad_power_timeout(unsigned long fcontext)

Why inline? It can't be inlined anyway since its address is used.

> +{
> + u32 status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(_power_lock, flags);
> +
> + status = readl(pmc_base + 0x14);
> +
> + if (power_button_pressed) {

This check is useless, you won't ever get here if button hasn't been
pressed.

> + 

Re: i915: GPU hang

[Heinz Diehl]

On 30.12.2012, Guennadi Liakhovetski wrote: 

> Did that and it did work for a while, longer than the average with 3.5. I 
> was already about to write a success report, but then it hung again 
> yesterday. I'm not using this laptop very intensively, so, it is hard to 
> collect statistics.

You could try to reproduce the error by writing a big file e.g.

 dd if=/dev/zero of=deleteme bs=1M count=8

or similar and watching high definition video on Youtube (1080p) or running a 
few
instances of glxgears. That triggers a gpu hang in my case after
just a couple of seconds.

In my case, the hang doesn't occur when using SNA (or a kernel < 3.7,
which isn't the case with your bug). I have this in my
xorg.conf:

Section "Device"
   Identifier "Card0"
   Driver "intel"
   Option "AccelMethod" "SNA"
EndSection

Without this, every 3.7 kernel produces a gpu hang within max. 1 min.

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

[Update 2][PATCH] ACPI / PM: Rework the handling of devices depending on power resources

[Rafael J. Wysocki]

From: Rafael J. Wysocki 
Subject: ACPI / PM: Rework the handling of devices depending on power resources

Commit 0090def6 (ACPI: Add interface to register/unregister device
to/from power resources) made it possible to indicate to the ACPI
core that if the given device depends on any power resources, then
it should be resumed as soon as all of the power resources required
by it to transition to the D0 power state have been turned on.

Unfortunately, however, this was a mistake, because all devices
depending on power resources should be treated this way (i.e. they
should be resumed when all power resources required by their D0
state have been turned on) and the ACPI core can figure out by itself
which (physical) devices depend on what power resources.

For this reason, replace the code added by commit 0090def6 with a
new, much more straightforward, mechanism that will be used
internally by the ACPI core and remove all references to that code
from kernel subsystems using ACPI.

Signed-off-by: Rafael J. Wysocki 
---

Second update: add the missing initialization of resource->dependent in
acpi_power_add().

Thanks,
Rafael

---
 drivers/acpi/internal.h   |2 
 drivers/acpi/power.c  |  211 --
 drivers/acpi/scan.c   |   26 -
 drivers/ata/libata-acpi.c |4 
 drivers/pci/pci-acpi.c|2 
 include/acpi/acpi_bus.h   |2 
 6 files changed, 99 insertions(+), 148 deletions(-)

Index: linux/drivers/acpi/scan.c
===
--- linux.orig/drivers/acpi/scan.c
+++ linux/drivers/acpi/scan.c
@@ -755,6 +755,14 @@ static void acpi_device_unregister(struc
 
acpi_device_remove_files(device);
device_unregister(>dev);
+
+   /*
+* Remove the device from the dependent devices lists of all of its
+* power resources, drop the reference counts of all power resources it
+* depends on and turn off the ones that have no more references.
+*/
+   acpi_power_remove_device(device);
+   acpi_power_transition(device, ACPI_STATE_D3_COLD);
 }
 
 /* --
@@ -1053,6 +1061,19 @@ static void acpi_bus_get_wakeup_device_f
 
 static void acpi_bus_add_power_resource(acpi_handle handle);
 
+static void acpi_bus_update_power_resources(struct acpi_device *device,
+   struct acpi_device_power_state *ps)
+{
+   int j;
+
+   for (j = 0; j < ps->resources.count; j++) {
+   acpi_handle rhandle = ps->resources.handles[j];
+
+   acpi_bus_add_power_resource(rhandle);
+   acpi_power_add_dependent(rhandle, device);
+   }
+}
+
 static int acpi_bus_get_power_flags(struct acpi_device *device)
 {
acpi_status status = 0;
@@ -1081,11 +1102,8 @@ static int acpi_bus_get_power_flags(stru
acpi_evaluate_reference(device->handle, object_name, NULL,
>resources);
if (ps->resources.count) {
-   int j;
-
device->power.flags.power_resources = 1;
-   for (j = 0; j < ps->resources.count; j++)
-   
acpi_bus_add_power_resource(ps->resources.handles[j]);
+   acpi_bus_update_power_resources(device, ps);
}
 
/* Evaluate "_PSx" to see if we can do explicit sets */
Index: linux/drivers/acpi/power.c
===
--- linux.orig/drivers/acpi/power.c
+++ linux/drivers/acpi/power.c
@@ -83,31 +83,20 @@ static struct acpi_driver acpi_power_dri
.drv.pm = _power_pm,
 };
 
-/*
- * A power managed device
- * A device may rely on multiple power resources.
- * */
-struct acpi_power_managed_device {
-   struct device *dev; /* The physical device */
-   acpi_handle *handle;
-};
-
-struct acpi_power_resource_device {
-   struct acpi_power_managed_device *device;
-   struct acpi_power_resource_device *next;
+struct acpi_power_dependent_device {
+   struct list_head node;
+   struct acpi_device *adev;
+   struct work_struct work;
 };
 
 struct acpi_power_resource {
-   struct acpi_device * device;
+   struct acpi_device *device;
+   struct list_head dependent;
acpi_bus_id name;
u32 system_level;
u32 order;
unsigned int ref_count;
struct mutex resource_lock;
-
-   /* List of devices relying on this power resource */
-   struct acpi_power_resource_device *devices;
-   struct mutex devices_lock;
 };
 
 static struct list_head acpi_power_resource_list;
@@ -207,21 +196,27 @@ static int acpi_power_get_list_state(str
return 0;
 }
 
-/* Resume the device when all power resources in _PR0 are on */
-static void acpi_power_on_device(struct acpi_power_managed_device *device)
+static void 

Re: kernel panic on resume from S3 - stumped

[Rafael J. Wysocki]

On Saturday, December 29, 2012 11:17:11 PM Tim Hockin wrote:
> Best guess:
> 
> With 'noapic', I see the "irq 5: nobody cared" message on resume,
> along with 1 IRQ5 counts in /proc/interrupts (the devices claiming
> that IRQ are quiescent).
> 
> Without 'noapic' that must be triggering something else to go haywire,
> perhaps the AER logic (though that is all MSI, so probably not).  I'm
> flying blind on those boots.
> 
> I bet that, if I can recall how to re-enable IRQ5, I'll see it
> continuously asserting.  Chipset or BIOS bug maybe.  I don't know if I
> had AER enabled under Lucid, so that might be the difference.
> 
> I'll try a vanilla kernel next, maybe hack on AER a bit, to see if I
> can make it progress.

I wonder what happens if you simply disable AER for starters?

There is the pci=noaer kernel command line switch for that.

Thanks,
Rafael


> On Sat, Dec 29, 2012 at 10:19 PM, Tim Hockin  wrote:
> > Quick update: booting with 'noapic' on the commandline seems to make
> > it resume successfully.
> >
> > The main dmesg diffs, other than the obvious "Skipping IOAPIC probe"
> > and IRG number diffs) are:
> >
> > -nr_irqs_gsi: 40
> > +nr_irqs_gsi: 16
> >
> > -NR_IRQS:16640 nr_irqs:776 16
> > +NR_IRQS:16640 nr_irqs:368 16
> >
> > -system 00:0a: [mem 0xfec0-0xfec00fff] could not be reserved
> > +system 00:0a: [mem 0xfec0-0xfec00fff] has been reserved
> >
> > and a new warning about irq 5: nobody cared (try booting with the
> > "irqpoll" option)
> >
> > I'll see if I can sort out further differences, but I thought it was
> > worth sending this new info along, anyway.
> >
> > It did not require 'noapic' on the Lucid (2.6.32?) kernel
> >
> >
> > On Sat, Dec 29, 2012 at 9:34 PM, Tim Hockin  wrote:
> >> Running a suspend with pm_trace set, I get:
> >>
> >> aer :00:03.0:pcie02: hash matches
> >>
> >> I don't know what magic might be needed here, though.
> >>
> >> I guess next step is to try to build a non-distro kernel.
> >>
> >> On Sat, Dec 29, 2012 at 1:57 PM, Rafael J. Wysocki  wrote:
> >>> On Saturday, December 29, 2012 12:03:13 PM Tim Hockin wrote:
>  4 days ago I had Ubuntu Lucid running on this computer. Suspend and
>  resume worked flawlessly every time.
> 
>  Then I upgraded to Ubuntu Precise.
> >>>
> >>> Well, do you use a distro kernel or a kernel.org kernel?
> >>>
>  Suspend seems to work, but resume
>  fails every time. The video never initializes.  By the flashing
>  keyboard lights, I guess it's a kernel panic. It fails from the Live
>  CD and from a fresh install.
> 
>  Here is my debug so far.
> 
>  Install all updates (3.2 kernel, nouveau driver)
>  Reboot
>  Try suspend = fails
> 
>  Install Ubuntu's linux-generic-lts-quantal (3.5 kernel, nouveau driver)
>  Reboot
>  Try suspend = fails
> 
>  Install nVidia's 304 driver
>  Reboot
>  Try suspend = fails
> 
>  From within X:
>    echo core > /sys/power/pm_test
>    echo mem > /sys/power/state
>  The system acts like it is going to sleep, and then wakes up a few
>  seconds later. dmesg shows:
> 
>  [ 1230.083404] [ cut here ]
>  [ 1230.083410] WARNING: at
>  /build/buildd/linux-lts-quantal-3.5.0/kernel/power/suspend_test.c:53
>  suspend_test_finish+0x86/0x90()
>  [ 1230.083411] Hardware name: To Be Filled By O.E.M.
>  [ 1230.083412] Component: resume devices, time: 14424
>  [ 1230.083412] Modules linked in: snd_emu10k1_synth snd_emux_synth
>  snd_seq_virmidi snd_seq_midi_emul bnep rfcomm parport_pc ppdev
>  nvidia(PO) snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm snd_page_alloc
>  snd_util_mem snd_hwdep snd_seq_midi snd_rawmidi snd_seq_midi_event
>  snd_seq snd_timer coretemp snd_seq_device kvm_intel kvm snd
>  ghash_clmulni_intel soundcore aesni_intel btusb cryptd aes_x86_64
>  bluetooth i7core_edac edac_core microcode mac_hid lpc_ich mxm_wmi
>  shpchp serio_raw wmi hid_generic lp parport usbhid hid r8169
>  pata_marvell
>  [ 1230.083445] Pid: 3329, comm: bash Tainted: P O 3.5.0-21-generic
>  #32~precise1-Ubuntu
>  [ 1230.083446] Call Trace:
>  [ 1230.083448] [] warn_slowpath_common+0x7f/0xc0
>  [ 1230.083452] [] warn_slowpath_fmt+0x46/0x50
>  [ 1230.083455] [] suspend_test_finish+0x86/0x90
>  [ 1230.083457] [] suspend_devices_and_enter+0x10b/0x200
>  [ 1230.083460] [] enter_state+0xd1/0x100
>  [ 1230.083463] [] pm_suspend+0x1b/0x60
>  [ 1230.083465] [] state_store+0x45/0x70
>  [ 1230.083467] [] kobj_attr_store+0xf/0x30
>  [ 1230.083471] [] sysfs_write_file+0xef/0x170
>  [ 1230.083476] [] vfs_write+0xb3/0x180
>  [ 1230.083480] [] sys_write+0x4a/0x90
>  [ 1230.083483] [] system_call_fastpath+0x16/0x1b
>  [ 1230.083488] ---[ end trace 839cdd0078b3ce03 ]---
> 
>  Boot with init=/bin/bash
>  unload all modules except USBHID
>  echo core > 

[RFC PATCH] input: i8042: Add support for devicetree to i8042 serio driver

[Tony Prisk]

This patch adds basic devicetree support for the i8042 controller
driver.

Simple properties to specify the register offsets.
Optional properties to specify the linux device descriptions.

Signed-off-by: Tony Prisk 
---
 .../devicetree/bindings/input/intel-8042.txt   |   29 +
 drivers/input/serio/Kconfig|   10 +-
 drivers/input/serio/i8042-dt.h |  127 
 drivers/input/serio/i8042.c|   15 ++-
 drivers/input/serio/i8042.h|4 +-
 5 files changed, 181 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/intel-8042.txt
 create mode 100644 drivers/input/serio/i8042-dt.h

diff --git a/Documentation/devicetree/bindings/input/intel-8042.txt 
b/Documentation/devicetree/bindings/input/intel-8042.txt
new file mode 100644
index 000..68f6fa2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/intel-8042.txt
@@ -0,0 +1,29 @@
+* Intel 8042 Keyboard controller
+
+Required properties:
+- compatible: should be "intel,8042"
+- regs: memory for keyboard controller
+- interrupts: two interrupts should be specified (keyboard and aux).
+- command-reg: offset in memory for command register
+- status-reg: offset in memory for status register
+- data-reg: offset in memory for data register
+
+Optional properties:
+- init-reset: Controller should be reset on init and cleanup
+
+Optional linux specific properties:
+- linux,kbd_phys_desc: defaults to i8042/serio0
+- linux,aux_phys_desc: defaults to i8042/serio1
+- linux,mux_phys_desc: defaults to i8042/serio%d
+
+
+Example:
+   keyboard@d8008800 {
+   compatible = "intel,8042";
+   reg = <0xD8008800 0x100>;
+   interrupts = <23 4>;
+   command-reg = <0x04>;
+   status-reg = <0x04>;
+   data-reg = <0x00>;
+   mux-ports = <2>;
+   };
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index 4a4e182..26e97a3 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -21,8 +21,9 @@ if SERIO
 config SERIO_I8042
tristate "i8042 PC Keyboard controller" if EXPERT || !X86
default y
-   depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && \
-  (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN
+   depends on (!PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && \
+  (!SUPERH || SH_CAYMAN) && !M68K && !BLACKFIN) || \
+  (SERIO_I8042_DT)
help
  i8042 is the chip over which the standard AT keyboard and PS/2
  mouse are connected to the computer. If you use these devices,
@@ -33,6 +34,11 @@ config SERIO_I8042
  To compile this driver as a module, choose M here: the
  module will be called i8042.
 
+config SERIO_I8042_DT
+   tristate "i8042 Keyboard controller DT support" if EXPERT || !X86
+   depends on USE_OF
+   select SERIO_I8042
+
 config SERIO_SERPORT
tristate "Serial port line discipline"
default y
diff --git a/drivers/input/serio/i8042-dt.h b/drivers/input/serio/i8042-dt.h
new file mode 100644
index 000..3875c90
--- /dev/null
+++ b/drivers/input/serio/i8042-dt.h
@@ -0,0 +1,127 @@
+#ifndef _I8042_DT_H
+#define _I8042_DT_H
+
+#include 
+#include 
+#include 
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+static void __iomem *dt_base;
+static const char *dt_kbd_phys_desc;
+static const char *dt_aux_phys_desc;
+static const char *dt_mux_phys_desc;
+static int dt_kbd_irq;
+static int dt_aux_irq;
+static unsigned int dt_command_reg;
+static unsigned int dt_status_reg;
+static unsigned int dt_data_reg;
+
+#define I8042_KBD_PHYS_DESCdt_kbd_phys_desc
+#define I8042_AUX_PHYS_DESCdt_aux_phys_desc
+#define I8042_MUX_PHYS_DESCdt_mux_phys_desc
+
+#define I8042_KBD_IRQ  (dt_kbd_irq)
+#define I8042_AUX_IRQ  (dt_aux_irq)
+
+#define I8042_COMMAND_REG  (dt_command_reg)
+#define I8042_STATUS_REG   (dt_status_reg)
+#define I8042_DATA_REG (dt_data_reg)
+
+
+static inline int i8042_read_data(void)
+{
+   return readb(dt_base + dt_data_reg);
+}
+
+static inline int i8042_read_status(void)
+{
+   return readb(dt_base + dt_status_reg);
+}
+
+static inline void i8042_write_data(int val)
+{
+   writeb(val, dt_base + dt_data_reg);
+}
+
+static inline void i8042_write_command(int val)
+{
+   writeb(val, dt_base + dt_command_reg);
+}
+
+static inline int dt_parse_node(struct device_node *np)
+{
+   int ret;
+
+   dt_base = of_iomap(np, 0);
+   if (!dt_base)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "command-reg", _command_reg);
+   if (ret) {
+   pr_err("i8042-dt: command-reg missing or invalid\n");
+ 

[RFC PATCH] Add support for devicetree to i8042 serio driver

[Tony Prisk]

Since this patch may adversely affect a lot of users, I thought I'd post this
as an RFC first. I don't think the changes should affect any existing i8042
implementations, but can never be certain.

Limitations:

This patch does not overcome the problem of only being able to select
a single i8042 platform at compile-time. If compiling for a multiplatform
kernel, all platforms must use the DT version or only one platform
can have i8042 support.

The DT version assumes memory-mapped i8042 registers. It can not handle
IO-mapped modules (eg. x86)

Tony Prisk (1):
  input: i8042: Add support for devicetree to i8042 serio driver

 .../devicetree/bindings/input/intel-8042.txt   |   29 +
 drivers/input/serio/Kconfig|   10 +-
 drivers/input/serio/i8042-dt.h |  127 
 drivers/input/serio/i8042.c|   15 ++-
 drivers/input/serio/i8042.h|4 +-
 5 files changed, 181 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/intel-8042.txt
 create mode 100644 drivers/input/serio/i8042-dt.h

-- 
1.7.9.5

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

[PATCH] rtc: pl031: add wake-up support

[Rob Herring]

From: Rob Herring 

Mark the pl031 as wake-up capable so that rtcwake and suspend test can work.

Signed-off-by: Rob Herring 
Cc: Srinidhi Kasagar 
Cc: Linus Walleij 
Cc: Alessandro Zummo 
Cc: linux-arm-ker...@lists.infradead.org
Cc: rtc-li...@googlegroups.com
Cc: linux-kernel@vger.kernel.org
---
 drivers/rtc/rtc-pl031.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 08378e3..9e20958 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/rtc/rtc-pl031.c
@@ -380,6 +380,8 @@ static int pl031_probe(struct amba_device *adev, const 
struct amba_id *id)
goto out_no_irq;
}
 
+   device_init_wakeup(>dev, 1);
+
return 0;
 
 out_no_irq:
-- 
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] prctl: fix validation of an address

[Eric Paris]

On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote:
> The address should be bigger than dac_mmap_min_addr, because
> a process with CAP_RAWIO can map a vma bellow mmap_min_addr.

NAK

This doesn't make any sense.  dac_mmap_min_addr should ONLY be used in
security/min_addr.c and security/commoncap.c.  Period.  You should not
be allowed to circumvent LSM protections.  Maybe you are missing that
mmap_min_addr = max(dac_mmap_min_addr, CONFIG_LSM_MMAP_MIN_ADDR)  ?

But this patch is absolutely unacceptable.  Maybe you can help me
understand what problem you had and what you were hoping for?

-Eric
> 
> Cc: Andrew Morton 
> Cc: Kees Cook 
> Cc: Cyrill Gorcunov 
> Cc: Serge Hallyn 
> Cc: "Eric W. Biederman" 
> Cc: Eric Paris 
> Cc: James Morris 
> Signed-off-by: Andrey Vagin 
> ---
>  kernel/sys.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 265b376..e0e1bbd 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -1868,7 +1868,7 @@ static int prctl_set_mm(int opt, unsigned long addr,
>   if (opt == PR_SET_MM_EXE_FILE)
>   return prctl_set_mm_exe_file(mm, (unsigned int)addr);
>  
> - if (addr >= TASK_SIZE || addr < mmap_min_addr)
> + if (addr >= TASK_SIZE || addr < dac_mmap_min_addr)
>   return -EINVAL;
>  
>   error = -EINVAL;


--
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: vt8500: Add power button keypad driver

[Tony Prisk]

This patch adds support for the Power Button keypad found on
Wondermedia netbooks/tablets.

A keymap property is exposed to allowing defining the key
event to be generated when the power button is pressed.

Signed-off-by: Tony Prisk 
---
 .../bindings/input/vt8500-power-keypad.txt |   17 ++
 drivers/input/keyboard/Kconfig |   10 ++
 drivers/input/keyboard/Makefile|1 +
 drivers/input/keyboard/wmt_power_keypad.c  |  174 
 4 files changed, 202 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
 create mode 100644 drivers/input/keyboard/wmt_power_keypad.c

diff --git a/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt 
b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
new file mode 100644
index 000..bae6228
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/vt8500-power-keypad.txt
@@ -0,0 +1,17 @@
+* Wondermedia Power Keypad device tree bindings
+
+Wondermedia SoCs have a single irq-driven power button attached to
+the power management controller.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+   - "wm,power-keypad": For all Wondermedia 8xxx-series SoCs.
+- interrupts: should be the power management controller wakeup interrupt.
+- keymap: linux keycode to generate when power button pressed.
+
+Example:
+   powerkey: pwrkey@0 {
+   compatible = "wm,power-keypad";
+   interrupts = <22>;
+   keymap = <116>; /* KEY_POWER */
+   };
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 5a240c6..c270f27 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -595,6 +595,16 @@ config KEYBOARD_TWL4030
  To compile this driver as a module, choose M here: the
  module will be called twl4030_keypad.
 
+config KEYBOARD_WMT_POWER_KEYPAD
+   tristate "Wondermedia Power keypad support"
+   depends on ARCH_VT8500
+   help
+ Say Y here to enable support for the power button keypad
+ on Wondermedia 8xxx-series SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called wmt_power_keypad.
+
 config KEYBOARD_XTKBD
tristate "XT keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..eea31af 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)+= 
tc3589x-keypad.o
 obj-$(CONFIG_KEYBOARD_TEGRA)   += tegra-kbc.o
 obj-$(CONFIG_KEYBOARD_TNETV107X)   += tnetv107x-keypad.o
 obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
+obj-$(CONFIG_KEYBOARD_WMT_POWER_KEYPAD)+= wmt_power_keypad.o
 obj-$(CONFIG_KEYBOARD_XTKBD)   += xtkbd.o
 obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/wmt_power_keypad.c 
b/drivers/input/keyboard/wmt_power_keypad.c
new file mode 100644
index 000..ce8aa9a
--- /dev/null
+++ b/drivers/input/keyboard/wmt_power_keypad.c
@@ -0,0 +1,174 @@
+/* Wondermedia Power Keypad
+ *
+ * Copyright (C) 2012 Tony Prisk 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void __iomem *pmc_base;
+static struct input_dev *kpad_power;
+static spinlock_t kpad_power_lock;
+static int power_button_pressed;
+static struct timer_list kpad_power_timer;
+static unsigned int kpad_power_code;
+
+static inline void kpad_power_timeout(unsigned long fcontext)
+{
+   u32 status;
+   unsigned long flags;
+
+   spin_lock_irqsave(_power_lock, flags);
+
+   status = readl(pmc_base + 0x14);
+
+   if (power_button_pressed) {
+   input_report_key(kpad_power, kpad_power_code, 0);
+   input_sync(kpad_power);
+   power_button_pressed = 0;
+   }
+
+   spin_unlock_irqrestore(_power_lock, flags);
+}
+
+static irqreturn_t kpad_power_isr(int irq_num, void *data)
+{
+   u32 status;
+   unsigned long flags;
+
+   spin_lock_irqsave(_power_lock, flags);
+
+   status = readl(pmc_base + 0x14);
+   udelay(100);
+   writel(status, pmc_base + 0x14);
+
+   if (status & BIT(14)) {
+   if (!power_button_pressed) {
+   input_report_key(kpad_power, kpad_power_code, 1);

[PATCH] relay: use sizeof(size_t), not sizeof(size_t *) in relay_create_buf()

[Jesper Juhl]

A number of size_t's is what we want to allocate memory for, not a
number of size_t pointers (at least as far as I can tell).
Now, depending on platform, sizeof(size_t *) may be >= sizeof(size_t)
so things actually work, but that's not really a portable assumption,
so let's use the value we actually mean.

Signed-off-by: Jesper Juhl 
---
 kernel/relay.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/relay.c b/kernel/relay.c
index e8cd202..806931b 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -166,13 +166,13 @@ static struct rchan_buf *relay_create_buf(struct rchan 
*chan)
 {
struct rchan_buf *buf;
 
-   if (chan->n_subbufs > UINT_MAX / sizeof(size_t *))
+   if (chan->n_subbufs > UINT_MAX / sizeof(size_t))
return NULL;
 
buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);
if (!buf)
return NULL;
-   buf->padding = kmalloc(chan->n_subbufs * sizeof(size_t *), GFP_KERNEL);
+   buf->padding = kmalloc(chan->n_subbufs * sizeof(size_t), GFP_KERNEL);
if (!buf->padding)
goto free_buf;
 
-- 
1.7.1


-- 
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
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 v2] mtd: vt8500: Add support for Wondermedia Serial Flash Controller

[Tony Prisk]

This patch adds support for the Wondermedia serial flash controller
found on WM8505, WM8650 and WM8850 SoCs.

Signed-off-by: Tony Prisk 
---
v2: Whitespace tidyup

 drivers/mtd/devices/Kconfig  |7 +
 drivers/mtd/devices/Makefile |3 +-
 drivers/mtd/devices/wmt_sflash.c |  614 ++
 3 files changed, 623 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/devices/wmt_sflash.c

diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 27f80cd..6c4bbd4 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -128,6 +128,13 @@ config MTD_BCM47XXSFLASH
  registered by bcma as platform devices. This enables driver for
  serial flash memories (only read-only mode is implemented).
 
+config MTD_WMT_SFLASH
+   tristate "WonderMedia Serial Flash Support"
+   depends on MTD
+   help
+ Enable this option to provide support for the Wondermedia SoC serial
+ flash controller.
+
 config MTD_SLRAM
tristate "Uncached system RAM"
help
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index 395733a..10b8bec 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_MTD_DATAFLASH)   += mtd_dataflash.o
 obj-$(CONFIG_MTD_M25P80)   += m25p80.o
 obj-$(CONFIG_MTD_SPEAR_SMI)+= spear_smi.o
 obj-$(CONFIG_MTD_SST25L)   += sst25l.o
+obj-$(CONFIG_MTD_WMT_SFLASH)   += wmt_sflash.o
 obj-$(CONFIG_MTD_BCM47XXSFLASH)+= bcm47xxsflash.o
 
-CFLAGS_docg3.o += -I$(src)
\ No newline at end of file
+CFLAGS_docg3.o += -I$(src)
diff --git a/drivers/mtd/devices/wmt_sflash.c b/drivers/mtd/devices/wmt_sflash.c
new file mode 100644
index 000..49359ea
--- /dev/null
+++ b/drivers/mtd/devices/wmt_sflash.c
@@ -0,0 +1,614 @@
+/*
+ * Copyright (C) 2012 Tony Prisk 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+/* controller only supports erase size of 64KB */
+#define WMT_ERASESIZE  0x1
+
+/* Serial Flash controller register offsets */
+#define SF_CHIP_SEL_0_CFG  0x000
+#define SF_CHIP_SEL_1_CFG  0x008
+#define SF_SPI_INTF_CFG0x040
+#define SF_SPI_RD_WR_CTR   0x050
+#define SF_SPI_WR_EN_CTR   0x060
+#define SF_SPI_ER_CTR  0x070
+#define SF_SPI_ER_START_ADDR   0x074
+#define SF_SPI_ERROR_STATUS0x080
+#define SF_SPI_MEM_0_SR_ACC0x100
+#define SF_SPI_MEM_1_SR_ACC0x110
+#define SF_SPI_PDWN_CTR_0  0x180
+#define SF_SPI_PDWN_CTR_1  0x190
+#define SF_SPI_PROG_CMD_CTR0x200
+#define SF_SPI_USER_CMD_VAL0x210
+#define SF_SPI_PROG_CMD_WBF0x300   /* 64 bytes */
+#define SF_SPI_PROG_CMD_RBF0x380   /* 64 bytes */
+
+/* SF_SPI_WR_EN_CTR bit fields */
+#define SF_CS0_WR_EN   BIT(0)
+#define SF_CS1_WR_EN   BIT(1)
+
+/* SF_SPI_ER_CTR bit fields */
+#define SF_SEC_ER_EN   BIT(31)
+
+/* SF_SPI_ERROR_STATUS bit fields */
+#define SF_ERR_TIMEOUT BIT(31)
+#define SF_ERR_WR_PROT_ERR BIT(5)
+#define SF_ERR_MEM_REGION_ERR  BIT(4)
+#define SF_ERR_PWR_DWN_ACC_ERR BIT(3)
+#define SF_ERR_PCMD_OP_ERR BIT(2)
+#define SF_ERR_PCMD_ACC_ERRBIT(1)
+#define SF_ERR_MASLOCK_ERR BIT(0)
+
+/*
+ * Serial Flash device manufacturers
+ * Please keep sorted by manufacturers ID
+ */
+#define MFR_SPANSION   0x01
+#define MFR_EON0x1C
+#define MFR_ATMEL  0x1F
+#define MFR_NUMONYX0x20
+#define MFR_FUDAN  0xA1
+#define MFR_SST0xBF
+#define MFR_MXIC   0xC2
+#define MFR_WINBOND0xEF
+
+/*
+ * SF Device Models
+ * Please keep in the same order as the manufacturers table
+ */
+
+/* Spansion */
+#define SPAN_FL016A0x0214 /* 2 MB */
+#define SPAN_FL064A0x0216 /* 8 MB */
+
+/* Eon */
+#define EON_25P16  0x2015 /* 2 MB */
+#define EON_25P64  0x2017 /* 8 MB */
+#define EON_25F40  0x3113 /* 512 KB */
+#define EON_25F16  0x3115 /* 2 MB */
+
+/* Atmel */
+#define AT_25DF041A0x4401 /* 512KB */
+
+/* Numonyx */
+#defineNX_25P160x2015 /* 2 MB */
+#define 

[PATCH] mtd: vt8500: Add support for Wondermedia Serial Flash Controller

[Tony Prisk]

This patch adds support for the Wondermedia serial flash controller
found on WM8505, WM8650 and WM8850 SoCs.

Signed-off-by: Tony Prisk 
---
 drivers/mtd/devices/Kconfig  |7 +
 drivers/mtd/devices/Makefile |3 +-
 drivers/mtd/devices/wmt_sflash.c |  614 ++
 3 files changed, 623 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/devices/wmt_sflash.c

diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index 27f80cd..6c4bbd4 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -128,6 +128,13 @@ config MTD_BCM47XXSFLASH
  registered by bcma as platform devices. This enables driver for
  serial flash memories (only read-only mode is implemented).
 
+config MTD_WMT_SFLASH
+   tristate "WonderMedia Serial Flash Support"
+   depends on MTD
+   help
+ Enable this option to provide support for the Wondermedia SoC serial
+ flash controller.
+
 config MTD_SLRAM
tristate "Uncached system RAM"
help
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index 395733a..10b8bec 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_MTD_DATAFLASH)   += mtd_dataflash.o
 obj-$(CONFIG_MTD_M25P80)   += m25p80.o
 obj-$(CONFIG_MTD_SPEAR_SMI)+= spear_smi.o
 obj-$(CONFIG_MTD_SST25L)   += sst25l.o
+obj-$(CONFIG_MTD_WMT_SFLASH)   += wmt_sflash.o
 obj-$(CONFIG_MTD_BCM47XXSFLASH)+= bcm47xxsflash.o
 
-CFLAGS_docg3.o += -I$(src)
\ No newline at end of file
+CFLAGS_docg3.o += -I$(src)
diff --git a/drivers/mtd/devices/wmt_sflash.c b/drivers/mtd/devices/wmt_sflash.c
new file mode 100644
index 000..f6b5a15
--- /dev/null
+++ b/drivers/mtd/devices/wmt_sflash.c
@@ -0,0 +1,614 @@
+/*
+ * Copyright (C) 2012 Tony Prisk 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+/* controller only supports erase size of 64KB */
+#define WMT_ERASESIZE  0x1
+
+/* Serial Flash controller register offsets */
+#define SF_CHIP_SEL_0_CFG  0x000
+#define SF_CHIP_SEL_1_CFG  0x008
+#define SF_SPI_INTF_CFG0x040
+#define SF_SPI_RD_WR_CTR   0x050
+#define SF_SPI_WR_EN_CTR   0x060
+#define SF_SPI_ER_CTR  0x070
+#define SF_SPI_ER_START_ADDR   0x074
+#define SF_SPI_ERROR_STATUS0x080
+#define SF_SPI_MEM_0_SR_ACC0x100
+#define SF_SPI_MEM_1_SR_ACC0x110
+#define SF_SPI_PDWN_CTR_0  0x180
+#define SF_SPI_PDWN_CTR_1  0x190
+#define SF_SPI_PROG_CMD_CTR0x200
+#define SF_SPI_USER_CMD_VAL0x210
+#define SF_SPI_PROG_CMD_WBF0x300   /* 64 bytes */
+#define SF_SPI_PROG_CMD_RBF0x380   /* 64 bytes */
+
+/* SF_SPI_WR_EN_CTR bit fields */
+#define SF_CS0_WR_EN   BIT(0)
+#define SF_CS1_WR_EN   BIT(1)
+
+/* SF_SPI_ER_CTR bit fields */
+#define SF_SEC_ER_EN   BIT(31)
+
+/* SF_SPI_ERROR_STATUS bit fields */
+#define SF_ERR_TIMEOUT BIT(31)
+#define SF_ERR_WR_PROT_ERR BIT(5)
+#define SF_ERR_MEM_REGION_ERR  BIT(4)
+#define SF_ERR_PWR_DWN_ACC_ERR BIT(3)
+#define SF_ERR_PCMD_OP_ERR BIT(2)
+#define SF_ERR_PCMD_ACC_ERRBIT(1)
+#define SF_ERR_MASLOCK_ERR BIT(0)
+
+/*
+ * Serial Flash device manufacturers
+ * Please keep sorted by manufacturers ID
+ */
+#define MFR_SPANSION   0x01
+#define MFR_EON0x1C
+#define MFR_ATMEL  0x1F
+#define MFR_NUMONYX0x20
+#define MFR_FUDAN  0xA1
+#define MFR_SST0xBF
+#define MFR_MXIC   0xC2
+#define MFR_WINBOND0xEF
+
+/*
+ * SF Device Models
+ * Please keep in the same order as the manufacturers table
+ */
+
+/* Spansion */
+#define SPAN_FL016A0x0214 /* 2 MB */
+#define SPAN_FL064A0x0216 /* 8 MB */
+
+/* Eon */
+#define EON_25P16  0x2015 /* 2 MB */
+#define EON_25P64  0x2017 /* 8 MB */
+#define EON_25F40  0x3113 /* 512 KB */
+#define EON_25F16  0x3115 /* 2 MB */
+
+/* Atmel */
+#define AT_25DF041A0x4401 /* 512KB */
+
+/* Numonyx */
+#defineNX_25P160x2015 /* 2 MB */
+#defineNX_25P64

Re: i915: GPU hang

[Guennadi Liakhovetski]

Hi Daniel

Sorry for a late reply.

On Tue, 18 Dec 2012, Daniel Vetter wrote:

> On Mon, Dec 17, 2012 at 11:36 PM, Guennadi Liakhovetski
>  wrote:
> > Sorry, not sure what information is most appropriate here. GPU hangs from
> > time to time on this laptop, typically when running firefox on
> > graphics-intensive sites. Error log at the bottom. Distro is Debian 6.0.6
> > (squeeze), lspci
> >
> > 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> > Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
> > Subsystem: Acer Incorporated [ALI] Device 011f
> > Flags: bus master, fast devsel, latency 0, IRQ 46
> > Memory at fc00 (64-bit, non-prefetchable) [size=1M]
> > Memory at d000 (64-bit, prefetchable) [size=256M]
> > I/O ports at 1800 [size=8]
> > Expansion ROM at  [disabled]
> > Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > Capabilities: [d0] Power Management version 3
> > Kernel driver in use: i915
> >
> > kernel version 3.5.2 (yes, I'll try to upgrade). Sometimes also the
> > X-server freezes and restarts with no errors in dmesg. Is it a known
> > problem?
> 
> Upgrading to 3.7 highly recommended, if just to get the recent pile of
> gpu reset fixes - those should increase the chances that the reset
> works and your system survives.

Did that and it did work for a while, longer than the average with 3.5. I 
was already about to write a success report, but then it hung again 
yesterday. I'm not using this laptop very intensively, so, it is hard to 
collect statistics.

> Also worth testing is upgrading
> userspace gfx driver components to the latest versions (mesa +
> xf86-video-intel).

Not sure I'll be bothered - recompiling user-space is too much of a hastle 
;-) Maybe I'll just upgrade my distro altogether. Thanks for the tips 
anyway!

> If you still have gpu hangs with all that, please
> file a bug report against DRM -> DRI/Intel and please attach the
> i915_error_state from debugfs after your gpu hung).
> 
> Yours, Daniel

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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] gpio: vt8500: Export dedicated GPIO before multifunction pins.

[Tony Prisk]

The vendor does not provide numbering for gpio pins. Vendor source
exports dedicated gpio pins first, followed by multifunction pins.
As this is what end users expect, this patch changes vt8500 and wm8505
to do the same.

Signed-off-by: Tony Prisk 
---
 drivers/gpio/gpio-vt8500.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
index b53320a..9a7c434 100644
--- a/drivers/gpio/gpio-vt8500.c
+++ b/drivers/gpio/gpio-vt8500.c
@@ -73,19 +73,20 @@ struct vt8500_gpio_data {
 static struct vt8500_gpio_data vt8500_data = {
.num_banks  = 7,
.banks  = {
+   VT8500_BANK(NO_REG, 0x3C, 0x5C, 0x7C, 9),
VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
-   VT8500_BANK(NO_REG, 0x3C, 0x5C, 0x7C, 9),
},
 };
 
 static struct vt8500_gpio_data wm8505_data = {
.num_banks  = 10,
.banks  = {
+   VT8500_BANK(0x64, 0x8C, 0xB4, 0xDC, 22),
VT8500_BANK(0x40, 0x68, 0x90, 0xB8, 8),
VT8500_BANK(0x44, 0x6C, 0x94, 0xBC, 32),
VT8500_BANK(0x48, 0x70, 0x98, 0xC0, 6),
@@ -95,7 +96,6 @@ static struct vt8500_gpio_data wm8505_data = {
VT8500_BANK(0x58, 0x80, 0xA8, 0xD0, 5),
VT8500_BANK(0x5C, 0x84, 0xAC, 0xD4, 12),
VT8500_BANK(0x60, 0x88, 0xB0, 0xD8, 16),
-   VT8500_BANK(0x64, 0x8C, 0xB4, 0xDC, 22),
VT8500_BANK(0x500, 0x504, 0x508, 0x50C, 6),
},
 };
-- 
1.7.9.5

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

[PATCH 1/2] pwm: vt8500: Register write busy test performed incorrectly

[Tony Prisk]

Correct operation for register writes is to perform a busy-wait
after writing the register. Currently the busy wait it performed
before, meaning subsequent register writes to bitfields may occur
before the previous field has been updated.

Also, all registers are defined as 32-bit read/write. Change
pwm_busy_wait() to use readl rather than readb.

Improve readability of code with defines for registers and bitfields.

Signed-off-by: Tony Prisk 
---
Thierry,

This patch is a fix but it can go to 3.9 rather than 3.8 (if you prefer)
as the incorrect behaviour doesn't seem to cause a problem on current
hardware.

 drivers/pwm/pwm-vt8500.c |   62 +++---
 1 file changed, 48 insertions(+), 14 deletions(-)

diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index b0ba2d4..27ed0f4 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -36,6 +36,25 @@
  */
 #define VT8500_NR_PWMS 2
 
+#define REG_CTRL(pwm)  (pwm << 4) + 0x00
+#define REG_SCALAR(pwm)(pwm << 4) + 0x04
+#define REG_PERIOD(pwm)(pwm << 4) + 0x08
+#define REG_DUTY(pwm)  (pwm << 4) + 0x0C
+#define REG_STATUS 0x40
+
+#define CTRL_ENABLEBIT(0)
+#define CTRL_INVERTBIT(1)
+#define CTRL_AUTOLOAD  BIT(2)
+#define CTRL_STOP_IMM  BIT(3)
+#define CTRL_LOAD_PRESCALE BIT(4)
+#define CTRL_LOAD_PERIOD   BIT(5)
+
+#define STATUS_CTRL_UPDATE BIT(0)
+#define STATUS_SCALAR_UPDATE   BIT(1)
+#define STATUS_PERIOD_UPDATE   BIT(2)
+#define STATUS_DUTY_UPDATE BIT(3)
+#define STATUS_ALL_UPDATE  0x0F
+
 struct vt8500_chip {
struct pwm_chip chip;
void __iomem *base;
@@ -45,15 +64,17 @@ struct vt8500_chip {
 #define to_vt8500_chip(chip)   container_of(chip, struct vt8500_chip, chip)
 
 #define msecs_to_loops(t) (loops_per_jiffy / 1000 * HZ * t)
-static inline void pwm_busy_wait(void __iomem *reg, u8 bitmask)
+static inline void pwm_busy_wait(struct vt8500_chip *vt8500, int nr, u8 
bitmask)
 {
int loops = msecs_to_loops(10);
-   while ((readb(reg) & bitmask) && --loops)
+   u32 mask = bitmask << (nr << 8);
+
+   while ((readl(vt8500->base + REG_STATUS) & mask) && --loops)
cpu_relax();
 
if (unlikely(!loops))
pr_warn("Waiting for status bits 0x%x to clear timed out\n",
-  bitmask);
+  mask);
 }
 
 static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -63,6 +84,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, prescale, pv, dc;
int err;
+   u32 val;
 
err = clk_enable(vt8500->clk);
if (err < 0) {
@@ -91,14 +113,19 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
do_div(c, period_ns);
dc = c;
 
-   pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 1));
-   writel(prescale, vt8500->base + 0x4 + (pwm->hwpwm << 4));
+   writel(prescale, vt8500->base + REG_SCALAR(pwm->hwpwm));
+   pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_SCALAR_UPDATE);
+
+   writel(pv, vt8500->base + REG_PERIOD(pwm->hwpwm));
+   pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_PERIOD_UPDATE);
 
-   pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 2));
-   writel(pv, vt8500->base + 0x8 + (pwm->hwpwm << 4));
+   writel(dc, vt8500->base + REG_DUTY(pwm->hwpwm));
+   pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_DUTY_UPDATE);
 
-   pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 3));
-   writel(dc, vt8500->base + 0xc + (pwm->hwpwm << 4));
+   val = readl(vt8500->base + REG_CTRL(pwm->hwpwm));
+   val |= CTRL_AUTOLOAD;
+   writel(val, vt8500->base + REG_CTRL(pwm->hwpwm));
+   pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_CTRL_UPDATE);
 
clk_disable(vt8500->clk);
return 0;
@@ -106,8 +133,9 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
 
 static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
-   int err;
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+   int err;
+   u32 val;
 
err = clk_enable(vt8500->clk);
if (err < 0) {
@@ -115,17 +143,23 @@ static int vt8500_pwm_enable(struct pwm_chip *chip, 
struct pwm_device *pwm)
return err;
}
 
-   pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
-   writel(5, vt8500->base + (pwm->hwpwm << 4));
+   val = readl(vt8500->base + REG_CTRL(pwm->hwpwm));
+   val |= CTRL_ENABLE;
+   writel(val, vt8500->base + REG_CTRL(pwm->hwpwm));
+   pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_CTRL_UPDATE);
+
return 0;
 }
 
 static void vt8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+   u32 

[PATCH 2/2] pwm: vt8500: Add support for .set_polarity

[Tony Prisk]

Add support to set polarity on pwm devices, allowing for inverted
duty cycles.

Also update the binding document to #pwm-cells = <3> to allow
passing the flags from devicetree.

Signed-off-by: Tony Prisk 
---
 .../devicetree/bindings/pwm/vt8500-pwm.txt |7 ---
 drivers/pwm/pwm-vt8500.c   |   21 
 2 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt 
b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
index bcc6367..f71cc8d 100644
--- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -3,14 +3,15 @@ VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
 Required properties:
 - compatible: should be "via,vt8500-pwm"
 - reg: physical base address and length of the controller's registers
-- #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the period in nanoseconds.
+- #pwm-cells: should be 3.  The first cell specifies the per-chip index
+  of the PWM to use, the second cell is the period in nanoseconds, and the
+  third cell is for flags.
 - clocks: phandle to the PWM source clock
 
 Example:
 
 pwm1: pwm@d822 {
-   #pwm-cells = <2>;
+   #pwm-cells = <3>;
compatible = "via,vt8500-pwm";
reg = <0xd822 0x1000>;
clocks = <>;
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index 27ed0f4..9abf561 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -164,10 +164,31 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
clk_disable(vt8500->clk);
 }
 
+static int vt8500_pwm_set_polarity(struct pwm_chip *chip,
+  struct pwm_device *pwm,
+  enum pwm_polarity polarity)
+{
+   struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+   u32 val;
+
+   val = readl(vt8500->base + REG_CTRL(pwm->hwpwm));
+
+   if (polarity == PWM_POLARITY_INVERSED)
+   val |= CTRL_INVERT;
+   else
+   val &= ~CTRL_INVERT;
+
+   writel(val, vt8500->base + REG_CTRL(pwm->hwpwm));
+   pwm_busy_wait(vt8500, pwm->hwpwm, STATUS_CTRL_UPDATE);
+
+   return 0;
+}
+
 static struct pwm_ops vt8500_pwm_ops = {
.enable = vt8500_pwm_enable,
.disable = vt8500_pwm_disable,
.config = vt8500_pwm_config,
+   .set_polarity = vt8500_pwm_set_polarity,
.owner = THIS_MODULE,
 };
 
-- 
1.7.9.5

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

[PATCH v2 1/3] [regmap] Add provisions to have user-defined read operation

[Andrey Smirnov]

This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register read function.

Signed-off-by: Andrey Smirnov 
---
 drivers/base/regmap/internal.h |2 ++
 drivers/base/regmap/regmap.c   |   35 ++-
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 401d191..471eb90 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -74,6 +74,8 @@ struct regmap {
const struct regmap_access_table *volatile_table;
const struct regmap_access_table *precious_table;
 
+   int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
+
u8 read_flag_mask;
u8 write_flag_mask;
 
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 42d5cb0..ceaefcf 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -34,6 +34,9 @@ static int _regmap_update_bits(struct regmap *map, unsigned 
int reg,
   unsigned int mask, unsigned int val,
   bool *change);
 
+static int _regmap_bus_read(void *context, unsigned int reg,
+   unsigned int *val);
+
 bool regmap_reg_in_ranges(unsigned int reg,
  const struct regmap_range *ranges,
  unsigned int nranges)
@@ -430,6 +433,8 @@ struct regmap *regmap_init(struct device *dev,
map->read_flag_mask = bus->read_flag_mask;
}
 
+   map->reg_read = _regmap_bus_read;
+
reg_endian = config->reg_format_endian;
if (reg_endian == REGMAP_ENDIAN_DEFAULT)
reg_endian = bus->reg_format_endian_default;
@@ -1202,10 +1207,27 @@ static int _regmap_raw_read(struct regmap *map, 
unsigned int reg, void *val,
return ret;
 }
 
+static int _regmap_bus_read(void *context, unsigned int reg,
+   unsigned int *val)
+{
+   int ret;
+   struct regmap *map = context;
+
+   if (!map->format.parse_val)
+   return -EINVAL;
+
+   ret = _regmap_raw_read(map, reg, map->work_buf, map->format.val_bytes);
+   if (ret == 0)
+   *val = map->format.parse_val(map->work_buf);
+
+   return ret;
+}
+
 static int _regmap_read(struct regmap *map, unsigned int reg,
unsigned int *val)
 {
int ret;
+   BUG_ON(!map->reg_read);
 
if (!map->cache_bypass) {
ret = regcache_read(map, reg, val);
@@ -1213,26 +1235,21 @@ static int _regmap_read(struct regmap *map, unsigned 
int reg,
return 0;
}
 
-   if (!map->format.parse_val)
-   return -EINVAL;
-
if (map->cache_only)
return -EBUSY;
 
-   ret = _regmap_raw_read(map, reg, map->work_buf, map->format.val_bytes);
+   ret = map->reg_read(map, reg, val);
if (ret == 0) {
-   *val = map->format.parse_val(map->work_buf);
-
 #ifdef LOG_DEVICE
if (strcmp(dev_name(map->dev), LOG_DEVICE) == 0)
dev_info(map->dev, "%x => %x\n", reg, *val);
 #endif
 
trace_regmap_reg_read(map->dev, reg, *val);
-   }
 
-   if (ret == 0 && !map->cache_bypass)
-   regcache_write(map, reg, *val);
+   if (!map->cache_bypass)
+   regcache_write(map, reg, *val);
+   }
 
return ret;
 }
-- 
1.7.9.5

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

[PATCH v2 3/3] [regmap] Add "no-bus" option for regmap API

[Andrey Smirnov]

This commit adds provision for "no-bus" usage of the regmap API. In
this configuration user can provide API with two callbacks 'reg_read'
and 'reg_write' which are to be called when reads and writes to one of
device's registers is performed. This is useful for devices that
expose registers but whose register access sequence does not fit the 'bus'
abstraction.

Signed-off-by: Andrey Smirnov 
---
 drivers/base/regmap/internal.h |2 ++
 drivers/base/regmap/regmap.c   |   52 ++--
 include/linux/regmap.h |   18 +-
 3 files changed, 59 insertions(+), 13 deletions(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 51f0574..3b1f74b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -77,6 +77,8 @@ struct regmap {
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
 
+   bool cache_registers;
+
u8 read_flag_mask;
u8 write_flag_mask;
 
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 6845a07..4f7fcec 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -379,7 +379,7 @@ struct regmap *regmap_init(struct device *dev,
enum regmap_endian reg_endian, val_endian;
int i, j;
 
-   if (!bus || !config)
+   if (!config)
goto err;
 
map = kzalloc(sizeof(*map), GFP_KERNEL);
@@ -393,7 +393,8 @@ struct regmap *regmap_init(struct device *dev,
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
} else {
-   if (bus->fast_io) {
+   if ((bus && bus->fast_io) ||
+   config->fast_io) {
spin_lock_init(>spinlock);
map->lock = regmap_lock_spinlock;
map->unlock = regmap_unlock_spinlock;
@@ -433,11 +434,19 @@ struct regmap *regmap_init(struct device *dev,
if (config->read_flag_mask || config->write_flag_mask) {
map->read_flag_mask = config->read_flag_mask;
map->write_flag_mask = config->write_flag_mask;
-   } else {
+   } else if (bus) {
map->read_flag_mask = bus->read_flag_mask;
}
 
-   map->reg_read = _regmap_bus_read;
+   if (!bus) {
+   map->reg_read  = config->reg_read;
+   map->reg_write = config->reg_write;
+
+   map->cache_registers = true;
+   goto skip_format_initialization;
+   } else {
+   map->reg_read  = _regmap_bus_read;
+   }
 
reg_endian = config->reg_format_endian;
if (reg_endian == REGMAP_ENDIAN_DEFAULT)
@@ -584,10 +593,14 @@ struct regmap *regmap_init(struct device *dev,
goto err_map;
}
 
-   if (map->format.format_write)
+   if (map->format.format_write) {
+   map->cache_registers = true;
map->reg_write = _regmap_bus_formatted_write;
-   else if (map->format.format_val)
+   } else if (map->format.format_val) {
map->reg_write = _regmap_bus_raw_write;
+   }
+
+skip_format_initialization:
 
map->range_tree = RB_ROOT;
for (i = 0; i < config->num_ranges; i++) {
@@ -790,7 +803,7 @@ void regmap_exit(struct regmap *map)
regcache_exit(map);
regmap_debugfs_exit(map);
regmap_range_exit(map);
-   if (map->bus->free_context)
+   if (map->bus && map->bus->free_context)
map->bus->free_context(map->bus_context);
kfree(map->work_buf);
kfree(map);
@@ -893,6 +906,8 @@ static int _regmap_raw_write(struct regmap *map, unsigned 
int reg,
size_t len;
int i;
 
+   BUG_ON(!map->bus);
+
/* Check for unwritable registers before we start */
if (map->writeable_reg)
for (i = 0; i < val_len / map->format.val_bytes; i++)
@@ -1002,7 +1017,7 @@ static int _regmap_bus_formatted_write(void *context, 
unsigned int reg,
struct regmap_range_node *range;
struct regmap *map = context;
 
-   BUG_ON(!map->format.format_write);
+   BUG_ON(!map->bus || !map->format.format_write);
 
range = _regmap_range_lookup(map, reg);
if (range) {
@@ -1028,7 +1043,7 @@ static int _regmap_bus_raw_write(void *context, unsigned 
int reg,
 {
struct regmap *map = context;
 
-   BUG_ON(!map->format.format_val);
+   BUG_ON(!map->bus || !map->format.format_val);
 
map->format.format_val(map->work_buf + map->format.reg_bytes
   + map->format.pad_bytes, val, 0);
@@ -1043,8 +1058,9 @@ int _regmap_write(struct regmap *map, unsigned int reg,
  unsigned int val)
 {
int ret;
+   void *context = (map->bus) ? map : map->bus_context;
 
-   if (!map->cache_bypass && 

[PATCH v2 2/3] [regmap] Add provisions to have user-defined write operation

[Andrey Smirnov]

This commit is a preparatory commit to provide "no-bus" configuration
option for regmap API. It adds necessary plumbing needed to have the
ability to provide user define register write function.

Signed-off-by: Andrey Smirnov 
---
 drivers/base/regmap/internal.h |1 +
 drivers/base/regmap/regmap.c   |   83 ++--
 2 files changed, 55 insertions(+), 29 deletions(-)

diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 471eb90..51f0574 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -75,6 +75,7 @@ struct regmap {
const struct regmap_access_table *precious_table;
 
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
+   int (*reg_write)(void *context, unsigned int reg, unsigned int val);
 
u8 read_flag_mask;
u8 write_flag_mask;
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index ceaefcf..6845a07 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -36,6 +36,10 @@ static int _regmap_update_bits(struct regmap *map, unsigned 
int reg,
 
 static int _regmap_bus_read(void *context, unsigned int reg,
unsigned int *val);
+static int _regmap_bus_formatted_write(void *context, unsigned int reg,
+  unsigned int val);
+static int _regmap_bus_raw_write(void *context, unsigned int reg,
+unsigned int val);
 
 bool regmap_reg_in_ranges(unsigned int reg,
  const struct regmap_range *ranges,
@@ -580,6 +584,11 @@ struct regmap *regmap_init(struct device *dev,
goto err_map;
}
 
+   if (map->format.format_write)
+   map->reg_write = _regmap_bus_formatted_write;
+   else if (map->format.format_val)
+   map->reg_write = _regmap_bus_raw_write;
+
map->range_tree = RB_ROOT;
for (i = 0; i < config->num_ranges; i++) {
const struct regmap_range_cfg *range_cfg = >ranges[i];
@@ -986,12 +995,54 @@ static int _regmap_raw_write(struct regmap *map, unsigned 
int reg,
return ret;
 }
 
+static int _regmap_bus_formatted_write(void *context, unsigned int reg,
+  unsigned int val)
+{
+   int ret;
+   struct regmap_range_node *range;
+   struct regmap *map = context;
+
+   BUG_ON(!map->format.format_write);
+
+   range = _regmap_range_lookup(map, reg);
+   if (range) {
+   ret = _regmap_select_page(map, , range, 1);
+   if (ret != 0)
+   return ret;
+   }
+
+   map->format.format_write(map, reg, val);
+
+   trace_regmap_hw_write_start(map->dev, reg, 1);
+
+   ret = map->bus->write(map->bus_context, map->work_buf,
+ map->format.buf_size);
+
+   trace_regmap_hw_write_done(map->dev, reg, 1);
+
+   return ret;
+}
+
+static int _regmap_bus_raw_write(void *context, unsigned int reg,
+unsigned int val)
+{
+   struct regmap *map = context;
+
+   BUG_ON(!map->format.format_val);
+
+   map->format.format_val(map->work_buf + map->format.reg_bytes
+  + map->format.pad_bytes, val, 0);
+   return _regmap_raw_write(map, reg,
+map->work_buf +
+map->format.reg_bytes +
+map->format.pad_bytes,
+map->format.val_bytes);
+}
+
 int _regmap_write(struct regmap *map, unsigned int reg,
  unsigned int val)
 {
-   struct regmap_range_node *range;
int ret;
-   BUG_ON(!map->format.format_write && !map->format.format_val);
 
if (!map->cache_bypass && map->format.format_write) {
ret = regcache_write(map, reg, val);
@@ -1010,33 +1061,7 @@ int _regmap_write(struct regmap *map, unsigned int reg,
 
trace_regmap_reg_write(map->dev, reg, val);
 
-   if (map->format.format_write) {
-   range = _regmap_range_lookup(map, reg);
-   if (range) {
-   ret = _regmap_select_page(map, , range, 1);
-   if (ret != 0)
-   return ret;
-   }
-
-   map->format.format_write(map, reg, val);
-
-   trace_regmap_hw_write_start(map->dev, reg, 1);
-
-   ret = map->bus->write(map->bus_context, map->work_buf,
- map->format.buf_size);
-
-   trace_regmap_hw_write_done(map->dev, reg, 1);
-
-   return ret;
-   } else {
-   map->format.format_val(map->work_buf + map->format.reg_bytes
-  + map->format.pad_bytes, val, 0);
-   return _regmap_raw_write(map, reg,
-map->work_buf +
-   

[PATCH v2 0/3] [regmap] Add "no-bus" configuration for regmap API

[Andrey Smirnov]

Second version of the initial patchset(can be found here:
https://lkml.org/lkml/2012/12/21/98)

This version contains following improvements:
 - Provisions to switch between mutexes and spinlocks for locking in
   "no-bus" configuration
 - "reg_read" and "reg_write" have "void *context" as a first argument
   in all the patches
 - Minor improvements in documentation

Andrey Smirnov (3):
  Add provisions to have user-defined read operation
  Add provisions to have user-defined write operation
  Add "no-bus" option for regmap API

 drivers/base/regmap/internal.h |5 ++
 drivers/base/regmap/regmap.c   |  156 +---
 include/linux/regmap.h |   18 -
 3 files changed, 135 insertions(+), 44 deletions(-)

-- 
1.7.9.5

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

[PATCH 1/1] thermal: Check cooling device's current state before declaring it inactive

[Alexander Lam]

It is possible for a cooling device to become active in between calls to
the thermal governor. An example of this is the acerhdf driver, which
can hand control of the cooling device over to the system firmware. Upon
returning control back to the thermal system, the cooling device might
be running again, so checking the current state of the cooling device is
required.

Signed-off-by: Alexander Lam 
---
 drivers/thermal/step_wise.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 0cd5e9f..0eeb709 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -94,16 +94,21 @@ static void update_instance_for_dethrottle(struct 
thermal_zone_device *tz,
unsigned long cur_state;
 
list_for_each_entry(instance, >thermal_instances, tz_node) {
-   if (instance->trip != trip ||
-   instance->target == THERMAL_NO_TARGET)
+   if (instance->trip != trip)
continue;
 
cdev = instance->cdev;
cdev->ops->get_cur_state(cdev, _state);
 
-   instance->target = cur_state > instance->lower ?
+   cur_state = cur_state > instance->lower ?
(cur_state - 1) : THERMAL_NO_TARGET;
 
+   if (cur_state == THERMAL_NO_TARGET &&
+   instance->target == THERMAL_NO_TARGET)
+   continue;
+
+   instance->target = cur_state;
+
/* Deactivate a passive thermal instance */
if (instance->target == THERMAL_NO_TARGET)
update_passive_instance(tz, trip_type, -1);
-- 
1.8.0.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] rtc: vt8500: Fix year field in vt8500_rtc_set_time

[Tony Prisk]

year field is incorrectly masked when setting the date. If the year
is beyond 2099, the year field will be incorrectly updated in hardware.

This patch masks the year field correctly.

Signed-off-by: Edgar Toernig 
Signed-off-by: Tony Prisk 
---
Patch based on 3.8-rc1

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

diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 14e2d8c..37b42a4 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -137,7 +137,7 @@ static int vt8500_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
return -EINVAL;
}
 
-   writel((bin2bcd(tm->tm_year - 100) << DATE_YEAR_S)
+   writel((bin2bcd(tm->tm_year % 100) << DATE_YEAR_S)
| (bin2bcd(tm->tm_mon) << DATE_MONTH_S)
| (bin2bcd(tm->tm_mday)),
vt8500_rtc->regbase + VT8500_RTC_DS);
-- 
1.7.9.5

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

Re: Fwd: PROBLEM: Random kernel panic & system freeze when watching video

[Du Jiulun]

@Boris:

> Recheck that it is completely correct and then run it through mcelog as
> it says above to decode what kind of error you get.

I didn't take the first photo clear enough to tell between "8" and
"0". But later the panic happened again, and the information is mostly
the same, except those after "TSC" and "TIME".
I tried to follow the instructions and I don't know if I'm right
(using "sudo mcelog --ascii < x.txt" where x.txt is the part without
"mce: [Hardware Error]: "). I switched to the same -ck kernel to run
the command, and the output is as following:

CPU 2: Machine Check Exception: 4 Bank 2: b205
TSC 6568f53a1cee
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 2 BANK 2 TSC 6568f53a1cee
TIME 1356717945 Sat Dec 29 02:05:45 2012
STATUS b205 MCGSTATUS 4
PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC 1 microcode c
Run the above through 'mcelog --ascii'
CPU 0: Machine Check Exception: 4 Bank 2: b205
TSC 6568f53a1cfc
HARDWARE ERROR. This is *NOT* a software problem!
Please contact your hardware vendor
CPU 0 BANK 2 TSC 6568f53a1cfc
TIME 1356717945 Sat Dec 29 02:05:45 2012
STATUS b205 MCGSTATUS 4
PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC 0 microcode c
Run the above through 'mcelog --ascii'
Machine check: Processor context corrupt

It seems that nothing much has come up except those already there.
Since there's something about hardware error, I've got these message
in *bold* in my booting log: (from "sudo journalctl --line=5000",
don't know if relevant, sorry if not)

ACPI: RSDP 000f0410 00024 (v02 _ASUS_)
ACPI: XSDT aada5e18 0006C (v01 _ASUS_ Notebook 06222004 MSFT 00010013)
ACPI: FACP aad81c18 000F4 (v04 _ASUS_ Notebook 06222004 MSFT 00010013)
ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tables!
(20120711/tbfadt-394)
ACPI BIOS Bug: Warning: 32/64X FACS address mismatch in FADT -
0xAADB7F40/0xAADD1D40, using 32 (20120711/tbfadt-521)
ACPI: DSDT aad44018 13C72 (v01 _ASUS_ Notebook  INTL 20051117)
ACPI: FACS aadb7f40 00040
ACPI: APIC aada4f18 0008C (v02 _ASUS_ Notebook 06222004 MSFT 00010013)
ACPI: DBGP aada6f18 00034 (v01 _ASUS_ Notebook 06222004 MSFT 00010013)
ACPI: ECDT aadd1b18 000C1 (v01 _ASUS_ Notebook 06222004 AMI. 0003)
ACPI: SLIC aadb2c18 00176 (v01 _ASUS_ Notebook 06222004 ASUS 0001)
ACPI: MCFG aadd0d18 0003C (v01 _ASUS_ Notebook 06222004 MSFT 0097)
ACPI: HPET aadd0c98 00038 (v01 _ASUS_ Notebook 06222004 AMI. 0003)
ACPI: SSDT aad9f018 009F1 (v01  PmRefCpuPm 3000 INTL 20051117)
ACPI: DMAR aad81f18 000B8 (v01 INTEL  CP_DALE  0001 INTL 0001)

perf_event_intel: CPUID marked event: 'bus cycles' unavailable

mtrr: your CPUs had inconsistent variable MTRR settings

ACPI: Executed 2 blocks of module-level executable AML code
[Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
ACPI: SSDT aada3918 003F7 (v01  PmRef  Cpu0Ist 3000 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 003F7 (v01  PmRef  Cpu0Ist 3000 INTL 20051117)
ACPI: SSDT aada1018 008A9 (v01  PmRef  Cpu0Cst 3001 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 008A9 (v01  PmRef  Cpu0Cst 3001 INTL 20051117)
ACPI: SSDT aada2a98 00303 (v01  PmRefApIst 3000 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 00303 (v01  PmRefApIst 3000 INTL 20051117)
ACPI: SSDT aada0d98 00119 (v01  PmRefApCst 3000 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT   (null) 00119 (v01  PmRefApCst 3000 INTL 20051117)

2012/12/30 Borislav Petkov :
> + Tony.
>
> On Sun, Dec 30, 2012 at 01:45:40AM +0800, Du Jiulun wrote:
>> [1.] One line summary of the problem:
>>
>> Random kernel panic and system freeze when watching video on my linux laptop
>>
>> [2.] Full description of the problem/report:
>>
>> I'm experiencing random (but frequent) kernel panics and system
>> freezes without panic information while I'm watching videos using
>> SMPlayer or Google Chrome (with Flash plugin).
>>
>> This problem has been troubling me since (about) a year ago when I was
>> using Ubuntu with 3.2.x kernel.
>>
>> I'm not quite sure if I should report to the kernel developers or the
>> Intel graphics driver's developers, so if it shouldn't be here, I'm
>> really sorry about this.
>>
>> [3.] Keywords (i.e., modules, networking, kernel):
>>
>> kernel, panic, freeze, video, Intel, h264, flash
>>
>> [4.] Kernel version (from /proc/version):
>>
>> Linux version 3.6.10-1-ck (xiaodu@xiaodupc) (gcc version 4.7.2 (GCC) )
>> #1 SMP PREEMPT Wed Dec 12 15:26:26 CST 2012
>>
>> [5.] Output of Oops.. message (if applicable) with symbolic information
>>  resolved (see Documentation/oops-tracing.txt)
>>
>> [5.1.] Kernel panic information (I read from the photo I taken, but
>> I'm not sure if it's completely correct)
>
> Recheck that it is completely correct and then run it through mcelog as
> it says above to decode what kind of error you get.

[PATCH 6/6 v13] gpio: Add block gpio to several gpio drivers

[Roland Stigge]

This patch adds block GPIO support to several gpio drivers.

This implements block GPIO only for some selected drivers since block GPIO is
an optional feature which may not be suitable for every GPIO hardware. (With
automatic fallback to the single GPIO functions if not available in a driver.)

Signed-off-by: Roland Stigge 

---
 drivers/gpio/Kconfig  |2 
 drivers/gpio/gpio-em.c|   23 ++
 drivers/gpio/gpio-ge.c|   29 +
 drivers/gpio/gpio-generic.c   |   56 +
 drivers/gpio/gpio-ks8695.c|   34 +++
 drivers/gpio/gpio-lpc32xx.c   |   82 ++
 drivers/gpio/gpio-max730x.c   |   61 
 drivers/gpio/gpio-max732x.c   |   59 +++
 drivers/gpio/gpio-mc33880.c   |   16 +++
 drivers/gpio/gpio-ml-ioh.c|   27 
 drivers/gpio/gpio-mm-lantiq.c |   22 ++
 drivers/gpio/gpio-mpc5200.c   |   64 +
 drivers/gpio/gpio-mpc8xxx.c   |   41 +++
 drivers/gpio/gpio-pca953x.c   |   64 +
 drivers/gpio/gpio-pcf857x.c   |   24 +++
 drivers/gpio/gpio-pch.c   |   27 
 drivers/gpio/gpio-pl061.c |   17 +++
 drivers/gpio/gpio-sa1100.c|   20 +
 drivers/gpio/gpio-samsung.c   |   31 ++
 drivers/gpio/gpio-twl6040.c   |   32 ++
 drivers/gpio/gpio-ucb1400.c   |   23 ++
 drivers/gpio/gpio-vt8500.c|   24 +++
 drivers/gpio/gpio-xilinx.c|   44 
 drivers/pinctrl/pinctrl-at91.c|   29 +
 drivers/pinctrl/pinctrl-nomadik.c |   36 
 25 files changed, 887 insertions(+)

--- linux-2.6.orig/drivers/gpio/Kconfig
+++ linux-2.6/drivers/gpio/Kconfig
@@ -144,11 +144,13 @@ config GPIO_MM_LANTIQ
 config GPIO_MPC5200
def_bool y
depends on PPC_MPC52xx
+   select BITREVERSE
 
 config GPIO_MPC8XXX
bool "MPC512x/MPC8xxx GPIO support"
depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
   FSL_SOC_BOOKE || PPC_86xx
+   select BITREVERSE
help
  Say Y here if you're going to use hardware that connects to the
  MPC512x/831x/834x/837x/8572/8610 GPIOs.
--- linux-2.6.orig/drivers/gpio/gpio-em.c
+++ linux-2.6/drivers/gpio/gpio-em.c
@@ -202,6 +202,27 @@ static void em_gio_set(struct gpio_chip
__em_gio_set(chip, GIO_OH, offset - 16, value);
 }
 
+static unsigned long em_gio_get_block(struct gpio_chip *chip,
+ unsigned long mask)
+{
+   return (int)(em_gio_read(gpio_to_priv(chip), GIO_I) & mask);
+}
+
+static void em_gio_set_block(struct gpio_chip *chip, unsigned long mask,
+unsigned long values)
+{
+   unsigned long mask_ol = mask & 0x;
+   unsigned long mask_oh = mask >> 16;
+
+   unsigned long values_ol = values & mask_ol;
+   unsigned long values_oh = (values >> 16) & mask_oh;
+
+   em_gio_write(gpio_to_priv(chip), GIO_OL,
+mask_ol << 16 | values_ol);
+   em_gio_write(gpio_to_priv(chip), GIO_OH,
+mask_oh << 16 | values_oh);
+}
+
 static int em_gio_direction_output(struct gpio_chip *chip, unsigned offset,
   int value)
 {
@@ -282,8 +303,10 @@ static int em_gio_probe(struct platform_
gpio_chip = >gpio_chip;
gpio_chip->direction_input = em_gio_direction_input;
gpio_chip->get = em_gio_get;
+   gpio_chip->get_block = em_gio_get_block;
gpio_chip->direction_output = em_gio_direction_output;
gpio_chip->set = em_gio_set;
+   gpio_chip->set_block = em_gio_set_block;
gpio_chip->to_irq = em_gio_to_irq;
gpio_chip->label = name;
gpio_chip->owner = THIS_MODULE;
--- linux-2.6.orig/drivers/gpio/gpio-ge.c
+++ linux-2.6/drivers/gpio/gpio-ge.c
@@ -100,6 +100,29 @@ static void gef_gpio_set(struct gpio_chi
_gef_gpio_set(mmchip->regs + GEF_GPIO_OUT, offset, value);
 }
 
+static unsigned long gef_gpio_get_block(struct gpio_chip *chip,
+   unsigned long mask)
+{
+   struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
+
+   return ioread32be(mmchip->regs + GEF_GPIO_IN) & mask;
+}
+
+static void gef_gpio_set_block(struct gpio_chip *chip,
+  unsigned long mask, unsigned long values)
+{
+   struct of_mm_gpio_chip *mmchip = to_of_mm_gpio_chip(chip);
+   void __iomem *reg = mmchip->regs + GEF_GPIO_OUT;
+   unsigned int data;
+
+   data = ioread32be(reg);
+
+   data &= ~mask;
+   data |= values & mask;
+
+   iowrite32be(data, reg);
+}
+
 static int __init gef_gpio_init(void)
 {
struct device_node *np;
@@ -125,6 +148,8 @@ static int __init 

[PATCH 1/6 v13] gpio: Add a block GPIO API to gpiolib

[Roland Stigge]

The recurring task of providing simultaneous access to GPIO lines (especially
for bit banging protocols) needs an appropriate API.

This patch adds a kernel internal "Block GPIO" API that enables simultaneous
access to several GPIOs. This is done by abstracting GPIOs to an n-bit word:
Once requested, it provides access to a group of GPIOs which can range over
multiple GPIO chips.

Signed-off-by: Roland Stigge 
---

 Documentation/gpio.txt |   58 +++
 drivers/gpio/gpiolib.c |  227 +
 include/asm-generic/gpio.h |   17 +++
 include/linux/gpio.h   |   97 +++
 4 files changed, 399 insertions(+)

--- linux-2.6.orig/Documentation/gpio.txt
+++ linux-2.6/Documentation/gpio.txt
@@ -481,6 +481,64 @@ exact name string of pinctrl device has
 argument to this routine.
 
 
+Block GPIO
+--
+
+The above described interface concentrates on handling single GPIOs.  However,
+in applications where it is critical to set several GPIOs at once, this
+interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
+Consider a GPIO controller that is connected via a slow I2C line. When
+switching two or more GPIOs one after another, there can be considerable time
+between those events. This is solved by an interface called Block GPIO:
+
+struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size,
+const char *name);
+
+This creates a new block of GPIOs as a list of GPIO numbers with the specified
+size which are accessible via the returned struct gpio_block and the accessor
+functions described below. Please note that you need to request the GPIOs
+separately via gpio_request(). Similarly, the direction of the used GPIOs need
+to be set by the user before using the block. An arbitrary list of globally
+valid GPIOs can be specified, even ranging over several gpio_chips. Actual
+handling of I/O operations will be done on a best effort base, i.e.
+simultaneous I/O only where possible by hardware and implemented in the
+respective GPIO driver. The number of GPIOs in one block is limited to the
+number of bits in an unsigned long, or BITS_PER_LONG, of the respective
+platform, i.e. typically at least 32 on a 32 bit system, and at least 64 on a
+64 bit system. However, several blocks can be defined at once.
+
+unsigned long gpio_block_get(struct gpio_block *block, unsigned long mask);
+void gpio_block_set(struct gpio_block *block, unsigned long mask,
+   unsigned long values);
+
+With those accessor functions, setting and getting the GPIO values is possible,
+analogous to gpio_get_value() and gpio_set_value(). Each bit in the return
+value of gpio_block_get() and in the value argument of gpio_block_set()
+corresponds to a bit specified on gpio_block_create(). The mask parameters
+specify which bits in the block are acted upon. This is useful to let some bits
+untouched when doing a set operation on the block.
+
+Block operations in hardware are only possible where the respective GPIO driver
+implements it, falling back to using single GPIO operations where the driver
+only implements single GPIO access.
+
+If a GPIO block includes GPIOs from several chips, the chips are handled one
+after another in the order of first specification in the list of GPIOs defined
+in the GPIO block, starting with bit 0. Note that in this case, you typically
+can't assume simultaneous access.
+
+void gpio_block_free(struct gpio_block *block);
+
+After the GPIO block isn't used anymore, it should be free'd via
+gpio_block_free().
+
+int gpio_block_register(struct gpio_block *block);
+void gpio_block_unregister(struct gpio_block *block);
+
+These functions can be used to register a GPIO block. Blocks registered this
+way will be available via userspace API.
+
+
 What do these conventions omit?
 ===
 One of the biggest things these conventions omit is pin multiplexing, since
--- linux-2.6.orig/drivers/gpio/gpiolib.c
+++ linux-2.6/drivers/gpio/gpiolib.c
@@ -83,6 +83,8 @@ static inline void desc_set_label(struct
 #endif
 }
 
+static LIST_HEAD(gpio_block_list);
+
 /* Warn when drivers omit gpio_request() calls -- legal but ill-advised
  * when setting direction, and otherwise illegal.  Until board setup code
  * and drivers use explicit requests everywhere (which won't happen when
@@ -217,6 +219,16 @@ static int gpio_get_direction(unsigned g
return status;
 }
 
+static bool gpio_block_is_output(struct gpio_block *block)
+{
+   int i;
+
+   for (i = 0; i < block->ngpio; i++)
+   if (!test_bit(FLAG_IS_OUT, _desc[block->gpio[i]].flags))
+   return false;
+   return true;
+}
+
 #ifdef CONFIG_GPIO_SYSFS
 
 /* lock protects against unexport_gpio() being called while
@@ -1799,6 +1811,221 @@ void __gpio_set_value(unsigned gpio, int
 }
 EXPORT_SYMBOL_GPL(__gpio_set_value);
 
+static struct gpio_block_chip 

[PATCH 2/6 v13] gpio: Add sysfs support to block GPIO API

[Roland Stigge]

This patch adds sysfs support to the block GPIO API.

Signed-off-by: Roland Stigge 

---
 Documentation/ABI/testing/sysfs-gpio |   20 ++
 drivers/gpio/gpiolib.c   |  252 ++-
 include/asm-generic/gpio.h   |   11 +
 include/linux/gpio.h |   15 ++
 4 files changed, 297 insertions(+), 1 deletion(-)

--- linux-2.6.orig/Documentation/ABI/testing/sysfs-gpio
+++ linux-2.6/Documentation/ABI/testing/sysfs-gpio
@@ -25,3 +25,23 @@ Description:
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
 
+What:  /sys/class/gpioblock/
+Date:  October 2012
+KernelVersion: 3.7
+Contact:   Roland Stigge 
+Description:
+
+  Block GPIO devices are visible in sysfs as soon as they are registered
+  (e.g. via devicetree definition). For actual I/O use, their "exported"
+  boolean attribute must be set to "1". Then, the attribute "values" is
+  created and at the same time, the GPIOs in the block are requested for
+  exclusive use by sysfs.
+
+/sys/class/gpioblock
+   /BLOCKNAME ... for each GPIO block name
+   /ngpio ... (r/o) number of GPIOs in this group
+   /exported ... sysfs export state of this group (0, 1)
+   /value ... current value as 32 or 64 bit integer in hex
+   (only available if /exported is 1)
+   /mask ... current mask as 32 or 64 bit integer in hex
+   (only available if /exported is 1)
--- linux-2.6.orig/drivers/gpio/gpiolib.c
+++ linux-2.6/drivers/gpio/gpiolib.c
@@ -224,7 +224,8 @@ static bool gpio_block_is_output(struct
int i;
 
for (i = 0; i < block->ngpio; i++)
-   if (!test_bit(FLAG_IS_OUT, _desc[block->gpio[i]].flags))
+   if ((block->cur_mask & BIT(i)) &&
+   !test_bit(FLAG_IS_OUT, _desc[block->gpio[i]].flags))
return false;
return true;
 }
@@ -1020,6 +1021,240 @@ static void gpiochip_unexport(struct gpi
chip->label, status);
 }
 
+static ssize_t gpio_block_ngpio_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   const struct gpio_block *block = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%u\n", block->ngpio);
+}
+
+static ssize_t gpio_block_value_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   const struct gpio_block *block = dev_get_drvdata(dev);
+
+   return sprintf(buf, sizeof(unsigned long) == 4 ? "0x%08lx\n" :
+  "0x%016lx\n", gpio_block_get(block, block->cur_mask));
+}
+
+static ssize_t gpio_block_value_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+   ssize_t status;
+   struct gpio_block   *block = dev_get_drvdata(dev);
+   unsigned long   value;
+
+   status = kstrtoul(buf, 0, );
+   if (status == 0) {
+   mutex_lock(_lock);
+   if (gpio_block_is_output(block)) {
+   gpio_block_set(block, block->cur_mask, value);
+   status = size;
+   } else {
+   status = -EPERM;
+   }
+   mutex_unlock(_lock);
+   }
+   return status;
+}
+
+static struct device_attribute
+dev_attr_block_value = __ATTR(value, S_IWUSR | S_IRUGO, gpio_block_value_show,
+ gpio_block_value_store);
+
+static ssize_t gpio_block_mask_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   const struct gpio_block *block = dev_get_drvdata(dev);
+
+   return sprintf(buf, sizeof(unsigned long) == 4 ? "0x%08lx\n" :
+  "0x%016lx\n", block->cur_mask);
+}
+
+static ssize_t gpio_block_mask_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t size)
+{
+   ssize_t status;
+   struct gpio_block   *block = dev_get_drvdata(dev);
+   unsigned long   mask;
+
+   status = kstrtoul(buf, 0, );
+   if (status == 0) {
+   block->cur_mask = mask;
+   status = size;
+   }
+   return status;
+}
+
+static struct device_attribute
+dev_attr_block_mask = __ATTR(mask, S_IWUSR | S_IRUGO, gpio_block_mask_show,
+gpio_block_mask_store);
+
+static struct class gpio_block_class;
+
+static int gpio_block_value_is_exported(struct gpio_block *block)
+{
+   struct device   *dev;
+   struct sysfs_dirent *sd = NULL;
+
+   mutex_lock(_lock);
+   dev = class_find_device(_block_class, NULL, block, match_export);
+

[PATCH 4/6 v13] gpiolib: Fix default attributes for class

[Roland Stigge]

There is a race condition between creating a gpio or gpiochip device and adding
default attributes. This patch fixes this by defining the default attributes as
dev_attrs of the class. For this, it was necessary to create a separate
gpiochip_class besides gpio_class.

Signed-off-by: Roland Stigge 
---
 Documentation/ABI/testing/sysfs-gpio |   11 
 drivers/gpio/gpiolib.c   |   78 ++-
 2 files changed, 44 insertions(+), 45 deletions(-)

--- linux-2.6.orig/Documentation/ABI/testing/sysfs-gpio
+++ linux-2.6/Documentation/ABI/testing/sysfs-gpio
@@ -20,6 +20,17 @@ Description:
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write: high, low
/edge ... r/w as: none, falling, rising, both
+
+What:  /sys/class/gpiochip/
+Date:  October 2012
+KernelVersion: 3.7
+Contact:   Roland Stigge 
+Description:
+
+  Each gpiochip is represented by a separate device having the following
+  attributes:
+
+/sys/class/gpiochip
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
--- linux-2.6.orig/drivers/gpio/gpiolib.c
+++ linux-2.6/drivers/gpio/gpiolib.c
@@ -362,9 +362,6 @@ static ssize_t gpio_value_store(struct d
return status;
 }
 
-static const DEVICE_ATTR(value, 0644,
-   gpio_value_show, gpio_value_store);
-
 static irqreturn_t gpio_sysfs_irq(int irq, void *priv)
 {
struct sysfs_dirent *value_sd = priv;
@@ -585,19 +582,6 @@ static ssize_t gpio_active_low_store(str
return status ? : size;
 }
 
-static const DEVICE_ATTR(active_low, 0644,
-   gpio_active_low_show, gpio_active_low_store);
-
-static const struct attribute *gpio_attrs[] = {
-   _attr_value.attr,
-   _attr_active_low.attr,
-   NULL,
-};
-
-static const struct attribute_group gpio_attr_group = {
-   .attrs = (struct attribute **) gpio_attrs,
-};
-
 /*
  * /sys/class/gpio/gpiochipN/
  *   /base ... matching gpio_chip.base (N)
@@ -612,7 +596,6 @@ static ssize_t chip_base_show(struct dev
 
return sprintf(buf, "%d\n", chip->base);
 }
-static DEVICE_ATTR(base, 0444, chip_base_show, NULL);
 
 static ssize_t chip_label_show(struct device *dev,
   struct device_attribute *attr, char *buf)
@@ -621,7 +604,6 @@ static ssize_t chip_label_show(struct de
 
return sprintf(buf, "%s\n", chip->label ? : "");
 }
-static DEVICE_ATTR(label, 0444, chip_label_show, NULL);
 
 static ssize_t chip_ngpio_show(struct device *dev,
   struct device_attribute *attr, char *buf)
@@ -630,18 +612,6 @@ static ssize_t chip_ngpio_show(struct de
 
return sprintf(buf, "%u\n", chip->ngpio);
 }
-static DEVICE_ATTR(ngpio, 0444, chip_ngpio_show, NULL);
-
-static const struct attribute *gpiochip_attrs[] = {
-   _attr_base.attr,
-   _attr_label.attr,
-   _attr_ngpio.attr,
-   NULL,
-};
-
-static const struct attribute_group gpiochip_attr_group = {
-   .attrs = (struct attribute **) gpiochip_attrs,
-};
 
 /*
  * /sys/class/gpio/export ... write-only
@@ -720,11 +690,32 @@ static struct class_attribute gpio_class
__ATTR_NULL,
 };
 
+static struct device_attribute gpio_attrs[] = {
+   __ATTR(active_low, 0644, gpio_active_low_show, gpio_active_low_store),
+   __ATTR(value, 0644, gpio_value_show, gpio_value_store),
+   __ATTR_NULL,
+};
+
 static struct class gpio_class = {
.name = "gpio",
.owner =THIS_MODULE,
 
-   .class_attrs =  gpio_class_attrs,
+   .class_attrs = gpio_class_attrs,
+   .dev_attrs = gpio_attrs,
+};
+
+static struct device_attribute gpiochip_attrs[] = {
+   __ATTR(label, 0444, chip_label_show, NULL),
+   __ATTR(base, 0444, chip_base_show, NULL),
+   __ATTR(ngpio, 0444, chip_ngpio_show, NULL),
+   __ATTR_NULL,
+};
+
+static struct class gpiochip_class = {
+   .name = "gpiochip",
+   .owner =THIS_MODULE,
+
+   .dev_attrs =gpiochip_attrs,
 };
 
 
@@ -791,10 +782,6 @@ int gpio_export(unsigned gpio, bool dire
goto fail_unlock;
}
 
-   status = sysfs_create_group(>kobj, _attr_group);
-   if (status)
-   goto fail_unregister_device;
-
if (direction_may_change) {
status = device_create_file(dev, _attr_direction);
if (status)
@@ -962,25 +949,22 @@ EXPORT_SYMBOL_GPL(gpio_unexport);
 
 static int gpiochip_export(struct gpio_chip *chip)
 {
-   int status;
+   int status = 0;
struct device   *dev;
 
/* Many systems register gpio chips for SOC support very early,
 * before driver model support is available.  In those cases we
 * export this later, in gpiolib_sysfs_init() ... here we just
-* verify that _some_ field 

[PATCH 0/6 v13] gpio: Add block GPIO

[Roland Stigge]

This set of patches adds:

* Block GPIO API to gpiolib
* Sysfs support for GPIO API, to provide userland access
* Device interface for userland access (alternative to sysfs)
* Devicetree support to instantiate GPIO blocks via DT
* Example implementations in several gpio drivers since they need
  special accessor functions for block wise GPIO access (only for some
  selected drivers since the feature is optional and not suitable for
  all GPIO hardware)
* Fix for race condition in gpiolib on device creation

Signed-off-by: Roland Stigge 
Tested by: Wolfgang Grandegger 
--

Testing branch available at: git://git.antcom.de/linux-2.6.git blockgpio

Changes since v12:
* Added support for gpio drivers ge, ks8695, mc33880, ml-ioh, mpc5200 and
  mpc8xxx
* Added support for pinctrl driver at91

Changes since v11:
* Removed support for at91, since this one is currently in the migration
  process to pinctrl implementation
* Fixed mask setting via sysfs
* Device interface: declare gpio_block_fop_poll() static

Changes since v10:
* gpioblock-of.c: Catch <1 specified GPIOs
* gpioblock-of.c: Fixed memory leak in probe()'s error path
* gpioblock-of.c: Fixed block node's refcount via of_node_put()
* Added driver support for samsung, mm-lantiq and sa1100
* Added driver support for at91 (by Wolfgang Grandegger)
* Added pinctrl driver support for pinctl-nomadik

Changed since v9:
* Changed IRQ flags for device interface's poll() from IRQF_TRIGGER_FALLING
  to IRQF_SHARED
* Use block name on gpio_request
* Added spinlock for ISR manipulated data (dev interface / poll())

Changed since v8:
* Added poll() function to dev interface for IRQ handling
* Fixed gpio_block_register() in case of missing CONFIG_GPIO_SYSFS
* Fixed mask handling in sysfs interface
* Fixed get_user/put_user pointer (cast)

Changes since v7:
* Fixed error in API documentation (name arg missing in prototype)
* Fixed compile error if sysfs is missing: Moved gpio_block_is_output()
  out of sysfs-ifdef
* Added error handling to gpio_block_register()
* Added mask attribute to sysfs (although dev interface exists now)

Changes since v6:
* Changed realloc to list handling
* Added mask to kernel API
* Added device interface as userspace API
* Changed sizeof() to BITS_PER_LONG
* Fixed multiline comment style
* Documented direction setting by the user
* Documented order of handled chips in case of multiple chips in one block

Changes since v5:
* Documented sysfs: elaborated on "exported" and "values" attributes
* Documented sysfs: gpiochip is a separate class now
* Aggregated driver support patches for block gpio into one single patch
* Added gpio block driver support for twl6040 and pch

Changes since v4:
* Documented word width
* Bugfix: export/unexport on register/unregister
* Using default dev_attrs for gpio_block_class
* Fix gpiolib: race condition on device creation
* Added driver support for ucb14500, vt8500, xilinx

Changes since v3:
* Added driver support for pca953x, em, pl061, max732x, pcf857x
* Coding style improvements
* Fixed krealloc memory leak in error case
* sysfs: values in hex
* Register blocks in a list
* Narrowing lock scope
* Use S_IWUSR and S_IRUGO instead of direct octal values
* Use for_each_set_bit()
* Change from unsigned to unsigned long for masks and values

Changes since v2:
* Added sysfs support
* Added devicetree support
* Added support for lpc32xx, generic
* Added functions for GPIO block registration
* Added more error checking
* Bit remapping bugfix

Changes since v1:
* API change to 32/64 bit word, bit masks

Thanks to Ryan Mallon, Linus Walleij, Stijn Devriendt, Jean-Christophe
Plagniol-Villard, Mark Brown, Greg Kroah-Hartman, Grant Likely, Stefan
Roese, Wolfgang Grandegger, Tobias Rutz, Fengguang Wu and Mark Rutland
for reviewing and testing!

Roland Stigge (6):
 gpio: Add a block GPIO API to gpiolib
 gpio: Add sysfs support to block GPIO API
 gpio: Add userland device interface to block GPIO
 gpiolib: Fix default attributes for class
 gpio: Add device tree support to block GPIO API
 gpio: Add block gpio to several gpio drivers

 Documentation/ABI/testing/dev-gpioblock   |   34 
 Documentation/ABI/testing/sysfs-gpio  |   31 
 Documentation/devicetree/bindings/gpio/gpio-block.txt |   36 
 Documentation/gpio.txt|   58 +
 drivers/gpio/Makefile |1 
 drivers/gpio/gpio-em.c|   23 
 drivers/gpio/gpio-generic.c   |   56 +
 drivers/gpio/gpio-lpc32xx.c   |   82 +
 drivers/gpio/gpio-max730x.c   |   61 +
 drivers/gpio/gpio-max732x.c   |   59 +
 drivers/gpio/gpio-mm-lantiq.c |   22 
 drivers/gpio/gpio-pca953x.c   |   64 +
 drivers/gpio/gpio-pcf857x.c   |   24 
 drivers/gpio/gpio-pch.c   |   27 
 drivers/gpio/gpio-pl061.c

[PATCH 3/6 v13] gpio: Add userland device interface to block GPIO

[Roland Stigge]

This patch adds a character device interface to the block GPIO system.

Signed-off-by: Roland Stigge 
---
 Documentation/ABI/testing/dev-gpioblock |   34 
 drivers/gpio/gpiolib.c  |  225 +++-
 include/linux/gpio.h|   13 +
 3 files changed, 271 insertions(+), 1 deletion(-)

--- /dev/null
+++ linux-2.6/Documentation/ABI/testing/dev-gpioblock
@@ -0,0 +1,34 @@
+What:  /dev/
+Date:  Nov 2012
+KernelVersion: 3.7
+Contact:   Roland Stigge 
+Description:   The /dev/ character device node provides userspace
+   access to GPIO blocks, named exactly as the block, e.g.
+   /dev/block0.
+
+   Reading:
+   When reading sizeof(unsigned long) bytes from the device, the
+   current state of the block, masked by the current mask (see
+   below) can be obtained as a word. When the device is opened
+   with O_NONBLOCK, read() always returns with data immediately,
+   otherwise it blocks until data is available, see IRQ handling
+   below.
+
+   Writing:
+   By writing sizeof(unsigned long) bytes to the device, the
+   current state of the block can be set. This operation is
+   masked by the current mask (see below).
+
+   IRQ handling:
+   When one or more IRQs in the block are IRQ capable, you can
+   poll() on the device to check/wait for this IRQ. If no IRQ
+   is available, poll() returns -ENOSYS and userspace needs to
+   (busy) poll itself if necessary.
+
+   Setting the mask (default: all bits set):
+   By doing an ioctl(fd, 0, ) with an unsigned long mask, the
+   current mask for read and write operations on this gpio block
+   can be set.
+
+   See also Documentation/gpio.txt for an explanation of block
+   GPIO.
--- linux-2.6.orig/drivers/gpio/gpiolib.c
+++ linux-2.6/drivers/gpio/gpiolib.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -2243,6 +2245,207 @@ struct gpio_block *gpio_block_find_by_na
 }
 EXPORT_SYMBOL_GPL(gpio_block_find_by_name);
 
+static struct gpio_block *gpio_block_find_by_minor(int minor)
+{
+   struct gpio_block *i;
+
+   list_for_each_entry(i, _block_list, list)
+   if (i->miscdev.minor == minor)
+   return i;
+   return NULL;
+}
+
+static bool gpio_block_is_irq_duplicate(struct gpio_block *block, int index)
+{
+   int irq = gpio_to_irq(block->gpio[index]);
+   int i;
+
+   for (i = 0; i < index; i++)
+   if (gpio_to_irq(block->gpio[i]) == irq)
+   return true;
+   return false;
+}
+
+static irqreturn_t gpio_block_irq_handler(int irq, void *dev)
+{
+   struct gpio_block *block = dev;
+
+   wake_up_interruptible(>wait_queue);
+   block->got_int = true;
+
+   return IRQ_HANDLED;
+}
+
+static int gpio_block_fop_open(struct inode *in, struct file *f)
+{
+   int i;
+   struct gpio_block *block = gpio_block_find_by_minor(MINOR(in->i_rdev));
+   int status;
+   int irq;
+
+   if (!block)
+   return -ENOENT;
+
+   block->irq_controlled = false;
+   block->got_int = false;
+   spin_lock_init(>lock);
+   init_waitqueue_head(>wait_queue);
+   f->private_data = block;
+
+   for (i = 0; i < block->ngpio; i++) {
+   status = gpio_request(block->gpio[i], block->name);
+   if (status)
+   goto err1;
+
+   irq = gpio_to_irq(block->gpio[i]);
+   if (irq >= 0 &&
+   !test_bit(FLAG_IS_OUT, _desc[block->gpio[i]].flags) &&
+   !gpio_block_is_irq_duplicate(block, i)) {
+   status = request_irq(irq, gpio_block_irq_handler,
+IRQF_SHARED,
+block->name, block);
+   if (status)
+   goto err2;
+
+   block->irq_controlled = true;
+   }
+   }
+
+   return 0;
+
+err1:
+   while (i > 0) {
+   i--;
+
+   irq = gpio_to_irq(block->gpio[i]);
+   if (irq >= 0 &&
+   !test_bit(FLAG_IS_OUT, _desc[block->gpio[i]].flags) &&
+   !gpio_block_is_irq_duplicate(block, i))
+   free_irq(irq, block);
+err2:
+   gpio_free(block->gpio[i]);
+   }
+   return status;
+}
+
+static int gpio_block_fop_release(struct inode *in, struct file *f)
+{
+   int i;
+   struct gpio_block *block = (struct gpio_block *)f->private_data;
+
+   for (i = 0; i < block->ngpio; i++) {
+   int irq = gpio_to_irq(block->gpio[i]);
+
+   

[PATCH 5/6 v13] gpio: Add device tree support to block GPIO API

[Roland Stigge]

This patch adds device tree support to the block GPIO API.

Signed-off-by: Roland Stigge 

---
 Documentation/devicetree/bindings/gpio/gpio-block.txt |   36 ++
 drivers/gpio/Makefile |1 
 drivers/gpio/gpioblock-of.c   |  100 ++
 3 files changed, 137 insertions(+)

--- /dev/null
+++ linux-2.6/Documentation/devicetree/bindings/gpio/gpio-block.txt
@@ -0,0 +1,36 @@
+Block GPIO definition
+=
+
+This binding specifies arbitrary blocks of gpios, combining gpios from one or
+more GPIO controllers together, to form a word for r/w access.
+
+Required property:
+- compatible: must be "linux,gpio-block"
+
+Required subnodes:
+- the name will be the registered name of the block
+- property "gpios" is a list of gpios for the respective block
+
+Example:
+
+blockgpio {
+compatible = "linux,gpio-block";
+
+block0 {
+gpios = < 3 0 0>,
+< 3 1 0>;
+};
+block1 {
+gpios = < 4 1 0>,
+< 4 3 0>,
+< 4 2 0>,
+< 4 4 0>,
+< 4 5 0>,
+< 4 6 0>,
+< 4 7 0>,
+< 4 8 0>,
+< 4 9 0>,
+< 4 10 0>,
+< 4 19 0>;
+};
+};
--- linux-2.6.orig/drivers/gpio/Makefile
+++ linux-2.6/drivers/gpio/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_DEBUG_GPIO)+= -DDEBUG
 obj-$(CONFIG_GPIOLIB)  += gpiolib.o devres.o
 obj-$(CONFIG_OF_GPIO)  += gpiolib-of.o
 obj-$(CONFIG_GPIO_ACPI)+= gpiolib-acpi.o
+obj-$(CONFIG_OF_GPIO)  += gpioblock-of.o
 
 # Device drivers. Generally keep list sorted alphabetically
 obj-$(CONFIG_GPIO_GENERIC) += gpio-generic.o
--- /dev/null
+++ linux-2.6/drivers/gpio/gpioblock-of.c
@@ -0,0 +1,100 @@
+/*
+ * OF implementation for Block GPIO
+ *
+ * Copyright (C) 2012 Roland Stigge 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int __devinit gpioblock_of_probe(struct platform_device *pdev)
+{
+   struct device_node *block;
+   unsigned *gpios;
+   int ngpio;
+   int ret;
+   struct gpio_block *gb;
+
+   for_each_available_child_of_node(pdev->dev.of_node, block) {
+   int i;
+
+   ngpio = of_gpio_count(block);
+   if (ngpio < 1) {
+   ret = -ENODEV;
+   goto err1;
+   }
+
+   gpios = kzalloc(ngpio * sizeof(*gpios), GFP_KERNEL);
+   if (!gpios) {
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   for (i = 0; i < ngpio; i++) {
+   ret = of_get_gpio(block, i);
+   if (ret < 0)
+   goto err2; /* expect -EPROBE_DEFER */
+   gpios[i] = ret;
+   }
+   gb = gpio_block_create(gpios, ngpio, block->name);
+   if (IS_ERR(gb)) {
+   dev_err(>dev,
+   "Error creating GPIO block from device tree\n");
+   ret = PTR_ERR(gb);
+   goto err2;
+   }
+   ret = gpio_block_register(gb);
+   if (ret < 0)
+   goto err3;
+
+   kfree(gpios);
+   dev_info(>dev, "Registered gpio block %s: %d gpios\n",
+block->name, ngpio);
+   }
+   return 0;
+
+err3:
+   gpio_block_free(gb);
+err2:
+   kfree(gpios);
+err1:
+   of_node_put(block);
+   return ret;
+}
+
+#ifdef CONFIG_OF
+static struct of_device_id gpioblock_of_match[] __devinitdata = {
+   { .compatible = "linux,gpio-block", },
+   { },
+};
+MODULE_DEVICE_TABLE(of, gpioblock_of_match);
+#endif
+
+static struct platform_driver gpioblock_of_driver = {
+   .driver = {
+   .name = "gpio-block",
+   .owner = THIS_MODULE,
+   .of_match_table = of_match_ptr(gpioblock_of_match),
+
+   },
+   .probe  = gpioblock_of_probe,
+};
+
+module_platform_driver(gpioblock_of_driver);
+
+MODULE_DESCRIPTION("GPIO Block driver");
+MODULE_AUTHOR("Roland Stigge ");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS("platform:gpioblock-of");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a 

Holiday

[nadinezmartin]

Dear Supplier,  








   Vanessa and I will be on new years holiday next week (29th 
December to 7th of January, both inclusive).








 If you have any doubt along these 
days we are out of office, contact our colleagues Cristina  
(cristina.serr...@charanga.es) and Rocio (rocio.to...@charanga.es). 








Happy new 
year!   








  Best regards,
--
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] uprobes: Change handle_swbp() to expose bp_vaddr to handler_chain()

[Oleg Nesterov]

Change handle_swbp() to set regs->ip = bp_vaddr in advance, this is
what consumer->handler() needs but uprobe_get_swbp_addr() is not
exported.

This also simplifies the code and makes it more consistent across
the supported architectures. handle_swbp() becomes the only caller
of uprobe_get_swbp_addr().

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/uprobes.c   |1 -
 kernel/events/uprobes.c |   15 +++
 kernel/trace/trace_uprobe.c |4 ++--
 3 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 4e33a35..0ba4cfb 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -681,7 +681,6 @@ static bool __skip_sstep(struct arch_uprobe *auprobe, 
struct pt_regs *regs)
continue;
 
if (auprobe->insn[i] == 0x90) {
-   regs->ip = uprobe_get_swbp_addr(regs);
regs->ip += i + 1;
return true;
}
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 59b6e97..f883813 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1504,6 +1504,10 @@ static void handle_swbp(struct pt_regs *regs)
}
return;
}
+
+   /* change it in advance for ->handler() and restart */
+   instruction_pointer_set(regs, bp_vaddr);
+
/*
 * TODO: move copy_insn/etc into _register and remove this hack.
 * After we hit the bp, _unregister + _register can install the
@@ -1511,14 +1515,14 @@ static void handle_swbp(struct pt_regs *regs)
 */
smp_rmb(); /* pairs with wmb() in install_breakpoint() */
if (unlikely(!test_bit(UPROBE_COPY_INSN, >flags)))
-   goto restart;
+   goto out;
 
utask = current->utask;
if (!utask) {
utask = add_utask();
/* Cannot allocate; re-execute the instruction. */
if (!utask)
-   goto restart;
+   goto out;
}
 
handler_chain(uprobe, regs);
@@ -1531,12 +1535,7 @@ static void handle_swbp(struct pt_regs *regs)
return;
}
 
-restart:
-   /*
-* cannot singlestep; cannot skip instruction;
-* re-execute the instruction.
-*/
-   instruction_pointer_set(regs, bp_vaddr);
+   /* can_skip_sstep() succeeded, or restart if can't singlestep */
 out:
put_uprobe(uprobe);
 }
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 38eee92..52caead 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -488,7 +488,7 @@ static void uprobe_trace_func(struct trace_uprobe *tu, 
struct pt_regs *regs)
return;
 
entry = ring_buffer_event_data(event);
-   entry->ip = uprobe_get_swbp_addr(task_pt_regs(current));
+   entry->ip = instruction_pointer(task_pt_regs(current));
data = (u8 *)[1];
for (i = 0; i < tu->nr_args; i++)
call_fetch(>args[i].fetch, regs, data + tu->args[i].offset);
@@ -663,7 +663,7 @@ static void uprobe_perf_func(struct trace_uprobe *tu, 
struct pt_regs *regs)
if (!entry)
goto out;
 
-   entry->ip = uprobe_get_swbp_addr(task_pt_regs(current));
+   entry->ip = instruction_pointer(task_pt_regs(current));
data = (u8 *)[1];
for (i = 0; i < tu->nr_args; i++)
call_fetch(>args[i].fetch, regs, data + tu->args[i].offset);
-- 
1.5.5.1

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

[PATCH 0/2] uprobes: Change handle_swbp() to expose bp_vaddr to handler_chain()

[Oleg Nesterov]

Hello.

Inspired by the recent uretrpobe RFC's. I think it simply makes no sense
to call handler/skip/arch_uprobe_pre_xol with regs->ip pointing to the
"random" address after the task hits bp.

Ananth, could you please confirm 2/2 can't break powerpc? It "obviously"
shouldn't because uprobe_get_swbp_addr() is a "nop" on ppc, but still
your ack is welcomed.

Oleg.

--
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] uprobes/x86: Change __skip_sstep() to actually skip the whole insn

[Oleg Nesterov]

__skip_sstep() doesn't update regs->ip. Currently this is correct
but only "by accident" and it doesn't skip the whole insn. Change
it to advance ->ip by the length of the detected 0x66*0x90 sequence.

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/uprobes.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index c71025b..4e33a35 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -680,8 +680,11 @@ static bool __skip_sstep(struct arch_uprobe *auprobe, 
struct pt_regs *regs)
if (auprobe->insn[i] == 0x66)
continue;
 
-   if (auprobe->insn[i] == 0x90)
+   if (auprobe->insn[i] == 0x90) {
+   regs->ip = uprobe_get_swbp_addr(regs);
+   regs->ip += i + 1;
return true;
+   }
 
break;
}
-- 
1.5.5.1

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

Re: [PATCH] hwspinlock/core: Add testing capabilities

[Ido Yariv]

Hi Steve,

On Sun, Dec 30, 2012 at 10:13:08PM +0800, steve.zhan wrote:
> Hi,
>    Acked-by: Steve zhan zhanzhe...@gmail.com
>  
>    "I'd rather not test the spinlocks after they are registering as they
> might already be in use by then."
> 
>     Why? I think user must use it after hwspin_lock_register have retured
> sucess.

Once the spinlocks are registered anyone can request and acquire these.
The tests could then interfere with any users of the hwspinlock layer,
or simply fail (because the spinlocks might already be acquired).

Thanks,
Ido.
--
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: [ibm-acpi-devel] [PATCH] drivers/platform/x86/thinkpad_acpi.c: Handle HKEY event 0x6040

[Henrique de Moraes Holschuh]

On Sat, 29 Dec 2012, Richard Hartmann wrote:
> Handle HKEY event generated on AC power change. The current message
> asks users to submit data related to this event which leads to
> a lot of confusion and noise on the mailing list.
> 
> The following is a list affected models and 'Message-Id'
> from ibm-acpi-de...@lists.sourceforge.net of people who saw this
> event when either plugging or unplugging the AC adapter or
> docking or undocking their laptop.
> 
> X120e - caaaujb5v9dhdbdxdvvhnjog4urzc1tgkqeb_zgpay7q8kzh...@mail.gmail.com
> X121e - 20120817143459.gb3...@x1.osrc.amd.com
> X220  - Confirmed by Richard Hartmann
> X220i - 4f406274.7070...@gmail.com
> X220t - 4f489f5b.9040...@cs.tu-berlin.de
> X230  - CAKx4u7kqvVH0-gstomsiVYdGC0i6=bgxzaq8sq9gbg76tgm...@mail.gmail.com
> T420  - 9c848ee30b006737d0534d906bab0...@niklaas-baudet.net
> T420s - 20120608080824.gs25...@hexapodia.org
> W520  - 20121008181050.gf2...@ericlaptop.home.christensenplace.us
> 
> Signed-off-by: Richard Hartmann 

Acked-by: Henrique de Moraes Holschuh 

> ---
>  drivers/platform/x86/thinkpad_acpi.c |   11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index 75dd651..15e2bba 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -209,9 +209,8 @@ enum tpacpi_hkey_event_t {
>   TP_HKEY_EV_ALARM_SENSOR_XHOT= 0x6022, /* sensor critically hot */
>   TP_HKEY_EV_THM_TABLE_CHANGED= 0x6030, /* thermal table changed */
>  
> - TP_HKEY_EV_UNK_6040 = 0x6040, /* Related to AC change?
> -  some sort of APM hint,
> -  W520 */
> + /* AC-related events */
> + TP_HKEY_EV_AC_CHANGED   = 0x6040, /* AC status changed */
>  
>   /* Misc */
>   TP_HKEY_EV_RFKILL_CHANGED   = 0x7000, /* rfkill switch changed */
> @@ -3629,6 +3628,12 @@ static bool hotkey_notify_6xxx(const u32 hkey,
>"a sensor reports something is extremely hot!\n");
>   /* recommended action: immediate sleep/hibernate */
>   break;
> + case TP_HKEY_EV_AC_CHANGED:
> + /* X120e, X121e, X220, X220i, X220t, X230, T420, T420s, W520:
> +  * AC status changed; can be triggered by plugging or
> +  * unplugging AC adapter, docking or undocking. */
> +
> + /* fallthrough */
>  
>   case TP_HKEY_EV_KEY_NUMLOCK:
>   case TP_HKEY_EV_KEY_FN:

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails

[Ben Hutchings]

On Sun, 2012-12-30 at 13:38 +0100, Ben Hutchings wrote:
> On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote:
> > Ben Hutchings wrote:
> > > 3.2-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Andreas Hartmann 
> > > 
> > > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.
> > 
> > [...]
> > 
> > This patch is a workaround for
> > 
> > mac80211: retry sending failed BAR frames later instead of tearing down
> > aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html -
> > f0425beda4d404a6e751439b562100b902ba9c98)
> > See:
> > http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
> > 
> > 
> > Meanwhile there was a bug report complaining about problems with
> > be03d4a45 when used as STA:
> > http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
> > You can find there a few other workaround proposals.
> [...]
> 
> OK, I'll drop this for now.  Once this is sorted out, please send to
> stable a complete list of fixes that are needed.

To be clear, I have all of these in the queue:

be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
ab9d6e4ffe19 Revert: "rt2x00: Don't let mac80211 send a BAR when an AMPDU 
subframe fails"

and I'm intending to drop/defer them all.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails

[Ben Hutchings]

On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote:
> Ben Hutchings wrote:
> > 3.2-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Andreas Hartmann 
> > 
> > commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.
> 
> [...]
> 
> This patch is a workaround for
> 
> mac80211: retry sending failed BAR frames later instead of tearing down
> aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html -
> f0425beda4d404a6e751439b562100b902ba9c98)
> See:
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
> 
> 
> Meanwhile there was a bug report complaining about problems with
> be03d4a45 when used as STA:
> http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
> You can find there a few other workaround proposals.
[...]

OK, I'll drop this for now.  Once this is sorted out, please send to
stable a complete list of fixes that are needed.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Re: [git pull] drm fixes

[Dave Airlie]

On Sun, Dec 30, 2012 at 8:09 PM, Lucas Stach  wrote:
> Hello Dave,
>
> Am Sonntag, den 30.12.2012, 04:23 + schrieb Dave Airlie:
>> Hi Linus,
>>
> [...]
>>
>> Lucas Stach (6):
>>   drm: tegra: protect DC register access with mutex
>  This patch is unnecessary and really shouldn't go in. There
> was a brief discussion on the list with the conclusion to disregard this
> patch.

Linus, I just reverted it on top, didn't want to cause a rebase on  that branch,

updated pull req.

The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:

  Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to d5757dbe79870d825d0dec30074d48683e1d7e9a:

  Revert "drm: tegra: protect DC register access with mutex"
(2012-12-30 21:58:20 +1000)


Alex Deucher (1):
  drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

Ben Skeggs (8):
  drm/nouveau: initial support for GK106
  drm/nouveau/bios: update gpio parsing apis to match current design
  drm/nouveau/bios: implement opcode 0xa9
  drm/nouveau/bios: parse/display extra version component
  drm/nouveau/mxm: silence output if no bios data
  drm/nouveau/bios: cache ramcfg strap on later chipsets
  drm/nvc0/graph: fix fuc, and enable acceleration on GF119
  drm/nve0/graph: fix fuc, and enable acceleration on all known chipsets

Chris Wilson (6):
  drm/i915: Fixup cursor latency used for IVB lp3 watermarks
  drm/i915: Double the cursor self-refresh latency on Valleyview
  drm/i915: Clear self-refresh watermarks when disabled
  drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM
computations
  drm: Export routines for inserting preallocated nodes into the mm manager
  drm/i915: Preallocate the drm_mm_node prior to manipulating the
GTT drm_mm manager

Daniel Vetter (6):
  drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
  drm/i915: Implement WaSetupGtModeTdRowDispatch
  drm/i915: Implement workaround for broken CS tlb on i830/845
  drm/i915: don't disable disconnected outputs
  drm/i915: optionally disable shrinker lock stealing
  drm/i915: disable shrinker lock stealing for create_mmap_offset

Dave Airlie (5):
  drm/i915: fix flags in dma buf exporting
  Merge branch 'drm-nouveau-fixes-3.8' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
  Merge branch 'drm-fixes-3.8' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next
  Revert "drm: tegra: protect DC register access with mutex"

Jerome Glisse (4):
  drm/radeon: don't leave fence blocked process on failed GPU reset
  drm/radeon: avoid deadlock in pm path when waiting for fence
  drm/radeon: restore modeset late in GPU reset path
  drm/radeon: add support for MEM_WRITE packet

Krzysztof Mazur (1):
  i915: ensure that VGA plane is disabled

Lucas Stach (6):
  drm: tegra: fix front_porch <-> back_porch mixup
  drm: tegra: don't leave clients host1x member uninitialized
  drm: tegra: protect DC register access with mutex
  drm: tegra: remove redundant tegra2_tmds_config entry
  drm: tegra: clean out old gem prototypes
  drm: tegra: program only one window during modeset

 drivers/gpu/drm/drm_mm.c   |  41 --
 drivers/gpu/drm/i915/i915_dma.c|   3 +
 drivers/gpu/drm/i915/i915_drv.h|   8 ++
 drivers/gpu/drm/i915/i915_gem.c|  77 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +
 drivers/gpu/drm/i915/i915_irq.c|  12 ++
 drivers/gpu/drm/i915/i915_reg.h|   4 +-
 drivers/gpu/drm/i915/intel_display.c   |  23 ++-
 drivers/gpu/drm/i915/intel_pm.c| 160 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c|  76 --
 drivers/gpu/drm/i915/intel_ringbuffer.h|   1 +
 .../drm/nouveau/core/engine/graph/fuc/gpcnve0.fuc  |   5 +
 .../nouveau/core/engine/graph/fuc/gpcnve0.fuc.h|  17 ++-
 .../drm/nouveau/core/engine/graph/fuc/hubnvc0.fuc  |  10 ++
 .../nouveau/core/engine/graph/fuc/hubnvc0.fuc.h| 147 +--
 .../drm/nouveau/core/engine/graph/fuc/hubnve0.fuc  |  13 ++
 .../nouveau/core/engine/graph/fuc/hubnve0.fuc.h| 157 ++--
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c   |  11 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |   1 +
 drivers/gpu/drm/nouveau/core/engine/graph/nve0.c   |   3 +-
 drivers/gpu/drm/nouveau/core/include/subdev/bios.h |   1 +
 .../drm/nouveau/core/include/subdev/bios/gpio.h|   8 +-
 

Re: 3.7.1 doesn't go to suspend

[Dmitry E. Oboukhov]

>> Hi, Linux maintainers!
>> 
>> First of all sorry for my bad English.
>> 
>> I have Macbook Pro Retina and used Linux-3.7rc7 with the book.
>> It worked fine.
>> 
>> Today I've tried to migrate to 3.7.1 (from debian repo) and found that
>> current kernel can't suspend.
>> 
>> If I call pm-suspend in my shell, my computer doesn't go to suspend
>> and dmesg showes the error:
>> 
>> [ 2512.960666] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 
>> [snd_hda_intel] returns -11
>> 
>> 
>> 3.7rc7 worked fine.
>> 
>> 
>> In attaches You can find some /proc/* files

> You may want to rmmod snd_hda_inte before suspend and see if it helps?

Hi!
After rmmodding snd_hda_intel pm-suspend doesn't work yet.

nb:[~]$ sudo rmmod snd_hda_intel 
nb:[~]$ sudo rmmod snd_hda_codec_cirrus snd_hda_codec_hdmi
snd_hda_codec
nb:[~]$ sudo rmmod snd_timer 
Error: Module snd_timer is in use by: snd_pcm snd_seq
nb:[~]$ sudo rmmod snd_pcm snd_seq snd_timer 
nb:[~]$ sudo rmmod snd_seq_device 
nb:[~]$ sudo rmmod snd_hwdep 
nb:[~]$ sudo rmmod snd_page_alloc 
nb:[~]$ sudo pm-suspend
nb:[~]$ dmesg|tail
[   30.266443] wlan0: associated
[   30.266463] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes
ready
[   30.342137] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11
[   30.352607] lp: driver loaded but no devices found
[   30.358793] ppdev: user-space parallel port driver
[   30.425092] nouveau W[  PGRAPH][:01:00.0] disabled, PGRAPH=1 to
enable
[   30.778659] bcm5974: bad trackpad package, length: 8
[   32.490108] input: Mouseemu virtual keyboard as
/devices/virtual/input/input19
[   32.490441] input: Mouseemu virtual mouse as
/devices/virtual/input/input20
[   65.112500] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11



Also dmesg complains about the modules until booting process is done:
nb:[~]$ dmesg|grep suspend
[   26.331831] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11
[   30.342137] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11
[   65.112500] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11




3.7rc7 works fine.

PPS: I've just rebooted into 3.7rc7.
its dmesg complains while booting, too:

nb:[~]$ dmesg|grep suspend
[   31.759388] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11

but it complains once and then it suspends/wakeups/plays sounds fine
:)



-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: [PATCH] hwspinlock/core: Add testing capabilities

[Ido Yariv]

Hi Steve,

On Sat, Dec 29, 2012 at 05:19:08PM +0800, steve.zhan wrote:
> Hi,
> 
> It is good idea add this feature.
> 
> 1: Can we let the "ret = hwspin_lock_tests(ops, hwlock);" add after
> hwspin_lock_register_single have return
> succeed, that can avoid test duplicated Or error lockid. Of course, If
> this interface is intend to test soc hardware capability only, we can
> put it in the arch module not this core framework. For driver hardware
> sanity check, i would add it after software have register it.

I'd rather not test the spinlocks after they are registering as they
might already be in use by then.

While this feature only verifies the underlying platform implementation,
I think it's best to avoid code duplication and keep it in one place
that will always get called.

> 2:Is it possible that interface add configs that choose which locks
> will be test? Because the hwspinlock module is init late in
> postcore_initcall phase, Maybe MACH/ARCH code(for example: code in
> early_initcall) need use private other interfaces to lock some
> hwspinlocks and then register hw locks to hwspinlock framework, Maybe
> some hw locks is in lock status but which test failed.

It was assumed that up to the point where the hw spinlocks are
registered they will not be used, regardless of when this module is
initialized.
If this assumption does not hold for your platform, the simplest
solution would be to set this config option to 'N', as there is no safe
way of verifying spinlocks that are actively being used.

Thanks for reviewing this,
Ido.
--
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 for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked

[Michal Hocko]

On Sun 30-12-12 02:09:47, azurIt wrote:
> >which suggests that the patch is incomplete and that I am blind :/
> >mem_cgroup_cache_charge calls __mem_cgroup_try_charge for the page cache
> >and that one doesn't check GFP_MEMCG_NO_OOM. So you need the following
> >follow-up patch on top of the one you already have (which should catch
> >all the remaining cases).
> >Sorry about that...
> 
> 
> This was, again, killing my MySQL server (search for "(mysqld)"):
> http://www.watchdog.sk/lkml/oom_mysqld5

grep "Kill process" oom_mysqld5 
Dec 30 01:53:34 server01 kernel: [  367.061801] Memory cgroup out of memory: 
Kill process 5512 (apache2) score 716 or sacrifice child
Dec 30 01:53:35 server01 kernel: [  367.338024] Memory cgroup out of memory: 
Kill process 5517 (apache2) score 718 or sacrifice child
Dec 30 01:53:35 server01 kernel: [  367.747888] Memory cgroup out of memory: 
Kill process 5513 (apache2) score 721 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  368.159860] Memory cgroup out of memory: 
Kill process 5516 (apache2) score 726 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  368.665606] Memory cgroup out of memory: 
Kill process 5520 (apache2) score 733 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  368.765652] Out of memory: Kill process 
1778 (mysqld) score 39 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  369.101753] Memory cgroup out of memory: 
Kill process 5519 (apache2) score 754 or sacrifice child
Dec 30 01:53:37 server01 kernel: [  369.464262] Memory cgroup out of memory: 
Kill process 5583 (apache2) score 762 or sacrifice child
Dec 30 01:53:37 server01 kernel: [  369.465017] Out of memory: Kill process 
5506 (apache2) score 18 or sacrifice child
Dec 30 01:53:37 server01 kernel: [  369.574932] Memory cgroup out of memory: 
Kill process 5523 (apache2) score 759 or sacrifice child

So your mysqld has been killed by the global OOM not memcg. But why when
you seem to be perfectly fine regarding memory? I guess the following
backtrace is relevant:
Dec 30 01:53:36 server01 kernel: [  368.569720] DMA: 0*4kB 1*8kB 0*16kB 1*32kB 
2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15912kB
Dec 30 01:53:36 server01 kernel: [  368.570447] DMA32: 9*4kB 10*8kB 8*16kB 
6*32kB 5*64kB 6*128kB 4*256kB 2*512kB 3*1024kB 3*2048kB 613*4096kB = 2523636kB
Dec 30 01:53:36 server01 kernel: [  368.571175] Normal: 5*4kB 2060*8kB 
4122*16kB 2550*32kB 2667*64kB 722*128kB 197*256kB 68*512kB 15*1024kB 4*2048kB 
1855*4096kB = 8134036kB
Dec 30 01:53:36 server01 kernel: [  368.571906] 308964 total pagecache pages
Dec 30 01:53:36 server01 kernel: [  368.572023] 0 pages in swap cache
Dec 30 01:53:36 server01 kernel: [  368.572140] Swap cache stats: add 0, delete 
0, find 0/0
Dec 30 01:53:36 server01 kernel: [  368.572260] Free swap  = 0kB
Dec 30 01:53:36 server01 kernel: [  368.572375] Total swap = 0kB
Dec 30 01:53:36 server01 kernel: [  368.597836] apache2 invoked oom-killer: 
gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0
Dec 30 01:53:36 server01 kernel: [  368.598034] apache2 cpuset=uid 
mems_allowed=0
Dec 30 01:53:36 server01 kernel: [  368.598152] Pid: 5385, comm: apache2 Not 
tainted 3.2.35-grsec #1
Dec 30 01:53:36 server01 kernel: [  368.598273] Call Trace:
Dec 30 01:53:36 server01 kernel: [  368.598396]  [] 
dump_header+0x7e/0x1e0
Dec 30 01:53:36 server01 kernel: [  368.598516]  [] ? 
find_lock_task_mm+0x2f/0x70
Dec 30 01:53:36 server01 kernel: [  368.598638]  [] 
oom_kill_process+0x85/0x2a0
Dec 30 01:53:36 server01 kernel: [  368.598759]  [] 
out_of_memory+0xe5/0x200
Dec 30 01:53:36 server01 kernel: [  368.598880]  [] 
pagefault_out_of_memory+0xbd/0x110
Dec 30 01:53:36 server01 kernel: [  368.599006]  [] 
mm_fault_error+0xb6/0x1a0
Dec 30 01:53:36 server01 kernel: [  368.599127]  [] 
do_page_fault+0x3ee/0x460
Dec 30 01:53:36 server01 kernel: [  368.599250]  [] ? 
mntput+0x1f/0x30
Dec 30 01:53:36 server01 kernel: [  368.599371]  [] ? 
fput+0x156/0x200
Dec 30 01:53:36 server01 kernel: [  368.599496]  [] 
page_fault+0x1f/0x30

This would suggest that an unexpected ENOMEM leaked during page fault
path. I do not see which one could that be because you said THP
(CONFIG_TRANSPARENT_HUGEPAGE) are disabled (and the other patch I have
mentioned in the thread should fix that issue - btw. the patch is
already scheduled for stable tree).
 __do_fault, do_anonymous_page and do_wp_page call
mem_cgroup_newpage_charge with GFP_KERNEL which means that
we do memcg OOM and never return ENOMEM. do_swap_page calls
mem_cgroup_try_charge_swapin with GFP_KERNEL as well.

I might have missed something but I will not get to look closer before
2nd January.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts

[Vasily Kulikov]

On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
> > A related issue which is NOT FIXED HERE is limits for all resources
> > available for containerized pseudo roots.  E.g. I succeeded creating
> > thousands of veth network devices without problems by a non-root user,
> > there seems no limit in number of network devices.  I suspect it is
> > possible to setup routing and net_ns'es the way it will be very
> > time-consuming for kernel to handle IP packets inside of ksoftirq, which
> > is not counted as this user scheduler time.   I suppose the issue is not
> > veth-specific, almost all newly available for unprivileged users code
> > pathes are vulnerable to DoS attacks.
> 
> veth at least should process packets synchronously so I don't see how
> you will get softirq action.

What do you mean -- synchronously?  From my limited understanding of
veth job, it is handled like every network packet in system, via:

veth_xmit() -> dev_forward_skb() -> netif_rx() -> enqueue_to_backlog()

enqueue_to_backlog() adds the packet to softnet_data->input_pkt_queue. 

Then inside of softirq process_backlog() moves ->input_pkt_queue to
->process_queue and calls __netif_receive_skb(), which does all networking
stack magic.

AFAICS, one could create user_ns, net_ns inside of it, and setup routing
tables and netfilter to infinitely pass few network packets from and to
veth, abusing ksoftirq.

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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: 3.7.1 doesn't go to suspend

[Pavel Machek]

On Sun 2012-12-30 13:06:21, Dmitry E. Oboukhov wrote:
> Hi, Linux maintainers!
> 
> First of all sorry for my bad English.
> 
> I have Macbook Pro Retina and used Linux-3.7rc7 with the book.
> It worked fine.
> 
> Today I've tried to migrate to 3.7.1 (from debian repo) and found that
> current kernel can't suspend.
> 
> If I call pm-suspend in my shell, my computer doesn't go to suspend
> and dmesg showes the error:
> 
> [ 2512.960666] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 
> [snd_hda_intel] returns -11
> 
> 
> 3.7rc7 worked fine.
> 
> 
> In attaches You can find some /proc/* files

You may want to rmmod snd_hda_inte before suspend and see if it helps?

Pavel



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

Re: 3.8-rc1 build failure with MIPS/SPARSEMEM

[Kirill A. Shutemov]

On Thu, Dec 27, 2012 at 02:16:07PM +0200, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Dec 26, 2012 at 02:34:35AM +0200, Kirill A. Shutemov wrote:
> > On MIPS if SPARSEMEM is enabled we've got this:
> > 
> > In file included from 
> > /home/kas/git/public/linux/arch/mips/include/asm/pgtable.h:552,
> >  from include/linux/mm.h:44,
> >  from arch/mips/kernel/asm-offsets.c:14:
> > include/asm-generic/pgtable.h: In function ‘my_zero_pfn’:
> > include/asm-generic/pgtable.h:466: error: implicit declaration of function 
> > ‘page_to_section’
> > In file included from arch/mips/kernel/asm-offsets.c:14:
> > include/linux/mm.h: At top level:
> > include/linux/mm.h:738: error: conflicting types for ‘page_to_section’
> > include/asm-generic/pgtable.h:466: note: previous implicit declaration of 
> > ‘page_to_section’ was here
> > 
> > Due header files inter-dependencies, the only way I see to fix it is
> > convert my_zero_pfn() for __HAVE_COLOR_ZERO_PAGE to macros.
> > 
> > Signed-off-by: Kirill A. Shutemov 
> 
> Thanks, this works.
> 
> Tested-by: Aaro Koskinen 

Andrew, could you take the patch?

-- 
 Kirill A. Shutemov


signature.asc
Description: Digital signature

Re: [git pull] drm fixes

[Lucas Stach]

Hello Dave,

Am Sonntag, den 30.12.2012, 04:23 + schrieb Dave Airlie:
> Hi Linus,
> 
[...]
> 
> Lucas Stach (6):
>   drm: tegra: protect DC register access with mutex
 This patch is unnecessary and really shouldn't go in. There
was a brief discussion on the list with the conclusion to disregard this
patch.

Regards,
Lucas

--
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] drivers/platform/x86/thinkpad_acpi.c: Handle HKEY event 0x6040

[Borislav Petkov]

On Sat, Dec 29, 2012 at 10:51:49PM +0100, Richard Hartmann wrote:
> Handle HKEY event generated on AC power change. The current message
> asks users to submit data related to this event which leads to
> a lot of confusion and noise on the mailing list.
> 
> The following is a list affected models and 'Message-Id'
> from ibm-acpi-de...@lists.sourceforge.net of people who saw this
> event when either plugging or unplugging the AC adapter or
> docking or undocking their laptop.
> 
> X120e - caaaujb5v9dhdbdxdvvhnjog4urzc1tgkqeb_zgpay7q8kzh...@mail.gmail.com
> X121e - 20120817143459.gb3...@x1.osrc.amd.com
> X220  - Confirmed by Richard Hartmann
> X220i - 4f406274.7070...@gmail.com
> X220t - 4f489f5b.9040...@cs.tu-berlin.de
> X230  - CAKx4u7kqvVH0-gstomsiVYdGC0i6=bgxzaq8sq9gbg76tgm...@mail.gmail.com
> T420  - 9c848ee30b006737d0534d906bab0...@niklaas-baudet.net
> T420s - 20120608080824.gs25...@hexapodia.org
> W520  - 20121008181050.gf2...@ericlaptop.home.christensenplace.us
> 
> Signed-off-by: Richard Hartmann 

Acked-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.
--
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] um: fix build failure due to mess-up of sig_info protorype

[Richard Weinberger]

Am Sun, 30 Dec 2012 01:37:31 +0300
schrieb Sergei Trofimovich :

> arch/um/os-Linux/signal.c:18:8: error: conflicting types for
> 'sig_info' In file included
> from /home/slyfox/linux-2.6/arch/um/os-Linux/signal.c:12:0:
> arch/um/include/shared/as-layout.h:64:15: note: previous declaration
> of 'sig_info' was here
> 
> Signed-off-by: Sergei Trofimovich 
> CC: Jeff Dike 
> CC: Richard Weinberger 
> CC: "Martin Pärtel" 
> CC: Al Viro 
> CC: user-mode-linux-de...@lists.sourceforge.net
> CC: user-mode-linux-u...@lists.sourceforge.net
> CC: linux-kernel@vger.kernel.org
> ---

I think both patches need to be backported to -stable.
I'll add the tag and push the patches ASAP to Linus.

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

Re: Fwd: PROBLEM: Random kernel panic & system freeze when watching video

[Borislav Petkov]

+ Tony.

On Sun, Dec 30, 2012 at 01:45:40AM +0800, Du Jiulun wrote:
> [1.] One line summary of the problem:
> 
> Random kernel panic and system freeze when watching video on my linux laptop
> 
> [2.] Full description of the problem/report:
> 
> I'm experiencing random (but frequent) kernel panics and system
> freezes without panic information while I'm watching videos using
> SMPlayer or Google Chrome (with Flash plugin).
> 
> This problem has been troubling me since (about) a year ago when I was
> using Ubuntu with 3.2.x kernel.
> 
> I'm not quite sure if I should report to the kernel developers or the
> Intel graphics driver's developers, so if it shouldn't be here, I'm
> really sorry about this.
> 
> [3.] Keywords (i.e., modules, networking, kernel):
> 
> kernel, panic, freeze, video, Intel, h264, flash
> 
> [4.] Kernel version (from /proc/version):
> 
> Linux version 3.6.10-1-ck (xiaodu@xiaodupc) (gcc version 4.7.2 (GCC) )
> #1 SMP PREEMPT Wed Dec 12 15:26:26 CST 2012
> 
> [5.] Output of Oops.. message (if applicable) with symbolic information
>  resolved (see Documentation/oops-tracing.txt)
> 
> [5.1.] Kernel panic information (I read from the photo I taken, but
> I'm not sure if it's completely correct)

Recheck that it is completely correct and then run it through mcelog as
it says above to decode what kind of error you get.

> 
> mce: [Hardware Error]: CPU 2: Machine Check Exception: 4 Bank 2:
> b205
> mce: [Hardware Error]: TSC 6568f53a1cee
> mce: [Hardware Error]: PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC
> 1 microcode c
> mce: [Hardware Error]: Run the above through 'mcelog --ascii'
> mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 2:
> b205
> mce: [Hardware Error]: TSC 6568f53a1cfc
> mce: [Hardware Error]: PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC
> 0 microcode c
> mce: [Hardware Error]: Run the above through 'mcelog --ascii'
> mce: [Hardware Error]: Machine check: Processor context corrupt

this piece until here should suffice.

Leaving in the rest for reference.

> Kernel panic - not syncing: Fatal Machine check
> panic occurred, switching back to text console
> Rebooting in 30 seconds..
> 
> [5.2.] Some other error message I get from "journald" (don't know if
> it's relevant)
> 
> [ cut here ]
> WARNING: at arch/x86/kernel/apic/ipi.c:109
> default_send_IPI_mask_logical+0xb2/0xf0()
> Hardware name: K42Jv
> empty IPI mask
> Modules linked in:
>  hid_generic hidp hid rfcomm btusb fuse ablk_helper cryptd aes_i586
> aes_generic pci_stub vboxpci(O) vboxnetflt(O) vboxne
>  libata sdhci_pci sdhci scsi_mod ehci_hcd mmc_core usbcore usb_common
> Pid: 6456, comm: WorkerPool/6456 Tainted: G   O 3.6.10-1-ck #1
> Call Trace:
>  [] warn_slowpath_common+0x72/0xa0
>  [] ? default_send_IPI_mask_logical+0xb2/0xf0
>  [] ? default_send_IPI_mask_logical+0xb2/0xf0
>  [] warn_slowpath_fmt+0x33/0x40
>  [] default_send_IPI_mask_logical+0xb2/0xf0
>  [] native_send_call_func_ipi+0x45/0x60
>  [] smp_call_function_many+0x172/0x200
>  [] native_flush_tlb_others+0x2b/0x30
>  [] flush_tlb_page+0x5c/0xc0
>  [] ptep_set_access_flags+0x66/0x80
>  [] do_wp_page+0x369/0x8a0
>  [] ? current_fs_time+0x18/0x60
>  [] handle_pte_fault+0x2cf/0xad0
>  [] handle_mm_fault+0x1f5/0x290
>  [] ? fsnotify+0x1e9/0x2d0
>  [] ? spurious_fault+0x114/0x114
>  [] do_page_fault+0x110/0x510
>  [] ? copy_to_user+0x31/0x50
>  [] ? sys_clock_gettime+0x48/0x70
>  [] ? spurious_fault+0x114/0x114
>  [] error_code+0x67/0x6c
>  [] ? schedule_hrtimeout_range_clock+0xab/0x160
>  [] ? schedule_hrtimeout_range_clock+0x30/0x160
> ---[ end trace 61cedb85d35e275f ]---
> 
> [6.] A small shell script or example program which triggers the
>  problem (if possible)
> 
> Just watch some online video with Flash plugin (with Firefox or
> Chrome), or local ones with mplayer, mostly encoded with H.264 (mp4 or
> mkv format).
> 
> [7.] Environment
> [7.1.] Software (add the output of the ver_linux script here)
> 
> Linux xiaodupc 3.6.10-1-ck #1 SMP PREEMPT Wed Dec 12 15:26:26 CST 2012
> i686 GNU/Linux
> 
> Gnu C  4.7.2
> Gnu make   3.82
> binutils   2.23.1
> util-linux 2.22.2
> mount  debug
> module-init-tools  12
> e2fsprogs  1.42.6
> jfsutils   1.1.15
> reiserfsprogs  3.6.21
> xfsprogs   3.1.8
> pcmciautils018
> PPP2.4.5
> Linux C Library2.16
> Dynamic linker (ldd)   2.16
> Linux C++ Library  6.0.17
> Procps 3.3.5
> Net-tools  1.60
> Kbd1.15.3
> Sh-utils   8.20
> wireless-tools 29
> Modules Loaded hid_generic hidp hid fuse ablk_helper cryptd
> aes_i586 aes_generic pci_stub vboxpci vboxnetflt vboxnetadp vboxdrv
> rfcomm bnep btusb joydev bluetooth uvcvideo videobuf2_vmalloc
> videobuf2_memops videobuf2_core videodev media iTCO_wdt
> iTCO_vendor_support 

Re: Fwd: PROBLEM: Random kernel panic system freeze when watching video

[Borislav Petkov]

+ Tony.

On Sun, Dec 30, 2012 at 01:45:40AM +0800, Du Jiulun wrote:
 [1.] One line summary of the problem:
 
 Random kernel panic and system freeze when watching video on my linux laptop
 
 [2.] Full description of the problem/report:
 
 I'm experiencing random (but frequent) kernel panics and system
 freezes without panic information while I'm watching videos using
 SMPlayer or Google Chrome (with Flash plugin).
 
 This problem has been troubling me since (about) a year ago when I was
 using Ubuntu with 3.2.x kernel.
 
 I'm not quite sure if I should report to the kernel developers or the
 Intel graphics driver's developers, so if it shouldn't be here, I'm
 really sorry about this.
 
 [3.] Keywords (i.e., modules, networking, kernel):
 
 kernel, panic, freeze, video, Intel, h264, flash
 
 [4.] Kernel version (from /proc/version):
 
 Linux version 3.6.10-1-ck (xiaodu@xiaodupc) (gcc version 4.7.2 (GCC) )
 #1 SMP PREEMPT Wed Dec 12 15:26:26 CST 2012
 
 [5.] Output of Oops.. message (if applicable) with symbolic information
  resolved (see Documentation/oops-tracing.txt)
 
 [5.1.] Kernel panic information (I read from the photo I taken, but
 I'm not sure if it's completely correct)

Recheck that it is completely correct and then run it through mcelog as
it says above to decode what kind of error you get.

 
 mce: [Hardware Error]: CPU 2: Machine Check Exception: 4 Bank 2:
 b205
 mce: [Hardware Error]: TSC 6568f53a1cee
 mce: [Hardware Error]: PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC
 1 microcode c
 mce: [Hardware Error]: Run the above through 'mcelog --ascii'
 mce: [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 2:
 b205
 mce: [Hardware Error]: TSC 6568f53a1cfc
 mce: [Hardware Error]: PROCESSOR 0:20652 TIME 1356717945 SOCKET 0 APIC
 0 microcode c
 mce: [Hardware Error]: Run the above through 'mcelog --ascii'
 mce: [Hardware Error]: Machine check: Processor context corrupt

this piece until here should suffice.

Leaving in the rest for reference.

 Kernel panic - not syncing: Fatal Machine check
 panic occurred, switching back to text console
 Rebooting in 30 seconds..
 
 [5.2.] Some other error message I get from journald (don't know if
 it's relevant)
 
 [ cut here ]
 WARNING: at arch/x86/kernel/apic/ipi.c:109
 default_send_IPI_mask_logical+0xb2/0xf0()
 Hardware name: K42Jv
 empty IPI mask
 Modules linked in:
  hid_generic hidp hid rfcomm btusb fuse ablk_helper cryptd aes_i586
 aes_generic pci_stub vboxpci(O) vboxnetflt(O) vboxne
  libata sdhci_pci sdhci scsi_mod ehci_hcd mmc_core usbcore usb_common
 Pid: 6456, comm: WorkerPool/6456 Tainted: G   O 3.6.10-1-ck #1
 Call Trace:
  [c103a582] warn_slowpath_common+0x72/0xa0
  [c1025b92] ? default_send_IPI_mask_logical+0xb2/0xf0
  [c1025b92] ? default_send_IPI_mask_logical+0xb2/0xf0
  [c103a653] warn_slowpath_fmt+0x33/0x40
  [c1025b92] default_send_IPI_mask_logical+0xb2/0xf0
  [c1023bf5] native_send_call_func_ipi+0x45/0x60
  [c1084a42] smp_call_function_many+0x172/0x200
  [c1033b1b] native_flush_tlb_others+0x2b/0x30
  [c1033dfc] flush_tlb_page+0x5c/0xc0
  [c1032b76] ptep_set_access_flags+0x66/0x80
  [c1100239] do_wp_page+0x369/0x8a0
  [c1041848] ? current_fs_time+0x18/0x60
  [c1101dff] handle_pte_fault+0x2cf/0xad0
  [c1103665] handle_mm_fault+0x1f5/0x290
  [c11663f9] ? fsnotify+0x1e9/0x2d0
  [c13d4f90] ? spurious_fault+0x114/0x114
  [c13d50a0] do_page_fault+0x110/0x510
  [c11f8971] ? copy_to_user+0x31/0x50
  [c105a468] ? sys_clock_gettime+0x48/0x70
  [c13d4f90] ? spurious_fault+0x114/0x114
  [c13d2bb7] error_code+0x67/0x6c
  [c13d007b] ? schedule_hrtimeout_range_clock+0xab/0x160
  [c13d] ? schedule_hrtimeout_range_clock+0x30/0x160
 ---[ end trace 61cedb85d35e275f ]---
 
 [6.] A small shell script or example program which triggers the
  problem (if possible)
 
 Just watch some online video with Flash plugin (with Firefox or
 Chrome), or local ones with mplayer, mostly encoded with H.264 (mp4 or
 mkv format).
 
 [7.] Environment
 [7.1.] Software (add the output of the ver_linux script here)
 
 Linux xiaodupc 3.6.10-1-ck #1 SMP PREEMPT Wed Dec 12 15:26:26 CST 2012
 i686 GNU/Linux
 
 Gnu C  4.7.2
 Gnu make   3.82
 binutils   2.23.1
 util-linux 2.22.2
 mount  debug
 module-init-tools  12
 e2fsprogs  1.42.6
 jfsutils   1.1.15
 reiserfsprogs  3.6.21
 xfsprogs   3.1.8
 pcmciautils018
 PPP2.4.5
 Linux C Library2.16
 Dynamic linker (ldd)   2.16
 Linux C++ Library  6.0.17
 Procps 3.3.5
 Net-tools  1.60
 Kbd1.15.3
 Sh-utils   8.20
 wireless-tools 29
 Modules Loaded hid_generic hidp hid fuse ablk_helper cryptd
 aes_i586 aes_generic pci_stub vboxpci vboxnetflt vboxnetadp vboxdrv
 rfcomm bnep btusb joydev bluetooth uvcvideo videobuf2_vmalloc
 videobuf2_memops 

Re: [PATCH 2/2] um: fix build failure due to mess-up of sig_info protorype

[Richard Weinberger]

Am Sun, 30 Dec 2012 01:37:31 +0300
schrieb Sergei Trofimovich sly...@gentoo.org:

 arch/um/os-Linux/signal.c:18:8: error: conflicting types for
 'sig_info' In file included
 from /home/slyfox/linux-2.6/arch/um/os-Linux/signal.c:12:0:
 arch/um/include/shared/as-layout.h:64:15: note: previous declaration
 of 'sig_info' was here
 
 Signed-off-by: Sergei Trofimovich sly...@gentoo.org
 CC: Jeff Dike jd...@addtoit.com
 CC: Richard Weinberger rich...@nod.at
 CC: Martin Pärtel martin.par...@gmail.com
 CC: Al Viro v...@zeniv.linux.org.uk
 CC: user-mode-linux-de...@lists.sourceforge.net
 CC: user-mode-linux-u...@lists.sourceforge.net
 CC: linux-kernel@vger.kernel.org
 ---

I think both patches need to be backported to -stable.
I'll add the tag and push the patches ASAP to Linus.

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

Re: [PATCH] drivers/platform/x86/thinkpad_acpi.c: Handle HKEY event 0x6040

[Borislav Petkov]

On Sat, Dec 29, 2012 at 10:51:49PM +0100, Richard Hartmann wrote:
 Handle HKEY event generated on AC power change. The current message
 asks users to submit data related to this event which leads to
 a lot of confusion and noise on the mailing list.
 
 The following is a list affected models and 'Message-Id'
 from ibm-acpi-de...@lists.sourceforge.net of people who saw this
 event when either plugging or unplugging the AC adapter or
 docking or undocking their laptop.
 
 X120e - caaaujb5v9dhdbdxdvvhnjog4urzc1tgkqeb_zgpay7q8kzh...@mail.gmail.com
 X121e - 20120817143459.gb3...@x1.osrc.amd.com
 X220  - Confirmed by Richard Hartmann
 X220i - 4f406274.7070...@gmail.com
 X220t - 4f489f5b.9040...@cs.tu-berlin.de
 X230  - CAKx4u7kqvVH0-gstomsiVYdGC0i6=bgxzaq8sq9gbg76tgm...@mail.gmail.com
 T420  - 9c848ee30b006737d0534d906bab0...@niklaas-baudet.net
 T420s - 20120608080824.gs25...@hexapodia.org
 W520  - 20121008181050.gf2...@ericlaptop.home.christensenplace.us
 
 Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com

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

-- 
Regards/Gruss,
Boris.
--
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: [git pull] drm fixes

[Lucas Stach]

Hello Dave,

Am Sonntag, den 30.12.2012, 04:23 + schrieb Dave Airlie:
 Hi Linus,
 
[...]
 
 Lucas Stach (6):
   drm: tegra: protect DC register access with mutex
 This patch is unnecessary and really shouldn't go in. There
was a brief discussion on the list with the conclusion to disregard this
patch.

Regards,
Lucas

--
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: 3.8-rc1 build failure with MIPS/SPARSEMEM

[Kirill A. Shutemov]

On Thu, Dec 27, 2012 at 02:16:07PM +0200, Aaro Koskinen wrote:
 Hi,
 
 On Wed, Dec 26, 2012 at 02:34:35AM +0200, Kirill A. Shutemov wrote:
  On MIPS if SPARSEMEM is enabled we've got this:
  
  In file included from 
  /home/kas/git/public/linux/arch/mips/include/asm/pgtable.h:552,
   from include/linux/mm.h:44,
   from arch/mips/kernel/asm-offsets.c:14:
  include/asm-generic/pgtable.h: In function ‘my_zero_pfn’:
  include/asm-generic/pgtable.h:466: error: implicit declaration of function 
  ‘page_to_section’
  In file included from arch/mips/kernel/asm-offsets.c:14:
  include/linux/mm.h: At top level:
  include/linux/mm.h:738: error: conflicting types for ‘page_to_section’
  include/asm-generic/pgtable.h:466: note: previous implicit declaration of 
  ‘page_to_section’ was here
  
  Due header files inter-dependencies, the only way I see to fix it is
  convert my_zero_pfn() for __HAVE_COLOR_ZERO_PAGE to macros.
  
  Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
 
 Thanks, this works.
 
 Tested-by: Aaro Koskinen aaro.koski...@iki.fi

Andrew, could you take the patch?

-- 
 Kirill A. Shutemov


signature.asc
Description: Digital signature

Re: 3.7.1 doesn't go to suspend

[Pavel Machek]

On Sun 2012-12-30 13:06:21, Dmitry E. Oboukhov wrote:
 Hi, Linux maintainers!
 
 First of all sorry for my bad English.
 
 I have Macbook Pro Retina and used Linux-3.7rc7 with the book.
 It worked fine.
 
 Today I've tried to migrate to 3.7.1 (from debian repo) and found that
 current kernel can't suspend.
 
 If I call pm-suspend in my shell, my computer doesn't go to suspend
 and dmesg showes the error:
 
 [ 2512.960666] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 
 [snd_hda_intel] returns -11
 
 
 3.7rc7 worked fine.
 
 
 In attaches You can find some /proc/* files

You may want to rmmod snd_hda_inte before suspend and see if it helps?

Pavel



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

Re: [PATCH/RFC] user_ns: fix missing limiting of user_ns counts

[Vasily Kulikov]

On Fri, Dec 28, 2012 at 20:05 -0800, Eric W. Biederman wrote:
  A related issue which is NOT FIXED HERE is limits for all resources
  available for containerized pseudo roots.  E.g. I succeeded creating
  thousands of veth network devices without problems by a non-root user,
  there seems no limit in number of network devices.  I suspect it is
  possible to setup routing and net_ns'es the way it will be very
  time-consuming for kernel to handle IP packets inside of ksoftirq, which
  is not counted as this user scheduler time.   I suppose the issue is not
  veth-specific, almost all newly available for unprivileged users code
  pathes are vulnerable to DoS attacks.
 
 veth at least should process packets synchronously so I don't see how
 you will get softirq action.

What do you mean -- synchronously?  From my limited understanding of
veth job, it is handled like every network packet in system, via:

veth_xmit() - dev_forward_skb() - netif_rx() - enqueue_to_backlog()

enqueue_to_backlog() adds the packet to softnet_data-input_pkt_queue. 

Then inside of softirq process_backlog() moves -input_pkt_queue to
-process_queue and calls __netif_receive_skb(), which does all networking
stack magic.

AFAICS, one could create user_ns, net_ns inside of it, and setup routing
tables and netfilter to infinitely pass few network packets from and to
veth, abusing ksoftirq.

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
--
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 for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked

[Michal Hocko]

On Sun 30-12-12 02:09:47, azurIt wrote:
 which suggests that the patch is incomplete and that I am blind :/
 mem_cgroup_cache_charge calls __mem_cgroup_try_charge for the page cache
 and that one doesn't check GFP_MEMCG_NO_OOM. So you need the following
 follow-up patch on top of the one you already have (which should catch
 all the remaining cases).
 Sorry about that...
 
 
 This was, again, killing my MySQL server (search for (mysqld)):
 http://www.watchdog.sk/lkml/oom_mysqld5

grep Kill process oom_mysqld5 
Dec 30 01:53:34 server01 kernel: [  367.061801] Memory cgroup out of memory: 
Kill process 5512 (apache2) score 716 or sacrifice child
Dec 30 01:53:35 server01 kernel: [  367.338024] Memory cgroup out of memory: 
Kill process 5517 (apache2) score 718 or sacrifice child
Dec 30 01:53:35 server01 kernel: [  367.747888] Memory cgroup out of memory: 
Kill process 5513 (apache2) score 721 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  368.159860] Memory cgroup out of memory: 
Kill process 5516 (apache2) score 726 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  368.665606] Memory cgroup out of memory: 
Kill process 5520 (apache2) score 733 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  368.765652] Out of memory: Kill process 
1778 (mysqld) score 39 or sacrifice child
Dec 30 01:53:36 server01 kernel: [  369.101753] Memory cgroup out of memory: 
Kill process 5519 (apache2) score 754 or sacrifice child
Dec 30 01:53:37 server01 kernel: [  369.464262] Memory cgroup out of memory: 
Kill process 5583 (apache2) score 762 or sacrifice child
Dec 30 01:53:37 server01 kernel: [  369.465017] Out of memory: Kill process 
5506 (apache2) score 18 or sacrifice child
Dec 30 01:53:37 server01 kernel: [  369.574932] Memory cgroup out of memory: 
Kill process 5523 (apache2) score 759 or sacrifice child

So your mysqld has been killed by the global OOM not memcg. But why when
you seem to be perfectly fine regarding memory? I guess the following
backtrace is relevant:
Dec 30 01:53:36 server01 kernel: [  368.569720] DMA: 0*4kB 1*8kB 0*16kB 1*32kB 
2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15912kB
Dec 30 01:53:36 server01 kernel: [  368.570447] DMA32: 9*4kB 10*8kB 8*16kB 
6*32kB 5*64kB 6*128kB 4*256kB 2*512kB 3*1024kB 3*2048kB 613*4096kB = 2523636kB
Dec 30 01:53:36 server01 kernel: [  368.571175] Normal: 5*4kB 2060*8kB 
4122*16kB 2550*32kB 2667*64kB 722*128kB 197*256kB 68*512kB 15*1024kB 4*2048kB 
1855*4096kB = 8134036kB
Dec 30 01:53:36 server01 kernel: [  368.571906] 308964 total pagecache pages
Dec 30 01:53:36 server01 kernel: [  368.572023] 0 pages in swap cache
Dec 30 01:53:36 server01 kernel: [  368.572140] Swap cache stats: add 0, delete 
0, find 0/0
Dec 30 01:53:36 server01 kernel: [  368.572260] Free swap  = 0kB
Dec 30 01:53:36 server01 kernel: [  368.572375] Total swap = 0kB
Dec 30 01:53:36 server01 kernel: [  368.597836] apache2 invoked oom-killer: 
gfp_mask=0x0, order=0, oom_adj=0, oom_score_adj=0
Dec 30 01:53:36 server01 kernel: [  368.598034] apache2 cpuset=uid 
mems_allowed=0
Dec 30 01:53:36 server01 kernel: [  368.598152] Pid: 5385, comm: apache2 Not 
tainted 3.2.35-grsec #1
Dec 30 01:53:36 server01 kernel: [  368.598273] Call Trace:
Dec 30 01:53:36 server01 kernel: [  368.598396]  [810cc89e] 
dump_header+0x7e/0x1e0
Dec 30 01:53:36 server01 kernel: [  368.598516]  [810cc79f] ? 
find_lock_task_mm+0x2f/0x70
Dec 30 01:53:36 server01 kernel: [  368.598638]  [810ccd65] 
oom_kill_process+0x85/0x2a0
Dec 30 01:53:36 server01 kernel: [  368.598759]  [810cd415] 
out_of_memory+0xe5/0x200
Dec 30 01:53:36 server01 kernel: [  368.598880]  [810cd5ed] 
pagefault_out_of_memory+0xbd/0x110
Dec 30 01:53:36 server01 kernel: [  368.599006]  [81026e96] 
mm_fault_error+0xb6/0x1a0
Dec 30 01:53:36 server01 kernel: [  368.599127]  [8102736e] 
do_page_fault+0x3ee/0x460
Dec 30 01:53:36 server01 kernel: [  368.599250]  [81131ccf] ? 
mntput+0x1f/0x30
Dec 30 01:53:36 server01 kernel: [  368.599371]  [811134e6] ? 
fput+0x156/0x200
Dec 30 01:53:36 server01 kernel: [  368.599496]  [815b567f] 
page_fault+0x1f/0x30

This would suggest that an unexpected ENOMEM leaked during page fault
path. I do not see which one could that be because you said THP
(CONFIG_TRANSPARENT_HUGEPAGE) are disabled (and the other patch I have
mentioned in the thread should fix that issue - btw. the patch is
already scheduled for stable tree).
 __do_fault, do_anonymous_page and do_wp_page call
mem_cgroup_newpage_charge with GFP_KERNEL which means that
we do memcg OOM and never return ENOMEM. do_swap_page calls
mem_cgroup_try_charge_swapin with GFP_KERNEL as well.

I might have missed something but I will not get to look closer before
2nd January.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH] hwspinlock/core: Add testing capabilities

[Ido Yariv]

Hi Steve,

On Sat, Dec 29, 2012 at 05:19:08PM +0800, steve.zhan wrote:
 Hi,
 
 It is good idea add this feature.
 
 1: Can we let the ret = hwspin_lock_tests(ops, hwlock); add after
 hwspin_lock_register_single have return
 succeed, that can avoid test duplicated Or error lockid. Of course, If
 this interface is intend to test soc hardware capability only, we can
 put it in the arch module not this core framework. For driver hardware
 sanity check, i would add it after software have register it.

I'd rather not test the spinlocks after they are registering as they
might already be in use by then.

While this feature only verifies the underlying platform implementation,
I think it's best to avoid code duplication and keep it in one place
that will always get called.

 2:Is it possible that interface add configs that choose which locks
 will be test? Because the hwspinlock module is init late in
 postcore_initcall phase, Maybe MACH/ARCH code(for example: code in
 early_initcall) need use private other interfaces to lock some
 hwspinlocks and then register hw locks to hwspinlock framework, Maybe
 some hw locks is in lock status but which test failed.

It was assumed that up to the point where the hw spinlocks are
registered they will not be used, regardless of when this module is
initialized.
If this assumption does not hold for your platform, the simplest
solution would be to set this config option to 'N', as there is no safe
way of verifying spinlocks that are actively being used.

Thanks for reviewing this,
Ido.
--
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: 3.7.1 doesn't go to suspend

[Dmitry E. Oboukhov]

 Hi, Linux maintainers!
 
 First of all sorry for my bad English.
 
 I have Macbook Pro Retina and used Linux-3.7rc7 with the book.
 It worked fine.
 
 Today I've tried to migrate to 3.7.1 (from debian repo) and found that
 current kernel can't suspend.
 
 If I call pm-suspend in my shell, my computer doesn't go to suspend
 and dmesg showes the error:
 
 [ 2512.960666] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37 
 [snd_hda_intel] returns -11
 
 
 3.7rc7 worked fine.
 
 
 In attaches You can find some /proc/* files

 You may want to rmmod snd_hda_inte before suspend and see if it helps?

Hi!
After rmmodding snd_hda_intel pm-suspend doesn't work yet.

nb:[~]$ sudo rmmod snd_hda_intel 
nb:[~]$ sudo rmmod snd_hda_codec_cirrus snd_hda_codec_hdmi
snd_hda_codec
nb:[~]$ sudo rmmod snd_timer 
Error: Module snd_timer is in use by: snd_pcm snd_seq
nb:[~]$ sudo rmmod snd_pcm snd_seq snd_timer 
nb:[~]$ sudo rmmod snd_seq_device 
nb:[~]$ sudo rmmod snd_hwdep 
nb:[~]$ sudo rmmod snd_page_alloc 
nb:[~]$ sudo pm-suspend
nb:[~]$ dmesg|tail
[   30.266443] wlan0: associated
[   30.266463] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes
ready
[   30.342137] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11
[   30.352607] lp: driver loaded but no devices found
[   30.358793] ppdev: user-space parallel port driver
[   30.425092] nouveau W[  PGRAPH][:01:00.0] disabled, PGRAPH=1 to
enable
[   30.778659] bcm5974: bad trackpad package, length: 8
[   32.490108] input: Mouseemu virtual keyboard as
/devices/virtual/input/input19
[   32.490441] input: Mouseemu virtual mouse as
/devices/virtual/input/input20
[   65.112500] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11



Also dmesg complains about the modules until booting process is done:
nb:[~]$ dmesg|grep suspend
[   26.331831] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11
[   30.342137] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11
[   65.112500] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11




3.7rc7 works fine.

PPS: I've just rebooted into 3.7rc7.
its dmesg complains while booting, too:

nb:[~]$ dmesg|grep suspend
[   31.759388] pci_pm_runtime_suspend(): azx_runtime_suspend+0x0/0x37
[snd_hda_intel] returns -11

but it complains once and then it suspends/wakeups/plays sounds fine
:)



-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: [git pull] drm fixes

[Dave Airlie]

On Sun, Dec 30, 2012 at 8:09 PM, Lucas Stach d...@lynxeye.de wrote:
 Hello Dave,

 Am Sonntag, den 30.12.2012, 04:23 + schrieb Dave Airlie:
 Hi Linus,

 [...]

 Lucas Stach (6):
   drm: tegra: protect DC register access with mutex
  This patch is unnecessary and really shouldn't go in. There
 was a brief discussion on the list with the conclusion to disregard this
 patch.

Linus, I just reverted it on top, didn't want to cause a rebase on  that branch,

updated pull req.

The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:

  Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to d5757dbe79870d825d0dec30074d48683e1d7e9a:

  Revert drm: tegra: protect DC register access with mutex
(2012-12-30 21:58:20 +1000)


Alex Deucher (1):
  drm/radeon: add WAIT_UNTIL to evergreen VM safe reg list

Ben Skeggs (8):
  drm/nouveau: initial support for GK106
  drm/nouveau/bios: update gpio parsing apis to match current design
  drm/nouveau/bios: implement opcode 0xa9
  drm/nouveau/bios: parse/display extra version component
  drm/nouveau/mxm: silence output if no bios data
  drm/nouveau/bios: cache ramcfg strap on later chipsets
  drm/nvc0/graph: fix fuc, and enable acceleration on GF119
  drm/nve0/graph: fix fuc, and enable acceleration on all known chipsets

Chris Wilson (6):
  drm/i915: Fixup cursor latency used for IVB lp3 watermarks
  drm/i915: Double the cursor self-refresh latency on Valleyview
  drm/i915: Clear self-refresh watermarks when disabled
  drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM
computations
  drm: Export routines for inserting preallocated nodes into the mm manager
  drm/i915: Preallocate the drm_mm_node prior to manipulating the
GTT drm_mm manager

Daniel Vetter (6):
  drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
  drm/i915: Implement WaSetupGtModeTdRowDispatch
  drm/i915: Implement workaround for broken CS tlb on i830/845
  drm/i915: don't disable disconnected outputs
  drm/i915: optionally disable shrinker lock stealing
  drm/i915: disable shrinker lock stealing for create_mmap_offset

Dave Airlie (5):
  drm/i915: fix flags in dma buf exporting
  Merge branch 'drm-nouveau-fixes-3.8' of
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
  Merge branch 'drm-fixes-3.8' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next
  Revert drm: tegra: protect DC register access with mutex

Jerome Glisse (4):
  drm/radeon: don't leave fence blocked process on failed GPU reset
  drm/radeon: avoid deadlock in pm path when waiting for fence
  drm/radeon: restore modeset late in GPU reset path
  drm/radeon: add support for MEM_WRITE packet

Krzysztof Mazur (1):
  i915: ensure that VGA plane is disabled

Lucas Stach (6):
  drm: tegra: fix front_porch - back_porch mixup
  drm: tegra: don't leave clients host1x member uninitialized
  drm: tegra: protect DC register access with mutex
  drm: tegra: remove redundant tegra2_tmds_config entry
  drm: tegra: clean out old gem prototypes
  drm: tegra: program only one window during modeset

 drivers/gpu/drm/drm_mm.c   |  41 --
 drivers/gpu/drm/i915/i915_dma.c|   3 +
 drivers/gpu/drm/i915/i915_drv.h|   8 ++
 drivers/gpu/drm/i915/i915_gem.c|  77 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |   2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +
 drivers/gpu/drm/i915/i915_irq.c|  12 ++
 drivers/gpu/drm/i915/i915_reg.h|   4 +-
 drivers/gpu/drm/i915/intel_display.c   |  23 ++-
 drivers/gpu/drm/i915/intel_pm.c| 160 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c|  76 --
 drivers/gpu/drm/i915/intel_ringbuffer.h|   1 +
 .../drm/nouveau/core/engine/graph/fuc/gpcnve0.fuc  |   5 +
 .../nouveau/core/engine/graph/fuc/gpcnve0.fuc.h|  17 ++-
 .../drm/nouveau/core/engine/graph/fuc/hubnvc0.fuc  |  10 ++
 .../nouveau/core/engine/graph/fuc/hubnvc0.fuc.h| 147 +--
 .../drm/nouveau/core/engine/graph/fuc/hubnve0.fuc  |  13 ++
 .../nouveau/core/engine/graph/fuc/hubnve0.fuc.h| 157 ++--
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c   |  11 +-
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |   1 +
 drivers/gpu/drm/nouveau/core/engine/graph/nve0.c   |   3 +-
 drivers/gpu/drm/nouveau/core/include/subdev/bios.h |   1 +
 .../drm/nouveau/core/include/subdev/bios/gpio.h|   8 +-
 

Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails

[Ben Hutchings]

On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote:
 Ben Hutchings wrote:
  3.2-stable review patch.  If anyone has any objections, please let me know.
  
  --
  
  From: Andreas Hartmann andihartm...@01019freenet.de
  
  commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.
 
 [...]
 
 This patch is a workaround for
 
 mac80211: retry sending failed BAR frames later instead of tearing down
 aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html -
 f0425beda4d404a6e751439b562100b902ba9c98)
 See:
 http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
 
 
 Meanwhile there was a bug report complaining about problems with
 be03d4a45 when used as STA:
 http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
 You can find there a few other workaround proposals.
[...]

OK, I'll drop this for now.  Once this is sorted out, please send to
stable a complete list of fixes that are needed.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Re: [ 104/173] rt2x00: Dont let mac80211 send a BAR when an AMPDU subframe fails

[Ben Hutchings]

On Sun, 2012-12-30 at 13:38 +0100, Ben Hutchings wrote:
 On Sat, 2012-12-29 at 09:04 +0100, Andreas Hartmann wrote:
  Ben Hutchings wrote:
   3.2-stable review patch.  If anyone has any objections, please let me 
   know.
   
   --
   
   From: Andreas Hartmann andihartm...@01019freenet.de
   
   commit be03d4a45c09ee5100d3aaaedd087f19bc20d01f upstream.
  
  [...]
  
  This patch is a workaround for
  
  mac80211: retry sending failed BAR frames later instead of tearing down
  aggr (http://www.spinics.net/lists/linux-wireless/msg76379.html -
  f0425beda4d404a6e751439b562100b902ba9c98)
  See:
  http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
  
  
  Meanwhile there was a bug report complaining about problems with
  be03d4a45 when used as STA:
  http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/1257
  You can find there a few other workaround proposals.
 [...]
 
 OK, I'll drop this for now.  Once this is sorted out, please send to
 stable a complete list of fixes that are needed.

To be clear, I have all of these in the queue:

be03d4a45c09 rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails
5b632fe85ec8 mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL
ab9d6e4ffe19 Revert: rt2x00: Don't let mac80211 send a BAR when an AMPDU 
subframe fails

and I'm intending to drop/defer them all.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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