Ping: Add 32 bit VDSO time function support

2014-03-04 Thread Stefani Seibold
Hi,

again i want ask if there is a change to bring the patch back to tip
and/or linux next?

I also need a review of [Patch v22 10/12] x86: Add 32 bit VDSO time
support for 64 bit kernel.

Some more tests and acked-by would be also fine :-)

Till the 32 bit VDSO time functions are not in the vanilla kernel
tree, there is no way to get in the glibc patch into glibc.

The glibc is available under 
http://seibold.net/glibc.patch, it applies with glibc 2.18, 2.19 and
glibc git master.

- Stefani


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


Re: [PATCH 4/4] phy: miphy365x: Provide support for the MiPHY356x Generic PHY

2014-03-04 Thread Mark Rutland
On Fri, Feb 14, 2014 at 11:23:56AM +, Lee Jones wrote:
> The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> devices. It has 2 ports which it can use for either; both SATA, both
> PCIe or one of each in any configuration.
> 
> Cc: Kishon Vijay Abraham I 
> Signed-off-by: Lee Jones 
> ---
>  drivers/phy/Kconfig |  10 +
>  drivers/phy/Makefile|   1 +
>  drivers/phy/phy-miphy365x.c | 614 
> 
>  3 files changed, 625 insertions(+)
>  create mode 100644 drivers/phy/phy-miphy365x.c

[...]

> +enum miphy_sata_gen {
> +   SATA_GEN1 = 1,
> +   SATA_GEN2,
> +   SATA_GEN3
> +};

It would be nice to have a comment here that these values are ABI and
cannot change.

[...]

> +static struct phy *miphy365x_phy_xlate(struct device *dev,
> +  struct of_phandle_args *args)
> +{
> +   struct miphy365x_dev *state = dev_get_drvdata(dev);
> +   u8 port = args->args[0];
> +   u8 type = args->args[1];

In case of a bad dt, it would be nice to check args->arg_count == 2.

ALso, we throw away the top 24 bits, which may have been set
erroneously. If we want to make use of those in future we should test
they are clear here to force people to do the right thing.

Otherwise, this looks fine to me.

With those additions:

Acked-by: Mark Rutland 

Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Re: [PATCH] IOMMU: iommu module do not check NULL return of kmem_cache_zalloc

2014-03-04 Thread Joerg Roedel
On Wed, Mar 05, 2014 at 10:31:17AM +0800, Zhouyi Zhou wrote:
> Thanks Joerg for reviewing
> Checking the null pointer in iopte_free guarantees kmem_cache_free
> is happy all the time.

Can you send this as a new patch in a new thread please?

Thanks,

Joerg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Part2 V2 00/17] Enhance DMAR drivers to handle PCI/memory hotplug events

2014-03-04 Thread Joerg Roedel
On Wed, Feb 19, 2014 at 02:07:20PM +0800, Jiang Liu wrote:
> Jiang Liu (17):
>   iommu/vt-d: avoid double free of g_iommus on error recovery path
>   iommu/vt-d: avoid caching stale domain_device_info and fix memory
> leak
>   iommu/vt-d: avoid caching stale domain_device_info when hot-removing
> PCI device
>   iommu/vt-d: factor out dmar_alloc_dev_scope() for later reuse
>   iommu/vt-d: move private structures and variables into intel-iommu.c
>   iommu/vt-d: simplify function get_domain_for_dev()
>   iommu/vt-d: free resources if failed to create domain for PCIe
> endpoint
>   iommu/vt-d: reduce duplicated code to handle virtual machine domains
>   iommu/vt-d: fix incorrect iommu_count for si_domain
>   iommu/vt-d: check for NULL pointer when freeing IOMMU data structure
>   iommu/vt-d: fix error in detect ATS capability
>   iommu/vt-d: introduce macro for_each_dev_scope() to walk device scope
> entries
>   iommu/vt-d: introduce a rwsem to protect global data structures
>   iommu/vt-d: use RCU to protect global resources in interrupt context
>   iommu/vt-d, PCI: update DRHD/RMRR/ATSR device scope caches when PCI
> hotplug happens
>   iommu/vt-d, PCI: unify the way to process DMAR device scope array
>   iommu/vt-d: update IOMMU state when memory hotplug happens
> 
>  drivers/iommu/dmar.c|  412 +--
>  drivers/iommu/intel-iommu.c |  750 
> ++-
>  drivers/iommu/intel_irq_remapping.c |  108 +++--
>  drivers/iommu/iova.c|   64 ++-
>  include/linux/dmar.h|   74 ++--
>  include/linux/iova.h|2 +
>  6 files changed, 848 insertions(+), 562 deletions(-)

Applied, thanks Jiang.


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


Re: [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x

2014-03-04 Thread Mark Rutland
On Fri, Feb 14, 2014 at 11:23:55AM +, Lee Jones wrote:
> The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> devices. It has 2 ports which it can use for either; both SATA, both
> PCIe or one of each in any configuration.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Srinivas Kandagatla 
> Signed-off-by: Lee Jones 
> ---
>  arch/arm/boot/dts/stih416-b2020-revE.dts |  6 +-
>  arch/arm/boot/dts/stih416-b2020.dts  |  6 ++
>  arch/arm/boot/dts/stih416.dtsi   | 13 +
>  3 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts 
> b/arch/arm/boot/dts/stih416-b2020-revE.dts
> index a874570..dbe67fa 100644
> --- a/arch/arm/boot/dts/stih416-b2020-revE.dts
> +++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
> @@ -32,6 +32,10 @@
>   ethernet1: ethernet@fef08000 {
>   snps,reset-gpio = < 7>;
>   };
> - };
>  
> + miphy365x_phy: miphy365x@0 {

This has registers at 0x0? Or is the unit-address wrong?

> + st,pcie_tx_pol_inv = <1>;

This is a boolean. The '= <1>' is not required and is confusing.

> + st,sata_gen = "gen3";

s/"gen3"/<3>/

Both these properties need s/_/-/ applied.

All these apply to the other dts too.

> + };
> + };
>  };
> diff --git a/arch/arm/boot/dts/stih416-b2020.dts 
> b/arch/arm/boot/dts/stih416-b2020.dts
> index 276f28d..fd9cbad 100644
> --- a/arch/arm/boot/dts/stih416-b2020.dts
> +++ b/arch/arm/boot/dts/stih416-b2020.dts
> @@ -13,4 +13,10 @@
>   model = "STiH416 B2020";
>   compatible = "st,stih416", "st,stih416-b2020";

This compatible list is the wrong way around. Left to right should go
from most specific to most general / oldest variant.

>  
> + soc {
> + miphy365x_phy: miphy365x@0 {

> + st,pcie_tx_pol_inv = <1>;
> + st,sata_gen = "gen3";
> + };
> + };
>  };
> diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
> index 85b8063..9fd8efb 100644
> --- a/arch/arm/boot/dts/stih416.dtsi
> +++ b/arch/arm/boot/dts/stih416.dtsi
> @@ -9,6 +9,8 @@
>  #include "stih41x.dtsi"
>  #include "stih416-clock.dtsi"
>  #include "stih416-pinctrl.dtsi"
> +
> +#include 
>  #include 
>  #include 
>  / {
> @@ -140,5 +142,16 @@
>   clocks  = <_S_ICN_REG_0>;
>   };
>  
> + miphy365x_phy: miphy365x@0 {

The unit-address should be fe382000 rather than 0 to match the first reg
entry.

Cheers,
Mark.

> + compatible  = "st,miphy365x-phy";
> + reg = <0xfe382000 0x100>,
> +   <0xfe38a000 0x100>,
> +   <0xfe394000 0x100>,
> +   <0xfe804000 0x100>;
> + reg-names   = "sata0", "sata1", "pcie0", "pcie1";
> +
> + #phy-cells  = <2>;
> + st,syscfg   = <_rear>;
> + };
>   };
>  };
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] Add option to build with -O3

2014-03-04 Thread jon
From: Jon Ringle 

Signed-off-by: Jon Ringle 
---
 Makefile |  2 ++
 init/Kconfig | 19 ---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 78209ee..e7f0b3c 100644
--- a/Makefile
+++ b/Makefile
@@ -581,6 +581,8 @@ all: vmlinux
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
 KBUILD_CFLAGS  += -Os $(call cc-disable-warning,maybe-uninitialized,)
+else ifdef CONFIG_CC_OPTIMIZE_FOR_SPEED
+KBUILD_CFLAGS   += -O3
 else
 KBUILD_CFLAGS  += -O2
 endif
diff --git a/init/Kconfig b/init/Kconfig
index 009a797..17d4c62 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1233,13 +1233,26 @@ source "usr/Kconfig"
 
 endif
 
+choice
+prompt "Optimize"
+
+config CC_OPTIMIZE_NORMAL
+bool "Optimize Normal (-O2)"
+help
+  Enabling this option will pass "-O2" to gcc
 config CC_OPTIMIZE_FOR_SIZE
-   bool "Optimize for size"
+   bool "Optimize for size (-Os)"
help
- Enabling this option will pass "-Os" instead of "-O2" to gcc
+ Enabling this option will pass "-Os" to gcc
  resulting in a smaller kernel.
 
- If unsure, say N.
+config CC_OPTIMIZE_FOR_SPEED
+bool "Optimze for speed (-O3)"
+help
+  Enabling this option will pass "-O3" to gcc
+  resulting in a larger kernel (but possibly faster)
+
+endchoice
 
 config SYSCTL
bool
-- 
1.8.5.4

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


Re: [PATCH 2/4] phy: miphy365x: Add MiPHY365x header file for DT x Driver defines

2014-03-04 Thread Mark Rutland
On Fri, Feb 14, 2014 at 11:23:54AM +, Lee Jones wrote:
> This provides the shared header file which will be reference from both
> the MiPHY365x driver and its associated Device Tree node(s).
> 
> Cc: devicet...@vger.kernel.org
> Cc: Srinivas Kandagatla 
> Signed-off-by: Lee Jones 
> ---
>  include/dt-bindings/phy/phy-miphy365x.h | 25 +
>  1 file changed, 25 insertions(+)
>  create mode 100644 include/dt-bindings/phy/phy-miphy365x.h

Given this defines part of the binding, it should probably go in the
same patch.

Cheers,
Mark.

> 
> diff --git a/include/dt-bindings/phy/phy-miphy365x.h 
> b/include/dt-bindings/phy/phy-miphy365x.h
> new file mode 100644
> index 000..8757c02
> --- /dev/null
> +++ b/include/dt-bindings/phy/phy-miphy365x.h
> @@ -0,0 +1,25 @@
> +/*
> + * This header provides constants for the phy framework
> + * based on the STMicroelectronics miphy365x.
> + */
> +#ifndef _DT_BINDINGS_PHY_MIPHY
> +#define _DT_BINDINGS_PHY_MIPHY
> +
> +/* Supports 16 ports without a datatype change (u8 & 0xF0). */
> +#define MIPHY_PORT_0 0
> +#define MIPHY_PORT_1 1
> +#define MIPHY_PORT_2 2
> +#define MIPHY_PORT_3 3
> +
> +/* Supports 16 types without a datatype change (u8 & 0x0F). */
> +#define MIPHY_TYPE_SHIFT 4
> +#define MIPHY_TYPE_SATA  (0 << MIPHY_TYPE_SHIFT)
> +#define MIPHY_TYPE_PCIE  (1 << MIPHY_TYPE_SHIFT)
> +#define MIPHY_TYPE_USB   (2 << MIPHY_TYPE_SHIFT)
> +
> +#define MIPHY_SATA_PORT0 (MIPHY_TYPE_SATA) | (MIPHY_PORT_0)
> +#define MIPHY_SATA_PORT1 (MIPHY_TYPE_SATA) | (MIPHY_PORT_1)
> +#define MIPHY_PCIE_PORT0 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_0)
> +#define MIPHY_PCIE_PORT1 (MIPHY_TYPE_PCIE) | (MIPHY_PORT_1)
> +
> +#endif /* _DT_BINDINGS_PHY_MIPHY */
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 RESEND 2/2] mtd: Fix the behavior of otp write if there is not enough room for data

2014-03-04 Thread Brian Norris
A few more things...

On Tue, Mar 04, 2014 at 11:20:10PM -0800, Brian Norris wrote:
> On Tue, Jan 28, 2014 at 09:29:45AM +0100, Christian Riesch wrote:
> > An OTP write shall write as much data as possible to the OTP memory
> > and return the number of bytes that have actually been written.
> > If no data could be written at all due to lack of OTP memory,
> > return -ENOSPC.
[snip]
> > diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c 
> > b/drivers/mtd/chips/cfi_cmdset_0001.c
> > index 7aa581f..cf423a6 100644
> > --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> > +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> > @@ -2387,8 +2387,17 @@ static int cfi_intelext_write_user_prot_reg(struct 
> > mtd_info *mtd, loff_t from,
> > size_t len, size_t *retlen,
> >  u_char *buf)
> >  {
> > -   return cfi_intelext_otp_walk(mtd, from, len, retlen,
> > -buf, do_otp_write, 1);
> > +   int ret;
> > +
> > +   ret = cfi_intelext_otp_walk(mtd, from, len, retlen,
> > +   buf, do_otp_write, 1);
> > +
> > +   /* if no data could be written due to lack of OTP memory,
> > +  return ENOSPC */
> 
> /*
>  * Can you use this style of mult-line comments please?
>  * It's in Documentation/CodingStyle
>  */
> 
> > +   if (!ret && len && !(*retlen))
> > +   return -ENOSPC;
> 
> Couldn't (shouldn't) this check be pushed to the common
> mtd_write_user_prot_reg() helper in mtdcore.c? And once you do that, you
> will see that cfi_intelext_write_user_prot_reg() (and other
> mtd->_write_user_prot_reg() implementations) will never be called with
> len == 0. So this just becomes (in mtdcore.c):
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 0a7d77e65335..ee6730748f7e 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -909,11 +909,16 @@ EXPORT_SYMBOL_GPL(mtd_read_fact_prot_reg);
>  int mtd_get_user_prot_info(struct mtd_info *mtd, size_t len, size_t *retlen,
>  struct otp_info *buf)
>  {
> + int ret;
> +
>   if (!mtd->_get_user_prot_info)
>   return -EOPNOTSUPP;
>   if (!len)
>   return 0;
> - return mtd->_get_user_prot_info(mtd, len, retlen, buf);
> + ret = mtd->_get_user_prot_info(mtd, len, retlen, buf);
> + if (ret)
> + return ret;
> + return !(*retlen) ? -ENOSPC: 0;
>  }
>  EXPORT_SYMBOL_GPL(mtd_get_user_prot_info);

Sorry, I patched the wrong function here! Please use your brain and
apply this to the OTP write function :)

> > +
> > +   return ret;
> >  }
> >  
> >  static int cfi_intelext_lock_user_prot_reg(struct mtd_info *mtd,
> > diff --git a/drivers/mtd/devices/mtd_dataflash.c 
> > b/drivers/mtd/devices/mtd_dataflash.c
> > index 09c69ce..5236d85 100644
> > --- a/drivers/mtd/devices/mtd_dataflash.c
> > +++ b/drivers/mtd/devices/mtd_dataflash.c
> > @@ -545,14 +545,11 @@ static int dataflash_write_user_otp(struct mtd_info 
> > *mtd,
> > struct dataflash*priv = mtd->priv;
> > int status;
> >  
> 
> I'm not sure I quite follow the logic for the following hunk. I think it
> deserves some more explanation, either in your commit or in a comment.
> As it stands, you're deleting a comment and potentially changing the
> return code behavior subtly.
> 
> > -   if (len > 64)
> > -   return -EINVAL;
> > -
> > -   /* Strictly speaking, we *could* truncate the write ... but
> > -* let's not do that for the only write that's ever possible.
> > -*/
> > -   if ((from + len) > 64)
> > -   return -EINVAL;
> > +   if ((from + len) > 64) {
> > +   len = 64 - from;
> 
> Why are you reassigning len? Are you trying to undo the comment above,
> so that you *can* truncate the write? (It looks like there are other
> implmentations which will truncate the write and return -ENOSPC, FWIW.)
> 
> > +   if (len <= 0)
> > +   return -ENOSPC;
> > +   }

I looked a bit more at [1] and it looks like you're actually trying to
straighten out some inconsistencies (hence the "harmonizing" in
$subject). I think this warrants:

(1) A little more in the commit message. You describe the new policy,
but you should also note *how* this is changing existing
implementations.

(2) A comment next to mtd_write_user_prot_reg() to describe the new
harmony.

> >  
> > /* OUT: OP_WRITE_SECURITY, 3 zeroes, 64 data-or-zero bytes
> >  * IN:  ignore all

[1] http://patchwork.ozlabs.org/patch/239897/

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


Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x

2014-03-04 Thread Mark Rutland
On Fri, Feb 14, 2014 at 11:23:53AM +, Lee Jones wrote:
> The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> devices. It has 2 ports which it can use for either; both SATA, both
> PCIe or one of each in any configuration.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Srinivas Kandagatla 
> Signed-off-by: Lee Jones 
> ---
>  .../devicetree/bindings/phy/phy-miphy365x.txt  | 54 
> ++
>  1 file changed, 54 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt 
> b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> new file mode 100644
> index 000..96f269f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
> @@ -0,0 +1,54 @@
> +STMicroelectronics STi MIPHY365x PHY binding
> +
> +
> +This binding describes a miphy device that is used to control PHY hardware
> +for SATA and PCIe.
> +
> +Required properties:
> +- compatible: Should be "st,miphy365x-phy"
> +- #phy-cells: Should be 2 (See second example)
> + First cell is the port number; MIPHY_PORT_{0,1}
> + Second cell is device type; MIPHY_TYPE_{SATA,PCI}

Either this should refer to the header file, or specific values should
be given in the binding document.

> +- reg: Address and length of the register set for the device
> +- reg-names:  The names of the register addresses corresponding to the
> +   registers filled in "reg"
> + Options are; sata{0,1} and pcie{0,1} (See first example)

How about something like:

- reg: a list of offset + length pairs, one for each entry in reg-names
- reg-names: should contain some of:
  * "sata0" for ...
  * "sata1" for ...
  * "pcie0" for ...
  * "pcie1" for ...

Where ... might just be "the sata port 0 registers"

> +- st,syscfg : Should be a phandle of the system configuration register group
> +   which contain the SATA, PCIe mode setting bits

I'll assume this is well-defined by some other binding.

> +
> +Optional properties:
> +- st,sata-gen : Generation of locally attached SATA IP. Expected 
> values
> +are {1,2,3). If not supplied generation 1 hardware will
> +be expected
> +- st,pcie-tx-pol-inv : Bool property to invert the polarity PCIe Tx (Txn/Txp)
> +- st,sata-tx-pol-inv : Bool property to invert the polarity SATA Tx (Txn/Txp)

It might just be me, but the phrase "invert the polarity {SATA,PCIe} Tx"
sounds odd. What exactly is being inverted?

> +
> +Example:
> +
> + miphy365x_phy: miphy365x@0 {
> + compatible = "st,miphy365x-phy";
> + #phy-cells = <2>;
> + reg =   <0xfe382000 0x100>,
> + <0xfe38a000 0x100>,
> + <0xfe394000 0x100>,
> + <0xfe804000 0x100>;
> + reg-names = "sata0", "sata1", "pcie0", "pcie1";
> + st,syscfg= <_rear>;

Nit: missing space before '='.

> + };
> +
> +Specifying phy control of devices
> +=
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the miphy device node, a port number
> +and a device type.
> +
> +Example:
> +
> +#include 
> +
> + sata0: sata@fe38 {
> + ...
> + phys  = <_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
> + ...
> + };

Is there not a generic phy binding we can point to? It seems a bit
redundant to do this in each phy binding.

Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add option to build with -O3

2014-03-04 Thread Jon Ringle
On Wed, 5 Mar 2014, Greg KH wrote:

> On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
> > +config CC_OPTIMIZE_FOR_SPEED
> > +bool "Optimze for speed (-O3)"
> > +help
> > +  Enabling this option will pass "-O3" to gcc
> > +  resulting in a larger kernel (but possibly faster)
> 
> Are you sure about that?  Have you measured it?

(Resending this message, since it was "destroyed". Hopefully, this is now 
an an acceptable form :)

I do know that there is an improvement performance-wise for my particular 
use-case.

My target is an ARM board being built with gcc-4.8.2. My board has on it a 
sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus, 
so when an interrupt comes in to indicate that there is data available to 
be read, I need to get the data over the i2c bus. I do this on a kthread 
to do this work. The i2c transactions (using i2c-davinci driver) are also 
interrupt driven. I was seeing a lot of lost packets when receiving data 
at only 19200. Adding the -O3 compile option helped in this regard in that 
I am now rarely seeing packet loss.

Jon
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/11] drivercore: Bind/unbind power domain on probe/remove

2014-03-04 Thread Ulf Hansson
On 3 March 2014 17:02, Tomasz Figa  wrote:
> On a number of platforms, devices are part of controllable power
> domains, which need to be enabled before such devices can be accessed
> and may be powered down when the device is idle to save some power.
> This means that on systems that support power domain control using
> generic power domains subsystem, it is necessary to add device to its
> power domain before binding a driver to it and remove it from its power
> domain after its driver is unbound to make sure that an unused device
> does not affect power domain state.
>
> Since this is not limited to particular busses and specific
> archs/platforms, it is more convenient to do the above directly in
> driver core, just as done with pinctrl default configuration. This patch
> adds necessary code to really_probe() and __device_release_driver() to
> achieve this and maintain consistent stack-like ordering of operations
> happening when binding and unbinding a driver.
>
> Signed-off-by: Tomasz Figa 

This definitely makes sense to me!

Reviewed-by: Ulf Hansson 

> ---
>  drivers/base/dd.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 0605176..78e5b36 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -273,6 +274,11 @@ static int really_probe(struct device *dev, struct 
> device_driver *drv)
>
> dev->driver = drv;
>
> +   /* If using genpd, bind power domain now before probing */
> +   ret = genpd_bind_domain(dev);
> +   if (ret)
> +   goto probe_failed;
> +
> /* If using pinctrl, bind pins now before probing */
> ret = pinctrl_bind_pins(dev);
> if (ret)
> @@ -303,6 +309,7 @@ static int really_probe(struct device *dev, struct 
> device_driver *drv)
>  probe_failed:
> devres_release_all(dev);
> driver_sysfs_remove(dev);
> +   genpd_unbind_domain(dev);
> dev->driver = NULL;
> dev_set_drvdata(dev, NULL);
>
> @@ -513,7 +520,7 @@ static void __device_release_driver(struct device *dev)
> 
> blocking_notifier_call_chain(>bus->p->bus_notifier,
>  
> BUS_NOTIFY_UNBOUND_DRIVER,
>  dev);
> -
> +   genpd_unbind_domain(dev);
> }
>  }
>
> --
> 1.9.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[RFC 1/6] sched: remove unused SCHED_INIT_NODE

2014-03-04 Thread Vincent Guittot
not used since new numa scheduler init sequence

Signed-off-by: Vincent Guittot 
---
 arch/metag/include/asm/topology.h |   27 ---
 1 file changed, 27 deletions(-)

diff --git a/arch/metag/include/asm/topology.h 
b/arch/metag/include/asm/topology.h
index 8e9c0b3..e95f874 100644
--- a/arch/metag/include/asm/topology.h
+++ b/arch/metag/include/asm/topology.h
@@ -3,33 +3,6 @@
 
 #ifdef CONFIG_NUMA
 
-/* sched_domains SD_NODE_INIT for Meta machines */
-#define SD_NODE_INIT (struct sched_domain) {   \
-   .parent = NULL, \
-   .child  = NULL, \
-   .groups = NULL, \
-   .min_interval   = 8,\
-   .max_interval   = 32,   \
-   .busy_factor= 32,   \
-   .imbalance_pct  = 125,  \
-   .cache_nice_tries   = 2,\
-   .busy_idx   = 3,\
-   .idle_idx   = 2,\
-   .newidle_idx= 0,\
-   .wake_idx   = 0,\
-   .forkexec_idx   = 0,\
-   .flags  = SD_LOAD_BALANCE   \
-   | SD_BALANCE_FORK   \
-   | SD_BALANCE_EXEC   \
-   | SD_BALANCE_NEWIDLE\
-   | SD_SERIALIZE, \
-   .last_balance   = jiffies,  \
-   .balance_interval   = 1,\
-   .nr_balance_failed  = 0,\
-   .max_newidle_lb_cost= 0,\
-   .next_decay_max_lb_cost = jiffies,  \
-}
-
 #define cpu_to_node(cpu)   ((void)(cpu), 0)
 #define parent_node(node)  ((void)(node), 0)
 
-- 
1.7.9.5

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


[PATCH 2/6] sched: rework of sched_domain topology definition

2014-03-04 Thread Vincent Guittot
We replace the old way to configure the scheduler topology with a new method
which enables a platform to declare additionnal level (if needed).

We still have a default topology table definition that can be used by platform
that don't want more level than the SMT, MC, CPU and NUMA ones. This table can
be overwritten by an arch which wants to add new level where a load balance
make sense like BOOK or powergating level.

For each level, we need a function pointer that returns cpumask for each cpu,
the flags configuration and a name. Each level must be a subset on
the next one. The build sequence of the sched_domain will take care of
removing useless levels like those with 1 CPU and those with the same CPU span
and relevant information for load balancing than its child .

Signed-off-by: Vincent Guittot 
---
 arch/ia64/include/asm/topology.h |   24 
 arch/s390/include/asm/topology.h |2 -
 arch/tile/include/asm/topology.h |   33 --
 include/linux/sched.h|   29 +
 include/linux/topology.h |  128 +++--
 kernel/sched/core.c  |  227 +++---
 6 files changed, 156 insertions(+), 287 deletions(-)

diff --git a/arch/ia64/include/asm/topology.h b/arch/ia64/include/asm/topology.h
index a2496e4..20d12fa 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -46,30 +46,6 @@
 
 void build_cpu_to_node_map(void);
 
-#define SD_CPU_INIT (struct sched_domain) {\
-   .parent = NULL, \
-   .child  = NULL, \
-   .groups = NULL, \
-   .min_interval   = 1,\
-   .max_interval   = 4,\
-   .busy_factor= 64,   \
-   .imbalance_pct  = 125,  \
-   .cache_nice_tries   = 2,\
-   .busy_idx   = 2,\
-   .idle_idx   = 1,\
-   .newidle_idx= 0,\
-   .wake_idx   = 0,\
-   .forkexec_idx   = 0,\
-   .flags  = SD_LOAD_BALANCE   \
-   | SD_BALANCE_NEWIDLE\
-   | SD_BALANCE_EXEC   \
-   | SD_BALANCE_FORK   \
-   | SD_WAKE_AFFINE,   \
-   .last_balance   = jiffies,  \
-   .balance_interval   = 1,\
-   .nr_balance_failed  = 0,\
-}
-
 #endif /* CONFIG_NUMA */
 
 #ifdef CONFIG_SMP
diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/topology.h
index 05425b1..07763bd 100644
--- a/arch/s390/include/asm/topology.h
+++ b/arch/s390/include/asm/topology.h
@@ -64,8 +64,6 @@ static inline void s390_init_cpu_topology(void)
 };
 #endif
 
