[PATCH] checkpatch: Add for_each tests to indentation and brace tests

[Joe Perches]

All the various for_each loop macros were not tested for
trailing brace on the following lines and for bad indentation.

Add them.

Reported-by: Greg KH 
Signed-off-by: Joe Perches 
---
On Sat, 2014-07-12 at 16:08 -0700, Greg KH wrote:
> The following function:
> 
> $ cat foo.c 
> 
> static int foo_init(void)
> {
> 
>   list_for_each_entry(foo, , list)
>   {
>   do_something_foo(foo);
>   }
> 
>   return 0;
> }
> 
> Will not be caught by checkpatch:
> 
> $ ./scripts/checkpatch.pl --file foo.c 
> total: 0 errors, 0 warnings, 11 lines checked
> 
> foo.c has no obvious style problems and is ready for submission.

 scripts/checkpatch.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d5ac001..5efbf50 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2698,7 +2698,7 @@ sub process {
 
 # if/while/etc brace do not go on next line, unless defining a do while loop,
 # or if that brace on the next line is for something else
-   if ($line =~ /(.*)\b((?:if|while|for|switch)\s*\(|do\b|else\b)/ 
&& $line !~ /^.\s*\#/) {
+   if ($line =~ 
/(.*)\b((?:if|while|for|switch|(?:[a-z_]+|)for_each[a-z_]+)\s*\(|do\b|else\b)/ 
&& $line !~ /^.\s*\#/) {
my $pre_ctx = "$1$2";
 
my ($level, @ctx) = ctx_statement_level($linenr, 
$realcnt, 0);
@@ -2744,7 +2744,7 @@ sub process {
}
 
 # Check relative indent for conditionals and blocks.
-   if ($line =~ /\b(?:(?:if|while|for)\s*\(|do\b)/ && $line !~ 
/^.\s*#/ && $line !~ /\}\s*while\s*/) {
+   if ($line =~ 
/\b(?:(?:if|while|for|(?:[a-z_]+|)for_each[a-z_]+)\s*\(|do\b)/ && $line !~ 
/^.\s*#/ && $line !~ /\}\s*while\s*/) {
($stat, $cond, $line_nr_next, $remain_next, $off_next) =
ctx_statement_block($linenr, $realcnt, 0)
if (!defined $stat);


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

[PULL REQUEST] slave dmaenegine fixes

[Vinod Koul]

Hi Linus,

Here is the fixes pull request for 3.16. We have two small fixes. First one from
Daniel to handle 0-length packets for usb cppi dma. Second by Russell for
imx-sdam cyclic residue reporting

The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
  Linus Torvalds (1):
Linux 3.16-rc3

are available in the git repository at:

  git://git.infradead.org/users/vkoul/slave-dma.git fixes

Daniel Mack (1):
  dma: cppi41: handle 0-length packets

Russell King - ARM Linux (1):
  Update imx-sdma cyclic handling to report residue

 drivers/dma/cppi41.c|   13 ++---
 drivers/dma/imx-sdma.c  |   22 ++
 sound/soc/fsl/imx-pcm-dma.c |1 -
 3 files changed, 28 insertions(+), 8 deletions(-)

-- 
Thanks
~Vinod


signature.asc
Description: Digital signature

Re: [GIT PULL] at91: dt for 3.17 #1

[Olof Johansson]

On Wed, Jul 09, 2014 at 07:29:39PM +0200, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> This is a big pull-request concerning DT on AT91. The bulk of it is the move 
> of
> the remaining SoCs to CCF. Some fixes and little additions are also included.
> Alexandre's work were taken as a pull-request: as it is my first one,
> please tell me if I did the inclusion correctly.

Looks good, you might want to ask him to write better tag descriptions though,
or fill them in a bit yourself when you do the merge.

> Thanks, best regards,
> 
> The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> 
>   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-dt
> 
> for you to fetch changes up to bf4d997ab890c2e32f3db390bec29fdd382da174:
> 
>   Merge tag 'CCF-for-3.17' of git://github.com/at91linux/linux-at91 into 
> at91-3.17-dt (2014-07-09 19:14:31 +0200)
> 
> 
> 
> First DT update for 3.17:
> - move of crystals DT definitions to the /clocks node
> - addition of clock entries for sound for CCF enabled platforms
> - addition of DMA and DMA + nand on at91sam9rl
> - move to CCF for all not-converted-yet AT91 SoCs: at91rm9200, 
> at91sam9260/9g20,
>   at91sam9g45 family and at91sam9263

Merged, thanks!


-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: [GIT PULL] at91: drivers for 3.17 #1

[Olof Johansson]

On Wed, Jul 09, 2014 at 06:53:57PM +0200, Nicolas Ferre wrote:
> Arnd, Olof, Kevin,
> 
> This update delayed to 3.17, is about replacing the existing calls to the
> older, non-standard drivers by the use of the newer "pwm-atmel" which takes
> advantage of the PWM framework.
> All concerned maintainer gave their acknowledgement to the relevant patches.
> At the end, it removes three obsolete drivers and the diffstat looks pretty
> nice as well.
> 
> Thanks, best regards,
> 
> The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> 
>   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> 
> are available in the git repository at:
> 
>   git://github.com/at91linux/linux-at91.git tags/at91-drivers
> 
> for you to fetch changes up to f2a70e1fc1ccc0fcdf4ad12db7382134228fb552:
> 
>   misc: atmel_pwm: remove obsolete driver (2014-07-09 15:14:35 +0200)
> 
> 
> Atmel PWM driver update for 3.17
> - move to the new PWM driver which uses PWM framework
> - remove 3 obsolete drivers (atmel-pwm-bl.c, leds-atmel-pwm.c and atmel_pwm.c)
> 

Merged, thanks!


-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: linux-next: Tree for Jul 11

[Nick Krause]

On Sat, Jul 12, 2014 at 6:26 PM, Nick Krause  wrote:
> On Fri, Jul 11, 2014 at 3:18 AM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> Changes since 20140710:
>>
>> My fixes tree contains:
>> powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
>>
>> The tty.current tree gained a build failure so I used the version from
>> next-20140710.
>>
>> The irqchip tree gained a conflict against the arm64 tree.
>>
>> The staging tree lost its build failure and gained a conflict against
>> the tty tree.
>>
>> Non-merge commits (relative to Linus' tree): 5114
>>  4474 files changed, 191199 insertions(+), 226003 deletions(-)
>>
>> 
>>
>> I have created today's linux-next tree at
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
>> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
>> are tracking the linux-next tree using git, you should not use "git pull"
>> to do so as that will try to merge the new linux-next release with the
>> old one.  You should use "git fetch" and checkout or reset to the new
>> master.
>>
>> You can see which trees have been included by looking in the Next/Trees
>> file in the source.  There are also quilt-import.log and merge.log files
>> in the Next directory.  Between each merge, the tree was built with
>> a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
>> multi_v7_defconfig for arm. After the final fixups (if any), it is also
>> built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
>> allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
>> defconfig.
>>
>> Below is a summary of the state of the merge.
>>
>> I am currently merging 222 trees (counting Linus' and 30 trees of patches
>> pending for Linus' tree).
>>
>> Stats about the size of the tree over time can be seen at
>> http://neuling.org/linux-next-size.html .
>>
>> Status of my local build tests will be at
>> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
>> advice about cross compilers/configs that work, we are always open to add
>> more builds.
>>
>> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
>> Gortmaker for triage and bug fixes.
>>
>> --
>> Cheers,
>> Stephen Rothwells...@canb.auug.org.au
>>

> I am been trying your tests for a while. Seems most of your failing
> tests work for me.
> Can you test a newer compiler in the 4.8 release series for gcc to see
> if this fixes your
> issues.
> Cheers Nick
I am also attaching logs of build I have that are succeeding to help
you.Furthermore I run the builds in two steps listed below using
compilers for
Ubuntu 14.04 and Fedora 20 turned into dpkgs to work with Debian
distros.Below are the steps.
1. make ARCH=x y_defconfig
2.ARCH= x CROSS_COMPILE=z make -j 8 2> error_file
x = cpu architecture  I am building
y=configuration I am building
z= gcc I am builds this architecture
error_file = file I am tracing errors and warnings to send if build
fails to maintainers of that architecture
If you have any other questions please ask me.
Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/83] AMD HSA kernel driver

[Jerome Glisse]

On Sat, Jul 12, 2014 at 09:55:49PM +, Gabbay, Oded wrote:
> On Fri, 2014-07-11 at 17:18 -0400, Jerome Glisse wrote:
> > On Thu, Jul 10, 2014 at 10:51:29PM +, Gabbay, Oded wrote:
> > >  On Thu, 2014-07-10 at 18:24 -0400, Jerome Glisse wrote:
> > > >  On Fri, Jul 11, 2014 at 12:45:27AM +0300, Oded Gabbay wrote:
> > > > >   This patch set implements a Heterogeneous System Architecture
> > > > >  (HSA) driver
> > > > >   for radeon-family GPUs.
> > > >  This is just quick comments on few things. Given size of this, 
> > > > people
> > > >  will need to have time to review things.
> > > > >   HSA allows different processor types (CPUs, DSPs, GPUs, 
> > > > > etc..) to
> > > > >  share
> > > > >   system resources more effectively via HW features including
> > > > >  shared pageable
> > > > >   memory, userspace-accessible work queues, and platform-level
> > > > >  atomics. In
> > > > >   addition to the memory protection mechanisms in GPUVM and
> > > > >  IOMMUv2, the Sea
> > > > >   Islands family of GPUs also performs HW-level validation of
> > > > >  commands passed
> > > > >   in through the queues (aka rings).
> > > > >   The code in this patch set is intended to serve both as a 
> > > > > sample
> > > > >  driver for
> > > > >   other HSA-compatible hardware devices and as a production 
> > > > > driver
> > > > >  for
> > > > >   radeon-family processors. The code is architected to support
> > > > >  multiple CPUs
> > > > >   each with connected GPUs, although the current implementation
> > > > >  focuses on a
> > > > >   single Kaveri/Berlin APU, and works alongside the existing 
> > > > > radeon
> > > > >  kernel
> > > > >   graphics driver (kgd).
> > > > >   AMD GPUs designed for use with HSA (Sea Islands and up) share
> > > > >  some hardware
> > > > >   functionality between HSA compute and regular gfx/compute 
> > > > > (memory,
> > > > >   interrupts, registers), while other functionality has been 
> > > > > added
> > > > >   specifically for HSA compute  (hw scheduler for virtualized
> > > > >  compute rings).
> > > > >   All shared hardware is owned by the radeon graphics driver, 
> > > > > and
> > > > >  an interface
> > > > >   between kfd and kgd allows the kfd to make use of those 
> > > > > shared
> > > > >  resources,
> > > > >   while HSA-specific functionality is managed directly by kfd 
> > > > > by
> > > > >  submitting
> > > > >   packets into an HSA-specific command queue (the "HIQ").
> > > > >   During kfd module initialization a char device node 
> > > > > (/dev/kfd) is
> > > > >  created
> > > > >   (surviving until module exit), with ioctls for queue 
> > > > > creation &
> > > > >  management,
> > > > >   and data structures are initialized for managing HSA device
> > > > >  topology.
> > > > >   The rest of the initialization is driven by calls from the 
> > > > > radeon
> > > > >  kgd at
> > > > >   the following points :
> > > > >   - radeon_init (kfd_init)
> > > > >   - radeon_exit (kfd_fini)
> > > > >   - radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
> > > > >   - radeon_driver_unload_kms (kfd_device_fini)
> > > > >   During the probe and init processing per-device data 
> > > > > structures
> > > > >  are
> > > > >   established which connect to the associated graphics kernel
> > > > >  driver. This
> > > > >   information is exposed to userspace via sysfs, along with a
> > > > >  version number
> > > > >   allowing userspace to determine if a topology change has 
> > > > > occurred
> > > > >  while it
> > > > >   was reading from sysfs.
> > > > >   The interface between kfd and kgd also allows the kfd to 
> > > > > request
> > > > >  buffer
> > > > >   management services from kgd, and allows kgd to route 
> > > > > interrupt
> > > > >  requests to
> > > > >   kfd code since the interrupt block is shared between regular
> > > > >   graphics/compute and HSA compute subsystems in the GPU.
> > > > >   The kfd code works with an open source usermode library
> > > > >  ("libhsakmt") which
> > > > >   is in the final stages of IP review and should be published 
> > > > > in a
> > > > >  separate
> > > > >   repo over the next few days.
> > > > >   The code operates in one of three modes, selectable via the
> > > > >  sched_policy
> > > > >   module parameter :
> > > > >   - sched_policy=0 uses a hardware scheduler running in the MEC
> > > > >  block within
> > > > >   CP, and allows oversubscription (more queues than HW slots)
> > > > >   - sched_policy=1 also uses HW scheduling but does not allow
> > > > >   oversubscription, so create_queue requests fail when we run 
> > > > > out
> > > > >  of HW slots
> > > > >   - sched_policy=2 does not use HW scheduling, so the driver
> > > > >  manually assigns
> > > > >   queues to HW slots by programming registers
> > > > >   The "no HW scheduling" option is for debug & new hardware 
> > > > > bringup
> > > > >  only, so
> > > > >   has less test coverage than the other options. Default in the
> > > > >  current 

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Marek Vasut]

On Sunday, July 13, 2014 at 05:07:10 AM, Chen Gang wrote:
> Several drivers need 'devm_ioremap_resource' which need HAS_IOMEM enabled.
> So let them depend on HAS_IOMEM.
> 
> The related error (with allmodconfig under score):
> 
> MODPOST 1365 modules
>   ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
>   ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko]
> undefined! ERROR: "devm_ioremap_resource"
> [drivers/staging/iio/adc/mxs-lradc.ko] undefined! ERROR:
> "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined! ERROR:
> "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
> ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!

This stuff should go through different trees, so I'd suggest to split this into 
multiple patches. Thanks for catching this stuff !

Best regards,
Marek Vasut
--
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: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

After this last patch, score architecture can pass allmodconfig. :-)

And also find a compiler issue, I will try to fix it, but shall not notify
kernel mailing list, again. The related issue is below (it seems a kernel
issue, but in fact, it is a compiler's issue):

CC [M]  drivers/staging/lustre/lustre/ptlrpc/sec.o
  drivers/staging/lustre/lustre/ptlrpc/sec.c: In function 
'sptlrpc_cli_ctx_expire':
  drivers/staging/lustre/lustre/ptlrpc/sec.c:309:13: error: 'struct 
ptlrpc_ctx_ops' has no member named '__die'
ctx->cc_ops->die(ctx, 0);
   ^
  drivers/staging/lustre/lustre/ptlrpc/sec.c: In function 'ctx_refresh_timeout':
  drivers/staging/lustre/lustre/ptlrpc/sec.c:594:26: error: 'struct 
ptlrpc_ctx_ops' has no member named '__die'
 req->rq_cli_ctx->cc_ops->die(req->rq_cli_ctx, 0);
^
  make[5]: *** [drivers/staging/lustre/lustre/ptlrpc/sec.o] Error 1
  make[4]: *** [drivers/staging/lustre/lustre/ptlrpc] Error 2
  make[3]: *** [drivers/staging/lustre/lustre] Error 2
  make[2]: *** [drivers/staging/lustre] Error 2
  make[1]: *** [drivers/staging] Error 2
  make: *** [drivers] Error 2

Thanks.

On 07/13/2014 11:07 AM, Chen Gang wrote:
> Several drivers need 'devm_ioremap_resource' which need HAS_IOMEM enabled.
> So let them depend on HAS_IOMEM.
> 
> The related error (with allmodconfig under score):
> 
> MODPOST 1365 modules
>   ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
>   ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] 
> undefined!
>   ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko] 
> undefined!
>   ERROR: "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined!
>   ERROR: "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
>   ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!
> 
> 
> Signed-off-by: Chen Gang 
> ---
>  drivers/input/serio/Kconfig | 3 ++-
>  drivers/pwm/Kconfig | 2 +-
>  drivers/staging/iio/adc/Kconfig | 2 +-
>  drivers/watchdog/Kconfig| 3 ++-
>  4 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index bc2d474..449d45f 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -244,6 +244,7 @@ config SERIO_PS2MULT
>  
>  config SERIO_ARC_PS2
>   tristate "ARC PS/2 support"
> + depends on HAS_IOMEM
>   help
> Say Y here if you have an ARC FPGA platform with a PS/2
> controller in it.
> @@ -263,7 +264,7 @@ config SERIO_APBPS2
>  
>  config SERIO_OLPC_APSP
>   tristate "OLPC AP-SP input support"
> - depends on OLPC || COMPILE_TEST
> + depends on (OLPC || COMPILE_TEST) && HAS_IOMEM
>   help
> Say Y here if you want support for the keyboard and touchpad included
> in the OLPC XO-1.75 and XO-4 laptops.
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 4ad7b89..2faf5ce 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -82,7 +82,7 @@ config PWM_BFIN
>  
>  config PWM_CLPS711X
>   tristate "CLPS711X PWM support"
> - depends on ARCH_CLPS711X || COMPILE_TEST
> + depends on (ARCH_CLPS711X || COMPILE_TEST) && HAS_IOMEM
>   help
> Generic PWM framework driver for Cirrus Logic CLPS711X.
>  
> diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
> index b87e382..4e927d2 100644
> --- a/drivers/staging/iio/adc/Kconfig
> +++ b/drivers/staging/iio/adc/Kconfig
> @@ -94,7 +94,7 @@ config LPC32XX_ADC
>  
>  config MXS_LRADC
>   tristate "Freescale i.MX23/i.MX28 LRADC"
> - depends on ARCH_MXS || COMPILE_TEST
> + depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
>   depends on INPUT
>   select STMP_DEVICE
>   select IIO_BUFFER
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 76dd541..0e4abb2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -113,6 +113,7 @@ config WM8350_WATCHDOG
>  
>  config XILINX_WATCHDOG
>   tristate "Xilinx Watchdog timer"
> + depends on HAS_IOMEM
>   select WATCHDOG_CORE
>   help
> Watchdog driver for the xps_timebase_wdt ip core.
> @@ -434,7 +435,7 @@ config SIRFSOC_WATCHDOG
>  
>  config TEGRA_WATCHDOG
>   tristate "Tegra watchdog"
> - depends on ARCH_TEGRA || COMPILE_TEST
> + depends on (ARCH_TEGRA || COMPILE_TEST) && HAS_IOMEM
>   select WATCHDOG_CORE
>   help
> Say Y here to include support for the watchdog timer
> 


-- 
Chen Gang

Open share and attitude like air water and life which God blessed
--
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: checkpatch.pl misses list_for_each_entry() coding style issues

[Joe Perches]

On Sat, 2014-07-12 at 16:08 -0700, Greg KH wrote:
> static int foo_init(void)
> {
> 
>   list_for_each_entry(foo, , list)
>   {
>   do_something_foo(foo);
>   }
> 
>   return 0;
> }
> 
> Will not be caught by checkpatch:
> 
> $ ./scripts/checkpatch.pl --file foo.c 
> total: 0 errors, 0 warnings, 11 lines checked
> 
> foo.c has no obvious style problems and is ready for submission.
> 
> 
> Any way to fix that up?

Probably.  Right now it only works on for/do tests.
It should probably also work on all functions.

I'll play with it.

--
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] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Chen Gang]

Several drivers need 'devm_ioremap_resource' which need HAS_IOMEM enabled.
So let them depend on HAS_IOMEM.

The related error (with allmodconfig under score):

MODPOST 1365 modules
  ERROR: "devm_ioremap_resource" [drivers/watchdog/tegra_wdt.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/watchdog/of_xilinx_wdt.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/staging/iio/adc/mxs-lradc.ko] 
undefined!
  ERROR: "devm_ioremap_resource" [drivers/pwm/pwm-clps711x.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/input/serio/olpc_apsp.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/input/serio/arc_ps2.ko] undefined!


Signed-off-by: Chen Gang 
---
 drivers/input/serio/Kconfig | 3 ++-
 drivers/pwm/Kconfig | 2 +-
 drivers/staging/iio/adc/Kconfig | 2 +-
 drivers/watchdog/Kconfig| 3 ++-
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index bc2d474..449d45f 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -244,6 +244,7 @@ config SERIO_PS2MULT
 
 config SERIO_ARC_PS2
tristate "ARC PS/2 support"
+   depends on HAS_IOMEM
help
  Say Y here if you have an ARC FPGA platform with a PS/2
  controller in it.
@@ -263,7 +264,7 @@ config SERIO_APBPS2
 
 config SERIO_OLPC_APSP
tristate "OLPC AP-SP input support"
-   depends on OLPC || COMPILE_TEST
+   depends on (OLPC || COMPILE_TEST) && HAS_IOMEM
help
  Say Y here if you want support for the keyboard and touchpad included
  in the OLPC XO-1.75 and XO-4 laptops.
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 4ad7b89..2faf5ce 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -82,7 +82,7 @@ config PWM_BFIN
 
 config PWM_CLPS711X
tristate "CLPS711X PWM support"
-   depends on ARCH_CLPS711X || COMPILE_TEST
+   depends on (ARCH_CLPS711X || COMPILE_TEST) && HAS_IOMEM
help
  Generic PWM framework driver for Cirrus Logic CLPS711X.
 
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index b87e382..4e927d2 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -94,7 +94,7 @@ config LPC32XX_ADC
 
 config MXS_LRADC
tristate "Freescale i.MX23/i.MX28 LRADC"
-   depends on ARCH_MXS || COMPILE_TEST
+   depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
depends on INPUT
select STMP_DEVICE
select IIO_BUFFER
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd541..0e4abb2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -113,6 +113,7 @@ config WM8350_WATCHDOG
 
 config XILINX_WATCHDOG
tristate "Xilinx Watchdog timer"
+   depends on HAS_IOMEM
select WATCHDOG_CORE
help
  Watchdog driver for the xps_timebase_wdt ip core.
@@ -434,7 +435,7 @@ config SIRFSOC_WATCHDOG
 
 config TEGRA_WATCHDOG
tristate "Tegra watchdog"
-   depends on ARCH_TEGRA || COMPILE_TEST
+   depends on (ARCH_TEGRA || COMPILE_TEST) && HAS_IOMEM
select WATCHDOG_CORE
help
  Say Y here to include support for the watchdog timer
-- 
1.7.11.7
--
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] drivers: firewire: Let several sub-modules depend on HAS_DMA

[Chen Gang]

Several sub-modules of 'firewire' need HAS_DMA, so let them depend on it.
FIREWIRE_NET and FIREWIRE_OHCI use 'core-iso.c' which also needs HAS_DMA,
so need 'ifdef' the related function by CONFIG_HAS_DMA in 'core-iso.c'.

The related error (with allmodconfig under score):

MODPOST 1365 modules
  ERROR: "dma_mapping_error" [drivers/firewire/firewire-sbp2.ko] undefined!
  ERROR: "dma_map_single" [drivers/firewire/firewire-sbp2.ko] undefined!
  ERROR: "dma_unmap_single" [drivers/firewire/firewire-sbp2.ko] undefined!
  ERROR: "scsi_dma_map" [drivers/firewire/firewire-sbp2.ko] undefined!
  ERROR: "scsi_dma_unmap" [drivers/firewire/firewire-sbp2.ko] undefined!
  ERROR: "dma_mapping_error" [drivers/firewire/firewire-core.ko] undefined!
  ERROR: "dma_map_page" [drivers/firewire/firewire-core.ko] undefined!
  ERROR: "dma_unmap_page" [drivers/firewire/firewire-core.ko] undefined!

Signed-off-by: Chen Gang 
---
 drivers/firewire/Kconfig|  6 +++---
 drivers/firewire/core-iso.c | 15 +++
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/firewire/Kconfig b/drivers/firewire/Kconfig
index 4199849..fd75278 100644
--- a/drivers/firewire/Kconfig
+++ b/drivers/firewire/Kconfig
@@ -19,7 +19,7 @@ config FIREWIRE
 
 config FIREWIRE_OHCI
tristate "OHCI-1394 controllers"
-   depends on PCI && FIREWIRE && MMU
+   depends on PCI && FIREWIRE && MMU && HAS_DMA
help
  Enable this driver if you have a FireWire controller based
  on the OHCI specification.  For all practical purposes, this
@@ -30,7 +30,7 @@ config FIREWIRE_OHCI
 
 config FIREWIRE_SBP2
tristate "Storage devices (SBP-2 protocol)"
-   depends on FIREWIRE && SCSI
+   depends on FIREWIRE && SCSI && HAS_DMA
help
  This option enables you to use SBP-2 devices connected to a
  FireWire bus.  SBP-2 devices include storage devices like
@@ -45,7 +45,7 @@ config FIREWIRE_SBP2
 
 config FIREWIRE_NET
tristate "IP networking over 1394"
-   depends on FIREWIRE && INET
+   depends on FIREWIRE && INET && HAS_DMA
help
  This enables IPv4/IPv6 over IEEE 1394, providing IP connectivity
  with other implementations of RFC 2734/3146 as found on several
diff --git a/drivers/firewire/core-iso.c b/drivers/firewire/core-iso.c
index 38c0aa6..995f038 100644
--- a/drivers/firewire/core-iso.c
+++ b/drivers/firewire/core-iso.c
@@ -64,6 +64,7 @@ int fw_iso_buffer_alloc(struct fw_iso_buffer *buffer, int 
page_count)
return 0;
 }
 
+#ifdef CONFIG_HAS_DMA
 int fw_iso_buffer_map_dma(struct fw_iso_buffer *buffer, struct fw_card *card,
  enum dma_data_direction direction)
 {
@@ -86,6 +87,13 @@ int fw_iso_buffer_map_dma(struct fw_iso_buffer *buffer, 
struct fw_card *card,
 
return 0;
 }
+#else
+int fw_iso_buffer_map_dma(struct fw_iso_buffer *buffer, struct fw_card *card,
+ enum dma_data_direction direction)
+{
+   return -ENXIO;
+}
+#endif
 
 int fw_iso_buffer_init(struct fw_iso_buffer *buffer, struct fw_card *card,
   int page_count, enum dma_data_direction direction)
@@ -122,6 +130,7 @@ int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
return 0;
 }
 
+#ifdef CONFIG_HAS_DMA
 void fw_iso_buffer_destroy(struct fw_iso_buffer *buffer,
   struct fw_card *card)
 {
@@ -141,6 +150,12 @@ void fw_iso_buffer_destroy(struct fw_iso_buffer *buffer,
buffer->page_count = 0;
buffer->page_count_mapped = 0;
 }
+#else
+void fw_iso_buffer_destroy(struct fw_iso_buffer *buffer,
+  struct fw_card *card)
+{
+}
+#endif
 EXPORT_SYMBOL(fw_iso_buffer_destroy);
 
 /* Convert DMA address to offset into virtually contiguous buffer. */
-- 
1.7.11.7
--
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] reformat_with_checkpatch: Add automation to checkpatch

[Joe Perches]

On Sat, 2014-07-12 at 12:28 -0700, Greg KH wrote:
> On Sat, Jul 12, 2014 at 11:29:37AM -0700, Joe Perches wrote:
> > On Sat, 2014-07-12 at 10:55 -0700, Greg KH wrote:
> > > Yes, the warnings are all due to line-length, but Joe, you shouldn't add
> > > a patch that causes more checkpatch warnings than before :)
> > 
> > Yeah, that was intentional though.
> > 
> > This script does a series of relatively discrete changes.
> > 
> > Lindent would more or less work, but it's _horrible_ at
> > wrapping overlong lines and merges all types of changes
> > together.
> 
> Oh I agree, I don't want to see Lindent, but maybe, if the patch adds
> checkpatch warnings, it should be at least "flagged" as maybe a problem?

The script I submitted does run checkpatch
before any commit is done.

> Would you want to be on the receiving end of this patch script?

You might have noticed I don't have a kernel.org
account.


--
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] drivers/rtc/Kconfig: Let several drivers depend on HAS_IOMEM to avoid compiling issue

[Chen Gang]

Some drivers need 'devm_ioremap_resource' or 'devm_ioremap' which need
HAS_IOMEM, so let them depend on it.

The related error (with allmodconfig under score):