-#define SD_BOOK_INIT   SD_CPU_INIT
-
 #include 
 
 #endif /* _ASM_S390_TOPOLOGY_H */
diff --git a/arch/tile/include/asm/topology.h b/arch/tile/include/asm/topology.h
index d15c0d8..9383118 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -44,39 +44,6 @@ static inline const struct cpumask *cpumask_of_node(int node)
 /* For now, use numa node -1 for global allocation. */
 #define pcibus_to_node(bus)((void)(bus), -1)
 
-/*
- * TILE architecture has many cores integrated in one processor, so we need
- * setup bigger balance_interval for both CPU/NODE scheduling domains to
- * reduce process scheduling costs.
- */
-
-/* sched_domains SD_CPU_INIT for TILE architecture */
-#define SD_CPU_INIT (struct sched_domain) {\
-   .min_interval   = 4,\
-   .max_interval   = 128,  \
-   .busy_factor= 64,   \
-   .imbalance_pct  = 125,  \
-   .cache_nice_tries   = 1,\
-   .busy_idx   = 2,\
-   .idle_idx   = 1,\
-   .newidle_idx= 0,\
-   .wake_idx   = 0,\
-   .forkexec_idx   = 0,\
-   \
-   .flags  = 1*SD_LOAD_BALANCE \
-   | 1*SD_BALANCE_NEWIDLE  \
-   | 1*SD_BALANCE_EXEC \
-   | 1*SD_BALANCE_FORK \
-   | 

[RFC 5/6] sched: add a new SD_SHARE_POWERDOMAIN for sched_domain

2014-03-04 Thread Vincent Guittot
A new flag SD_SHARE_POWERDOMAIN is created to reflect whether groups of CPUs
in a sched_domain level can or not reach different power state. As an example,
the flag should be cleared at CPU level if groups of cores can be power gated
independently. This information can be used to add load balancing level between
group of CPUs than can power gate independantly. The default behavior of the
scheduler is to spread tasks across CPUs and groups of CPUs so the flag is set
into all sched_domains.

Signed-off-by: Vincent Guittot 
---
 include/linux/sched.h |1 +
 kernel/sched/core.c   |9 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index dbc35dd..182a080 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -861,6 +861,7 @@ enum cpu_idle_type {
 #define SD_BALANCE_WAKE0x0010  /* Balance on wakeup */
 #define SD_WAKE_AFFINE 0x0020  /* Wake task to waking CPU */
 #define SD_SHARE_CPUPOWER  0x0080  /* Domain members share cpu power */
+#define SD_SHARE_POWERDOMAIN   0x0100  /* Domain members share power domain */
 #define SD_SHARE_PKG_RESOURCES 0x0200  /* Domain members share cpu pkg 
resources */
 #define SD_SERIALIZE   0x0400  /* Only a single load balancing 
instance */
 #define SD_ASYM_PACKING0x0800  /* Place busy groups earlier in 
the domain */
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7606de0..b28cff0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5283,7 +5283,8 @@ static int sd_degenerate(struct sched_domain *sd)
 SD_BALANCE_FORK |
 SD_BALANCE_EXEC |
 SD_SHARE_CPUPOWER |
-SD_SHARE_PKG_RESOURCES)) {
+SD_SHARE_PKG_RESOURCES |
+SD_SHARE_POWERDOMAIN)) {
if (sd->groups != sd->groups->next)
return 0;
}
@@ -5314,7 +5315,8 @@ sd_parent_degenerate(struct sched_domain *sd, struct 
sched_domain *parent)
SD_BALANCE_EXEC |
SD_SHARE_CPUPOWER |
SD_SHARE_PKG_RESOURCES |
-   SD_PREFER_SIBLING);
+   SD_PREFER_SIBLING |
+   SD_SHARE_POWERDOMAIN);
if (nr_node_ids == 1)
pflags &= ~SD_SERIALIZE;
}
@@ -5932,7 +5934,8 @@ static struct cpumask ***sched_domains_numa_masks;
(SD_SHARE_CPUPOWER |\
 SD_SHARE_PKG_RESOURCES |   \
 SD_NUMA |  \
-SD_ASYM_PACKING)
+SD_ASYM_PACKING |  \
+SD_SHARE_POWERDOMAIN)
 
 static struct sched_domain *
 sd_init(struct sched_domain_topology_level *tl, int cpu)
-- 
1.7.9.5

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


Re: [PATCH v2 RESEND 2/2] mtd: Fix the behavior of otp write if there is not enough room for data

2014-03-04 Thread Brian Norris
Hi Christian,

A few comments below.

On Tue, Jan 28, 2014 at 09:29:45AM +0100, Christian Riesch wrote:
> An OTP write shall write as much data as possible to the OTP memory
> and return the number of bytes that have actually been written.
> If no data could be written at all due to lack of OTP memory,
> return -ENOSPC.
> 
> Signed-off-by: Christian Riesch 
> Cc: Artem Bityutskiy 
> Cc: Kyungmin Park 
> Cc: Amul Kumar Saha 
> ---
>  drivers/mtd/chips/cfi_cmdset_0001.c |   13 +++--
>  drivers/mtd/devices/mtd_dataflash.c |   13 +
>  drivers/mtd/mtdchar.c   |7 +++
>  drivers/mtd/onenand/onenand_base.c  |   10 +-
>  4 files changed, 32 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c 
> b/drivers/mtd/chips/cfi_cmdset_0001.c
> index 7aa581f..cf423a6 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0001.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0001.c
> @@ -2387,8 +2387,17 @@ static int cfi_intelext_write_user_prot_reg(struct 
> mtd_info *mtd, loff_t from,
>   size_t len, size_t *retlen,
>u_char *buf)
>  {
> - return cfi_intelext_otp_walk(mtd, from, len, retlen,
> -  buf, do_otp_write, 1);
> + int ret;
> +
> + ret = cfi_intelext_otp_walk(mtd, from, len, retlen,
> + buf, do_otp_write, 1);
> +
> + /* if no data could be written due to lack of OTP memory,
> +return ENOSPC */

/*
 * Can you use this style of mult-line comments please?
 * It's in Documentation/CodingStyle
 */

> + if (!ret && len && !(*retlen))
> + return -ENOSPC;

Couldn't (shouldn't) this check be pushed to the common
mtd_write_user_prot_reg() helper in mtdcore.c? And once you do that, you
will see that cfi_intelext_write_user_prot_reg() (and other
mtd->_write_user_prot_reg() implementations) will never be called with
len == 0. So this just becomes (in mtdcore.c):

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 0a7d77e65335..ee6730748f7e 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -909,11 +909,16 @@ EXPORT_SYMBOL_GPL(mtd_read_fact_prot_reg);
 int mtd_get_user_prot_info(struct mtd_info *mtd, size_t len, size_t *retlen,
   struct otp_info *buf)
 {
+   int ret;
+
if (!mtd->_get_user_prot_info)
return -EOPNOTSUPP;
if (!len)
return 0;
-   return mtd->_get_user_prot_info(mtd, len, retlen, buf);
+   ret = mtd->_get_user_prot_info(mtd, len, retlen, buf);
+   if (ret)
+   return ret;
+   return !(*retlen) ? -ENOSPC: 0;
 }
 EXPORT_SYMBOL_GPL(mtd_get_user_prot_info);
 

> +
> + return ret;
>  }
>  
>  static int cfi_intelext_lock_user_prot_reg(struct mtd_info *mtd,
> diff --git a/drivers/mtd/devices/mtd_dataflash.c 
> b/drivers/mtd/devices/mtd_dataflash.c
> index 09c69ce..5236d85 100644
> --- a/drivers/mtd/devices/mtd_dataflash.c
> +++ b/drivers/mtd/devices/mtd_dataflash.c
> @@ -545,14 +545,11 @@ static int dataflash_write_user_otp(struct mtd_info 
> *mtd,
>   struct dataflash*priv = mtd->priv;
>   int status;
>  

I'm not sure I quite follow the logic for the following hunk. I think it
deserves some more explanation, either in your commit or in a comment.
As it stands, you're deleting a comment and potentially changing the
return code behavior subtly.

> - if (len > 64)
> - return -EINVAL;
> -
> - /* Strictly speaking, we *could* truncate the write ... but
> -  * let's not do that for the only write that's ever possible.
> -  */
> - if ((from + len) > 64)
> - return -EINVAL;
> + if ((from + len) > 64) {
> + len = 64 - from;

Why are you reassigning len? Are you trying to undo the comment above,
so that you *can* truncate the write? (It looks like there are other
implmentations which will truncate the write and return -ENOSPC, FWIW.)

> + if (len <= 0)
> + return -ENOSPC;
> + }
>  
>   /* OUT: OP_WRITE_SECURITY, 3 zeroes, 64 data-or-zero bytes
>* IN:  ignore all
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 0edb0ca..db99031 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -323,6 +323,13 @@ static ssize_t mtdchar_write(struct file *file, const 
> char __user *buf, size_t c
>   default:
>   ret = mtd_write(mtd, *ppos, len, , kbuf);
>   }
> + /* return -ENOSPC only if no data was written */
> + if ((ret == -ENOSPC) && (total_retlen)) {
> + ret = 0;
> + retlen = 0;
> + /* drop the remaining data */
> + count = 0;

This block can just be a 'break' statement, no?

> + }

I'm a bit wary of changing the behavior of 

[RFC 4/6] sched: powerpc: create a dedicated topology table

2014-03-04 Thread Vincent Guittot
Create a dedicated topology table for handling asymetric feature.
The current proposal creates a new level which describes which groups of CPUs
take adavantge of SD_ASYM_PACKING. The useless level will be removed during the
build of the sched_domain topology.

Another solution would be to set SD_ASYM_PACKING in the sd_flags of SMT level
during the boot sequence and before the build of the sched_domain topology.

Signed-off-by: Vincent Guittot 
---
 arch/powerpc/kernel/smp.c |   35 +++
 kernel/sched/core.c   |6 --
 2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ac2621a..75da054 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -755,6 +755,32 @@ int setup_profiling_timer(unsigned int multiplier)
return 0;
 }
 
+#ifdef CONFIG_SCHED_SMT
+/* cpumask of CPUs with asymetric SMT dependancy */
+static const struct cpumask *cpu_asmt_mask(int cpu)
+{
+   if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
+   printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
+   return topology_thread_cpumask(cpu);
+   }
+   return cpumask_of(cpu);
+}
+#endif
+
+static struct sched_domain_topology_level powerpc_topology[] = {
+#ifdef CONFIG_SCHED_SMT
+   { cpu_asmt_mask, SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES | 
SD_ASYM_PACKING, SD_INIT_NAME(ASMT) },
+   { cpu_smt_mask, SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES, 
SD_INIT_NAME(SMT) },
+#endif
+   { cpu_cpu_mask, SD_INIT_NAME(DIE) },
+   { NULL, },
+};
+
+static void __init set_sched_topology(void)
+{
+   sched_domain_topology = powerpc_topology;
+}
+
 void __init smp_cpus_done(unsigned int max_cpus)
 {
cpumask_var_t old_mask;
@@ -779,15 +805,8 @@ void __init smp_cpus_done(unsigned int max_cpus)
 
dump_numa_cpu_topology();
 
-}
+   set_sched_topology();
 
-int arch_sd_sibling_asym_packing(void)
-{
-   if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
-   printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
-   return SD_ASYM_PACKING;
-   }
-   return 0;
 }
 
 #ifdef CONFIG_HOTPLUG_CPU
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 3479467..7606de0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5818,11 +5818,6 @@ static void init_sched_groups_power(int cpu, struct 
sched_domain *sd)
atomic_set(>sgp->nr_busy_cpus, sg->group_weight);
 }
 
-int __weak arch_sd_sibling_asym_packing(void)
-{
-   return 0*SD_ASYM_PACKING;
-}
-
 /*
  * Initializers for schedule domains
  * Non-inlined to reduce accumulated stack pressure in build_sched_domains()
@@ -6000,7 +5995,6 @@ sd_init(struct sched_domain_topology_level *tl, int cpu)
if (sd->flags & SD_SHARE_CPUPOWER) {
sd->imbalance_pct = 110;
sd->smt_gain = 1178; /* ~15% */
-   sd->flags |= arch_sd_sibling_asym_packing();
 
} else if (sd->flags & SD_SHARE_PKG_RESOURCES) {
sd->imbalance_pct = 117;
-- 
1.7.9.5

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


[RFC 6/6] sched: ARM: create a dedicated scheduler topology table

2014-03-04 Thread Vincent Guittot
Create a dedicated topology table for ARM which will create new level to
differentiate CPUs that can or not powergate independantly from others.

The patch gives an example of how to add domain that will take advantage of
SD_SHARE_POWERDOMAIN.

Signed-off-by: Vincent Guittot 
---
 arch/arm/kernel/topology.c |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 0bc94b1..ae8ffbc 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -185,6 +185,15 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
return _topology[cpu].core_sibling;
 }
 
+/*
+ * The current assumption is that we can power gate each core independently.
+ * This will be superseded by DT binding once available.
+ */
+const struct cpumask *cpu_corepower_mask(int cpu)
+{
+   return _topology[cpu].thread_sibling;
+}
+
 static void update_siblings_masks(unsigned int cpuid)
 {
struct cputopo_arm *cpu_topo, *cpuid_topo = _topology[cpuid];
@@ -266,6 +275,20 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
 }
 
+static struct sched_domain_topology_level arm_topology[] = {
+#ifdef CONFIG_SCHED_MC
+   { cpu_corepower_mask, SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN, 
SD_INIT_NAME(GMC) },
+   { cpu_coregroup_mask, SD_SHARE_PKG_RESOURCES, SD_INIT_NAME(MC) },
+#endif
+   { cpu_cpu_mask, SD_INIT_NAME(DIE) },
+   { NULL, },
+};
+
+static void __init set_sched_topology(void)
+{
+   sched_domain_topology = arm_topology;
+}
+
 /*
  * init_cpu_topology is called at boot when only one cpu is running
  * which prevent simultaneous write access to cpu_topology array
@@ -289,4 +312,7 @@ void __init init_cpu_topology(void)
smp_wmb();
 
parse_dt_topology();
+
+   /* Set scheduler topology descriptor */
+   set_sched_topology();
 }
-- 
1.7.9.5

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


Re: [PATCH v2 01/11] base: power: Add generic OF-based power domain look-up

2014-03-04 Thread Ulf Hansson
On 3 March 2014 17:02, Tomasz Figa  wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa 
> ---
>  .../devicetree/bindings/power/power_domain.txt |  51 
>  drivers/base/power/domain.c| 298 
> +
>  include/linux/pm_domain.h  |  46 
>  kernel/power/Kconfig   |   4 +
>  4 files changed, 399 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> +   Typically 0 for nodes representing a single power domain and 1 for nodes
> +   providing multiple power domains (e.g. power controllers), but can be
> +   any value as specified by device tree binding documentation of particular
> +   provider.
> +
> +Example:
> +
> +   power: power-controller@1234 {
> +   compatible = "foo,power-controller";
> +   reg = <0x1234 0x1000>;
> +   #power-domain-cells = <1>;
> +   };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> +  of power controller specified by phandle.
> +
> +Example:
> +
> +   leaky-device@1235 {
> +   compatible = "foo,i-leak-current";
> +   reg = <0x1235 0x1000>;
> +   power-domain = < 0>;
> +   };
> +
> +The node above defines a typical power domain consumer device, which is 
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index dc127e5..006b455 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3,12 +3,16 @@
>   *
>   * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics 
> Corp.
>   *
> + * Support for Device Tree based power domain providers:
> + * Copyright (C) 2014 Tomasz Figa 
> + *
>   * This file is released under the GPLv2.
>   */
>
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> list_add(>gpd_list_node, _list);
> mutex_unlock(_list_lock);
>  }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF

Do we need a new config for this? Can't we just use CONFIG_OF?

> +/*
> + * DEVICE TREE BASED POWER DOMAIN PROVIDERS
> + *
> + * The code below implements generic device tree based power domain providers
> + * that bind device tree nodes with generic power domains registered in the
> + * system.
> + *
> + * Any driver that registers generic power domains and need to support 
> binding
> + * of devices to these domains is supposed to register a power domain 
> provider,
> + * which maps a power domain specifier retrieved from device tree to a power
> + * domain.
> + *
> + * Two simple mapping functions have been provided for convenience:
> + *  - of_genpd_xlate_simple() for 1:1 device tree node to domain mapping,
> + *  - of_genpd_xlate_onecell() for mapping of multiple domains per node
> + *by index.
> + */
> +
> +/**
> + * struct of_genpd_provider - Power domain 

[RFC 3/6] sched: s390: create a dedicated topology table

2014-03-04 Thread Vincent Guittot
BOOK level is only relevant for s390 so we create a dedicated topology table
with BOOK level and remove it from default table.

Signed-off-by: Vincent Guittot 
---
 arch/s390/include/asm/topology.h |   11 +--
 arch/s390/kernel/topology.c  |   25 +
 kernel/sched/core.c  |3 ---
 3 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/arch/s390/include/asm/topology.h b/arch/s390/include/asm/topology.h
index 07763bd..56af530 100644
--- a/arch/s390/include/asm/topology.h
+++ b/arch/s390/include/asm/topology.h
@@ -26,21 +26,12 @@ extern struct cpu_topology_s390 cpu_topology[NR_CPUS];
 
 #define mc_capable() 1
 
-static inline const struct cpumask *cpu_coregroup_mask(int cpu)
-{
-   return _topology[cpu].core_mask;
-}
-
-static inline const struct cpumask *cpu_book_mask(int cpu)
-{
-   return _topology[cpu].book_mask;
-}
-
 int topology_cpu_init(struct cpu *);
 int topology_set_cpu_management(int fc);
 void topology_schedule_update(void);
 void store_topology(struct sysinfo_15_1_x *info);
 void topology_expect_change(void);
+const struct cpumask *cpu_coregroup_mask(int cpu);
 
 #else /* CONFIG_SCHED_BOOK */
 
diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 4b2e3e3..8a7ac47 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -443,6 +443,28 @@ int topology_cpu_init(struct cpu *cpu)
return sysfs_create_group(>dev.kobj, _cpu_attr_group);
 }
 
+const struct cpumask *cpu_coregroup_mask(int cpu)
+{
+   return _topology[cpu].core_mask;
+}
+
+static const struct cpumask *cpu_book_mask(int cpu)
+{
+   return _topology[cpu].book_mask;
+}
+
+static struct sched_domain_topology_level s390_topology[] = {
+   { cpu_coregroup_mask, SD_SHARE_PKG_RESOURCES, SD_INIT_NAME(MC) },
+   { cpu_book_mask, SD_INIT_NAME(BOOK) },
+   { cpu_cpu_mask, SD_INIT_NAME(DIE) },
+   { NULL, },
+};
+
+static void __init set_sched_topology(void)
+{
+   sched_domain_topology = s390_topology;
+}
+
 static int __init topology_init(void)
 {
if (!MACHINE_HAS_TOPOLOGY) {
@@ -452,6 +474,9 @@ static int __init topology_init(void)
set_topology_timer();
 out:
update_cpu_masks();
+
+   set_sched_topology();
+
return device_create_file(cpu_subsys.dev_root, _attr_dispatching);
 }
 device_initcall(topology_init);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 6f6a8f0..3479467 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6043,9 +6043,6 @@ static struct sched_domain_topology_level 
default_topology[] = {
 #ifdef CONFIG_SCHED_MC
{ cpu_coregroup_mask, SD_SHARE_PKG_RESOURCES, SD_INIT_NAME(MC) },
 #endif
-#ifdef CONFIG_SCHED_BOOK
-   { cpu_book_mask, SD_INIT_NAME(BOOK) },
-#endif
{ cpu_cpu_mask, SD_INIT_NAME(DIE) },
{ NULL, },
 };
-- 
1.7.9.5

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


[RFC 0/6] rework sched_domain topology description

2014-03-04 Thread Vincent Guittot
This patchset was previously part of the larger tasks packing patchset [1].
I have splitted the latter in 3 different patchsets (at least) to make the
thing easier.
-configuration of sched_domain topology (this patchset)
-update and consolidation of cpu_power
-tasks packing algorithm

Based on Peter Z's proposal [2][3], this patchset modifies the way to configure
the sched_domain level in order to let architectures to add specific level like
the current BOOK level or the proposed power gating level for ARM architecture.

[1] https://lkml.org/lkml/2013/10/18/121
[2] https://lkml.org/lkml/2013/11/5/239
[3] https://lkml.org/lkml/2013/11/5/449

Vincent Guittot (6):
  sched: remove unused SCHED_INIT_NODE
  sched: rework of sched_domain topology definition
  sched: s390: create a dedicated topology table
  sched: powerpc: create a dedicated topology table
  sched: add a new SD_SHARE_POWERDOMAIN for sched_domain
  sched: ARM: create a dedicated scheduler topology table

 arch/arm/kernel/topology.c|   26 
 arch/ia64/include/asm/topology.h  |   24 
 arch/metag/include/asm/topology.h |   27 -
 arch/powerpc/kernel/smp.c |   35 --
 arch/s390/include/asm/topology.h  |   13 +-
 arch/s390/kernel/topology.c   |   25 
 arch/tile/include/asm/topology.h  |   33 --
 include/linux/sched.h |   30 +
 include/linux/topology.h  |  128 ++--
 kernel/sched/core.c   |  235 ++---
 10 files changed, 237 insertions(+), 339 deletions(-)

-- 
1.7.9.5

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


[Update v2 PATCH 2/2] aio, mem-hotplug: Add memory barrier to aio ring page migration.

2014-03-04 Thread Yasuaki Ishimatsu
When doing aio ring page migration, we migrated the page, and update
ctx->ring_pages[]. Like the following:

aio_migratepage()
 |-> migrate_page_copy(new, old)
 |   .. /* Need barrier here */
 |-> ctx->ring_pages[idx] = new

Actually, we need a memory barrier between these two operations.
Otherwise, if ctx->ring_pages[] is updated before memory copy due to
the compiler optimization, other processes may have an opportunity
to access to the not fully initialized new ring page.

So add a wmb and rmb to synchronize them.

Signed-off-by: Tang Chen 
Signed-off-by: Yasuaki Ishimatsu 
---
v2: change smp_rmb() to smp_read_barrier_depends(). Thanks Miao.
---
 fs/aio.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/fs/aio.c b/fs/aio.c
index 50c089c..98c7f2d 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -327,6 +327,14 @@ static int aio_migratepage(struct address_space *mapping, 
struct page *new,
pgoff_t idx;
spin_lock_irqsave(>completion_lock, flags);
migrate_page_copy(new, old);
+
+   /*
+* Ensure memory copy is finished before updating
+* ctx->ring_pages[]. Otherwise other processes may access to
+* new ring pages which are not fully initialized.
+*/
+   smp_wmb();
+
idx = old->index;
if (idx < (pgoff_t)ctx->nr_pages) {
/* And only do the move if things haven't changed */
@@ -1074,6 +1082,12 @@ static long aio_read_events_ring(struct kioctx *ctx,
page = ctx->ring_pages[pos / AIO_EVENTS_PER_PAGE];
pos %= AIO_EVENTS_PER_PAGE;

+   /*
+* Ensure that the page's data was copied from old one by
+* aio_migratepage().
+*/
+   smp_read_barrier_depends();
+
ev = kmap(page);
copy_ret = copy_to_user(event + ret, ev + pos,
sizeof(*ev) * avail);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: build failure after merge of the final tree (gpio tree related)

2014-03-04 Thread Linus Walleij
On Wed, Mar 5, 2014 at 2:35 PM, Stephen Rothwell  wrote:

> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/gpio/gpio-zevio.c: In function 'zevio_gpio_port_get':
> drivers/gpio/gpio-zevio.c:70:2: error: implicit declaration of function 
> 'IOMEM' [-Werror=implicit-function-declaration]
>   return readl(IOMEM(c->chip.regs + section_offset + port_offset));
>   ^
> drivers/gpio/gpio-zevio.c:70:2: warning: passing argument 1 of 'readl' makes 
> pointer from integer without a cast [enabled by default]
> In file included from include/linux/io.h:22:0,
>  from drivers/gpio/gpio-zevio.c:15:
> arch/powerpc/include/asm/io-defs.h:6:16: note: expected 'const volatile void 
> *' but argument is of type 'int'
>  DEF_PCI_AC_RET(readl, u32, (const PCI_IO_ADDR addr), (addr), mem, addr)
> ^

Fabian can you suggest a patch adding the proper depends added to
the Kconfig. Check what things bring in the IOMEM etc that is needed
to compile this.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails

2014-03-04 Thread Peter Ujfalusi
On 03/04/2014 04:37 PM, Santosh Shilimkar wrote:
> On Tuesday 04 March 2014 08:48 PM, Peter Ujfalusi wrote:
>> Use dev_err() which will going to print the driver's name as well and the
>> KERN_ERR level is sufficient in this case (we also print via dev_err when
>> there is an error with the mem resources)
>>
>> Signed-off-by: Peter Ujfalusi 
>> Reviewed-by: Santosh Shilimkar 
>> ---
>>  drivers/bus/omap_l3_noc.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
>> index 0eff48585ae3..972691a668a3 100644
>> --- a/drivers/bus/omap_l3_noc.c
>> +++ b/drivers/bus/omap_l3_noc.c
>> @@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
>>  ret = devm_request_irq(>dev, l3->debug_irq, l3_interrupt_handler,
>> IRQF_DISABLED, "l3-dbg-irq", l3);
>>  if (ret) {
>> -pr_crit("L3: request_irq failed to register for 0x%x\n",
>> -l3->debug_irq);
>> +dev_err(>dev, "request_irq failed for %d\n",
>> +l3->debug_irq);
>>  return ret;
>>  }
>>  
>> @@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
>>  ret = devm_request_irq(>dev, l3->app_irq, l3_interrupt_handler,
>> IRQF_DISABLED, "l3-app-irq", l3);
>>  if (ret)
>> -pr_crit("L3: request_irq failed to register for 0x%x\n",
>> -l3->app_irq);
>> +dev_err(>dev, "request_irq failed for %d\n", l3->app_irq);
>>  
>>  return ret;
>>  }
>>
> So this one change in the log level. If I look at now, may be dev_err
> is fine but the change is not same.

Not sure what you mean by 'the change is not same'?
I just picked the old series and rebased it on linux-next, the patch is the
same as it was back in May 2013:
https://lkml.org/lkml/2013/5/2/205

And yes, I have shortened the texts in the print, but the meaning of the
prints have not changed.

> Apart from above comment, rest of the series looks fine to me.
> Feel free to add my ack...

Thanks.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [alsa-devel] [PATCH 01/10] ASoC: core: Add snd_soc_dai_set_tdm_slot_xlate().

2014-03-04 Thread Mark Brown
On Wed, Mar 05, 2014 at 03:55:50AM +, li.xi...@freescale.com wrote:

> This adds the function of snd_soc_dai_set_tdm_slot_xlate, which is almost
> One new signature of snd_soc_dai_set_tdm_slot discarding the mask
> Parameters, which could be generated by itself.

Right, so that's not a bad thing but the _xlate() naming is confusing -
Lars' point was that if a function is called _xlate() it would usually
be an operation used as part of DT parsing, not something called from
non-DT code.  The new interface is probably a good thing but needs a
different name (perhaps _simple or something?) or we need to rename the
old one out of the way (it's slightly less flexible so we probably don't
want to remove it totally).

> And I want to provide one standard method for the drivers who are parsing
> The TDM information from the DT node. 

This is a good goal.


signature.asc
Description: Digital signature


Re: [PATCH 2/3] phy: omap-usb2: Provide workaround for USB2PHY false disconnect

2014-03-04 Thread Kishon Vijay Abraham I

Hi,

On Monday 03 March 2014 03:52 PM, George Cherian wrote:

From: Austin Beam 

Enable the dra7x errata workaround for false disconnect problem
with USB2PHY. False disconnects were detected with some of the devices.
Reduce the sensitivity of the disconnect logic within the USB2PHY subsystem
to enusre these false disconnects are not registered.

[george.cher...@ti.com]
While at that, pass proper flags for each SoC's. This is a common driver
used across OMAP4,OMAP5,DRA7xx and AM437x USB2PHY.

False disconnect workaround is currently applicable for only DRA7x.

Update the Documentation also to add new comaptible.

Signed-off-by: Austin Beam 
Signed-off-by: George Cherian 
Signed-off-by: Kishon Vijay Abraham I 
---
  Documentation/devicetree/bindings/usb/usb-phy.txt |  3 +-
  drivers/phy/phy-omap-usb2.c   | 48 +++
  include/linux/usb/omap_usb.h  |  3 ++
  3 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt 
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index b3fa409..03de61a5 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -4,7 +4,8 @@ OMAP USB2 PHY

  Required properties:
   - compatible: Should be either of
-   * "ti,omap-usb2" for OMAP4, OMAP5, DRA7
+   * "ti,omap-usb2" for OMAP4 and OMAP5
+   * "ti,dra7x-usb2" for DRA7
* "ti,am437x-usb2" for AM437x
   - reg : Address and length of the register set for the device.
   - #phy-cells: determine the number of cells that should be given in the
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index d54f24b..80ba7f0 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -31,6 +31,9 @@
  #include 
  #include 

+#define USB2PHY_DISCON_BYP_LATCH (1 << 31)
+#define USB2PHY_ANA_CONFIG1 0x4c
+
  /**
   * omap_usb2_set_comparator - links the comparator present in the sytem with
   *this phy
@@ -138,7 +141,30 @@ static int omap_usb_power_on(struct phy *x)
return 0;
  }

+static int omap_usb_init(struct phy *x)
+{
+   struct omap_usb *phy = phy_get_drvdata(x);
+   u32 val;
+
+   if (phy->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT) {
+   /*
+*
+* Reduce the sensitivity of internal PHY by enabling the
+* DISCON_BYP_LATCH of the USB2PHY_ANA_CONFIG1 register. This
+* resolves issues with certain devices which can otherwise
+* be prone to false disconnects.
+*
+*/
+   val = omap_usb_readl(phy->phy_base, USB2PHY_ANA_CONFIG1);
+   val |= USB2PHY_DISCON_BYP_LATCH;
+   omap_usb_writel(phy->phy_base, USB2PHY_ANA_CONFIG1, val);
+   }
+
+   return 0;
+}
+
  static struct phy_ops ops = {
+   .init   = omap_usb_init,
.power_on   = omap_usb_power_on,
.power_off  = omap_usb_power_off,
.owner  = THIS_MODULE,
@@ -150,6 +176,11 @@ static const struct usb_phy_data omap_usb2_data = {
.flags = OMAP_USB2_HAS_START_SRP | OMAP_USB2_HAS_SET_VBUS,
  };

+static const struct usb_phy_data dra7x_usb2_data = {
+   .label = "dra7x_usb2",
+   .flags = OMAP_USB2_CALIBRATE_FALSE_DISCONNECT,
+};
+
  static const struct usb_phy_data am437x_usb2_data = {
.label = "am437x_usb2",
.flags =  0,
@@ -161,6 +192,10 @@ static const struct of_device_id omap_usb2_id_table[] = {
.data = _usb2_data,
},
{
+   .compatible = "ti,dra7x-usb2",
+   .data = _usb2_data,
+   },
+   {
.compatible = "ti,am437x-usb2",
.data = _usb2_data,
},
@@ -173,6 +208,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
  {
struct omap_usb *phy;
struct phy *generic_phy;
+   struct resource *res;
struct phy_provider *phy_provider;
struct usb_otg *otg;
struct device_node *node = pdev->dev.of_node;
@@ -208,6 +244,18 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy->phy.otg = otg;
phy->phy.type= USB_PHY_TYPE_USB2;

+   if (phy_data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT) {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   dev_err(>dev, "memory resource not available\n");
+   return -ENODEV;
+   }


You can remove the error check here and..

+   phy->phy_base = devm_request_and_ioremap(>dev, res);


use devm_ioremap_resource instead.

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

Re: [PATCH V3] support Thinkpad X1 Carbon 2nd generation's adaptive keyboard

2014-03-04 Thread SeongJae Park
On Wed, Mar 5, 2014 at 3:35 PM, Shuduo Sang  wrote:
>
>
> On 03/05/2014 01:54 PM, SeongJae Park wrote:
>> Hello,
>> This is just a trivial comment.
>>
>>
>> On Tue, Mar 4, 2014 at 8:13 PM, Shuduo Sang  
>> wrote:
>>>
>>>
>>> Submit patch V3 to support Adaptive Keyboard on Thinkpad X1 Carbon 2nd
>>> generation according to Tobias's comments.
>>>
>>> Thanks,
>>> Shuduo
>>>
>>> From 2b8175e69deee661d97d371b2422a9c192fefd52 Mon Sep 17 00:00:00 2001
>>> From: Shuduo Sang 
>>> Date: Mon, 3 Mar 2014 14:29:32 +0800
>>> Subject: [PATCH] support thinkpad X1 Carbon's adaptive keyboard
>>>
>>> Thinkpad X1 Carbon's adaptive keyboard has five modes including Home
>>> mode, Web browser mode, Web conference mode, Function mode and Lay-flat
>>> mode. We support Home mode and Function mode currently.
>>>
>>> Signed-off-by: Bruce Ma 
>>> Signed-off-by: Shuduo Sang 
>>> ---
>>>  drivers/platform/x86/thinkpad_acpi.c | 102
>>> +++
>>>  1 file changed, 102 insertions(+)
>>>
>>> diff --git a/drivers/platform/x86/thinkpad_acpi.c
>>> b/drivers/platform/x86/thinkpad_acpi.c
>>> index defb6af..6664dcd 100644
>>> --- a/drivers/platform/x86/thinkpad_acpi.c
>>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>>> @@ -3437,6 +3437,106 @@ err_exit:
>>> return (res < 0)? res : 1;
>>>  }
>>>
>>> +/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
>>> + * mode, Web conference mode, Function mode and Lay-flat mode.
>>> + * We support Home mode and Function mode currently.
>>> + *
>>> + * Will consider support rest of modes in future.
>>> + *
>>> + */
>>> +enum ADAPTIVE_KEY_MODE {
>>> +   HOME_MODE,
>>> +   WEB_BROWSER_MODE,
>>> +   WEB_CONFERENCE_MODE,
>>> +   FUNCTION_MODE,
>>> +   LAYFLAT_MODE
>>> +};
>>> +
>>> +int adaptive_keyboard_modes[] = {
>>> +   HOME_MODE,
>>> +/* WEB_BROWSER_MODE = 2,
>>> +   WEB_CONFERENCE_MODE = 3, */
>>> +   FUNCTION_MODE
>>> +};
>>> +
>>> +#define DFR_CHANGE_ROW 0x101
>>> +#define DFR_SHOW_QUICKVIEW_ROW 0x102
>>> +
>>> +/* press Fn key a while second, it will switch to Function Mode. Then
>>> + * release Fn key, previous mode be restored.
>>> + */
>>> +static bool adaptive_keyboard_mode_is_saved;
>>> +static int adaptive_keyboard_prev_mode;
>>> +
>>> +static int adaptive_keyboard_get_next_mode(int mode)
>>> +{
>>> +   int i;
>>> +   size_t max_mode = ARRAY_SIZE(adaptive_keyboard_modes) - 1;
>>> +
>>> +   for (i = 0; i <= max_mode; i++) {
>>> +   if (adaptive_keyboard_modes[i] == mode)
>>> +   break;
>>> +   }
>>> +
>>> +   if (i >= max_mode)
>>> +   i = 0;
>>> +   else
>>> +   i++;
>>> +
>>> +   return adaptive_keyboard_modes[i];
>>> +}
>>> +
>>> +static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
>>> +{
>>> +   u32 current_mode = 0;
>>> +   int new_mode = 0;
>>> +
>>> +   switch (scancode) {
>>> +   case DFR_CHANGE_ROW:
>>> +   if (adaptive_keyboard_mode_is_saved) {
>>> +   new_mode = adaptive_keyboard_prev_mode;
>>> +   adaptive_keyboard_mode_is_saved = false;
>>> +   } else {
>>> +   if (!acpi_evalf(
>>> +   hkey_handle, _mode,
>>> +   "GTRW", "dd", 0)) {
>>> +   pr_err("Cannot read adaptive keyboard 
>>> mode\n");
>>> +   return false;
>>> +   } else {
>>> +   new_mode = adaptive_keyboard_get_next_mode(
>>> +   current_mode);
>>> +   }
>>> +   }
>>> +
>>> +   if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode)) 
>>> {
>>> +   pr_err("Cannot set adaptive keyboard mode\n");
>>> +   return false;
>>> +   }
>>> +
>>> +   return true;
>>
>> Isn't the blank line above return statement unnecessary?
>>
>
> Doesn't it look clearly? :)

Well, I thought it might be unintended blank line because
the return statement in below case doesn't have blank line.
Anyway, I agree if it was your intention.

>
>>> +
>>> +   case DFR_SHOW_QUICKVIEW_ROW:
>>> +   if (!acpi_evalf(hkey_handle,
>>> +   _keyboard_prev_mode,
>>> +   "GTRW", "dd", 0)) {
>>> +   pr_err("Cannot read adaptive keyboard mode\n");
>>> +   return false;
>>> +   } else {
>>> +   adaptive_keyboard_mode_is_saved = true;
>>> +
>>> +   if (!acpi_evalf(hkey_handle,
>>> +   NULL, "STRW", "vd", FUNCTION_MODE)) 
>>> {
>>> +   pr_err("Cannot set adaptive keyboard 
>>> mode\n");
>>> +

RE: [PATCH v5] can: xilinx CAN controller support.

2014-03-04 Thread Appana Durga Kedareswara Rao
Hi Oliver,

> -Original Message-
> From: Oliver Hartkopp [mailto:socket...@hartkopp.net]
> Sent: Wednesday, March 05, 2014 12:29 PM
> To: Appana Durga Kedareswara Rao
> Cc: Soren Brinkmann; w...@grandegger.com; m...@pengutronix.de; Michal
> Simek; grant.lik...@linaro.org; robh...@kernel.org; linux-
> c...@vger.kernel.org; net...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Appana Durga Kedareswara Rao
> Subject: Re: [PATCH v5] can: xilinx CAN controller support.
>
>
>
> On 05.03.2014 00:51, Sören Brinkmann wrote:
> > Hi Kedar,
> >
> > On Tue, 2014-03-04 at 06:50PM +0530, Kedareswara rao Appana wrote:
> >> This patch adds xilinx CAN controller support.
> >> This driver supports both ZYNQ CANPS and Soft IP AXI CAN controller.
> >>
> > [...]
> >> diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt
> >> b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
> >> new file mode 100644
> >> index 000..0e57103
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
> >> @@ -0,0 +1,45 @@
> >> +Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
> >> +-
> >> +
> >> +Required properties:
> >> +- compatible  : Should be "xlnx,zynq-can-1.00.a" for Zynq
> CAN
> >> +controllers and "xlnx,axi-can-1.00.a" for Axi CAN
> >> +controllers.
> >> +- reg : Physical base address and size of the Axi
> CAN/Zynq
> >> +CANPS registers map.
> >> +- interrupts  : Property with a value describing the interrupt
> >> +number.
> >> +- interrupt-parent: Must be core interrupt controller
> >> +- clock-names : List of input clock names - "ref_clk",
> "aper_clk"
> >
> > Let's reconsider these names. These are rather Zynq specific names.
> > Does the IP documentation use these as well? The names should match
> > the naming used for the IP, rather than the SOC. Is this the correct data
> sheet:
> >
> http://www.xilinx.com/support/documentation/ip_documentation/axi_can
> /v
> > 1_03_a/ds791_axi_can.pdf ? According to that the names should rather
> > be 's_axi_aclk' and 'can_clk', IMHO.
> >
> > Sören
> >
>
> And when renaming stuff anyway:
>
> +
> +#define DRIVER_NAME  "XILINX_CAN"
> +
>
> should be changed to

Ok Will do

Regards,
Kedar.

>
> +
> +#define DRIVER_NAME  "xilinx_can"
> +
>
> Regards,
> Oliver
>



This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.





Re: [PATCH v5] can: xilinx CAN controller support.

2014-03-04 Thread Oliver Hartkopp


On 05.03.2014 00:51, Sören Brinkmann wrote:
> Hi Kedar,
> 
> On Tue, 2014-03-04 at 06:50PM +0530, Kedareswara rao Appana wrote:
>> This patch adds xilinx CAN controller support.
>> This driver supports both ZYNQ CANPS and Soft IP
>> AXI CAN controller.
>>
> [...]
>> diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt 
>> b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
>> new file mode 100644
>> index 000..0e57103
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
>> @@ -0,0 +1,45 @@
>> +Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
>> +-
>> +
>> +Required properties:
>> +- compatible: Should be "xlnx,zynq-can-1.00.a" for Zynq CAN
>> +  controllers and "xlnx,axi-can-1.00.a" for Axi CAN
>> +  controllers.
>> +- reg   : Physical base address and size of the Axi 
>> CAN/Zynq
>> +  CANPS registers map.
>> +- interrupts: Property with a value describing the interrupt
>> +  number.
>> +- interrupt-parent  : Must be core interrupt controller
>> +- clock-names   : List of input clock names - "ref_clk", 
>> "aper_clk"
> 
> Let's reconsider these names. These are rather Zynq specific names. Does
> the IP documentation use these as well? The names should match the
> naming used for the IP, rather than the SOC. Is this the correct data sheet:
> http://www.xilinx.com/support/documentation/ip_documentation/axi_can/v1_03_a/ds791_axi_can.pdf
> ? According to that the names should rather be 's_axi_aclk' and
> 'can_clk', IMHO.
> 
>   Sören
> 

And when renaming stuff anyway:

+
+#define DRIVER_NAME"XILINX_CAN"
+

should be changed to

+
+#define DRIVER_NAME"xilinx_can"
+

Regards,
Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5] can: xilinx CAN controller support.

2014-03-04 Thread Appana Durga Kedareswara Rao
Hi Soren,

> -Original Message-
> From: Sören Brinkmann [mailto:soren.brinkm...@xilinx.com]
> Sent: Wednesday, March 05, 2014 5:21 AM
> To: Appana Durga Kedareswara Rao
> Cc: w...@grandegger.com; m...@pengutronix.de; Michal Simek;
> grant.lik...@linaro.org; robh...@kernel.org; linux-...@vger.kernel.org;
> net...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; Appana Durga
> Kedareswara Rao
> Subject: Re: [PATCH v5] can: xilinx CAN controller support.
>
> Hi Kedar,
>
> On Tue, 2014-03-04 at 06:50PM +0530, Kedareswara rao Appana wrote:
> > This patch adds xilinx CAN controller support.
> > This driver supports both ZYNQ CANPS and Soft IP AXI CAN controller.
> >
> [...]
> > diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt
> > b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
> > new file mode 100644
> > index 000..0e57103
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
> > @@ -0,0 +1,45 @@
> > +Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
> > +-
> > +
> > +Required properties:
> > +- compatible   : Should be "xlnx,zynq-can-1.00.a" for Zynq
> CAN
> > + controllers and "xlnx,axi-can-1.00.a" for Axi CAN
> > + controllers.
> > +- reg  : Physical base address and size of the Axi 
> > CAN/Zynq
> > + CANPS registers map.
> > +- interrupts   : Property with a value describing the interrupt
> > + number.
> > +- interrupt-parent : Must be core interrupt controller
> > +- clock-names  : List of input clock names - "ref_clk",
> "aper_clk"
>
> Let's reconsider these names. These are rather Zynq specific names. Does
> the IP documentation use these as well? The names should match the
> naming used for the IP, rather than the SOC. Is this the correct data sheet:
> http://www.xilinx.com/support/documentation/ip_documentation/axi_can
> /v1_03_a/ds791_axi_can.pdf
> ? According to that the names should rather be 's_axi_aclk' and 'can_clk',
> IMHO.

Axi CAN driver uses only one clock i.e ref_clk the name in the documentation 
for this clock is can_clk.
Ok will change the clock name to can_clk.


Regards,
Kedar.

>
>   Sören



This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.





Re: linux-next: build failure after merge of the omap_dss2 tree

2014-03-04 Thread Tomi Valkeinen
On 05/03/14 05:32, Stephen Rothwell wrote:
> Hi Tomi,
> 
> After merging the omap_dss2 tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/video/fbdev/aty/mach64_cursor.c:8:24: fatal error: ../fb_draw.h: No 
> such file or directory
>  #include "../fb_draw.h"
> ^
> 
> Caused by commit 236c52f2ad52 ("fbdev: move fbdev core files to separate 
> directory").
> 
> I have used the omap_dss2 tree from next-20140304 for today.

Thanks. It was a bad merge between the main fbdev changes and the fbdev
restructuring. I've fixed it and pushed the branch.

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [Update PATCH 2/2] aio, mem-hotplug: Add memory barrier to aio ring page migration.

2014-03-04 Thread Yasuaki Ishimatsu
(2014/03/04 14:35), Miao Xie wrote:
> Onthu, 27 Feb 2014 21:44:23 +0900, Yasuaki Ishimatsu wrote:
>> When doing aio ring page migration, we migrated the page, and update
>> ctx->ring_pages[]. Like the following:
>>
>> aio_migratepage()
>>   |-> migrate_page_copy(new, old)
>>   |   .. /* Need barrier here */
>>   |-> ctx->ring_pages[idx] = new
>>
>> Actually, we need a memory barrier between these two operations.
>> Otherwise, if ctx->ring_pages[] is updated before memory copy due to
>> the compiler optimization, other processes may have an opportunity
>> to access to the not fully initialized new ring page.
>>
>> So add a wmb and rmb to synchronize them.
>>
>> Signed-off-by: Tang Chen 
>> Signed-off-by: Yasuaki Ishimatsu 
>>
>> ---
>>   fs/aio.c | 14 ++
>>   1 file changed, 14 insertions(+)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 50c089c..8d9b82b 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -327,6 +327,14 @@ static int aio_migratepage(struct address_space 
>> *mapping, struct page *new,
>>  pgoff_t idx;
>>  spin_lock_irqsave(>completion_lock, flags);
>>  migrate_page_copy(new, old);
>> +
>> +/*
>> + * Ensure memory copy is finished before updating
>> + * ctx->ring_pages[]. Otherwise other processes may access to
>> + * new ring pages which are not fully initialized.
>> + */
>> +smp_wmb();
>> +
>>  idx = old->index;
>>  if (idx < (pgoff_t)ctx->nr_pages) {
>>  /* And only do the move if things haven't changed */
>> @@ -1074,6 +1082,12 @@ static long aio_read_events_ring(struct kioctx *ctx,
>>  page = ctx->ring_pages[pos / AIO_EVENTS_PER_PAGE];
>>  pos %= AIO_EVENTS_PER_PAGE;
>>
>> +/*
>> + * Ensure that the page's data was copied from old one by
>> + * aio_migratepage().
>> + */
>> +smp_rmb();
>> +
> 
> smp_read_barrier_depends() is better.
> 
> "One could place an A smp_rmb() primitive between the pointer fetch and
>   dereference. However, this imposes unneeded overhead on systems (such as
>   i386, IA64, PPC, and SPARC) that respect data dependencies on the read side.
>   A smp_read_barrier_depends() primitive has been added to the Linux 2.6 
> kernel
>   to eliminate overhead on these systems."
>   -- From Chapter 7.1 of  Software Hackers>
>  Written by Paul E. McKenney
> 
> Thanks
> Miao

Thank you for your comment.
I'll update soon.

Thanks,
Yasauaki Ishimatsu


> 
>>  ev = kmap(page);
>>  copy_ret = copy_to_user(event + ret, ev + pos,
>>  sizeof(*ev) * avail);
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] EDAC: remove deprecated IRQF_DISABLED

2014-03-04 Thread Borislav Petkov
On Wed, Mar 05, 2014 at 06:04:37AM +0100, Michael Opdenacker wrote:
> My patch still applies to 3.14-rc5, which means that mpc85xx_edac is
> still there.
> 
> I'd like to get rid of this patch for good ;)

Something like that, right:

https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/commit/?id=e245e3b25f9ef33b166f0f01d19d6418f52ae726

?

Its on its way upstream.

-- 
Regards/Gruss,
Boris.

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


linux-next: Tree for Mar 5

2014-03-04 Thread Stephen Rothwell
Hi all,

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140304:

The powerpc tree still had its build failure.

The mfd-lj tree lost its build failure.

The wireless-next tree still had its build failure so I used the version
from next-20140224.

The gpio tree gained a build failure for which I reverted a commit.

The omap_dss2 tree lost its build failure but gained another so I used
the version from next-20140304 (with a fix for a staging driver).

The char-misc tree still had its 2 build failures for which I reverted 2
commits.

Non-merge commits (relative to Linus' tree): 5485
 6189 files changed, 512427 insertions(+), 434892 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" as mentioned in the FAQ on the wiki
(see below).

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 210 trees (counting Linus' and 28 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.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (0c0bd34a1429 Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (b36345759308 ARM: 7980/1: kernel: improve error 
message when LPAE config doesn't match CPU)
Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and 
sched_getattr)
Merging metag-fixes/fixes (f229006ec6be irq-metag*: stop set_affinity vectoring 
to offline cpus)
Merging powerpc-merge/merge (e0cf95761497 powerpc/powernv: Fix indirect XSCOM 
unmangling)
Merging sparc/master (10527106abec Merge tag 'dt-for-linus' of 
git://git.secretlab.ca/git/linux)
Merging net/master (8b4703e9bd11 macvlan: Add support for 'always_on' offload 
features)
Merging ipsec/master (3a9016f97fdc xfrm: Fix unlink race when policies are 
deleted.)
Merging sound-current/for-linus (a6b92b6650d0 ALSA: hda - Added inverted 
digital-mic handling for Acer TravelMate 8371)
Merging pci-current/for-linus (fc40363b2140 ahci: Fix broken fallback to single 
MSI mode)
Merging wireless/master (9b8ba9f51882 Merge branch 'for-john' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (0414855fdc4a Linux 3.14-rc5)
Merging tty.current/tty-linus (0414855fdc4a Linux 3.14-rc5)
Merging usb.current/usb-linus (0414855fdc4a Linux 3.14-rc5)
Merging staging.current/staging-linus (0414855fdc4a Linux 3.14-rc5)
Merging char-misc.current/char-misc-linus (0414855fdc4a Linux 3.14-rc5)
Merging input-current/for-linus (70b0052425ff Input: da9052_onkey - use correct 
register bit for key status)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede 
ctr concurrency issue)
Merging ide/master (a259d5320537 m68k/atari - ide: do not register interrupt if 
host->get_lock is set)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for 
of_match_node())
Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter 
kernel symbols for arm)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts

Re: [PATCH v10 1/3] mmc: sdhci-msm: Qualcomm SDHCI binding documentation

2014-03-04 Thread Rob Herring
On Tue, Mar 4, 2014 at 1:27 PM, Georgi Djakov  wrote:
> This patch adds the device-tree binding documentation for
> Qualcomm SDHCI driver. It contains the differences between
> the core properties in mmc.txt and the properties used by
> the sdhci-msm driver.
>
> Signed-off-by: Georgi Djakov 
> ---
>  .../devicetree/bindings/mmc/sdhci-msm.txt  |   63 
> 
>  1 file changed, 63 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt 
> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> new file mode 100644
> index 000..c635c53
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> @@ -0,0 +1,63 @@
> +* Qualcomm SDHCI controller (sdhci-msm)
> +
> +This file documents differences between the core properties in mmc.txt
> +and the properties used by the sdhci-msm driver.
> +
> +Required properties:
> +- compatible: Should contain "qcom,sdhci-msm-v4".
> +- reg: Base address and length of the register set listed in reg-names.
> +- reg-names: Should contain the following:
> +   "hc_mem"   - Host controller register map
> +   "core_mem" - SD Core register map

reg-names should not be required and the order specified by the binding.

> +- interrupts: Should contain an interrupt-specifiers for the interrupts 
> listed in interrupt-names.
> +- interrupt-names: Should contain the following:
> +   "hc_irq" - Host controller interrupt
> +   "pwr_irq"- PMIC interrupt

Same for interrupt-names.

> +- vdd-supply: Phandle to the regulator for the vdd (core voltage) supply.
> +- vdd-io-supply: Phandle to the regulator for the vdd-io (i/o voltage) 
> supply.
> +- pinctrl-names: Should contain only one value - "default".
> +- pinctrl-0: Should specify pin control groups used for this controller.
> +- clocks: A list of phandle + clock-specifier pairs for the clocks listed in 
> clock-names.
> +- clock-names: Should contain the following:
> +   "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) 
> (required)
> +   "core"  - SDC MMC clock (MCLK) (required)
> +   "bus"   - SDCC bus voter clock (optional)
> +
> +Example:
> +
> +   sdhc_1: sdhci@f9824900 {
> +   compatible = "qcom,sdhci-msm-v4";
> +   reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;

Are there cases where these are really in a different 4KB range? If
not, this should just be 1 range.

> +   reg-names = "hc_mem", "core_mem";
> +   interrupts = <0 123 0>, <0 138 0>;
> +   interrupt-names = "hc_irq", "pwr_irq";
> +   bus-width = <8>;
> +   non-removable;
> +
> +   vdd-supply = <_l20>;
> +   vdd-io-supply = <_s3>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_clk _cmd _data>;
> +
> +   clocks = < GCC_SDCC1_APPS_CLK>, < GCC_SDCC1_AHB_CLK>;
> +   clock-names = "core", "iface";
> +   };
> +
> +   sdhc_2: sdhci@f98a4900 {
> +   compatible = "qcom,sdhci-msm-v4";
> +   reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
> +   reg-names = "hc_mem", "core_mem";
> +   interrupts = <0 125 0>, <0 221 0>;
> +   interrupt-names = "hc_irq", "pwr_irq";
> +   bus-width = <4>;
> +
> +   vdd-supply = <_l21>;
> +   vdd-io-supply = <_l13>;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_clk _cmd _data>;
> +
> +   clocks = < GCC_SDCC2_APPS_CLK>, < GCC_SDCC2_AHB_CLK>;
> +   clock-names = "core", "iface";
> +   };
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

2014-03-04 Thread Jean-Christophe PLAGNIOL-VILLARD

On Mar 5, 2014, at 9:53 AM, Wenyou Yang  wrote:

> In order to support the pinctrl sleep state.

As I said before NACK

this is not the job of the pinctrl to describe gpio output or input state

Best Regards,
J.
> 
> Signed-off-by: Wenyou Yang 
> ---
> Hi Linus,
> 
> The patch is based on branch: for-next
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> 
> Best Regards,
> Wenyou Yang
> 
> drivers/pinctrl/pinctrl-at91.c |   31 +++
> include/dt-bindings/pinctrl/at91.h |2 ++
> 2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index 5d24aae..fc51e59 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -62,6 +62,8 @@ static int gpio_banks;
> #define DEGLITCH  (1 << 2)
> #define PULL_DOWN (1 << 3)
> #define DIS_SCHMIT(1 << 4)
> +#define GPIO_OUTPUT_HIGH (1 << 5)
> +#define GPIO_OUTPUT_LOW  (1 << 6)
> #define DEBOUNCE  (1 << 16)
> #define DEBOUNCE_VAL_SHIFT17
> #define DEBOUNCE_VAL  (0x3fff << DEBOUNCE_VAL_SHIFT)
> @@ -152,12 +154,15 @@ struct at91_pinctrl_mux_ops {
>   void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
>   bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
>   void (*disable_schmitt_trig)(void __iomem *pio, unsigned mask);
> + bool (*get_gpio_output)(void __iomem *pio, unsigned mask);
> + void (*set_gpio_output)(void __iomem *pio, unsigned mask, bool is_high);
>   /* irq */
>   int (*irq_type)(struct irq_data *d, unsigned type);
> };
> 
> static int gpio_irq_type(struct irq_data *d, unsigned type);
> static int alt_gpio_irq_type(struct irq_data *d, unsigned type);
> +static void at91_mux_gpio_enable(void __iomem *pio, unsigned mask, bool 
> input);
> 
> struct at91_pinctrl {
>   struct device   *dev;
> @@ -472,6 +477,20 @@ static bool at91_mux_pio3_get_schmitt_trig(void __iomem 
> *pio, unsigned pin)
>   return (__raw_readl(pio + PIO_SCHMITT) >> pin) & 0x1;
> }
> 
> +static bool at91_mux_pio3_get_gpio_output(void __iomem *pio, unsigned pin)
> +{
> + return (__raw_readl(pio + PIO_ODSR) >> pin) & 0x1;
> +}
> +
> +static void at91_mux_pio3_set_gpio_output(void __iomem *pio,
> + unsigned mask,
> + bool is_high)
> +{
> + at91_mux_gpio_enable(pio, mask, 0);
> + writel_relaxed(mask, pio + (is_high ? PIO_SODR : PIO_CODR));
> +}
> +
> +
> static struct at91_pinctrl_mux_ops at91rm9200_ops = {
>   .get_periph = at91_mux_get_periph,
>   .mux_A_periph   = at91_mux_set_A_periph,
> @@ -495,6 +514,8 @@ static struct at91_pinctrl_mux_ops at91sam9x5_ops = {
>   .set_pulldown   = at91_mux_pio3_set_pulldown,
>   .get_schmitt_trig = at91_mux_pio3_get_schmitt_trig,
>   .disable_schmitt_trig = at91_mux_pio3_disable_schmitt_trig,
> + .get_gpio_output = at91_mux_pio3_get_gpio_output,
> + .set_gpio_output = at91_mux_pio3_set_gpio_output,
>   .irq_type   = alt_gpio_irq_type,
> };
> 
> @@ -741,6 +762,10 @@ static int at91_pinconf_get(struct pinctrl_dev *pctldev,
>   *config |= PULL_DOWN;
>   if (info->ops->get_schmitt_trig && info->ops->get_schmitt_trig(pio, 
> pin))
>   *config |= DIS_SCHMIT;
> + if (info->ops->get_gpio_output) {
> + *config |= info->ops->get_gpio_output(pio, pin) ?
> + GPIO_OUTPUT_HIGH : GPIO_OUTPUT_LOW;
> + }
> 
>   return 0;
> }
> @@ -778,6 +803,12 @@ static int at91_pinconf_set(struct pinctrl_dev *pctldev,
>   info->ops->set_pulldown(pio, mask, config & PULL_DOWN);
>   if (info->ops->disable_schmitt_trig && config & DIS_SCHMIT)
>   info->ops->disable_schmitt_trig(pio, mask);
> + if (info->ops->set_gpio_output) {
> + if (config & GPIO_OUTPUT_HIGH)
> + info->ops->set_gpio_output(pio, mask, 1);
> + if (config & GPIO_OUTPUT_LOW)
> + info->ops->set_gpio_output(pio, mask, 0);
> + };
> 
>   } /* for each config */
> 
> diff --git a/include/dt-bindings/pinctrl/at91.h 
> b/include/dt-bindings/pinctrl/at91.h
> index 0fee6ff..e799268 100644
> --- a/include/dt-bindings/pinctrl/at91.h
> +++ b/include/dt-bindings/pinctrl/at91.h
> @@ -15,6 +15,8 @@
> #define AT91_PINCTRL_DEGLITCH (1 << 2)
> #define AT91_PINCTRL_PULL_DOWN(1 << 3)
> #define AT91_PINCTRL_DIS_SCHMIT   (1 << 4)
> +#define AT91_PINCTRL_OUTPUT_HIGH (1 << 5)
> +#define AT91_PINCTRL_OUTPUT_LOW  (1 << 6)
> #define AT91_PINCTRL_DEBOUNCE (1 << 16)
> #define AT91_PINCTRL_DEBOUNCE_VAL(x)  (x << 17)
> 
> -- 
> 1.7.9.5
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail


[PATCH net-next v2 04/13] r8152: replace spin_lock_irqsave and spin_unlock_irqrestore

2014-03-04 Thread Hayes Wang
Use spin_lock and spin_unlock in interrupt context.

The ndo_start_xmit would not be called in interrupt context, so
replace the relative spin_lock_irqsave and spin_unlock_irqrestore
with spin_lock_bh and spin_unlock_bh.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 28 
 1 file changed, 12 insertions(+), 16 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b8eee36..8ecb41b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -963,7 +963,6 @@ static int rtl8152_set_mac_address(struct net_device 
*netdev, void *p)
 static void read_bulk_callback(struct urb *urb)
 {
struct net_device *netdev;
-   unsigned long flags;
int status = urb->status;
struct rx_agg *agg;
struct r8152 *tp;
@@ -997,9 +996,9 @@ static void read_bulk_callback(struct urb *urb)
if (urb->actual_length < ETH_ZLEN)
break;
 
-   spin_lock_irqsave(>rx_lock, flags);
+   spin_lock(>rx_lock);
list_add_tail(>list, >rx_done);
-   spin_unlock_irqrestore(>rx_lock, flags);
+   spin_unlock(>rx_lock);
tasklet_schedule(>tl);
return;
case -ESHUTDOWN:
@@ -1022,9 +1021,9 @@ static void read_bulk_callback(struct urb *urb)
if (result == -ENODEV) {
netif_device_detach(tp->netdev);
} else if (result) {
-   spin_lock_irqsave(>rx_lock, flags);
+   spin_lock(>rx_lock);
list_add_tail(>list, >rx_done);
-   spin_unlock_irqrestore(>rx_lock, flags);
+   spin_unlock(>rx_lock);
tasklet_schedule(>tl);
}
 }
@@ -1033,7 +1032,6 @@ static void write_bulk_callback(struct urb *urb)
 {
struct net_device_stats *stats;
struct net_device *netdev;
-   unsigned long flags;
struct tx_agg *agg;
struct r8152 *tp;
int status = urb->status;
@@ -1057,9 +1055,9 @@ static void write_bulk_callback(struct urb *urb)
stats->tx_bytes += agg->skb_len;
}
 
-   spin_lock_irqsave(>tx_lock, flags);
+   spin_lock(>tx_lock);
list_add_tail(>list, >tx_free);
-   spin_unlock_irqrestore(>tx_lock, flags);
+   spin_unlock(>tx_lock);
 
usb_autopm_put_interface_async(tp->intf);
 
@@ -1330,14 +1328,13 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, 
struct sk_buff *skb)
 static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
 {
struct sk_buff_head skb_head, *tx_queue = >tx_queue;
-   unsigned long flags;
int remain, ret;
u8 *tx_data;
 
__skb_queue_head_init(_head);
-   spin_lock_irqsave(_queue->lock, flags);
+   spin_lock_bh(_queue->lock);
skb_queue_splice_init(tx_queue, _head);
-   spin_unlock_irqrestore(_queue->lock, flags);
+   spin_unlock_bh(_queue->lock);
 
tx_data = agg->head;
agg->skb_num = agg->skb_len = 0;
@@ -1374,9 +1371,9 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct 
tx_agg *agg)
}
 
if (!skb_queue_empty(_head)) {
-   spin_lock_irqsave(_queue->lock, flags);
+   spin_lock_bh(_queue->lock);
skb_queue_splice(_head, tx_queue);
-   spin_unlock_irqrestore(_queue->lock, flags);
+   spin_unlock_bh(_queue->lock);
}
 
netif_tx_lock_bh(tp->netdev);
@@ -1551,16 +1548,15 @@ static void rtl_drop_queued_tx(struct r8152 *tp)
 {
struct net_device_stats *stats = >netdev->stats;
struct sk_buff_head skb_head, *tx_queue = >tx_queue;
-   unsigned long flags;
struct sk_buff *skb;
 
if (skb_queue_empty(tx_queue))
return;
 
__skb_queue_head_init(_head);
-   spin_lock_irqsave(_queue->lock, flags);
+   spin_lock_bh(_queue->lock);
skb_queue_splice_init(tx_queue, _head);
-   spin_unlock_irqrestore(_queue->lock, flags);
+   spin_unlock_bh(_queue->lock);
 
while ((skb = __skb_dequeue(_head))) {
dev_kfree_skb(skb);
-- 
1.8.4.2

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


[PATCH net-next v2 05/13] r8152: check tx agg list before spin lock

2014-03-04 Thread Hayes Wang
Check tx agg list before spin lock to avoid doing spin lock every
times.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8ecb41b..00b3192 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1266,6 +1266,9 @@ static struct tx_agg *r8152_get_tx_agg(struct r8152 *tp)
struct tx_agg *agg = NULL;
unsigned long flags;
 
+   if (list_empty(>tx_free))
+   return NULL;
+
spin_lock_irqsave(>tx_lock, flags);
if (!list_empty(>tx_free)) {
struct list_head *cursor;
-- 
1.8.4.2

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


[PATCH net-next v2 01/13] r8152: deal with the empty line and space

2014-03-04 Thread Hayes Wang
Add or remove some empty lines. Replace the spaces with the tabs.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0654bd3..c8bad62 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -593,6 +593,7 @@ int set_registers(struct r8152 *tp, u16 value, u16 index, 
u16 size, void *data)
   value, index, tmp, size, 500);
 
kfree(tmp);
+
return ret;
 }
 
@@ -1514,6 +1515,7 @@ static void tx_bottom(struct r8152 *tp)
netif_warn(tp, tx_err, netdev,
   "failed tx_urb %d\n", res);
stats->tx_dropped += agg->skb_num;
+
spin_lock_irqsave(>tx_lock, flags);
list_add_tail(>list, >tx_free);
spin_unlock_irqrestore(>tx_lock, flags);
@@ -1833,7 +1835,6 @@ static void r8152_power_cut_en(struct r8152 *tp, bool 
enable)
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_PM_CTRL_STATUS);
ocp_data &= ~RESUME_INDICATE;
ocp_write_word(tp, MCU_TYPE_USB, USB_PM_CTRL_STATUS, ocp_data);
-
 }
 
 #define WAKE_ANY (WAKE_PHY | WAKE_MAGIC | WAKE_UCAST | WAKE_BCAST | WAKE_MCAST)
@@ -2013,8 +2014,8 @@ static void r8152b_hw_phy_cfg(struct r8152 *tp)
 
 static void r8152b_exit_oob(struct r8152 *tp)
 {
-   u32 ocp_data;
-   int i;
+   u32 ocp_data;
+   int i;
 
ocp_data = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
ocp_data &= ~RCR_ACPT_ALL;
@@ -2573,6 +2574,7 @@ static int rtl8152_open(struct net_device *netdev)
netif_carrier_off(netdev);
netif_start_queue(netdev);
set_bit(WORK_ENABLE, >flags);
+
res = usb_submit_urb(tp->intr_urb, GFP_KERNEL);
if (res) {
if (res == -ENODEV)
@@ -3101,6 +3103,7 @@ static int rtl8152_probe(struct usb_interface *intf,
 
netdev->features |= NETIF_F_IP_CSUM;
netdev->hw_features = NETIF_F_IP_CSUM;
+
SET_ETHTOOL_OPS(netdev, );
 
tp->mii.dev = netdev;
-- 
1.8.4.2

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


[PATCH net-next v2 03/13] r8152: remove rtl8152_get_stats

2014-03-04 Thread Hayes Wang
The rtl8152_get_stats() returns the point address of the struct
net_device_stats. This could be got from struct net_device directly.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 21 ++---
 1 file changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 151398b..b8eee36 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -960,11 +960,6 @@ static int rtl8152_set_mac_address(struct net_device 
*netdev, void *p)
return 0;
 }
 
-static struct net_device_stats *rtl8152_get_stats(struct net_device *dev)
-{
-   return >stats;
-}
-
 static void read_bulk_callback(struct urb *urb)
 {
struct net_device *netdev;
@@ -1052,7 +1047,7 @@ static void write_bulk_callback(struct urb *urb)
return;
 
netdev = tp->netdev;
-   stats = rtl8152_get_stats(netdev);
+   stats = >stats;
if (status) {
if (net_ratelimit())
netdev_warn(netdev, "Tx status %d\n", status);
@@ -1442,7 +1437,7 @@ static void rx_bottom(struct r8152 *tp)
 
while (urb->actual_length > len_used) {
struct net_device *netdev = tp->netdev;
-   struct net_device_stats *stats;
+   struct net_device_stats *stats = >stats;
unsigned int pkt_len;
struct sk_buff *skb;
 
@@ -1454,8 +1449,6 @@ static void rx_bottom(struct r8152 *tp)
if (urb->actual_length < len_used)
break;
 
-   stats = rtl8152_get_stats(netdev);
-
pkt_len -= CRC_SIZE;
rx_data += sizeof(struct rx_desc);
 
@@ -1504,16 +1497,14 @@ static void tx_bottom(struct r8152 *tp)
 
res = r8152_tx_agg_fill(tp, agg);
if (res) {
-   struct net_device_stats *stats;
-   struct net_device *netdev;
-   unsigned long flags;
-
-   netdev = tp->netdev;
-   stats = rtl8152_get_stats(netdev);
+   struct net_device *netdev = tp->netdev;
 
if (res == -ENODEV) {
netif_device_detach(netdev);
} else {
+   struct net_device_stats *stats = >stats;
+   unsigned long flags;
+
netif_warn(tp, tx_err, netdev,
   "failed tx_urb %d\n", res);
stats->tx_dropped += agg->skb_num;
-- 
1.8.4.2

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


[PATCH net-next v2 06/13] r8152: up the priority of the transmission

2014-03-04 Thread Hayes Wang
move the tx_bottom() from delayed_work to tasklet. It makes the rx
and tx balanced. If the device is in runtime suspend when getting
the tx packet, wakeup the device before trasmitting.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 45 +++--
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 00b3192..f1eaa18 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -447,6 +447,7 @@ enum rtl8152_flags {
RTL8152_LINK_CHG,
SELECTIVE_SUSPEND,
PHY_RESET,
+   SCHEDULE_TASKLET,
 };
 
 /* Define these values to match your device */
@@ -1071,7 +1072,7 @@ static void write_bulk_callback(struct urb *urb)
return;
 
if (!skb_queue_empty(>tx_queue))
-   schedule_delayed_work(>schedule, 0);
+   tasklet_schedule(>tl);
 }
 
 static void intr_callback(struct urb *urb)
@@ -1335,9 +1336,9 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct 
tx_agg *agg)
u8 *tx_data;
 
__skb_queue_head_init(_head);
-   spin_lock_bh(_queue->lock);
+   spin_lock(_queue->lock);
skb_queue_splice_init(tx_queue, _head);
-   spin_unlock_bh(_queue->lock);
+   spin_unlock(_queue->lock);
 
tx_data = agg->head;
agg->skb_num = agg->skb_len = 0;
@@ -1374,20 +1375,20 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct 
tx_agg *agg)
}
 
if (!skb_queue_empty(_head)) {
-   spin_lock_bh(_queue->lock);
+   spin_lock(_queue->lock);
skb_queue_splice(_head, tx_queue);
-   spin_unlock_bh(_queue->lock);
+   spin_unlock(_queue->lock);
}
 
-   netif_tx_lock_bh(tp->netdev);
+   netif_tx_lock(tp->netdev);
 
if (netif_queue_stopped(tp->netdev) &&
skb_queue_len(>tx_queue) < tp->tx_qlen)
netif_wake_queue(tp->netdev);
 
-   netif_tx_unlock_bh(tp->netdev);
+   netif_tx_unlock(tp->netdev);
 
-   ret = usb_autopm_get_interface(tp->intf);
+   ret = usb_autopm_get_interface_async(tp->intf);
if (ret < 0)
goto out_tx_fill;
 
@@ -1395,9 +1396,9 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct 
tx_agg *agg)
  agg->head, (int)(tx_data - (u8 *)agg->head),
  (usb_complete_t)write_bulk_callback, agg);
 
-   ret = usb_submit_urb(agg->urb, GFP_KERNEL);
+   ret = usb_submit_urb(agg->urb, GFP_ATOMIC);
if (ret < 0)
-   usb_autopm_put_interface(tp->intf);
+   usb_autopm_put_interface_async(tp->intf);
 
 out_tx_fill:
return ret;
@@ -1535,6 +1536,7 @@ static void bottom_half(unsigned long data)
return;
 
rx_bottom(tp);
+   tx_bottom(tp);
 }
 
 static
@@ -1630,7 +1632,7 @@ static void _rtl8152_set_rx_mode(struct net_device 
*netdev)
 }
 
 static netdev_tx_t rtl8152_start_xmit(struct sk_buff *skb,
-   struct net_device *netdev)
+   struct net_device *netdev)
 {
struct r8152 *tp = netdev_priv(netdev);
 
@@ -1638,13 +1640,17 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff 
*skb,
 
skb_queue_tail(>tx_queue, skb);
 
-   if (list_empty(>tx_free) &&
-   skb_queue_len(>tx_queue) > tp->tx_qlen)
+   if (!list_empty(>tx_free)) {
+   if (test_bit(SELECTIVE_SUSPEND, >flags)) {
+   set_bit(SCHEDULE_TASKLET, >flags);
+   schedule_delayed_work(>schedule, 0);
+   } else {
+   usb_mark_last_busy(tp->udev);
+   tasklet_schedule(>tl);
+   }
+   } else if (skb_queue_len(>tx_queue) > tp->tx_qlen)
netif_stop_queue(netdev);
 
-   if (!list_empty(>tx_free))
-   schedule_delayed_work(>schedule, 0);
-
return NETDEV_TX_OK;
 }
 
@@ -2523,8 +2529,11 @@ static void rtl_work_func_t(struct work_struct *work)
if (test_bit(RTL8152_SET_RX_MODE, >flags))
_rtl8152_set_rx_mode(tp->netdev);
 
-   if (tp->speed & LINK_STATUS)
-   tx_bottom(tp);
+   if (test_bit(SCHEDULE_TASKLET, >flags) &&
+   (tp->speed & LINK_STATUS)) {
+   clear_bit(SCHEDULE_TASKLET, >flags);
+   tasklet_schedule(>tl);
+   }
 
if (test_bit(PHY_RESET, >flags))
rtl_phy_reset(tp);
-- 
1.8.4.2

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


[PATCH net-next v2 02/13] r8152: replace tp->netdev with netdev

2014-03-04 Thread Hayes Wang
Replace some tp->netdev with netdev.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c8bad62..151398b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1037,6 +1037,7 @@ static void read_bulk_callback(struct urb *urb)
 static void write_bulk_callback(struct urb *urb)
 {
struct net_device_stats *stats;
+   struct net_device *netdev;
unsigned long flags;
struct tx_agg *agg;
struct r8152 *tp;
@@ -1050,10 +1051,11 @@ static void write_bulk_callback(struct urb *urb)
if (!tp)
return;
 
-   stats = rtl8152_get_stats(tp->netdev);
+   netdev = tp->netdev;
+   stats = rtl8152_get_stats(netdev);
if (status) {
if (net_ratelimit())
-   netdev_warn(tp->netdev, "Tx status %d\n", status);
+   netdev_warn(netdev, "Tx status %d\n", status);
stats->tx_errors += agg->skb_num;
} else {
stats->tx_packets += agg->skb_num;
@@ -1066,7 +1068,7 @@ static void write_bulk_callback(struct urb *urb)
 
usb_autopm_put_interface_async(tp->intf);
 
-   if (!netif_carrier_ok(tp->netdev))
+   if (!netif_carrier_ok(netdev))
return;
 
if (!test_bit(WORK_ENABLE, >flags))
-- 
1.8.4.2

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


[PATCH net-next v2 07/13] r8152: calculate the dropped packets for rx

2014-03-04 Thread Hayes Wang
Continue dealing with the remain rx packets, even though the allocation
of the skb fail. This could calculate the correct dropped packets.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f1eaa18..08f4e870 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1456,7 +1456,7 @@ static void rx_bottom(struct r8152 *tp)
skb = netdev_alloc_skb_ip_align(netdev, pkt_len);
if (!skb) {
stats->rx_dropped++;
-   break;
+   goto find_next_rx;
}
memcpy(skb->data, rx_data, pkt_len);
skb_put(skb, pkt_len);
@@ -1465,6 +1465,7 @@ static void rx_bottom(struct r8152 *tp)
stats->rx_packets++;
stats->rx_bytes += pkt_len;
 
+find_next_rx:
rx_data = rx_agg_align(rx_data + pkt_len + CRC_SIZE);
rx_desc = (struct rx_desc *)rx_data;
len_used = (int)(rx_data - (u8 *)agg->head);
-- 
1.8.4.2

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


[PATCH net-next v2 11/13] r8152: reduce the numbers of the bulks

2014-03-04 Thread Hayes Wang
Reduce the numbers of tx and rx aggregation buffers.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8e208f30..ddb5200 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -416,8 +416,8 @@ enum rtl_register_content {
FULL_DUP= 0x01,
 };
 
-#define RTL8152_MAX_TX 10
-#define RTL8152_MAX_RX 10
+#define RTL8152_MAX_TX 4
+#define RTL8152_MAX_RX 4
 #define INTBUFSIZE 2
 #define CRC_SIZE   4
 #define TX_ALIGN   4
-- 
1.8.4.2

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


[PATCH net-next v2 12/13] r8152: add additional parameter for non x86 platform

2014-03-04 Thread Hayes Wang
Add additional parameter for non x86 platform for better throughput.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ddb5200..6c0ec37 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -313,7 +313,11 @@
 #define PCUT_STATUS0x0001
 
 /* USB_RX_EARLY_AGG */
-#define EARLY_AGG_SUPPER   0x0e832981
+#if defined(__i386__) || defined(__x86_64__)
+   #define EARLY_AGG_SUPPER0x0e832981
+#else
+   #define EARLY_AGG_SUPPER0x0e835000
+#endif
 #define EARLY_AGG_HIGH 0x0e837a12
 #define EARLY_AGG_SLOW 0x0e83
 
-- 
1.8.4.2

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


[PATCH net-next v2 10/13] r8152: support IPv6

2014-03-04 Thread Hayes Wang
Support hw IPv6 checksum for TCP and UDP packets.

Note that the hw has the limitation of the range of the transport
offset. Besides, the TCP Pseudo Header of the IPv6 TSO of the hw
bases on the Microsoft document which excludes the packet length.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 107 ++--
 1 file changed, 104 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8f6d0f8..8e208f30 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Version Information */
 #define DRIVER_VERSION "v1.06.0 (2014/03/03)"
@@ -472,6 +473,7 @@ struct rx_desc {
__le32 opts2;
 #define RD_UDP_CS  (1 << 23)
 #define RD_TCP_CS  (1 << 22)
+#define RD_IPV6_CS (1 << 20)
 #define RD_IPV4_CS (1 << 19)
 
__le32 opts3;
@@ -489,7 +491,9 @@ struct tx_desc {
 #define TX_FS  (1 << 31) /* First segment of a packet */
 #define TX_LS  (1 << 30) /* Final segment of a packet */
 #define GTSENDV4   (1 << 28)
+#define GTSENDV6   (1 << 27)
 #define GTTCPHO_SHIFT  18
+#define GTTCPHO_MAX0x7fU
 #define TX_LEN_MAX 0x3U
 
__le32 opts2;
@@ -500,6 +504,7 @@ struct tx_desc {
 #define MSS_SHIFT  17
 #define MSS_MAX0x7ffU
 #define TCPHO_SHIFT17
+#define TCPHO_MAX  0x7ffU
 };
 
 struct r8152;
@@ -1319,6 +1324,70 @@ static inline __be16 get_protocol(struct sk_buff *skb)
return protocol;
 }
 
+/*
+ * r8152_csum_workaround()
+ * The hw limites the value the transport offset. When the offset is out of the
+ * range, calculate the checksum by sw.
+ */
+static void r8152_csum_workaround(struct r8152 *tp, struct sk_buff *skb,
+ struct sk_buff_head *list)
+{
+   if (skb_shinfo(skb)->gso_size) {
+   netdev_features_t features = tp->netdev->features;
+   struct sk_buff_head seg_list;
+   struct sk_buff *segs, *nskb;
+
+   features &= ~(NETIF_F_IP_CSUM | NETIF_F_SG | NETIF_F_TSO);
+   segs = skb_gso_segment(skb, features);
+   if (IS_ERR(segs) || !segs)
+   goto drop;
+
+   __skb_queue_head_init(_list);
+
+   do {
+   nskb = segs;
+   segs = segs->next;
+   nskb->next = NULL;
+   __skb_queue_tail(_list, nskb);
+   } while (segs);
+
+   skb_queue_splice(_list, list);
+
+   dev_kfree_skb(skb);
+   } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
+   if (skb_checksum_help(skb) < 0)
+   goto drop;
+
+   __skb_queue_head(list, skb);
+   } else {
+   struct net_device_stats *stats;
+
+drop:
+   stats = >netdev->stats;
+   stats->tx_dropped++;
+   dev_kfree_skb(skb);
+   }
+}
+
+/*
+ * msdn_giant_send_check()
+ * According to the document of microsoft, the TCP Pseudo Header excludes the
+ * packet length for IPv6 TCP large packets.
+ */
+static int msdn_giant_send_check(struct sk_buff *skb)
+{
+   const struct ipv6hdr *ipv6h;
+   struct tcphdr *th;
+
+   ipv6h = ipv6_hdr(skb);
+   th = tcp_hdr(skb);
+
+   th->check = 0;
+   th->check = ~tcp_v6_check(0, >saddr, >daddr, 0);
+
+   return 0;
+}
+
 static int r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
 struct sk_buff *skb, u32 len, u32 transport_offset)
 {
@@ -1331,11 +1400,24 @@ static int r8152_tx_csum(struct r8152 *tp, struct 
tx_desc *desc,
opts1 = len | TX_FS | TX_LS;
 
if (mss) {
+   if (transport_offset > GTTCPHO_MAX) {
+   netif_warn(tp, tx_err, tp->netdev,
+  "Invalid transport offset 0x%x for TSO\n",
+  transport_offset);
+   ret = TX_CSUM_TSO;
+   goto unavailable;
+   }
+
switch (get_protocol(skb)) {
case htons(ETH_P_IP):
opts1 |= GTSENDV4;
break;
 
+   case htons(ETH_P_IPV6):
+   opts1 |= GTSENDV6;
+   msdn_giant_send_check(skb);
+   break;
+
default:
WARN_ON_ONCE(1);
break;
@@ -1346,6 +1428,14 @@ static int r8152_tx_csum(struct r8152 *tp, struct 
tx_desc *desc,
} else if (skb->ip_summed == CHECKSUM_PARTIAL) {
u8 ip_protocol;
 
+   if (transport_offset > TCPHO_MAX) {
+   netif_warn(tp, tx_err, tp->netdev,
+ 

[PATCH net-next v2 08/13] r8152: support rx checksum

2014-03-04 Thread Hayes Wang
Support hw rx checksum for TCP and UDP packets.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 41 +++--
 1 file changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 08f4e870..c76e018 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -466,9 +466,19 @@ enum rtl8152_flags {
 
 struct rx_desc {
__le32 opts1;
+#define RD_CRC (1 << 15)
 #define RX_LEN_MASK0x7fff
+
__le32 opts2;
+#define RD_UDP_CS  (1 << 23)
+#define RD_TCP_CS  (1 << 22)
+#define RD_IPV4_CS (1 << 19)
+
__le32 opts3;
+#define IPF(1 << 23) /* IP checksum fail */
+#define UDPF   (1 << 22) /* UDP checksum fail */
+#define TCPF   (1 << 21) /* TCP checksum fail */
+
__le32 opts4;
__le32 opts5;
__le32 opts6;
@@ -1404,6 +1414,31 @@ out_tx_fill:
return ret;
 }
 
+static int r8152_rx_csum(struct r8152 *tp, struct rx_desc *rx_desc)
+{
+   int checksum = CHECKSUM_NONE;
+   u32 opts2, opts3;
+
+   if (tp->version == RTL_VER_01)
+   goto return_result;
+
+   opts2 = le32_to_cpu(rx_desc->opts2);
+   opts3 = le32_to_cpu(rx_desc->opts3);
+
+   if (opts2 & RD_IPV4_CS) {
+   if (opts3 & IPF)
+   checksum = CHECKSUM_NONE;
+   else if (((opts2 & RD_UDP_CS) && (opts3 & UDPF)) ||
+((opts2 & RD_TCP_CS) && (opts3 & TCPF)))
+   checksum = CHECKSUM_NONE;
+   else
+   checksum = CHECKSUM_UNNECESSARY;
+   }
+
+return_result:
+   return checksum;
+}
+
 static void rx_bottom(struct r8152 *tp)
 {
unsigned long flags;
@@ -1458,6 +1493,8 @@ static void rx_bottom(struct r8152 *tp)
stats->rx_dropped++;
goto find_next_rx;
}
+
+   skb->ip_summed = r8152_rx_csum(tp, rx_desc);
memcpy(skb->data, rx_data, pkt_len);
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, netdev);
@@ -3103,8 +3140,8 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev->netdev_ops = _netdev_ops;
netdev->watchdog_timeo = RTL8152_TX_TIMEOUT;
 
-   netdev->features |= NETIF_F_IP_CSUM;
-   netdev->hw_features = NETIF_F_IP_CSUM;
+   netdev->features |= NETIF_F_RXCSUM | NETIF_F_IP_CSUM;
+   netdev->hw_features = NETIF_F_RXCSUM | NETIF_F_IP_CSUM;
 
SET_ETHTOOL_OPS(netdev, );
 
-- 
1.8.4.2

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


[PATCH net-next v2 13/13] r8152: modify the tx timeout funcfion

2014-03-04 Thread Hayes Wang
Reset and reinitialize the device when the tx timeout occurs.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 41 +++--
 1 file changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 6c0ec37..2de8ce4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1764,16 +1764,6 @@ static void rtl_drop_queued_tx(struct r8152 *tp)
}
 }
 
-static void rtl8152_tx_timeout(struct net_device *netdev)
-{
-   struct r8152 *tp = netdev_priv(netdev);
-   int i;
-
-   netif_warn(tp, tx_err, netdev, "Tx timeout\n");
-   for (i = 0; i < RTL8152_MAX_TX; i++)
-   usb_unlink_urb(tp->tx_info[i].urb);
-}
-
 static void rtl8152_set_rx_mode(struct net_device *netdev)
 {
struct r8152 *tp = netdev_priv(netdev);
@@ -3150,6 +3140,37 @@ out:
return res;
 }
 
+static void rtl8152_tx_timeout(struct net_device *netdev)
+{
+   struct r8152 *tp = netdev_priv(netdev);
+
+   netif_warn(tp, tx_err, netdev, "Tx timeout\n");
+
+   if (usb_autopm_get_interface(tp->intf) < 0)
+   return;
+
+   netif_stop_queue(netdev);
+   clear_bit(WORK_ENABLE, >flags);
+   usb_kill_urb(tp->intr_urb);
+   cancel_delayed_work_sync(>schedule);
+   tp->rtl_ops.down(tp);
+
+   usb_reset_device(tp->udev);
+
+   tp->rtl_ops.init(tp);
+   tp->rtl_ops.up(tp);
+   rtl8152_set_speed(tp, AUTONEG_ENABLE,
+ tp->mii.supports_gmii ? SPEED_1000 : SPEED_100,
+ DUPLEX_FULL);
+   tp->speed = 0;
+   netif_carrier_off(netdev);
+   netif_start_queue(netdev);
+   set_bit(WORK_ENABLE, >flags);
+   usb_submit_urb(tp->intr_urb, GFP_KERNEL);
+
+   usb_autopm_put_interface(tp->intf);
+}
+
 static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_open   = rtl8152_open,
.ndo_stop   = rtl8152_close,
-- 
1.8.4.2

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


[PATCH net-next v2 00/13] r8152: new features

2014-03-04 Thread Hayes Wang
Besides the adjustment of the code, support rx checksum,
TCP large send, and IPv6.

v2:
 - Split "support rx checksum" into two patches.
 - Don't drop the packet, even though the rx checksum fail for
   "support rx checksum".
 - Replace r8152_xmit_frags() with skb_copy_bits() for "support TSO".
 - Fix the issue of reording the packets for "support IPv6".

Hayes Wang (13):
  r8152: deal with the empty line and space
  r8152: replace tp->netdev with netdev
  r8152: remove rtl8152_get_stats
  r8152: replace spin_lock_irqsave and spin_unlock_irqrestore
  r8152: check tx agg list before spin lock
  r8152: up the priority of the transmission
  r8152: calculate the dropped packets for rx
  r8152: support rx checksum
  r8152: support TSO
  r8152: support IPv6
  r8152: reduce the numbers of the bulks
  r8152: add additional parameter for non x86 platform
  r8152: modify the tx timeout funcfion

 drivers/net/usb/r8152.c | 411 +---
 1 file changed, 318 insertions(+), 93 deletions(-)

--
1.8.4.2

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


[PATCH net-next v2 09/13] r8152: support TSO

2014-03-04 Thread Hayes Wang
Support scatter gather and TSO.

Adjust the tx checksum function and set the max gso size to fix the
size of the tx aggregation buffer.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 117 +++-
 1 file changed, 87 insertions(+), 30 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c76e018..8f6d0f8 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -23,7 +23,7 @@
 #include 
 
 /* Version Information */
-#define DRIVER_VERSION "v1.05.0 (2014/02/18)"
+#define DRIVER_VERSION "v1.06.0 (2014/03/03)"
 #define DRIVER_AUTHOR "Realtek linux nic maintainers "
 #define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
 #define MODULENAME "r8152"
@@ -488,13 +488,18 @@ struct tx_desc {
__le32 opts1;
 #define TX_FS  (1 << 31) /* First segment of a packet */
 #define TX_LS  (1 << 30) /* Final segment of a packet */
-#define TX_LEN_MASK0x3
+#define GTSENDV4   (1 << 28)
+#define GTTCPHO_SHIFT  18
+#define TX_LEN_MAX 0x3U
 
__le32 opts2;
 #define UDP_CS (1 << 31) /* Calculate UDP/IP checksum */
 #define TCP_CS (1 << 30) /* Calculate TCP/IP checksum */
 #define IPV4_CS(1 << 29) /* Calculate IPv4 checksum */
 #define IPV6_CS(1 << 28) /* Calculate IPv6 checksum */
+#define MSS_SHIFT  17
+#define MSS_MAX0x7ffU
+#define TCPHO_SHIFT17
 };
 
 struct r8152;
@@ -561,12 +566,21 @@ enum rtl_version {
RTL_VER_MAX
 };
 
+enum tx_csum_stat {
+   TX_CSUM_SUCCESS = 0,
+   TX_CSUM_TSO,
+   TX_CSUM_NONE
+};
+
 /* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
  * The RTL chips use a 64 element hash table based on the Ethernet CRC.
  */
 static const int multicast_filter_limit = 32;
 static unsigned int rx_buf_sz = 16384;
 
+#define RTL_LIMITED_TSO_SIZE   (rx_buf_sz - sizeof(struct tx_desc) - \
+VLAN_ETH_HLEN - VLAN_HLEN)
+
 static
 int get_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
 {
@@ -1293,24 +1307,46 @@ static struct tx_agg *r8152_get_tx_agg(struct r8152 *tp)
return agg;
 }
 
-static void
-r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, struct sk_buff *skb)
+static inline __be16 get_protocol(struct sk_buff *skb)
 {
-   memset(desc, 0, sizeof(*desc));
+   __be16 protocol;
 
-   desc->opts1 = cpu_to_le32((skb->len & TX_LEN_MASK) | TX_FS | TX_LS);
+   if (skb->protocol == htons(ETH_P_8021Q))
+   protocol = vlan_eth_hdr(skb)->h_vlan_encapsulated_proto;
+   else
+   protocol = skb->protocol;
 
-   if (skb->ip_summed == CHECKSUM_PARTIAL) {
-   __be16 protocol;
-   u8 ip_protocol;
-   u32 opts2 = 0;
+   return protocol;
+}
 
-   if (skb->protocol == htons(ETH_P_8021Q))
-   protocol = vlan_eth_hdr(skb)->h_vlan_encapsulated_proto;
-   else
-   protocol = skb->protocol;
+static int r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
+struct sk_buff *skb, u32 len, u32 transport_offset)
+{
+   u32 mss = skb_shinfo(skb)->gso_size;
+   u32 opts1, opts2 = 0;
+   int ret = TX_CSUM_SUCCESS;
+
+   WARN_ON_ONCE(len > TX_LEN_MAX);
+
+   opts1 = len | TX_FS | TX_LS;
+
+   if (mss) {
+   switch (get_protocol(skb)) {
+   case htons(ETH_P_IP):
+   opts1 |= GTSENDV4;
+   break;
+
+   default:
+   WARN_ON_ONCE(1);
+   break;
+   }
+
+   opts1 |= transport_offset << GTTCPHO_SHIFT;
+   opts2 |= min(mss, MSS_MAX) << MSS_SHIFT;
+   } else if (skb->ip_summed == CHECKSUM_PARTIAL) {
+   u8 ip_protocol;
 
-   switch (protocol) {
+   switch (get_protocol(skb)) {
case htons(ETH_P_IP):
opts2 |= IPV4_CS;
ip_protocol = ip_hdr(skb)->protocol;
@@ -1326,17 +1362,20 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, 
struct sk_buff *skb)
break;
}
 
-   if (ip_protocol == IPPROTO_TCP) {
+   if (ip_protocol == IPPROTO_TCP)
opts2 |= TCP_CS;
-   opts2 |= (skb_transport_offset(skb) & 0x7fff) << 17;
-   } else if (ip_protocol == IPPROTO_UDP) {
+   else if (ip_protocol == IPPROTO_UDP)
opts2 |= UDP_CS;
-   } else {
+   else
WARN_ON_ONCE(1);
-   }
 
-   desc->opts2 = cpu_to_le32(opts2);
+   opts2 |= transport_offset << TCPHO_SHIFT;
 

Re: [PATCH] staging: usbip: claim ports used by shared devices

2014-03-04 Thread Greg KH
On Tue, Mar 04, 2014 at 09:25:04PM +0200, Valentina Manea wrote:
> Signed-off-by: Valentina Manea 

As you are touching core USB code, you need to have some kind of
description here as to what you are doing, and why you are doing 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/


Re: [PATCH 1/5] drivers: input: keyboard: st-keyscan: add keyscan driver

2014-03-04 Thread Dmitry Torokhov
Hi Gabriel,

On Wed, Mar 05, 2014 at 04:39:28AM +0100, Gabriel FERNANDEZ wrote:
> This patch adds ST Keyscan driver to use the keypad hw a subset
> of ST boards provide. Specific board setup will be put in the
> given dt.
> 
> Signed-off-by: Giuseppe Condorelli 
> Signed-off-by: Gabriel Fernandez 
> ---
>  .../devicetree/bindings/input/st-keypad.txt|  50 
>  drivers/input/keyboard/Kconfig |  12 +
>  drivers/input/keyboard/Makefile|   1 +
>  drivers/input/keyboard/st-keyscan.c| 323 
> +
>  4 files changed, 386 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/st-keypad.txt
>  create mode 100644 drivers/input/keyboard/st-keyscan.c
> 
> diff --git a/Documentation/devicetree/bindings/input/st-keypad.txt 
> b/Documentation/devicetree/bindings/input/st-keypad.txt
> new file mode 100644
> index 000..63eb07a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/st-keypad.txt
> @@ -0,0 +1,50 @@
> +* ST Keypad controller device tree bindings
> +
> +The ST keypad controller device tree binding is based on the
> +matrix-keymap.
> +
> +Required properties:
> +
> +- compatible: "st,keypad"
> +
> +- reg: Register base address of st-keypad controler.
> +
> +- interrupts: Interrupt numberof st-keypad controler.
> +
> +- clocks: Must contain one entry, for the module clock.
> +  See ../clocks/clock-bindings.txt for details.
> +
> +- pinctrl-0: Should specify pin control groups used for this controller.
> +
> +- pinctrl-names: Should contain only one value - "default".
> +
> +- linux,keymap: The keymap for keys as described in the binding document
> +  devicetree/bindings/input/matrix-keymap.txt.
> +
> +- keypad,num-rows: Number of row lines connected to the keypad controller.
> +
> +- keypad,num-columns: Number of column lines connected to the keypad
> +  controller.
> +
> +- st,debounce_us: Debouncing interval time in microseconds
> +
> +
> +Example:
> +
> +keyscan: keyscan@fe4b {
> + compatible = "st,keypad";
> + reg = <0xfe4b 0x2000>;
> + interrupts = ;
> + clocks  = <_SYSIN>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_keyscan>;
> +
> + keypad,num-rows = <4>;
> + keypad,num-columns = <4>;
> + st,debounce_us = <5000>;
> + linux,keymap = < /* in0 in1 in2 in3 */
> + KEY_F13 KEY_F9  KEY_F5 KEY_F1   /* out0 */
> + KEY_F14 KEY_F10 KEY_F6 KEY_F2   /* out1 */
> + KEY_F15 KEY_F11 KEY_F7 KEY_F3   /* out2 */
> + KEY_F16 KEY_F12 KEY_F8 KEY_F4 >;/* out3 */
> +};
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index a673c9f..9e29125 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -512,6 +512,18 @@ config KEYBOARD_STOWAWAY
> To compile this driver as a module, choose M here: the
> module will be called stowaway.
>  
> +config KEYBOARD_ST_KEYSCAN
> + tristate "STMicroelectronics keyscan support"
> + depends on ARCH_STI
> + select INPUT_EVDEV
> + select INPUT_MATRIXKMAP
> + help
> +   Say Y here if you want to use a keypad attached to the keyscan block
> +   on some STMicroelectronics SoC devices.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called stm-keyscan.
> +
>  config KEYBOARD_SUNKBD
>   tristate "Sun Type 4 and Type 5 keyboard"
>   select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index a699b61..5fd020a 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_KEYBOARD_SH_KEYSC) += sh_keysc.o
>  obj-$(CONFIG_KEYBOARD_SPEAR) += spear-keyboard.o
>  obj-$(CONFIG_KEYBOARD_STMPE) += stmpe-keypad.o
>  obj-$(CONFIG_KEYBOARD_STOWAWAY)  += stowaway.o
> +obj-$(CONFIG_KEYBOARD_ST_KEYSCAN)+= st-keyscan.o
>  obj-$(CONFIG_KEYBOARD_SUNKBD)+= sunkbd.o
>  obj-$(CONFIG_KEYBOARD_TC3589X)   += tc3589x-keypad.o
>  obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> diff --git a/drivers/input/keyboard/st-keyscan.c 
> b/drivers/input/keyboard/st-keyscan.c
> new file mode 100644
> index 000..606cc19
> --- /dev/null
> +++ b/drivers/input/keyboard/st-keyscan.c
> @@ -0,0 +1,323 @@
> +/*
> + * STMicroelectronics Key Scanning driver
> + *
> + * Copyright (c) 2014 STMicroelectonics Ltd.
> + * Author: Stuart Menefy 
> + *
> + * Based on sh_keysc.c, copyright 2008 Magnus Damm
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ST_KEYSCAN_MAXKEYS 16
> +
> +#define KEYSCAN_CONFIG_OFF   

Re: [PATCH v2] ARM: dts: remove bcm11351-brt.dts

2014-03-04 Thread Matt Porter
On Wed, Feb 19, 2014 at 04:31:52PM -0500, Matt Porter wrote:
> The BCM11351 BRT board will never see the light of day. Remove the BRT
> dts since it is not maintainable.
> 
> Reviewed-by: Alex Elder 
> Signed-off-by: Matt Porter 
> ---
> Changes since v1:
>   - remove bcm11351-brt from Makefile
> 

Applied to mach-bcm for-3.15/dt

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


Re: [PATCH 00/12] Migrate usbip-utils to libudev

2014-03-04 Thread Greg KH
On Tue, Mar 04, 2014 at 09:10:40PM +0200, Valentina Manea wrote:
> This patch series modifies the USB/IP userspace side (usbip-utils)
> to use libudev instead of libsysfs. This change was necessary as
> libsysfs is no longer maintained and we have discovered a bug that
> affected USB/IP.

That's great, I didn't even know anything even used libsysfs anymore.

> On the other hand, libudev is actively maintained and recommended
> for interacting with sysfs.

Yes, that's the correct thing to do here, nice job.

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/


linux-next: build failure after merge of the final tree (gpio tree related)

2014-03-04 Thread Stephen Rothwell
Hi all,

After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/gpio/gpio-zevio.c: In function 'zevio_gpio_port_get':
drivers/gpio/gpio-zevio.c:70:2: error: implicit declaration of function 'IOMEM' 
[-Werror=implicit-function-declaration]
  return readl(IOMEM(c->chip.regs + section_offset + port_offset));
  ^
drivers/gpio/gpio-zevio.c:70:2: warning: passing argument 1 of 'readl' makes 
pointer from integer without a cast [enabled by default]
In file included from include/linux/io.h:22:0,
 from drivers/gpio/gpio-zevio.c:15:
arch/powerpc/include/asm/io-defs.h:6:16: note: expected 'const volatile void *' 
but argument is of type 'int'
 DEF_PCI_AC_RET(readl, u32, (const PCI_IO_ADDR addr), (addr), mem, addr)
^
arch/powerpc/include/asm/io.h:577:19: note: in definition of macro 
'DEF_PCI_AC_RET'
 static inline ret name at \
   ^
drivers/gpio/gpio-zevio.c: In function 'zevio_gpio_port_set':
drivers/gpio/gpio-zevio.c:77:2: warning: passing argument 2 of 'writel' makes 
pointer from integer without a cast [enabled by default]
  writel(val, IOMEM(c->chip.regs + section_offset + port_offset));
  ^
In file included from include/linux/io.h:22:0,
 from drivers/gpio/gpio-zevio.c:15:
arch/powerpc/include/asm/io-defs.h:11:18: note: expected 'volatile void *' but 
argument is of type 'int'
 DEF_PCI_AC_NORET(writel, (u32 val, PCI_IO_ADDR addr), (val, addr), mem, addr)
  ^
arch/powerpc/include/asm/io.h:585:20: note: in definition of macro 
'DEF_PCI_AC_NORET'
 static inline void name at \
^

Caused by commit 9af4d80ba566 ("gpio: New driver for LSI ZEVIO SoCs").

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp79obEc_xOh.pgp
Description: PGP signature


Re: [PATCH 06/12] staging: usbip: userspace: add new list API

2014-03-04 Thread Greg KH
On Tue, Mar 04, 2014 at 09:10:46PM +0200, Valentina Manea wrote:
> Add a new list API from CCAN.

Why can't you just take the one from the kernel, as userspace is GPLv2
code, right?

And are you sure CC0 is a "valid" license that you can mix with GPLv2
code?  I ask this seriously, as I have heard that CC0 really isn't even
a valid license at all, and if I was to accept this patch, I'm going to
have to go talk to some lawyers, which isn't going to be fun...

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] support Thinkpad X1 Carbon 2nd generation's adaptive keyboard

2014-03-04 Thread Shuduo Sang


On 03/05/2014 01:54 PM, SeongJae Park wrote:
> Hello,
> This is just a trivial comment.
> 
> 
> On Tue, Mar 4, 2014 at 8:13 PM, Shuduo Sang  wrote:
>>
>>
>> Submit patch V3 to support Adaptive Keyboard on Thinkpad X1 Carbon 2nd
>> generation according to Tobias's comments.
>>
>> Thanks,
>> Shuduo
>>
>> From 2b8175e69deee661d97d371b2422a9c192fefd52 Mon Sep 17 00:00:00 2001
>> From: Shuduo Sang 
>> Date: Mon, 3 Mar 2014 14:29:32 +0800
>> Subject: [PATCH] support thinkpad X1 Carbon's adaptive keyboard
>>
>> Thinkpad X1 Carbon's adaptive keyboard has five modes including Home
>> mode, Web browser mode, Web conference mode, Function mode and Lay-flat
>> mode. We support Home mode and Function mode currently.
>>
>> Signed-off-by: Bruce Ma 
>> Signed-off-by: Shuduo Sang 
>> ---
>>  drivers/platform/x86/thinkpad_acpi.c | 102
>> +++
>>  1 file changed, 102 insertions(+)
>>
>> diff --git a/drivers/platform/x86/thinkpad_acpi.c
>> b/drivers/platform/x86/thinkpad_acpi.c
>> index defb6af..6664dcd 100644
>> --- a/drivers/platform/x86/thinkpad_acpi.c
>> +++ b/drivers/platform/x86/thinkpad_acpi.c
>> @@ -3437,6 +3437,106 @@ err_exit:
>> return (res < 0)? res : 1;
>>  }
>>
>> +/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
>> + * mode, Web conference mode, Function mode and Lay-flat mode.
>> + * We support Home mode and Function mode currently.
>> + *
>> + * Will consider support rest of modes in future.
>> + *
>> + */
>> +enum ADAPTIVE_KEY_MODE {
>> +   HOME_MODE,
>> +   WEB_BROWSER_MODE,
>> +   WEB_CONFERENCE_MODE,
>> +   FUNCTION_MODE,
>> +   LAYFLAT_MODE
>> +};
>> +
>> +int adaptive_keyboard_modes[] = {
>> +   HOME_MODE,
>> +/* WEB_BROWSER_MODE = 2,
>> +   WEB_CONFERENCE_MODE = 3, */
>> +   FUNCTION_MODE
>> +};
>> +
>> +#define DFR_CHANGE_ROW 0x101
>> +#define DFR_SHOW_QUICKVIEW_ROW 0x102
>> +
>> +/* press Fn key a while second, it will switch to Function Mode. Then
>> + * release Fn key, previous mode be restored.
>> + */
>> +static bool adaptive_keyboard_mode_is_saved;
>> +static int adaptive_keyboard_prev_mode;
>> +
>> +static int adaptive_keyboard_get_next_mode(int mode)
>> +{
>> +   int i;
>> +   size_t max_mode = ARRAY_SIZE(adaptive_keyboard_modes) - 1;
>> +
>> +   for (i = 0; i <= max_mode; i++) {
>> +   if (adaptive_keyboard_modes[i] == mode)
>> +   break;
>> +   }
>> +
>> +   if (i >= max_mode)
>> +   i = 0;
>> +   else
>> +   i++;
>> +
>> +   return adaptive_keyboard_modes[i];
>> +}
>> +
>> +static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
>> +{
>> +   u32 current_mode = 0;
>> +   int new_mode = 0;
>> +
>> +   switch (scancode) {
>> +   case DFR_CHANGE_ROW:
>> +   if (adaptive_keyboard_mode_is_saved) {
>> +   new_mode = adaptive_keyboard_prev_mode;
>> +   adaptive_keyboard_mode_is_saved = false;
>> +   } else {
>> +   if (!acpi_evalf(
>> +   hkey_handle, _mode,
>> +   "GTRW", "dd", 0)) {
>> +   pr_err("Cannot read adaptive keyboard 
>> mode\n");
>> +   return false;
>> +   } else {
>> +   new_mode = adaptive_keyboard_get_next_mode(
>> +   current_mode);
>> +   }
>> +   }
>> +
>> +   if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode)) {
>> +   pr_err("Cannot set adaptive keyboard mode\n");
>> +   return false;
>> +   }
>> +
>> +   return true;
> 
> Isn't the blank line above return statement unnecessary?
> 

Doesn't it look clearly? :)

>> +
>> +   case DFR_SHOW_QUICKVIEW_ROW:
>> +   if (!acpi_evalf(hkey_handle,
>> +   _keyboard_prev_mode,
>> +   "GTRW", "dd", 0)) {
>> +   pr_err("Cannot read adaptive keyboard mode\n");
>> +   return false;
>> +   } else {
>> +   adaptive_keyboard_mode_is_saved = true;
>> +
>> +   if (!acpi_evalf(hkey_handle,
>> +   NULL, "STRW", "vd", FUNCTION_MODE)) {
>> +   pr_err("Cannot set adaptive keyboard 
>> mode\n");
>> +   return false;
>> +   }
>> +   }
>> +   return true;
>> +
>> +   default:
>> +   return false;
>> +   }
>> +}
>> +
>>  static bool hotkey_notify_hotkey(const u32 hkey,
>>  bool *send_acpi_ev,
>>  bool *ignore_acpi_ev)
>> @@ -3456,6 

Re: [PATCH 0/3] Reorder drivers/video directory

2014-03-04 Thread Tomi Valkeinen
On 04/03/14 21:21, Randy Dunlap wrote:

>> I have pushed this to my for-next branch. Let's see what happens... At
>> least I'm able to merge the current linux-next without any conflicts.
> 
> Thanks, I'm looking at this change in linux-next now.
> 
> EXYNOS_VIDEO seems to be a little bit odd.  Can you clarify that for me?
> (This is not a change that you introduced.)
> 
> 
> In particular, under Graphics support, select Framebuffer Devices.
> This lists:
>   Support for frame buffer devices -->
>   Exynos Video driver support
> 
> It appears to me that Exynos either is a Framebuffer Device and should depend
> on FB like the other drivers here do OR (actually XOR) it is not a frame 
> buffer
> device and it should not be listed here.
> 
> Then once that is cleared up :), we don't need 2 levels of menu to get to the
> list of FB drivers -- i.e., one of those levels can be removed.

There are others. For my config, I have:

{*} Support for frame buffer devices  --->
 OMAP2+ Display Subsystem support  --->
[ ] Exynos Video driver support  
< > Solomon SSD1307 framebuffer support

I didn't want to start fixing those at the moment, as I have no idea
about exynos or solomon, and I wanted to just try to do the reorder,
without any other changes.

I agree that there's something wrong with the items. For the OMAP DSS,
there are non-fbdev related items under that menu, used also by omapdrm.
So it should probably be split into different components.

> Oh, and if you keep the new menu item "Framebuffer Devices", please spell it
> like the other entry (Frame Buffer).

Ok, fixed.

> Other than those nits, I like this change very much.  Thanks.

Thanks. After pushing this to for-next, I'm getting compile error
reports from Fengguang and Stephen. Let's see if I manage to avoid
those... This is not the easiest change to manage.

 Tomi




signature.asc
Description: OpenPGP digital signature


Re: [PATCH] Add option to build with -O3

2014-03-04 Thread Greg KH
On Wed, Mar 05, 2014 at 01:19:17AM -0500, Jon Ringle wrote:
> 
> 
> On Wed, 5 Mar 2014, Greg KH wrote:
> 
> > On Wed, Mar 05, 2014 at 12:37:56AM -0500, Jon Ringle wrote:
> > > The information contained in this transmission may contain confidential 
> > > information.  If the reader of this message is not the intended 
> > > recipient, you are hereby notified that any review, dissemination, 
> > > distribution or duplication of this communication is strictly prohibited. 
> > >  If you are not the intended recipient, please contact the sender by 
> > > reply email and destroy all copies of the original message.
> >
> > Because of this footer, I must destroy this message, kernel development
> > is not confidental.
> >
> 
> Obviously, this is a footer that is not added by me, but rather the mail
> server I am sending this message through. Besides, the footer indates it
> "may contain confidential information". The key word being *may*. Of
> course kernel development is never confidential and the content of any
> transmission done to the lkml is of public record. You and anyone who
> cares to read/comment this message on lkml is indeed the inteded
> recipient, therefore there is no need to destroy this message :)

But how do I know for sure that there isn't anything confidential in it?

> I sure hope your response was just in jest :)

Sadly, no, I have been advised that I am not supposed to respond to
messages with footers like that, and I am not allowed to take patches
with them either.

Now, I'm ignoring the first part (responding) to help you learn why your
patches will proabably always be ignored, please work to remove that
from your email server.

good luck,

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] IPv6 exthedrs offload registration fixed

2014-03-04 Thread Anton Nayshtut
Without this fix, ipv6_exthdrs_offload_init doesn't register IPPROTO_DSTOPTS
offload, but returns 0 (as the IPPROTO_ROUTING registration actually succeeds).

This then causes the ipv6_gso_segment to drop IPv6 packets with IPPROTO_DSTOPTS
header.

The issue detected and the fix verified by running MS HCK Offload LSO test on
top of QEMU Windows guests, as this test sends IPv6 packets with
IPPROTO_DSTOPTS.

Signed-off-by: Anton Nayshtut 
---
 net/ipv6/exthdrs_offload.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/exthdrs_offload.c b/net/ipv6/exthdrs_offload.c
index cf77f3a..447a7fb 100644
--- a/net/ipv6/exthdrs_offload.c
+++ b/net/ipv6/exthdrs_offload.c
@@ -25,11 +25,11 @@ int __init ipv6_exthdrs_offload_init(void)
int ret;
 
ret = inet6_add_offload(_offload, IPPROTO_ROUTING);
-   if (!ret)
+   if (ret)
goto out;
 
ret = inet6_add_offload(_offload, IPPROTO_DSTOPTS);
-   if (!ret)
+   if (ret)
goto out_rt;
 
 out:
-- 
1.7.9.5

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


RE: [PATCH 2/4] ACPICA: Introduce new acpi_os_physical_table_add OS callback

2014-03-04 Thread Zheng, Lv
Hi, Thomas

> From: Thomas Renninger [mailto:tr...@suse.de]
> Sent: Tuesday, March 04, 2014 7:55 PM
> 
> On Tuesday, March 04, 2014 12:31:57 AM Zheng, Lv wrote:
> > Hi,  Thomas
> >
> > > From: Thomas Renninger [mailto:tr...@suse.de]
> > > Sent: Monday, March 03, 2014 8:42 PM
> > >
> > > Hi Lv,
> > >
> > > On Monday, March 03, 2014 01:20:31 AM Zheng, Lv wrote:
> > > > Hi, Thomas
> > > >
> > > > I have a patch series that can cleanup the ACPICA table manager, and
> > > > change
> > >
> > > > the acpi_load_table into the following style:
> > > Ok. I suggest that:
> > > 1) If Thomas (Gleixner) or whoever wants to try out or needs it urgently,
> > > he>
> > >can (must) use a recent kernel with my patches applied.
> > >
> > > 2) You continue to get your changes into ACPICA.
> > >
> > >Eventually or best would be if you add whatever is needed to
> > >allow adding of tables as well (which will be there automatically if
> > >I understood the description of your changes correctly).
> > >
> > > 3) Either you give it a try yourself or give me short description for
> > >
> > >what I have to look out for and I can re-post the Linux patches
> > >based on your ACPICA changes, once they show up in the Linux kernel.
> > >Best give me a ping as soon as I should look at it.
> >
> > That sounds good.
> >
> > Or it can be more efficient for productions:
> > Linux can merge your patches and ACPICA just stop to take them.
> You mean add my stuff to drivers/acpi/acpica in Linux kernel without
> pushing them into the ACPICA repository?
> 
> I cannot remember that this ever happened (beside small important fixes)
> and I doubt Rafael is willing to do that.
> If it would be super critical, but I cannot see that it is.

OK.

> > This will leave us divergences.
> Yes, that would be bad.

Yes.

> > After the table manager cleanups are tested and shipped in the ACPICA repo,
> > the new facilities will automatically be rolled into Linux branches.
> I'd suggest to just wait for that.
> Best already try to integrate the ACPI table override/add part as you think
> it should work without additional changes in drivers/acpi/acpica.
> 
> If this happened and things are submitted to get integrated into the Linux
> kernel, please add me to CC or point me to the patchset.

Fortunately, there is a kernel bugzilla entry requires this series.
I've posted it on the kernel bugzilla.
Here is the patchset:
https://bugzilla.kernel.org/show_bug.cgi?id=69711
You need to apply 9 patches:
attachment 128061 - attachment 128141
The last patch has introduced an early boot API:
acpi_install_table.
This can be used to enhance this series.

> > Then I
> > can help to reduce the divergences using the new ACPICA facilities. At that
> > time I may ask whoever that can test to offer help to review the cleanup
> > patch.
> 
> I can then give your new patcheset some testing and try to get the Linux
> (drivers/acpi/osl.c) parts (re-)implemented based on your stuff.
> There might still be the one or other minor fix needed that has to go
> into acpica as well, but that should not be that hard to manage and
> might end up in acpica and Linux kernel in parallel without much
> extra overhead.

If you found any issues in using this series, let me know.

Thanks and best regards
-Lv

> 
>  Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add option to build with -O3

2014-03-04 Thread Jon Ringle


On Wed, 5 Mar 2014, Greg KH wrote:

> On Wed, Mar 05, 2014 at 12:37:56AM -0500, Jon Ringle wrote:
> > The information contained in this transmission may contain confidential 
> > information.  If the reader of this message is not the intended recipient, 
> > you are hereby notified that any review, dissemination, distribution or 
> > duplication of this communication is strictly prohibited.  If you are not 
> > the intended recipient, please contact the sender by reply email and 
> > destroy all copies of the original message.
>
> Because of this footer, I must destroy this message, kernel development
> is not confidental.
>

Obviously, this is a footer that is not added by me, but rather the mail
server I am sending this message through. Besides, the footer indates it
"may contain confidential information". The key word being *may*. Of
course kernel development is never confidential and the content of any
transmission done to the lkml is of public record. You and anyone who
cares to read/comment this message on lkml is indeed the inteded
recipient, therefore there is no need to destroy this message :)

I sure hope your response was just in jest :)

Jon

The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ARM: dts: imx6qdl-sabresd.dtsi: Add heartbeat led

2014-03-04 Thread Shawn Guo
On Tue, Mar 04, 2014 at 03:34:45PM +0100, Vincent Stehlé wrote:
> Use the red gpio led for heartbeat.

Some people think it's annoying to have a LED blinking all the time.
Since it's a user defined LED, let's leave it to users for their
particular use case.

Shawn

> 
> Signed-off-by: Vincent Stehlé 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> ---
> 
> Hi,
> 
> This has been tested on Sabre SD i.MX6 Quad board, with linux v3.14-rc5+ and
> imx_v6_v7_defconfig.
> 
> As a side note, checkpatch.pl complains about gpio-leds being undocumented, 
> but
> I am not sure what to do about that.
> 
> Best regards,
> 
> V.
> 
>  arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi 
> b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> index e75e11b..cf4d736 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -88,6 +88,16 @@
>   default-brightness-level = <7>;
>   status = "okay";
>   };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + heartbeat-led {
> + label = "Heartbeat";
> + gpios = < 2 0>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
>  };
>  
>   {
> @@ -182,6 +192,7 @@
>   MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x8000
>   MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x8000
>   MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x8000
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x8000
>   >;
>   };
>   };
> -- 
> 1.9.0
> 
> 

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