MODPOST 1365 modules
  ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-xgene.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-stk17ta8.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1742.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1553.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1511.ko] undefined!
  ERROR: "devm_ioremap_resource" [drivers/rtc/rtc-ds1286.ko] undefined!
  ERROR: "devm_ioremap" [drivers/rtc/rtc-rp5c01.ko] undefined!
  ERROR: "devm_ioremap" [drivers/rtc/rtc-msm6242.ko] undefined!
  ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t59.ko] undefined!
  ERROR: "devm_ioremap" [drivers/rtc/rtc-m48t35.ko] undefined!
  ERROR: "devm_ioremap" [drivers/rtc/rtc-bq4802.ko] undefined!

Signed-off-by: Chen Gang 
---
 drivers/rtc/Kconfig | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a672dd1..d707092 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -724,6 +724,7 @@ config RTC_DRV_DS1216
 
 config RTC_DRV_DS1286
tristate "Dallas DS1286"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the Dallas DS1286 RTC chips.
 
@@ -735,6 +736,7 @@ config RTC_DRV_DS1302
 
 config RTC_DRV_DS1511
tristate "Dallas DS1511"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the
  Dallas DS1511 timekeeping/watchdog chip.
@@ -744,6 +746,7 @@ config RTC_DRV_DS1511
 
 config RTC_DRV_DS1553
tristate "Maxim/Dallas DS1553"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the
  Maxim/Dallas DS1553 timekeeping chip.
@@ -753,6 +756,7 @@ config RTC_DRV_DS1553
 
 config RTC_DRV_DS1742
tristate "Maxim/Dallas DS1742/1743"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the
  Maxim/Dallas DS1742/1743 timekeeping chip.
@@ -808,6 +812,7 @@ config RTC_DRV_EFI
 
 config RTC_DRV_STK17TA8
tristate "Simtek STK17TA8"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the
  Simtek STK17TA8 timekeeping chip.
@@ -826,6 +831,7 @@ config RTC_DRV_M48T86
 
 config RTC_DRV_M48T35
tristate "ST M48T35"
+   depends on HAS_IOMEM
help
  If you say Y here you will get support for the
  ST M48T35 RTC chip.
@@ -835,6 +841,7 @@ config RTC_DRV_M48T35
 
 config RTC_DRV_M48T59
tristate "ST M48T59/M48T08/M48T02"
+   depends on HAS_IOMEM
help
  If you say Y here you will get support for the
  ST M48T59 RTC chip and compatible ST M48T08 and M48T02.
@@ -847,6 +854,7 @@ config RTC_DRV_M48T59
 
 config RTC_DRV_MSM6242
tristate "Oki MSM6242"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the Oki MSM6242
  timekeeping chip. It is used in some Amiga models (e.g. A2000).
@@ -856,6 +864,7 @@ config RTC_DRV_MSM6242
 
 config RTC_DRV_BQ4802
tristate "TI BQ4802"
+   depends on HAS_IOMEM
help
  If you say Y here you will get support for the TI
  BQ4802 RTC chip.
@@ -865,6 +874,7 @@ config RTC_DRV_BQ4802
 
 config RTC_DRV_RP5C01
tristate "Ricoh RP5C01"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the Ricoh RP5C01
  timekeeping chip. It is used in some Amiga models (e.g. A3000
@@ -1359,6 +1369,7 @@ config RTC_DRV_MOXART
 
 config RTC_DRV_XGENE
tristate "APM X-Gene RTC"
+   depends on HAS_IOMEM
help
  If you say yes here you get support for the APM X-Gene SoC real time
  clock.
-- 
1.7.11.7
--
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] drivers/crypto/Kconfig: Let 'DEV_QCE' depend on both HAS_DMA and HAS_IOMEM

[Chen Gang]

'DEV_QCE' needs both HAS_DMA and HAS_IOMEM, so let it depend on them.

The related error (with allmodconfig under score):

MODPOST 1365 modules
  ERROR: "devm_ioremap_resource" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_map_sg" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_set_mask" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_supported" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_unmap_sg" [drivers/crypto/qce/qcrypto.ko] undefined!

Signed-off-by: Chen Gang 
---
 drivers/crypto/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 5ef9ec9..2fb0fdf 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -422,7 +422,7 @@ source "drivers/crypto/qat/Kconfig"
 
 config CRYPTO_DEV_QCE
tristate "Qualcomm crypto engine accelerator"
-   depends on ARCH_QCOM || COMPILE_TEST
+   depends on (ARCH_QCOM || COMPILE_TEST) && HAS_DMA && HAS_IOMEM
select CRYPTO_AES
select CRYPTO_DES
select CRYPTO_ECB
-- 
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/4] ARM: tegra: roth: add display DT node

[Alexandre Courbot]

On Fri, Jul 11, 2014 at 10:14 PM, Thierry Reding
 wrote:
> On Tue, Jul 08, 2014 at 09:32:14PM +0900, Alexandre Courbot wrote:
>> Tegra DSI support has been fixed to support continuous clock behavior that
>> the panel used on SHIELD requires, so finally add its device tree node
>> since it is functional.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  arch/arm/boot/dts/tegra114-roth.dts | 22 +++---
>>  1 file changed, 19 insertions(+), 3 deletions(-)
>
> I've applied this to Tegra's for-3.17/dt branch. Thanks.

Thanks - how about the other patches of the series? Ideally this one
should be applied last.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH] staging: android: Clean up binder_buffer_size()

[Greg Kroah-Hartman]

On Sat, Jul 12, 2014 at 09:50:09PM -0300, Lucas Tanure wrote:
> Kernel coding style. Remove useless else statement after return.
> 
> Signed-off-by: Lucas Tanure 
> ---
>  drivers/staging/android/binder.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

What tree are you making this patch against?  Someone already has this
patch accepted into my staging-next branch, which means that linux-next
also should show this change in it.

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/

[PATCH] dgnc: DGNC_VERIFY_BOARD macro in do while block

[Jeremiah Mahler]

Enclose the body of the multi-statement DGNC_VERIFY_BOARD macro inside a
do - while block as per Documentation/CodingStyle.  Fixes 1 error found
by checkpatch.pl.

Signed-off-by: Jeremiah Mahler 
---
 drivers/staging/dgnc/dgnc_sysfs.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_sysfs.c 
b/drivers/staging/dgnc/dgnc_sysfs.c
index 0f0e8fc..3f321bb 100644
--- a/drivers/staging/dgnc/dgnc_sysfs.c
+++ b/drivers/staging/dgnc/dgnc_sysfs.c
@@ -150,15 +150,17 @@ void dgnc_remove_driver_sysfiles(struct pci_driver 
*dgnc_driver)
 }
 
 
-#define DGNC_VERIFY_BOARD(p, bd)   \
-   if (!p) \
-   return 0;   \
-   \
-   bd = dev_get_drvdata(p);\
-   if (!bd || bd->magic != DGNC_BOARD_MAGIC)   \
-   return 0;   \
-   if (bd->state != BOARD_READY)   \
-   return 0;   \
+#define DGNC_VERIFY_BOARD(p, bd)   \
+   do {\
+   if (!p) \
+   return 0;   \
+   \
+   bd = dev_get_drvdata(p);\
+   if (!bd || bd->magic != DGNC_BOARD_MAGIC)   \
+   return 0;   \
+   if (bd->state != BOARD_READY)   \
+   return 0;   \
+   } while (0)
 
 
 
-- 
2.0.1

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

Re: [PATCH v2] not adding modules range to kcore if it's equal to vmcore range

[Baoquan He]

On some ARCHs modules range is eauql to vmalloc range. E.g on i686
"#define MODULES_VADDR   VMALLOC_START"
"#define MODULES_END VMALLOC_END"
This will cause 2 duplicate program segments in /proc/kcore, makes
user confused. In this patch a judgment added to check if modules
range is equal to vmalloc range. If yes, just skip adding the modules
range.

Signed-off-by: Baoquan He 
---
 fs/proc/kcore.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 39e6ef3..bf5127c 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -610,8 +610,10 @@ static void __init proc_kcore_text_init(void)
 struct kcore_list kcore_modules;
 static void __init add_modules_range(void)
 {
-   kclist_add(_modules, (void *)MODULES_VADDR,
-   MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
+   if (MODULES_VADDR != VMALLOC_START) {
+   kclist_add(_modules, (void *)MODULES_VADDR,
+   MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
+   }
 }
 #else
 static void __init add_modules_range(void)
-- 
1.9.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/

[RESEND PATCH] staging: android: Clean up binder_buffer_size()

[Lucas Tanure]

Kernel coding style. Remove useless else statement after return.

Signed-off-by: Lucas Tanure 
---
 drivers/staging/android/binder.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index cfe4bc8..1a0966b 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -451,8 +451,7 @@ static size_t binder_buffer_size(struct binder_proc *proc,
 {
if (list_is_last(>entry, >buffers))
return proc->buffer + proc->buffer_size - (void *)buffer->data;
-   else
-   return (size_t)list_entry(buffer->entry.next,
+   return (size_t)list_entry(buffer->entry.next,
struct binder_buffer, entry) - (size_t)buffer->data;
 }
 
-- 
2.0.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] not adding modules range to kcore if it's equal to vmcore range

[Baoquan He]

On some ARCHs modules range is eauql to vmalloc range. E.g on i686

This will cause 2 duplicate program segments in /proc/kcore, makes
user confused. In this patch a judgment added to check if modules
range is equal to vmalloc range. If yes, just skip adding the modules
range.

Signed-off-by: Baoquan He 
---
 fs/proc/kcore.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 39e6ef3..bf5127c 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -610,8 +610,10 @@ static void __init proc_kcore_text_init(void)
 struct kcore_list kcore_modules;
 static void __init add_modules_range(void)
 {
-   kclist_add(_modules, (void *)MODULES_VADDR,
-   MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
+   if (MODULES_VADDR != VMALLOC_START) {
+   kclist_add(_modules, (void *)MODULES_VADDR,
+   MODULES_END - MODULES_VADDR, KCORE_VMALLOC);
+   }
 }
 #else
 static void __init add_modules_range(void)
-- 
1.9.3

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

Re: [PATCH 0/4] New Qualcomm PMIC pin controller drivers

[Bjorn Andersson]

On Thu, Jul 10, 2014 at 6:39 AM, Ivan T. Ivanov  wrote:
> On Wed, 2014-07-09 at 07:02 -0700, Bjorn Andersson wrote:
[..]
>> Correct Ivan; we do however share the same issues related to how to do
>> interrupt handling,
>
> Yep, but do we actually need to do interrupt handling in driver?
> Interrupts are handled by parent device. GPIO client drivers could
> use interrupt-controller registered by core driver?
>

Among other things we have the volume and camera keys hooked to these
pins, using the gpio-keys driver; so that needs to be able to convert
a gpio to an irq.
But I don't believe we should turn this driver into an
interrupt-controller; as that wouldn't add any value...

Regards,
Bjorn
--
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 10/11] perf, tools, test: Add test case for alias and JSON parsing

[Andi Kleen]

> missing the tests/aliases.o file
> 
>   AR   libperf.a
> ar: tests/aliases.o: No such file or directory

Fixed here (and in git)

---

From: Andi Kleen 

Add a simple test case to perf test that runs perf download and parses
all the available events, including json events.

This needs adding an all event iterator to pmu.c

v2: Rename identifiers
v3: Only iterate cpu pmu to avoid bogus errors.
Move pmu iterator to extra patch
v4: Include aliases.c again
Acked-by: Namhyung Kim 
Signed-off-by: Andi Kleen 

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 0600425..6adb37f 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -419,6 +419,7 @@ endif
 LIB_OBJS += $(OUTPUT)tests/code-reading.o
 LIB_OBJS += $(OUTPUT)tests/sample-parsing.o
 LIB_OBJS += $(OUTPUT)tests/parse-no-sample-id-all.o
+LIB_OBJS += $(OUTPUT)tests/aliases.o
 ifndef NO_DWARF_UNWIND
 ifeq ($(ARCH),$(filter $(ARCH),x86 arm))
 LIB_OBJS += $(OUTPUT)tests/dwarf-unwind.o
diff --git a/tools/perf/tests/aliases.c b/tools/perf/tests/aliases.c
new file mode 100644
index 000..08a5f01
--- /dev/null
+++ b/tools/perf/tests/aliases.c
@@ -0,0 +1,58 @@
+/* Check if we can set up all aliases and can read JSON files */
+#include 
+#include "tests.h"
+#include "pmu.h"
+#include "evlist.h"
+#include "parse-events.h"
+
+static struct perf_evlist *evlist;
+
+static int num_events;
+static int failed;
+
+static int test__event(const char *pmu, const char *name)
+{
+   int ret;
+
+   /* Not supported for now */
+   if (strcmp(pmu, "cpu"))
+   return 0;
+
+   ret = parse_events(evlist, name);
+
+   if (ret) {
+   /*
+* We only print on failure because common perf setups
+* have events that cannot be parsed.
+*/
+   fprintf(stderr, "invalid or unsupported event: '%s'\n", name);
+   ret = 0;
+   failed++;
+   } else
+   num_events++;
+   return ret;
+}
+
+int test__aliases(void)
+{
+   int err;
+
+   /* Download JSON files */
+   /* XXX assumes perf is installed */
+   /* For now user must manually download */
+   if (0 && system("perf download > /dev/null") < 0) {
+   /* Don't error out for this for now */
+   fprintf(stderr, "perf download failed\n");
+   }
+
+   evlist = perf_evlist__new();
+   if (evlist == NULL)
+   return -ENOMEM;
+
+   err = pmu_iterate_events(test__event);
+   fprintf(stderr, " Parsed %d events :", num_events);
+   if (failed > 0)
+   pr_debug(" %d events failed", failed);
+   perf_evlist__delete(evlist);
+   return err;
+}
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 6f8b01b..bb37ac2 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -154,6 +154,10 @@ static struct test {
.func = test__hists_cumulate,
},
{
+   .desc = "Test parsing JSON aliases",
+   .func = test__aliases,
+   },
+   {
.func = NULL,
},
 };
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index ed64790..ab92ad9 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -48,6 +48,7 @@ int test__mmap_thread_lookup(void);
 int test__thread_mg_share(void);
 int test__hists_output(void);
 int test__hists_cumulate(void);
+int test__aliases(void);
 
 #if defined(__x86_64__) || defined(__i386__) || defined(__arm__)
 #ifdef HAVE_DWARF_UNWIND_SUPPORT
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drivers: tty: Fix use-after-free in pty_common_install

[Rasmus Villemoes]

In 2c964a2f "drivers: tty: Merge alloc_tty_struct and
initialize_tty_struct", I messed up the refactorization of
pty_common_install, causing use-after-free and NULL pointer derefs on
various error paths. This should fix it.

Reported-by: Julia Lawall 
Reported-by: Dan Carpenter 
Signed-off-by: Rasmus Villemoes 
---
 drivers/tty/pty.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index ac723e3..9bbdb1d 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -388,7 +388,7 @@ err_deinit_tty:
deinitialize_tty_struct(o_tty);
free_tty_struct(o_tty);
 err_put_module:
-   module_put(o_tty->driver->owner);
+   module_put(driver->other->owner);
 err:
kfree(ports[0]);
kfree(ports[1]);
-- 
1.9.2

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

Re: bit fields && data tearing

[Benjamin Herrenschmidt]

On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
> OK, looks like this is compiler bug,
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
> 
> Thanks to Dan who informed me privately.

So yes, there's is this compiler bug which means a bitfield
access can cause a r-m-w access to a neighbouring field but
in general, I would be weary of bitfields anyway since accessing
them isn't going to be atomic anyway... it's too easy to get things
wrong and in most cases the benefit is yet to be demonstrated.

In your example, I don't see the point of the bitfield.

Cheers,
Ben.

> On 07/12, Oleg Nesterov wrote:
> >
> > Hello,
> >
> > I am not sure I should ask here, but since Documentation/memory-barriers.txt
> > mentions load/store tearing perhaps my question is not completely 
> > off-topic...
> >
> > I am fighting with mysterious RHEL bug, it can be reproduced on ppc and s390
> > but not on x86. Finally I seem to understand the problem, and I even wrote 
> > the
> > stupid kernel module to ensure, see it below at the end.
> >
> > It triggers the problem immediately, kt_2() sees the wrong value in 
> > freeze_stop.
> > (If I turn ->freeze_stop int "long", the problem goes away).
> >
> > So the question is: is this gcc bug or the code below is buggy?
> >
> > If it is buggy, then probably memory-barriers.txt could mention that you 
> > should
> > be carefull with bit fields, even ACCESS_ONCE() obviously can't help.
> >
> > Or this just discloses my ignorance and you need at least aligned(long) 
> > after a
> > bit field to be thread-safe ? I thought that compiler should take care and 
> > add
> > the necessary alignment if (say) CPU can't update a single byte/uint.
> >
> > gcc version 4.4.7 20120313 (Red Hat 4.4.7-9) (GCC). Asm:
> >
> >  <.kt_2>:
> >0:   7c 08 02 a6 mflrr0
> >4:   fb 81 ff e0 std r28,-32(r1)
> >8:   fb a1 ff e8 std r29,-24(r1)
> >c:   fb c1 ff f0 std r30,-16(r1)
> >   10:   fb e1 ff f8 std r31,-8(r1)
> >   14:   eb c2 00 00 ld  r30,0(r2)
> >   18:   f8 01 00 10 std r0,16(r1)
> >   1c:   f8 21 ff 71 stdur1,-144(r1)
> >   20:   7c 7d 1b 78 mr  r29,r3
> >   24:   3b e0 00 00 li  r31,0
> >   28:   78 3c 04 64 rldicr  r28,r1,0,49
> >   2c:   3b 9c 00 80 addir28,r28,128
> >   30:   48 00 00 2c b   5c <.kt_2+0x5c>
> >   34:   60 00 00 00 nop
> >   38:   60 00 00 00 nop
> >   3c:   60 00 00 00 nop
> >   40:   93 fd 00 04 stw r31,4(r29)
> >   44:   e8 9d 00 06 lwa r4,4(r29)
> >   48:   7f 84 f8 00 cmpwcr7,r4,r31
> >   4c:   40 de 00 4c bne-cr7,98 <.kt_2+0x98>
> >   50:   e8 1c 00 00 ld  r0,0(r28)
> >   54:   78 09 f7 e3 rldicl. r9,r0,62,63
> >   58:   40 c2 00 54 bne-ac <.kt_2+0xac>
> >   5c:   48 00 00 01 bl  5c <.kt_2+0x5c>
> >   60:   60 00 00 00 nop
> >   64:   3b ff 00 01 addir31,r31,1
> >   68:   2f a3 00 00 cmpdi   cr7,r3,0
> >   6c:   7f ff 07 b4 extsw   r31,r31
> >   70:   41 9e ff d0 beq+cr7,40 <.kt_2+0x40>
> >   74:   38 21 00 90 addir1,r1,144
> >   78:   38 60 00 00 li  r3,0
> >   7c:   e8 01 00 10 ld  r0,16(r1)
> >   80:   eb 81 ff e0 ld  r28,-32(r1)
> >   84:   eb a1 ff e8 ld  r29,-24(r1)
> >   88:   eb c1 ff f0 ld  r30,-16(r1)
> >   8c:   eb e1 ff f8 ld  r31,-8(r1)
> >   90:   7c 08 03 a6 mtlrr0
> >   94:   4e 80 00 20 blr
> >   98:   e8 7e 80 28 ld  r3,-32728(r30)
> >   9c:   7f e5 fb 78 mr  r5,r31
> >   a0:   48 00 00 01 bl  a0 <.kt_2+0xa0>
> >   a4:   60 00 00 00 nop
> >   a8:   4b ff ff a8 b   50 <.kt_2+0x50>
> >   ac:   48 00 00 01 bl  ac <.kt_2+0xac>
> >   b0:   60 00 00 00 nop
> >   b4:   4b ff ff a8 b   5c <.kt_2+0x5c>
> >   b8:   60 00 00 00 nop
> >   bc:   60 00 00 00 nop
> >
> > 00c0 <.kt_1>:
> >   c0:   7c 08 02 a6 mflrr0
> >   c4:   fb 81 ff e0 std r28,-32(r1)
> >   c8:   fb a1 ff e8 std r29,-24(r1)
> >   cc:   fb c1 ff f0 std r30,-16(r1)
> >   d0:   fb e1 ff f8 std r31,-8(r1)
> >   d4:   eb c2 00 00 ld  r30,0(r2)
> >   d8:   f8 01 00 10 std r0,16(r1)
> >   dc:   f8 21 ff 71 stdur1,-144(r1)
> >   e0:   7c 7d 1b 78 mr  r29,r3
> >   e4:   3b e0 00 00 li  r31,0
> >   e8:   78 3c 04 64 rldicr  r28,r1,0,49
> >   ec:   3b 9c 00 80 addir28,r28,128
> >   f0:   48 00 00 38 b   128 <.kt_1+0x68>
> >   f4:   60 00 00 00 nop
> >   f8:   60 00 00 00 nop
> >   fc:   60 00 00 00 nop
> >  100:   e8 1d 00 00 ld  r0,0(r29)
> >  104:   

Re: [PATCHv6] perf tools: enable close-on-exec flag on perf file descriptor

[Jiri Olsa]

On Mon, Jun 30, 2014 at 10:28:47PM +0200, Yann Droneaud wrote:
> In commit a21b0b354d4a ('perf: Introduce a flag to enable
> close-on-exec in perf_event_open()'), flag PERF_FLAG_FD_CLOEXEC
> was added to perf_event_open(2) syscall to allows userspace
> to atomically enable close-on-exec behavor when creating
> the file descriptor.
> 
> This patch makes perf tools use the new flag if supported
> by the kernel, so that the event file descriptors got
> automatically closed if perf tool exec a sub-command.
> 
> Cc: Peter Zijlstra 
> Cc: Arnaldo Carvalho de Melo 
> Cc: Jiri Olsa 
> Cc: Andi Kleen 
> Cc: Ingo Molnar 
> Signed-off-by: Yann Droneaud 
> ---
> 
> Hi,
> 
> I've addressed the issues reported by Jiri Olsa,
> please have a look at the update patch.

hi,
I'll queue this one

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

RE: scsi-mq V2

[Elliott, Robert (Server Storage)]

> I will see if that solves the problem with the scsi-mq-3 tree, or
> at least some of the bisect trees leading up to it.

scsi-mq-3 is still going after 45 minutes.  I'll leave it running
overnight.


--
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 10/11] perf, tools, test: Add test case for alias and JSON parsing

[Jiri Olsa]

On Fri, Jul 11, 2014 at 04:59:24PM -0700, Andi Kleen wrote:
> From: Andi Kleen 
> 
> Add a simple test case to perf test that runs perf download and parses
> all the available events, including json events.
> 
> This needs adding an all event iterator to pmu.c
> 
> v2: Rename identifiers
> v3: Only iterate cpu pmu to avoid bogus errors.
> Move pmu iterator to extra patch
> Acked-by: Namhyung Kim 
> Signed-off-by: Andi Kleen 
> ---
>  tools/perf/Makefile.perf| 1 +
>  tools/perf/tests/builtin-test.c | 4 
>  tools/perf/tests/tests.h| 1 +
>  3 files changed, 6 insertions(+)
> 
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 0600425..6adb37f 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -419,6 +419,7 @@ endif
>  LIB_OBJS += $(OUTPUT)tests/code-reading.o
>  LIB_OBJS += $(OUTPUT)tests/sample-parsing.o
>  LIB_OBJS += $(OUTPUT)tests/parse-no-sample-id-all.o
> +LIB_OBJS += $(OUTPUT)tests/aliases.o

missing the tests/aliases.o file

  AR   libperf.a
ar: tests/aliases.o: No such file or directory


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

checkpatch.pl misses list_for_each_entry() coding style issues

[Greg KH]

Hi Joe,

The following function:

$ cat foo.c 

static int foo_init(void)
{

list_for_each_entry(foo, , list)
{
do_something_foo(foo);
}

return 0;
}

Will not be caught by checkpatch:

$ ./scripts/checkpatch.pl --file foo.c 
total: 0 errors, 0 warnings, 11 lines checked

foo.c has no obvious style problems and is ready for submission.


Any way to fix that up?

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 00/19] ARM: SAMSUNG: S5PV210 platform clean-up

[Kukjin Kim]

On 07/05/14 05:15, Arnd Bergmann wrote:

On Friday 04 July 2014 19:48:00 Tomasz Figa wrote:

This huge series is a (hopefully final) attempt to convert Samsung S5PV210
into a DT-only and multiplatform-aware platform. It consists of several
steps to gradually replace legacy code with one meeting current standards
and then finally remove unused remnants.

Patches 1-6 migrate the platform to fully use the Common Clock Framework
and get rid of legacy private clock code, of which s5pv210 was the last
user. Then patch 7 adds generic PHY driver for USB PHY on S5PV210 to allow
USB to be supported when using DT. Further three patches (8-10) add DT
support for mach-s5pv210 and necessary DT sources for currently supported
boards. Patch 11 removes board files and code directly related to them,
effectively making s5pv210 a DT-only platform. In next step, patches 12-15
prepare remaining code for multiplatform enablement, which is finally done
in patch 16. Patches 17-19 are a final clean-up, which remove a lot of
unused code left after making the last S5P platform DT-only.

Build tested patch by patch on following configs:
  - s3c2410_defconfig (with DT support enabled),
  - s3c6400_defconfig (with DT support enabled),
  - s5pv210_defconfig (with DT support enabled after patches adding it),
  - exynos_defconfig,
  - exynos_defconfig with S5PV210 enabled in multiplatform configuration.

Boot tested on s5pv210-goni board.

Note that support for smdkc110, smdkv210 and torbreck boards is provided
by moving data from existing board files to new device tree sources. No
testing was performed due to mentioned board not being available anymore.
However I believe we agreed on this approach, because apparently there
are no active users of them. See the RFC from August 2013 asking for
removal of the whole platform [1].

[1] 
http://www.mail-archive.com/linux-samsung-soc%40vger.kernel.org/msg21882.html



Great work, everything

Acked-by: Arnd Bergmann

I hope we can get this into linux-next soon so we can do some more
cleanups on top.


Sorry for a little bit late applying, I just wanted to get ack from 
driver maintainers but... anyway I'll apply this series so you may see 
this on Monday in -next :)


Tomasz, many thanks for your effort and time.

- Kukjin
--
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] staging: comedi: addi_apci_1564: use addi_watchdog module to init watchdog subdevice

[Chase Southwood]

Use the addi_watchdog module to provide support for the watchdog
subdevice.

Also, rearrange the subdevice init blocks so that the order makes sense.
Digital input/output subdevices and subdevices for DI/DO interrupt
support, followed by timer/counter/watchdog subdevices is the new order.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 drivers/staging/comedi/drivers/addi_apci_1564.c | 34 +++--
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c 
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 16f3b69..190b026 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -373,7 +373,7 @@ static int apci1564_auto_attach(struct comedi_device *dev,
dev->irq = pcidev->irq;
}
 
-   ret = comedi_alloc_subdevices(dev, 4);
+   ret = comedi_alloc_subdevices(dev, 5);
if (ret)
return ret;
 
@@ -397,20 +397,8 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s->insn_bits = apci1564_do_insn_bits;
s->insn_read = apci1564_do_read;
 
-   /*  Allocate and Initialise Timer Subdevice Structures */
-   s = >subdevices[2];
-   s->type = COMEDI_SUBD_TIMER;
-   s->subdev_flags = SDF_WRITEABLE;
-   s->n_chan = 1;
-   s->maxdata = 0;
-   s->len_chanlist = 1;
-   s->range_table = _digital;
-   s->insn_write = apci1564_timer_write;
-   s->insn_read = apci1564_timer_read;
-   s->insn_config = apci1564_timer_config;
-
/* Change-Of-State (COS) interrupt subdevice */
-   s = >subdevices[3];
+   s = >subdevices[2];
if (dev->irq) {
dev->read_subdev = s;
s->type = COMEDI_SUBD_DI;
@@ -428,6 +416,24 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s->type = COMEDI_SUBD_UNUSED;
}
 