Re: [PATCH v2 RESEND 1/2] mtd: Add a retlen parameter to _get_{fact,user}_prot_info

2014-03-04 Thread Brian Norris
On Tue, Jan 28, 2014 at 09:29:44AM +0100, Christian Riesch wrote:
> Signed-off-by: Christian Riesch 
> Cc: Artem Bityutskiy 
> Cc: Brian Norris 
> ---
>  drivers/mtd/chips/cfi_cmdset_0001.c |   31 +--
>  drivers/mtd/devices/mtd_dataflash.c |7 ---
>  drivers/mtd/mtdchar.c   |   11 ++-
>  drivers/mtd/mtdcore.c   |   12 ++--
>  drivers/mtd/mtdpart.c   |   14 --
>  drivers/mtd/onenand/onenand_base.c  |   30 --
>  include/linux/mtd/mtd.h |   16 
>  7 files changed, 57 insertions(+), 64 deletions(-)

Pushed patch 1 to l2-mtd.git. I may not push patch 2 yet; let me know if
you see a problem with that.

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


Re: [PATCH] ARM: vf610: add UART choice for low-level debug

2014-03-04 Thread Shawn Guo
On Tue, Mar 04, 2014 at 12:27:09AM +0100, Stefan Agner wrote:
> Add choice for low-level debug UART. Similar to i.MX6, there is a
> numeric configuration, valid choices are 0 to 3.
> Not that the kernel assumes that the boot loader initialized clock
> properly.
> 
> Signed-off-by: Stefan Agner 
> ---
>  arch/arm/Kconfig.debug  |  9 +
>  arch/arm/include/debug/vf.S | 16 ++--
>  2 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index 0531da8..c2005a7 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -946,6 +946,15 @@ config DEBUG_IMX_UART_PORT
> Choose UART port on which kernel low-level debug messages
> should be output.
>  
> +config DEBUG_VF_UART_PORT
> + int "Vybrid Debug UART Port Selection" if DEBUG_VF_UART
> + default 1
> + range 0 3
> + depends on SOC_VF610
> + help
> +   Choose UART port on which kernel low-level debug messages
> +   should be output.
> +
>  config DEBUG_TEGRA_UART
>   bool
>   depends on ARCH_TEGRA
> diff --git a/arch/arm/include/debug/vf.S b/arch/arm/include/debug/vf.S
> index ba12cc4..4683b7c 100644
> --- a/arch/arm/include/debug/vf.S
> +++ b/arch/arm/include/debug/vf.S
> @@ -7,9 +7,21 @@
>   *
>   */
>  
> +#define VF_UART0_BASE_ADDR   0x40027000
> +#define VF_UART1_BASE_ADDR   0x40028000
> +#define VF_UART2_BASE_ADDR   0x40029000
> +#define VF_UART3_BASE_ADDR   0x4002a000
> +#define VF_UART_BASE_ADDR(n) VF_UART##n##_BASE_ADDR
> +#define VF_UART_BASE(n)  VF_UART_BASE_ADDR(n)
> +#define VF_UART_PHYSICAL_BASEVF_UART_BASE(CONFIG_DEBUG_VF_UART_PORT)
> +
> +#define VF_UART_VIRTUAL_BASE 0xfe00
> +
> +

One new line is good enough.

>   .macro  addruart, rp, rv, tmp
> - ldr \rp, =0x40028000@ physical
> - ldr \rv, =0xfe028000@ virtual
> + ldr \rp, =(VF_UART_PHYSICAL_BASE)   @ physical

The parentheses is unnecessary.

Shawn

> + and \rv, \rp, #0xff @ offset within 16MB section
> + add \rv, \rv, #VF_UART_VIRTUAL_BASE
>   .endm
>  
>   .macro  senduart, rd, rx
> -- 
> 1.9.0
> 

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


Re: [PATCH] Add option to build with -O3

2014-03-04 Thread Greg KH
On Wed, Mar 05, 2014 at 12:37:56AM -0500, Jon Ringle wrote:
> The information contained in this transmission may contain confidential 
> information.  If the reader of this message is not the intended recipient, 
> you are hereby notified that any review, dissemination, distribution or 
> duplication of this communication is strictly prohibited.  If you are not the 
> intended recipient, please contact the sender by reply email and destroy all 
> copies of the original message.

Because of this footer, I must destroy this message, kernel development
is not confidental.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: How to get rid of IRQF_DISABLED for good?

2014-03-04 Thread Michael Opdenacker
Hi Levente,

Thank you for your good advise!

On 02/20/2014 07:17 PM, Levente Kurusa wrote:
> 2014-02-20 18:44 GMT+01:00 Michael Opdenacker
> :
>> Hi,
>>
>> In spite of the patches I have been sending (and resending!) over the
>> past months, there are still 118 occurrences of the idle IRQF_DISABLED
>> flag in the kernel code. This corresponds to 31 patches which haven't
>> been accepted yet.
>>
>> What would you advise to get rid of IRQF_DISABLED for good?
>>
>>   * Send a treewide patch removing the last occurrences in one shot,
>> bypassing the regular maintainers? Who could take it?
> Andrew Morton would take it to his -mm tree.
> This, IMO, seems to be the best solution to circumvent unresponsive/uncaring
> maintainers.
>
>>   * Remove the definition of IRQF_DISABLED to force the individual
>> maintainers (and out of tree drivers!) to update their code? It
>> could be a way of seeing which code isn't maintained any more ;)
> No, every single patch has to be 'bisectable' meaning that when you bisect
> you should be able to build every single patch as is.
>
>>   * Continue to resend the patches for a few more cycles, until the
>> corresponding maintainers can no longer bear the discredit?
> Maybe once more, if they don't reply, send it to Andrew Morton as well
> and CC a few people who know your work is good so that they can ACK it.
I sent my patches once more, and will see which ones remain. Then I will
send the changes to Andrew Morton as you suggested.