+   /*  Allocate and Initialise Timer Subdevice Structures */
+   s = >subdevices[3];
+   s->type = COMEDI_SUBD_TIMER;
+   s->subdev_flags = SDF_WRITEABLE;
+   s->n_chan = 1;
+   s->maxdata = 0;
+   s->len_chanlist = 1;
+   s->range_table = _digital;
+   s->insn_write = apci1564_timer_write;
+   s->insn_read = apci1564_timer_read;
+   s->insn_config = apci1564_timer_config;
+
+   /* Initialize the watchdog subdevice */
+   s = >subdevices[4];
+   ret = addi_watchdog_init(s, devpriv->amcc_iobase + APCI1564_WDOG_REG);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
2.0.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 1/2] staging: comedi: addi_apci_1564: driver no longer needs to include addi_common.h

[Chase Southwood]

This driver no longer depends on anything in addi_common.h, save for a
few headers that it was including indirectly.  Remove the include of
addi_common.h and add the includes of 
and  directly.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 drivers/staging/comedi/drivers/addi_apci_1564.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c 
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 1e25342..16f3b69 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -1,13 +1,13 @@
 #include 
 #include 
+#include 
+#include 
 
 #include "../comedidev.h"
 #include "comedi_fc.h"
 #include "amcc_s5933.h"
 #include "addi_watchdog.h"
 