Thanks again!

Cheers,

Michael.

-- 
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098

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


Re: [PATCH net-next] hyperv: Move state setting for link query

2014-03-04 Thread Jason Wang
On 03/05/2014 12:57 AM, Haiyang Zhang wrote:
>
>> -Original Message-
>> From: Jason Wang [mailto:jasow...@redhat.com]
>> Sent: Monday, March 3, 2014 10:10 PM
>> To: Haiyang Zhang; da...@davemloft.net; net...@vger.kernel.org
>> Cc: KY Srinivasan; o...@aepfle.de; linux-kernel@vger.kernel.org; driverdev-
>> de...@linuxdriverproject.org
>> Subject: Re: [PATCH net-next] hyperv: Move state setting for link query
>>
>> On 03/04/2014 07:54 AM, Haiyang Zhang wrote:
>>> It moves the state setting for query into rndis_filter_receive_response().
>>> All callbacks including query-complete and status-callback are
>>> synchronized by channel->inbound_lock. This prevents pentential race
>> between them.
>>
>> This still looks racy to me. The problem is workqueue is not synchronized 
>> with
>> those here.
>>
>> Consider the following case in netvsc_link_change():
>>
>> if (rdev->link_state) {
>> ... receive interrupt ...
>> rndis_filter_receice_response() which changes rdev->link_state
>> ...
>> netif_carrier_off()
>> }
>>
>> And also it need to schedule a work otherwise the link status is out of sync.
> The rndis_filter_query_device_link_status() makes the query and wait for the
> complete message, including set state, before returning.
>
> The rndis_filter_query_device_link_status() is called from 
> rndis_filter_device_add(),
> which is called from either netvsc_change_mtu() or netvsc_probe().
>
> The change_mtu() and netvsc_link_change() are synchronized by rtnl_lock().
> In netvsc_probe(), the status query & complete happens before 
> register_netdev(), and
> the netvsc_linkstatus_callback() schedules the work only after netdevice is 
> registered.
> So, there are no race in either case.
>
> The carrier_on/off work will be scheduled when netvsc_open() is called. Then,
> the status will be updated based on the latest link_state.
>
> Thanks,
> - Haiyang
>

I see. Then if the link status is changing during mtu changing in guest.
Looks like we may miss a link status updating?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] [RESEND][TRIVIAL] treewide: fix occurrences of "the the "

2014-03-04 Thread Michael Opdenacker
On 03/05/2014 06:52 AM, Michael Opdenacker wrote:
> Fix all occurrences of "the the " in the source code,
> comments and documentation.
>
> The replacement couldn't be automated because sometimes
> the first "the" was meant to be another word.
>
> Example: "according the the"
> meaning: "according to the"
>
> Note that I sometimes took the opportunity to fix
> other spelling issues or typos in the same sentences.
> I also fixed a few checkpatch errors in the same
> lines.
>
> Signed-off-by: Michael Opdenacker 
> ---
>  Documentation/ABI/testing/sysfs-devices-memory | 2 +-
>  Documentation/DocBook/media/v4l/controls.xml   | 2 +-
>  Documentation/DocBook/media/v4l/vidioc-g-parm.xml  | 2 +-
>  Documentation/devicetree/bindings/arm/msm/timer.txt| 2 +-
>  Documentation/devicetree/bindings/ata/cavium-compact-flash.txt | 2 +-
>  Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt| 2 +-
>  Documentation/devicetree/bindings/mtd/fsmc-nand.txt| 2 +-
>  Documentation/filesystems/autofs4-mount-control.txt| 6 +++---
>  Documentation/futex-requeue-pi.txt | 2 +-
>  Documentation/input/multi-touch-protocol.txt   | 2 +-
>  Documentation/kmemcheck.txt| 2 +-
>  Documentation/memory-barriers.txt  | 2 +-
>  Documentation/networking/spider_net.txt| 2 +-
>  Documentation/phy.txt  | 2 +-
>  Documentation/power/devices.txt| 2 +-
>  Documentation/security/Smack.txt   | 2 +-
>  Documentation/trace/ring-buffer-design.txt | 2 +-
>  Documentation/usb/WUSB-Design-overview.txt | 2 +-
>  Documentation/virtual/kvm/api.txt  | 2 +-
>  Documentation/vm/unevictable-lru.txt   | 2 +-
>  arch/arm/Kconfig   | 2 +-
>  arch/arm/include/asm/unwind.h  | 2 +-
>  arch/arm/mach-omap2/omap_hwmod.c   | 6 +++---
>  arch/arm/mach-pxa/stargate2.c  | 2 +-
>  arch/blackfin/mach-common/entry.S  | 2 +-
>  arch/c6x/platforms/cache.c | 2 +-
>  arch/ia64/include/asm/spinlock.h   | 2 +-
>  arch/ia64/include/asm/uv/uv_hub.h  | 2 +-
>  arch/m68k/platform/coldfire/intc-2.c   | 2 +-
>  arch/metag/kernel/process.c| 2 +-
>  arch/microblaze/kernel/entry.S | 2 +-
>  arch/mips/alchemy/devboards/pm.c   | 2 +-
>  arch/mips/include/asm/octeon/cvmx-pip.h| 2 +-
>  arch/mips/include/asm/spinlock.h   | 2 +-
>  arch/mips/kernel/smtc.c| 2 +-
>  arch/mips/kvm/kvm_mips.c   | 2 +-
>  arch/mips/mm/c-octeon.c| 4 ++--
>  arch/mips/netlogic/xlr/fmn.c   | 2 +-
>  arch/powerpc/include/asm/cache.h   | 2 +-
>  arch/powerpc/include/asm/epapr_hcalls.h| 2 +-
>  arch/powerpc/include/asm/hw_breakpoint.h   | 2 +-
>  arch/powerpc/kernel/head_64.S  | 2 +-
>  arch/powerpc/mm/gup.c  | 2 +-
>  arch/powerpc/mm/hugetlbpage.c  | 2 +-
>  arch/powerpc/platforms/52xx/mpc52xx_gpt.c  | 2 +-
>  arch/powerpc/platforms/chrp/setup.c| 2 +-
>  arch/powerpc/platforms/powernv/pci-ioda.c  | 2 +-
>  arch/s390/kernel/perf_cpum_sf.c| 2 +-
>  arch/s390/mm/gup.c | 2 +-
>  arch/sparc/kernel/pci.c| 2 +-
>  arch/sparc/mm/gup.c| 2 +-
>  arch/tile/include/asm/irqflags.h   | 2 +-
>  arch/tile/include/gxio/trio.h  | 2 +-
>  arch/tile/kernel/single_step.c | 2 +-
>  arch/x86/include/asm/spinlock.h| 2 +-
>  arch/x86/include/asm/uv/uv_hub.h   | 2 +-
>  arch/x86/kvm/x86.c | 2 +-
>  arch/x86/mm/gup.c  | 4 ++--
>  arch/x86/xen/setup.c   | 2 +-
>  arch/xtensa/include/asm/initialize_mmu.h   | 2 +-
>  arch/xtensa/kernel/entry.S | 4 ++--
>  

Re: [PATCH V3] support Thinkpad X1 Carbon 2nd generation's adaptive keyboard

2014-03-04 Thread SeongJae Park
Hello,
This is just a trivial comment.


On Tue, Mar 4, 2014 at 8:13 PM, Shuduo Sang  wrote:
>
>
> Submit patch V3 to support Adaptive Keyboard on Thinkpad X1 Carbon 2nd
> generation according to Tobias's comments.
>
> Thanks,
> Shuduo
>
> From 2b8175e69deee661d97d371b2422a9c192fefd52 Mon Sep 17 00:00:00 2001
> From: Shuduo Sang 
> Date: Mon, 3 Mar 2014 14:29:32 +0800
> Subject: [PATCH] support thinkpad X1 Carbon's adaptive keyboard
>
> Thinkpad X1 Carbon's adaptive keyboard has five modes including Home
> mode, Web browser mode, Web conference mode, Function mode and Lay-flat
> mode. We support Home mode and Function mode currently.
>
> Signed-off-by: Bruce Ma 
> Signed-off-by: Shuduo Sang 
> ---
>  drivers/platform/x86/thinkpad_acpi.c | 102
> +++
>  1 file changed, 102 insertions(+)
>
> diff --git a/drivers/platform/x86/thinkpad_acpi.c
> b/drivers/platform/x86/thinkpad_acpi.c
> index defb6af..6664dcd 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -3437,6 +3437,106 @@ err_exit:
> return (res < 0)? res : 1;
>  }
>
> +/* Thinkpad X1 Carbon support 5 modes including Home mode, Web browser
> + * mode, Web conference mode, Function mode and Lay-flat mode.
> + * We support Home mode and Function mode currently.
> + *
> + * Will consider support rest of modes in future.
> + *
> + */
> +enum ADAPTIVE_KEY_MODE {
> +   HOME_MODE,
> +   WEB_BROWSER_MODE,
> +   WEB_CONFERENCE_MODE,
> +   FUNCTION_MODE,
> +   LAYFLAT_MODE
> +};
> +
> +int adaptive_keyboard_modes[] = {
> +   HOME_MODE,
> +/* WEB_BROWSER_MODE = 2,
> +   WEB_CONFERENCE_MODE = 3, */
> +   FUNCTION_MODE
> +};
> +
> +#define DFR_CHANGE_ROW 0x101
> +#define DFR_SHOW_QUICKVIEW_ROW 0x102
> +
> +/* press Fn key a while second, it will switch to Function Mode. Then
> + * release Fn key, previous mode be restored.
> + */
> +static bool adaptive_keyboard_mode_is_saved;
> +static int adaptive_keyboard_prev_mode;
> +
> +static int adaptive_keyboard_get_next_mode(int mode)
> +{
> +   int i;
> +   size_t max_mode = ARRAY_SIZE(adaptive_keyboard_modes) - 1;
> +
> +   for (i = 0; i <= max_mode; i++) {
> +   if (adaptive_keyboard_modes[i] == mode)
> +   break;
> +   }
> +
> +   if (i >= max_mode)
> +   i = 0;
> +   else
> +   i++;
> +
> +   return adaptive_keyboard_modes[i];
> +}
> +
> +static bool adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
> +{
> +   u32 current_mode = 0;
> +   int new_mode = 0;
> +
> +   switch (scancode) {
> +   case DFR_CHANGE_ROW:
> +   if (adaptive_keyboard_mode_is_saved) {
> +   new_mode = adaptive_keyboard_prev_mode;
> +   adaptive_keyboard_mode_is_saved = false;
> +   } else {
> +   if (!acpi_evalf(
> +   hkey_handle, _mode,
> +   "GTRW", "dd", 0)) {
> +   pr_err("Cannot read adaptive keyboard 
> mode\n");
> +   return false;
> +   } else {
> +   new_mode = adaptive_keyboard_get_next_mode(
> +   current_mode);
> +   }
> +   }
> +
> +   if (!acpi_evalf(hkey_handle, NULL, "STRW", "vd", new_mode)) {
> +   pr_err("Cannot set adaptive keyboard mode\n");
> +   return false;
> +   }
> +
> +   return true;

Isn't the blank line above return statement unnecessary?

> +
> +   case DFR_SHOW_QUICKVIEW_ROW:
> +   if (!acpi_evalf(hkey_handle,
> +   _keyboard_prev_mode,
> +   "GTRW", "dd", 0)) {
> +   pr_err("Cannot read adaptive keyboard mode\n");
> +   return false;
> +   } else {
> +   adaptive_keyboard_mode_is_saved = true;
> +
> +   if (!acpi_evalf(hkey_handle,
> +   NULL, "STRW", "vd", FUNCTION_MODE)) {
> +   pr_err("Cannot set adaptive keyboard mode\n");
> +   return false;
> +   }
> +   }
> +   return true;
> +
> +   default:
> +   return false;
> +   }
> +}
> +
>  static bool hotkey_notify_hotkey(const u32 hkey,
>  bool *send_acpi_ev,
>  bool *ignore_acpi_ev)
> @@ -3456,6 +3556,8 @@ static bool hotkey_notify_hotkey(const u32 hkey,
> *ignore_acpi_ev = true;
> }
> return true;
> +   } else {
> +   return 

Re: [PATCH -mm 00/12] kmemcg reparenting

2014-03-04 Thread Vladimir Davydov
On 03/04/2014 07:21 PM, Michal Hocko wrote:
> On Tue 04-03-14 18:56:06, Vladimir Davydov wrote:
>> Hi Johannes, Michal
>>
>> Could you please take a look at this set when you have time?
> I plan to catch up with others as well. I was on vacation last week and
> now catching up with other stuff. I do understand that this review
> "speed" might be really frustrating for you but there is a lot of things
> on my agenda now (and last few weeks). Sorry about that.

Never mind. I just want to be sure you haven't missed that.

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


Re: [PATCH] blackfin: bf537: fix typo "CONFIG_SND_SOC_ADV80X_MODULE"

2014-03-04 Thread Steven Miao
Hi Paul,

On Sat, Mar 1, 2014 at 5:13 AM, Paul Bolle  wrote:
> Steven,
>
> On Wed, 2014-02-26 at 18:35 +0800, Steven Miao wrote:
>> On Thu, Feb 13, 2014 at 5:40 PM, Paul Bolle  wrote:
>> >> 1) There are many lines that might be converted to IS_ENABLED() in this
>> >> file. I'm not sure if and how that should be done.
>> Sorry for the late reply. There are many CONFIG_xxx ||
>> CONFIG_xxx_MODULE things, we need a cleanup for it under all the
>> stamp.c and ezkit.c.
>
> Should I draft a patch to do that? And should that patch include this
> patch, or is this patch finally getting pushed (after some testing, that
> is)?
Yes, sure you can, and I will test your patch.
>
> Thanks,
>
>
> Paul Bolle
>
-steven
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Add option to build with -O3

2014-03-04 Thread Jon Ringle


On Wed, 5 Mar 2014, Greg KH wrote:

> On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
> > +config CC_OPTIMIZE_FOR_SPEED
> > +bool "Optimze for speed (-O3)"
> > +help
> > +  Enabling this option will pass "-O3" to gcc
> > +  resulting in a larger kernel (but possibly faster)
>
> Are you sure about that?  Have you measured it?

I do know that there is an improvement performance-wise for my particular
use-case.

My target is an ARM board being built with gcc-4.8.2. My board has on it a
sc16is740 that is used as an RS-485 port. The sc16is740 is on the i2c bus,
so when an interrupt comes in to indicate that there is data available to
be read, I need to get the data over the i2c bus. I do this on a kthread
to do this work. The i2c transactions (using i2c-davinci driver) are also
interrupt driven. I was seeing a lot of lost packets when receiving data
at only 19200. Adding the -O3 compile option helped in this regard in that
I am now rarely seeing packet loss.

Jon

The information contained in this transmission may contain confidential 
information.  If the reader of this message is not the intended recipient, you 
are hereby notified that any review, dissemination, distribution or duplication 
of this communication is strictly prohibited.  If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies of 
the original message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] [RESEND] [SCSI] misc drivers: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
in several drivers in drivers/scsi/

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/dtc.c| 2 +-
 drivers/scsi/esas2r/esas2r_init.c | 2 +-
 drivers/scsi/g_NCR5380.c  | 2 +-
 drivers/scsi/gdth.c   | 6 +++---
 drivers/scsi/in2000.c | 2 +-
 drivers/scsi/initio.c | 2 +-
 drivers/scsi/pas16.c  | 2 +-
 drivers/scsi/pm8001/pm8001_init.c | 2 --
 drivers/scsi/t128.c   | 2 +-
 9 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index d01f01604140..eb29fe7eaf49 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -277,7 +277,7 @@ found:
/* With interrupts enabled, it will sometimes hang when doing 
heavy
 * reads. So better not enable them until I finger it out. */