-#include "addi-data/addi_common.h"
-
 struct apci1564_private {
unsigned int amcc_iobase;   /* base of AMCC I/O registers */
unsigned int mode1; /* riding-edge/high level channels */
-- 
2.0.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: linux-next: Tree for Jul 11

[Nick Krause]

On Fri, Jul 11, 2014 at 3:18 AM, Stephen Rothwell  wrote:
> Hi all,
>
> Changes since 20140710:
>
> My fixes tree contains:
> powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
>
> The tty.current tree gained a build failure so I used the version from
> next-20140710.
>
> The irqchip tree gained a conflict against the arm64 tree.
>
> The staging tree lost its build failure and gained a conflict against
> the tty tree.
>
> Non-merge commits (relative to Linus' tree): 5114
>  4474 files changed, 191199 insertions(+), 226003 deletions(-)
>
> 
>
> I have created today's linux-next tree at
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> (patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
> are tracking the linux-next tree using git, you should not use "git pull"
> to do so as that will try to merge the new linux-next release with the
> old one.  You should use "git fetch" and checkout or reset to the new
> master.
>
> You can see which trees have been included by looking in the Next/Trees
> file in the source.  There are also quilt-import.log and merge.log files
> in the Next directory.  Between each merge, the tree was built with
> a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
> multi_v7_defconfig for arm. After the final fixups (if any), it is also
> built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
> allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
> defconfig.
>
> Below is a summary of the state of the merge.
>
> I am currently merging 222 trees (counting Linus' and 30 trees of patches
> pending for Linus' tree).
>
> Stats about the size of the tree over time can be seen at
> http://neuling.org/linux-next-size.html .
>
> Status of my local build tests will be at
> http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
> advice about cross compilers/configs that work, we are always open to add
> more builds.
>
> Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
> Gortmaker for triage and bug fixes.
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> $ git checkout master
> $ git reset --hard stable
> Merging origin/master (4c71842375f5 Merge branch 'for-3.16-fixes' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata)
> Merging fixes/master (b8accbbce667 powerpc: Disable RELOCATABLE for 
> COMPILE_TEST with PPC64)
> Merging kbuild-current/rc-fixes (dd5a6752ae7d firmware: Create directories 
> for external firmware)
> Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
> Merging arm-current/fixes (9a2c33a422d6 ARM: l2c: fix revision checking)
> Merging m68k-current/for-linus (f1a1b6352998 m68k: Fix boot regression on 
> machines with RAM at non-zero)
> Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
> Merging powerpc-merge/merge (6663a4fa6711 powerpc: Don't skip ePAPR 
> spin-table CPUs)
> Merging sparc/master (894e552cfaa3 Merge branch 'for-linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
> Merging net/master (f6864c6f3513 Merge branch 'for-davem' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless)
> Merging ipsec/master (a0e5ef53aac8 xfrm: Fix installation of AH IPsec SAs)
> Merging sound-current/for-linus (91947d8cc553 ALSA: hda - Add new GPU codec 
> ID 0x10de0070 to snd-hda)
> Merging pci-current/for-linus (bf177a1eb6d1 MAINTAINERS: Update mx6 PCI 
> driver maintainer's email)
> Merging wireless/master (2c4db12ec469 rt2800usb: Don't perform DMA from stack)
> Merging driver-core.current/driver-core-linus (cd3de83f1476 Linux 3.16-rc4)
> Merging tty.current/tty-linus (99ecb001f52e serial: arc_uart: Use 
> uart_circ_empty() for open-coded comparison)
> $ git reset --hard HEAD^
> Merging next-20140710 version of tty.current
> Merging usb.current/usb-linus (5a7fbe7e9ea0 USB: ftdi_sio: Add extra PID.)
> Merging usb-gadget-fixes/fixes (8035691365b8 usb: musb: dsps: fix the base 
> address for accessing the mode register)
> Merging usb-serial-fixes/usb-linus (3d28bd840b2d usb: option: Add ID for 
> Telewell TW-LTE 4G v2)
> Merging staging.current/staging-linus (bdac8ca90e07 Merge tag 
> 'iio-fixes-for-3.16c' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus)
> Merging char-misc.current/char-misc-linus (6d827fbcc370 i8k: Fix non-SMP 
> operation)
> Merging input-current/for-linus (31972f6e517d Input: ti_am335x_tsc - warn 
> about incorrect spelling)
> Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
> stripe)
> Merging crypto-current/master (0378c9a855bf crypto: caam - fix memleak in 
> caam_jr module)
> Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
> Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
> Merging devicetree-current/devicetree/merge (356facff5275 of/platform: Fix 

[PATCH] timekeeping: Fix missing memory barriers in NMI safe CLOCK_MONOTONIC[_RAW]

[Mathieu Desnoyers]

Commit c7b080e148d9 "timekeeping: Provide fast and NMI safe access to
CLOCK_MONOTONIC[_RAW]" lacks memory barriers.

The following scenario demonstrates a race condition where the reader
can see a corrupted clock value.

Initial conditions:

tkf->seq = 0
tkf->base[0] and tkf->base[1] are initialized.

CPU 0  CPU 1
   
update:
  tkf->seq++
  smb_wmb()
  tkf->seq++ (reordered before update)
   reader:
 seq = tkf->seq (reads 2)
 smp_rmb()
 idx = seq & 0x01
 now = now(tkf->base[idx]
# reads base[0]
  update(tkf->base[0], tk)
   # racy concurrent update
 smp_rmb()
 while (seq != tkf->seq)
# they are equal
 [ update continues ... ]

In this situation, the reader returns a corrupted value. Adding a
smp_wmb() between update of base[0] and increment of seq, as well as
between update of base[1] and the _following_ increment of seq (next
update call) fixes this.

Introduce raw_write_seqcount_latch() to abstract those barriers rather
than open-coding them in update_fast_timekeeper().

Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1407122145580.4357@nanos
Fixes: c7b080e148d9 "timekeeping: Provide fast and NMI safe access to 
CLOCK_MONOTONIC[_RAW]"
Signed-off-by: Mathieu Desnoyers 
Cc: Thomas Gleixner 
Cc: John Stultz 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
---
 include/linux/seqlock.h   |   11 +++
 kernel/time/timekeeping.c |4 ++--
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index dcc64b9..c18adee 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -236,6 +236,17 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
 }
 
 /*
+ * raw_write_seqcount_latch - redirect readers to even/odd copy
+ * @s: pointer to seqcount_t
+ */
+static inline void raw_write_seqcount_latch(seqcount_t *s)
+{
+   smp_wmb();  /* prior stores before incrementing "sequence" */
+   s->sequence++;
+   smp_wmb();  /* increment "sequence" before following stores */
+}
+
+/*
  * Sequence counter only version assumes that callers are using their
  * own mutexing.
  */
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 47d2caf..2bd73b0 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -317,7 +317,7 @@ static void update_fast_timekeeper(struct clocksource *clk, 
struct tk_fast *tkf,
struct tk_fast_base *base = tkf->base;
 
/* Force readers off to base[1] */
-   raw_write_seqcount_begin(>seq);
+   raw_write_seqcount_latch(>seq);
 
/* Update base[0] */
base->clock = clk;
@@ -327,7 +327,7 @@ static void update_fast_timekeeper(struct clocksource *clk, 
struct tk_fast *tkf,
base->mult = mult;
 
/* Force readers back to base[0] */
-   raw_write_seqcount_end(>seq);
+   raw_write_seqcount_latch(>seq);
 
/* Update base[1] */
base++;
-- 
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: Blackfin Build fixs

[Nick Krause]

On Fri, Jul 11, 2014 at 12:18 PM, Nick Krause  wrote:
> Hey Steven,
> I having been testing what builds are still failing from Steven
> Rothwell's tests and there seem to be two failing
> still for blackfin. I am tracing the issues to make it easier for you
> as a maintainer.  BF561-ACVILON_defconfig
> is failing in acvlion.c due to BFIN_NAND_PLAT_READY not being defined
> when calling gpio request in
> bfin_plat_nand_init. I would recommend defining it to the correct
> value to initialize nand on this board.
> There also seems to be some undefined syscalls for this board I would
> can either remove them or you can
> tell me how to clean them up.
>
> I also am hitting a build failure still for blackstamp defconfig. The
> issue seems to be that when calling functions
> that need GPIO_PF0 that it's undefined as it fails whenc calling
> gpio_request that needs it be defined on line 318
> of file , arch/blackfin/mach-bf533/boards/blackstamp.c on line 480 and
> again on line 481 when calling gpio_free.
> Like the other build there seems to be undefined syscalls and they
> need to be either removed or cleaned up. I
> would like recommendations or how you want to clean up these system calls.
>
> I am also attaching the log files for these failing builds.
>
> Cheers Nick
Sorry about my grammar. I attached the same file twice. I will attach
my build log for Blackstamp
defconfig.
Cheers Nick


Blackstamp_defconfig
Description: Binary data

Re: [PATCHv2 2/5] mailbox/omap: add support for parsing dt devices

[Pavel Machek]

On Fri 2014-07-11 17:04:09, Suman Anna wrote:
> Logic has been added to the OMAP2+ mailbox code to parse the
> mailbox dt nodes and construct the different sub-mailboxes
> associated with the instance. The DT representation of the
> sub-mailbox devices is different from legacy platform data
> representation to allow flexibility of interrupt configuration
> between Tx and Rx fifos (to also possibly allow simplex devices
> in the future). The DT representation gathers similar information
> that was being passed previously through the platform data, except
> for the number of fifos, interrupts and interrupt type information,
> which are gathered through driver compatible match data.
> 
> The non-DT support has to be maintained for now to not break
> OMAP3 legacy boot, and the legacy-style code will be cleaned
> up once OMAP3 is also converted to DT-boot only.
> 
> Cc: Jassi Brar 
> Cc: Rob Herring 
> Signed-off-by: Suman Anna 

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

[PATCH 3/4] perf tools: Factor eprintf to allow different debug variables

[Jiri Olsa]

This way we can easily reuse current debug functions for
another debug variables other than verbose.

Cc: Arnaldo Carvalho de Melo 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/debug.c  | 12 ++--
 tools/perf/util/debug.h  | 12 ++--
 tools/perf/util/python.c |  4 ++--
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index 299b555..c208d6f 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -16,11 +16,11 @@
 int verbose;
 bool dump_trace = false, quiet = false;
 
-static int _eprintf(int level, const char *fmt, va_list args)
+static int _eprintf(int level, int var, const char *fmt, va_list args)
 {
int ret = 0;
 
-   if (verbose >= level) {
+   if (var >= level) {
if (use_browser >= 1)
ui_helpline__vshow(fmt, args);
else
@@ -30,13 +30,13 @@ static int _eprintf(int level, const char *fmt, va_list 
args)
return ret;
 }
 
-int eprintf(int level, const char *fmt, ...)
+int eprintf(int level, int var, const char *fmt, ...)
 {
va_list args;
int ret;
 
va_start(args, fmt);
-   ret = _eprintf(level, fmt, args);
+   ret = _eprintf(level, var, fmt, args);
va_end(args);
 
return ret;
@@ -51,9 +51,9 @@ void pr_stat(const char *fmt, ...)
va_list args;
 
va_start(args, fmt);
-   _eprintf(1, fmt, args);
+   _eprintf(1, verbose, fmt, args);
va_end(args);
-   eprintf(1, "\n");
+   eprintf(1, verbose, "\n");
 }
 
 int dump_printf(const char *fmt, ...)
diff --git a/tools/perf/util/debug.h b/tools/perf/util/debug.h
index 8a8ceb3..1cb8081 100644
--- a/tools/perf/util/debug.h
+++ b/tools/perf/util/debug.h
@@ -16,15 +16,15 @@ extern bool quiet, dump_trace;
 #endif
 
 #define pr_err(fmt, ...) \
-   eprintf(0, pr_fmt(fmt), ##__VA_ARGS__)
+   eprintf(0, verbose, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_warning(fmt, ...) \
-   eprintf(0, pr_fmt(fmt), ##__VA_ARGS__)
+   eprintf(0, verbose, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_info(fmt, ...) \
-   eprintf(0, pr_fmt(fmt), ##__VA_ARGS__)
+   eprintf(0, verbose, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_debug(fmt, ...) \
-   eprintf(1, pr_fmt(fmt), ##__VA_ARGS__)
+   eprintf(1, verbose, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_debugN(n, fmt, ...) \
-   eprintf(n, pr_fmt(fmt), ##__VA_ARGS__)
+   eprintf(n, verbose, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_debug2(fmt, ...) pr_debugN(2, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_debug3(fmt, ...) pr_debugN(3, pr_fmt(fmt), ##__VA_ARGS__)
 #define pr_debug4(fmt, ...) pr_debugN(4, pr_fmt(fmt), ##__VA_ARGS__)
@@ -37,6 +37,6 @@ int ui__warning(const char *format, ...) 
__attribute__((format(printf, 1, 2)));
 
 void pr_stat(const char *fmt, ...);
 
-int eprintf(int level, const char *fmt, ...) __attribute__((format(printf, 2, 
3)));
+int eprintf(int level, int var, const char *fmt, ...) 
__attribute__((format(printf, 3, 4)));
 
 #endif /* __PERF_DEBUG_H */
diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index 122669c..12aa9b0 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -14,12 +14,12 @@
  */
 int verbose;
 
-int eprintf(int level, const char *fmt, ...)
+int eprintf(int level, int var, const char *fmt, ...)
 {
va_list args;
int ret = 0;
 
-   if (verbose >= level) {
+   if (var >= level) {
va_start(args, fmt);
ret = vfprintf(stderr, fmt, args);
va_end(args);
-- 
1.8.3.1

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

[PATCH 2/4] perf tools: Move pr_* debug macros into debug object

[Jiri Olsa]

Moving pr_* debug macros to have it with in same object as
debug variables, becase we will change them to use verbose
variable in next patch.

Cc: Arnaldo Carvalho de Melo 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Signed-off-by: Jiri Olsa 
---
 tools/perf/arch/x86/tests/dwarf-unwind.c|  1 +
 tools/perf/arch/x86/util/unwind-libunwind.c |  1 +
 tools/perf/builtin-evlist.c |  1 +
 tools/perf/builtin-help.c   |  1 +
 tools/perf/builtin-timechart.c  |  1 +
 tools/perf/tests/dso-data.c |  1 +
 tools/perf/tests/evsel-roundtrip-name.c |  1 +
 tools/perf/tests/evsel-tp-sched.c   |  1 +
 tools/perf/tests/open-syscall-tp-fields.c   |  1 +
 tools/perf/tests/parse-events.c |  1 +
 tools/perf/tests/parse-no-sample-id-all.c   |  1 +
 tools/perf/tests/sample-parsing.c   |  1 +
 tools/perf/tests/thread-mg-share.c  |  1 +
 tools/perf/util/data.c  |  1 +
 tools/perf/util/debug.h | 20 
 tools/perf/util/include/linux/kernel.h  | 21 -
 tools/perf/util/pstack.c|  1 +
 .../perf/util/scripting-engines/trace-event-perl.c  |  1 +
 tools/perf/util/trace-event-info.c  |  1 +
 tools/perf/util/trace-event-read.c  |  1 +
 tools/perf/util/unwind-libunwind.c  |  1 +
 tools/perf/util/util.c  |  1 +
 tools/perf/util/vdso.c  |  1 +
 23 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/tools/perf/arch/x86/tests/dwarf-unwind.c 
b/tools/perf/arch/x86/tests/dwarf-unwind.c
index 9f89f89..d8bbf7a 100644
--- a/tools/perf/arch/x86/tests/dwarf-unwind.c
+++ b/tools/perf/arch/x86/tests/dwarf-unwind.c
@@ -3,6 +3,7 @@
 #include "thread.h"
 #include "map.h"
 #include "event.h"
+#include "debug.h"
 #include "tests/tests.h"
 
 #define STACK_SIZE 8192
diff --git a/tools/perf/arch/x86/util/unwind-libunwind.c 
b/tools/perf/arch/x86/util/unwind-libunwind.c
index 3261f68..db25e93 100644
--- a/tools/perf/arch/x86/util/unwind-libunwind.c
+++ b/tools/perf/arch/x86/util/unwind-libunwind.c
@@ -3,6 +3,7 @@
 #include 
 #include "perf_regs.h"
 #include "../../util/unwind.h"
+#include "../../util/debug.h"
 
 #ifdef HAVE_ARCH_X86_64_SUPPORT
 int libunwind__arch_reg_id(int regnum)
diff --git a/tools/perf/builtin-evlist.c b/tools/perf/builtin-evlist.c
index c99e0de..66e12f5 100644
--- a/tools/perf/builtin-evlist.c
+++ b/tools/perf/builtin-evlist.c
@@ -15,6 +15,7 @@
 #include "util/parse-options.h"
 #include "util/session.h"
 #include "util/data.h"
+#include "util/debug.h"
 
 static int __cmd_evlist(const char *file_name, struct perf_attr_details 
*details)
 {
diff --git a/tools/perf/builtin-help.c b/tools/perf/builtin-help.c
index 178b88a..0384d93 100644
--- a/tools/perf/builtin-help.c
+++ b/tools/perf/builtin-help.c
@@ -11,6 +11,7 @@
 #include "util/parse-options.h"
 #include "util/run-command.h"
 #include "util/help.h"
+#include "util/debug.h"
 
 static struct man_viewer_list {
struct man_viewer_list *next;
diff --git a/tools/perf/builtin-timechart.c b/tools/perf/builtin-timechart.c
index 04c9c53..2f1a522 100644
--- a/tools/perf/builtin-timechart.c
+++ b/tools/perf/builtin-timechart.c
@@ -37,6 +37,7 @@
 #include "util/svghelper.h"
 #include "util/tool.h"
 #include "util/data.h"
+#include "util/debug.h"
 
 #define SUPPORT_OLD_POWER_EVENTS 1
 #define PWR_EVENT_EXIT -1
diff --git a/tools/perf/tests/dso-data.c b/tools/perf/tests/dso-data.c
index 630808c..caaf37f 100644
--- a/tools/perf/tests/dso-data.c
+++ b/tools/perf/tests/dso-data.c
@@ -10,6 +10,7 @@
 #include "machine.h"
 #include "symbol.h"
 #include "tests.h"
+#include "debug.h"
 
 static char *test_file(int size)
 {
diff --git a/tools/perf/tests/evsel-roundtrip-name.c 
b/tools/perf/tests/evsel-roundtrip-name.c
index 465cdbc..b8d8341 100644
--- a/tools/perf/tests/evsel-roundtrip-name.c
+++ b/tools/perf/tests/evsel-roundtrip-name.c
@@ -2,6 +2,7 @@
 #include "evsel.h"
 #include "parse-events.h"
 #include "tests.h"
+#include "debug.h"
 
 static int perf_evsel__roundtrip_cache_name_test(void)
 {
diff --git a/tools/perf/tests/evsel-tp-sched.c 
b/tools/perf/tests/evsel-tp-sched.c
index 35d7fdb..5216242 100644
--- a/tools/perf/tests/evsel-tp-sched.c
+++ b/tools/perf/tests/evsel-tp-sched.c
@@ -1,6 +1,7 @@
 #include 
 #include "evsel.h"
 #include "tests.h"
+#include "debug.h"
 
 static int perf_evsel__test_field(struct perf_evsel *evsel, const char *name,
  int size, bool should_be_signed)
diff --git a/tools/perf/tests/open-syscall-tp-fields.c 
b/tools/perf/tests/open-syscall-tp-fields.c
index c505ef2..0785b64 100644
--- 

[PATCH 4/4] perf tools: Add --debug optionto set debug variable

[Jiri Olsa]

Adding --debug option as a way to setup debug variables.
Starting with support for verbose, more will come.

It's possible to use it now with report command:
  $ perf report --debug verbose
  $ perf report --debug verbose=2

I'll need this support to add separated debug variable
for ordered events change in order to separate debug
output out of standard verbose stream.

Also removing unneeded getopt.h includes.

Cc: Arnaldo Carvalho de Melo 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Signed-off-by: Jiri Olsa 
---
 tools/perf/Documentation/perf-report.txt |  6 +
 tools/perf/builtin-report.c  |  2 ++
 tools/perf/util/debug.c  | 45 
 tools/perf/util/debug.h  |  3 +++
 tools/perf/util/probe-finder.c   |  1 -
 tools/perf/util/trace-event-read.c   |  1 -
 6 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-report.txt 
b/tools/perf/Documentation/perf-report.txt
index d2b59af..53b6ad8 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -25,6 +25,12 @@ OPTIONS
 --verbose::
 Be more verbose. (show symbol address, etc)
 
+--debug::
+Setup debug variable (just verbose for now) in value
+range (0, 10). Use like:
+   --debug verbose   # sets verbose = 1
+   --debug verbose=2 # sets verbose = 2
+
 -n::
 --show-nr-samples::
Show the number of samples for each symbol
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 21d830b..deb8f1e 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -679,6 +679,8 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
 "Don't show entries under that percent", 
parse_percent_limit),
OPT_CALLBACK(0, "percentage", NULL, "relative|absolute",
 "how to display percentage of filtered entries", 
parse_filter_percentage),
+   OPT_CALLBACK(0, "debug", NULL, "variable[=VALUE]",
+"set debug variable (verbose)", perf_debug_option),
OPT_END()
};
struct perf_data_file file = {
diff --git a/tools/perf/util/debug.c b/tools/perf/util/debug.c
index c208d6f..54bd12a 100644
--- a/tools/perf/util/debug.c
+++ b/tools/perf/util/debug.c
@@ -105,3 +105,48 @@ void trace_event(union perf_event *event)
}
printf(".\n");
 }
+
+static struct variables_t {
+   const char *name;
+   int *ptr;
+} variables[] = {
+   { .name = "verbose", .ptr =  },
+   { .name = NULL, }
+};
+
+int perf_debug_option(const struct option *opt __maybe_unused, const char *str,
+ int unset __maybe_unused)
+{
+   struct variables_t *var = [0];
+   char *vstr, *s = strdup(str);
+   int v = 1;
+
+   vstr = strchr(s, '=');
+   if (vstr)
+   *vstr++ = 0;
+
+   while (var->name) {
+   if (!strcmp(s, var->name))
+   break;
+   var++;
+   }
+
+   if (!var->name) {
+   pr_err("Unknown debug variable name '%s'\n", s);
+   free(s);
+   return -1;
+   }
+
+   if (vstr) {
+   v = atoi(vstr);
+   /*
+* Allow only values in range (0, 10),
+* otherwise set 0.
+*/
+   v = (v < 0) || (v > 10) ? 0 : v;
+   }
+
+   *var->ptr = v;
+   free(s);
+   return 0;
+}
diff --git a/tools/perf/util/debug.h b/tools/perf/util/debug.h
index 1cb8081..295fee5 100644
--- a/tools/perf/util/debug.h
+++ b/tools/perf/util/debug.h
@@ -7,6 +7,7 @@
 #include "../ui/helpline.h"
 #include "../ui/progress.h"
 #include "../ui/util.h"
+#include "parse-options.h"
 
 extern int verbose;
 extern bool quiet, dump_trace;
@@ -39,4 +40,6 @@ void pr_stat(const char *fmt, ...);
 
 int eprintf(int level, int var, const char *fmt, ...) 
__attribute__((format(printf, 3, 4)));
 
+int perf_debug_option(const struct option *opt, const char *str, int unset);
+
 #endif /* __PERF_DEBUG_H */
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 98e3047..dca9145 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/tools/perf/util/trace-event-read.c 
b/tools/perf/util/trace-event-read.c
index ea3fd7f..54d9e9b 100644
--- a/tools/perf/util/trace-event-read.c
+++ b/tools/perf/util/trace-event-read.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.8.3.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  

[PATCH 1/4] perf tools: Remove verbose from functions prototypes

[Jiri Olsa]

And use verbose as an global object in following fuunctions:
  __map_groups__fprintf_maps
  __map_groups__fprintf_removed_maps
  map_groups__fprintf_maps
  map_groups__fprintf

Also making map_groups__fprintf_maps static.

Cc: Arnaldo Carvalho de Melo 
Cc: Corey Ashford 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Signed-off-by: Jiri Olsa 
---
 tools/perf/ui/stdio/hist.c |  2 +-
 tools/perf/util/map.c  | 24 
 tools/perf/util/map.h  |  9 -
 tools/perf/util/thread.c   |  4 ++--
 4 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 90122ab..40af0ac 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -479,7 +479,7 @@ print_entries:
 
if (h->ms.map == NULL && verbose > 1) {
__map_groups__fprintf_maps(h->thread->mg,
-  MAP__FUNCTION, verbose, fp);
+  MAP__FUNCTION, fp);
fprintf(fp, "%.10s end\n", graph_dotted_line);
}
}
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 25c571f..49f5f37 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -12,6 +12,7 @@
 #include "vdso.h"
 #include "build-id.h"
 #include "util.h"
+#include "debug.h"
 #include 
 
 const char *map_type__name[MAP__NR_TYPES] = {
@@ -554,8 +555,8 @@ int map_groups__find_ams(struct addr_map_symbol *ams, 
symbol_filter_t filter)
return ams->sym ? 0 : -1;
 }
 
-size_t __map_groups__fprintf_maps(struct map_groups *mg,
- enum map_type type, int verbose, FILE *fp)
+size_t __map_groups__fprintf_maps(struct map_groups *mg, enum map_type type,
+ FILE *fp)
 {
size_t printed = fprintf(fp, "%s:\n", map_type__name[type]);
struct rb_node *nd;
@@ -573,17 +574,16 @@ size_t __map_groups__fprintf_maps(struct map_groups *mg,
return printed;
 }
 
-size_t map_groups__fprintf_maps(struct map_groups *mg, int verbose, FILE *fp)
+static size_t map_groups__fprintf_maps(struct map_groups *mg, FILE *fp)
 {
size_t printed = 0, i;
for (i = 0; i < MAP__NR_TYPES; ++i)
-   printed += __map_groups__fprintf_maps(mg, i, verbose, fp);
+   printed += __map_groups__fprintf_maps(mg, i, fp);
return printed;
 }
 
 static size_t __map_groups__fprintf_removed_maps(struct map_groups *mg,
-enum map_type type,
-int verbose, FILE *fp)
+enum map_type type, FILE *fp)
 {
struct map *pos;
size_t printed = 0;
@@ -600,23 +600,23 @@ static size_t __map_groups__fprintf_removed_maps(struct 
map_groups *mg,
 }
 
 static size_t map_groups__fprintf_removed_maps(struct map_groups *mg,
-  int verbose, FILE *fp)
+  FILE *fp)
 {
size_t printed = 0, i;
for (i = 0; i < MAP__NR_TYPES; ++i)
-   printed += __map_groups__fprintf_removed_maps(mg, i, verbose, 
fp);
+   printed += __map_groups__fprintf_removed_maps(mg, i, fp);
return printed;
 }
 
-size_t map_groups__fprintf(struct map_groups *mg, int verbose, FILE *fp)
+size_t map_groups__fprintf(struct map_groups *mg, FILE *fp)
 {
-   size_t printed = map_groups__fprintf_maps(mg, verbose, fp);
+   size_t printed = map_groups__fprintf_maps(mg, fp);
printed += fprintf(fp, "Removed maps:\n");
-   return printed + map_groups__fprintf_removed_maps(mg, verbose, fp);
+   return printed + map_groups__fprintf_removed_maps(mg, fp);
 }
 
 int map_groups__fixup_overlappings(struct map_groups *mg, struct map *map,
-  int verbose, FILE *fp)
+  FILE *fp)
 {
struct rb_root *root = >maps[map->type];
struct rb_node *next = rb_first(root);
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index 7758c72..b57d49a 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -141,8 +141,8 @@ void map__fixup_end(struct map *map);
 
 void map__reloc_vmlinux(struct map *map);
 
-size_t __map_groups__fprintf_maps(struct map_groups *mg,
- enum map_type type, int verbose, FILE *fp);
+size_t __map_groups__fprintf_maps(struct map_groups *mg, enum map_type type,
+ FILE *fp);
 void maps__insert(struct rb_root *maps, struct map *map);
 void maps__remove(struct rb_root *maps, struct map *map);
 struct map *maps__find(struct rb_root *maps, u64 addr);
@@ -152,8 +152,7 @@ void map_groups__init(struct map_groups *mg);
 void map_groups__exit(struct map_groups *mg);
 int 

[PATCH 0/4] perf tools: Add support for more debug variables

[Jiri Olsa]

hi,
adding support for more debug variables and --debug option
as a way to setup debug variables. Starting with support
for verbose, more will come.

It's possible to use it now with report command:
  $ perf report --debug verbose
  $ perf report --debug verbose=2

I need this for ordered events object debug outputs.

thanks,
jirka


---
Jiri Olsa (4):
  perf tools: Remove verbose from functions prototypes
  perf tools: Move pr_* debug macros into debug object
  perf tools: Factor eprintf to allow different debug variables
  perf tools: Add --debug optionto set debug variable

 tools/perf/Documentation/perf-report.txt |  6 ++
 tools/perf/arch/x86/tests/dwarf-unwind.c |  1 +
 tools/perf/arch/x86/util/unwind-libunwind.c  |  1 +
 tools/perf/builtin-evlist.c  |  1 +
 tools/perf/builtin-help.c|  1 +
 tools/perf/builtin-report.c  |  2 ++
 tools/perf/builtin-timechart.c   |  1 +
 tools/perf/tests/dso-data.c  |  1 +
 tools/perf/tests/evsel-roundtrip-name.c  |  1 +
 tools/perf/tests/evsel-tp-sched.c|  1 +
 tools/perf/tests/open-syscall-tp-fields.c|  1 +
 tools/perf/tests/parse-events.c  |  1 +
 tools/perf/tests/parse-no-sample-id-all.c|  1 +
 tools/perf/tests/sample-parsing.c|  1 +
 tools/perf/tests/thread-mg-share.c   |  1 +
 tools/perf/ui/stdio/hist.c   |  2 +-
 tools/perf/util/data.c   |  1 +
 tools/perf/util/debug.c  | 57 
++--
 tools/perf/util/debug.h  | 23 +
 tools/perf/util/include/linux/kernel.h   | 21 ---
 tools/perf/util/map.c| 24 
+++---
 tools/perf/util/map.h|  9 -
 tools/perf/util/probe-finder.c   |  1 -
 tools/perf/util/pstack.c |  1 +
 tools/perf/util/python.c |  4 ++--
 tools/perf/util/scripting-engines/trace-event-perl.c |  1 +
 tools/perf/util/thread.c |  4 ++--
 tools/perf/util/trace-event-info.c   |  1 +
 tools/perf/util/trace-event-read.c   |  2 +-
 tools/perf/util/unwind-libunwind.c   |  1 +
 tools/perf/util/util.c   |  1 +
 tools/perf/util/vdso.c   |  1 +
 32 files changed, 124 insertions(+), 51 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/83] AMD HSA kernel driver

[Gabbay, Oded]

On Fri, 2014-07-11 at 17:18 -0400, Jerome Glisse wrote:
> On Thu, Jul 10, 2014 at 10:51:29PM +, Gabbay, Oded wrote:
> >  On Thu, 2014-07-10 at 18:24 -0400, Jerome Glisse wrote:
> > >  On Fri, Jul 11, 2014 at 12:45:27AM +0300, Oded Gabbay wrote:
> > > >   This patch set implements a Heterogeneous System Architecture
> > > >  (HSA) driver
> > > >   for radeon-family GPUs.
> > >  This is just quick comments on few things. Given size of this, 
> > > people
> > >  will need to have time to review things.
> > > >   HSA allows different processor types (CPUs, DSPs, GPUs, 
> > > > etc..) to
> > > >  share
> > > >   system resources more effectively via HW features including
> > > >  shared pageable
> > > >   memory, userspace-accessible work queues, and platform-level
> > > >  atomics. In
> > > >   addition to the memory protection mechanisms in GPUVM and
> > > >  IOMMUv2, the Sea
> > > >   Islands family of GPUs also performs HW-level validation of
> > > >  commands passed
> > > >   in through the queues (aka rings).
> > > >   The code in this patch set is intended to serve both as a 
> > > > sample
> > > >  driver for
> > > >   other HSA-compatible hardware devices and as a production 
> > > > driver
> > > >  for
> > > >   radeon-family processors. The code is architected to support
> > > >  multiple CPUs
> > > >   each with connected GPUs, although the current implementation
> > > >  focuses on a
> > > >   single Kaveri/Berlin APU, and works alongside the existing 
> > > > radeon
> > > >  kernel
> > > >   graphics driver (kgd).
> > > >   AMD GPUs designed for use with HSA (Sea Islands and up) share
> > > >  some hardware
> > > >   functionality between HSA compute and regular gfx/compute 
> > > > (memory,
> > > >   interrupts, registers), while other functionality has been 
> > > > added
> > > >   specifically for HSA compute  (hw scheduler for virtualized
> > > >  compute rings).
> > > >   All shared hardware is owned by the radeon graphics driver, 
> > > > and
> > > >  an interface
> > > >   between kfd and kgd allows the kfd to make use of those 
> > > > shared
> > > >  resources,
> > > >   while HSA-specific functionality is managed directly by kfd 
> > > > by
> > > >  submitting
> > > >   packets into an HSA-specific command queue (the "HIQ").
> > > >   During kfd module initialization a char device node 
> > > > (/dev/kfd) is
> > > >  created
> > > >   (surviving until module exit), with ioctls for queue 
> > > > creation &
> > > >  management,
> > > >   and data structures are initialized for managing HSA device
> > > >  topology.
> > > >   The rest of the initialization is driven by calls from the 
> > > > radeon
> > > >  kgd at
> > > >   the following points :
> > > >   - radeon_init (kfd_init)
> > > >   - radeon_exit (kfd_fini)
> > > >   - radeon_driver_load_kms (kfd_device_probe, kfd_device_init)
> > > >   - radeon_driver_unload_kms (kfd_device_fini)
> > > >   During the probe and init processing per-device data 
> > > > structures
> > > >  are
> > > >   established which connect to the associated graphics kernel
> > > >  driver. This
> > > >   information is exposed to userspace via sysfs, along with a
> > > >  version number
> > > >   allowing userspace to determine if a topology change has 
> > > > occurred
> > > >  while it
> > > >   was reading from sysfs.
> > > >   The interface between kfd and kgd also allows the kfd to 
> > > > request
> > > >  buffer
> > > >   management services from kgd, and allows kgd to route 
> > > > interrupt
> > > >  requests to
> > > >   kfd code since the interrupt block is shared between regular
> > > >   graphics/compute and HSA compute subsystems in the GPU.
> > > >   The kfd code works with an open source usermode library
> > > >  ("libhsakmt") which
> > > >   is in the final stages of IP review and should be published 
> > > > in a
> > > >  separate
> > > >   repo over the next few days.
> > > >   The code operates in one of three modes, selectable via the
> > > >  sched_policy
> > > >   module parameter :
> > > >   - sched_policy=0 uses a hardware scheduler running in the MEC
> > > >  block within
> > > >   CP, and allows oversubscription (more queues than HW slots)
> > > >   - sched_policy=1 also uses HW scheduling but does not allow
> > > >   oversubscription, so create_queue requests fail when we run 
> > > > out
> > > >  of HW slots
> > > >   - sched_policy=2 does not use HW scheduling, so the driver
> > > >  manually assigns
> > > >   queues to HW slots by programming registers
> > > >   The "no HW scheduling" option is for debug & new hardware 
> > > > bringup
> > > >  only, so
> > > >   has less test coverage than the other options. Default in the
> > > >  current code
> > > >   is "HW scheduling without oversubscription" since that is 
> > > > where
> > > >  we have the
> > > >   most test coverage but we expect to change the default to "HW
> > > >  scheduling
> > > >   with oversubscription" after further testing. This 
> > > > effectively
> > > 

RE: scsi-mq V2

[Elliott, Robert (Server Storage)]

> -Original Message-
> From: Benjamin LaHaise [mailto:b...@kvack.org]
> Sent: Friday, 11 July, 2014 9:55 AM
> To: Elliott, Robert (Server Storage)
> Cc: Christoph Hellwig; Jeff Moyer; Jens Axboe; dgilb...@interlog.com; James
> Bottomley; Bart Van Assche; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: scsi-mq V2
...
> Can you try the below totally untested patch instead?  It looks like
> put_reqs_available() is not irq-safe.
> 

With that addition alone, fio still runs into the same problem.

I added the same fix to get_reqs_available, which also accesses 
kcpu->reqs_available, and the test has run for 35 minutes with 
no problem.

Patch applied:

diff --git a/fs/aio.c b/fs/aio.c
index e59bba8..8e85e26 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -830,16 +830,20 @@ void exit_aio(struct mm_struct *mm)
 static void put_reqs_available(struct kioctx *ctx, unsigned nr)
 {
struct kioctx_cpu *kcpu;
+   unsigned long flags;
 
preempt_disable();
kcpu = this_cpu_ptr(ctx->cpu);
 
+   local_irq_save(flags);
kcpu->reqs_available += nr;
+
while (kcpu->reqs_available >= ctx->req_batch * 2) {
kcpu->reqs_available -= ctx->req_batch;
atomic_add(ctx->req_batch, >reqs_available);
}
 
+   local_irq_restore(flags);
preempt_enable();
 }
 
@@ -847,10 +851,12 @@ static bool get_reqs_available(struct kioctx *ctx)
 {
struct kioctx_cpu *kcpu;
bool ret = false;
+   unsigned long flags;
 
preempt_disable();
kcpu = this_cpu_ptr(ctx->cpu);
 
+   local_irq_save(flags);
if (!kcpu->reqs_available) {
int old, avail = atomic_read(>reqs_available);
 
@@ -869,6 +875,7 @@ static bool get_reqs_available(struct kioctx *ctx)
ret = true;
kcpu->reqs_available--;
 out:
+   local_irq_restore(flags);
preempt_enable();
return ret;
 }

--
I will see if that solves the problem with the scsi-mq-3 tree, or 
at least some of the bisect trees leading up to it.

A few other comments:

1. Those changes boost _raw_spin_lock_irqsave into first place
in perf top:

  6.59%  [kernel][k] _raw_spin_lock_irqsave
  4.37%  [kernel][k] put_compound_page
  2.87%  [scsi_debug][k] sdebug_q_cmd_hrt_complete
  2.74%  [kernel][k] _raw_spin_lock
  2.73%  [kernel][k] apic_timer_interrupt
  2.41%  [kernel][k] do_blockdev_direct_IO
  2.24%  [kernel][k] __get_page_tail
  1.97%  [kernel][k] _raw_spin_unlock_irqrestore
  1.87%  [kernel][k] scsi_queue_rq
  1.76%  [scsi_debug][k] schedule_resp

Maybe (later) kcpu->reqs_available should converted to an atomic,
like ctx->reqs_available, to reduce that overhead?

2. After the f8567a3 patch, aio_complete has one early return that 
bypasses the call to put_reqs_available.  Is that OK, or does
that mean that sync iocbs will now eat up reqs_available?

/*
 * Special case handling for sync iocbs:
 *  - events go directly into the iocb for fast handling
 *  - the sync task with the iocb in its stack holds the single iocb
 *ref, no other paths have a way to get another ref
 *  - the sync task helpfully left a reference to itself in the iocb
 */
if (is_sync_kiocb(iocb)) {
iocb->ki_user_data = res;
smp_wmb();
iocb->ki_ctx = ERR_PTR(-EXDEV);
wake_up_process(iocb->ki_obj.tsk);
return;
}


3. The f8567a3 patch renders this comment in aio.c out of date - it's 
no longer incremented when pulled off the ringbuffer, but is now 
incremented when aio_complete is called.

struct {
/*
 * This counts the number of available slots in the ringbuffer,
 * so we avoid overflowing it: it's decremented (if positive)
 * when allocating a kiocb and incremented when the resulting
 * io_event is pulled off the ringbuffer.
 *
 * We batch accesses to it with a percpu version.
 */
atomic_treqs_available;
} cacheline_aligned_in_smp;


---
Rob ElliottHP Server Storage



--
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] staging: android: Coding style fix

[Modestas Stankus]

This patch fixes warnings of checkpatch.pl script:
WARNING: void function return statements are not generally useful
+   return;
+}

Task of Eudyptula challenge.
---
 drivers/staging/android/ion/ion_carveout_heap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index dcb6f21..9156d82 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -133,7 +133,6 @@ static struct sg_table *ion_carveout_heap_map_dma(struct 
ion_heap *heap,
 static void ion_carveout_heap_unmap_dma(struct ion_heap *heap,
struct ion_buffer *buffer)
 {
-   return;
 }
 
 static struct ion_heap_ops carveout_heap_ops = {
-- 
2.0.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 V8 2/2] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers

[Greg KH]

On Thu, Jul 10, 2014 at 04:16:37PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Jul 10, 2014 at 03:31:57PM +0100, One Thousand Gnomes wrote:
> > > I really don't like the way that the tty core has been changed to handle
> > > multiple attribute groups, as I feel tty drivers shouldn't be creating
> > > "special" sysfs files, depending on what driver is bound to them.
> > 
> > The intent isn't that it is "special" but that it can be propogated to
> > others as and when they wish to provide it.
> >  
> > > Usually we have handled this using tools like 'stty' and ioctls, right?
> > > Surely there is an ioctl to control the interrupt level, right?  Hasn't
> > > this been covered before somehow?
> > 
> > No, and the direction when this started was to use sysfs as we have also
> > been moving all the other attributes towards sysfs and has been since
> > 2012.
> > 
> > TTY devices do have lots of strange attributes and right now many of them
> > are only programmable by using device tree and rebooting.
> 
> Ok.  Hm, there has to be a better way to do the group sysfs file
> handling...
> 
> Let me work on this tomorrow and see what I can come up with.  We should
> be able to use the is_visable() attribute to create/notcreate the
> attribute where needed...

Ok, how about this patch instead of your first one?

It creates a new port attribute, attr_group, which you should be able to
set in the 8250 driver if you device needs it.  Then the serial core
will handle the dynamic group creation, without relying on a "magic"
number of groups.  Very close to your patch, but now it's dynamic, and
no fixed array, and no crazy casting in the
tty_port_register_device_attr() call.

I have not tested this, only test built the code.

If it works for you, can you redo your second patch, and then send both
of these back to me so that I can apply them?

thanks,

greg k-h


---

Subject: [PATCH] Serial: allow port drivers to have a default attribute group

From: Greg Kroah-Hartman 

Some serial drivers (like 8250), want to add sysfs files.  We need to do
so in a race-free way, so allow any port to be able to specify an
attribute group that should be added at device creation time.

Based on a patch from Yoshihiro YUNOMAE


Cc: Yoshihiro YUNOMAE 
Signed-off-by: Greg Kroah-Hartman 


diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index b70095e55df6..b8c3a5419060 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2564,11 +2564,6 @@ static const struct attribute_group tty_dev_attr_group = 
{
.attrs = tty_dev_attrs,
};
 
-static const struct attribute_group *tty_dev_attr_groups[] = {
-   _dev_attr_group,
-   NULL
-   };
-
 
 /**
  * uart_add_one_port - attach a driver-defined port structure
@@ -2586,6 +2581,7 @@ int uart_add_one_port(struct uart_driver *drv, struct 
uart_port *uport)
struct tty_port *port;
int ret = 0;
struct device *tty_dev;
+   int num_groups;
 
BUG_ON(in_interrupt());
 
@@ -2619,12 +2615,26 @@ int uart_add_one_port(struct uart_driver *drv, struct 
uart_port *uport)
 
uart_configure_port(drv, state, uport);
 
+   num_groups = 2;
+   if (uport->attr_group)
+   num_groups++;
+
+   uport->tty_groups = kzalloc(sizeof(struct attribute_group *) * 
num_groups,
+GFP_KERNEL);
+   if (!uport->tty_groups) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   uport->tty_groups[0] = _dev_attr_group;
+   if (uport->attr_group)
+   uport->tty_groups[1] = uport->attr_group;
+
/*
 * Register the port whether it's detected or not.  This allows
 * setserial to be used to alter this port's parameters.
 */
tty_dev = tty_port_register_device_attr(port, drv->tty_driver,
-   uport->line, uport->dev, port, tty_dev_attr_groups);
+   uport->line, uport->dev, port, uport->tty_groups);
if (likely(!IS_ERR(tty_dev))) {
device_set_wakeup_capable(tty_dev, 1);
} else {
@@ -2703,6 +2713,7 @@ int uart_remove_one_port(struct uart_driver *drv, struct 
uart_port *uport)
 */
if (uport->type != PORT_UNKNOWN)
uport->ops->release_port(uport);
+   kfree(uport->tty_groups);
 
/*
 * Indicate that there isn't a port here anymore.
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5bbb809ee197..cf3a1e789bf5 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -199,6 +199,8 @@ struct uart_port {
unsigned char   suspended;
unsigned char   irq_wake;
unsigned char   unused[2];
+   struct attribute_group  *attr_group;/* port specific 
attributes */
+   const struct attribute_group **tty_groups;  /* all attributes 
(serial core use only) */
 

Re: [PATCH 2/2] x86_64,signal: Remove 'fs' and 'gs' from sigcontext

[Andy Lutomirski]

On Sat, Jul 12, 2014 at 11:52 AM, Andi Kleen  wrote:
> On Sat, Jul 12, 2014 at 11:40:03AM -0700, H. Peter Anvin wrote:
>> Because you are doing something weird (like Pin, for example) and take an 
>> asynchronous fault?
>
> But even for pin that would need executing 16 bit code, or really weird
> 32bit code. AFAIK for 32bit the only good use case was NX emulation
> (and old virtualization) which are both completely obsolete.

Nothing particularly weird is needed.  Set a non-default stack segment
(e.g. any 16-bit ss) and take *any* fault.  This could be something
asynchronous or even a normal synchronous fault.  Return from the
signal handler: boom.

We know that people use 16-bit stack segments: it's what prompted the
whole espfix64 thing.

>
> I don't think it's worth messing with the signal handlers for 16bit
> code. If there's any problem with saving/restoring state that emulator
> can always handle it by itself.
>

How?

I can think of at least two vaguely feasible ways.  The program could
ptrace itself, trap sigreturn, and fix ss.  Or it could restore
registers itself and return using far ret or iret.  Both suck.

--Andy
--
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 2/2] arch/x86/xen: Silence compiler warnings

[Daniel Kiper]

Compiler complains in the following way when x86 32-bit kernel
with Xen support is build:

  CC  arch/x86/xen/enlighten.o
arch/x86/xen/enlighten.c: In function ‘xen_start_kernel’:
arch/x86/xen/enlighten.c:1726:3: warning: right shift count >= width of type 
[enabled by default]

Such line contains following EFI initialization code:

boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 32);

There is no issue if x86 64-bit kernel is build. However, 32-bit case
generate warning (even if that code will not be executed because Xen
does not work on 32-bit EFI platforms) due to __pa() returning unsigned long
type which has 32-bits width. So move whole EFI initialization stuff
to separate function and build it conditionally to avoid above mentioned
warning on x86 32-bit architecture.

Signed-off-by: Daniel Kiper 
---
v2 - suggestions/fixes:
   - move xen_efi_init() to separate module
 (suggested by Konrad Rzeszutek Wilk).
---
 arch/x86/xen/Makefile|1 +
 arch/x86/xen/efi.c   |   43 +++
 arch/x86/xen/enlighten.c |   15 +--
 arch/x86/xen/xen-ops.h   |8 
 4 files changed, 53 insertions(+), 14 deletions(-)
 create mode 100644 arch/x86/xen/efi.c

diff --git a/arch/x86/xen/Makefile b/arch/x86/xen/Makefile
index 96ab2c0..7322755 100644
--- a/arch/x86/xen/Makefile
+++ b/arch/x86/xen/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= spinlock.o
 obj-$(CONFIG_XEN_DEBUG_FS) += debugfs.o
 obj-$(CONFIG_XEN_DOM0) += apic.o vga.o
 obj-$(CONFIG_SWIOTLB_XEN)  += pci-swiotlb-xen.o
+obj-$(CONFIG_XEN_EFI)  += efi.o
diff --git a/arch/x86/xen/efi.c b/arch/x86/xen/efi.c
new file mode 100644
index 000..a02e09e
--- /dev/null
+++ b/arch/x86/xen/efi.c
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2014 Oracle Co., Daniel Kiper
+ *
+ * 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, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+void __init xen_efi_init(void)
+{
+   efi_system_table_t *efi_systab_xen;
+
+   efi_systab_xen = xen_efi_probe();
+
+   if (efi_systab_xen == NULL)
+   return;
+
+   strncpy((char *)_params.efi_info.efi_loader_signature, "Xen",
+   sizeof(boot_params.efi_info.efi_loader_signature));
+   boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
+   boot_params.efi_info.efi_systab_hi = (__u32)(__pa(efi_systab_xen) >> 
32);
+
+   set_bit(EFI_BOOT, );
+   set_bit(EFI_PARAVIRT, );
+   set_bit(EFI_64BIT, );
+}
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index bc89647..2cd0463 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -32,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -1521,7 +1520,6 @@ asmlinkage __visible void __init xen_start_kernel(void)
 {
struct physdev_set_iopl set_iopl;
int rc;
-   efi_system_table_t *efi_systab_xen;
 
if (!xen_start_info)
return;
@@ -1717,18 +1715,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
 
xen_setup_runstate_info(0);
 
-   efi_systab_xen = xen_efi_probe();
-
-   if (efi_systab_xen) {
-   strncpy((char *)_params.efi_info.efi_loader_signature, 
"Xen",
-   
sizeof(boot_params.efi_info.efi_loader_signature));
-   boot_params.efi_info.efi_systab = (__u32)__pa(efi_systab_xen);
-   boot_params.efi_info.efi_systab_hi = 
(__u32)(__pa(efi_systab_xen) >> 32);
-
-   set_bit(EFI_BOOT, );
-   set_bit(EFI_PARAVIRT, );
-   set_bit(EFI_64BIT, );
-   }
+   xen_efi_init();
 
/* Start the world */
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/xen/xen-ops.h b/arch/x86/xen/xen-ops.h
index c834d4b..75f98fe 100644
--- a/arch/x86/xen/xen-ops.h
+++ b/arch/x86/xen/xen-ops.h
@@ -104,6 +104,14 @@ static inline void __init xen_init_apic(void)
 }
 #endif
 
+#ifdef CONFIG_XEN_EFI
+extern void xen_efi_init(void);
+#else
+static inline void __init xen_efi_init(void)
+{
+}
+#endif
+
 /* Declare an asm function, along with symbols needed to make it
inlineable */
 #define DECL_ASM(ret, name, ...)   \
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

[PATCH v2 1/2] xen: Silence compiler warnings

[Daniel Kiper]

Add inline keyword to silence the following compiler
warnings if xen_efi_probe() is not used:

  CC  arch/x86/xen/setup.o
In file included from arch/x86/xen/xen-ops.h:7:0,
 from arch/x86/xen/setup.c:31:
include/xen/xen-ops.h:43:35: warning: ‘xen_efi_probe’ defined but not used 
[-Wunused-function]

Signed-off-by: Daniel Kiper 
---
 include/xen/xen-ops.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 771bbba..7491ee5 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -40,7 +40,7 @@ bool xen_running_on_version_or_later(unsigned int major, 
unsigned int minor);
 #ifdef CONFIG_XEN_EFI
 extern efi_system_table_t *xen_efi_probe(void);
 #else
-static efi_system_table_t __init *xen_efi_probe(void)
+static inline efi_system_table_t __init *xen_efi_probe(void)
 {
return NULL;
 }
-- 
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 v2 0/2] xen: Silence compiler warnings

[Daniel Kiper]

Hi,

Here are two patches that follow earlier Xen dom0 EFI series and
fix some compiler warnings found during detailed build tests.

Both patches should be applied to:

git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git next

v2 contains fix suggested by Konrad Rzeszutek Wilk.

Daniel

PS I will be on vacation from 14th Jul till 25th Jul.

 arch/x86/xen/Makefile|1 +
 arch/x86/xen/efi.c   |   43 +++
 arch/x86/xen/enlighten.c |   15 +--
 arch/x86/xen/xen-ops.h   |8 
 include/xen/xen-ops.h|2 +-
 5 files changed, 54 insertions(+), 15 deletions(-)

Daniel Kiper (2):
  xen: Silence compiler warnings
  arch/x86/xen: Silence compiler warnings

--
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: bit fields && data tearing

[Oleg Nesterov]

OK, looks like this is compiler bug,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080

Thanks to Dan who informed me privately.

On 07/12, Oleg Nesterov wrote:
>
> Hello,
>
> I am not sure I should ask here, but since Documentation/memory-barriers.txt
> mentions load/store tearing perhaps my question is not completely off-topic...
>
> I am fighting with mysterious RHEL bug, it can be reproduced on ppc and s390
> but not on x86. Finally I seem to understand the problem, and I even wrote the
> stupid kernel module to ensure, see it below at the end.
>
> It triggers the problem immediately, kt_2() sees the wrong value in 
> freeze_stop.
> (If I turn ->freeze_stop int "long", the problem goes away).
>
> So the question is: is this gcc bug or the code below is buggy?
>
> If it is buggy, then probably memory-barriers.txt could mention that you 
> should
> be carefull with bit fields, even ACCESS_ONCE() obviously can't help.
>
> Or this just discloses my ignorance and you need at least aligned(long) after 
> a
> bit field to be thread-safe ? I thought that compiler should take care and add
> the necessary alignment if (say) CPU can't update a single byte/uint.
>
> gcc version 4.4.7 20120313 (Red Hat 4.4.7-9) (GCC). Asm:
>
>    <.kt_2>:
>  0:   7c 08 02 a6 mflrr0
>  4:   fb 81 ff e0 std r28,-32(r1)
>  8:   fb a1 ff e8 std r29,-24(r1)
>  c:   fb c1 ff f0 std r30,-16(r1)
> 10:   fb e1 ff f8 std r31,-8(r1)
> 14:   eb c2 00 00 ld  r30,0(r2)
> 18:   f8 01 00 10 std r0,16(r1)
> 1c:   f8 21 ff 71 stdur1,-144(r1)
> 20:   7c 7d 1b 78 mr  r29,r3
> 24:   3b e0 00 00 li  r31,0
> 28:   78 3c 04 64 rldicr  r28,r1,0,49
> 2c:   3b 9c 00 80 addir28,r28,128
> 30:   48 00 00 2c b   5c <.kt_2+0x5c>
> 34:   60 00 00 00 nop
> 38:   60 00 00 00 nop
> 3c:   60 00 00 00 nop
> 40:   93 fd 00 04 stw r31,4(r29)
> 44:   e8 9d 00 06 lwa r4,4(r29)
> 48:   7f 84 f8 00 cmpwcr7,r4,r31
> 4c:   40 de 00 4c bne-cr7,98 <.kt_2+0x98>
> 50:   e8 1c 00 00 ld  r0,0(r28)
> 54:   78 09 f7 e3 rldicl. r9,r0,62,63
> 58:   40 c2 00 54 bne-ac <.kt_2+0xac>
> 5c:   48 00 00 01 bl  5c <.kt_2+0x5c>
> 60:   60 00 00 00 nop
> 64:   3b ff 00 01 addir31,r31,1
> 68:   2f a3 00 00 cmpdi   cr7,r3,0
> 6c:   7f ff 07 b4 extsw   r31,r31
> 70:   41 9e ff d0 beq+cr7,40 <.kt_2+0x40>
> 74:   38 21 00 90 addir1,r1,144
> 78:   38 60 00 00 li  r3,0
> 7c:   e8 01 00 10 ld  r0,16(r1)
> 80:   eb 81 ff e0 ld  r28,-32(r1)
> 84:   eb a1 ff e8 ld  r29,-24(r1)
> 88:   eb c1 ff f0 ld  r30,-16(r1)
> 8c:   eb e1 ff f8 ld  r31,-8(r1)
> 90:   7c 08 03 a6 mtlrr0
> 94:   4e 80 00 20 blr
> 98:   e8 7e 80 28 ld  r3,-32728(r30)
> 9c:   7f e5 fb 78 mr  r5,r31
> a0:   48 00 00 01 bl  a0 <.kt_2+0xa0>
> a4:   60 00 00 00 nop
> a8:   4b ff ff a8 b   50 <.kt_2+0x50>
> ac:   48 00 00 01 bl  ac <.kt_2+0xac>
> b0:   60 00 00 00 nop
> b4:   4b ff ff a8 b   5c <.kt_2+0x5c>
> b8:   60 00 00 00 nop
> bc:   60 00 00 00 nop
>
>   00c0 <.kt_1>:
> c0:   7c 08 02 a6 mflrr0
> c4:   fb 81 ff e0 std r28,-32(r1)
> c8:   fb a1 ff e8 std r29,-24(r1)
> cc:   fb c1 ff f0 std r30,-16(r1)
> d0:   fb e1 ff f8 std r31,-8(r1)
> d4:   eb c2 00 00 ld  r30,0(r2)
> d8:   f8 01 00 10 std r0,16(r1)
> dc:   f8 21 ff 71 stdur1,-144(r1)
> e0:   7c 7d 1b 78 mr  r29,r3
> e4:   3b e0 00 00 li  r31,0
> e8:   78 3c 04 64 rldicr  r28,r1,0,49
> ec:   3b 9c 00 80 addir28,r28,128
> f0:   48 00 00 38 b   128 <.kt_1+0x68>
> f4:   60 00 00 00 nop
> f8:   60 00 00 00 nop
> fc:   60 00 00 00 nop
>100:   e8 1d 00 00 ld  r0,0(r29)
>104:   79 20 e8 0e rldimi  r0,r9,61,0
>108:   f8 1d 00 00 std r0,0(r29)
>10c:   80 1d 00 00 lwz r0,0(r29)
>110:   54 00 1f 7e rlwinm  r0,r0,3,29,31
>114:   7f 80 f8 00 cmpwcr7,r0,r31
>118:   40 de 00 6c bne-cr7,184 <.kt_1+0xc4>
>11c:   e8 1c 00 00 ld  r0,0(r28)
>120:   78 09 f7 e3 rldicl. r9,r0,62,63
>124:   40 c2 00 70 bne-194 <.kt_1+0xd4>
>128:   48 00 00 01 bl  128 <.kt_1+0x68>
>

[GIT PULL] TTY/Serial fixes for 3.16-rc5

[Greg KH]

The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:

  Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ 
tags/tty-3.16-rc5

for you to fetch changes up to 34c4eda809e1efb16c554c07bb5df4c8ace9424e:

  serial: sh-sci: Add device tree support for r8a7{778,740,3a4} and sh73a0 
(2014-07-11 17:45:12 -0700)


TTY/Serial fixes for 3.16-rc5

Here are some small serial fixes that resolve some reported problems
that started in 3.15 with some serial drivers.  And there's a new dt
binding for a serial driver, which was all that was needed for the
renesas serial driver.

Signed-off-by: Greg Kroah-Hartman 


Peter Hurley (3):
  serial: Test for no tx data on tx restart
  serial: arc_uart: Use uart_circ_empty() for open-coded comparison
  serial: imx: Fix build breakage

Simon Horman (1):
  serial: sh-sci: Add device tree support for r8a7{778,740,3a4} and sh73a0

 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 7 +++
 drivers/tty/serial/arc_uart.c   | 2 +-
 drivers/tty/serial/imx.c| 3 +++
 drivers/tty/serial/ip22zilog.c  | 2 ++
 drivers/tty/serial/m32r_sio.c   | 8 +---
 drivers/tty/serial/pmac_zilog.c | 3 +++
 drivers/tty/serial/sunsab.c | 3 +++
 drivers/tty/serial/sunzilog.c   | 2 ++
 8 files changed, 26 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] USB driver fixes for 3.16-rc5

[Greg KH]

The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:

  Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-3.16-rc5

for you to fetch changes up to eb82a3d846fab00c4b9ad6bbe5ade4fa5febc0af:

  phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove 
(2014-07-11 18:23:50 -0700)


USB fixes for 3.16-rc5

Here are some small USB fixes, PHY driver fixes (they ended up in this
tree for lack of somewhere else to put them), and some new USB device
ids.

Signed-off-by: Greg Kroah-Hartman 


Andras Kovacs (1):
  USB: cp210x: add support for Corsair usb dongle

Bernd Wachter (1):
  usb: option: Add ID for Telewell TW-LTE 4G v2

Bert Vermeulen (1):
  USB: ftdi_sio: Add extra PID.

Greg Kroah-Hartman (1):
  Merge tag 'usb-serial-3.16-rc5' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus

Himangi Saraogi (1):
  phy: omap-usb2: fix devm_ioremap_resource error detection code

Maxime Ripard (1):
  phy: sun4i: depend on RESET_CONTROLLER

Michal Sojka (1):
  USB: serial: ftdi_sio: Add Infineon Triboard

Roger Quadros (2):
  phy: core: Fix error path in phy_create()
  phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove

Sjoerd Simons (1):
  drivers: phy: phy-samsung-usb2.c: Add missing MODULE_DEVICE_TABLE

 drivers/phy/Kconfig   |  1 +
 drivers/phy/phy-core.c|  7 ---
 drivers/phy/phy-omap-usb2.c   | 11 +++
 drivers/phy/phy-samsung-usb2.c|  1 +
 drivers/usb/serial/cp210x.c   |  1 +
 drivers/usb/serial/ftdi_sio.c |  5 -
 drivers/usb/serial/ftdi_sio_ids.h |  9 -
 drivers/usb/serial/option.c   |  2 ++
 8 files changed, 28 insertions(+), 9 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] char/misc driver fixes for 3.16-rc5

[Greg KH]

The following changes since commit a497c3ba1d97fc69c1e78e7b96435ba8c2cb42ee:

  Linux 3.16-rc2 (2014-06-21 19:02:54 -1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-3.16-rc5

for you to fetch changes up to 6d827fbcc370ca259a2905309f64161ab7b10596:

  i8k: Fix non-SMP operation (2014-07-09 16:45:36 -0700)


char/misc driver fixes for 3.16-rc5

Here are 2 hyperv driver fixes, and one i8k driver fix for 3.16.

Signed-off-by: Greg Kroah-Hartman 


Guenter Roeck (1):
  i8k: Fix non-SMP operation

K. Y. Srinivasan (2):
  Drivers: hv: vmbus: Fix a bug in the channel callback dispatch code
  Drivers: hv: util: Fix a bug in the KVP code

 drivers/char/i8k.c  |  4 +++-
 drivers/hv/connection.c |  8 ++--
 drivers/hv/hv_kvp.c | 17 ++---
 drivers/hv/hv_util.c|  2 +-
 4 files changed, 24 insertions(+), 7 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] Staging driver fixes for 3.16-rc5

[Greg KH]

The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:

  Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-3.16-rc5

for you to fetch changes up to bdac8ca90e07edde8bbef5396784f7011e6e5b8d:

  Merge tag 'iio-fixes-for-3.16c' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus 
(2014-07-08 15:43:45 -0700)


Staging / IIO fixes for 3.16-rc5

Here are some IIO driver fixes for 3.16-rc5.  Nothing major, just
resolves some minor issues that have been reported.

Signed-off-by: Greg Kroah-Hartman 


Greg Kroah-Hartman (1):
  Merge tag 'iio-fixes-for-3.16c' of git://git.kernel.org/.../jic23/iio 
into staging-linus

Jan Kardell (1):
  iio: ti_am335x_adc: Fix: Use same step id at FIFOs both ends

Peter Meerwald (1):
  iio:tcs3472: Check for buffer enabled and locking

Sachin Kamat (6):
  iio: hid-sensor-press: Fix return values
  iio: hid-sensor-accel-3d: Fix return values
  iio: hid-sensor-magn-3d: Fix return values
  iio: hid-sensor-als: Fix return values
  iio: hid-sensor-gyro-3d: Fix return values
  iio: hid-sensor-prox: Fix return values

 drivers/iio/accel/hid-sensor-accel-3d.c   |  7 ++-
 drivers/iio/adc/ti_am335x_adc.c   |  2 +-
 drivers/iio/gyro/hid-sensor-gyro-3d.c |  7 ++-
 drivers/iio/light/hid-sensor-als.c|  7 ++-
 drivers/iio/light/hid-sensor-prox.c   |  7 ++-
 drivers/iio/light/tcs3472.c   | 11 ++-
 drivers/iio/magnetometer/hid-sensor-magn-3d.c |  7 ++-
 drivers/iio/pressure/hid-sensor-press.c   |  7 ++-
 8 files changed, 23 insertions(+), 32 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC[_RAW]

[Mathieu Desnoyers]

- Original Message -
> From: "Thomas Gleixner" 
> To: "Mathieu Desnoyers" 
> Cc: "LKML" , "John Stultz" 
> , "Peter Zijlstra"
> , "Steven Rostedt" 
> Sent: Saturday, July 12, 2014 4:04:59 PM
> Subject: Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to 
> CLOCK_MONOTONIC[_RAW]
> 
> On Sat, 12 Jul 2014, Thomas Gleixner wrote:
> > On Sat, 12 Jul 2014, Mathieu Desnoyers wrote:
> > > I'm perhaps missing something here, but what happens with the
> > > following scenario ?
> > > 
> > > Initial conditions:
> > > 
> > > tkf->seq = 0
> > > tkf->base[0] and tkf->base[1] are initialized.
> > > 
> > > CPU 0  CPU 1
> > >    
> > > update:
> > >   tkf->seq++
> > >   smb_wmb()
> > >   tkf->seq++ (reordered before update)
> > >reader:
> > >seq = tkf->seq (reads 2)
> > >smp_rmb()
> > >idx = seq & 0x01
> > >now = now(tkf->base[idx]
> > >(reads base[0])
> > >   update(tkf->base[0], tk) (racy concurrent update)
> > >smp_rmb()
> > >while (seq != tkf->seq) (they
> > >are equal)
> > > 
> > > So AFAIU, we end up returning a corrupted value. Adding a
> > > smp_wmb() between update of base[0] and increment of seq,
> > > as well as between update of base[1] and the _following_
> > > increment of seq (next update call) would fix this.
> > > 
> > > Thoughts ?
> 
> Second thoughts :)
> 
> > Well, the actual implementation does:
> > 
> > +   /* Force readers off to base[1] */
> > +   raw_write_seqcount_begin(>seq);
> 
> i.e:
>   seq++;
>   smp_wmb();
> 
> > +
> > +   /* Update base[0] */
> > +   base->clock = clk;
> > +   base->cycle_last = clk->cycle_last;
> > +   base->base = tbase;
> > +   base->shift = shift;
> > +   base->mult = mult;
> > +
> > +   /* Force readers back to base[0] */
> > +   raw_write_seqcount_end(>seq);
> 
> i.e:
>   smp_wmb();
>   seq++;
> 
> So while this orders against the update of base0, it does not prevent
> reordering against the update of base1. So you're right, we need a
> 
>   smp_wmb();
> 
> before we start updating base1.
> 
> > +   /* Update base[1] */
> > +   base++;
> > +   base->clock = clk;
> > +   base->cycle_last = clk->cycle_last;
> > +   base->base = tbase;
> > +   base->shift = shift;
> > +   base->mult = mult;
> 
> So as a consequence we need another one here:
> 
>   smp_wmb();
> 
> to protect against the unlikely, but possible seq++ at the begin of
> the update. Debatable whether this can happen without another wmb()
> between the two calls, but yes for sanity reasons we should add it
> until we can prove that the actual call chains prevent this.
> 
> Nice catch!

Thanks! Yep, the barriers you propose are what appears
to be missing,

Mathieu

> 
>  tglx
> 

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

[PATCH 2/2] pinctrl: remove all usage of gpio_remove ret val in driver/pinctl

[abdoulaye berthe]

Signed-off-by: abdoulaye berthe 
---
 drivers/pinctrl/pinctrl-adi2.c |  9 -
 drivers/pinctrl/pinctrl-as3722.c   | 11 ++-
 drivers/pinctrl/pinctrl-baytrail.c |  5 +
 drivers/pinctrl/pinctrl-coh901.c   | 10 ++
 drivers/pinctrl/pinctrl-rockchip.c | 16 
 drivers/pinctrl/sh-pfc/gpio.c  |  9 +++--
 drivers/pinctrl/spear/pinctrl-plgpio.c |  3 +--
 drivers/pinctrl/sunxi/pinctrl-sunxi.c  |  3 +--
 drivers/pinctrl/vt8500/pinctrl-wmt.c   |  9 ++---
 9 files changed, 20 insertions(+), 55 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-adi2.c b/drivers/pinctrl/pinctrl-adi2.c
index 46413e9..b092b93 100644
--- a/drivers/pinctrl/pinctrl-adi2.c
+++ b/drivers/pinctrl/pinctrl-adi2.c
@@ -949,7 +949,7 @@ static int adi_gpio_probe(struct platform_device *pdev)
struct gpio_port *port;
char pinctrl_devname[DEVNAME_SIZE];
static int gpio;
-   int ret = 0, ret1;
+   int ret = 0;
 
pdata = dev->platform_data;
if (!pdata)
@@ -1027,7 +1027,7 @@ static int adi_gpio_probe(struct platform_device *pdev)
return 0;
 
 out_remove_gpiochip:
-   ret1 = gpiochip_remove(>chip);
+   gpiochip_remove(>chip);
 out_remove_domain:
if (port->pint)
irq_domain_remove(port->domain);
@@ -1038,12 +1038,11 @@ out_remove_domain:
 static int adi_gpio_remove(struct platform_device *pdev)
 {
struct gpio_port *port = platform_get_drvdata(pdev);
-   int ret;
u8 offset;
 
list_del(>node);
gpiochip_remove_pin_ranges(>chip);
-   ret = gpiochip_remove(>chip);
+   gpiochip_remove(>chip);
if (port->pint) {
for (offset = 0; offset < port->width; offset++)
irq_dispose_mapping(irq_find_mapping(port->domain,
@@ -1051,7 +1050,7 @@ static int adi_gpio_remove(struct platform_device *pdev)
irq_domain_remove(port->domain);
}
 
-   return ret;
+   return 0;
 }
 
 static int adi_pinctrl_probe(struct platform_device *pdev)
diff --git a/drivers/pinctrl/pinctrl-as3722.c b/drivers/pinctrl/pinctrl-as3722.c
index c862f9c0..0e4ec91 100644
--- a/drivers/pinctrl/pinctrl-as3722.c
+++ b/drivers/pinctrl/pinctrl-as3722.c
@@ -565,7 +565,6 @@ static int as3722_pinctrl_probe(struct platform_device 
*pdev)
 {
struct as3722_pctrl_info *as_pci;
int ret;
-   int tret;
 
as_pci = devm_kzalloc(>dev, sizeof(*as_pci), GFP_KERNEL);
if (!as_pci)
@@ -611,10 +610,7 @@ static int as3722_pinctrl_probe(struct platform_device 
*pdev)
return 0;
 
 fail_range_add:
-   tret = gpiochip_remove(_pci->gpio_chip);
-   if (tret < 0)
-   dev_warn(>dev, "Couldn't remove gpio chip, %d\n", tret);
-
+   gpiochip_remove(_pci->gpio_chip);
 fail_chip_add:
pinctrl_unregister(as_pci->pctl);
return ret;
@@ -623,11 +619,8 @@ fail_chip_add:
 static int as3722_pinctrl_remove(struct platform_device *pdev)
 {
struct as3722_pctrl_info *as_pci = platform_get_drvdata(pdev);
-   int ret;
 
-   ret = gpiochip_remove(_pci->gpio_chip);
-   if (ret < 0)
-   return ret;
+   gpiochip_remove(_pci->gpio_chip);
pinctrl_unregister(as_pci->pctl);
return 0;
 }
diff --git a/drivers/pinctrl/pinctrl-baytrail.c 
b/drivers/pinctrl/pinctrl-baytrail.c
index 701a646..d8e9469 100644
--- a/drivers/pinctrl/pinctrl-baytrail.c
+++ b/drivers/pinctrl/pinctrl-baytrail.c
@@ -638,12 +638,9 @@ MODULE_DEVICE_TABLE(acpi, byt_gpio_acpi_match);
 static int byt_gpio_remove(struct platform_device *pdev)
 {
struct byt_gpio *vg = platform_get_drvdata(pdev);
-   int err;
 
pm_runtime_disable(>dev);
-   err = gpiochip_remove(>chip);
-   if (err)
-   dev_warn(>dev, "failed to remove gpio_chip.\n");
+   gpiochip_remove(>chip);
 
return 0;
 }
diff --git a/drivers/pinctrl/pinctrl-coh901.c b/drivers/pinctrl/pinctrl-coh901.c
index d182fdd..29cbbab 100644
--- a/drivers/pinctrl/pinctrl-coh901.c
+++ b/drivers/pinctrl/pinctrl-coh901.c
@@ -756,8 +756,7 @@ static int __init u300_gpio_probe(struct platform_device 
*pdev)
 
 err_no_range:
 err_no_irqchip:
-   if (gpiochip_remove(>chip))
-   dev_err(>dev, "failed to remove gpio chip\n");
+   gpiochip_remove(>chip);
 err_no_chip:
clk_disable_unprepare(gpio->clk);
dev_err(>dev, "module ERROR:%d\n", err);
@@ -767,16 +766,11 @@ err_no_chip:
 static int __exit u300_gpio_remove(struct platform_device *pdev)
 {
struct u300_gpio *gpio = platform_get_drvdata(pdev);
-   int err;
 
/* Turn off the GPIO block */
writel(0xU, gpio->base + U300_GPIO_CR);
 
-   err = gpiochip_remove(>chip);
-   if (err < 0) {
-   dev_err(gpio->dev, "unable to remove gpiochip: %d\n", err);
-   return err;
-   }
+   gpiochip_remove(>chip);
clk_disable_unprepare(gpio->clk);

[PATCH 0/3] remove all usage of gpio_remove retval

[abdoulaye berthe]

This removes all usage of gpio_remove retval
driver/gpio: 0001-gpio-remove-all-usage-of-gpio_remove-retval-in-drive
driver/pinctl: 0002-pinctrl-remove-all-usage-of-gpio_remove-ret-val-in-d
all the rest: 0003-driver-gpio-remove-all-usage-of-gpio_remove-retval-i

abdoulaye berthe (1):
  driver:gpio remove all usage of gpio_remove retval 

--
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] gpio: remove all usage of gpio_remove retval in driver/gpio

[abdoulaye berthe]

Signed-off-by: abdoulaye berthe 
---
 drivers/gpio/gpio-74x164.c |  8 +++-
 drivers/gpio/gpio-adnp.c   |  9 +
 drivers/gpio/gpio-adp5520.c|  8 +---
 drivers/gpio/gpio-adp5588.c|  6 +-
 drivers/gpio/gpio-amd8111.c|  3 +--
 drivers/gpio/gpio-arizona.c|  3 ++-
 drivers/gpio/gpio-cs5535.c |  8 +---
 drivers/gpio/gpio-da9052.c |  3 ++-
 drivers/gpio/gpio-da9055.c |  3 ++-
 drivers/gpio/gpio-dwapb.c  |  2 +-
 drivers/gpio/gpio-em.c |  5 +
 drivers/gpio/gpio-f7188x.c | 18 ++
 drivers/gpio/gpio-generic.c|  3 ++-
 drivers/gpio/gpio-grgpio.c |  4 +---
 drivers/gpio/gpio-ich.c|  9 +
 drivers/gpio/gpio-it8761e.c|  6 +-
 drivers/gpio/gpio-janz-ttl.c   |  8 +---
 drivers/gpio/gpio-kempld.c |  3 ++-
 drivers/gpio/gpio-lp3943.c |  3 ++-
 drivers/gpio/gpio-lynxpoint.c  |  5 +
 drivers/gpio/gpio-max730x.c| 13 -
 drivers/gpio/gpio-max732x.c|  7 +--
 drivers/gpio/gpio-mc33880.c| 11 +++
 drivers/gpio/gpio-mc9s08dz60.c |  3 ++-
 drivers/gpio/gpio-mcp23s08.c   | 26 +++---
 drivers/gpio/gpio-ml-ioh.c |  8 ++--
 drivers/gpio/gpio-msm-v2.c |  5 +
 drivers/gpio/gpio-mxc.c|  2 +-
 drivers/gpio/gpio-octeon.c |  3 ++-
 drivers/gpio/gpio-palmas.c |  3 ++-
 drivers/gpio/gpio-pca953x.c|  7 +--
 drivers/gpio/gpio-pcf857x.c|  4 +---
 drivers/gpio/gpio-pch.c| 10 ++
 drivers/gpio/gpio-rc5t583.c|  3 ++-
 drivers/gpio/gpio-rcar.c   |  5 +
 drivers/gpio/gpio-rdc321x.c|  7 ++-
 drivers/gpio/gpio-sch.c| 16 +++-
 drivers/gpio/gpio-sch311x.c|  6 ++
 drivers/gpio/gpio-sodaville.c  |  4 +---
 drivers/gpio/gpio-stmpe.c  |  8 +---
 drivers/gpio/gpio-sx150x.c |  7 ++-
 drivers/gpio/gpio-syscon.c |  3 ++-
 drivers/gpio/gpio-tb10x.c  |  5 +
 drivers/gpio/gpio-tc3589x.c|  8 +---
 drivers/gpio/gpio-timberdale.c |  5 +
 drivers/gpio/gpio-tps6586x.c   |  3 ++-
 drivers/gpio/gpio-tps65910.c   |  3 ++-
 drivers/gpio/gpio-tps65912.c   |  3 ++-
 drivers/gpio/gpio-ts5500.c |  6 +++---
 drivers/gpio/gpio-twl4030.c|  4 +---
 drivers/gpio/gpio-twl6040.c|  3 ++-
 drivers/gpio/gpio-ucb1400.c|  2 +-
 drivers/gpio/gpio-viperboard.c | 10 +++---
 drivers/gpio/gpio-vx855.c  |  3 +--
 drivers/gpio/gpio-wm831x.c |  3 ++-
 drivers/gpio/gpio-wm8350.c |  3 ++-
 drivers/gpio/gpio-wm8994.c |  3 ++-
 57 files changed, 100 insertions(+), 242 deletions(-)

diff --git a/drivers/gpio/gpio-74x164.c b/drivers/gpio/gpio-74x164.c
index e4ae298..e3d968f 100644
--- a/drivers/gpio/gpio-74x164.c
+++ b/drivers/gpio/gpio-74x164.c
@@ -167,13 +167,11 @@ exit_destroy:
 static int gen_74x164_remove(struct spi_device *spi)
 {
struct gen_74x164_chip *chip = spi_get_drvdata(spi);
-   int ret;
 
-   ret = gpiochip_remove(>gpio_chip);
-   if (!ret)
-   mutex_destroy(>lock);
+   gpiochip_remove(>gpio_chip);
+   mutex_destroy(>lock);
 
-   return ret;
+   return 0;
 }
 
 static const struct of_device_id gen_74x164_dt_ids[] = {
diff --git a/drivers/gpio/gpio-adnp.c b/drivers/gpio/gpio-adnp.c
index b2239d6..416b220 100644
--- a/drivers/gpio/gpio-adnp.c
+++ b/drivers/gpio/gpio-adnp.c
@@ -585,15 +585,8 @@ static int adnp_i2c_remove(struct i2c_client *client)
 {
struct adnp *adnp = i2c_get_clientdata(client);
struct device_node *np = client->dev.of_node;
-   int err;
-
-   err = gpiochip_remove(>gpio);
-   if (err < 0) {
-   dev_err(>dev, "%s failed: %d\n", "gpiochip_remove()",
-   err);
-   return err;
-   }
 
+   gpiochip_remove(>gpio);
if (of_find_property(np, "interrupt-controller", NULL))
adnp_irq_teardown(adnp);
 
diff --git a/drivers/gpio/gpio-adp5520.c b/drivers/gpio/gpio-adp5520.c
index f1ade8f..b08bd16 100644
--- a/drivers/gpio/gpio-adp5520.c
+++ b/drivers/gpio/gpio-adp5520.c
@@ -167,15 +167,9 @@ err:
 static int adp5520_gpio_remove(struct platform_device *pdev)
 {
struct adp5520_gpio *dev;
-   int ret;
 
dev = platform_get_drvdata(pdev);
-   ret = gpiochip_remove(>gpio_chip);
-   if (ret) {
-   dev_err(>dev, "%s failed, %d\n",
-   "gpiochip_remove()", ret);
-   return ret;
-   }
+   gpiochip_remove(>gpio_chip);
 
return 0;
 }
diff --git a/drivers/gpio/gpio-adp5588.c b/drivers/gpio/gpio-adp5588.c
index ef19bc3..3beed6e 100644
--- a/drivers/gpio/gpio-adp5588.c
+++ b/drivers/gpio/gpio-adp5588.c
@@ -470,11 +470,7 @@ static int adp5588_gpio_remove(struct i2c_client *client)
if (dev->irq_base)
free_irq(dev->client->irq, dev);
 
-   ret = gpiochip_remove(>gpio_chip);
-   if (ret) {
-   dev_err(>dev, "gpiochip_remove failed %d\n", ret);
-

[PATCH 3/3] driver:gpio remove all usage of gpio_remove retval in driver

[abdoulaye berthe]

this remove all reference to gpio_remove retval in all driver
except pinctrl and gpio. the same thing is done for gpio and
pinctrl in two different patches.

Signed-off-by: abdoulaye berthe 
---
 arch/arm/common/scoop.c| 10 ++
 arch/mips/txx9/generic/setup.c |  4 ++--
 arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c |  3 ++-
 arch/sh/boards/mach-x3proto/gpio.c |  6 ++
 drivers/bcma/driver_gpio.c |  3 ++-
 drivers/hid/hid-cp2112.c   |  6 ++
 drivers/input/keyboard/adp5588-keys.c  |  4 +---
 drivers/input/keyboard/adp5589-keys.c  |  4 +---
 drivers/input/touchscreen/ad7879.c | 10 +++---
 drivers/leds/leds-pca9532.c| 10 ++
 drivers/leds/leds-tca6507.c|  7 ++-
 drivers/media/dvb-frontends/cxd2820r_core.c| 10 +++---
 drivers/mfd/asic3.c|  3 ++-
 drivers/mfd/htc-i2cpld.c   |  8 +---
 drivers/mfd/sm501.c| 17 +++--
 drivers/mfd/tc6393xb.c | 13 -
 drivers/mfd/ucb1x00-core.c |  8 ++--
 drivers/pinctrl/pinctrl-abx500.c   | 15 +++
 drivers/pinctrl/pinctrl-exynos5440.c   |  6 +-
 drivers/pinctrl/pinctrl-msm.c  | 10 +++---
 drivers/pinctrl/pinctrl-nomadik.c  |  2 +-
 drivers/pinctrl/pinctrl-samsung.c  | 14 --
 drivers/platform/x86/intel_pmic_gpio.c |  3 +--
 drivers/ssb/driver_gpio.c  |  3 ++-
 drivers/staging/vme/devices/vme_pio2_gpio.c|  4 +---
 drivers/tty/serial/max310x.c   | 10 --
 drivers/video/fbdev/via/via-gpio.c | 10 +++---
 sound/soc/codecs/wm5100.c  |  5 +
 sound/soc/codecs/wm8903.c  |  6 +-
 sound/soc/codecs/wm8962.c  |  5 +
 sound/soc/codecs/wm8996.c  |  6 +-
 31 files changed, 63 insertions(+), 162 deletions(-)

diff --git a/arch/arm/common/scoop.c b/arch/arm/common/scoop.c
index 6ef146e..5881c9c 100644
--- a/arch/arm/common/scoop.c
+++ b/arch/arm/common/scoop.c
@@ -244,18 +244,12 @@ err_ioremap:
 static int scoop_remove(struct platform_device *pdev)
 {
struct scoop_dev *sdev = platform_get_drvdata(pdev);
-   int ret;
 
if (!sdev)
return -EINVAL;
 
-   if (sdev->gpio.base != -1) {
-   ret = gpiochip_remove(>gpio);
-   if (ret) {
-   dev_err(>dev, "Can't remove gpio chip: %d\n", 
ret);
-   return ret;
-   }
-   }
+   if (sdev->gpio.base != -1)
+   gpiochip_remove(>gpio);
 
platform_set_drvdata(pdev, NULL);
iounmap(sdev->base);
diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c
index dd2cf25..49be896 100644
--- a/arch/mips/txx9/generic/setup.c
+++ b/arch/mips/txx9/generic/setup.c
@@ -789,11 +789,11 @@ void __init txx9_iocled_init(unsigned long baseaddr,
if (platform_device_add(pdev))
goto out_pdev;
return;
+
 out_pdev:
platform_device_put(pdev);
 out_gpio:
-   if (gpiochip_remove(>chip))
-   return;
+   gpiochip_remove(>chip);
 out_unmap:
iounmap(iocled->mmioaddr);
 out_free:
diff --git a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c 
b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
index e238b6a..7399702 100644
--- a/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
+++ b/arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c
@@ -141,7 +141,8 @@ static int mcu_gpiochip_add(struct mcu *mcu)
 
 static int mcu_gpiochip_remove(struct mcu *mcu)
 {
-   return gpiochip_remove(>gc);
+   gpiochip_remove(>gc);
+   return 0;
 }
 
 static int mcu_probe(struct i2c_client *client, const struct i2c_device_id *id)
diff --git a/arch/sh/boards/mach-x3proto/gpio.c 
b/arch/sh/boards/mach-x3proto/gpio.c
index 3ea65e9..f035a7a 100644
--- a/arch/sh/boards/mach-x3proto/gpio.c
+++ b/arch/sh/boards/mach-x3proto/gpio.c
@@ -128,10 +128,8 @@ int __init x3proto_gpio_setup(void)
return 0;
 
 err_irq:
-   ret = gpiochip_remove(_gpio_chip);
-   if (unlikely(ret))
-   pr_err("Failed deregistering GPIO\n");
-
+   gpiochip_remove(_gpio_chip);
+   ret = 0;
 err_gpio:
synchronize_irq(ilsel);
 
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index d7f81ad..7dd70a7 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -250,5 +250,6 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
 int bcma_gpio_unregister(struct bcma_drv_cc *cc)
 {
bcma_gpio_irq_domain_exit(cc);
-   return gpiochip_remove(>gpio);
+   gpiochip_remove(>gpio);
+   return 0;
 }
diff --git a/drivers/hid/hid-cp2112.c 

[PATCH v2] lib/Kconfig.debug: introduce CONFIG_CC_STACK_USAGE

[Konstantin Khlebnikov]

This patch adds option for collecting stack usage statistics
via gcc option '-fstack-usage' (needs gcc 4.6 or newer).
For each .o file gcc dumps stack-frame sizes into .su file.

File format:
::: 

select.c:870:5:do_sys_poll  1040static
rtnetlink.c:1880:12:rtnl_newlink552 dynamic
random.c:1334:1:random_read 664 dynamic,bounded

Quote from the gcc manpage about qualifiers:

The qualifier "static" means that the function
manipulates the stack statically: a fixed number of bytes
are allocated for the frame on function entry and
released on function exit; no stack adjustments are
otherwise made in the function.  The second field is this
fixed number of bytes.

The qualifier "dynamic" means that the function
manipulates the stack dynamically: in addition to the
static allocation described above, stack adjustments are
made in the body of the function, for example to push/pop
arguments around function calls.  If the qualifier
"bounded" is also present, the amount of these
adjustments is bounded at compile time and the second
field is an upper bound of the total amount of stack used
by the function.  If it is not present, the amount of
these adjustments is not bounded at compile time and the
second field only represents the bounded part.

In comparison to the scripts/checkstack.pl this method is more accurate.
It takes into account function arguments, push/pop pairs, frame
pointers and saved return address. It gives information about all
functions except purely assember (for example sha1_transform_avx2).

Also this patch adds make target 'stack-usage' which combines all .su
files into one sorted 'stack-usage'. Also prints top 100 and all unbounded
dynamic stack frames.

Signed-off-by: Konstantin Khlebnikov 
---
 .gitignore|3 +++
 Makefile  |   23 ++-
 lib/Kconfig.debug |9 +
 3 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/.gitignore b/.gitignore
index f4c0b09..96b8984 100644
--- a/.gitignore
+++ b/.gitignore
@@ -85,6 +85,9 @@ GTAGS
 *~
 \#*#
 
+*.su
+/stack-usage
+
 #
 # Leavings from module signing
 #
diff --git a/Makefile b/Makefile
index 2167084..29fe588 100644
--- a/Makefile
+++ b/Makefile
@@ -635,6 +635,11 @@ ifneq ($(CONFIG_FRAME_WARN),0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
 endif
 
+ifdef CONFIG_CC_STACK_USAGE
+KBUILD_CFLAGS += $(call cc-option,-fstack-usage)
+endif
+CLEAN_FILES += stack-usage
+
 # Handle stack protector mode.
 ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
   stackp-flag := -fstack-protector
@@ -1228,6 +1233,7 @@ help:
 echo  ''
@echo  'Static analysers'
@echo  '  checkstack  - Generate a list of stack hogs'
+   @echo  '  stack-usage - Alternative list of stack hogs'
@echo  '  namespacecheck  - Name space analysis on compiled kernel'
@echo  '  versioncheck- Sanity check on version.h usage'
@echo  '  includecheck- Check for duplicate included header files'
@@ -1376,7 +1382,7 @@ clean: $(clean-dirs)
$(call cmd,rmfiles)
@find $(if $(KBUILD_EXTMOD), $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
\( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
-   -o -name '*.ko.*' \
+   -o -name '*.ko.*' -o -name '*.su' \
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.symtypes' -o -name 'modules.order' \
-o -name modules.builtin -o -name '.tmp_*.o.*' \
@@ -1432,6 +1438,21 @@ checkstack:
$(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
$(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)
 
+quiet_cmd_cc_stack_usage = SORTING $@
+cmd_cc_stack_usage = find -name '*.su' | xargs cat | sort -k 2 -n -r > $@
+
+stack-usage: FORCE
+ifndef CONFIG_CC_STACK_USAGE
+   $(Q)echo >&2 'Please rebuild with CONFIG_CC_STACK_USAGE=y' && false
+endif
+   $(call cmd,cc_stack_usage)
+   $(Q)echo ''
+   $(Q)echo 'Unbounded dynamic stack frames:'
+   $(Q)grep '\bdynamic$$' $@ || true
+   $(Q)echo ''
+   $(Q)echo 'Top 100 stack frames:'
+   $(Q)head -100 < $@
+
 kernelrelease:
@echo "$(KERNELVERSION)$$($(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree))"
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 7a638aa..3b30853 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -170,6 +170,15 @@ config FRAME_WARN
  Setting it to 0 disables the warning.
  Requires gcc 4.4
 
+config CC_STACK_USAGE
+   bool "Collect statistics about stack usage (needs gcc 4.6)"
+   help
+ This enables gcc option -fstack-usage which saves information
+ about stack frames in per-function basis into '.su' files.
+
+ Run 'make stack-usage' after building kernel and modules to
+ combine all information in one file.
+
 config 

Re: [PATCH] media: em28xx-dvb - fix em28xx_dvb_resume() to not unregister i2c and dvb

[Antti Palosaari]

Reviewed-by: Antti Palosaari 

Antti

On 07/09/2014 04:21 PM, Shuah Khan wrote:

em28xx_dvb_resume() unregisters i2c tuner, i2c demod, and dvb.
This erroneous cleanup results in i2c tuner, i2c demod, and dvb
devices unregistered and removed during resume. This error is a
result of merge conflict between two patches that went into 3.15.

Signed-off-by: Shuah Khan 
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   17 -
  1 file changed, 17 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a121ed9..d381861 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1712,7 +1712,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
em28xx_info("Resuming DVB extension");
if (dev->dvb) {
struct em28xx_dvb *dvb = dev->dvb;
-   struct i2c_client *client = dvb->i2c_client_tuner;

if (dvb->fe[0]) {
ret = dvb_frontend_resume(dvb->fe[0]);
@@ -1723,22 +1722,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
ret = dvb_frontend_resume(dvb->fe[1]);
em28xx_info("fe1 resume %d", ret);
}
-   /* remove I2C tuner */
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
-   /* remove I2C demod */
-   client = dvb->i2c_client_demod;
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
-   em28xx_unregister_dvb(dvb);
-   kfree(dvb);
-   dev->dvb = NULL;
}

return 0;



--
http://palosaari.fi/
--
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: android: Cleanup style issues

[Greg KH]

On Sat, Jul 12, 2014 at 01:23:10PM -0700, Greg KH wrote:
> On Sat, Jul 12, 2014 at 09:55:56PM +0200, Peter Senna Tschudin wrote:
> > This patch fixes the following checkpatch warnings:
> >  - Remove else after return
> >  - Add space after declaration
> > 
> > Tested by compilation only.
> > 
> > Signed-off-by: Peter Senna Tschudin 
> > ---
> >  drivers/staging/android/sync_debug.c | 11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> This file is no longer in my kernel tree, what tree did you make it
> against?
> 
> Please create staging patches against the staging-next branch of the
> staging.git tree on git.kernel.org so that I can apply them.

Ah, nevermind, things moved around here, I figured this out, sorry for
the noise...

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] media: em28xx - add error handling for KWORLD dvb_attach failures

[Antti Palosaari]

Looks correct!
All the other devices, excluding those few PCTV ones I have added, has 
that same bug... Deadlocks if tuner attach fails.


Reviewed-by: Antti Palosaari 

regards
Antti


On 07/09/2014 11:36 PM, Shuah Khan wrote:

Add error hanlding when EM2870_BOARD_KWORLD_A340 dvb_attach()
for fe and tuner fail in em28xx_dvb_init().

Signed-off-by: Shuah Khan 
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index d381861..8314f51 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1213,9 +1213,17 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb->fe[0] = dvb_attach(lgdt3305_attach,
   _lgdt3304_dev,
   >i2c_adap[dev->def_i2c_bus]);
-   if (dvb->fe[0] != NULL)
-   dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
-  >i2c_adap[dev->def_i2c_bus], 
_a340_config);
+   if (!dvb->fe[0]) {
+   result = -EINVAL;
+   goto out_free;
+   }
+   if (!dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
+   >i2c_adap[dev->def_i2c_bus],
+   _a340_config)) {
+   dvb_frontend_detach(dvb->fe[0]);
+   result = -EINVAL;
+   goto out_free;
+   }
break;
case EM28174_BOARD_PCTV_290E:
/* set default GPIO0 for LNA, used if GPIOLIB is undefined */



--
http://palosaari.fi/
--
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: android: Cleanup style issues

[Greg KH]

On Sat, Jul 12, 2014 at 09:55:56PM +0200, Peter Senna Tschudin wrote:
> This patch fixes the following checkpatch warnings:
>  - Remove else after return
>  - Add space after declaration
> 
> Tested by compilation only.
> 
> Signed-off-by: Peter Senna Tschudin 
> ---
>  drivers/staging/android/sync_debug.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

This file is no longer in my kernel tree, what tree did you make it
against?

Please create staging patches against the staging-next branch of the
staging.git tree on git.kernel.org so that I can apply them.

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] media: em28xx-dvb unregister i2c tuner and demod after fe detach

[Antti Palosaari]

Moikka Shuah!
I suspect that patch makes no sense. On DVB there is runtime PM 
controlled by DVB frontend. It wakes up all FE sub-devices when frontend 
device is opened and sleeps when closed.


FE release() is not relevant at all for those sub-devices which are 
implemented as a proper I2C client. I2C client has own remove() for that.


em28xx_dvb_init and em28xx_dvb_fini are counterparts. Those I2C drivers 
are load on em28xx_dvb_init so logical place for unload is em28xx_dvb_fini.


Is there some real use case you need that change?

regards
Antti


On 07/11/2014 06:45 PM, Shuah Khan wrote:

i2c tuner and demod are unregisetred in .fini before fe detach.
dvb_unregister_frontend() and dvb_frontend_detach() invoke tuner
sleep() and release() interfaces. Change to unregister i2c tuner
and demod from em28xx_unregister_dvb() after unregistering dvb
and detaching fe.

Signed-off-by: Shuah Khan 
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   32 +---
  1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 8314f51..8d5cb62 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1030,6 +1030,8 @@ fail_adapter:

  static void em28xx_unregister_dvb(struct em28xx_dvb *dvb)
  {
+   struct i2c_client *client;
+
dvb_net_release(>net);
dvb->demux.dmx.remove_frontend(>demux.dmx, >fe_mem);
dvb->demux.dmx.remove_frontend(>demux.dmx, >fe_hw);
@@ -1041,6 +1043,21 @@ static void em28xx_unregister_dvb(struct em28xx_dvb *dvb)
if (dvb->fe[1] && !dvb->dont_attach_fe1)
dvb_frontend_detach(dvb->fe[1]);
dvb_frontend_detach(dvb->fe[0]);
+
+   /* remove I2C tuner */
+   client = dvb->i2c_client_tuner;
+   if (client) {
+   module_put(client->dev.driver->owner);
+   i2c_unregister_device(client);
+   }
+
+   /* remove I2C demod */
+   client = dvb->i2c_client_demod;
+   if (client) {
+   module_put(client->dev.driver->owner);
+   i2c_unregister_device(client);
+   }
+
dvb_unregister_adapter(>adapter);
  }

@@ -1628,7 +1645,6 @@ static inline void prevent_sleep(struct dvb_frontend_ops 
*ops)
  static int em28xx_dvb_fini(struct em28xx *dev)
  {
struct em28xx_dvb *dvb;
-   struct i2c_client *client;

if (dev->is_audio_only) {
/* Shouldn't initialize IR for this interface */
@@ -1646,7 +1662,6 @@ static int em28xx_dvb_fini(struct em28xx *dev)
em28xx_info("Closing DVB extension");

dvb = dev->dvb;
-   client = dvb->i2c_client_tuner;

em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE);

@@ -1659,19 +1674,6 @@ static int em28xx_dvb_fini(struct em28xx *dev)
prevent_sleep(>fe[1]->ops);
}

-   /* remove I2C tuner */
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
-   /* remove I2C demod */
-   client = dvb->i2c_client_demod;
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
em28xx_unregister_dvb(dvb);
kfree(dvb);
dev->dvb = NULL;



--
http://palosaari.fi/
--
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] lib/Kconfig.debug: introduce CONFIG_CC_STACK_USAGE

[Konstantin Khlebnikov]

Damn, I forget to add them to the .gitignore

On Sun, Jul 13, 2014 at 12:01 AM, Konstantin Khlebnikov
 wrote:
> This patch adds option for collecting stack usage statistics
> via gcc option '-fstack-usage' (needs gcc 4.6 or newer).
> For each .o file gcc dumps stack-frame sizes into .su file.
>
> File format:
> ::: 
>
> select.c:870:5:do_sys_poll  1040static
> rtnetlink.c:1880:12:rtnl_newlink552 dynamic
> random.c:1334:1:random_read 664 dynamic,bounded
>
> Quote from the gcc manpage about qualifiers:
>
> The qualifier "static" means that the function
> manipulates the stack statically: a fixed number of bytes
> are allocated for the frame on function entry and
> released on function exit; no stack adjustments are
> otherwise made in the function.  The second field is this
> fixed number of bytes.
>
> The qualifier "dynamic" means that the function
> manipulates the stack dynamically: in addition to the
> static allocation described above, stack adjustments are
> made in the body of the function, for example to push/pop
> arguments around function calls.  If the qualifier
> "bounded" is also present, the amount of these
> adjustments is bounded at compile time and the second
> field is an upper bound of the total amount of stack used
> by the function.  If it is not present, the amount of
> these adjustments is not bounded at compile time and the
> second field only represents the bounded part.
>
> In comparison to the scripts/checkstack.pl this method is more accurate.
> It takes into account function arguments, push/pop pairs, frame
> pointers and saved return address. It gives information about all
> functions except purely assember (for example sha1_transform_avx2).
>
> Also this patch adds make target 'stack-usage' which combines all .su
> files into one sorted 'stack-usage'. Also prints top 100 and all unbounded
> dynamic stack frames.
>
> Signed-off-by: Konstantin Khlebnikov 
> ---
>  Makefile  |   22 +-
>  lib/Kconfig.debug |9 +
>  2 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 2167084..9ba61ee 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -635,6 +635,10 @@ ifneq ($(CONFIG_FRAME_WARN),0)
>  KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
>  endif
>
> +ifdef CONFIG_CC_STACK_USAGE
> +KBUILD_CFLAGS += $(call cc-option,-fstack-usage)
> +endif
> +
>  # Handle stack protector mode.
>  ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
>stackp-flag := -fstack-protector
> @@ -1228,6 +1232,7 @@ help:
>  echo  ''
> @echo  'Static analysers'
> @echo  '  checkstack  - Generate a list of stack hogs'
> +   @echo  '  stack-usage - Alternative list of stack hogs'
> @echo  '  namespacecheck  - Name space analysis on compiled kernel'
> @echo  '  versioncheck- Sanity check on version.h usage'
> @echo  '  includecheck- Check for duplicate included header files'
> @@ -1376,7 +1381,7 @@ clean: $(clean-dirs)
> $(call cmd,rmfiles)
> @find $(if $(KBUILD_EXTMOD), $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
> \( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
> -   -o -name '*.ko.*' \
> +   -o -name '*.ko.*' -o -name '*.su' \
> -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
> -o -name '*.symtypes' -o -name 'modules.order' \
> -o -name modules.builtin -o -name '.tmp_*.o.*' \
> @@ -1432,6 +1437,21 @@ checkstack:
> $(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
> $(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)
>
> +quiet_cmd_cc_stack_usage = SORTING $@
> +cmd_cc_stack_usage = find -name '*.su' | xargs cat | sort -k 2 -n -r > $@
> +
> +stack-usage: FORCE
> +ifndef CONFIG_CC_STACK_USAGE
> +   $(Q)echo >&2 'Please rebuild with CONFIG_CC_STACK_USAGE=y' && false
> +endif
> +   $(call cmd,cc_stack_usage)
> +   $(Q)echo ''
> +   $(Q)echo 'Unbounded dynamic stack frames:'
> +   $(Q)grep '\bdynamic$$' $@
> +   $(Q)echo ''
> +   $(Q)echo 'Top 100 stack frames:'
> +   $(Q)head -100 < $@
> +
>  kernelrelease:
> @echo "$(KERNELVERSION)$$($(CONFIG_SHELL) 
> $(srctree)/scripts/setlocalversion $(srctree))"
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 7a638aa..3b30853 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -170,6 +170,15 @@ config FRAME_WARN
>   Setting it to 0 disables the warning.
>   Requires gcc 4.4
>
> +config CC_STACK_USAGE
> +   bool "Collect statistics about stack usage (needs gcc 4.6)"
> +   help
> + This enables gcc option -fstack-usage which saves information
> + about stack frames in per-function basis into '.su' files.
> +
> + Run 'make stack-usage' after building kernel and modules to
> +   

Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC[_RAW]

[Thomas Gleixner]

On Sat, 12 Jul 2014, Thomas Gleixner wrote:
> On Sat, 12 Jul 2014, Mathieu Desnoyers wrote:
> > I'm perhaps missing something here, but what happens with the
> > following scenario ?
> > 
> > Initial conditions:
> > 
> > tkf->seq = 0
> > tkf->base[0] and tkf->base[1] are initialized.
> > 
> > CPU 0  CPU 1
> >    
> > update:
> >   tkf->seq++
> >   smb_wmb()
> >   tkf->seq++ (reordered before update)
> >reader:
> >seq = tkf->seq (reads 2)
> >smp_rmb()
> >idx = seq & 0x01
> >now = now(tkf->base[idx]   
> > (reads base[0])
> >   update(tkf->base[0], tk) (racy concurrent update)
> >smp_rmb()
> >while (seq != tkf->seq) (they 
> > are equal)
> > 
> > So AFAIU, we end up returning a corrupted value. Adding a
> > smp_wmb() between update of base[0] and increment of seq,
> > as well as between update of base[1] and the _following_
> > increment of seq (next update call) would fix this.
> > 
> > Thoughts ?

Second thoughts :)

> Well, the actual implementation does:
> 
> +   /* Force readers off to base[1] */
> +   raw_write_seqcount_begin(>seq);

i.e:
seq++;
smp_wmb();

> +
> +   /* Update base[0] */
> +   base->clock = clk;
> +   base->cycle_last = clk->cycle_last;
> +   base->base = tbase;
> +   base->shift = shift;
> +   base->mult = mult;
> +
> +   /* Force readers back to base[0] */
> +   raw_write_seqcount_end(>seq);

i.e:
smp_wmb();
seq++;

So while this orders against the update of base0, it does not prevent
reordering against the update of base1. So you're right, we need a

smp_wmb();

before we start updating base1.

> +   /* Update base[1] */
> +   base++;
> +   base->clock = clk;
> +   base->cycle_last = clk->cycle_last;
> +   base->base = tbase;
> +   base->shift = shift;
> +   base->mult = mult;

So as a consequence we need another one here:

smp_wmb();

to protect against the unlikely, but possible seq++ at the begin of
the update. Debatable whether this can happen without another wmb()
between the two calls, but yes for sanity reasons we should add it
until we can prove that the actual call chains prevent this.

Nice catch!

 tglx
--
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] lib/Kconfig.debug: introduce CONFIG_CC_STACK_USAGE

[Konstantin Khlebnikov]

This patch adds option for collecting stack usage statistics
via gcc option '-fstack-usage' (needs gcc 4.6 or newer).
For each .o file gcc dumps stack-frame sizes into .su file.

File format:
::: 

select.c:870:5:do_sys_poll  1040static
rtnetlink.c:1880:12:rtnl_newlink552 dynamic
random.c:1334:1:random_read 664 dynamic,bounded

Quote from the gcc manpage about qualifiers:

The qualifier "static" means that the function
manipulates the stack statically: a fixed number of bytes
are allocated for the frame on function entry and
released on function exit; no stack adjustments are
otherwise made in the function.  The second field is this
fixed number of bytes.

The qualifier "dynamic" means that the function
manipulates the stack dynamically: in addition to the
static allocation described above, stack adjustments are
made in the body of the function, for example to push/pop
arguments around function calls.  If the qualifier
"bounded" is also present, the amount of these
adjustments is bounded at compile time and the second
field is an upper bound of the total amount of stack used
by the function.  If it is not present, the amount of
these adjustments is not bounded at compile time and the
second field only represents the bounded part.

In comparison to the scripts/checkstack.pl this method is more accurate.
It takes into account function arguments, push/pop pairs, frame
pointers and saved return address. It gives information about all
functions except purely assember (for example sha1_transform_avx2).

Also this patch adds make target 'stack-usage' which combines all .su
files into one sorted 'stack-usage'. Also prints top 100 and all unbounded
dynamic stack frames.

Signed-off-by: Konstantin Khlebnikov 
---
 Makefile  |   22 +-
 lib/Kconfig.debug |9 +
 2 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 2167084..9ba61ee 100644
--- a/Makefile
+++ b/Makefile
@@ -635,6 +635,10 @@ ifneq ($(CONFIG_FRAME_WARN),0)
 KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
 endif
 
+ifdef CONFIG_CC_STACK_USAGE
+KBUILD_CFLAGS += $(call cc-option,-fstack-usage)
+endif
+
 # Handle stack protector mode.
 ifdef CONFIG_CC_STACKPROTECTOR_REGULAR
   stackp-flag := -fstack-protector
@@ -1228,6 +1232,7 @@ help:
 echo  ''
@echo  'Static analysers'
@echo  '  checkstack  - Generate a list of stack hogs'
+   @echo  '  stack-usage - Alternative list of stack hogs'
@echo  '  namespacecheck  - Name space analysis on compiled kernel'
@echo  '  versioncheck- Sanity check on version.h usage'
@echo  '  includecheck- Check for duplicate included header files'
@@ -1376,7 +1381,7 @@ clean: $(clean-dirs)
$(call cmd,rmfiles)
@find $(if $(KBUILD_EXTMOD), $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
\( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \
-   -o -name '*.ko.*' \
+   -o -name '*.ko.*' -o -name '*.su' \
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.symtypes' -o -name 'modules.order' \
-o -name modules.builtin -o -name '.tmp_*.o.*' \
@@ -1432,6 +1437,21 @@ checkstack:
$(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
$(PERL) $(src)/scripts/checkstack.pl $(CHECKSTACK_ARCH)
 
+quiet_cmd_cc_stack_usage = SORTING $@
+cmd_cc_stack_usage = find -name '*.su' | xargs cat | sort -k 2 -n -r > $@
+
+stack-usage: FORCE
+ifndef CONFIG_CC_STACK_USAGE
+   $(Q)echo >&2 'Please rebuild with CONFIG_CC_STACK_USAGE=y' && false
+endif
+   $(call cmd,cc_stack_usage)
+   $(Q)echo ''
+   $(Q)echo 'Unbounded dynamic stack frames:'
+   $(Q)grep '\bdynamic$$' $@
+   $(Q)echo ''
+   $(Q)echo 'Top 100 stack frames:'
+   $(Q)head -100 < $@
+
 kernelrelease:
@echo "$(KERNELVERSION)$$($(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree))"
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 7a638aa..3b30853 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -170,6 +170,15 @@ config FRAME_WARN
  Setting it to 0 disables the warning.
  Requires gcc 4.4
 
+config CC_STACK_USAGE
+   bool "Collect statistics about stack usage (needs gcc 4.6)"
+   help
+ This enables gcc option -fstack-usage which saves information
+ about stack frames in per-function basis into '.su' files.
+
+ Run 'make stack-usage' after building kernel and modules to
+ combine all information in one file.
+
 config STRIP_ASM_SYMS
bool "Strip assembler-generated symbols during link"
default n

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

[PATCH 1/1] doc: fix docbook generation

[Pranith Kumar]

kernel/timer.c and kernel/hrtimer.c have moved to kernel/time directory. This
causes docbook generation to fail. The following commit fixes it by updating the
references.

Signed-off-by: Pranith Kumar 
---
 Documentation/DocBook/device-drivers.tmpl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index dd3f278..f213058 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -54,7 +54,7 @@
 !Ikernel/sched/cpupri.c
 !Ikernel/sched/fair.c
 !Iinclude/linux/completion.h
-!Ekernel/timer.c
+!Ekernel/time/timer.c
  
  Wait queues and Wake events
 !Iinclude/linux/wait.h
@@ -63,7 +63,7 @@
  High-resolution timers
 !Iinclude/linux/ktime.h
 !Iinclude/linux/hrtimer.h
-!Ekernel/hrtimer.c
+!Ekernel/time/hrtimer.c
  
  Workqueues and Kevents
 !Ekernel/workqueue.c
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: android: Cleanup style issues

[Peter Senna Tschudin]

This patch fixes the following checkpatch warnings:
 - Remove else after return
 - Add space after declaration

Tested by compilation only.

Signed-off-by: Peter Senna Tschudin 
---
 drivers/staging/android/sync_debug.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index a9f7fd5..257fc91 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -74,10 +74,11 @@ static const char *sync_status_str(int status)
 {
if (status == 0)
return "signaled";
-   else if (status > 0)
+
+   if (status > 0)
return "active";
-   else
-   return "error";
+
+   return "error";
 }
 
 static void sync_print_pt(struct seq_file *s, struct sync_pt *pt, bool fence)
@@ -95,12 +96,14 @@ static void sync_print_pt(struct seq_file *s, struct 
sync_pt *pt, bool fence)
 
if (status <= 0) {
struct timeval tv = ktime_to_timeval(pt->base.timestamp);
+
seq_printf(s, "@%ld.%06ld", tv.tv_sec, tv.tv_usec);
}
 
if (parent->ops->timeline_value_str &&
parent->ops->pt_value_str) {
char value[64];
+
parent->ops->pt_value_str(pt, value, sizeof(value));
seq_printf(s, ": %s", value);
if (fence) {
@@ -122,6 +125,7 @@ static void sync_print_obj(struct seq_file *s, struct 
sync_timeline *obj)
 
if (obj->ops->timeline_value_str) {
char value[64];
+
obj->ops->timeline_value_str(obj, value, sizeof(value));
seq_printf(s, ": %s", value);
}
@@ -234,6 +238,7 @@ void sync_dump(void)
for (i = 0; i < s.count; i += DUMP_CHUNK) {
if ((s.count - i) > DUMP_CHUNK) {
char c = s.buf[i + DUMP_CHUNK];
+
s.buf[i + DUMP_CHUNK] = 0;
pr_cont("%s", s.buf + i);
s.buf[i + DUMP_CHUNK] = c;
-- 
1.9.3

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

Re: [patch 35/55] mfd: cros_ec_spi: Use ktime_get_ns()

[Thomas Gleixner]

On Fri, 11 Jul 2014, Lee Jones wrote:

> > Replace the ever recurring:
> > ts = ktime_get_ts();
> > ns = timespec_to_ns();
> > with
> > ns = ktime_get_ns();
> > 
> > Signed-off-by: Thomas Gleixner 
> > Cc: Samuel Ortiz 
> 
> Only Sam?  How old is your version of MAINTAINERS?

Hmm. I use get_maintainers.pl and manually edit it afterwards. Seems
that I killed one extra line :)
 
> Sam hasn't actively maintained MFD for over a year now.
> 
> Patch applied though, thanks.

ktime_get_ns() is not upstream yet, it's part of the series I posted :)

If you ack it, i'll carry it and also remove the now unused variable
ts before applying it.

Thanks,

tglx


--
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: slub/debugobjects: lockup when freeing memory

[Paul E. McKenney]

On Sat, Jul 12, 2014 at 02:03:57PM -0400, Sasha Levin wrote:
> On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
> > rcu: Export debug_init_rcu_head() and and debug_init_rcu_head()
> > 
> > Currently, call_rcu() relies on implicit allocation and initialization
> > for the debug-objects handling of RCU callbacks.  If you hammer the
> > kernel hard enough with Sasha's modified version of trinity, you can end
> > up with the sl*b allocators recursing into themselves via this implicit
> > call_rcu() allocation.
> > 
> > This commit therefore exports the debug_init_rcu_head() and
> > debug_rcu_head_free() functions, which permits the allocators to allocated
> > and pre-initialize the debug-objects information, so that there no longer
> > any need for call_rcu() to do that initialization, which in turn prevents
> > the recursion into the memory allocators.
> > 
> > Reported-by: Sasha Levin 
> > Suggested-by: Thomas Gleixner 
> > Signed-off-by: Paul E. McKenney 
> > Acked-by: Thomas Gleixner 
> 
> Hi Paul,
> 
> Oddly enough, I still see the issue in -next (I made sure that this patch
> was in the tree):

Hello, Sasha,

This commit is only part of the solution.  The allocators need to change
to make use of it.

Thanx, Paul

> [  393.810123] =
> [  393.810123] [ INFO: possible recursive locking detected ]
> [  393.810123] 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813 Not 
> tainted
> [  393.810123] -
> [  393.810123] trinity-c32/9762 is trying to acquire lock:
> [  393.810123] (&(>list_lock)->rlock){-.-...}, at: 
> get_partial_node.isra.39 (mm/slub.c:1628)
> [  393.810123]
> [  393.810123] but task is already holding lock:
> [  393.810123] (&(>list_lock)->rlock){-.-...}, at: __kmem_cache_shutdown 
> (mm/slub.c:3210 mm/slub.c:3233 mm/slub.c:3244)
> [  393.810123]
> [  393.810123] other info that might help us debug this:
> [  393.810123]  Possible unsafe locking scenario:
> [  393.810123]
> [  393.810123]CPU0
> [  393.810123]
> [  393.810123]   lock(&(>list_lock)->rlock);
> [  393.810123]   lock(&(>list_lock)->rlock);
> [  393.810123]
> [  393.810123]  *** DEADLOCK ***
> [  393.810123]
> [  393.810123]  May be due to missing lock nesting notation
> [  393.810123]
> [  393.810123] 5 locks held by trinity-c32/9762:
> [  393.810123] #0: (net_mutex){+.+.+.}, at: copy_net_ns 
> (net/core/net_namespace.c:254)
> [  393.810123] #1: (cpu_hotplug.lock){++}, at: get_online_cpus 
> (kernel/cpu.c:90)
> [  393.810123] #2: (mem_hotplug.lock){.+.+.+}, at: get_online_mems 
> (mm/memory_hotplug.c:83)
> [  393.810123] #3: (slab_mutex){+.+.+.}, at: kmem_cache_destroy 
> (mm/slab_common.c:344)
> [  393.810123] #4: (&(>list_lock)->rlock){-.-...}, at: 
> __kmem_cache_shutdown (mm/slub.c:3210 mm/slub.c:3233 mm/slub.c:3244)
> [  393.810123]
> [  393.810123] stack backtrace:
> [  393.810123] CPU: 32 PID: 9762 Comm: trinity-c32 Not tainted 
> 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813
> [  393.843284]  880bc26730e0  b4ae7ff0 
> 880bc26a3848
> [  393.843284]  b0e47068 b4ae7ff0 880bc26a38f0 
> ac258586
> [  393.843284]  880bc2673e30 0005000a b444dee0 
> 880bc2673e48
> [  393.843284] Call Trace:
> [  393.843284] dump_stack (lib/dump_stack.c:52)
> [  393.843284] __lock_acquire (kernel/locking/lockdep.c:1739 
> kernel/locking/lockdep.c:1783 kernel/locking/lockdep.c:2115 
> kernel/locking/lockdep.c:3182)
> [  393.843284] lock_acquire (kernel/locking/lockdep.c:3602)
> [  393.843284] ? get_partial_node.isra.39 (mm/slub.c:1628)
> [  393.843284] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 
> kernel/locking/spinlock.c:151)
> [  393.843284] ? get_partial_node.isra.39 (mm/slub.c:1628)
> [  393.843284] get_partial_node.isra.39 (mm/slub.c:1628)
> [  393.843284] ? check_irq_usage (kernel/locking/lockdep.c:1638)
> [  393.843284] ? __slab_alloc (mm/slub.c:2307)
> [  393.843284] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [  393.843284] __slab_alloc (mm/slub.c:1730 mm/slub.c:2208 mm/slub.c:2372)
> [  393.843284] ? __debug_object_init (lib/debugobjects.c:100 
> lib/debugobjects.c:312)
> [  393.843284] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90 
> arch/x86/kernel/kvmclock.c:86)
> [  393.843284] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 
> arch/x86/kernel/tsc.c:304)
> [  393.843284] kmem_cache_alloc (mm/slub.c:2445 mm/slub.c:2487 mm/slub.c:2492)
> [  393.843284] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
> [  393.843284] ? __debug_object_init (lib/debugobjects.c:100 
> lib/debugobjects.c:312)
> [  393.843284] ? check_chain_key (kernel/locking/lockdep.c:2188)
> [  393.843284] __debug_object_init (lib/debugobjects.c:100 
> lib/debugobjects.c:312)
> [  393.843284] ? _raw_spin_unlock_irqrestore 
> (include/linux/spinlock_api_smp.h:160 

Re: [patch 54/55] timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC[_RAW]

[Thomas Gleixner]

On Sat, 12 Jul 2014, Mathieu Desnoyers wrote:
> - Original Message -
> > From: "Thomas Gleixner" 
> > On Fri, 11 Jul 2014, Mathieu Desnoyers wrote:
> > > Any reason why the updater wouldn't do:
> > > 
> > > tkf->seq++;
> > > smp_wmb();
> > > update(tkf->base[1 - (tkf->seq & 0x01)], tk);
> > > 
> > > instead of updating both array entries each time ?
> > 
> >   base[0];<- Current active
> >   seq++;  -> Makes base[1] the active one for readers
> >   update(base[0]);
> > 
> > So readers are always one update cycle behind. Probably not an issue
> > most of the time, but think about fast wrapping clocksources and
> > NOHZ
> 
> Ah, yep, got it.
> 
> So instead of calling update() twice per update, could we do
> the following instead ?
> 
> tkf->seq++;
> smp_wmb();
> update(tkf->base[0], tk);
> tkf->seq++;
> smp_wmb();
> memcpy(tkf->base[1], tkf->base[0], sizeof(tkf->base[1]);
> 
> just in case "update" would happen to be expensive for
> some clock implementation.

Sure, same end result ...

Thanks,

tglx
--
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 54/55] timekeeping: Provide fast and NMI safe access to CLOCK_MONOTONIC[_RAW]

[Thomas Gleixner]

On Sat, 12 Jul 2014, Mathieu Desnoyers wrote:
> I'm perhaps missing something here, but what happens with the
> following scenario ?
> 
> Initial conditions:
> 
> tkf->seq = 0
> tkf->base[0] and tkf->base[1] are initialized.
> 
> CPU 0  CPU 1
>    
> update:
>   tkf->seq++
>   smb_wmb()
>   tkf->seq++ (reordered before update)
>reader:
>seq = tkf->seq (reads 2)
>smp_rmb()
>idx = seq & 0x01
>now = now(tkf->base[idx]   (reads 
> base[0])
>   update(tkf->base[0], tk) (racy concurrent update)
>smp_rmb()
>while (seq != tkf->seq) (they are 
> equal)
> 
> So AFAIU, we end up returning a corrupted value. Adding a
> smp_wmb() between update of base[0] and increment of seq,
> as well as between update of base[1] and the _following_
> increment of seq (next update call) would fix this.
> 
> Thoughts ?

Well, the actual implementation does:

+   /* Force readers off to base[1] */
+   raw_write_seqcount_begin(>seq);
+
+   /* Update base[0] */
+   base->clock = clk;
+   base->cycle_last = clk->cycle_last;
+   base->base = tbase;
+   base->shift = shift;
+   base->mult = mult;
+
+   /* Force readers back to base[0] */
+   raw_write_seqcount_end(>seq);
+
+   /* Update base[1] */
+   base++;
+   base->clock = clk;
+   base->cycle_last = clk->cycle_last;
+   base->base = tbase;
+   base->shift = shift;
+   base->mult = mult;

Where raw_write_seqcount_begin/raw_write_seqcount_end provides the
required memory barriers.

Sure I should update the documentaion 

Thanks,

tglx
--
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] scripts/get_maintainer: increase threshold for --follow to reduce time

[Pranith Kumar]

get_maintainer tries to follow files with a matching threshold of default 50%.
This is not really necessary as we do not change a file and move it in the same
commit usually. Increasing the threshold to 90% should be sufficient.

I encountered this on a recent commit where I was touching 12 files. Time take
dropped from 24 sec to 12 sec after this change. It can be reduced further by
increasing the threshold, but I think 90% is sufficient.

Signed-off-by: Pranith Kumar 
---
 scripts/get_maintainer.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index d701627..bc4a69e 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -98,7 +98,7 @@ my %VCS_cmds_git = (
 "execute_cmd" => \_execute_cmd,
 "available" => '(which("git") ne "") && (-e ".git")',
 "find_signers_cmd" =>
-   "git log --no-color --follow --since=\$email_git_since " .
+   "git log --no-color --follow -M90 --since=\$email_git_since " .
'--numstat --no-merges ' .
'--format="GitCommit: %H%n' .
  'GitAuthor: %an <%ae>%n' .
-- 
1.9.1

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

Re: [PATCH] reformat_with_checkpatch: Add automation to checkpatch

[Greg KH]

On Sat, Jul 12, 2014 at 11:29:37AM -0700, Joe Perches wrote:
> On Sat, 2014-07-12 at 10:55 -0700, Greg KH wrote:
> > Yes, the warnings are all due to line-length, but Joe, you shouldn't add
> > a patch that causes more checkpatch warnings than before :)
> 
> Yeah, that was intentional though.
> 
> This script does a series of relatively discrete changes.
> 
> Lindent would more or less work, but it's _horrible_ at
> wrapping overlong lines and merges all types of changes
> together.

Oh I agree, I don't want to see Lindent, but maybe, if the patch adds
checkpatch warnings, it should be at least "flagged" as maybe a problem?

> > While I always want to see more developers get involved with kernel
> > development, there should be a minimum barrier to entry.  And that
> > barrier is the knowledge of the C language, and knowledge of how to edit
> > a text file, and use git.  This script takes that barrier away, for
> > whitespace cleanups, with not much real use overall.
> > 
> > So, I'll keep my local copy of this script now, just to have fun with at
> > times when I'm bored.  But I don't think it should be merged, as-is.
> 
> Dunno, I still think it's useful.

For you, and me, but the world?

Would you want to be on the receiving end of this patch script?  I
don't, and I'm willing to take almost any patch cleanup for staging
code.  I think that says something :)

> Maybe when you get new code, you might run it through a
> script like this before committing it.

I will keep it for me, like I said.

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/

[PATCH] staging: iio: adc: ad7192: fix coding style

[Marcus Folkesson]

Line over 80 characters. This is for Eudyptula Challenge.

Signed-off-by: Marcus Folkesson 
---
 drivers/staging/iio/adc/ad7192.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index 83bb44b..c25c9ab 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -223,7 +223,8 @@ static int ad7192_setup(struct ad7192_state *st,
id &= AD7192_ID_MASK;
 
if (id != st->devid)
-   dev_warn(>sd.spi->dev, "device ID query failed (0x%X)\n", 
id);
+   dev_warn(>sd.spi->dev,
+   "device ID query failed (0x%X)\n", id);
 
switch (pdata->clock_source_sel) {
case AD7192_CLK_EXT_MCLK1_2:
-- 
2.0.0.rc0

--
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: Things I wish I'd known about Inotify

[Michael Kerrisk (man-pages)]

Late follow up on this thread..., since another question occurred in
discussions with Jake.

On Fri, Apr 4, 2014 at 2:43 PM, Jan Kara  wrote:
> On Fri 04-04-14 09:35:50, Michael Kerrisk (man-pages) wrote:
>> On 04/03/2014 10:52 PM, Jan Kara wrote:
>> > On Thu 03-04-14 08:34:44, Michael Kerrisk (man-pages) wrote:
[...]
>> >>Dealing with rename() events
>> >>The  IN_MOVED_FROM  and  IN_MOVED_TO events that are generated by
>> >>rename(2) are usually available as consecutive events when  read‐
>> >>ing from the inotify file descriptor.  However, this is not guar‐
>> >>anteed.  If multiple processes are triggering  events  for  moni‐
>> >>tored  objects,  then  (on rare occasions) an arbitrary number of
>> >>other events may appear between the IN_MOVED_FROM and IN_MOVED_TO
>> >>events.
>> >>
>> >>Matching  up  the IN_MOVED_FROM and IN_MOVED_TO event pair gener‐
>> >>ated by rename(2) is thus inherently racy.  (Don't forget that if
>> >>an  object is renamed outside of a monitored directory, there may
>> >>not even be an IN_MOVED_TO event.)  Heuristic  approaches  (e.g.,
>> >>assume the events are always consecutive) can be used to ensure a
>> >>match in most cases, but will inevitably miss some cases, causing
>> >>the  application  to  perceive  the IN_MOVED_FROM and IN_MOVED_TO
>> >>events as being unrelated.  If watch  descriptors  are  destroyed
>> >>and  re-created as a result, then those watch descriptors will be
>> >>inconsistent with the watch descriptors in  any  pending  events.
>> >>(Re-creating the inotify file descriptor and rebuilding the cache
>> >>may be useful to deal with this scenario.)
>> >   Well, but there's 'cookie' value meant exactly for matching up
>> > IN_MOVED_FROM and IN_MOVED_TO events. And 'cookie' is guaranteed to be
>> > unique at least within the inotify instance (in fact currently it is unique
>> > within the whole system but I don't think we want to give that promise).
>>
>> Yes, that's already assumed by my discussion above (its described elsewhere
>> in the page). But your comment makes me think I should add a few words to
>> remind the reader of that fact. I'll do that.
>   Yes, that would be good.
>
>> But, the point is that even with the cookie, matching the events is
>> nontrivial, since:
>>
>> * There may not even be an IN_MOVED_FROM event
>> * There may be an arbitrary number of other events in between the
>>   IN_MOVED_FROM and the IN_MOVED_TO.
>>
>> Therefore, one has to use heuristic approaches such as "allow at least
>> N millisconds" or "check the next N events" to see if there is an
>> IN_MOVED_FROM that matches the IN_MOVED_TO. I can't see any way around
>> that being inherently racy. (It's unfortunate that the kernel can't
>> provide a guarantee that the two events are always consecutive, since
>> that would simply user space's life considerably.)
>   Yeah, it's unpleasant but doing that would be quite costly/complex at the
> kernel side. And the race would in the worst case lead to application
> thinking there's been file moved outside of watched area & a file moved
> somewhere else inside the watched area. So the application will have to
> possibly inspect that file. That doesn't seem too bad.

One further question. The IN_MOVED_FROM+IN_MOVED_TO pair may not be
guaranteed to be contiguous in the read buffer, but is their insertion
in the event queue guaranteed to be atomic from a user-space point of
view? That is to say: having read an IN_MOVED_FROM event, does user
space have the guarantee that if there is an IN_MOVED_TO event, then
it will already be in the queue? The reason I ask is that this would
affect how user space might try to read the IN_MOVED_TO event. If
there is no such guarantee, then a read() (or select()/poll()) with
(small) timeout is needed. If such a guarantee is provided, then a
nonblocking read() would suffice.

Cheers,

Michael

PS I just now found this code by John McCutchan
https://git.gnome.org/browse/gnome-vfs/tree/modules/inotify-kernel.c#n570
which suggests that the insertion of the event pair is not atomic
w.r.t. user space. Still, I wonder if there is any definitive
statement about this.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] x86_64,signal: Remove 'fs' and 'gs' from sigcontext

[Andi Kleen]

On Sat, Jul 12, 2014 at 11:40:03AM -0700, H. Peter Anvin wrote:
> Because you are doing something weird (like Pin, for example) and take an 
> asynchronous fault?

But even for pin that would need executing 16 bit code, or really weird
32bit code. AFAIK for 32bit the only good use case was NX emulation
(and old virtualization) which are both completely obsolete.

I don't think it's worth messing with the signal handlers for 16bit
code. If there's any problem with saving/restoring state that emulator 
can always handle it by itself.

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

Re: [PATCH 2/2] x86_64,signal: Remove 'fs' and 'gs' from sigcontext

[H. Peter Anvin]

Because you are doing something weird (like Pin, for example) and take an 
asynchronous fault?

On July 12, 2014 11:37:48 AM PDT, Andi Kleen  wrote:
>> This seems like it's asking for trouble.  I think wxe'd have to
>> separately save the selectors and the base registers to avoid
>breaking
>> something, especially once wrgsbase, etc are enabled.
>
>I agree, it would likely break existing code.
>
>> Linus, for context, the other patch in this series saves and restores
>> SS. 
>
>> Without that, 64-bit sigreturn to a nondefault stack segment is
>> basically impossible.  
>
>Why would you ever want to do that?
>
>-Andi

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

Re: [PATCH 2/2] x86_64,signal: Remove 'fs' and 'gs' from sigcontext

[Andi Kleen]

> This seems like it's asking for trouble.  I think wxe'd have to
> separately save the selectors and the base registers to avoid breaking
> something, especially once wrgsbase, etc are enabled.

I agree, it would likely break existing code.

> Linus, for context, the other patch in this series saves and restores
> SS. 

> Without that, 64-bit sigreturn to a nondefault stack segment is
> basically impossible.  

Why would you ever want to do that?

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

Re: [PATCH] reformat_with_checkpatch: Add automation to checkpatch

[Joe Perches]

On Sat, 2014-07-12 at 10:55 -0700, Greg KH wrote:
> Yes, the warnings are all due to line-length, but Joe, you shouldn't add
> a patch that causes more checkpatch warnings than before :)

Yeah, that was intentional though.

This script does a series of relatively discrete changes.

Lindent would more or less work, but it's _horrible_ at
wrapping overlong lines and merges all types of changes
together.

For now, people are probably better at line wrapping in
an acceptable way.

> While I always want to see more developers get involved with kernel
> development, there should be a minimum barrier to entry.  And that
> barrier is the knowledge of the C language, and knowledge of how to edit
> a text file, and use git.  This script takes that barrier away, for
> whitespace cleanups, with not much real use overall.
> 
> So, I'll keep my local copy of this script now, just to have fun with at
> times when I'm bored.  But I don't think it should be merged, as-is.

Dunno, I still think it's useful.

Maybe when you get new code, you might run it through a
script like this before committing it.


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

[no subject]

[Gregory K Quintana]

unsubscribe linux-kernel
--
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/

hi

[laura wintour]

Bitte sei nicht böse über diese Mail, es ist wegen der Dringlichkeit der meine 
Situation hier. Ich bin Laura Wintour Sirleaf, 23 Jahre alt Nursing Student, 
Cote Dvoire, aber derzeit Asylsuchende in Lome Republik Togo, als Folge des 
Krieges in meinem Land, mein Vater eine Selige Erinnerung Ende Dr, Wintour 
Sirleaf war der Besitzer der Rana-Energie und Petrochemie sowie eine Regierung 
Auftragnehmer in Gold und Öl-Angebote. starb während der Krisen, die 
aufgetreten in meinem Land, die auf meinen Aufenthalt im Flüchtlingslager 
geführt sind, ich möchte Sie so um mich in Ihrem Land die 3,5 Millionen Dollar 
zu investieren, die ich von meinen Eltern, als einziges Kind von der family.i 
geerbt komme so bald wie möglich zu Ihrem Land wenn die Überweisung auf Ihr 
Konto erfolgt möglicherweise. Bitte antworten Sie mir, damit ich Informationen 
geben können. mit freundlichen Grüßen...lAURA
--
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/

bit fields && data tearing

[Oleg Nesterov]

Hello,

I am not sure I should ask here, but since Documentation/memory-barriers.txt
mentions load/store tearing perhaps my question is not completely off-topic...

I am fighting with mysterious RHEL bug, it can be reproduced on ppc and s390
but not on x86. Finally I seem to understand the problem, and I even wrote the
stupid kernel module to ensure, see it below at the end.

It triggers the problem immediately, kt_2() sees the wrong value in freeze_stop.
(If I turn ->freeze_stop int "long", the problem goes away).

So the question is: is this gcc bug or the code below is buggy?

If it is buggy, then probably memory-barriers.txt could mention that you should
be carefull with bit fields, even ACCESS_ONCE() obviously can't help.

Or this just discloses my ignorance and you need at least aligned(long) after a
bit field to be thread-safe ? I thought that compiler should take care and add
the necessary alignment if (say) CPU can't update a single byte/uint.

gcc version 4.4.7 20120313 (Red Hat 4.4.7-9) (GCC). Asm:

 <.kt_2>:
   0:   7c 08 02 a6 mflrr0
   4:   fb 81 ff e0 std r28,-32(r1)
   8:   fb a1 ff e8 std r29,-24(r1)
   c:   fb c1 ff f0 std r30,-16(r1)
  10:   fb e1 ff f8 std r31,-8(r1)
  14:   eb c2 00 00 ld  r30,0(r2)
  18:   f8 01 00 10 std r0,16(r1)
  1c:   f8 21 ff 71 stdur1,-144(r1)
  20:   7c 7d 1b 78 mr  r29,r3
  24:   3b e0 00 00 li  r31,0
  28:   78 3c 04 64 rldicr  r28,r1,0,49
  2c:   3b 9c 00 80 addir28,r28,128
  30:   48 00 00 2c b   5c <.kt_2+0x5c>
  34:   60 00 00 00 nop
  38:   60 00 00 00 nop
  3c:   60 00 00 00 nop
  40:   93 fd 00 04 stw r31,4(r29)
  44:   e8 9d 00 06 lwa r4,4(r29)
  48:   7f 84 f8 00 cmpwcr7,r4,r31
  4c:   40 de 00 4c bne-cr7,98 <.kt_2+0x98>
  50:   e8 1c 00 00 ld  r0,0(r28)
  54:   78 09 f7 e3 rldicl. r9,r0,62,63
  58:   40 c2 00 54 bne-ac <.kt_2+0xac>
  5c:   48 00 00 01 bl  5c <.kt_2+0x5c>
  60:   60 00 00 00 nop
  64:   3b ff 00 01 addir31,r31,1
  68:   2f a3 00 00 cmpdi   cr7,r3,0
  6c:   7f ff 07 b4 extsw   r31,r31
  70:   41 9e ff d0 beq+cr7,40 <.kt_2+0x40>
  74:   38 21 00 90 addir1,r1,144
  78:   38 60 00 00 li  r3,0
  7c:   e8 01 00 10 ld  r0,16(r1)
  80:   eb 81 ff e0 ld  r28,-32(r1)
  84:   eb a1 ff e8 ld  r29,-24(r1)
  88:   eb c1 ff f0 ld  r30,-16(r1)
  8c:   eb e1 ff f8 ld  r31,-8(r1)
  90:   7c 08 03 a6 mtlrr0
  94:   4e 80 00 20 blr
  98:   e8 7e 80 28 ld  r3,-32728(r30)
  9c:   7f e5 fb 78 mr  r5,r31
  a0:   48 00 00 01 bl  a0 <.kt_2+0xa0>
  a4:   60 00 00 00 nop
  a8:   4b ff ff a8 b   50 <.kt_2+0x50>
  ac:   48 00 00 01 bl  ac <.kt_2+0xac>
  b0:   60 00 00 00 nop
  b4:   4b ff ff a8 b   5c <.kt_2+0x5c>
  b8:   60 00 00 00 nop
  bc:   60 00 00 00 nop

00c0 <.kt_1>:
  c0:   7c 08 02 a6 mflrr0
  c4:   fb 81 ff e0 std r28,-32(r1)
  c8:   fb a1 ff e8 std r29,-24(r1)
  cc:   fb c1 ff f0 std r30,-16(r1)
  d0:   fb e1 ff f8 std r31,-8(r1)
  d4:   eb c2 00 00 ld  r30,0(r2)
  d8:   f8 01 00 10 std r0,16(r1)
  dc:   f8 21 ff 71 stdur1,-144(r1)
  e0:   7c 7d 1b 78 mr  r29,r3
  e4:   3b e0 00 00 li  r31,0
  e8:   78 3c 04 64 rldicr  r28,r1,0,49
  ec:   3b 9c 00 80 addir28,r28,128
  f0:   48 00 00 38 b   128 <.kt_1+0x68>
  f4:   60 00 00 00 nop
  f8:   60 00 00 00 nop
  fc:   60 00 00 00 nop
 100:   e8 1d 00 00 ld  r0,0(r29)
 104:   79 20 e8 0e rldimi  r0,r9,61,0
 108:   f8 1d 00 00 std r0,0(r29)
 10c:   80 1d 00 00 lwz r0,0(r29)
 110:   54 00 1f 7e rlwinm  r0,r0,3,29,31
 114:   7f 80 f8 00 cmpwcr7,r0,r31
 118:   40 de 00 6c bne-cr7,184 <.kt_1+0xc4>
 11c:   e8 1c 00 00 ld  r0,0(r28)
 120:   78 09 f7 e3 rldicl. r9,r0,62,63
 124:   40 c2 00 70 bne-194 <.kt_1+0xd4>
 128:   48 00 00 01 bl  128 <.kt_1+0x68>
 12c:   60 00 00 00 nop
 130:   3b ff 00 01 addir31,r31,1
 134:   2f a3 00 00 cmpdi   cr7,r3,0
 138:   7f ff 07 b4 extsw   r31,r31
 13c:   2f 1f 00 07 cmpwi   

[PATCH V2 3/9] i40e: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c 
b/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
index 870ab1e..7c6bf89 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c
@@ -417,7 +417,6 @@ static i40e_status i40e_create_lan_hmc_object(struct 
i40e_hw *hw,
default:
ret_code = I40E_ERR_INVALID_SD_TYPE;
goto exit;
-   break;
}
}
}
@@ -502,7 +501,6 @@ try_type_paged:
hw_dbg(hw, "i40e_configure_lan_hmc: Unknown SD type: %d\n",
  ret_code);
goto configure_lan_hmc_out;
-   break;
}
 
/* Configure and program the FPM registers so objects can be created */
-- 
1.9.1

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

[PATCH V2 5/9] ps3_gelic: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c 
b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
index d568af1..2553ed5 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
@@ -723,13 +723,10 @@ static int gelic_wl_get_scan(struct net_device *netdev,
/* If a scan in progress, caller should call me again */
ret = -EAGAIN;
goto out;
-   break;
-
case GELIC_WL_SCAN_STAT_INIT:
/* last scan request failed or never issued */
ret = -ENODEV;
goto out;
-   break;
case GELIC_WL_SCAN_STAT_GOT_LIST:
/* ok, use current list */
break;
-- 
1.9.1

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

[PATCH V2 8/9] rtlwifi: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/wireless/rtlwifi/rtl8192se/fw.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/rtlwifi/rtl8192se/fw.c 
b/drivers/net/wireless/rtlwifi/rtl8192se/fw.c
index 380e7d4..73fa4a1 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192se/fw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192se/fw.c
@@ -438,7 +438,6 @@ int rtl92s_download_fw(struct ieee80211_hw *hw)
RT_TRACE(rtlpriv, COMP_ERR, DBG_EMERG,
 "Unexpected Download step!!\n");
goto fail;
-   break;
}
 
/* <2> Download image file */
-- 
1.9.1

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

[PATCH V2 6/9] orinoco_usb: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/wireless/orinoco/orinoco_usb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/orinoco/orinoco_usb.c 
b/drivers/net/wireless/orinoco/orinoco_usb.c
index c90939c..d3cf7c3 100644
--- a/drivers/net/wireless/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/orinoco/orinoco_usb.c
@@ -921,7 +921,6 @@ static int ezusb_access_ltv(struct ezusb_priv *upriv,
retval = -EFAULT;
}
goto exit;
-   break;
}
if (ctx->in_rid) {
struct ezusb_packet *ans = ctx->buf;
-- 
1.9.1

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

[PATCH V2 7/9] wcn36xx: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/wireless/ath/wcn36xx/main.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 4ab5370..b71d2b3 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -488,7 +488,6 @@ static int wcn36xx_set_key(struct ieee80211_hw *hw, enum 
set_key_cmd cmd,
wcn36xx_err("Unsupported key cmd 0x%x\n", cmd);
ret = -EOPNOTSUPP;
goto out;
-   break;
}
 
 out:
-- 
1.9.1

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

[PATCH V2 1/9] igb: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/ethernet/intel/igb/e1000_82575.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c 
b/drivers/net/ethernet/intel/igb/e1000_82575.c
index a2db388..168a5ee 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -837,7 +837,6 @@ static s32 igb_get_phy_id_82575(struct e1000_hw *hw)
default:
ret_val = -E1000_ERR_PHY;
goto out;
-   break;
}
ret_val = igb_get_phy_id(hw);
goto out;
-- 
1.9.1

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

[PATCH V2 4/9] i40evf: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c 
b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 7fc5f3b..7195566 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -2006,7 +2006,6 @@ static void i40evf_init_task(struct work_struct *work)
}
adapter->state = __I40EVF_INIT_VERSION_CHECK;
goto restart;
-   break;
case __I40EVF_INIT_VERSION_CHECK:
if (!i40evf_asq_done(hw)) {
dev_err(>dev, "Admin queue command never 
completed\n");
@@ -2028,7 +2027,6 @@ static void i40evf_init_task(struct work_struct *work)
}
adapter->state = __I40EVF_INIT_GET_RESOURCES;
goto restart;
-   break;
case __I40EVF_INIT_GET_RESOURCES:
/* aq msg sent, awaiting reply */
if (!adapter->vf_res) {
-- 
1.9.1

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

[PATCH V2 2/9] ixgbe: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c  | 1 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c  | 4 
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 2 --
 3 files changed, 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
index 1560933..206171f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c
@@ -430,7 +430,6 @@ static s32 ixgbe_fc_enable_82598(struct ixgbe_hw *hw)
hw_dbg(hw, "Flow control param set incorrectly\n");
ret_val = IXGBE_ERR_CONFIG;
goto out;
-   break;
}
 
/* Set 802.3x based flow control settings. */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
index bc7c924..0373a5b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c
@@ -432,7 +432,6 @@ static s32 ixgbe_get_link_capabilities_82599(struct 
ixgbe_hw *hw,
default:
status = IXGBE_ERR_LINK_SETUP;
goto out;
-   break;
}
 
if (hw->phy.multispeed_fiber) {
@@ -2035,7 +2034,6 @@ static u32 
ixgbe_get_supported_physical_layer_82599(struct ixgbe_hw *hw)
else if (pma_pmd_10g_parallel == IXGBE_AUTOC_10G_XAUI)
physical_layer = IXGBE_PHYSICAL_LAYER_10GBASE_XAUI;
goto out;
-   break;
case IXGBE_AUTOC_LMS_10G_SERIAL:
if (pma_pmd_10g_serial == IXGBE_AUTOC2_10G_KR) {
physical_layer = IXGBE_PHYSICAL_LAYER_10GBASE_KR;
@@ -2052,10 +2050,8 @@ static u32 
ixgbe_get_supported_physical_layer_82599(struct ixgbe_hw *hw)
if (autoc & IXGBE_AUTOC_KR_SUPP)
physical_layer |= IXGBE_PHYSICAL_LAYER_10GBASE_KR;
goto out;
-   break;
default:
goto out;
-   break;
}
 
 sfp_check:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
index 4e5385a..3f318c5 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.c
@@ -216,7 +216,6 @@ static s32 ixgbe_setup_fc(struct ixgbe_hw *hw)
hw_dbg(hw, "Flow control param set incorrectly\n");
ret_val = IXGBE_ERR_CONFIG;
goto out;
-   break;
}
 
if (hw->mac.type != ixgbe_mac_X540) {
@@ -2179,7 +2178,6 @@ s32 ixgbe_fc_enable_generic(struct ixgbe_hw *hw)
hw_dbg(hw, "Flow control param set incorrectly\n");
ret_val = IXGBE_ERR_CONFIG;
goto out;
-   break;
}
 
/* Set 802.3x based flow control settings. */
-- 
1.9.1

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

[PATCH V2 9/9] slip: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/net/slip/slhc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/slip/slhc.c b/drivers/net/slip/slhc.c
index 1252d9c..079f7ad 100644
--- a/drivers/net/slip/slhc.c
+++ b/drivers/net/slip/slhc.c
@@ -396,7 +396,6 @@ found:
   ntohs(cs->cs_ip.tot_len) == hlen)
break;
goto uncompressed;
-   break;
case SPECIAL_I:
case SPECIAL_D:
/* actual changes match one of our special case encodings --
-- 
1.9.1

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

[PATCH V2 0/9] drivers/net: remove unnecessary break after goto

[Fabian Frederick]

Small patchset addressing break redundancy on drivers/net branch
(suggested by Joe Perches). 

V2: cc to maintainers of each section.


Fabian Frederick (9):
  igb: remove unnecessary break after goto
  ixgbe: remove unnecessary break after goto
  i40e: remove unnecessary break after goto
  i40evf: remove unnecessary break after goto
  ps3_gelic: remove unnecessary break after goto
  orinoco_usb: remove unnecessary break after goto
  wcn36xx: remove unnecessary break after goto
  rtlwifi: remove unnecessary break after goto
  slip: remove unnecessary break after goto

 drivers/net/ethernet/intel/i40e/i40e_lan_hmc.c| 2 --
 drivers/net/ethernet/intel/i40evf/i40evf_main.c   | 2 --
 drivers/net/ethernet/intel/igb/e1000_82575.c  | 1 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_82598.c| 1 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c| 4 
 drivers/net/ethernet/intel/ixgbe/ixgbe_common.c   | 2 --
 drivers/net/ethernet/toshiba/ps3_gelic_wireless.c | 3 ---
 drivers/net/slip/slhc.c   | 1 -
 drivers/net/wireless/ath/wcn36xx/main.c   | 1 -
 drivers/net/wireless/orinoco/orinoco_usb.c| 1 -
 drivers/net/wireless/rtlwifi/rtl8192se/fw.c   | 1 -
 11 files changed, 19 deletions(-)

-- 
1.9.1

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

Re: slub/debugobjects: lockup when freeing memory

[Sasha Levin]

On 06/20/2014 11:40 AM, Paul E. McKenney wrote:
> rcu: Export debug_init_rcu_head() and and debug_init_rcu_head()
> 
> Currently, call_rcu() relies on implicit allocation and initialization
> for the debug-objects handling of RCU callbacks.  If you hammer the
> kernel hard enough with Sasha's modified version of trinity, you can end
> up with the sl*b allocators recursing into themselves via this implicit
> call_rcu() allocation.
> 
> This commit therefore exports the debug_init_rcu_head() and
> debug_rcu_head_free() functions, which permits the allocators to allocated
> and pre-initialize the debug-objects information, so that there no longer
> any need for call_rcu() to do that initialization, which in turn prevents
> the recursion into the memory allocators.
> 
> Reported-by: Sasha Levin 
> Suggested-by: Thomas Gleixner 
> Signed-off-by: Paul E. McKenney 
> Acked-by: Thomas Gleixner 

Hi Paul,

Oddly enough, I still see the issue in -next (I made sure that this patch
was in the tree):

[  393.810123] =
[  393.810123] [ INFO: possible recursive locking detected ]
[  393.810123] 3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813 Not 
tainted
[  393.810123] -
[  393.810123] trinity-c32/9762 is trying to acquire lock:
[  393.810123] (&(>list_lock)->rlock){-.-...}, at: get_partial_node.isra.39 
(mm/slub.c:1628)
[  393.810123]
[  393.810123] but task is already holding lock:
[  393.810123] (&(>list_lock)->rlock){-.-...}, at: __kmem_cache_shutdown 
(mm/slub.c:3210 mm/slub.c:3233 mm/slub.c:3244)
[  393.810123]
[  393.810123] other info that might help us debug this:
[  393.810123]  Possible unsafe locking scenario:
[  393.810123]
[  393.810123]CPU0
[  393.810123]
[  393.810123]   lock(&(>list_lock)->rlock);
[  393.810123]   lock(&(>list_lock)->rlock);
[  393.810123]
[  393.810123]  *** DEADLOCK ***
[  393.810123]
[  393.810123]  May be due to missing lock nesting notation
[  393.810123]
[  393.810123] 5 locks held by trinity-c32/9762:
[  393.810123] #0: (net_mutex){+.+.+.}, at: copy_net_ns 
(net/core/net_namespace.c:254)
[  393.810123] #1: (cpu_hotplug.lock){++}, at: get_online_cpus 
(kernel/cpu.c:90)
[  393.810123] #2: (mem_hotplug.lock){.+.+.+}, at: get_online_mems 
(mm/memory_hotplug.c:83)
[  393.810123] #3: (slab_mutex){+.+.+.}, at: kmem_cache_destroy 
(mm/slab_common.c:344)
[  393.810123] #4: (&(>list_lock)->rlock){-.-...}, at: __kmem_cache_shutdown 
(mm/slub.c:3210 mm/slub.c:3233 mm/slub.c:3244)
[  393.810123]
[  393.810123] stack backtrace:
[  393.810123] CPU: 32 PID: 9762 Comm: trinity-c32 Not tainted 
3.16.0-rc4-next-20140711-sasha-00046-g07d3099-dirty #813
[  393.843284]  880bc26730e0  b4ae7ff0 
880bc26a3848
[  393.843284]  b0e47068 b4ae7ff0 880bc26a38f0 
ac258586
[  393.843284]  880bc2673e30 0005000a b444dee0 
880bc2673e48
[  393.843284] Call Trace:
[  393.843284] dump_stack (lib/dump_stack.c:52)
[  393.843284] __lock_acquire (kernel/locking/lockdep.c:1739 
kernel/locking/lockdep.c:1783 kernel/locking/lockdep.c:2115 
kernel/locking/lockdep.c:3182)
[  393.843284] lock_acquire (kernel/locking/lockdep.c:3602)
[  393.843284] ? get_partial_node.isra.39 (mm/slub.c:1628)
[  393.843284] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 
kernel/locking/spinlock.c:151)
[  393.843284] ? get_partial_node.isra.39 (mm/slub.c:1628)
[  393.843284] get_partial_node.isra.39 (mm/slub.c:1628)
[  393.843284] ? check_irq_usage (kernel/locking/lockdep.c:1638)
[  393.843284] ? __slab_alloc (mm/slub.c:2307)
[  393.843284] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[  393.843284] __slab_alloc (mm/slub.c:1730 mm/slub.c:2208 mm/slub.c:2372)
[  393.843284] ? __debug_object_init (lib/debugobjects.c:100 
lib/debugobjects.c:312)
[  393.843284] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90 
arch/x86/kernel/kvmclock.c:86)
[  393.843284] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 
arch/x86/kernel/tsc.c:304)
[  393.843284] kmem_cache_alloc (mm/slub.c:2445 mm/slub.c:2487 mm/slub.c:2492)
[  393.843284] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[  393.843284] ? __debug_object_init (lib/debugobjects.c:100 
lib/debugobjects.c:312)
[  393.843284] ? check_chain_key (kernel/locking/lockdep.c:2188)
[  393.843284] __debug_object_init (lib/debugobjects.c:100 
lib/debugobjects.c:312)
[  393.843284] ? _raw_spin_unlock_irqrestore 
(include/linux/spinlock_api_smp.h:160 kernel/locking/spinlock.c:191)
[  393.843284] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[  393.843284] debug_object_init (lib/debugobjects.c:365)
[  393.843284] rcuhead_fixup_activate (kernel/rcu/update.c:260)
[  393.843284] debug_object_activate (lib/debugobjects.c:280 
lib/debugobjects.c:439)
[  393.843284] ? preempt_count_sub (kernel/sched/core.c:2600)
[  393.843284] ? slab_cpuup_callback (mm/slub.c:1484)
[  393.843284] 

Re: [PATCH] reformat_with_checkpatch: Add automation to checkpatch

[Greg KH]

On Sat, Jul 12, 2014 at 12:30:43PM +0300, Dan Carpenter wrote:
> On Fri, Jul 11, 2014 at 06:40:16PM -0700, Joe Perches wrote:
> > On Fri, 2014-07-11 at 18:34 -0700, Greg KH wrote:
> > > On Fri, Jul 11, 2014 at 06:21:27PM -0700, Joe Perches wrote:
> > > > A simple script to run checkpatch --fix for various types of
> > > > of cleanups.
> > > > 
> > > > This script is useful primarily for staging.
> > > > 
> > > > This reformats code to a more CodingStyle conforming style,
> > > > compiles it, verifies that the object code hasn't changed,
> > > > and git commits it too.
> > > 
> > > And 'git commits' it?
> > 
> > The thought I had was to made it easier to
> > submit "my first kernel patch" correctly.
> > like that tuxradar article you wrote a few
> > years ago.
> > 
> > http://www.tuxradar.com/content/newbies-guide-hacking-linux-kernel
> > 
> > > Heh, I should just run this myself to clean up
> > > staging and beat everyone else to it...
> > 
> > At least for the whitespace noise, you could
> > but I hope it'll encourage a few more people
> > to try kernel patching instead.
> 
> I have always hate the idea of automated patches from random people
> because I don't trust them to not be malicious so I have to review them
> manually.  There is a story that back in the day the US government paid
> someone to send tons of checkpatch style patches to BSD.  The guy
> thought he was "cleaning up the code" but actually he was part of a
> larger scheme to flood the maintainers with patches so another person
> could slip in some malicious code.

Based on some of the patches that I get sent, I wouldn't be surprised if
that's already happening :(

> It's better if someone just ran this on all new staging code before
> adding it to the tree.

I spent some time messing with this script today, and while it is "fun"
to run, I don't think it's all that useful.

One example, before running the script:

~/linux/work/staging $ ./scripts/checkpatch.pl --terse --file 
drivers/staging/android/binder.c | tail -n 1
total: 0 errors, 103 warnings, 3670 lines checked

After running it:

~/linux/work/staging $ ./scripts/checkpatch.pl --terse --file 
drivers/staging/android/binder.c | tail -n 1
total: 0 errors, 125 warnings, 3670 lines checked

And that was after the script created two patches, with the resulting
diffstat of:

 drivers/staging/android/binder.c |  124 +++
 1 file changed, 62 insertions(+), 62 deletions(-)

So 2 patches, 60+ lines to review, and 22 more warnings from checkpatch
as the end result?

Yes, the warnings are all due to line-length, but Joe, you shouldn't add
a patch that causes more checkpatch warnings than before :)


I know people have scripts like this of their own, and while it might be
nice to "standardize" them, I am really reluctant to put this script in
the kernel tree itself.  There's a barrier of entry to write your own
type of script here that honestly, I like.

We already have the example of someone who obviously does not know the C
language at all, running through the kernel tree at the moment, creating
horrible patches that are flat-out wrong and annoying maintainers with
their result.  I've had to kill-file them for now, as it was just too
annoying and maintainer time is what we have the least of.

While I always want to see more developers get involved with kernel
development, there should be a minimum barrier to entry.  And that
barrier is the knowledge of the C language, and knowledge of how to edit
a text file, and use git.  This script takes that barrier away, for
whitespace cleanups, with not much real use overall.

So, I'll keep my local copy of this script now, just to have fun with at
times when I'm bored.  But I don't think it should be merged, as-is.

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 v3 1/2] iio: adc: add driver for Rockchip saradc

[Jonathan Cameron]

On July 12, 2014 4:14:58 PM GMT+01:00, "Heiko Stübner"  wrote:
>Am Samstag, 12. Juli 2014, 15:35:04 schrieb Jonathan Cameron:
>> On 09/07/14 11:22, Heiko Stübner wrote:
>> > The ADC is a 3-channel signal-ended 10-bit Successive Approximation
>> > Register (SAR) A/D Converter. It uses the supply and ground as its
>> > reference and converts the analog input signal into 10-bit binary
>digital
>> > codes.
>> > 
>> > Signed-off-by: Heiko Stuebner 
>> 
>> Very nice.  One utterly trivial comment inline that doesn't really
>> bother me (made the review take a good 10 seconds longer than it
>> otherwise would have done!)
>> 
>> Ah, and as my build tests (x86_64) just finished, a build issue:
>> 
>> drivers/iio/adc/rockchip_saradc.c:65:17: error: undefined identifier
>> 'writel_relaxed' drivers/iio/adc/rockchip_saradc.c:73:25: error:
>undefined
>> identifier 'writel_relaxed' drivers/iio/adc/rockchip_saradc.c:99:9:
>error:
>> undefined identifier 'writel_relaxed'
>> 
>> I can't immediately identify if there is a CONFIG element to indicate
>> the availability of the relaxed form.  Anyone else know?
>
>taking a spi driver from another architecture (spi_qup), I see
>
>config SPI_QUP
>   depends on ARCH_QCOM || (ARM && COMPILE_TEST)
>
>
>A fix Mark Brown did for the actual rockchip spi driver does
>
>config SPI_ROCKCHIP
>   depends on ARM || ARM64 || AVR32 || HEXAGON || MIPS || SUPERH
>
>
>so I guess the saradc also could do one of the two ... preferences? :-)
>
Which ever you prefer. Either will get hammered by the autobuilders so we will 
get plenty of test coverage.
>
>
>> I'm in two minds on whether the binding is obvous enough to take
>without
>> a device-tree maintainer ack. I'll let it sit for a bit - perhaps
>> even the standard 3 weeks (please repost with the typos fixed though)
>> and see if anyone want to comment.
>
>ok, so I'll repost the two patches, fixing the typos and Kconfig and
>changing 
>the of_property_read_u32 behaviour.
>
>
>Heiko
>
>
>> 
>> Jonathan
>> 
>> > ---
>> > 
>> >   changes since v2:
>> > - address more comments from Peter Meerwald
>> > 
>> >mainly the missing info_mask_shared_by_type element
>> >   
>> >   changes since v1:
>> > - address comments from Peter Meerwald
>> > 
>> > drivers/iio/adc/Kconfig   |  10 ++
>> > 
>> >   drivers/iio/adc/Makefile  |   1 +
>> >   drivers/iio/adc/rockchip_saradc.c | 314
>> >   ++ 3 files changed, 325
>> >   insertions(+)
>> >   create mode 100644 drivers/iio/adc/rockchip_saradc.c
>> > 
>> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>> > index a80d236..5d36bdb 100644
>> > --- a/drivers/iio/adc/Kconfig
>> > +++ b/drivers/iio/adc/Kconfig
>> > @@ -187,6 +187,16 @@ config NAU7802
>> > 
>> >  To compile this driver as a module, choose M here: the
>> >  module will be called nau7802.
>> > 
>> > +config ROCKCHIP_SARADC
>> > +  tristate "Rockchip SARADC driver"
>> > +  depends on ARCH_ROCKCHIP || (OF && COMPILE_TEST)
>> > +  help
>> > +Say yes here to build support for the SARADC found in SoCs from
>> > +Rockchip.
>> > +
>> > +To compile this driver as a module, choose M here: the
>> > +module will be called rockchip_saradc.
>> > +
>> > 
>> >   config TI_ADC081C
>> >   
>> >tristate "Texas Instruments ADC081C021/027"
>> >depends on I2C
>> > 
>> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>> > index 9d60f2d..8e2932d 100644
>> > --- a/drivers/iio/adc/Makefile
>> > +++ b/drivers/iio/adc/Makefile
>> > @@ -20,6 +20,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
>> > 
>> >   obj-$(CONFIG_MCP3422) += mcp3422.o
>> >   obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>> >   obj-$(CONFIG_NAU7802) += nau7802.o
>> > 
>> > +obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>> > 
>> >   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>> >   obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
>> >   obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
>> > 
>> > diff --git a/drivers/iio/adc/rockchip_saradc.c
>> > b/drivers/iio/adc/rockchip_saradc.c new file mode 100644
>> > index 000..8fc5867
>> > --- /dev/null
>> > +++ b/drivers/iio/adc/rockchip_saradc.c
>> > @@ -0,0 +1,314 @@
>> > +/*
>> > + * Rockchip Successive Approximation Register (SAR) A/D Converter
>> > + * Copyright (C) 2014 ROCKCHIP, Inc.
>> > + *
>> > + * This program is free software; you can redistribute it and/or
>modify
>> > + * it under the terms of the GNU General Public License as
>published by
>> > + * the Free Software Foundation; either version 2 of the License,
>or
>> > + * (at your option) any later version.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > + * GNU General Public License for more details.
>> > + */
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> > 

Re: [PATCH] pci: Add include guard to include/linux/pci_ids.h

[Bjorn Helgaas]

On Sat, Jul 12, 2014 at 6:09 AM, Rasmus Villemoes
 wrote:
> Bjorn Helgaas  writes:
>
>> On Thu, Jul 10, 2014 at 02:05:11PM +0200, Rasmus Villemoes wrote:
>>> Adding an include guard frees the preprocessor from reparsing over
>>> 2600 #defines in the cases where pci_ids.h is somehow included more
>>> than once. This gives a tiny-but-measurable performance improvement
>>> when compiling such files.
>>>
>>> Signed-off-by: Rasmus Villemoes 
>>
>> Applied to pci/misc for v3.17, thanks!
>>
>
> Great.
>
> One thing I thought about, but which is likely undoable in practice:
> There are only about 800 files which use any of the #defines in
> pci_ids.h, but more than 3000 files include pci.h directly or
> indirectly. Making those 800 include pci_ids.h directly and removing it
> from pci.h could speed up compilation of the other 2200.

Yeah, changing 800 files for a minor build performance improvement
doesn't sound like it'd be worth the churn.

Bjorn
--
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: Power Supply Subsystem Maintainer

[Dmitry Eremin-Solenikov]

Hello,

On Mon, Jul 7, 2014 at 10:20 PM, Andrew Morton
 wrote:
> On Wed, 2 Jul 2014 08:41:19 +0530 Jenny Tc  wrote:
>
>> Andrew Morton,
>>
>> Appreciate your help to sort out the power supply maintainer issue. The
>> subsystem is not active after February 2014. No response from maintainer and 
>> the
>> last commit on git://git.infradead.org/battery-2.6 was on 2014-02-01. 
>> Appreciate
>> your help.
>
> Well, two weeks ago Dmitry did say that he'd been busy at work and
> planned to pick things up again soon.
>
> Dmitry, could you please make a firm and realistic decision one way or
> the other?  If it isn't truly going to happen then that's OK - these
> things happen.  But please tell us so other arrangements can be put in
> place if that's the way we'll be proceeding.

Well, I am sorry. I promised that I will have time for this, but it
seems things did not go
the way I expected. Sebastian volunteered  to pick up power/reset
maintainership,
so if he still is willing to work on that topic, I'll ack a patch
transferring maintainership
to him.

As a side note, I'd suggest to also open a mailing list either on
infradead.org (David, I
made several requests, to n/a) or on vger.kernel.org.

-- 
With best wishes
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/

[PATCH v3] rcu: define tracepoint strings only if CONFIG_TRACING is set

[Ard Biesheuvel]

Commit f7f7bac9cb1c ("rcu: Have the RCU tracepoints use the tracepoint_string
infrastructure") unconditionally populates the __tracepoint_str input section,
but this section is not assigned an output section if CONFIG_TRACING is not set.
This results in the __tracepoint_str turning up in unexpected places, i.e.,
after _edata.

Signed-off-by: Ard Biesheuvel 
Cc: rost...@goodmis.org
Cc: paul...@linux.vnet.ibm.com
---
v3:
- make definition of _varname conditional as well
v2:
- s/DEFINE_TPS/DEFINE_RCU_TPS/

 kernel/rcu/tree.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f1ba77363fbb..0756a4696007 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -79,9 +79,18 @@ static struct lock_class_key rcu_fqs_class[RCU_NUM_LVLS];
  * the tracing userspace tools to be able to decipher the string
  * address to the matching string.
  */
-#define RCU_STATE_INITIALIZER(sname, sabbr, cr) \
+#ifdef CONFIG_TRACING
+# define DEFINE_RCU_TPS(sname) \
 static char sname##_varname[] = #sname; \
-static const char *tp_##sname##_varname __used __tracepoint_string = 
sname##_varname; \
+static const char *tp_##sname##_varname __used __tracepoint_string = 
sname##_varname;
+# define RCU_STATE_NAME(sname) sname##_varname
+#else
+# define DEFINE_RCU_TPS(sname)
+# define RCU_STATE_NAME(sname) __stringify(sname)
+#endif
+
+#define RCU_STATE_INITIALIZER(sname, sabbr, cr) \
+DEFINE_RCU_TPS(sname) \
 struct rcu_state sname##_state = { \
.level = { ##_state.node[0] }, \
.call = cr, \
@@ -93,7 +102,7 @@ struct rcu_state sname##_state = { \
.orphan_donetail = ##_state.orphan_donelist, \
.barrier_mutex = __MUTEX_INITIALIZER(sname##_state.barrier_mutex), \
.onoff_mutex = __MUTEX_INITIALIZER(sname##_state.onoff_mutex), \
-   .name = sname##_varname, \
+   .name = RCU_STATE_NAME(sname), \
.abbr = sabbr, \
 }; \
 DEFINE_PER_CPU(struct rcu_data, sname##_data)
-- 
1.8.3.2

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