if (instance->irq != SCSI_IRQ_NONE)
-   if (request_irq(instance->irq, dtc_intr, IRQF_DISABLED,
+   if (request_irq(instance->irq, dtc_intr, 0,
"dtc", instance)) {
printk(KERN_ERR "scsi%d : IRQ%d not free, 
interrupts disabled\n", instance->host_no, instance->irq);
instance->irq = SCSI_IRQ_NONE;
diff --git a/drivers/scsi/esas2r/esas2r_init.c 
b/drivers/scsi/esas2r/esas2r_init.c
index b9750e296d71..6776931e25d4 100644
--- a/drivers/scsi/esas2r/esas2r_init.c
+++ b/drivers/scsi/esas2r/esas2r_init.c
@@ -231,7 +231,7 @@ use_legacy_interrupts:
 
 static void esas2r_claim_interrupts(struct esas2r_adapter *a)
 {
-   unsigned long flags = IRQF_DISABLED;
+   unsigned long flags = 0;
 
if (a->intr_mode == INTR_MODE_LEGACY)
flags |= IRQF_SHARED;
diff --git a/drivers/scsi/g_NCR5380.c b/drivers/scsi/g_NCR5380.c
index 5cec6c60ca22..7176365e916b 100644
--- a/drivers/scsi/g_NCR5380.c
+++ b/drivers/scsi/g_NCR5380.c
@@ -461,7 +461,7 @@ int __init generic_NCR5380_detect(struct scsi_host_template 
* tpnt)
 
if (instance->irq != SCSI_IRQ_NONE)
if (request_irq(instance->irq, generic_NCR5380_intr,
-   IRQF_DISABLED, "NCR5380", instance)) {
+   0, "NCR5380", instance)) {
printk(KERN_WARNING "scsi%d : IRQ%d not free, 
interrupts disabled\n", instance->host_no, instance->irq);
instance->irq = SCSI_IRQ_NONE;
}
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index ce5ef0190bad..0f1ae13ce7c7 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -4711,7 +4711,7 @@ static int __init gdth_isa_probe_one(u32 isa_bios)
printk("Configuring GDT-ISA HA at BIOS 0x%05X IRQ %u DRQ %u\n",
isa_bios, ha->irq, ha->drq);
 
-   error = request_irq(ha->irq, gdth_interrupt, IRQF_DISABLED, "gdth", ha);
+   error = request_irq(ha->irq, gdth_interrupt, 0, "gdth", ha);
if (error) {
printk("GDT-ISA: Unable to allocate IRQ\n");
goto out_host_put;
@@ -4843,7 +4843,7 @@ static int __init gdth_eisa_probe_one(u16 eisa_slot)
printk("Configuring GDT-EISA HA at Slot %d IRQ %u\n",
eisa_slot >> 12, ha->irq);
 
-   error = request_irq(ha->irq, gdth_interrupt, IRQF_DISABLED, "gdth", ha);
+   error = request_irq(ha->irq, gdth_interrupt, 0, "gdth", ha);
if (error) {
printk("GDT-EISA: Unable to allocate IRQ\n");
goto out_host_put;
@@ -4979,7 +4979,7 @@ static int gdth_pci_probe_one(gdth_pci_str *pcistr, 
gdth_ha_str **ha_out)
ha->irq);
 
error = request_irq(ha->irq, gdth_interrupt,
-   IRQF_DISABLED|IRQF_SHARED, "gdth", ha);
+   IRQF_SHARED, "gdth", ha);
if (error) {
printk("GDT-PCI: Unable to allocate IRQ\n");
goto out_host_put;
diff --git a/drivers/scsi/in2000.c b/drivers/scsi/in2000.c
index bf028218ac36..b1c4d831137d 100644
--- a/drivers/scsi/in2000.c
+++ b/drivers/scsi/in2000.c
@@ -2015,7 +2015,7 @@ static int __init in2000_detect(struct scsi_host_template 
* tpnt)
write1_io(0, IO_FIFO_READ); /* start fifo out in read mode 
*/
write1_io(0, IO_INTR_MASK); /* allow all ints */
x = int_tab[(switches & (SW_INT0 | SW_INT1)) >> SW_INT_SHIFT];
-   if (request_irq(x, in2000_intr, IRQF_DISABLED, "in2000", 
instance)) {
+   if (request_irq(x, in2000_intr, 0, "in2000", instance)) {
printk("in2000_detect: Unable to allocate IRQ.\n");
detect_count--;
continue;
diff --git a/drivers/scsi/initio.c b/drivers/scsi/initio.c
index 

[PATCH] [RESEND] MAINTAINERS: blackfin: add git repository

2014-03-04 Thread Michael Opdenacker
Add the git repository currently in use for
blackfin architecture development.

This information was obtained from Steven Miao.

Signed-off-by: Michael Opdenacker 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c6d0e93eff62..d00f5ae83236 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1737,6 +1737,7 @@ F:include/uapi/linux/bfs_fs.h
 BLACKFIN ARCHITECTURE
 M: Steven Miao 
 L: adi-buildroot-de...@lists.sourceforge.net
+T: git git://git.code.sf.net/p/adi-linux/code
 W: http://blackfin.uclinux.org
 S: Supported
 F: arch/blackfin/
-- 
1.8.3.2

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


Re: How could we get rid of saved_max_pfn for calgary iommu?

2014-03-04 Thread WANG Chao
[ Add Muli, I find his new email in git log]

Hi, Muli

saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
could get rid of saved_max_pfn at all. But If this can't work, how about
exporting a calgary tce table size to user space, so that kexec-tools
can simply pass calgary=xxx cmdline to 2nd kernel.

What do you think of this problem?

BTW MAINTAINERS file still uses your old email, please update
accordingly.

Thanks
WANG Chao

On 02/19/14 at 02:18pm, WANG Chao wrote:
> Hi, All
> 
> arch/x86/kernel/pci-calgary.c is the only user of saved_max_pfn today:
> 
> int __init detect_calgary(void)
> {
>   [..]
>   specified_table_size = determine_tce_table_size((is_kdump_kernel() ?
>   saved_max_pfn : max_pfn) * PAGE_SIZE);
>   [..]
> }
> 
> saved_max_pfn is the real mem size and is calculated by 1st kernel E820
> memmap which is passed in by 2nd kernel's boot_params (done by kexec):
> 
>   saved_max_pfn = e820_end_of_ram_pfn();
> 
> After saved_max_pfn has been set, memmap=exactmap will reset the E820
> provided by boot_params and use the user defined E820 instead.
> 
> Now we want to get rid of memmap=exactmap and directly pass the E820
> memmap by boot_params for some reason (eg. exactmap may exceed the cmdline
> size and also isn't compatible with kaslr).
> 
> However saved_max_pfn becomes the obstacle for obsoleting exactmap.
> Because it needs two conditions: first kernel's E820 map and
> memmap=exactmap cmdline.
> 
> So I'm wondering if it's possible to get rid of saved_max_pfn totally in
> calgary code. Or we can get saved_max_pfn using a different way, for
> example calculated in 1st kernel and passed in to 2nd kernel by cmdline.
> 
> Thanks
> WANG Chao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH v2 1/2] Staging: comedi: introduce {outl,inl}_amcc() and {outl,inl}_iobase() helper functions in hwdrv_apci1564.c

2014-03-04 Thread Chase Southwood
>On Tuesday, March 4, 2014 6:38 PM, Greg KH  wrote:

>>On Mon, Mar 03, 2014 at 12:27:55PM +0300, Dan Carpenter wrote:
>>> On Sun, Mar 02, 2014 at 08:52:19PM -0600, Chase Southwood wrote:
>>> This patch introduces a few simple outl and inl helper functions to allow
>>> several lines which violate the character limit to be shortened
>>> appropriately.  It also changes a few macro values which represented
>>> offset values from a single unique base value to instead represent the value
>>> of that base plus the offset.  This is to simplify the use of these macros
>>> in the new helper functions.
>>> 
>>> Cc: Dan Carpenter 
>>> Signed-off-by: Chase Southwood 
>>> ---
>>> 
>>> All right, here's another shot at this.  Dan, I took your outl_amcc idea
>>> and did a version for the outl/inl calls based from devpriv->iobase as well.
>>> I changed all of the macros which only offset from one base value as you
>>> had mentioned as well, and the result is starting to look very good.
>>> The only outl/inl calls which still look a little gross (see PATCH v2 2/2) 
>>> are
>>> the ones involving DIGITAL_OP_WATCHDOG, TIMER, or any of the COUNTER macros,
>>> just because they use a common set of offset macros so simplifying
>>> those calls in the same way as the rest isn't possible.  What are your
>>> thoughts on this version of the patchset?
>>> 
>>> This is version 2 of [PATCH 1/2] Staging: comedi: introduce outl_1564_* and
>>> inl_1564_* helper functions in hwdrv_apci1564.c
>>> 
>>> 2: Changed helper functions from {outl,inl}_1564_*() to
>>> {outl,inl}_{amcc,iobase}()
>>> 
>>> Comments welcome!
>>> 
>>>  .../comedi/drivers/addi-data/hwdrv_apci1564.c      | 38 
>>>+-
>>>  1 file changed, 30 insertions(+), 8 deletions(-)
>>> 
>>> diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
>>> b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
>>> index 2b47fa1..58e301d 100644
>>> --- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
>>> +++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
>>> @@ -49,25 +49,25 @@ This program is distributed in the hope that it will be 
>>> useful, but WITHOUT ANY
>>>  /* DIGITAL INPUT-OUTPUT DEFINE */
>>>  /* Input defines */
>>>  #define APCI1564_DIGITAL_IP                0x04
>>> -#define APCI1564_DIGITAL_IP_INTERRUPT_MODE1        4
>>> -#define APCI1564_DIGITAL_IP_INTERRUPT_MODE2        8
>>> -#define APCI1564_DIGITAL_IP_IRQ                16
>>> +#define APCI1564_DIGITAL_IP_INTERRUPT_MODE1        (0x04 + 0x04)
>>> +#define APCI1564_DIGITAL_IP_INTERRUPT_MODE2        (0x04 + 0x08)
>>> +#define APCI1564_DIGITAL_IP_IRQ                (0x04 + 0x10)
>> 
>> You can't change these without changing the callers.  This bit needs to
>> be in patch 2/2.  You should probably just merge both patches anyway
>> because presumably this one adds some GCC warnings about unused static
>> functions.>
>
>I'm totally confused about this series...
>
>Chase, can you resend any outstanding patches that I haven't applied of
>yours, as these different revisions and threads don't make much sense
>right now.
>

Greg,
Yes, admittedly this whole thing has gotten a little messy :P sorry for all the 
confusion.
I've finally spoken with Hartley about how to best clean this driver, and so I 
will submit
a final patchset to you as soon as I finish up with it.  Until then, please 
just disregard
all prior patches to hwdrv_apci1564.c from me, as the one I send next will 
supersede all of them
and I will clearly mark it as such for you.

Thanks,
Chase

>
>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: RCU stalls when running out of memory on 3.14-rc4 w/ NFS and kernel threads priorities changed

2014-03-04 Thread Paul E. McKenney
On Tue, Mar 04, 2014 at 07:55:03PM -0800, Florian Fainelli wrote:
> 2014-03-04 17:43 GMT-08:00 Paul E. McKenney :
> > On Tue, Mar 04, 2014 at 05:16:27PM -0800, Florian Fainelli wrote:
> >> 2014-03-04 17:03 GMT-08:00 Florian Fainelli :
> >> > 2014-03-04 16:48 GMT-08:00 Eric Dumazet :
> >> >> On Tue, 2014-03-04 at 15:55 -0800, Florian Fainelli wrote:
> >> >>> Hi all,
> >> >>>
> >> >>> I am seeing the following RCU stalls messages appearing on an ARMv7
> >> >>> 4xCPUs system running 3.14-rc4:
> >> >>>
> >> >>> [   42.974327] INFO: rcu_sched detected stalls on CPUs/tasks:
> >> >>> [   42.979839]  (detected by 0, t=2102 jiffies, g=4294967082,
> >> >>> c=4294967081, q=516)
> >> >>> [   42.987169] INFO: Stall ended before state dump start
> >> >>>
> >> >>> this is happening under the following conditions:
> >> >>>
> >> >>> - the attached bumper.c binary alters various kernel thread priorities
> >> >>> based on the contents of bumpup.cfg and
> >> >>> - malloc_crazy is running from a NFS share
> >> >>> - malloc_crazy.c is running in a loop allocating chunks of memory but
> >> >>> never freeing it
> >> >>>
> >> >>> when the priorities are altered, instead of getting the OOM killer to
> >> >>> be invoked, the RCU stalls are happening. Taking NFS out of the
> >> >>> equation does not allow me to reproduce the problem even with the
> >> >>> priorities altered.
> >> >>>
> >> >>> This "problem" seems to have been there for quite a while now since I
> >> >>> was able to get 3.8.13 to trigger that bug as well, with a slightly
> >> >>> more detailed RCU debugging trace which points the finger at kswapd0.
> >> >>>
> >> >>> You should be able to get that reproduced under QEMU with the
> >> >>> Versatile Express platform emulating a Cortex A15 CPU and the attached
> >> >>> files.
> >> >>>
> >> >>> Any help or suggestions would be greatly appreciated. Thanks!
> >> >>
> >> >> Do you have a more complete trace, including stack traces ?
> >> >
> >> > Attatched is what I get out of SysRq-t, which is the only thing I have
> >> > (note that the kernel is built with CONFIG_RCU_CPU_STALL_INFO=y):
> >>
> >> QEMU for Versatile Express w/ 2 CPUs yields something slightly
> >> different than the real HW platform this is happening with, but it
> >> does produce the RCU stall anyway:
> >>
> >> [  125.762946] BUG: soft lockup - CPU#1 stuck for 53s! [malloc_crazy:91]
> >
> > This soft-lockup condition can result in RCU CPU stall warnings.  Fix
> > the problem causing the soft lockup, and I bet that your RCU CPU stall
> > warnings go away.
> 
> I definitively agree, which is why I was asking for help, as I think
> the kernel thread priority change is what is causing the soft lockup
> to appear, but nothing obvious jumps to mind when looking at the
> trace.

Is your hardware able to make the malloc_crazy CPU periodically dump
its stack, perhaps in response to an NMI?  If not, another approach is
to use ftrace -- though this will require a very high-priority task to
turn tracing on and off reasonably quickly, unless you happen to have
a very large amount of storage to hold the trace.

What happens if you malloc() less intensively?  Does that avoid this
problem?  The reason I ask is that you mentioned that avoiding NFS helped,
and it is possible that NFS is increasing storage-access latencies and
thus triggering another problem.  It is quite possible that slowing
down the malloc()s would also help, and might allow you to observe what
is happening more easily than when the system is driven fully to the
lockup condition.

Finally, what are you trying to achieve with this workload?  Does your
production workload behave in this way?  Or is this an experimental
investigation of some sort?

Thanx, Paul

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


[PATCH] [RESEND] [SCSI] wd7000: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
from drivers/scsi/wd7000.c

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/wd7000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/wd7000.c b/drivers/scsi/wd7000.c
index f9a6e4b0affe..32674236fec7 100644
--- a/drivers/scsi/wd7000.c
+++ b/drivers/scsi/wd7000.c
@@ -1252,7 +1252,7 @@ static int wd7000_init(Adapter * host)
return 0;
 
 
-   if (request_irq(host->irq, wd7000_intr, IRQF_DISABLED, "wd7000", host)) 
{
+   if (request_irq(host->irq, wd7000_intr, 0, "wd7000", host)) {
printk("wd7000_init: can't get IRQ %d.\n", host->irq);
return (0);
}
-- 
1.8.3.2

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


RE: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x

2014-03-04 Thread Yang, Wenyou
Hi JC,

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com]
> Sent: Wednesday, March 05, 2014 12:58 PM
> To: Yang, Wenyou
> Cc: Jean-Christophe PLAGNIOL-VILLARD; linus.wall...@linaro.org;
> b.brezil...@overkiz.com;  mailing
> list; Linux Kernel list; devicet...@vger.kernel.org; robh...@kernel.org;
> pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
> ga...@codeaurora.org
> Subject: Re: [PATCH] pinctrl: at91: add the config GPIO_OUTPUT_x
> 
> 
> On Mar 5, 2014, at 9:53 AM, Wenyou Yang  wrote:
> 
> > In order to support the pinctrl sleep state.
> 
> As I said before NACK
> 
> this is not the job of the pinctrl to describe gpio output or input
> state
But according to what said in the section "GPIO mode pitfalls" of 
Documentation/pinctrl.txt.
It should be handle by the pinctrl.

If not, to deal with the sleep state will be very complicated. 
Muxing the pins for FUNCTION to enable peripheral, then twist them over to GPIO 
mode
and use gpio_direction_output() to drive it HIGH or LOW during sleep.

--->8 
The solution is to not think that what the datasheet calls "GPIO mode"
has to be handled by the  interface. Instead view this as
a certain pin config setting. Look in e.g. 
and you find this in the documentation:

  PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
 1 to indicate high level, argument 0 to indicate low level.

So it is perfectly possible to push a pin into "GPIO mode" and drive the
line low as part of the usual pin control map.
---<8 

Best Regards,
Wenyou Yang

> 
> Best Regards,
> J.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> > Hi Linus,
> >
> > The patch is based on branch: for-next
> > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
> >
> > Best Regards,
> > Wenyou Yang
> >
> > drivers/pinctrl/pinctrl-at91.c |   31
> +++
> > include/dt-bindings/pinctrl/at91.h |2 ++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/pinctrl/pinctrl-at91.c
> > b/drivers/pinctrl/pinctrl-at91.c index 5d24aae..fc51e59 100644
> > --- a/drivers/pinctrl/pinctrl-at91.c
> > +++ b/drivers/pinctrl/pinctrl-at91.c
> > @@ -62,6 +62,8 @@ static int gpio_banks;
> > #define DEGLITCH(1 << 2)
> > #define PULL_DOWN   (1 << 3)
> > #define DIS_SCHMIT  (1 << 4)
> > +#define GPIO_OUTPUT_HIGH   (1 << 5)
> > +#define GPIO_OUTPUT_LOW(1 << 6)
> > #define DEBOUNCE(1 << 16)
> > #define DEBOUNCE_VAL_SHIFT  17
> > #define DEBOUNCE_VAL(0x3fff << DEBOUNCE_VAL_SHIFT)
> > @@ -152,12 +154,15 @@ struct at91_pinctrl_mux_ops {
> > void (*set_pulldown)(void __iomem *pio, unsigned mask, bool is_on);
> > bool (*get_schmitt_trig)(void __iomem *pio, unsigned pin);
> > void (*disable_schmitt_trig)(void __iomem *pio, unsigned mask);
> > +   bool (*get_gpio_output)(void __iomem *pio, unsigned mask);
> > +   void (*set_gpio_output)(void __iomem *pio, unsigned mask, bool
> > +is_high);
> > /* irq */
> > int (*irq_type)(struct irq_data *d, unsigned type); };
> >
> > static int gpio_irq_type(struct irq_data *d, unsigned type); static
> > int alt_gpio_irq_type(struct irq_data *d, unsigned type);
> > +static void at91_mux_gpio_enable(void __iomem *pio, unsigned mask,
> > +bool input);
> >
> > struct at91_pinctrl {
> > struct device   *dev;
> > @@ -472,6 +477,20 @@ static bool at91_mux_pio3_get_schmitt_trig(void
> __iomem *pio, unsigned pin)
> > return (__raw_readl(pio + PIO_SCHMITT) >> pin) & 0x1; }
> >
> > +static bool at91_mux_pio3_get_gpio_output(void __iomem *pio, unsigned
> > +pin) {
> > +   return (__raw_readl(pio + PIO_ODSR) >> pin) & 0x1; }
> > +
> > +static void at91_mux_pio3_set_gpio_output(void __iomem *pio,
> > +   unsigned mask,
> > +   bool is_high)
> > +{
> > +   at91_mux_gpio_enable(pio, mask, 0);
> > +   writel_relaxed(mask, pio + (is_high ? PIO_SODR : PIO_CODR)); }
> > +
> > +
> > static struct at91_pinctrl_mux_ops at91rm9200_ops = {
> > .get_periph = at91_mux_get_periph,
> > .mux_A_periph   = at91_mux_set_A_periph,
> > @@ -495,6 +514,8 @@ static struct at91_pinctrl_mux_ops at91sam9x5_ops
> = {
> > .set_pulldown   = at91_mux_pio3_set_pulldown,
> > .get_schmitt_trig = at91_mux_pio3_get_schmitt_trig,
> > .disable_schmitt_trig = at91_mux_pio3_disable_schmitt_trig,
> > +   .get_gpio_output = at91_mux_pio3_get_gpio_output,
> > +   .set_gpio_output = at91_mux_pio3_set_gpio_output,
> > .irq_type   = alt_gpio_irq_type,
> > };
> >
> > @@ -741,6 +762,10 @@ static int at91_pinconf_get(struct pinctrl_dev
> *pctldev,
> > *config |= PULL_DOWN;
> > if (info->ops->get_schmitt_trig && info->ops->get_schmitt_trig(pio,
> pin))
> > *config |= DIS_SCHMIT;
> > +   if (info->ops->get_gpio_output) {
> > +   *config |= info->ops->get_gpio_output(pio, pin) ?
> > +  

[PATCH] [RESEND] [SCSI] u14-34f: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the the use of the IRQF_DISABLED flag
from drivers/scsi/u14-34f.c

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/u14-34f.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/u14-34f.c b/drivers/scsi/u14-34f.c
index 9c216e563568..5a03bb3bcfef 100644
--- a/drivers/scsi/u14-34f.c
+++ b/drivers/scsi/u14-34f.c
@@ -873,7 +873,7 @@ static int port_detect \
 
/* Board detected, allocate its IRQ */
if (request_irq(irq, do_interrupt_handler,
- IRQF_DISABLED | ((subversion == ESA) ? IRQF_SHARED : 0),
+ (subversion == ESA) ? IRQF_SHARED : 0,
  driver_name, (void *) [j])) {
   printk("%s: unable to allocate IRQ %u, detaching.\n", name, irq);
   goto freelock;
-- 
1.8.3.2

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


[PATCH] [RESEND] [SCSI] ibmvstgt: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
from drivers/scsi/ibmvscsi/ibmvstgt.c

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/ibmvscsi/ibmvstgt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ibmvscsi/ibmvstgt.c b/drivers/scsi/ibmvscsi/ibmvstgt.c
index bf9eca845166..56f8a861ed72 100644
--- a/drivers/scsi/ibmvscsi/ibmvstgt.c
+++ b/drivers/scsi/ibmvscsi/ibmvstgt.c
@@ -589,7 +589,7 @@ static int crq_queue_create(struct crq_queue *queue, struct 
srp_target *target)
}
 
err = request_irq(vport->dma_dev->irq, _interrupt,
- IRQF_DISABLED, "ibmvstgt", target);
+ 0, "ibmvstgt", target);
if (err)
goto req_irq_failed;
 
-- 
1.8.3.2

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


[PATCH] [RESEND] [SCSI] eata: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
from drivers/scsi/eata*

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/eata.c | 2 +-
 drivers/scsi/eata_pio.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/eata.c b/drivers/scsi/eata.c
index 94de88955a99..ebf57364df91 100644
--- a/drivers/scsi/eata.c
+++ b/drivers/scsi/eata.c
@@ -1221,7 +1221,7 @@ static int port_detect(unsigned long port_base, unsigned 
int j,
 
/* Board detected, allocate its IRQ */
if (request_irq(irq, do_interrupt_handler,
-   IRQF_DISABLED | ((subversion == ESA) ? IRQF_SHARED : 0),
+   (subversion == ESA) ? IRQF_SHARED : 0,
driver_name, (void *)[j])) {
printk("%s: unable to allocate IRQ %u, detaching.\n", name,
   irq);
diff --git a/drivers/scsi/eata_pio.c b/drivers/scsi/eata_pio.c
index 1663173cdb91..8319d2b417b8 100644
--- a/drivers/scsi/eata_pio.c
+++ b/drivers/scsi/eata_pio.c
@@ -687,7 +687,7 @@ static int register_pio_HBA(long base, struct get_conf *gc, 
struct pci_dev *pdev
return 0;
 
if (!reg_IRQ[gc->IRQ]) {/* Interrupt already registered ? */
-   if (!request_irq(gc->IRQ, do_eata_pio_int_handler, 
IRQF_DISABLED, "EATA-PIO", sh)) {
+   if (!request_irq(gc->IRQ, do_eata_pio_int_handler, 0, 
"EATA-PIO", sh)) {
reg_IRQ[gc->IRQ]++;
if (!gc->IRQ_TR)
reg_IRQL[gc->IRQ] = 1;  /* IRQ is edge 
triggered */
@@ -921,7 +921,7 @@ static int eata_pio_detect(struct scsi_host_template *tpnt)
 
for (i = 0; i < MAXIRQ; i++)
if (reg_IRQ[i])
-   request_irq(i, do_eata_pio_int_handler, IRQF_DISABLED, 
"EATA-PIO", NULL);
+   request_irq(i, do_eata_pio_int_handler, 0, "EATA-PIO", 
NULL);
 
HBA_ptr = first_HBA;
 
-- 
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/


Urgent Please

2014-03-04 Thread rose robert
-- 
Urgent Please

My name is Mrs Rose Robert, I have been surffering from Ovarian cancer
disease and the doctor says that i have just few days to leave.I am
from Belgium, but based in Burkina Faso,Africa since ten years ago as
a business woman dealing with cocoa exportation,now that i am about to
end the race like this,without any family members and no child.I have
$1 Million US DOLLARS in EcoBank here in Burkina Faso

which i instructed the bank to give African union leaders to help sick
people around Africa.But my mind is not at rest because of that i am
writing thisletter now through the help of my Doctor beside me here in
my hospital room. I also have $3.1 Million US Dollars in Bank Of
Africa Burkina Faso,

which i want you to claim from the bank and use it to help less
previledge people in your country,but you must assure me that you will
take only 40% of the total money and give the rest 60% to the
orphanage home in your country,

for my heart to rest.Upon the receipt of your email that you are
willing and capable to execute my plan, i will instruct the bank
management to make an immediate transfer into your account. forther
more as soon as you receive the massge if you want to reply me i will
want you to reply me  with your personal information and you will also
send me a copy id to forward to them that you are the person I am
willing my wealth;

Sincerely,

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


[PATCH] [RESEND] [SCSI] aic7xxx: remove duplicate define

2014-03-04 Thread Michael Opdenacker
Remove duplicate define
in drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h

Signed-off-by: Michael Opdenacker 
Acked-by: Hannes Reinecke 
---
 drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h 
b/drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h
index 9df9e2ce3538..8373447bd7d3 100644
--- a/drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h
+++ b/drivers/scsi/aic7xxx/aicasm/aicasm_insformat.h
@@ -209,7 +209,6 @@ struct instruction {
 #define AIC_OP_JC160x9105
 #define AIC_OP_JNC16   0x9205
 #define AIC_OP_CALL16  0x9305
-#define AIC_OP_CALL16  0x9305
 
 /* Page extension is low three bits of second opcode byte. */
 #define AIC_OP_JMPF0xA005
-- 
1.8.3.2

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


[PATCH] [RESEND] [SCSI] aha152x: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
from drivers/scsi/aha152x.c

It's a NOOP since 2.6.35 and it will be removed one day.

Also taking the opportunity to fix checkpatch issues on the lines I modified

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/aha152x.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/aha152x.c b/drivers/scsi/aha152x.c
index 3f7b6fee0a74..e86eb6a921fc 100644
--- a/drivers/scsi/aha152x.c
+++ b/drivers/scsi/aha152x.c
@@ -857,7 +857,7 @@ struct Scsi_Host *aha152x_probe_one(struct aha152x_setup 
*setup)
SETPORT(SIMODE0, 0);
SETPORT(SIMODE1, 0);
 
-   if( request_irq(shpnt->irq, swintr, IRQF_DISABLED|IRQF_SHARED, 
"aha152x", shpnt) ) {
+   if (request_irq(shpnt->irq, swintr, IRQF_SHARED, "aha152x", shpnt)) {
printk(KERN_ERR "aha152x%d: irq %d busy.\n", shpnt->host_no, 
shpnt->irq);
goto out_host_put;
}
@@ -891,7 +891,7 @@ struct Scsi_Host *aha152x_probe_one(struct aha152x_setup 
*setup)
SETPORT(SSTAT0, 0x7f);
SETPORT(SSTAT1, 0xef);
 
-   if ( request_irq(shpnt->irq, intr, IRQF_DISABLED|IRQF_SHARED, 
"aha152x", shpnt) ) {
+   if (request_irq(shpnt->irq, intr, IRQF_SHARED, "aha152x", shpnt)) {
printk(KERN_ERR "aha152x%d: failed to reassign irq %d.\n", 
shpnt->host_no, shpnt->irq);
goto out_host_put;
}
-- 
1.8.3.2

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


[PATCH] [RESEND] [SCSI] aacraid: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of IRQF_DISABLED
from code in drivers/scsi/aacraid/

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/aacraid/rx.c  | 2 +-
 drivers/scsi/aacraid/sa.c  | 3 +--
 drivers/scsi/aacraid/src.c | 4 ++--
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/aacraid/rx.c b/drivers/scsi/aacraid/rx.c
index dada38aeacc0..bf077ce95bfe 100644
--- a/drivers/scsi/aacraid/rx.c
+++ b/drivers/scsi/aacraid/rx.c
@@ -646,7 +646,7 @@ int _aac_rx_init(struct aac_dev *dev)
dev->sync_mode = 0; /* sync. mode not supported */
dev->msi = aac_msi && !pci_enable_msi(dev->pdev);
if (request_irq(dev->pdev->irq, dev->a_ops.adapter_intr,
-   IRQF_SHARED|IRQF_DISABLED, "aacraid", dev) < 0) {
+   IRQF_SHARED, "aacraid", dev) < 0) {
if (dev->msi)
pci_disable_msi(dev->pdev);
printk(KERN_ERR "%s%d: Interrupt unavailable.\n",
diff --git a/drivers/scsi/aacraid/sa.c b/drivers/scsi/aacraid/sa.c
index 2244f315f33b..e66477c98240 100644
--- a/drivers/scsi/aacraid/sa.c
+++ b/drivers/scsi/aacraid/sa.c
@@ -387,8 +387,7 @@ int aac_sa_init(struct aac_dev *dev)
goto error_irq;
dev->sync_mode = 0; /* sync. mode not supported */
if (request_irq(dev->pdev->irq, dev->a_ops.adapter_intr,
-   IRQF_SHARED|IRQF_DISABLED,
-   "aacraid", (void *)dev ) < 0) {
+   IRQF_SHARED, "aacraid", (void *)dev) < 0) {
printk(KERN_WARNING "%s%d: Interrupt unavailable.\n",
name, instance);
goto error_iounmap;
diff --git a/drivers/scsi/aacraid/src.c b/drivers/scsi/aacraid/src.c
index 7e17107643d4..9c65aed26212 100644
--- a/drivers/scsi/aacraid/src.c
+++ b/drivers/scsi/aacraid/src.c
@@ -647,7 +647,7 @@ int aac_src_init(struct aac_dev *dev)
dev->msi = aac_msi && !pci_enable_msi(dev->pdev);
 
if (request_irq(dev->pdev->irq, dev->a_ops.adapter_intr,
-   IRQF_SHARED|IRQF_DISABLED, "aacraid", dev) < 0) {
+   IRQF_SHARED, "aacraid", dev) < 0) {
 
if (dev->msi)
pci_disable_msi(dev->pdev);
@@ -804,7 +804,7 @@ int aac_srcv_init(struct aac_dev *dev)
goto error_iounmap;
dev->msi = aac_msi && !pci_enable_msi(dev->pdev);
if (request_irq(dev->pdev->irq, dev->a_ops.adapter_intr,
-   IRQF_SHARED|IRQF_DISABLED, "aacraid", dev) < 0) {
+   IRQF_SHARED, "aacraid", dev) < 0) {
if (dev->msi)
pci_disable_msi(dev->pdev);
printk(KERN_ERR "%s%d: Interrupt unavailable.\n",
-- 
1.8.3.2

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


Re: [PATCH] Add option to build with -O3

2014-03-04 Thread Greg KH
On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote:
> +config CC_OPTIMIZE_FOR_SPEED
> +bool "Optimze for speed (-O3)"
> +help
> +  Enabling this option will pass "-O3" to gcc
> +  resulting in a larger kernel (but possibly faster)

Are you sure about that?  Have you measured 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] [RESEND] [SCSI] NCR5380: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
from drivers/scsi/NCR5380.c

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/scsi/NCR5380.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 1e9d6ad9302b..bcd223868227 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -584,7 +584,7 @@ static int __init __maybe_unused NCR5380_probe_irq(struct 
Scsi_Host *instance,
NCR5380_setup(instance);
 
for (trying_irqs = i = 0, mask = 1; i < 16; ++i, mask <<= 1)
-   if ((mask & possible) && (request_irq(i, _intr, 
IRQF_DISABLED, "NCR-probe", NULL) == 0))
+   if ((mask & possible) && (request_irq(i, _intr, 0, 
"NCR-probe", NULL) == 0))
trying_irqs |= mask;
 
timeout = jiffies + (250 * HZ / 1000);
-- 
1.8.3.2

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


[PATCH] [RESEND] PNP: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
from drivers/pnp/resource.c

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/pnp/resource.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pnp/resource.c b/drivers/pnp/resource.c
index bacddd102ae9..01712cbfd92e 100644
--- a/drivers/pnp/resource.c
+++ b/drivers/pnp/resource.c
@@ -385,7 +385,7 @@ int pnp_check_irq(struct pnp_dev *dev, struct resource *res)
 * device is active because it itself may be in use */
if (!dev->active) {
if (request_irq(*irq, pnp_test_handler,
-   IRQF_DISABLED | IRQF_PROBE_SHARED, "pnp", NULL))
+   IRQF_PROBE_SHARED, "pnp", NULL))
return 0;
free_irq(*irq, NULL);
}
-- 
1.8.3.2

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


Re: [PATCH] EDAC: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
Hi Johannes,

On 10/14/2013 11:56 AM, Johannes Thumshirn wrote:

> Hi Michael,
>
> mpc85xx_edac has them already removed in the version that is going into 3.13.
>
> Sorry for the inconvenience. I'll set up a public tree at my github repo, so
> everyone can see the current mpc85xx_edac state.

Any news about this removal?

My patch still applies to 3.14-rc5, which means that mpc85xx_edac is
still there.

I'd like to get rid of this patch for good ;)

Thank you,

Michael.

-- 
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098

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


[PATCH] [RESEND] drivers: bus: omap_l3: remove deprecated IRQF_DISABLED

2014-03-04 Thread Michael Opdenacker
This patch removes the use of the IRQF_DISABLED flag
from drivers/bus/omap_l3_*

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker 
---
 drivers/bus/omap_l3_noc.c | 4 ++--
 drivers/bus/omap_l3_smx.c | 6 ++
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae623f6..6ada27a911d1 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -187,7 +187,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq,
l3_interrupt_handler,
-   IRQF_DISABLED, "l3-dbg-irq", l3);
+   0, "l3-dbg-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->debug_irq);
@@ -197,7 +197,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq,
l3_interrupt_handler,
-   IRQF_DISABLED, "l3-app-irq", l3);
+   0, "l3-app-irq", l3);
if (ret) {
pr_crit("L3: request_irq failed to register for 0x%x\n",
l3->app_irq);
diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc216491b8a..769d64c0b0fe 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -238,8 +238,7 @@ static int __init omap3_l3_probe(struct platform_device 
*pdev)
 
l3->debug_irq = platform_get_irq(pdev, 0);
ret = request_irq(l3->debug_irq, omap3_l3_app_irq,
-   IRQF_DISABLED | IRQF_TRIGGER_RISING,
-   "l3-debug-irq", l3);
+   IRQF_TRIGGER_RISING, "l3-debug-irq", l3);
if (ret) {
dev_err(>dev, "couldn't request debug irq\n");
goto err1;
@@ -247,8 +246,7 @@ static int __init omap3_l3_probe(struct platform_device 
*pdev)
 
l3->app_irq = platform_get_irq(pdev, 1);
ret = request_irq(l3->app_irq, omap3_l3_app_irq,
-   IRQF_DISABLED | IRQF_TRIGGER_RISING,
-   "l3-app-irq", l3);
+   IRQF_TRIGGER_RISING, "l3-app-irq", l3);
if (ret) {
dev_err(>dev, "couldn't request app irq\n");
goto err2;
-- 
1.8.3.2

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


Re: futex funkiness -- massive lockups

2014-03-04 Thread Davidlohr Bueso
On Tue, 2014-03-04 at 19:36 -0800, Linus Torvalds wrote:
> On Tue, Mar 4, 2014 at 5:43 PM, Davidlohr Bueso  wrote:
> >
> >
> > From the paths related to futex wait we are stuck when taking the hb
> > spinlock in futex_wait_setup >> queue_lock.
> 
> Just judging from your trace, I would have suspected a (possibly soft)
> lockup in load_balance() rather than the futexes.
> 
> The futex being stuck seems expected, since one cpu is definitely
> holding the lock - it was interrupted by a timer interrupt at the
> successful return case of raw_spin_lock if I read the offset right.
> 
> So if that softirq is stuck - perhaps because it's in some endless
> loop in load_balance(), or perhaps because it's spending so much time
> load-balancing that the next balancing time happens immediately, or
> whatever - then you'd see that trace.

That does make a lot of sense, and since this is a futex intense
workload, it would also explain why I'm seeing so many CPUs stuck
waiting for the lock in the futex wait paths, it's the same hash bucket
and it's stuck just doing the cmpxchg over and over again.

Unfortunately the machine code dump is missing in for the load balancing
bits so it's pretty hard to see right away where the trapping
instruction would occur.

Thanks!

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


Re: [PATCH v5 3/7] pci: Create pci_host_bridge before its associated bus in pci_create_root_bus.

2014-03-04 Thread Jingoo Han
On Wednesday, March 05, 2014 12:48 PM, Yijing Wang wrote:
> On 2014/3/4 23:50, Liviu Dudau wrote:
> > Before commit 7b5436635800 the pci_host_bridge was created before the root 
> > bus.
> > As that commit has added a needless dependency on the bus for 
> > pci_alloc_host_bridge()
> > the creation order has been changed for no good reason. Revert the order of
> > creation as we are going to depend on the pci_host_bridge structure to 
> > retrieve the
> > domain number of the root bus.
> >
> > Signed-off-by: Liviu Dudau 
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 6e34498..78ccba0 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -505,7 +505,7 @@ static void pci_release_host_bridge_dev(struct device 
> > *dev)
> > kfree(bridge);
> >  }
> >
> > -static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
> > +static struct pci_host_bridge *pci_alloc_host_bridge(void)
> >  {
> > struct pci_host_bridge *bridge;
> >
> > @@ -514,7 +514,6 @@ static struct pci_host_bridge 
> > *pci_alloc_host_bridge(struct pci_bus *b)
> > return NULL;
> >
> > INIT_LIST_HEAD(>windows);
> > -   bridge->bus = b;
> > return bridge;
> >  }
> >
> > @@ -1727,9 +1726,21 @@ struct pci_bus *pci_create_root_bus(struct device 
> > *parent, int bus,
> > char bus_addr[64];
> > char *fmt;
> >
> > +   bridge = pci_alloc_host_bridge();
> > +   if (!bridge)
> > +   return NULL;
> > +
> > +   bridge->dev.parent = parent;
> > +   bridge->dev.release = pci_release_host_bridge_dev;
> > +   error = pcibios_root_bridge_prepare(bridge);
> > +   if (error) {
> > +   kfree(bridge);
> > +   return NULL;
> 
> What about use goto err_out?

+1

I agree with your opinion.
It makes the code simpler.

Best regards,
Jingoo Han

> 
> > +   }
> > +
> > b = pci_alloc_bus();
> > if (!b)
> > -   return NULL;
> > +   goto err_out;
> >
> > b->sysdata = sysdata;
> > b->ops = ops;
> > @@ -1738,26 +1749,15 @@ struct pci_bus *pci_create_root_bus(struct device 
> > *parent, int bus,
> > if (b2) {
> > /* If we already got to this bus through a different bridge, 
> > ignore it */
> > dev_dbg(>dev, "bus already known\n");
> > -   goto err_out;
> > +   goto err_bus_out;
> > }
> >
> > -   bridge = pci_alloc_host_bridge(b);
> > -   if (!bridge)
> > -   goto err_out;
> > -
> > -   bridge->dev.parent = parent;
> > -   bridge->dev.release = pci_release_host_bridge_dev;
> > +   bridge->bus = b;
> > dev_set_name(>dev, "pci%04x:%02x", pci_domain_nr(b), bus);
> > -   error = pcibios_root_bridge_prepare(bridge);
> > -   if (error) {
> > -   kfree(bridge);
> > -   goto err_out;
> > -   }
> > -
> > error = device_register(>dev);
> > if (error) {
> > put_device(>dev);
> > -   goto err_out;
> > +   goto err_bus_out;
> > }
> > b->bridge = get_device(>dev);
> > device_enable_async_suspend(b->bridge);
> > @@ -1814,8 +1814,10 @@ struct pci_bus *pci_create_root_bus(struct device 
> > *parent, int bus,
> >  class_dev_reg_err:
> > put_device(>dev);
> > device_unregister(>dev);
> > -err_out:
> > +err_bus_out:
> > kfree(b);
> > +err_out:
> > +   kfree(bridge);
> > return NULL;
> >  }
> >
> >

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


Re: [PATCH v10 2/3] mmc: sdhci-msm: Initial support for Qualcomm chipsets

2014-03-04 Thread Ulf Hansson
On 4 March 2014 20:27, Georgi Djakov  wrote:
> This platform driver adds the initial support of Secure
> Digital Host Controller Interface compliant controller
> found in Qualcomm chipsets.
>
> Signed-off-by: Asutosh Das 
> Signed-off-by: Venkat Gopalakrishnan 
> Tested-by: Ivan T. Ivanov 
> Signed-off-by: Georgi Djakov 
> ---
>  drivers/mmc/host/Kconfig |   13 ++
>  drivers/mmc/host/Makefile|1 +
>  drivers/mmc/host/sdhci-msm.c |  427 
> ++
>  3 files changed, 441 insertions(+)
>  create mode 100644 drivers/mmc/host/sdhci-msm.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 82cc34d..66ef8b9 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -334,6 +334,19 @@ config MMC_ATMELMCI
>
>   If unsure, say N.
>
> +config MMC_SDHCI_MSM
> +   tristate "Qualcomm SDHCI Controller Support"
> +   depends on ARCH_QCOM
> +   depends on MMC_SDHCI_PLTFM
> +   help
> + This selects the Secure Digital Host Controller Interface (SDHCI)
> + support present in Qualcomm SOCs. The controller supports
> + SD/MMC/SDIO devices.
> +
> + If you have a controller with this interface, say Y or M here.
> +
> + If unsure, say N.
> +
>  config MMC_MSM
> tristate "Qualcomm SDCC Controller Support"
> depends on MMC && (ARCH_MSM7X00A || ARCH_MSM7X30 || ARCH_QSD8X50)
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index f162f87a0..0c8aa5e 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)  += sdhci-of-esdhc.o
>  obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
>  obj-$(CONFIG_MMC_SDHCI_BCM_KONA)   += sdhci-bcm-kona.o
>  obj-$(CONFIG_MMC_SDHCI_BCM2835)+= sdhci-bcm2835.o
> +obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
>
>  ifeq ($(CONFIG_CB710_DEBUG),y)
> CFLAGS-cb710-mmc+= -DDEBUG
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> new file mode 100644
> index 000..46e4e0b
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -0,0 +1,427 @@
> +/*
> + * drivers/mmc/host/sdhci-msm.c - Qualcomm SDHCI Platform driver
> + *
> + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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 "sdhci-pltfm.h"
> +
> +#define CORE_HC_MODE   0x78
> +#define HC_MODE_EN 0x1
> +
> +#define CORE_POWER 0x0
> +#define CORE_SW_RSTBIT(7)
> +
> +#define CORE_PWRCTL_STATUS 0xdc
> +#define CORE_PWRCTL_MASK   0xe0
> +#define CORE_PWRCTL_CLEAR  0xe4
> +#define CORE_PWRCTL_CTL0xe8
> +
> +#define CORE_PWRCTL_BUS_OFFBIT(0)
> +#define CORE_PWRCTL_BUS_ON BIT(1)
> +#define CORE_PWRCTL_IO_LOW BIT(2)
> +#define CORE_PWRCTL_IO_HIGHBIT(3)
> +
> +#define CORE_PWRCTL_BUS_SUCCESSBIT(0)
> +#define CORE_PWRCTL_BUS_FAIL   BIT(1)
> +#define CORE_PWRCTL_IO_SUCCESS BIT(2)
> +#define CORE_PWRCTL_IO_FAILBIT(3)
> +
> +#define INT_MASK   0xf
> +
> +#define QCOM_SDHCI_VOLTAGE_LOW 180
> +#define QCOM_SDHCI_VOLTAGE_HIGH295
> +
> +
> +struct sdhci_msm_pltfm_data {
> +   u32 caps;   /* Supported UHS-I Modes */
> +   u32 caps2;  /* More capabilities */

Why do you need these caps, there are already a part of the mmc host.

> +   struct regulator *vdd;  /* VDD/VCC regulator */
> +   struct regulator *vdd_io;   /* VDD IO regulator */

Why do you need to duplicate the regulators for sdhci_msm? sdhci core
is already taking care of regulators, I suppose you should adopt to
that!?

> +};
> +
> +struct sdhci_msm_host {
> +   struct platform_device *pdev;
> +   void __iomem *core_mem; /* MSM SDCC mapped address */
> +   int pwr_irq;/* power irq */
> +   struct clk *clk;/* main SD/MMC bus clock */
> +   struct clk *pclk;   /* SDHC peripheral bus clock */
> +   struct clk *bus_clk;/* SDHC bus voter clock */
> +   struct sdhci_msm_pltfm_data pdata;
> +   struct mmc_host *mmc;
> +   struct sdhci_pltfm_data sdhci_msm_pdata;
> +};
> +
> +/* MSM platform specific tuning */
> +int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
> +{
> +   /*
> +* Tuning 

Re: [PATCH] Revert "driver core: synchronize device shutdown"

2014-03-04 Thread Greg Kroah-Hartman
On Tue, Mar 04, 2014 at 08:15:36PM -0800, Roland Dreier wrote:
> > Hm, no one seems to have said anything for the past 5 years about this.
> 
> It definitely is hard to hit -- you have to do "shutdown" or "reboot"
> right as something schedules async work.  In our case we have some
> systems with a large and slightly flaky SAS fabric, so there's a
> constant level of re-probing SCSI disks, and we occasionally see
> reboots hanging due to waiting for never-finishing sd probe async
> work.
> 
> AFAICT the synchronization does nothing useful and is just a remnant
> of a patch series where the real meat didn't get applied.  But of
> course it would be great if Shaohua could confirm my understanding.

Shaohua's email address seems to now bounce :(

Arjan, any thoughts?

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 1/2] sched: Remove unused mc_capable() and smt_capable()

2014-03-04 Thread Benjamin Herrenschmidt
On Tue, 2014-03-04 at 14:07 -0700, Bjorn Helgaas wrote:
> Remove mc_capable() and smt_capable().  Neither is used.
> 
> Both were added by 5c45bf279d37 ("sched: mc/smt power savings sched
> policy").  Uses of both were removed by 8e7fbcbc22c1 ("sched: Remove stale
> power aware scheduling remnants and dysfunctional knobs").
> 
> Signed-off-by: Bjorn Helgaas 

Acked-by: Benjamin Herrenschmidt 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/11] ARM: s3c64xx: dt: Enable SoC-level power management

2014-03-04 Thread Mark Brown
On Mon, Mar 03, 2014 at 05:02:13PM +0100, Tomasz Figa wrote:
> This patch adds call to s3c64xx_pm_init() from init_machine() callback
> of mach-s3c64xx-dt to enable SoC-level power management features, such
> as power domain management and sleep support.

Reviewed-by: Mark Brown 


signature.asc
Description: Digital signature


Re: [PATCH v2 07/11] ARM: s3c64xx: pm: Add device tree based power domain instantiation

2014-03-04 Thread Mark Brown
On Mon, Mar 03, 2014 at 05:02:12PM +0100, Tomasz Figa wrote:
> This patch adds support for registering power domains of S3C64xx SoCs
> and binding devices to them using device tree.

Reviwed-by: Mark Brown 


signature.asc
Description: Digital signature


Re: [PATCH v2 09/11] ARM: dts: s3c64xx: Add nodes for power domains

2014-03-04 Thread Mark Brown
On Mon, Mar 03, 2014 at 05:02:14PM +0100, Tomasz Figa wrote:
> This patch adds device tree nodes for power domains available on S3C64xx
> SoCs.

Reviwed-by: Mark Brown 


signature.asc
Description: Digital signature


Re: [PATCH 1/3] regulator: tps80031: remove unnecessary parentheses

2014-03-04 Thread Mark Brown
On Wed, Feb 26, 2014 at 10:19:30AM +0900, Jingoo Han wrote:
> Remove unnecessary parentheses in order to fix the following
> checkpatch error.
> 
>   ERROR: return is not a function, parentheses are not required

Applied, thanks.


signature.asc
Description: Digital signature


  1   2   3   4   5   6   7   8   9   10   >