Re: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability

[Chanwoo Choi]

Hi Naveen,

On 06/18/2014 02:27 PM, Naveen Krishna Ch wrote:
> Hello Chanwoo,
> 
> On 18 June 2014 07:50, Chanwoo Choi  wrote:
>> This patchset add 'exynos_adc_ops' structure which includes some functions
>> to control ADC operation according to ADC version (v1 or v2).
>>
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Kyungmin Park 
> 
> This is a good piece of change, Thanks.
> 
> Reviewed-by: Naveen Krishna Chatradhi 

Thanks for your review.

Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI/portdrv: Remove warning about invalid IRQ

[Jiang Liu]

For hot-added PCIe ports, it always generates a warning message on x86
platforms when binding to portdrv as:
"device [8086:0e0b] has invalid IRQ; check vendor BIOS".

It's due to that we check pci_dev->irq before actually allocating IRQ
for the PCI device:
if (!dev->irq && dev->pin) {
dev_warn(>dev, "device [%04x:%04x] has invalid IRQ; "
 "check vendor BIOS\n", dev->vendor, dev->device);
}
status = pcie_port_device_register(dev);
-->pci_enable_device(dev);
-->pci_enable_device_flags()
-->do_pci_enable_device()
-->pcibios_enable_device()
-->pcibios_enable_irq()

This warning message isn't generated for PCIe ports present at boot time
because x86 arch code has called acpi_pci_irq_enable() in pci_acpi_init()
for each PCI device for safety.

Signed-off-by: Jiang Liu 
---
Hi Bjorn,
I have rebased it onto v3.16-rc1 and changed the patch title
according to your suggestion.
Thanks!
Gerry
___
 drivers/pci/pcie/portdrv_pci.c |4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 80887eaa0668..2ccc9b926ea7 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -203,10 +203,6 @@ static int pcie_portdrv_probe(struct pci_dev *dev,
 (pci_pcie_type(dev) != PCI_EXP_TYPE_DOWNSTREAM)))
return -ENODEV;
 
-   if (!dev->irq && dev->pin) {
-   dev_warn(>dev, "device [%04x:%04x] has invalid IRQ; check 
vendor BIOS\n",
-dev->vendor, dev->device);
-   }
status = pcie_port_device_register(dev);
if (status)
return status;
-- 
1.7.10.4

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

Re: [PATCH v2] drbd: change one-bit bitfield to be an unsigned int

[Martin Kepplinger]

Am 2014-06-17 21:46, schrieb David Rientjes:
> On Tue, 17 Jun 2014, Martin Kepplinger wrote:
> 
>> The one-bit bitfields are assigned true (1) or false (0) and checked
>> for them respectively. While it should work either way and -1 is true
>> as well it is more clear to see what's going on when using an unsigned int
>> because 1 doesn't silently become -1 behind the label true.
>>
> 
> Nothing is silently becoming anything, I have no idea what you're trying 
> to address.  Is there something in drivers/block/drbd that needs this 
> change?

nope.

> 
>> Signed-off-by: Martin Kepplinger 
>> ---
>> Thanks for looking at it. This is more of a question: Does this make sense
>> to you now? I can be mistaken. It just wasn't totally clear to me at first
>> sight and even though it should be, why not try to improve it.
>>
> 
> There's no improvement here, you realize that the sign of one-bit 
> bitfields are implementation defined, correct?  On what implementation 
> does this patch make a difference?
> 
> If you are trying to convert these to unsigned for consistency, then just 
> say so in the changelog and don't talk about silent changes or comparisons 
> to true and false that obfuscate the fact that this is just a trivial 
> cleanup that is based on the author's own preference rather than anything 
> else.

learning learning learning. in this case, why sparse calls this dubious.
This would be more appropriate on kernelnewbies or the like, sorry.

> 
>> sparse called it 'dubious' before the change.
>>
>> (built but untested)
>>
>>  drivers/block/drbd/drbd_interval.h |4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/block/drbd/drbd_interval.h 
>> b/drivers/block/drbd/drbd_interval.h
>> index f38fcb0..8d670e6 100644
>> --- a/drivers/block/drbd/drbd_interval.h
>> +++ b/drivers/block/drbd/drbd_interval.h
>> @@ -9,8 +9,8 @@ struct drbd_interval {
>>  sector_t sector;/* start sector of the interval */
>>  unsigned int size;  /* size in bytes */
>>  sector_t end;   /* highest interval end in subtree */
>> -int local:1 /* local or remote request? */;
>> -int waiting:1;
>> +unsigned int local:1;   /* local or remote request? */
>> +unsigned int waiting:1;
>>  };
>>  
>>  static inline void drbd_clear_interval(struct drbd_interval *i)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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/

[RFC PATCH 1/1] Move two pinned pages to non-movable node in kvm.

[Tang Chen]

Hi,

I met a problem when offlining memory with a kvm guest running.


[Problem]
When qemu creates vpus, it will call the following two functions
to allocate two pages:
1. alloc_apic_access_page(): allocate apic access page for FlexPriority in 
intel cpu.
2. alloc_identity_pagetable(): allocate ept identity pagetable for real mode.

And unfortunately, these two pages will be pinned in memory, and they cannot
be migrated. As a result, they cannot be offlined. And memory hot-remove will 
fail.



[The way I tried]
I tried to migrate these two pages, but I think I cannot find a proper way
to migrate them.

Let's take ept identity pagetable for example:
In my opinion, since it is pagetable, CPU will access this page every time the 
guest
read/write memory. For example, the following code will access memory:
int a;
a = 0;
So this ept identity pagetable page can be accessed at any time by CPU 
automatically.



[Solution]
I have a basic idea to solve this problem: allocate these two pages in 
non-movable nodes.
(For now, we can only hot-remove memory in movable nodes.)

alloc_identity_pagetable()
|-> __kvm_set_memory_region()
|   |-> kvm_arch_prepare_memory_region()
|   |-> userspace_addr = vm_mmap();
|   |-> memslot->userspace_addr = userspace_addr;  /* map usespace address 
(qemu) */
|
|   /*
|* Here, set memory policy for the mapped but not allocated page,
|* make it can only be allocated in non-movable nodes.
|* (We can reuse "numa_kernel_nodes" node mask in movable_node 
functionality.)
|*/
|
|-> page = gfn_to_page()  /* allocate and pin page */

Please refer to the attached patch for detail.
I did some basic test for the patch, and it will make memory offline succeed.



[Questions]
And by the way, would you guys please answer the following questions for me ?

1. What's the ept identity pagetable for ?  Only one page is enough ?

2. Is the ept identity pagetable only used in realmode ?
   Can we free it once the guest is up (vcpu in protect mode)?

3. Now, ept identity pagetable is allocated in qemu userspace.
   Can we allocate it in kernel space ?

4. If I want to migrate these two pages, what do you think is the best way ?

Thanks.


Signed-off-by: Tang Chen 
---
 arch/x86/include/asm/numa.h | 1 +
 arch/x86/kvm/vmx.c  | 5 +
 arch/x86/kvm/x86.c  | 1 +
 arch/x86/mm/numa.c  | 3 ++-
 include/linux/mempolicy.h   | 6 ++
 mm/mempolicy.c  | 9 +
 6 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
index 4064aca..6312577 100644
--- a/arch/x86/include/asm/numa.h
+++ b/arch/x86/include/asm/numa.h
@@ -30,6 +30,7 @@ extern int numa_off;
  */
 extern s16 __apicid_to_node[MAX_LOCAL_APIC];
 extern nodemask_t numa_nodes_parsed __initdata;
+extern nodemask_t numa_kernel_nodes;
 
 extern int __init numa_add_memblk(int nodeid, u64 start, u64 end);
 extern void __init numa_set_distance(int from, int to, int distance);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 801332e..4a3b5b5 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "kvm_cache_regs.h"
 #include "x86.h"
 
@@ -3988,6 +3989,8 @@ static int alloc_apic_access_page(struct kvm *kvm)
if (r)
goto out;
 
+   numa_bind_non_movable(kvm_userspace_mem.userspace_addr, PAGE_SIZE);
+
page = gfn_to_page(kvm, 0xfee00);
if (is_error_page(page)) {
r = -EFAULT;
@@ -4018,6 +4021,8 @@ static int alloc_identity_pagetable(struct kvm *kvm)
if (r)
goto out;
 
+   numa_bind_non_movable(kvm_userspace_mem.userspace_addr, PAGE_SIZE);
+
page = gfn_to_page(kvm, kvm->arch.ept_identity_map_addr >> PAGE_SHIFT);
if (is_error_page(page)) {
r = -EFAULT;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f32a025..3962a23 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7295,6 +7295,7 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
return PTR_ERR((void *)userspace_addr);
 
memslot->userspace_addr = userspace_addr;
+   mem->userspace_addr = userspace_addr;
}
 
return 0;
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index a32b706..d706148 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -22,6 +22,8 @@
 
 int __initdata numa_off;
 nodemask_t numa_nodes_parsed __initdata;
+nodemask_t numa_kernel_nodes;
+EXPORT_SYMBOL(numa_kernel_nodes);
 
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
 EXPORT_SYMBOL(node_data);
@@ -557,7 +559,6 @@ static void __init numa_init_array(void)
 static void __init numa_clear_kernel_node_hotplug(void)
 {
int i, nid;
-   nodemask_t numa_kernel_nodes = NODE_MASK_NONE;
unsigned long start, end;
struct memblock_region *r;
 
diff --git a/include/linux/mempolicy.h 

Re: [PATCH v5] hwmon: Driver for TI TMP103 temperature sensor

[Varka Bhadram]

Hi,

On 06/18/2014 11:07 AM, Heiko Schocher wrote:

Driver for the TI TMP103.

The TI TMP103 is similar to the TMP102.  It differs from the TMP102
by having only 8 bit registers.

Signed-off-by: Heiko Schocher 

---

Cc: Jean Delvare 
Cc: Guenter Roeck 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mark Rutland 

- change for v2:
   - add comments from GuenterRoeck:
 - remove Cc from commit subject
 - add devicetree maintainer
 - move Documentation to Documentation/hwmon/tmp103
 - remove devicetree bindings from Documentation
 - add compatible string to
   "Documentation/devicetree/bindings/i2c/trivial-devices.txt"
 - remove CamelCase
 - fix Codingstyle issues
 - use ATTRIBUTE_GROUPS and devm_hwmon_device_register_with_groups()
 - remove unsused define TMP103_CONFIG_RD_ONLY
 - restore config register when exit()
 - use regmap
- changes for v3:
   again a lot of fantastic tips how to use regmap efficiently
   from Guenter Roeck:
   - get rid of "struct tmp103"
   - get rid of "static const u8 tmp103_reg[]"
   - get rid of mutex lock
   - drop config_orig entirely
   - use regmap_update_bits()
- changes for v4:
   - add comment from Guenter Roeck:
 define TMP103_CONFIG_MASK and TMP103_CONF_SD_MASK
 separately to ensure you catch all the to-be-cleared bits.
- changes for v5:
   add comment from Guenter Roeck:
   - use "#define TMP103_CONF_SD TMP103_CONF_M1"
   add comment from Mark Rutland:
   - use full string for DT compatible string matching, instead of
 DRIVER_NAME. Get rid complete of DRIVER_NAME define.

  .../devicetree/bindings/i2c/trivial-devices.txt|   1 +
  Documentation/hwmon/tmp103 |  28 +++
  drivers/hwmon/Kconfig  |  10 +
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/tmp103.c | 205 +
  5 files changed, 245 insertions(+)
  create mode 100644 Documentation/hwmon/tmp103
  create mode 100644 drivers/hwmon/tmp103.c

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index bef86e5..fc944e0 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -83,5 +83,6 @@ stm,m41t80M41T80 - SERIAL ACCESS RTC WITH ALARMS
  taos,tsl2550  Ambient Light Sensor with SMBUS/Two Wire Serial 
Interface
  ti,tsc2003I2C Touch-Screen Controller
  ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two 
Wire Serial Interface
+ti,tmp103  Low Power Digital Temperature Sensor with SMBUS/Two 
Wire Serial Interface
  ti,tmp275 Digital Temperature Sensor
  winbond,wpct301   i2c trusted platform module (TPM)
diff --git a/Documentation/hwmon/tmp103 b/Documentation/hwmon/tmp103
new file mode 100644
index 000..ec00a15
--- /dev/null
+++ b/Documentation/hwmon/tmp103
@@ -0,0 +1,28 @@
+Kernel driver tmp103
+
+
+Supported chips:
+  * Texas Instruments TMP103
+Prefix: 'tmp103'
+Addresses scanned: none
+Product info and datasheet: http://www.ti.com/product/tmp103
+
+Author:
+   Heiko Schocher 
+
+Description
+---
+
+The TMP103 is a digital output temperature sensor in a four-ball
+wafer chip-scale package (WCSP). The TMP103 is capable of reading
+temperatures to a resolution of 1°C. The TMP103 is specified for
+operation over a temperature range of –40°C to +125°C.
+
+Resolution: 8 Bits
+Accuracy: ±1°C Typ (–10°C to +100°C)
+
+The driver provides the common sysfs-interface for temperatures (see
+Documentation/hwmon/sysfs-interface under Temperatures).
+
+Please refer how to instantiate this driver:
+Documentation/i2c/instantiating-devices
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..c882d4b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1391,6 +1391,16 @@ config SENSORS_TMP102
  This driver can also be built as a module.  If so, the module
  will be called tmp102.
  
+config SENSORS_TMP103

+   tristate "Texas Instruments TMP103"
+   depends on I2C
+   help
+ If you say yes here you get support for Texas Instruments TMP103
+ sensor chips.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tmp103.
+
  config SENSORS_TMP401
tristate "Texas Instruments TMP401 and compatibles"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 3dc0f02..cc0df1ef 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -135,6 +135,7 @@ obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
  obj-$(CONFIG_SENSORS_AMC6821) += amc6821.o
  obj-$(CONFIG_SENSORS_THMC50)  += thmc50.o
  obj-$(CONFIG_SENSORS_TMP102)  += tmp102.o

Re: [PATCH 1/1] scripts/coccinelle/free: add conditional kfree test

[Joe Perches]

On Wed, 2014-06-18 at 07:25 +0200, Julia Lawall wrote:
> 
> On Tue, 17 Jun 2014, Joe Perches wrote:
> 
> > (adding Jesper Juhl)
> > 
> > On Tue, 2014-06-17 at 23:33 +0200, Julia Lawall wrote:
> > > On Tue, 17 Jun 2014, Joe Perches wrote:
> > > > On Tue, 2014-06-17 at 21:43 +0200, Fabian Frederick wrote:
> > > > > This patch adds a trivial script warning on
> > > > > 
> > > > > if(foo)
> > > > >   kfree(foo)
> > > > > 
> > > > > (based on checkpatch)
> > > > []
> > > > > diff --git a/scripts/coccinelle/free/cond_kfree.cocci 
> > > > > b/scripts/coccinelle/free/cond_kfree.cocci
> > > > []
> > > > > +* if (E)
> > > > > +*kfree@p(E);
> > > > 
> > > > You should probably add all of the unnecessary
> > > > conditional tests that checkpatch uses:
> > > > 
> > > > kfree
> > > > usb_free_urb
> > > > debugfs_remove
> > > > debugfs_remove_recursive
> > > 
> > > Personally, I would prefer that the message encourage the user to 
> > > consider 
> > > whether it is necessary to call these functions with NULL as an argument 
> > > in any case.
> > 
> > Jesper quite awhile ago wrote:
> > 
> > https://lkml.org/lkml/2005/10/13/81
> > 
> > - Since kfree always checks for a NULL argument there's no reason to have an
> > additional check prior to calling kfree. It's redundant.
> > - In many cases gcc produce significantly smaller code without the redundant
> > check before the call.
> > - It's been shown in the past (in discussions on LKML) that it's generally a
> > win performance wise to avoid the extra NULL check even though it might save
> > a function call. Only when the NULL check avoids the function call in the 
> > vast
> > majority of cases and the code is in a hot path does it make sense to have 
> > it.
> > - This patch removes quite a few more source lines than it adds, cutting 
> > down
> > on the overall number of source lines is generally a good thing.
> > - This patch reduces the indentation level, which is nice when the kfree 
> > call
> > is inside some deeply nested construct.
> 
> What I don't like is:
> 
> a = kmalloc(...);
> if (!a) goto out;
> b = kmalloc(...);
> if (!b) goto out;
> c = kmalloc(...);
> if (!c) goto out;
> ...
> out:
>   kfree(a);
>   kfree(b);
>   kfree(c);
> 
> With a little thought, one could reorganize the code to not call kfree on 
> a null value.

And I think most kernel malloc failures are written like:

a = kmalloc(...);
if (!a) goto out1;
b = kmalloc(...);
if (!b) goto out2;
c = kmalloc(...)
if (!c) goto out3;
...
out3:   kfree(b);
out2:   kfree(a);
out1:   ...

>   Someone who is not familiar with Linux programming style 
> could interpret the feedback as that the above code is perfectly fine.  
> (And perhaps some people do consider that it is perfectly fine).

maybe so.

> On the other hand, in the case:
> 
> x = NULL;
> if (complicated_condition)
>   x = kmalloc(...);
>   if (!x) return;
> y = something(...);
> if (!y)
>   goto out1;
> ...
> out1: kfree(x);
> 
> I guess it's OK.  Mildly unpleasant, but probably the best option given 
> the various tradeoff.
> 
> In looking at Jesper's patch, I see that another case is:
> 
> a = kmalloc(...);
> b = kmalloc(...);
> if (!a || !b) {
>   kfree(a);
>   kfree(b);
> }
> 
> Personally, I would rather see each call have its own error handling code.  
> There is no point to make the second call if the first one fails.
> 
> When one tries to understand code, the main questions are why is this done 
> here, and why is this not done here.  Doing things that are unnecessary 
> introduces confusion in this regard.  Perhaps it doesn't matter for 
> kmalloc and kfree because everyone is familiar with them and they are 
> pretty innocuous.  But for the more obscure functions, like in my 
> recollection of Markus's patch, I'm not convinced that simply blindly 
> removing all unneeded tests without thinking whether the code could be 
> written in a better way is a good idea.

Blindly applying patches, even those produced by coccinelle,
let alone mine, is rarely good practice.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5] hwmon: Driver for TI TMP103 temperature sensor

[Heiko Schocher]

Driver for the TI TMP103.

The TI TMP103 is similar to the TMP102.  It differs from the TMP102
by having only 8 bit registers.

Signed-off-by: Heiko Schocher 

---

Cc: Jean Delvare 
Cc: Guenter Roeck 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Mark Rutland 

- change for v2:
  - add comments from GuenterRoeck:
- remove Cc from commit subject
- add devicetree maintainer
- move Documentation to Documentation/hwmon/tmp103
- remove devicetree bindings from Documentation
- add compatible string to
  "Documentation/devicetree/bindings/i2c/trivial-devices.txt"
- remove CamelCase
- fix Codingstyle issues
- use ATTRIBUTE_GROUPS and devm_hwmon_device_register_with_groups()
- remove unsused define TMP103_CONFIG_RD_ONLY
- restore config register when exit()
- use regmap
- changes for v3:
  again a lot of fantastic tips how to use regmap efficiently
  from Guenter Roeck:
  - get rid of "struct tmp103"
  - get rid of "static const u8 tmp103_reg[]"
  - get rid of mutex lock
  - drop config_orig entirely
  - use regmap_update_bits()
- changes for v4:
  - add comment from Guenter Roeck:
define TMP103_CONFIG_MASK and TMP103_CONF_SD_MASK
separately to ensure you catch all the to-be-cleared bits.
- changes for v5:
  add comment from Guenter Roeck:
  - use "#define TMP103_CONF_SD TMP103_CONF_M1"
  add comment from Mark Rutland:
  - use full string for DT compatible string matching, instead of
DRIVER_NAME. Get rid complete of DRIVER_NAME define.

 .../devicetree/bindings/i2c/trivial-devices.txt|   1 +
 Documentation/hwmon/tmp103 |  28 +++
 drivers/hwmon/Kconfig  |  10 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/tmp103.c | 205 +
 5 files changed, 245 insertions(+)
 create mode 100644 Documentation/hwmon/tmp103
 create mode 100644 drivers/hwmon/tmp103.c

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index bef86e5..fc944e0 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -83,5 +83,6 @@ stm,m41t80M41T80 - SERIAL ACCESS RTC WITH ALARMS
 taos,tsl2550   Ambient Light Sensor with SMBUS/Two Wire Serial 
Interface
 ti,tsc2003 I2C Touch-Screen Controller
 ti,tmp102  Low Power Digital Temperature Sensor with SMBUS/Two 
Wire Serial Interface
+ti,tmp103  Low Power Digital Temperature Sensor with SMBUS/Two 
Wire Serial Interface
 ti,tmp275  Digital Temperature Sensor
 winbond,wpct301i2c trusted platform module (TPM)
diff --git a/Documentation/hwmon/tmp103 b/Documentation/hwmon/tmp103
new file mode 100644
index 000..ec00a15
--- /dev/null
+++ b/Documentation/hwmon/tmp103
@@ -0,0 +1,28 @@
+Kernel driver tmp103
+
+
+Supported chips:
+  * Texas Instruments TMP103
+Prefix: 'tmp103'
+Addresses scanned: none
+Product info and datasheet: http://www.ti.com/product/tmp103
+
+Author:
+   Heiko Schocher 
+
+Description
+---
+
+The TMP103 is a digital output temperature sensor in a four-ball
+wafer chip-scale package (WCSP). The TMP103 is capable of reading
+temperatures to a resolution of 1°C. The TMP103 is specified for
+operation over a temperature range of –40°C to +125°C.
+
+Resolution: 8 Bits
+Accuracy: ±1°C Typ (–10°C to +100°C)
+
+The driver provides the common sysfs-interface for temperatures (see
+Documentation/hwmon/sysfs-interface under Temperatures).
+
+Please refer how to instantiate this driver:
+Documentation/i2c/instantiating-devices
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..c882d4b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1391,6 +1391,16 @@ config SENSORS_TMP102
  This driver can also be built as a module.  If so, the module
  will be called tmp102.
 
+config SENSORS_TMP103
+   tristate "Texas Instruments TMP103"
+   depends on I2C
+   help
+ If you say yes here you get support for Texas Instruments TMP103
+ sensor chips.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tmp103.
+
 config SENSORS_TMP401
tristate "Texas Instruments TMP401 and compatibles"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 3dc0f02..cc0df1ef 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -135,6 +135,7 @@ obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o
 obj-$(CONFIG_SENSORS_AMC6821)  += amc6821.o
 obj-$(CONFIG_SENSORS_THMC50)   += thmc50.o
 obj-$(CONFIG_SENSORS_TMP102)   += tmp102.o
+obj-$(CONFIG_SENSORS_TMP103)   += tmp103.o
 obj-$(CONFIG_SENSORS_TMP401)   += tmp401.o
 

Re: [PATCH] pinctrl: msm: Add msm8960 definitions

[Bjorn Andersson]

On Tue, Jun 17, 2014 at 3:00 PM, Andy Gross  wrote:
> On Tue, Jun 10, 2014 at 11:25:23AM -0700, Bjorn Andersson wrote:
>
> In general, it all looks good.  I only have 2 areas of concern.  The first is 
> a
> nit and it has to do with alternate pins for functions.  There really isn't a
> need for a separate function name.  That would only be required if the same 
> pin
> had multiple functions defined for the same thing.
>

I have to blame unclear documentation here ;)
Will drop all the _[abc] suffixes.

> As for the second area of concern, there are some discrepancies between our
> internal function map and yours.  This is probably due to some minor 
> difference
> in chip rev.  I'll try to find more information on this and determine if that 
> is
> true, or if one set of documentation is incorrect.

I'll await your feedback on this; but as the documentation available
to me would be
a rewrite of what you have I suspect we'll end up with your versions.
Just ping me
when you figure this one out and I'll respin.

Thanks for the review!

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

[PATCH] extcon: Remove unnecessary OOM messages

[Jingoo Han]

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message. The following
checkpatch warning is also removed.

  WARNING: Possible unnecessary 'out of memory' message

Signed-off-by: Jingoo Han 
---
 drivers/extcon/extcon-arizona.c  |4 +---
 drivers/extcon/extcon-max14577.c |5 ++---
 drivers/extcon/extcon-max77693.c |5 ++---
 drivers/extcon/extcon-max8997.c  |4 +---
 4 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 6c84e3d..90223a3 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1103,10 +1103,8 @@ static int arizona_extcon_probe(struct platform_device 
*pdev)
return -EPROBE_DEFER;
 
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
-   if (!info) {
-   dev_err(>dev, "Failed to allocate memory\n");
+   if (!info)
return -ENOMEM;
-   }
 
info->micvdd = devm_regulator_get(arizona->dev, "MICVDD");
if (IS_ERR(info->micvdd)) {
diff --git a/drivers/extcon/extcon-max14577.c b/drivers/extcon/extcon-max14577.c
index d49e891..7309743 100644
--- a/drivers/extcon/extcon-max14577.c
+++ b/drivers/extcon/extcon-max14577.c
@@ -692,10 +692,9 @@ static int max14577_muic_probe(struct platform_device 
*pdev)
u8 id;
 
info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
-   if (!info) {
-   dev_err(>dev, "failed to allocate memory\n");
+   if (!info)
return -ENOMEM;
-   }
+
info->dev = >dev;
info->max14577 = max14577;
 
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index 2c7c3e1..47998a2 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -1099,10 +1099,9 @@ static int max77693_muic_probe(struct platform_device 
*pdev)
 
info = devm_kzalloc(>dev, sizeof(struct max77693_muic_info),
   GFP_KERNEL);
-   if (!info) {
-   dev_err(>dev, "failed to allocate memory\n");
+   if (!info)
return -ENOMEM;
-   }
+
info->dev = >dev;
info->max77693 = max77693;
if (info->max77693->regmap_muic) {
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index d9f7f1b..045e230 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -661,10 +661,8 @@ static int max8997_muic_probe(struct platform_device *pdev)
 
info = devm_kzalloc(>dev, sizeof(struct max8997_muic_info),
GFP_KERNEL);
-   if (!info) {
-   dev_err(>dev, "failed to allocate memory\n");
+   if (!info)
return -ENOMEM;
-   }
 
info->dev = >dev;
info->muic = max8997->muic;
-- 
1.7.10.4


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

[PATCH] extcon: palmas: Make of_device_id array const

[Jingoo Han]

Make of_device_id array const, because all OF functions handle
it as const.

Signed-off-by: Jingoo Han 
---
 drivers/extcon/extcon-palmas.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 7417ce8..5efa96c 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -278,7 +278,7 @@ static int palmas_usb_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(palmas_pm_ops, palmas_usb_suspend, palmas_usb_resume);
 
-static struct of_device_id of_palmas_match_tbl[] = {
+static const struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = "ti,palmas-usb", },
{ .compatible = "ti,palmas-usb-vid", },
{ .compatible = "ti,twl6035-usb", },
-- 
1.7.10.4


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

Re: [PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability

[Naveen Krishna Ch]

Hello Chanwoo,

On 18 June 2014 07:50, Chanwoo Choi  wrote:
> This patchset add 'exynos_adc_ops' structure which includes some functions
> to control ADC operation according to ADC version (v1 or v2).
>
> Signed-off-by: Chanwoo Choi 
> Acked-by: Kyungmin Park 

This is a good piece of change, Thanks.

Reviewed-by: Naveen Krishna Chatradhi 
> ---
>  drivers/iio/adc/exynos_adc.c | 174 
> +--
>  1 file changed, 120 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
> index 010578f..c30def6 100644
> --- a/drivers/iio/adc/exynos_adc.c
> +++ b/drivers/iio/adc/exynos_adc.c
> @@ -90,6 +90,7 @@ struct exynos_adc {
> struct clk  *clk;
> unsigned intirq;
> struct regulator*vdd;
> +   struct exynos_adc_ops   *ops;
>
> struct completion   completion;
>
> @@ -97,6 +98,13 @@ struct exynos_adc {
> unsigned intversion;
>  };
>
> +struct exynos_adc_ops {
> +   void (*init_hw)(struct exynos_adc *info);
> +   void (*clear_irq)(struct exynos_adc *info);
> +   void (*start_conv)(struct exynos_adc *info, unsigned long addr);
> +   void (*stop_conv)(struct exynos_adc *info);
> +};
> +
>  static const struct of_device_id exynos_adc_match[] = {
> { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
> { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
> @@ -112,30 +120,98 @@ static inline unsigned int 
> exynos_adc_get_version(struct platform_device *pdev)
> return (unsigned int)match->data;
>  }
>
> -static void exynos_adc_hw_init(struct exynos_adc *info)
> +static void exynos_adc_v1_init_hw(struct exynos_adc *info)
> +{
> +   u32 con1;
> +
> +   /* set default prescaler values and Enable prescaler */
> +   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
> +
> +   /* Enable 12-bit ADC resolution */
> +   con1 |= ADC_V1_CON_RES;
> +   writel(con1, ADC_V1_CON(info->regs));
> +}
> +
> +static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned long 
> addr)
> +{
> +   u32 con1;
> +
> +   writel(addr, ADC_V1_MUX(info->regs));
> +
> +   con1 = readl(ADC_V1_CON(info->regs));
> +   writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
> +}
> +
> +static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
> +{
> +   writel(1, ADC_V1_INTCLR(info->regs));
> +}
> +
> +static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
> +{
> +   u32 con;
> +
> +   con = readl(ADC_V1_CON(info->regs));
> +   con |= ADC_V1_CON_STANDBY;
> +   writel(con, ADC_V1_CON(info->regs));
> +}
> +
> +static struct exynos_adc_ops exynos_adc_v1_ops = {
> +   .init_hw= exynos_adc_v1_init_hw,
> +   .clear_irq  = exynos_adc_v1_clear_irq,
> +   .start_conv = exynos_adc_v1_start_conv,
> +   .stop_conv  = exynos_adc_v1_stop_conv,
> +};
> +
> +static void exynos_adc_v2_init_hw(struct exynos_adc *info)
>  {
> u32 con1, con2;
>
> -   if (info->version == ADC_V2) {
> -   con1 = ADC_V2_CON1_SOFT_RESET;
> -   writel(con1, ADC_V2_CON1(info->regs));
> +   con1 = ADC_V2_CON1_SOFT_RESET;
> +   writel(con1, ADC_V2_CON1(info->regs));
>
> -   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
> -   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
> -   writel(con2, ADC_V2_CON2(info->regs));
> +   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
> +   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
> +   writel(con2, ADC_V2_CON2(info->regs));
>
> -   /* Enable interrupts */
> -   writel(1, ADC_V2_INT_EN(info->regs));
> -   } else {
> -   /* set default prescaler values and Enable prescaler */
> -   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
> +   /* Enable interrupts */
> +   writel(1, ADC_V2_INT_EN(info->regs));
> +}
>
> -   /* Enable 12-bit ADC resolution */
> -   con1 |= ADC_V1_CON_RES;
> -   writel(con1, ADC_V1_CON(info->regs));
> -   }
> +static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned long 
> addr)
> +{
> +   u32 con1, con2;
> +
> +   con2 = readl(ADC_V2_CON2(info->regs));
> +   con2 &= ~ADC_V2_CON2_ACH_MASK;
> +   con2 |= ADC_V2_CON2_ACH_SEL(addr);
> +   writel(con2, ADC_V2_CON2(info->regs));
> +
> +   con1 = readl(ADC_V2_CON1(info->regs));
> +   writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
> +}
> +
> +static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
> +{
> +   writel(1, ADC_V2_INT_ST(info->regs));
> +}
> +
> +static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
> +{
> +   u32 con;
> +
> +   con = readl(ADC_V2_CON1(info->regs));
> +   con &= ~ADC_CON_EN_START;
> +   writel(con, ADC_V2_CON1(info->regs));
>  }
>
> 

Re: [PATCH 1/4] ACPI: Support _OSI("Darwin") correctly

[Matthew Garrett]

On Tue, Jun 17, 2014 at 03:46:15PM +0100, Matthew Garrett wrote:
> On Tue, Jun 17, 2014 at 02:11:36PM +0200, Rafael J. Wysocki wrote:
> > Does applying this patch without the rest of the series makes things worse
> > or better on the machines in question (or perhaps it doesn't matter at all
> > alone)?
> 
> On its own, I think this will do nothing.

Ugh, no, sorry - on its own, this will break PCIe hotplug events and 
battery reporting. It should only be merged with the others.

-- 
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] scripts/coccinelle/free: add conditional kfree test

[Julia Lawall]

On Tue, 17 Jun 2014, Joe Perches wrote:

> (adding Jesper Juhl)
> 
> On Tue, 2014-06-17 at 23:33 +0200, Julia Lawall wrote:
> > On Tue, 17 Jun 2014, Joe Perches wrote:
> > > On Tue, 2014-06-17 at 21:43 +0200, Fabian Frederick wrote:
> > > > This patch adds a trivial script warning on
> > > > 
> > > > if(foo)
> > > > kfree(foo)
> > > > 
> > > > (based on checkpatch)
> > > []
> > > > diff --git a/scripts/coccinelle/free/cond_kfree.cocci 
> > > > b/scripts/coccinelle/free/cond_kfree.cocci
> > > []
> > > > +* if (E)
> > > > +*  kfree@p(E);
> > > 
> > > You should probably add all of the unnecessary
> > > conditional tests that checkpatch uses:
> > > 
> > > kfree
> > > usb_free_urb
> > > debugfs_remove
> > > debugfs_remove_recursive
> > 
> > Personally, I would prefer that the message encourage the user to consider 
> > whether it is necessary to call these functions with NULL as an argument 
> > in any case.
> 
> Jesper quite awhile ago wrote:
> 
> https://lkml.org/lkml/2005/10/13/81
> 
> - Since kfree always checks for a NULL argument there's no reason to have an
> additional check prior to calling kfree. It's redundant.
> - In many cases gcc produce significantly smaller code without the redundant
> check before the call.
> - It's been shown in the past (in discussions on LKML) that it's generally a
> win performance wise to avoid the extra NULL check even though it might save
> a function call. Only when the NULL check avoids the function call in the vast
> majority of cases and the code is in a hot path does it make sense to have it.
> - This patch removes quite a few more source lines than it adds, cutting down
> on the overall number of source lines is generally a good thing.
> - This patch reduces the indentation level, which is nice when the kfree call
> is inside some deeply nested construct.

What I don't like is:

a = kmalloc(...);
if (!a) goto out;
b = kmalloc(...);
if (!b) goto out;
c = kmalloc(...);
if (!c) goto out;
...
out:
  kfree(a);
  kfree(b);
  kfree(c);

With a little thought, one could reorganize the code to not call kfree on 
a null value.  Someone who is not familiar with Linux programming style 
could interpret the feedback as that the above code is perfectly fine.  
(And perhaps some people do consider that it is perfectly fine).

On the other hand, in the case:

x = NULL;
if (complicated_condition)
  x = kmalloc(...);
  if (!x) return;
y = something(...);
if (!y)
  goto out1;
...
out1: kfree(x);

I guess it's OK.  Mildly unpleasant, but probably the best option given 
the various tradeoff.

In looking at Jesper's patch, I see that another case is:

a = kmalloc(...);
b = kmalloc(...);
if (!a || !b) {
  kfree(a);
  kfree(b);
}

Personally, I would rather see each call have its own error handling code.  
There is no point to make the second call if the first one fails.

When one tries to understand code, the main questions are why is this done 
here, and why is this not done here.  Doing things that are unnecessary 
introduces confusion in this regard.  Perhaps it doesn't matter for 
kmalloc and kfree because everyone is familiar with them and they are 
pretty innocuous.  But for the more obscure functions, like in my 
recollection of Markus's patch, I'm not convinced that simply blindly 
removing all unneeded tests without thinking whether the code could be 
written in a better way is a good idea.

julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: qcom: Add BUS_HOLD pin bias

[Bjorn Andersson]

On Tue, Jun 17, 2014 at 9:49 PM, Andy Gross  wrote:
> This patch adds the BUS_HOLD (Keeper) bias option for pins.
>
> Signed-off-by: Andy Gross 

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

Re: [PATCH v3 1/3] soc: devicetree: bindings: Add Qualcomm RPM DT binding

[Bjorn Andersson]

On Tue, Jun 17, 2014 at 4:59 PM, Stephen Boyd  wrote:
[...]
>
> because ipc is actually a register inside the Krait complex's global
> clock control/distribution hardware block (it's located at 0x2011000).
> From what I can tell, this is the only non-clock/power register inside
> there. I plan to send out a driver for this hardware block so that I can
> switch the L2 aux source mux over to PLL8 instead of PXO (done with a
> single register write to 0x2011028) and this mapping/use here is going
> to conflict with that unless I only map the single register like is done
> here.
>
> I wonder if we'd be better off making this region a separate node and
> having some phandle to it here in the RPM node? That way we have a
> driver that provides a clock and some IPC handle the RPM driver can get.
> The SMD driver also uses the same register to kick other processors so
> having some generic IPC handle may be useful there too.

Thanks Stephen,

I never connected the dots here but now that I found the right pieces of
documentation I can only agree with you. This would better be some sort of
reverse interrupt chip.

Another such use case would be the smsm and smp2p, which in the codeaurora tree
are modelled with a custom "state change" api and as gpios respectively. Both
of these seems like they should better just be modelled as incoming virtual
interrupts and then some sort of outgoing "interrupts" or "signals".

Maybe I'm over optimistic regarding the reusability here, but I definitely
agree with you that having a "ipc = < 0>;" does look like a better
solution.

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

[PATCH net-next v2 2/3] ieee802154: cc2520: add driver to kernel build system

[Varka Bhadram]

Signed-off-by: Varka Bhadram 
---
 drivers/net/ieee802154/Kconfig  |   11 +++
 drivers/net/ieee802154/Makefile |1 +
 2 files changed, 12 insertions(+)

diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig
index 3e89bea..680422f 100644
--- a/drivers/net/ieee802154/Kconfig
+++ b/drivers/net/ieee802154/Kconfig
@@ -51,3 +51,14 @@ config IEEE802154_MRF24J40
 
  This driver can also be built as a module. To do so, say M here.
  the module will be called 'mrf24j40'.
+
+config IEEE802154_CC2520
+   depends on IEEE802154_DRIVERS && MAC802154
+   tristate "cc2520 transceiver driver"
+   depends on SPI
+   ---help---
+ Say Y here to enable the CC2520 SPI 802.15.4 wireless
+ controller.
+
+ This driver can also be built as a module. To do so, say M here.
+ the module will be called 'cc2520'.
diff --git a/drivers/net/ieee802154/Makefile b/drivers/net/ieee802154/Makefile
index abb0c08..655cb95 100644
--- a/drivers/net/ieee802154/Makefile
+++ b/drivers/net/ieee802154/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_IEEE802154_FAKEHARD) += fakehard.o
 obj-$(CONFIG_IEEE802154_FAKELB) += fakelb.o
 obj-$(CONFIG_IEEE802154_AT86RF230) += at86rf230.o
 obj-$(CONFIG_IEEE802154_MRF24J40) += mrf24j40.o
+obj-$(CONFIG_IEEE802154_CC2520) += cc2520.o
-- 
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 net-next v2 3/3] devicetree: add devicetree bindings for cc2520 driver

[Varka Bhadram]

devicetree bindings for cc2520 radio driver.

Signed-off-by: Varka Bhadram 
---
 .../devicetree/bindings/net/ieee802154/cc2520.txt  |   26 
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/ieee802154/cc2520.txt

diff --git a/Documentation/devicetree/bindings/net/ieee802154/cc2520.txt 
b/Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
new file mode 100644
index 000..f0a749d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
@@ -0,0 +1,26 @@
+CC2520 IEEE 802.15.4 Compatible Radio
+
+Required properties:
+   - compatible:   should be "ti,cc2520"
+   - spi-max-frequency:maximal bus speed (800), should be set to 
400 depends
+   sync or async operation mode
+   - reg:  the chipselect index
+   - mode: SPI mode
+Example:
+
+   cc2520@0 {
+   compatible = "ti,cc2520";
+   reg = <0>;
+   spi-max-frequency = <400>;
+   mode = <1>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_cape_pins>;/*GPIO pin muxing 
details*/
+
+   fifo-gpio = < 18 0>;
+   fifop-gpio = < 19 0>;
+   sfd-gpio = < 13 0>;
+   cca-gpio = < 16 0>;
+   vreg-gpio = < 31 0>;
+   reset-gpio = < 12 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 net-next v2 0/3] Driver fir TI CC2520 Radio

[Varka Bhadram]

This series adds the driver support for TI cc2520 radio.
also devicetree bindings for the driver.

changes since v1:
- improverment in gpio setup
- changed len pointer to len variable
- 
Varka Bhadram (3):
  ieee802154: cc2520: adds driver for TI CC2520 radio
  ieee802154: cc2520: add driver to kernel build system
  devicetree: add devicetree bindings for cc2520 driver

 .../devicetree/bindings/net/ieee802154/cc2520.txt  |   26 +
 drivers/net/ieee802154/Kconfig |   11 +
 drivers/net/ieee802154/Makefile|1 +
 drivers/net/ieee802154/cc2520.c|  968 
 include/linux/spi/cc2520.h |   26 +
 5 files changed, 1032 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
 create mode 100644 drivers/net/ieee802154/cc2520.c
 create mode 100644 include/linux/spi/cc2520.h

-- 
1.7.9.5

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

[PATCH net-next v2 1/3] ieee802154: cc2520: adds driver for TI CC2520 radio

[Varka Bhadram]

Driver support:
- Tx and Rx of IEEE-802.15.4 packets.
- Energy Detection on channel.
- Setting the Channel for the radio. [b/w 11 - 26 channels]
- Start and Stop the radio.

Signed-off-by: Varka Bhadram 
---
 drivers/net/ieee802154/cc2520.c |  968 +++
 include/linux/spi/cc2520.h  |   26 ++
 2 files changed, 994 insertions(+)
 create mode 100644 drivers/net/ieee802154/cc2520.c
 create mode 100644 include/linux/spi/cc2520.h

diff --git a/drivers/net/ieee802154/cc2520.c b/drivers/net/ieee802154/cc2520.c
new file mode 100644
index 000..29ac8d8
--- /dev/null
+++ b/drivers/net/ieee802154/cc2520.c
@@ -0,0 +1,968 @@
+/* Driver for TI CC2520 802.15.4 Wireless-PAN Networking controller
+ *
+ * Copyright (C) 2014 Varka Bhadram 
+ *   Md.Jamal Mohiuddin 
+ *   P Sowjanya 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#defineSPI_COMMAND_BUFFER  3
+#defineHIGH1
+#defineLOW 0
+#defineSTATE_IDLE  0
+#define RSSI_VALID 0
+#define RSSI_OFFSET78
+
+#define CC2520_RAM_SIZE640
+#define CC2520_FIFO_SIZE   128
+
+#define CC2520RAM_TXFIFO   0x100,
+#define CC2520RAM_RXFIFO   0x180,
+#define CC2520RAM_IEEEADDR 0x3EA,
+#define CC2520RAM_PANID0x3F2,
+#define CC2520RAM_SHORTADDR0x3F4,
+
+#define CC2520_FREG_MASK   0x3F
+
+/*status byte values */
+#defineCC2520_STATUS_XOSC32M_STABLE(1 << 7)
+#defineCC2520_STATUS_RSSI_VALID(1 << 6)
+#defineCC2520_STATUS_TX_UNDERFLOW  (1 << 3)
+
+/*IEEE 802.15.4 defined constants (2.4 GHz logical channels) */
+#define CC2520_MINCHANNEL  11
+#define CC2520_MAXCHANNEL  26
+#define CC2520_CHANNEL_SPACING 5
+
+/*command strobes*/
+#defineCC2520_CMD_SNOP 0x00
+#defineCC2520_CMD_IBUFLD   0x02
+#defineCC2520_CMD_SIBUFEX  0x03
+#defineCC2520_CMD_SSAMPLECCA   0x04
+#defineCC2520_CMD_SRES 0x0f
+#defineCC2520_CMD_MEMORY_MASK  0x0f
+#defineCC2520_CMD_MEMORY_READ  0x10
+#defineCC2520_CMD_MEMORY_WRITE 0x20
+#defineCC2520_CMD_RXBUF0x30
+#defineCC2520_CMD_RXBUFCP  0x38
+#defineCC2520_CMD_RXBUFMOV 0x32
+#defineCC2520_CMD_TXBUF0x3A
+#defineCC2520_CMD_TXBUFCP  0x3E
+#defineCC2520_CMD_RANDOM   0x3C
+#defineCC2520_CMD_SXOSCON  0x40
+#defineCC2520_CMD_STXCAL   0x41
+#defineCC2520_CMD_SRXON0x42
+#defineCC2520_CMD_STXON0x43
+#defineCC2520_CMD_STXONCCA 0x44
+#defineCC2520_CMD_SRFOFF   0x45
+#defineCC2520_CMD_SXOSCOFF 0x46
+#defineCC2520_CMD_SFLUSHRX 0x47
+#defineCC2520_CMD_SFLUSHTX 0x48
+#defineCC2520_CMD_SACK 0x49
+#defineCC2520_CMD_SACKPEND 0x4A
+#defineCC2520_CMD_SNACK0x4B
+#defineCC2520_CMD_SRXMASKBITSET0x4C
+#defineCC2520_CMD_SRXMASKBITCLR0x4D
+#defineCC2520_CMD_RXMASKAND0x4E
+#defineCC2520_CMD_RXMASKOR 0x4F
+#defineCC2520_CMD_MEMCP0x50
+#defineCC2520_CMD_MEMCPR   0x52
+#defineCC2520_CMD_MEMXCP   0x54
+#defineCC2520_CMD_MEMXWR   0x56
+#defineCC2520_CMD_BCLR 0x58
+#defineCC2520_CMD_BSET 0x59
+#defineCC2520_CMD_CTR_UCTR 0x60
+#defineCC2520_CMD_CBCMAC   0x64
+#defineCC2520_CMD_UCBCMAC  0x66
+#defineCC2520_CMD_CCM  0x68
+#defineCC2520_CMD_UCCM 0x6A
+#defineCC2520_CMD_ECB  0x70
+#defineCC2520_CMD_ECBO 0x72
+#defineCC2520_CMD_ECBX 0x74
+#defineCC2520_CMD_INC  0x78
+#defineCC2520_CMD_ABORT0x7F
+#defineCC2520_CMD_REGISTER_READ0x80
+#defineCC2520_CMD_REGISTER_WRITE   0xC0
+
+/* status registers */
+#defineCC2520_CHIPID   0x40
+#defineCC2520_VERSION  0x42
+#define

[x86_64,vsyscall] 21d4ab4881a: -11.1% will-it-scale.per_process_ops

[Jet Chen]

Hi Andy,

we noticed the below changes on

git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vsyscall
commit 21d4ab4881ad9b257bec75d04480105dad4336e1 ("x86_64,vsyscall: Move all of the 
gate_area code to vsyscall_64.c")

test case: lkp-wsx01/will-it-scale/signal1

a7781f1035319a7  21d4ab4881ad9b257bec75d04
---  -
259032 ~ 1% -11.1% 230288 ~ 0%  TOTAL will-it-scale.per_process_ops
  0.04 ~ 9%   +4276.2%   1.84 ~ 1%  TOTAL 
perf-profile.cpu-cycles.map_id_up.do_tkill.sys_tgkill.system_call_fastpath.raise
  2.36 ~ 0% -63.8%   0.85 ~ 2%  TOTAL 
perf-profile.cpu-cycles._atomic_dec_and_lock.free_uid.__sigqueue_free.__dequeue_signal.dequeue_signal
  2.25 ~14% -55.2%   1.01 ~ 1%  TOTAL perf-profile.cpu-cycles.raise
 42.41 ~ 0% +34.5%  57.04 ~ 0%  TOTAL 
perf-profile.cpu-cycles.__sigqueue_alloc.__send_signal.send_signal.do_send_sig_info.do_send_specific
 40.70 ~ 0% -23.9%  30.96 ~ 0%  TOTAL 
perf-profile.cpu-cycles.__sigqueue_free.part.11.__dequeue_signal.dequeue_signal.get_signal_to_deliver.do_signal
   252 ~11% -18.8%204 ~ 9%  TOTAL 
numa-vmstat.node1.nr_page_table_pages
  1012 ~11% -18.3%827 ~ 9%  TOTAL numa-meminfo.node1.PageTables
   520 ~ 7% -17.1%431 ~ 5%  TOTAL cpuidle.C1-NHM.usage

Legend:
~XX%- stddev percent
[+-]XX% - change percent


will-it-scale.per_process_ops

  27 ++-+
 |  |
  26 *+.*..*.. .*..  .*..  .*..*...  .*..   *..  .*..   *.. .*..*
 |*..*.*.*.*. ..   *. ..   *..*.|
  25 ++  *   *  |
 |  |
  24 ++ |
 |  |
  23 ++ O  O  O O  O   O O  O  O  O  O  |
 O   O O|
  22 ++   OO O  |
 |  O O O O |
  21 ++  O  |
 |  |
  20 ++-+


[*] bisect-good sample
[O] bisect-bad  sample


Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.

Thanks,
Jet

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu11/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu12/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu14/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu16/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu17/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu18/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu19/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu20/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu21/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu22/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu23/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu24/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu25/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu26/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu27/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu28/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu29/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu30/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu31/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu32/cpufreq/scaling_governor
echo performance > 

Re: [PATCH 3/9] mfd: palmas: Add tps65917 specific definitions and enums

[Keerthy]

On Tuesday 17 June 2014 09:41 PM, Lee Jones wrote:

Add tps65917 specific definitions and enums.

Signed-off-by: Keerthy 
---
  include/linux/mfd/palmas.h |  793 
  1 file changed, 793 insertions(+)

Acked-by: Lee Jones 


Thanks.




diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index ccbb21f..52a24a9 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -30,6 +30,8 @@
  #define PALMAS_CHIP_ID0xC035
  #define PALMAS_CHIP_CHARGER_ID0xC036
  
+#define TPS65917_RESERVED		-1

+
  #define is_palmas(a)  (((a) == PALMAS_CHIP_OLD_ID) || \
((a) == PALMAS_CHIP_ID))
  #define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
@@ -184,6 +186,27 @@ enum palmas_regulators {
PALMAS_NUM_REGS,
  };
  
+enum tps65917_regulators {

+   /* SMPS regulators */
+   TPS65917_REG_SMPS1,
+   TPS65917_REG_SMPS2,
+   TPS65917_REG_SMPS3,
+   TPS65917_REG_SMPS4,
+   TPS65917_REG_SMPS5,
+   /* LDO regulators */
+   TPS65917_REG_LDO1,
+   TPS65917_REG_LDO2,
+   TPS65917_REG_LDO3,
+   TPS65917_REG_LDO4,
+   TPS65917_REG_LDO5,
+   TPS65917_REG_REGEN1,
+   TPS65917_REG_REGEN2,
+   TPS65917_REG_REGEN3,
+
+   /* Total number of regulators */
+   TPS65917_NUM_REGS,
+};
+
  /* External controll signal name */
  enum {
PALMAS_EXT_CONTROL_ENABLE1  = 0x1,
@@ -228,6 +251,24 @@ enum palmas_external_requestor_id {
PALMAS_EXTERNAL_REQSTR_ID_MAX,
  };
  
+enum tps65917_external_requestor_id {

+   TPS65917_EXTERNAL_REQSTR_ID_REGEN1,
+   TPS65917_EXTERNAL_REQSTR_ID_REGEN2,
+   TPS65917_EXTERNAL_REQSTR_ID_REGEN3,
+   TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+   TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+   TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+   TPS65917_EXTERNAL_REQSTR_ID_SMPS4,
+   TPS65917_EXTERNAL_REQSTR_ID_SMPS5,
+   TPS65917_EXTERNAL_REQSTR_ID_LDO1,
+   TPS65917_EXTERNAL_REQSTR_ID_LDO2,
+   TPS65917_EXTERNAL_REQSTR_ID_LDO3,
+   TPS65917_EXTERNAL_REQSTR_ID_LDO4,
+   TPS65917_EXTERNAL_REQSTR_ID_LDO5,
+   /* Last entry */
+   TPS65917_EXTERNAL_REQSTR_ID_MAX,
+};
+
  struct palmas_pmic_platform_data {
/* An array of pointers to regulator init data indexed by regulator
 * ID
@@ -349,6 +390,48 @@ struct palmas_gpadc_result {
  
  #define PALMAS_MAX_CHANNELS 16
  
+/* Define the tps65917 IRQ numbers */

+enum tps65917_irqs {
+   /* INT1 registers */
+   TPS65917_RESERVED1,
+   TPS65917_PWRON_IRQ,
+   TPS65917_LONG_PRESS_KEY_IRQ,
+   TPS65917_RESERVED2,
+   TPS65917_PWRDOWN_IRQ,
+   TPS65917_HOTDIE_IRQ,
+   TPS65917_VSYS_MON_IRQ,
+   TPS65917_RESERVED3,
+   /* INT2 registers */
+   TPS65917_RESERVED4,
+   TPS65917_OTP_ERROR_IRQ,
+   TPS65917_WDT_IRQ,
+   TPS65917_RESERVED5,
+   TPS65917_RESET_IN_IRQ,
+   TPS65917_FSD_IRQ,
+   TPS65917_SHORT_IRQ,
+   TPS65917_RESERVED6,
+   /* INT3 registers */
+   TPS65917_GPADC_AUTO_0_IRQ,
+   TPS65917_GPADC_AUTO_1_IRQ,
+   TPS65917_GPADC_EOC_SW_IRQ,
+   TPS65917_RESREVED6,
+   TPS65917_RESERVED7,
+   TPS65917_RESERVED8,
+   TPS65917_RESERVED9,
+   TPS65917_VBUS_IRQ,
+   /* INT4 registers */
+   TPS65917_GPIO_0_IRQ,
+   TPS65917_GPIO_1_IRQ,
+   TPS65917_GPIO_2_IRQ,
+   TPS65917_GPIO_3_IRQ,
+   TPS65917_GPIO_4_IRQ,
+   TPS65917_GPIO_5_IRQ,
+   TPS65917_GPIO_6_IRQ,
+   TPS65917_RESERVED10,
+   /* Total Number IRQs */
+   TPS65917_NUM_IRQ,
+};
+
  /* Define the palmas IRQ numbers */
  enum palmas_irqs {
/* INT1 registers */
@@ -400,6 +483,7 @@ struct palmas_pmic {
  
  	int smps123;

int smps457;
+   int smps12;
  
  	int range[PALMAS_REG_SMPS10_OUT1];

unsigned int ramp_delay[PALMAS_REG_SMPS10_OUT1];
@@ -2871,6 +2955,715 @@ enum usb_irq_events {
  #define PALMAS_GPADC_TRIM15   0x0E
  #define PALMAS_GPADC_TRIM16   0x0F
  
+/* TPS65917 Interrupt registers */

+
+/* Registers for function INTERRUPT */
+#define TPS65917_INT1_STATUS   0x00
+#define TPS65917_INT1_MASK 0x01
+#define TPS65917_INT1_LINE_STATE   0x02
+#define TPS65917_INT2_STATUS   0x05
+#define TPS65917_INT2_MASK 0x06
+#define TPS65917_INT2_LINE_STATE   0x07
+#define TPS65917_INT3_STATUS   0x0A
+#define TPS65917_INT3_MASK 0x0B
+#define TPS65917_INT3_LINE_STATE   0x0C
+#define TPS65917_INT4_STATUS   0x0F
+#define TPS65917_INT4_MASK 0x10
+#define 

Re: [PATCH 4/9] mfd: palmas: Add tps65917 support

[Keerthy]

On Tuesday 17 June 2014 09:49 PM, Lee Jones wrote:

Add tps65917 PMIC support. tps65917 is a subset of palmas PMIC.
Some of the register definitions and the interrupt mappings
are different.

Signed-off-by: Keerthy 
---
  drivers/mfd/palmas.c |  176 --
  1 file changed, 171 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index d280d78..485d755 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c

[...]


+struct palmas_driver_data {
+   unsigned int *features;
+   struct regmap_irq_chip *irq_chip;
+};
+
+static struct palmas_driver_data palmas_data = {
+   .features = _features,
+   .irq_chip = _irq_chip,
+};
+
+static struct palmas_driver_data tps659038_data = {
+   .features = _features,
+   .irq_chip = _irq_chip,
+};
+
+static struct palmas_driver_data tps65917_data = {
+   .features = _features,
+   .irq_chip = _irq_chip,
+};
+

[...]


@@ -375,6 +539,7 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
  {
struct palmas *palmas;
struct palmas_platform_data *pdata;
+   struct palmas_driver_data *driver_data;
struct device_node *node = i2c->dev.of_node;
int ret = 0, i;
unsigned int reg, addr, *features;
@@ -408,7 +573,8 @@ static int palmas_i2c_probe(struct i2c_client *i2c,
if (!match)
return -ENODATA;
  
-	features = (unsigned int *)match->data;

+   driver_data = (struct palmas_driver_data *)match->data;
+   features = (unsigned int *)driver_data->features;
palmas->features = *features;

Couple of things a) I don't think the cast is required here and b) you
may as well do away with the local features variable here.

Just do:
   palmas->features = *driver_data->features;

Once fixed, re-submit with my:
   Acked-by: Lee Jones 


Sure. I will redo and send this set.
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/

[PATCH] arch/score/include/asm/io.h: Add generic io map functions when MMU enabled

[Chen Gang]

score did not implement some io map functions when MMU enabled, so need
add generic io map functions, just like some other architectures have
done (e.g. sparc64, s390, and mn10300), or will cause compiling issue.

The related error (allmodconfig under score):

CC  drivers/clocksource/sh_cmt.o
  drivers/clocksource/sh_cmt.c: In function 'sh_cmt_map_memory':
  drivers/clocksource/sh_cmt.c:932:2: error: implicit declaration of function 
'ioremap_nocache' [-Werror=implicit-function-declaration]
cmt->mapbase = ioremap_nocache(mem->start, resource_size(mem));
^
  drivers/clocksource/sh_cmt.c:932:15: warning: assignment makes pointer from 
integer without a cast
cmt->mapbase = ioremap_nocache(mem->start, resource_size(mem));
 ^
  drivers/clocksource/sh_cmt.c: In function 'sh_cmt_map_memory_legacy':
  drivers/clocksource/sh_cmt.c:953:18: warning: assignment makes pointer from 
integer without a cast
cmt->mapbase_ch = ioremap_nocache(res->start, resource_size(res));
^
  drivers/clocksource/sh_cmt.c:963:15: warning: assignment makes pointer from 
integer without a cast
cmt->mapbase = ioremap_nocache(res2 ? res2->start :
 ^
  drivers/clocksource/sh_cmt.c:968:3: error: implicit declaration of function 
'iounmap' [-Werror=implicit-function-declaration]
 iounmap(cmt->mapbase_ch);
 ^
  cc1: some warnings being treated as errors
  make[2]: *** [drivers/clocksource/sh_cmt.o] Error 1
  make[1]: *** [drivers/clocksource] Error 2
  make: *** [drivers] Error 2

Signed-off-by: Chen Gang 
---
 arch/score/include/asm/io.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/score/include/asm/io.h b/arch/score/include/asm/io.h
index 574c8827..d67aeea 100644
--- a/arch/score/include/asm/io.h
+++ b/arch/score/include/asm/io.h
@@ -3,6 +3,22 @@
 
 #include 
 
+#ifdef CONFIG_MMU
+static inline void __iomem *ioremap(phys_addr_t offset, unsigned long size)
+{
+   return (void __iomem *) (unsigned long)offset;
+}
+
+#define __ioremap(offset, size, flags) ioremap(offset, size)
+
+#define ioremap_nocache ioremap
+#define ioremap_wc ioremap_nocache
+
+static inline void iounmap(void __iomem *addr)
+{
+}
+#endif
+
 #define virt_to_busvirt_to_phys
 #define bus_to_virtphys_to_virt
 #endif /* _ASM_SCORE_IO_H */
-- 
1.9.2.459.g68773ac
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/9] regulator: palmas: Shift the reg_info structure definition to the header file

[Keerthy]

On Tuesday 17 June 2014 10:02 PM, Lee Jones wrote:

On Wed, 28 May 2014, Keerthy wrote:


Shift the reg_info structure definition to the header file.

Signed-off-by: Keerthy 
---
  drivers/regulator/palmas-regulator.c |9 -
  include/linux/mfd/palmas.h   |9 +
  2 files changed, 9 insertions(+), 9 deletions(-)

Patch looks fine.  I guess we'll wait and pull the entire set in once
it's ready.

Acked-by: Lee Jones 


Thanks.




diff --git a/drivers/regulator/palmas-regulator.c 
b/drivers/regulator/palmas-regulator.c
index 9602eba..d41f3de 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -27,15 +27,6 @@
  #include 
  #include 
  
-struct regs_info {

-   char*name;
-   char*sname;
-   u8  vsel_addr;
-   u8  ctrl_addr;
-   u8  tstep_addr;
-   int sleep_id;
-};
-
  static const struct regulator_linear_range smps_low_ranges[] = {
REGULATOR_LINEAR_RANGE(50, 0x1, 0x6, 0),
REGULATOR_LINEAR_RANGE(51, 0x7, 0x79, 1),
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 52a24a9..150a6314 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -88,6 +88,15 @@ struct palmas {
u8 pwm_muxed;
  };
  
+struct regs_info {

+   char*name;
+   char*sname;
+   u8  vsel_addr;
+   u8  ctrl_addr;
+   u8  tstep_addr;
+   int sleep_id;
+};
+
  struct palmas_gpadc_platform_data {
/* Channel 3 current source is only enabled during conversion */
int ch3_current;


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

Re: [PATCH 10/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC

[Simon Glass]

Hi Doug,

On 17 June 2014 21:54, Doug Anderson  wrote:
> Simon,
>
> On Tue, Jun 17, 2014 at 8:46 PM, Simon Glass  wrote:
>> Hi,
>>
>> On 16 June 2014 14:40, Doug Anderson  wrote:
>>> From: Bill Richardson 
>>>
>>> When communicating with the EC, the cmd_xfer() function should return the
>>> number of bytes it received from the EC, or negative on error.
>>
>> This is just for the I2C tunnel feature, right? If so, I think this
>> should be mentioned here. It seems to be affecting ec_i2c_xfer(), not
>> cmd_xfer().
>
> No, the tunnel feature is implemented just fine without this (and is
> already landed and working).  It looks like the (not yet upstreamed)
> ec_i2c_limited_xfer for spring returns this new value directly but I'm
> not convinced that's technicall correct.
>
> Bill can correct me if I'm wrong, but I think this is primarily
> interesting once we add in cros_ec_dev (the userspace API) which needs
> this info.  Until that happens this patch doesn't hurt and just
> returns some extra info.

Agreed.

Reviewed-by: Simon Glass 

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

Re: [PATCH 6/9] mfd: palmas: shift the palmas_sleep_requestor_info structure definition to the header file

[Keerthy]

On Tuesday 17 June 2014 10:03 PM, Lee Jones wrote:

On Wed, 28 May 2014, Keerthy wrote:


shift the palmas_sleep_requestor_info structure definition to the header file.

Signed-off-by: Keerthy 
---
  drivers/mfd/palmas.c   |   10 --
  include/linux/mfd/palmas.h |   10 ++
  2 files changed, 10 insertions(+), 10 deletions(-)

Acked-by: Lee Jones 


Thanks.




diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 485d755..f1f31d5 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,16 +25,6 @@
  #include 
  #include 
  
-#define PALMAS_EXT_REQ (PALMAS_EXT_CONTROL_ENABLE1 |	\

-   PALMAS_EXT_CONTROL_ENABLE2 |\
-   PALMAS_EXT_CONTROL_NSLEEP)
-
-struct palmas_sleep_requestor_info {
-   int id;
-   int reg_offset;
-   int bit_pos;
-};
-
  #define EXTERNAL_REQUESTOR(_id, _offset, _pos)\
[PALMAS_EXTERNAL_REQSTR_ID_##_id] = {   \
.id = PALMAS_EXTERNAL_REQSTR_ID_##_id,  \
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 150a6314..8d68452 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -88,6 +88,16 @@ struct palmas {
u8 pwm_muxed;
  };
  
+#define PALMAS_EXT_REQ (PALMAS_EXT_CONTROL_ENABLE1 |	\

+   PALMAS_EXT_CONTROL_ENABLE2 |\
+   PALMAS_EXT_CONTROL_NSLEEP)
+
+struct palmas_sleep_requestor_info {
+   int id;
+   int reg_offset;
+   int bit_pos;
+};
+
  struct regs_info {
char*name;
char*sname;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions

[Simon Glass]

Hi Doug,

On 17 June 2014 21:27, Doug Anderson  wrote:
> Simon,
>
> On Tue, Jun 17, 2014 at 8:42 PM, Simon Glass  wrote:
>>> diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
>>> b/drivers/input/keyboard/cros_ec_keyb.c
>>> index 4083796..dc37b6b 100644
>>> --- a/drivers/input/keyboard/cros_ec_keyb.c
>>> +++ b/drivers/input/keyboard/cros_ec_keyb.c
>>> @@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)
>>>
>>>  static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t 
>>> *kb_state)
>>>  {
>>> -   return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
>>> - kb_state, ckdev->cols);
>>> +   int ret;
>>> +   struct cros_ec_command msg = {
>>> +   .version = 0,
>>> +   .command = EC_CMD_MKBP_STATE,
>>> +   .outdata = NULL,
>>> +   .outsize = 0,
>>> +   .indata = kb_state,
>>> +   .insize = ckdev->cols,
>>> +   };
>>> +
>>> +   ret = ckdev->ec->cmd_xfer(ckdev->ec, );
>>
>> Do we need ret?
>
> No.  If you wish I will spin without it.  Let me know.
>
> Note that locally this code includes a comment between the above and the 
> return:
>   /* FIXME: This assumes msg.result == EC_RES_SUCCESS */

It's not important to me, and you've explained the other question.

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

[RESEND PATCH] dt-bindings: extcon: Add support for SM5502 MUIC device

[Chanwoo Choi]

This patch add documentation for binding of SM5502 MUIC (Micro-USB Interface
Controller) device which is using EXTCON subsystem. The SM5502 MUIC device
can detect various external accessories when external accessories is attached
or detached.

Signed-off-by: Chanwoo Choi 
---
 .../devicetree/bindings/extcon/extcon-sm5502.txt   | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-sm5502.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt 
b/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt
new file mode 100644
index 000..4ecda22
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt
@@ -0,0 +1,23 @@
+
+* SM5502 MUIC (Micro-USB Interface Controller) device
+
+The Silicon Mitus SM5502 is a MUIC (Micro-USB Interface Controller) device
+which can detect the state of external accessory when external accessory is
+attached or detached and button is pressed or released. It is interfaced to
+the host controller using an I2C interface.
+
+Required properties:
+- compatible: Should be "siliconmitus,sm5502-muic"
+- reg: Specifies the I2C slave address of the MUIC block. It should be 0x25
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+  the interrupts from sm5502 are delivered to.
+- interrupts: Interrupt specifiers for detection interrupt sources.
+
+Example:
+
+   sm5502@25 {
+   compatible = "siliconmitus,sm5502-muic";
+   interrupt-parent = <>;
+   interrupts = <5 0>;
+   reg = <0x25>;
+   };
-- 
1.8.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 7/9] regulator: palmas: Add palmas_pmic_driver_data structure

[Keerthy]

On Tuesday 17 June 2014 10:07 PM, Lee Jones wrote:

On Wed, 28 May 2014, Keerthy wrote:


Add palmas_pmic_driver_data structure.

Signed-off-by: Keerthy 
---
  include/linux/mfd/palmas.h |   25 +
  1 file changed, 25 insertions(+)

diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 8d68452..70f0695 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -53,6 +53,8 @@ struct palmas_pmic;
  struct palmas_gpadc;
  struct palmas_resource;
  struct palmas_usb;
+struct palmas_pmic_driver_data;
+struct palmas_pmic_platform_data;
  
  enum palmas_usb_state {

PALMAS_USB_STATE_DISCONNECT,
@@ -76,6 +78,8 @@ struct palmas {
struct mutex irq_lock;
struct regmap_irq_chip_data *irq_data;
  
+	struct palmas_pmic_driver_data *pmic_ddata;

+
/* Child Devices */
struct palmas_pmic *pmic;
struct palmas_gpadc *gpadc;
@@ -107,6 +111,27 @@ struct regs_info {
int sleep_id;
  };
  
+struct palmas_pmic_driver_data {

+   int smps_start;
+   int smps_end;
+   int ldo_begin;
+   int ldo_end;
+   int max_reg;
+   struct regs_info *palmas_regs_info;
+   struct of_regulator_match *palmas_matches;
+   struct palmas_sleep_requestor_info *sleep_req_info;
+   int (*smps_register)(struct palmas_pmic *pmic,
+struct palmas_pmic_driver_data *ddata,
+struct palmas_pmic_platform_data *pdata,
+const char *pdev_name,
+struct regulator_config config);
+   int (*ldo_register)(struct palmas_pmic *pmic,
+   struct palmas_pmic_driver_data *ddata,
+   struct palmas_pmic_platform_data *pdata,
+   const char *pdev_name,
+   struct regulator_config config);

Are you sure you need to store all of this stuff?

Particularly the match pointer.  Do you really re-use it?


Match pointer is used extensively in the palmas_regulator.c.
This structure is very much used by regulator driver.




+};
+
  struct palmas_gpadc_platform_data {
/* Channel 3 current source is only enabled during conversion */
int ch3_current;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/9] regulator: palmas: add driver data and modularize the probe

[Keerthy]

On Tuesday 17 June 2014 10:15 PM, Lee Jones wrote:

add driver data and modularize the probe.

Signed-off-by: Keerthy 
---
  drivers/mfd/palmas.c |   42 +--
  drivers/regulator/palmas-regulator.c |  656 --
  2 files changed, 395 insertions(+), 303 deletions(-)

diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c

[...]


@@ -370,6 +334,8 @@ int palmas_ext_control_req_config(struct palmas *palmas,
int bit_pos;
int ret;
  
+	struct palmas_pmic_driver_data *pmic_ddata = palmas->pmic_ddata;

+

Nit: I'd prefer the declarations to be grouped together, normally with
the struct defines above the ints etc.


Ok. I will change this.



[...]



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

Re: [PATCH 10/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC

[Doug Anderson]

Simon,

On Tue, Jun 17, 2014 at 8:46 PM, Simon Glass  wrote:
> Hi,
>
> On 16 June 2014 14:40, Doug Anderson  wrote:
>> From: Bill Richardson 
>>
>> When communicating with the EC, the cmd_xfer() function should return the
>> number of bytes it received from the EC, or negative on error.
>
> This is just for the I2C tunnel feature, right? If so, I think this
> should be mentioned here. It seems to be affecting ec_i2c_xfer(), not
> cmd_xfer().

No, the tunnel feature is implemented just fine without this (and is
already landed and working).  It looks like the (not yet upstreamed)
ec_i2c_limited_xfer for spring returns this new value directly but I'm
not convinced that's technicall correct.

Bill can correct me if I'm wrong, but I think this is primarily
interesting once we add in cros_ec_dev (the userspace API) which needs
this info.  Until that happens this patch doesn't hurt and just
returns some extra info.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: select 'idle' cfs_rq per task-group to prevent tg-internal imbalance

[Michael wang]

By testing we found that after put benchmark (dbench) in to deep cpu-group,
tasks (dbench routines) start to gathered on one CPU, which lead to that the
benchmark could only get around 100% CPU whatever how big it's task-group's
share is, here is the link of the way to reproduce the issue:

https://lkml.org/lkml/2014/5/16/4

Please note that our comparison was based on the same workload, the only
difference is we put the workload one level deeper, and dbench could only
got 1/3 of the CPU% it used to have, the throughput dropped to half.

The dbench got less CPU since all it's instances start to gathering on the
same CPU more often than before, and in such cases, whatever how big their
share is, only one CPU they could occupy.

This is caused by that when dbench is in deep-group, the balance between
it's gathering speed (depends on wake-affine) and spreading speed (depends
on load-balance) was broken, that is more gathering chances while less
spreading chances.

Since after put dbench into deep group, it's representive load in root-group
become less, which make it harder to break the load balance of system, this
is a comparison between dbench root-load and system-tasks (besides dbench)
load, for eg:

sg0 sg1
cpu0cpu1cpu2cpu3

kworker/0:0 kworker/1:0 kworker/2:0 kworker/3:0
kworker/0:1 kworker/1:1 kworker/2:1 kworker/3:1
dbench
dbench
dbench
dbench
dbench
dbench

Here without dbench, the load between sg is already balanced, which is:

4096:4096

When dbench is in one of the three cpu-cgroups on level 1, it's root-load
is 1024/6, so we have:

sg0
4096 + 6 * (1024 / 6)
sg1
4096

sg0 : sg1 == 5120 : 4096 == 125%

bigger than imbalance-pct (117% for eg), dbench spread to sg1


When dbench is in one of the three cpu-cgroups on level 2, it's root-load
is 1024/18, now we have:

sg0
4096 + 6 * (1024 / 18)
sg1
4096

sg0 : sg1 ~= 4437 : 4096 ~= 108%

smaller than imbalance-pct (same the 117%), dbench keep gathering in sg0

Thus load-balance routine become inactively on spreading dbench to other CPU,
and it's routine keep gathering on CPU more longer than before.

This patch try to select 'idle' cfs_rq inside task's cpu-group when there is no
idle CPU located by select_idle_sibling(), instead of return the 'target'
arbitrarily, this recheck help us to reserve the effect of load-balance longer,
and help to make the system more balance.

Like in the example above, the fix now will make things as:
1. dbench instances will be 'balanced' inside tg, ideally each cpu will
   have one instance.
2. if 1 do make the load become imbalance, load-balance routine will do
   it's job and move instances to proper CPU.
3. after 2 was done, the target CPU will always be preferred as long as
   it only got one instance.

Although for tasks like dbench, 2 is rarely happened, while combined with 3, we
will finally locate a good CPU for each instance which make both internal and
external balanced.

After applied this patch, the behaviour of dbench in deep cpu-group become
normal, the dbench throughput was back.

Tested benchmarks like ebizzy, kbench, dbench on X86 12-CPU server, the patch
works well and no regression showup.

Highlight:
With out a fix, any similar workload like dbench will face the same
issue that the cpu-cgroup share lost it's effect

This may not just be an issue of cgroup, whenever we have tasks which
with small-load, play quick flip on each other, they may gathering.

Please let me know if you have any questions on whatever the issue or the fix,
comments are welcomed ;-)

CC: Ingo Molnar 
CC: Peter Zijlstra 
Signed-off-by: Michael Wang 
---
 kernel/sched/fair.c |   81 +++
 1 file changed, 81 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fea7d33..e1381cd 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4409,6 +4409,62 @@ find_idlest_cpu(struct sched_group *group, struct 
task_struct *p, int this_cpu)
return idlest;
 }
 
+static inline int tg_idle_cpu(struct task_group *tg, int cpu)
+{
+   return !tg->cfs_rq[cpu]->nr_running;
+}
+
+/*
+ * Try and locate an idle CPU in the sched_domain from tg's view.
+ *
+ * Although gathered on same CPU and spread accross CPUs could make
+ * no difference from highest group's view, this will cause the tasks
+ * starving, even they have enough share to fight for CPU, they only
+ * got one battle filed, which means whatever how big their weight is,
+ * they totally got one CPU at maximum.
+ *
+ * Thus when system is busy, we filtered out those tasks which couldn't
+ * 

[PATCH] pinctrl: qcom: Add BUS_HOLD pin bias

[Andy Gross]

This patch adds the BUS_HOLD (Keeper) bias option for pins.

Signed-off-by: Andy Gross 
---
 drivers/pinctrl/pinctrl-msm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
index e43fbce..9aa2839 100644
--- a/drivers/pinctrl/pinctrl-msm.c
+++ b/drivers/pinctrl/pinctrl-msm.c
@@ -206,6 +206,7 @@ static int msm_config_reg(struct msm_pinctrl *pctrl,
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
case PIN_CONFIG_BIAS_PULL_DOWN:
+   case PIN_CONFIG_BIAS_BUS_HOLD:
case PIN_CONFIG_BIAS_PULL_UP:
*bit = g->pull_bit;
*mask = 3;
@@ -243,6 +244,7 @@ static int msm_config_set(struct pinctrl_dev *pctldev, 
unsigned int pin,
 
 #define MSM_NO_PULL0
 #define MSM_PULL_DOWN  1
+#define MSM_KEEPER 2
 #define MSM_PULL_UP3
 
 static unsigned msm_regval_to_drive(u32 val)
@@ -280,6 +282,9 @@ static int msm_config_group_get(struct pinctrl_dev *pctldev,
case PIN_CONFIG_BIAS_PULL_DOWN:
arg = arg == MSM_PULL_DOWN;
break;
+   case PIN_CONFIG_BIAS_BUS_HOLD:
+   arg = arg == MSM_KEEPER;
+   break;
case PIN_CONFIG_BIAS_PULL_UP:
arg = arg == MSM_PULL_UP;
break;
@@ -339,6 +344,9 @@ static int msm_config_group_set(struct pinctrl_dev *pctldev,
case PIN_CONFIG_BIAS_PULL_DOWN:
arg = MSM_PULL_DOWN;
break;
+   case PIN_CONFIG_BIAS_BUS_HOLD:
+   arg = MSM_KEEPER;
+   break;
case PIN_CONFIG_BIAS_PULL_UP:
arg = MSM_PULL_UP;
break;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [bisected] pre-3.16 regression on open() scalability

[Paul E. McKenney]

On Tue, Jun 17, 2014 at 07:27:31PM -0700, Andi Kleen wrote:
> > OK.  What would you suggest instead?  If all we do is to revert the
> 
> Hang checker should have two timer phases:
> 
> Timer fires first time:
> - Save context switch counter on that. Force a reschedule to some
> work queue. Rearm timer
> 
> Timer fires again:
> - Check reschedule count. If the reschedule count changed
> it was a real hang, otherwise ignore.

I could take that approach, but the RT guys aren't going to thank me for
the wakeup associated with the work queue.  I suppose that I could use
one approach for real-time workloads and your workqueue-base approach
for other workloads.

Still, I bet I can drop the common-case cond_resched() overhead to a
single read of a per-CPU variable and a branch.  But yes, that would be
in response to the second phase, FWIW.  If that measurably too much
overhead, then one thing for realtime and another otherwise.

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/

Re: [PATCH 09/10] mfd: cros_ec: Check result code from EC messages

[Doug Anderson]

Simon,

On Tue, Jun 17, 2014 at 8:43 PM, Simon Glass  wrote:
>> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
>> index 09ca789..4d34f1c 100644
>> --- a/drivers/mfd/cros_ec_spi.c
>> +++ b/drivers/mfd/cros_ec_spi.c
>> @@ -289,21 +289,23 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device 
>> *ec_dev,
>> goto exit;
>> }
>>
>> -   /* check response error code */
>> ptr = ec_dev->din;
>> -   if (ptr[0]) {
>> -   if (ptr[0] == EC_RES_IN_PROGRESS) {
>> -   dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
>> -   ec_msg->command);
>> -   ret = -EAGAIN;
>> -   goto exit;
>> -   }
>> -   dev_warn(ec_dev->dev, "command 0x%02x returned an error 
>> %d\n",
>> -ec_msg->command, ptr[0]);
>> -   debug_packet(ec_dev->dev, "in_err", ptr, len);
>> -   ret = -EINVAL;
>> +
>> +   /* check response error code */
>> +   ec_msg->result = ptr[0];
>> +   switch (ec_msg->result) {
>> +   case EC_RES_SUCCESS:
>> +   break;
>> +   case EC_RES_IN_PROGRESS:
>> +   ret = -EAGAIN;
>> +   dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
>> +   ec_msg->command);
>> goto exit;
>> +   default:
>> +   dev_warn(ec_dev->dev, "command 0x%02x returned %d\n",
>> +ec_msg->command, ec_msg->result);
>> }
>
> Since this code is the same as the above, should it go in a common
> function in cros_ec?

So you are thinking it should be written like:

ec_msg->result = ptr[0];
ret = cros_ec_check_result(ec_dev, ec_msg);
if (ret)
  goto exit;

---

int cros_ec_check_result(struct cros_ec_device *ec_dev, struct
cros_ec_command *ec_msg)
{
   switch (ec_msg->result) {
   case EC_RES_SUCCESS:
   return 0;
   case EC_RES_IN_PROGRESS:
   dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
   ec_msg->command);
   return -EAGAIN;
   default:
   dev_warn(ec_dev->dev, "command 0x%02x returned %d\n",
ec_msg->command, ec_msg->result);
   return 0;
}

OK, that seems reasonable.  I'll plan to spin tomorrow with that.

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

Re: Build regressions/improvements in v3.16-rc1

[Guenter Roeck]

On 06/17/2014 08:23 AM, Geert Uytterhoeven wrote:

On Tue, Jun 17, 2014 at 5:16 PM, Geert Uytterhoeven
 wrote:

[...]



   + /scratch/kisskb/src/sound/soc/fsl/fsl_dma.c: error: invalid use of undefined 
type 'struct ccsr_ssi':  => 926:34, 927:34


powerpc/mpc85xx_defconfig



Being fixed:
http://patchwork.ozlabs.org/patch/358500/

Guenter

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

Re: [RESEND] shm: shm exit scalability fixes

[Michael Ellerman]

On Wed, 2014-06-18 at 12:53 +1000, Anton Blanchard wrote:
> > I normally wouldn't mind optimizing synthetic cases like this, but a
> > quick look at patch 1/3 shows that we're adding an extra overhead (16
> > bytes) in the task_struct.
> 
> > We have the shmmni limit (and friends) for that.
> 
> If we want to use this to guard against the problem, we may need to
> drop shmmni. Looking at my notes, I could take down a box with 4096
> segments and 16 threads. This is where I got to before it disappeared:
> 
> # ./bust_shm_exit 4096 16
> # uptime
> 03:00:50 up 8 days, 18:05  5 users,load average: 6076.98, 2494.09, 910.37

I win, using 4096 segments and 16 threads:

 # uptime
 13:50:46 up 1 day, 19:41,  2 users,  load average: 7621.57, 1718.39, 943.13
 13:52:35 up 1 day, 19:43,  2 users,  load average: 15422.64, 7409.90, 3156.82

That's on a 16 cpu box running 3.16-rc1.

In contrast, if you run it with 1 segment and 16 threads it maxes out about:

 # uptime
 13:58:00 up 1 min,  2 users,  load average: 1.81, 0.46, 0.15

And the box is entirely responsive.

cheers


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/10] mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device

[Doug Anderson]

Simon,

On Tue, Jun 17, 2014 at 9:25 PM, Simon Glass  wrote:
> Hi Doug,
>
> On 17 June 2014 21:22, Doug Anderson  wrote:
>>
>> Simon,
>>
>> On Tue, Jun 17, 2014 at 8:39 PM, Simon Glass  wrote:
>> > Hi Doug,
>> >
>> > On 16 June 2014 14:39, Doug Anderson  wrote:
>> >> From: Bill Richardson 
>> >>
>> >> struct cros_ec_device has a superfluous "name" field. We can get all the
>> >> debugging info we need from the existing ec_name and phys_name fields, so
>> >> let's take out the extra field.
>> >
>> > Except that it no longer prints I2C/SPI - i.e. the transport that is
>> > used. Is that not considered important?
>>
>> Before this change:
>>   [1.895472] cros-ec-spi spi2.0: Chrome EC (SPI)
>>
>> After this change:
>>   [1.910671] cros-ec-spi spi2.0: Chrome EC device registered
>>
>>
>> I think having SPI in the name twice is probably enough.  ;)
>
> Ah that helps! Could have been in the commit message.
>
> Reviewed-by: Simon Glass 

If I re-spin the series I'll add it.  I think the new message was in
the original commit in the "TEST=" clause and I left it out.  I
probably should have added it in with the proper wording...

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions

[Doug Anderson]

Simon,

On Tue, Jun 17, 2014 at 8:42 PM, Simon Glass  wrote:
>> diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
>> b/drivers/input/keyboard/cros_ec_keyb.c
>> index 4083796..dc37b6b 100644
>> --- a/drivers/input/keyboard/cros_ec_keyb.c
>> +++ b/drivers/input/keyboard/cros_ec_keyb.c
>> @@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)
>>
>>  static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t 
>> *kb_state)
>>  {
>> -   return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
>> - kb_state, ckdev->cols);
>> +   int ret;
>> +   struct cros_ec_command msg = {
>> +   .version = 0,
>> +   .command = EC_CMD_MKBP_STATE,
>> +   .outdata = NULL,
>> +   .outsize = 0,
>> +   .indata = kb_state,
>> +   .insize = ckdev->cols,
>> +   };
>> +
>> +   ret = ckdev->ec->cmd_xfer(ckdev->ec, );
>
> Do we need ret?

No.  If you wish I will spin without it.  Let me know.

Note that locally this code includes a comment between the above and the return:
  /* FIXME: This assumes msg.result == EC_RES_SUCCESS */

Given that this is not a new problem introduced in this code, that it
still hasn't been fixed locally in the ChromeOS tree, and that
generally FIXMEs don't seem to be left in the code upstream, I left it
out.

>> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
>> index 2b0c598..60c0880 100644
>> --- a/include/linux/mfd/cros_ec.h
>> +++ b/include/linux/mfd/cros_ec.h
>> @@ -63,9 +63,10 @@ struct cros_ec_command {
>>   * @was_wake_device: true if this device was set to wake the system from
>>   * sleep at the last suspend
>>   * @event_notifier: interrupt event notifier for transport devices
>> - * @command_send: send a command
>> - * @command_recv: receive a response
>> - * @command_sendrecv: send a command and receive a response
>> + * @cmd_xfer: send command to EC and get response
>> + * Returns 0 if the communication succeeded, but that doesn't mean the 
>> EC
>> + * was happy with the command it got. Caller should check msg.result for
>> + * the EC's result code.
>>   *
>>   * @priv: Private data
>>   * @irq: Interrupt to use
>> @@ -83,7 +84,6 @@ struct cros_ec_command {
>>   * @parent: pointer to parent device (e.g. i2c or spi device)
>>   * @wake_enabled: true if this device can wake the system from sleep
>>   * @lock: one transaction at a time
>> - * @cmd_xfer: low-level channel to the EC
>>   */
>>  struct cros_ec_device {
>>
>> @@ -94,13 +94,8 @@ struct cros_ec_device {
>> bool was_wake_device;
>> struct class *cros_class;
>> struct blocking_notifier_head event_notifier;
>> -   int (*command_send)(struct cros_ec_device *ec,
>> -   uint16_t cmd, void *out_buf, int out_len);
>> -   int (*command_recv)(struct cros_ec_device *ec,
>> -   uint16_t cmd, void *in_buf, int in_len);
>> -   int (*command_sendrecv)(struct cros_ec_device *ec,
>> -   uint16_t cmd, void *out_buf, int out_len,
>> -   void *in_buf, int in_len);
>> +   int (*cmd_xfer)(struct cros_ec_device *ec,
>> +   struct cros_ec_command *msg);
>>
>> /* These are used to implement the platform-specific interface */
>> void *priv;
>> @@ -112,8 +107,6 @@ struct cros_ec_device {
>> struct device *parent;
>> bool wake_enabled;
>> struct mutex lock;
>> -   int (*cmd_xfer)(struct cros_ec_device *ec,
>> -   struct cros_ec_command *msg);
>
> Seems odd - maybe this line move of cmd_xfer() should be in an earlier patch?

It got moved from "private" to public.  Bill reorganized all the
public stuff at the top and the private at the bottom.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/10] mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device

[Simon Glass]

Hi Doug,

On 17 June 2014 21:22, Doug Anderson  wrote:
>
> Simon,
>
> On Tue, Jun 17, 2014 at 8:39 PM, Simon Glass  wrote:
> > Hi Doug,
> >
> > On 16 June 2014 14:39, Doug Anderson  wrote:
> >> From: Bill Richardson 
> >>
> >> struct cros_ec_device has a superfluous "name" field. We can get all the
> >> debugging info we need from the existing ec_name and phys_name fields, so
> >> let's take out the extra field.
> >
> > Except that it no longer prints I2C/SPI - i.e. the transport that is
> > used. Is that not considered important?
>
> Before this change:
>   [1.895472] cros-ec-spi spi2.0: Chrome EC (SPI)
>
> After this change:
>   [1.910671] cros-ec-spi spi2.0: Chrome EC device registered
>
>
> I think having SPI in the name twice is probably enough.  ;)

Ah that helps! Could have been in the commit message.

Reviewed-by: Simon Glass 

Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: vdso_install target broken post-3.15

[Andy Lutomirski]

On Tue, Jun 17, 2014 at 8:48 PM, H. Peter Anvin  wrote:
> On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
>> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski  wrote:
>>> Just a heads up: gdb can't debug the vdso on 3.16-rc1.  I filed a bug:
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17064
>>>
>>> We may need to extend the fake section header hack to all vdso
>>> versions and stick the ELF notes in there.
>>
>> I have a semi-working implementation of a workaround, bit it adds a
>> fair amount of extra crud to the image, and it's pushing my
>> configuration past a page boundary.  I suspect that, if we're willing
>> to abuse the ELF format a bit more, I can get the overhead down,
>> though.
>>
>> Are we okay with regressing here until binutils gets fixed?
>>
>
> Probably not... although I guess it depends just how bad it really is.

AFAICT the only issue is that gdb will fail to find installed debug
info on systems that install it into .build-id, which AFAIK means
Fedora and similar users who install kernel RPMs.  This won't effect
anyone who installs their own kernel, since it never worked correctly
for those users anyway.

Fortunately, Fedora ought to be able to update its gdb and/or binutils
rpm by the time that 3.16 kernel RPMs show up.  Josh, is this
workable?  In my experience, I've never had a sourceware.org bug
fixed, but I have had bugzilla.redhat.org bugs fixed.  I'm looking at
the binutils code, and I'm kind of scared of it.  Also, I don't have
an FSF copyright assignment on file.

I filed this Fedora bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1110598

Let's see what happens.  Can we give this a little while?

I wrote this:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/vdso_sections

but it's bad: I'm not allocating space properly, so it doesn't
reliably build.  Also, it wastes space, and I'd rather just get rid of
this crap.

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

Re: [PATCH 07/10] mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device

[Doug Anderson]

Simon,

On Tue, Jun 17, 2014 at 8:39 PM, Simon Glass  wrote:
> Hi Doug,
>
> On 16 June 2014 14:39, Doug Anderson  wrote:
>> From: Bill Richardson 
>>
>> struct cros_ec_device has a superfluous "name" field. We can get all the
>> debugging info we need from the existing ec_name and phys_name fields, so
>> let's take out the extra field.
>
> Except that it no longer prints I2C/SPI - i.e. the transport that is
> used. Is that not considered important?

Before this change:
  [1.895472] cros-ec-spi spi2.0: Chrome EC (SPI)

After this change:
  [1.910671] cros-ec-spi spi2.0: Chrome EC device registered


I think having SPI in the name twice is probably enough.  ;)

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/10] mfd: cros_ec: Tweak struct cros_ec_device for clarity

[Doug Anderson]

Simon,

On Tue, Jun 17, 2014 at 8:35 PM, Simon Glass  wrote:
> Hi Doug,
>
> On 16 June 2014 14:39, Doug Anderson  wrote:
>> From: Bill Richardson 
>>
>> The members of struct cros_ec_device were improperly commented, and
>> intermixed the private and public sections. This is just cleanup to make it
>> more obvious what goes with what.
>>
>> [dianders: left lock in the structure but gave it the name that will
>> eventually be used.]
>>
>> Signed-off-by: Bill Richardson 
>> Signed-off-by: Doug Anderson 
>> ---
>>  drivers/mfd/cros_ec.c   |  2 +-
>>  drivers/mfd/cros_ec_i2c.c   |  4 +--
>>  drivers/mfd/cros_ec_spi.c   | 10 +++
>>  include/linux/mfd/cros_ec.h | 65 
>> -
>>  4 files changed, 43 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
>> index bd6f936..a9eede5 100644
>> --- a/drivers/mfd/cros_ec.c
>> +++ b/drivers/mfd/cros_ec.c
>> @@ -57,7 +57,7 @@ static int cros_ec_command_sendrecv(struct cros_ec_device 
>> *ec_dev,
>> msg.in_buf = in_buf;
>> msg.in_len = in_len;
>>
>> -   return ec_dev->command_xfer(ec_dev, );
>> +   return ec_dev->cmd_xfer(ec_dev, );
>
> Why do this rename? It makes it different from the other members.

All I know of the history of this change is at
.  My best guess is that Bill was trying
to differentiate public vs. private function pointers.  Perhaps he
will chime in.

If it helps the other command_xxx() function pointers are removed in
the later "mfd: cros_ec: cleanup: Remove EC wrapper functions"

If you wish I can skip this rename, just let me know and it won't be
too much trouble.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [RFT v5h printk: allow increasing the ring buffer depending on the number of CPUs

[Luis R. Rodriguez]

On Tue, Jun 17, 2014 at 5:18 PM, Luis R. Rodriguez  wrote:
> @@ -828,29 +829,68 @@ void log_buf_kexec_setup(void)
>  /* requested log_buf_len from kernel cmdline */
>  static unsigned long __initdata new_log_buf_len;
>
> -/* save requested log_buf_len since it's too early to process it */
> -static int __init log_buf_len_setup(char *str)
> +/*
> + * CONFIG_LOG_BUF_SHIFT would be architecture aligned, anything > than it and
> + * a multiple of two of it upkeeps the alignment.
> + */
> +static void __init log_buf_len_align(unsigned size)
>  {
> -   unsigned size = memparse(str, );
> -
> if (size)
> size = roundup_pow_of_two(size);
> if (size > log_buf_len)
> new_log_buf_len = size;
> +}
> +
> +/* save requested log_buf_len since it's too early to process it */
> +static int __init log_buf_len_setup(char *str)
> +{
> +   unsigned size = memparse(str, );
> +
> +   log_buf_len_align(size);
>
> return 0;
>  }
>  early_param("log_buf_len", log_buf_len_setup);

This could go as a separate patch first too, which would make the
addition very clean.

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

Re: [RFC PATCH 2/2] block: virtio-blk: support multi virt queues per virtio-blk device

[Ming Lei]

On Wed, Jun 18, 2014 at 12:34 AM, Paolo Bonzini  wrote:
> Il 17/06/2014 18:00, Ming Lei ha scritto:
>
>>> > If you want to do queue steering based on the guest VCPU number, the
>>> > number
>>> > of queues must be = to the number of VCPUs shouldn't it?
>>> >
>>> > I tried using a divisor of the number of VCPUs, but couldn't get the
>>> > block
>>> > layer to deliver interrupts to the right VCPU.
>>
>> For blk-mq's hardware queue, that won't be necessary to equal to
>> VCPUs number, and irq affinity per hw queue can be simply set as
>> blk_mq_hw_ctx->cpumask.
>
>
> Yes, but on top of that you want to have each request processed exactly by
> the CPU that sent it.  Unless the cpumasks are singletons, most of the
> benefit went away in my virtio-scsi tests.  Perhaps blk-mq is smarter.
>
> Can you try benchmarking a 16 VCPU guest with 8 and 16 queues?

>From VM side, it might be better to use one hardware queue per vCPU,
since in theory it can remove vq lock contention.

But from host side, there is still disadvantage with more queues, since
more queues means more notify times, in my virtio-blk test, even with
ioeventfd, one notification may take ~3us averagely on qemu-system-x86_64.

For virtio-blk, I don't think it is always better to take more queues, and
we need to leverage below things in host side:

- host storage top performance, generally it reaches that with more
than 1 jobs with libaio(suppose it is N, so basically we can use N
iothread per device in qemu to try to get top performance)

- iothreads' loading(if iothreads are at full loading, increasing
queues doesn't help at all)

In my test, I only use the current per-dev iothread(x-dataplane)
in qemu to handle 2 vqs' notification and precess all I/O from
the 2 vqs, and looks it can improve IOPS by ~30%.

For virtio-scsi, the current usage doesn't make full use of blk-mq's
advantage too because only one vq is active at the same time, so I
guess the multi vqs' benefit won't be very much and I'd like to post
patches to support that first, then provide test data with
more queues(8, 16).


Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 Jun 18

[Stephen Rothwell]

Hi all,

The powerpc allyesconfig is again broken more than usual.

Changes since 20140617:

Non-merge commits (relative to Linus' tree): 868
 1021 files changed, 24269 insertions(+), 14775 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (ebe06187bf2a epoll: fix use-after-free in 
eventpoll_release_file)
Merging fixes/master (4b660a7f5c80 Linux 3.15-rc6)
Merging kbuild-current/rc-fixes (7171511eaec5 Linux 3.16-rc1)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (870cbe8cb204 ARM: 8069/1: Make thread_save_fp macro 
aware of THUMB2 mode)
Merging m68k-current/for-linus (e8d6dc5ad26e m68k/hp300: Convert printk to 
pr_foo())
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (68986c9f0f45 Revert "offb: Add palette hack for 
little endian")
Merging sparc/master (8ecc1bad4c9b sparc64: fix format string mismatch in 
arch/sparc/kernel/sysfs.c)
Merging net/master (bc56151d07ea ptp: ptp_pch depends on x86_32)
Merging ipsec/master (7171511eaec5 Linux 3.16-rc1)
Merging sound-current/for-linus (74b0c2d75fb4 drm/i915, HD-audio: Don't 
continue probing when nomodeset is given)
Merging pci-current/for-linus (7171511eaec5 Linux 3.16-rc1)
Merging wireless/master (616a8394b5df rt2x00: fix rfkill regression on 
rt2500pci)
Merging driver-core.current/driver-core-linus (7171511eaec5 Linux 3.16-rc1)
Merging tty.current/tty-linus (7171511eaec5 Linux 3.16-rc1)
Merging usb.current/usb-linus (7171511eaec5 Linux 3.16-rc1)
Merging usb-gadget-fixes/fixes (886c7c426d46 usb: gadget: at91-udc: fix irq and 
iomem resource retrieval)
Merging staging.current/staging-linus (c44b33b72133 staging: rtl8723au: 
Reference correct firmwarefiles with MODULE_FIRMWARE())
Merging char-misc.current/char-misc-linus (b29f680c4fe3 Revert "uio: fix vma io 
range check in mmap")
Merging input-current/for-linus (31972f6e517d Input: ti_am335x_tsc - warn about 
incorrect spelling)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode 
concurrency finding.)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (4b660a7f5c80 Linux 3.15-rc6)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for-linux-next-fixes (15d24aa5602f drm/i915: BDW: 
Adding missing cursor offsets.)
Merging asm-generic/master (fb9de7ebc3a2 xtensa: Use generic asm/mmu.h for 
nommu)
Merging arc/for-next (230a15f171ba ARC: remove checks for CONFIG_ARC_MMU_V4)
Merging arm/for-next (a6d997d18aa4 Merge branches 'fixes' and 'misc' into 
for-next)
Merging arm-perf/for-next/perf (7171511eaec5 Linux 3.16-rc1)
Merging arm-soc/for-next (f2592714cddc ARM: use menuconfig for sub-arch menus)
Merging bcm2835/for-next (fa389e220254 Linux 3.14-rc6)
Merging berlin/berlin/for-next (251f72d06c59 Merge 

Re: vdso_install target broken post-3.15

[H. Peter Anvin]

On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski  wrote:
>> Just a heads up: gdb can't debug the vdso on 3.16-rc1.  I filed a bug:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17064
>>
>> We may need to extend the fake section header hack to all vdso
>> versions and stick the ELF notes in there.
> 
> I have a semi-working implementation of a workaround, bit it adds a
> fair amount of extra crud to the image, and it's pushing my
> configuration past a page boundary.  I suspect that, if we're willing
> to abuse the ELF format a bit more, I can get the overhead down,
> though.
> 
> Are we okay with regressing here until binutils gets fixed?
> 

Probably not... although I guess it depends just how bad it really is.

-hpa


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

Re: [PATCH 10/10] mfd: cros_ec: ec_dev->cmd_xfer() returns number of bytes received from EC

[Simon Glass]

Hi,

On 16 June 2014 14:40, Doug Anderson  wrote:
> From: Bill Richardson 
>
> When communicating with the EC, the cmd_xfer() function should return the
> number of bytes it received from the EC, or negative on error.

This is just for the I2C tunnel feature, right? If so, I think this
should be mentioned here. It seems to be affecting ec_i2c_xfer(), not
cmd_xfer().

>
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c | 2 +-
>  drivers/mfd/cros_ec_i2c.c   | 2 +-
>  drivers/mfd/cros_ec_spi.c   | 2 +-
>  include/linux/mfd/cros_ec.h | 8 
>  4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c 
> b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index dd07818..05e033c 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -228,7 +228,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct 
> i2c_msg i2c_msgs[],
> msg.insize = response_len;
>
> result = bus->ec->cmd_xfer(bus->ec, );
> -   if (result)
> +   if (result < 0)
> goto exit;
>
> result = ec_i2c_parse_response(response, i2c_msgs, );
> diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
> index 2276096..dc0ba29 100644
> --- a/drivers/mfd/cros_ec_i2c.c
> +++ b/drivers/mfd/cros_ec_i2c.c
> @@ -120,7 +120,7 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device 
> *ec_dev,
> goto done;
> }
>
> -   ret = 0;
> +   ret = i2c_msg[1].buf[1];
>   done:
> kfree(in_buf);
> kfree(out_buf);
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 4d34f1c..beba1bc 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -333,7 +333,7 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device 
> *ec_dev,
> goto exit;
> }
>
> -   ret = 0;
> +   ret = len;
>  exit:
> mutex_unlock(_spi->lock);
> return ret;
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 60c0880..7b65a75 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -41,7 +41,7 @@ enum {
>   * @outdata: Outgoing data to EC
>   * @outsize: Outgoing length in bytes
>   * @indata: Where to put the incoming data from EC
> - * @insize: Incoming length in bytes (filled in by EC)
> + * @insize: Max number of bytes to accept from EC
>   * @result: EC's response to the command (separate from communication 
> failure)
>   */
>  struct cros_ec_command {
> @@ -64,9 +64,9 @@ struct cros_ec_command {
>   * sleep at the last suspend
>   * @event_notifier: interrupt event notifier for transport devices
>   * @cmd_xfer: send command to EC and get response
> - * Returns 0 if the communication succeeded, but that doesn't mean the EC
> - * was happy with the command it got. Caller should check msg.result for
> - * the EC's result code.
> + * Returns the number of bytes received if the communication succeeded, 
> but
> + * that doesn't mean the EC was happy with the command. The caller
> + * should check msg.result for the EC's result code.
>   *
>   * @priv: Private data
>   * @irq: Interrupt to use
> --
> 2.0.0.526.g5318336
>

Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: vdso_install target broken post-3.15

[Andy Lutomirski]

On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski  wrote:
> Just a heads up: gdb can't debug the vdso on 3.16-rc1.  I filed a bug:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=17064
>
> We may need to extend the fake section header hack to all vdso
> versions and stick the ELF notes in there.

I have a semi-working implementation of a workaround, bit it adds a
fair amount of extra crud to the image, and it's pushing my
configuration past a page boundary.  I suspect that, if we're willing
to abuse the ELF format a bit more, I can get the overhead down,
though.

Are we okay with regressing here until binutils gets fixed?

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

Re: scsi-mq

[Jens Axboe]

On 2014-06-17 07:27, Bart Van Assche wrote:

On 06/12/14 15:48, Christoph Hellwig wrote:

Bart and Robert have helped with some very detailed measurements that they
might be able to send in reply to this, although these usually involve
significantly reworked low level drivers to avoid other bottle necks.


In case someone would like to see the results of the measurements I ran,
these results can be found here:
https://docs.google.com/file/d/0B1YQOreL3_FxUXFMSjhmNDBNNTg.

Two important conclusions from the data in that PDF document are as follows:
- A small but significant performance improvement for the traditional
   SCSI mid-layer (use_blk_mq=N).
- A very significant performance improvement for multithreaded
   workloads with use_blk_mq=Y. As an example, the number of I/O
   operations per second reported for the random write test increased
   with 170%. That means 2.7 times the performance
   of use_blk_mq=N.


Thanks for posting these numbers, Bart. The CPU utilization and IOPS 
speak a very clear message. The only mystery is why the singe threaded 
performance is down. That we need to get sort, but it's not a show 
stopper for inclusion.


If you run the single threaded tests and watch for queue depths, is 
there a difference between blk-mq=y/scsi-mq and the stock kernel?



I think this means the scsi-mq patches are ready for wider use.


I would agree. James, I haven't seen any comments from you on this yet. 
I've run various bits of scsi-mq testing as well, and no ill effects 
seen. On top of that, Christophs patches are nicely separated and have 
general benefits even for the non-blk-mq cases. Time to shove them into 
the queue for the next merge window?


--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/10] mfd: cros_ec: Check result code from EC messages

[Simon Glass]

Hi Doug,

On 16 June 2014 14:39, Doug Anderson  wrote:
> From: Bill Richardson 
>
> Just because the host was able to talk to the EC doesn't mean that the EC
> was happy with what it was told. Errors in communincation are not the same
> as error messages from the EC itself.
>
> This change lets the EC report its errors separately.
>
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/mfd/cros_ec_i2c.c | 15 +++
>  drivers/mfd/cros_ec_spi.c | 26 ++
>  2 files changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
> index 5bb32f5..2276096 100644
> --- a/drivers/mfd/cros_ec_i2c.c
> +++ b/drivers/mfd/cros_ec_i2c.c
> @@ -92,11 +92,18 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device 
> *ec_dev,
> }
>
> /* check response error code */
> -   if (i2c_msg[1].buf[0]) {
> -   dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
> -msg->command, i2c_msg[1].buf[0]);
> -   ret = -EINVAL;
> +   msg->result = i2c_msg[1].buf[0];
> +   switch (msg->result) {
> +   case EC_RES_SUCCESS:
> +   break;
> +   case EC_RES_IN_PROGRESS:
> +   ret = -EAGAIN;
> +   dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
> +   msg->command);
> goto done;
> +   default:
> +   dev_warn(ec_dev->dev, "command 0x%02x returned %d\n",
> +msg->command, msg->result);
> }
>
> /* copy response packet payload and compute checksum */
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 09ca789..4d34f1c 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -289,21 +289,23 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device 
> *ec_dev,
> goto exit;
> }
>
> -   /* check response error code */
> ptr = ec_dev->din;
> -   if (ptr[0]) {
> -   if (ptr[0] == EC_RES_IN_PROGRESS) {
> -   dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
> -   ec_msg->command);
> -   ret = -EAGAIN;
> -   goto exit;
> -   }
> -   dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
> -ec_msg->command, ptr[0]);
> -   debug_packet(ec_dev->dev, "in_err", ptr, len);
> -   ret = -EINVAL;
> +
> +   /* check response error code */
> +   ec_msg->result = ptr[0];
> +   switch (ec_msg->result) {
> +   case EC_RES_SUCCESS:
> +   break;
> +   case EC_RES_IN_PROGRESS:
> +   ret = -EAGAIN;
> +   dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
> +   ec_msg->command);
> goto exit;
> +   default:
> +   dev_warn(ec_dev->dev, "command 0x%02x returned %d\n",
> +ec_msg->command, ec_msg->result);
> }

Since this code is the same as the above, should it go in a common
function in cros_ec?

> +
> len = ptr[1];
> sum = ptr[0] + ptr[1];
> if (len > ec_msg->insize) {
> --
> 2.0.0.526.g5318336
>

Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/10] mfd: cros_ec: cleanup: Remove EC wrapper functions

[Simon Glass]

Hi Doug,

On 16 June 2014 14:39, Doug Anderson  wrote:
> From: Bill Richardson 
>
> Remove the three wrapper functions that talk to the EC without passing all
> the desired arguments and just use the underlying communication function
> that passes everything in a struct intead.
>
> This is internal code refactoring only. Nothing should change.
>
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c | 15 +++
>  drivers/input/keyboard/cros_ec_keyb.c   | 14 --
>  drivers/mfd/cros_ec.c   | 32 
>  include/linux/mfd/cros_ec.h | 19 ++-
>  4 files changed, 29 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c 
> b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> index 8e7a714..dd07818 100644
> --- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> +++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
> @@ -183,6 +183,7 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct 
> i2c_msg i2c_msgs[],
> u8 *request = NULL;
> u8 *response = NULL;
> int result;
> +   struct cros_ec_command msg;
>
> request_len = ec_i2c_count_message(i2c_msgs, num);
> if (request_len < 0) {
> @@ -218,9 +219,15 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct 
> i2c_msg i2c_msgs[],
> }
>
> ec_i2c_construct_message(request, i2c_msgs, num, bus_num);
> -   result = bus->ec->command_sendrecv(bus->ec, EC_CMD_I2C_PASSTHRU,
> -  request, request_len,
> -  response, response_len);
> +
> +   msg.version = 0;
> +   msg.command = EC_CMD_I2C_PASSTHRU;
> +   msg.outdata = request;
> +   msg.outsize = request_len;
> +   msg.indata = response;
> +   msg.insize = response_len;
> +
> +   result = bus->ec->cmd_xfer(bus->ec, );
> if (result)
> goto exit;
>
> @@ -258,7 +265,7 @@ static int ec_i2c_probe(struct platform_device *pdev)
> u32 remote_bus;
> int err;
>
> -   if (!ec->command_sendrecv) {
> +   if (!ec->cmd_xfer) {
> dev_err(dev, "Missing sendrecv\n");
> return -EINVAL;
> }
> diff --git a/drivers/input/keyboard/cros_ec_keyb.c 
> b/drivers/input/keyboard/cros_ec_keyb.c
> index 4083796..dc37b6b 100644
> --- a/drivers/input/keyboard/cros_ec_keyb.c
> +++ b/drivers/input/keyboard/cros_ec_keyb.c
> @@ -191,8 +191,18 @@ static void cros_ec_keyb_close(struct input_dev *dev)
>
>  static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t 
> *kb_state)
>  {
> -   return ckdev->ec->command_recv(ckdev->ec, EC_CMD_MKBP_STATE,
> - kb_state, ckdev->cols);
> +   int ret;
> +   struct cros_ec_command msg = {
> +   .version = 0,
> +   .command = EC_CMD_MKBP_STATE,
> +   .outdata = NULL,
> +   .outsize = 0,
> +   .indata = kb_state,
> +   .insize = ckdev->cols,
> +   };
> +
> +   ret = ckdev->ec->cmd_xfer(ckdev->ec, );

Do we need ret?

> +   return ret;
>  }
>
>  static int cros_ec_keyb_work(struct notifier_block *nb,
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index d242714..6dd91e9 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -44,34 +44,6 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
>  }
>  EXPORT_SYMBOL(cros_ec_prepare_tx);
>
> -static int cros_ec_command_sendrecv(struct cros_ec_device *ec_dev,
> -   uint16_t cmd, void *out_buf, int out_len,
> -   void *in_buf, int in_len)
> -{
> -   struct cros_ec_command msg;
> -
> -   msg.version = cmd >> 8;
> -   msg.command = cmd & 0xff;
> -   msg.outdata = out_buf;
> -   msg.outsize = out_len;
> -   msg.indata = in_buf;
> -   msg.insize = in_len;
> -
> -   return ec_dev->cmd_xfer(ec_dev, );
> -}
> -
> -static int cros_ec_command_recv(struct cros_ec_device *ec_dev,
> -   uint16_t cmd, void *buf, int buf_len)
> -{
> -   return cros_ec_command_sendrecv(ec_dev, cmd, NULL, 0, buf, buf_len);
> -}
> -
> -static int cros_ec_command_send(struct cros_ec_device *ec_dev,
> -   uint16_t cmd, void *buf, int buf_len)
> -{
> -   return cros_ec_command_sendrecv(ec_dev, cmd, buf, buf_len, NULL, 0);
> -}
> -
>  static irqreturn_t ec_irq_thread(int irq, void *data)
>  {
> struct cros_ec_device *ec_dev = data;
> @@ -104,10 +76,6 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
>
> BLOCKING_INIT_NOTIFIER_HEAD(_dev->event_notifier);
>
> -   ec_dev->command_send = cros_ec_command_send;
> -   ec_dev->command_recv = cros_ec_command_recv;
> -   ec_dev->command_sendrecv = cros_ec_command_sendrecv;
> -
> if (ec_dev->din_size) {
> ec_dev->din = devm_kzalloc(dev, 

Re: [PATCH 07/10] mfd: cros_ec: cleanup: remove unused fields from struct cros_ec_device

[Simon Glass]

Hi Doug,

On 16 June 2014 14:39, Doug Anderson  wrote:
> From: Bill Richardson 
>
> struct cros_ec_device has a superfluous "name" field. We can get all the
> debugging info we need from the existing ec_name and phys_name fields, so
> let's take out the extra field.

Except that it no longer prints I2C/SPI - i.e. the transport that is
used. Is that not considered important?

Anyway:

Reviewed-by: Simon Glass 

Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mm: NULL ptr deref in remove_migration_pte

[Hugh Dickins]

On Mon, 16 Jun 2014, Sasha Levin wrote:
> On 06/10/2014 12:20 AM, Hugh Dickins wrote:
> > Although there's nothing in the backtrace to implicate it,
> > I think this crash is caused by THP: please try this patch - thanks.
> > 
> > [PATCH] mm: let mm_find_pmd fix buggy race with THP fault
...
> 
> It took some time to hit something here,

I take that to mean that you were running with the mm_find_pmd patch in,
and it seemed to take a little longer to hit the problem than before?

> but I think that the following is related:

I agree it does look like a variant of what you got before the patch;
but I still think the patch is good, and don't believe it caused this.

It looks as if these symptoms have an additional cause, which that patch
did not even attempt to address.  I've looked around, but not found what.

> 
> [  489.152166] INFO: trying to register non-static key.
> [  489.152166] the code is fine but needs lockdep annotation.
> [  489.152166] turning off the locking correctness validator.
> [  489.152166] CPU: 23 PID: 12148 Comm: trinity-c79 Not tainted 
> 3.15.0-next-20140616-sasha-00025-g0fd1f7d-dirty #657
> [  489.152166]  8804dd013000 8804e15a38e8 965140d1 
> 0002
> [  489.152166]  9a5ce7c0 8804e15a39e8 931ca363 
> 8804e15a3928
> [  489.152166]    8804e4730978 
> 0001
> [  489.152166] Call Trace:
> [  489.152166] dump_stack (lib/dump_stack.c:52)
> [  489.152166] __lock_acquire (kernel/locking/lockdep.c:743 
> kernel/locking/lockdep.c:3078)
> [  489.152166] ? __lock_acquire (kernel/locking/lockdep.c:3189)
> [  489.152166] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90 
> arch/x86/kernel/kvmclock.c:86)
> [  489.152166] lock_acquire (./arch/x86/include/asm/current.h:14 
> kernel/locking/lockdep.c:3602)
> [  489.152166] ? __page_check_address (include/linux/spinlock.h:303 
> mm/rmap.c:630)
> [  489.152166] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 
> kernel/locking/spinlock.c:151)
> [  489.152166] ? __page_check_address (include/linux/spinlock.h:303 
> mm/rmap.c:630)
> [  489.152166] ? get_parent_ip (kernel/sched/core.c:2546)
> [  489.152166] __page_check_address (include/linux/spinlock.h:303 
> mm/rmap.c:630)
> [  489.152166] try_to_unmap_one (mm/rmap.c:1153)
> [  489.152166] ? __const_udelay (arch/x86/lib/delay.c:126)
> [  489.152166] ? __rcu_read_unlock (kernel/rcu/update.c:97)
> [  489.152166] ? page_lock_anon_vma_read (mm/rmap.c:448)
> [  489.152166] rmap_walk (mm/rmap.c:1654 mm/rmap.c:1725)
> [  489.152166] ? preempt_count_sub (kernel/sched/core.c:2602)
> [  489.152166] try_to_unmap (mm/rmap.c:1547)
> [  489.152166] ? page_remove_rmap (mm/rmap.c:1144)
> [  489.152166] ? invalid_migration_vma (mm/rmap.c:1503)
> [  489.152166] ? try_to_unmap_one (mm/rmap.c:1411)
> [  489.152166] ? anon_vma_prepare (mm/rmap.c:448)
> [  489.152166] ? invalid_mkclean_vma (mm/rmap.c:1498)
> [  489.152166] ? page_get_anon_vma (mm/rmap.c:405)
> [  489.152166] migrate_pages (mm/migrate.c:913 mm/migrate.c:959 
> mm/migrate.c:1146)
> [  489.152166] ? _raw_spin_unlock_irq (./arch/x86/include/asm/preempt.h:98 
> include/linux/spinlock_api_smp.h:169 kernel/locking/spinlock.c:199)
> [  489.152166] ? perf_trace_mm_numa_migrate_ratelimit (mm/migrate.c:1594)
> [  489.152166] migrate_misplaced_page (mm/migrate.c:1754)
> [  489.152166] __handle_mm_fault (mm/memory.c:3157 mm/memory.c:3207 
> mm/memory.c:3317)
> [  489.152166] handle_mm_fault (include/linux/memcontrol.h:151 
> mm/memory.c:3343)
> [  489.152166] ? __do_page_fault (arch/x86/mm/fault.c:1163)
> [  489.152166] __do_page_fault (arch/x86/mm/fault.c:1230)
> [  489.152166] ? vtime_account_user (kernel/sched/cputime.c:687)
> [  489.152166] ? get_parent_ip (kernel/sched/core.c:2546)
> [  489.152166] ? preempt_count_sub (kernel/sched/core.c:2602)
> [  489.152166] ? context_tracking_user_exit (kernel/context_tracking.c:184)
> [  489.152166] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [  489.152166] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2638 
> (discriminator 2))
> [  489.152166] trace_do_page_fault (arch/x86/mm/fault.c:1313 
> include/linux/jump_label.h:115 include/linux/context_tracking_state.h:27 
> include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1314)
> [  489.152166] do_async_page_fault (arch/x86/kernel/kvm.c:264)
> [  489.152166] async_page_fault (arch/x86/kernel/entry_64.S:1322)

Originally I thought that the trace above and the trace below were
probably unrelated, there being more than five seconds between them.

But then noticed 8804e4730978 in the stack contents above, with
8804e4730e10 the object address in the slub diagnostic below.

As Christoph points out, the slub diagnostic shows that something
has been overwriting with zeroes there.

Maybe the whole page (containing the slub-allocated page table lock
being checked by lockdep above) has been overwritten with zeroes.

>From experience a few months ago in 

Re: [PATCH 6/6] percpu-refcount: implement percpu_ref_reinit() and percpu_ref_is_zero()

[Lai Jiangshan]

On 06/18/2014 09:08 AM, Tejun Heo wrote:
> Now that explicit invocation of percpu_ref_exit() is necessary to free
> the percpu counter, we can implement percpu_ref_reinit() which
> reinitializes a released percpu_ref.  This can be used implement
> scalable gating switch which can be drained and then re-opened without
> worrying about memory allocation failures.
> 
> percpu_ref_is_zero() is added to be used in a sanity check in
> percpu_ref_exit().  As this function will be useful for other purposes
> too, make it a public interface.
> 
> Signed-off-by: Tejun Heo 
> Cc: Kent Overstreet 
> Cc: Christoph Lameter 
> ---
>  include/linux/percpu-refcount.h | 21 -
>  lib/percpu-refcount.c   | 35 +++
>  2 files changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
> index 0ddd283..80f21ea 100644
> --- a/include/linux/percpu-refcount.h
> +++ b/include/linux/percpu-refcount.h
> @@ -67,6 +67,7 @@ struct percpu_ref {
>  
>  int __must_check percpu_ref_init(struct percpu_ref *ref,
>percpu_ref_func_t *release);
> +void percpu_ref_reinit(struct percpu_ref *ref);
>  void percpu_ref_exit(struct percpu_ref *ref);
>  void percpu_ref_kill_and_confirm(struct percpu_ref *ref,
>percpu_ref_func_t *confirm_kill);
> @@ -97,7 +98,10 @@ static inline void percpu_ref_kill(struct percpu_ref *ref)
>  static inline bool __pcpu_ref_alive(struct percpu_ref *ref,
>   unsigned __percpu **pcpu_countp)
>  {
> - unsigned long pcpu_ptr = ACCESS_ONCE(ref->pcpu_count_ptr);
> + unsigned long pcpu_ptr;
> +
> + /* paired with smp_store_release() in percpu_ref_reinit() */
> + pcpu_ptr = smp_load_acquire(>pcpu_count_ptr);


Does "smp_load_acquire()" hurts the performance of percpu_ref_get/put()
in non-x86 system?

>  
>   if (unlikely(pcpu_ptr & PCPU_REF_DEAD))
>   return false;
> @@ -206,4 +210,19 @@ static inline void percpu_ref_put(struct percpu_ref *ref)
>   rcu_read_unlock_sched();
>  }
>  
> +/**
> + * percpu_ref_is_zero - test whether a percpu refcount reached zero
> + * @ref: percpu_ref to test
> + *
> + * Returns %true if @ref reached zero.
> + */
> +static inline bool percpu_ref_is_zero(struct percpu_ref *ref)
> +{
> + unsigned __percpu *pcpu_count;
> +
> + if (__pcpu_ref_alive(ref, _count))
> + return false;
> + return !atomic_read(>count);
> +}
> +
>  #endif
> diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
> index ac42991..b348a2f 100644
> --- a/lib/percpu-refcount.c
> +++ b/lib/percpu-refcount.c
> @@ -61,6 +61,41 @@ int percpu_ref_init(struct percpu_ref *ref, 
> percpu_ref_func_t *release)
>  EXPORT_SYMBOL_GPL(percpu_ref_init);
>  
>  /**
> + * percpu_ref_reinit - re-initialize a percpu refcount
> + * @ref: perpcu_ref to re-initialize
> + *
> + * Re-initialize @ref so that it's in the same state as when it finished
> + * percpu_ref_init().  @ref must have been initialized successfully, killed
> + * and reached 0 but not exited.
> + *
> + * Note that percpu_ref_tryget[_live]() are safe to perform on @ref while
> + * this function is in progress.
> + */
> +void percpu_ref_reinit(struct percpu_ref *ref)
> +{
> + unsigned __percpu *pcpu_count = pcpu_count_ptr(ref);
> + int cpu;
> +
> + BUG_ON(!pcpu_count);
> + WARN_ON(!percpu_ref_is_zero(ref));
> +
> + atomic_set(>count, 1 + PCPU_COUNT_BIAS);
> +
> + /*
> +  * Restore per-cpu operation.  smp_store_release() is paired with
> +  * smp_load_acquire() in __pcpu_ref_alive() and guarantees that the
> +  * zeroing is visible to all percpu accesses which can see the
> +  * following PCPU_REF_DEAD clearing.
> +  */
> + for_each_possible_cpu(cpu)
> + *per_cpu_ptr(pcpu_count, cpu) = 0;
> +
> + smp_store_release(>pcpu_count_ptr,
> +   ref->pcpu_count_ptr & ~PCPU_REF_DEAD);
> +}
> +EXPORT_SYMBOL_GPL(percpu_ref_reinit);
> +
> +/**
>   * percpu_ref_exit - undo percpu_ref_init()
>   * @ref: percpu_ref to exit
>   *

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 04/10] mfd: cros_ec: Tweak struct cros_ec_device for clarity

[Simon Glass]

Hi Doug,

On 16 June 2014 14:39, Doug Anderson  wrote:
> From: Bill Richardson 
>
> The members of struct cros_ec_device were improperly commented, and
> intermixed the private and public sections. This is just cleanup to make it
> more obvious what goes with what.
>
> [dianders: left lock in the structure but gave it the name that will
> eventually be used.]
>
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/mfd/cros_ec.c   |  2 +-
>  drivers/mfd/cros_ec_i2c.c   |  4 +--
>  drivers/mfd/cros_ec_spi.c   | 10 +++
>  include/linux/mfd/cros_ec.h | 65 
> -
>  4 files changed, 43 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index bd6f936..a9eede5 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -57,7 +57,7 @@ static int cros_ec_command_sendrecv(struct cros_ec_device 
> *ec_dev,
> msg.in_buf = in_buf;
> msg.in_len = in_len;
>
> -   return ec_dev->command_xfer(ec_dev, );
> +   return ec_dev->cmd_xfer(ec_dev, );

Why do this rename? It makes it different from the other members.

Regards,
Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: mc13xxx: Use regmap irq framework for interrupts

[Alexander Shiyan]

Tue, 17 Jun 2014 21:04:59 +0100 от Lee Jones :
> On Sat, 07 Jun 2014, Alexander Shiyan wrote:
> 
> > This patch convert mc13xxx MFD driver to use regmap irq framework
> > for interrupt registration.
> > 
> > Signed-off-by: Alexander Shiyan 
> > ---
> >  drivers/mfd/Kconfig |   1 +
> >  drivers/mfd/mc13xxx-core.c  | 299 
> > ++--
> >  drivers/mfd/mc13xxx.h   |   7 +-
> >  include/linux/mfd/mc13xxx.h |  21 +++-
> >  4 files changed, 59 insertions(+), 269 deletions(-)
> 
> Patch looks good to me and I love the diffstat.  If any problems occur
> as a result of applying this patch we can fix it up as subsequent
> patch submissions.

Unfortunately, prolonged use of the modified version, revealed two errors.
I will try to make incremental patch quickly, or can send a second version
of the patch.

---

Re: [PATCH 03/10] mfd: cros_ec: Allow static din/dout buffers with cros_ec_register()

[Simon Glass]

On 16 June 2014 14:39, Doug Anderson  wrote:
> From: Bill Richardson 
>
> The lower-level driver may want to provide its own buffers. If so,
> there's no need to allocate new ones.  This already happens to work
> just fine (since we check for size of 0 and use devm allocation), but
> it's good to document it.
>
> [dianders: Resolved conflicts; documented that no code changes needed
> on mainline]
>
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 

Reviewed-by: Simon Glass 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/10] mfd: cros_ec: IRQs for cros_ec should be optional

[Simon Glass]

On 16 June 2014 14:39, Doug Anderson  wrote:
> From: Bill Richardson 
>
> Preparing the way for the LPC device, which is just a plaform_device without
> interrupts.
>
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 

Reviewed-by: Simon Glass 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Guaranteed Top 10 Google Placements for mail-archive.com In 100 Days

[josefina89933]

Hello Sir / Mam

We would like to have a chance to work on your website and get it positioned 
top 10 on major search engines around the world ( Google & Bing ). We are 
presently working with 500+ clients world wide and we have made sure all our 
clients rank top 10 for their best keywords. None of our clients have been 
caught in any of the recent google updates. We only use ethical white hat 
methods to deliver rankings. Our search engine packages include both onsite & 
off optimization, we provide complete SEO solution to our clients and not just 
link building packages.

We understand there are many SEO Scam companies mailing you each day over and 
over again and I am also sure you have been robbed off a few times in past with 
no results at all. To make sure you we show you our WORTH, we have launched 15 
DAY FREE SEO TRIAL service. We want to build your faith in our service and make 
sure you see results before paying for our service.

Is 15 days Enough time to deliver results ?

15 days is good enough a time to show you huge movements in rankings for all 
your keywords. We start with A) choosing the best keywords for your website, B) 
 Approve a final list of keywords, C) Make onsite changes D) Build links for 
your website. If in these 15 days you are not happy with our performance, you 
can cancel or decide to opt-out. You will not be billed a single dime for these 
15 days.

Post Trial Pricing & Package

In the 15 days trial, we only work for 10 keywords so that we can show best 
possible results in the time span. Once the trial is over you pick one of the 
packages listed below :

Package A ) $99 / month (10 keywords optimized ) Package B ) $149 / month ( 20 
keywords optimized ) Package C ) $199 / month ( 30 keywords optimized )

To Sign up for our free trial email us back with the information below so we 
can send you our sign up link.

1) " Website You Want To Optimize "
2) Keywords ( Optional )
3) SEO Done Before ( Yes / No )

Looking forward working with you, let us know if you would like to have more 
information about our company and procedures.
Regards

Babita Rani
SEO Manager : T.O.B
7 B Green Avenue, Amritsar Punjab



Our email above is not intended to waste your time or fill your inbox with 
spam. If you would not like to hear from us, email us back with NOT INTERESTED. 
We will never email you again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/9] ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in atomic context.

[Lv Zheng]

The GPE APIs should be invoked inside of an IRQ context GPE handler or in
the task context with a driver provided lock held. This driver provided
lock should be safe to be held in the GPE handler by the driver.

While currently we cannot do this, thus we can only use the GPE APIs for
limitted cases.

This patch adds reference counting for struct acpi_gpe_handler_info. Then the 
GPE
handler can be safely invoked without holding the GPE lock, thus
facilitates GPE APIs to be invoked in any atomic environment. Lv Zheng.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acevents.h |1 +
 drivers/acpi/acpica/aclocal.h  |1 +
 drivers/acpi/acpica/evgpe.c|   71 
 drivers/acpi/acpica/evxface.c  |   14 +---
 4 files changed, 70 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/acpica/acevents.h b/drivers/acpi/acpica/acevents.h
index 7a7811a..a3d5276 100644
--- a/drivers/acpi/acpica/acevents.h
+++ b/drivers/acpi/acpica/acevents.h
@@ -123,6 +123,7 @@ ACPI_HW_DEPENDENT_RETURN_OK(acpi_status
 u32
 acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
 struct acpi_gpe_event_info *gpe_event_info,
+struct acpi_gpe_handler_info *gpe_handler_info,
 u32 gpe_number);
 
 /*
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index a9fa666..7363e2c 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -414,6 +414,7 @@ struct acpi_gpe_handler_info {
struct acpi_namespace_node *method_node;/* Method node for this 
GPE level (saved) */
u8 original_flags;  /* Original (pre-handler) GPE info */
u8 originally_enabled;  /* True if GPE was originally enabled */
+   u16 reference_count;/* For deletion management */
 };
 
 /* Notify info for implicit notify, multiple device objects */
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index f9e6891..3ab56d7 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -338,6 +338,8 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info 
*gpe_xrupt_list)
 {
acpi_status status;
struct acpi_gpe_block_info *gpe_block;
+   struct acpi_gpe_event_info *gpe_event_info;
+   struct acpi_gpe_handler_info *gpe_handler_info;
struct acpi_gpe_register_info *gpe_register_info;
u32 int_status = ACPI_INTERRUPT_NOT_HANDLED;
u8 enabled_status_byte;
@@ -442,15 +444,45 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info 
*gpe_xrupt_list)
/* Examine one GPE bit */
 
if (enabled_status_byte & (1 << j)) {
+   gpe_event_info =
+   _block->
+   event_info[((acpi_size) i *
+   ACPI_GPE_REGISTER_WIDTH)
+  + j];
+   gpe_handler_info =
+   gpe_event_info->dispatch.handler;
+
+   /* Acquire the reference to protect the 
invocations */
+
+   if (gpe_handler_info) {
+   gpe_handler_info->
+   reference_count++;
+   }
+
/*
 * Found an active GPE. Dispatch the 
event to a handler
-* or method.
+* or method. Invoke without GPE lock 
held.
 */
+   acpi_os_release_lock(acpi_gbl_gpe_lock,
+flags);
int_status |=
acpi_ev_gpe_dispatch(gpe_block->
 node,
-_block->
-
event_info[((acpi_size) i * ACPI_GPE_REGISTER_WIDTH) + j], j + 
gpe_register_info->base_gpe_number);
+gpe_event_info,
+
gpe_handler_info,
+j +
+
gpe_register_info->
+
base_gpe_number);
+   flags =
+   acpi_os_acquire_lock
+   

[PATCH 1/9] ACPICA: Events: Reduce indent divergences of events files.

[Lv Zheng]

This patch reduces indent divergences first in order to reduce human
intervention work for the follow-up linuxized event patches.

This patch reduces indent divergences of the event files. Though the
divergences report doesn't care about these differences, they do hurt
patches maintanence.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/aclocal.h |4 ++--
 drivers/acpi/acpica/evgpe.c   |   18 +-
 drivers/acpi/acpica/evxface.c |8 
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 91f801a..a9fa666 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -412,8 +412,8 @@ struct acpi_gpe_handler_info {
acpi_gpe_handler address;   /* Address of handler, if any */
void *context;  /* Context to be passed to handler */
struct acpi_namespace_node *method_node;/* Method node for this 
GPE level (saved) */
-   u8 original_flags;  /* Original (pre-handler) GPE info */
-   u8 originally_enabled;  /* True if GPE was originally enabled */
+   u8 original_flags;  /* Original (pre-handler) GPE info */
+   u8 originally_enabled;  /* True if GPE was originally enabled */
 };
 
 /* Notify info for implicit notify, multiple device objects */
diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index e4ba4de..f9e6891 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -212,7 +212,7 @@ acpi_ev_remove_gpe_reference(struct acpi_gpe_event_info 
*gpe_event_info)
if (ACPI_SUCCESS(status)) {
status =
acpi_hw_low_set_gpe(gpe_event_info,
-ACPI_GPE_DISABLE);
+   ACPI_GPE_DISABLE);
}
 
if (ACPI_FAILURE(status)) {
@@ -334,7 +334,7 @@ struct acpi_gpe_event_info 
*acpi_ev_get_gpe_event_info(acpi_handle gpe_device,
  *
  
**/
 
-u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info * gpe_xrupt_list)
+u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info *gpe_xrupt_list)
 {
acpi_status status;
struct acpi_gpe_block_info *gpe_block;
@@ -427,7 +427,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info * 
gpe_xrupt_list)
 
/* Check if there is anything active at all in this 
register */
 
-   enabled_status_byte = (u8) (status_reg & enable_reg);
+   enabled_status_byte = (u8)(status_reg & enable_reg);
if (!enabled_status_byte) {
 
/* No active GPEs in this register, move on */
@@ -450,7 +450,7 @@ u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info * 
gpe_xrupt_list)
acpi_ev_gpe_dispatch(gpe_block->
 node,
 _block->
-   event_info[((acpi_size) i * 
ACPI_GPE_REGISTER_WIDTH) + j], j + gpe_register_info->base_gpe_number);
+
event_info[((acpi_size) i * ACPI_GPE_REGISTER_WIDTH) + j], j + 
gpe_register_info->base_gpe_number);
}
}
}
@@ -636,7 +636,7 @@ static void ACPI_SYSTEM_XFACE 
acpi_ev_asynch_enable_gpe(void *context)
  *
  
**/
 
-acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info *gpe_event_info)
+acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info * gpe_event_info)
 {
acpi_status status;
 
@@ -666,9 +666,9 @@ acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info 
*gpe_event_info)
  *
  * FUNCTION:acpi_ev_gpe_dispatch
  *
- * PARAMETERS:  gpe_device  - Device node. NULL for GPE0/GPE1
- *  gpe_event_info  - Info for this GPE
- *  gpe_number  - Number relative to the parent GPE block
+ * PARAMETERS:  gpe_device  - Device node. NULL for GPE0/GPE1
+ *  gpe_event_info  - Info for this GPE
+ *  gpe_number  - Number relative to the parent GPE block
  *
  * RETURN:  INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED
  *
@@ -681,7 +681,7 @@ acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info 
*gpe_event_info)
 
 u32
 acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
-   struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
+struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
 {
acpi_status status;
u32 return_value;
diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c
index 11e5803..1bcb55b 

[PATCH 4/9] ACPICA: Events: Remove acpi_ev_enable_gpe().

[Lv Zheng]

The stale GPE indication is not a problem. Drivers should always check the
underlying hardware status and be ready to handle invalid status.

The GPE clearing implemented in acpi_ev_enable_gpe() on the contrary
introduces issues for acpi_enable_gpe() logic. When the usage count of GPE is
increased by suspend/resume code, GPE status shouldn't be cleared, or a GPE
loss could happen when the driver relies on the interrupt mode.

With previous cleanup, all acpi_ev_enable_gpe() usages are removed, this patch
also removes this internal API. Lv Zheng.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/evgpe.c |   45 +++
 1 file changed, 3 insertions(+), 42 deletions(-)

diff --git a/drivers/acpi/acpica/evgpe.c b/drivers/acpi/acpica/evgpe.c
index 3ab56d7..64f6d41 100644
--- a/drivers/acpi/acpica/evgpe.c
+++ b/drivers/acpi/acpica/evgpe.c
@@ -98,47 +98,6 @@ acpi_ev_update_gpe_enable_mask(struct acpi_gpe_event_info 
*gpe_event_info)
 
 
/***
  *
- * FUNCTION:acpi_ev_enable_gpe
- *
- * PARAMETERS:  gpe_event_info  - GPE to enable
- *
- * RETURN:  Status
- *
- * DESCRIPTION: Clear a GPE of stale events and enable it.
- *
- 
**/
-acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
-{
-   acpi_status status;
-
-   ACPI_FUNCTION_TRACE(ev_enable_gpe);
-
-   /*
-* We will only allow a GPE to be enabled if it has either an associated
-* method (_Lxx/_Exx) or a handler, or is using the implicit notify
-* feature. Otherwise, the GPE will be immediately disabled by
-* acpi_ev_gpe_dispatch the first time it fires.
-*/
-   if ((gpe_event_info->flags & ACPI_GPE_DISPATCH_MASK) ==
-   ACPI_GPE_DISPATCH_NONE) {
-   return_ACPI_STATUS(AE_NO_HANDLER);
-   }
-
-   /* Clear the GPE (of stale events) */
-   status = acpi_hw_clear_gpe(gpe_event_info);
-   if (ACPI_FAILURE(status)) {
-   return_ACPI_STATUS(status);
-   }
-
-   /* Enable the requested GPE */
-
-   status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
-   return_ACPI_STATUS(status);
-}
-
-
-/***
- *
  * FUNCTION:acpi_ev_add_gpe_reference
  *
  * PARAMETERS:  gpe_event_info  - Add a reference to this GPE
@@ -168,7 +127,9 @@ acpi_ev_add_gpe_reference(struct acpi_gpe_event_info 
*gpe_event_info)
 
status = acpi_ev_update_gpe_enable_mask(gpe_event_info);
if (ACPI_SUCCESS(status)) {
-   status = acpi_ev_enable_gpe(gpe_event_info);
+   status =
+   acpi_hw_low_set_gpe(gpe_event_info,
+   ACPI_GPE_ENABLE);
}
 
if (ACPI_FAILURE(status)) {
-- 
1.7.10

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

[tracing] 939c7a4f04f: -46.4% cpuidle.C3-IVT.time

[Jet Chen]

Hi Yoshihiro,

FYI, we noticed the below changes on

commit 939c7a4f04fcd2162109744e8bf88194948a6e65 ("tracing: Introduce 
saved_cmdlines_size file")

test case: brickland3/aim7/3000-brk_test

beba4bb096201ce  939c7a4f04fcd2162109744e8
---  -
352643 ~40% -46.4% 189136 ~15%  TOTAL cpuidle.C3-IVT.time
   750 ~ 2% -13.3%650 ~ 2%  TOTAL vmstat.procs.b
362016 ~ 3%  -6.0% 340296 ~ 3%  TOTAL proc-vmstat.pgmigrate_success
362016 ~ 3%  -6.0% 340296 ~ 3%  TOTAL 
proc-vmstat.numa_pages_migrated
   1642328 ~ 3% +13.3%1860721 ~ 2%  TOTAL softirqs.RCU
   2278829 ~ 2% -14.0%1959647 ~ 2%  TOTAL 
time.voluntary_context_switches
   207 ~ 0% -10.4%185 ~ 0%  TOTAL time.user_time
   ~ 0%  +8.5%~ 0%  TOTAL turbostat.RAM_W
   4418246 ~ 3%  -6.4%4136447 ~ 1%  TOTAL time.minor_page_faults
   ~ 0%  +3.4%~ 0%  TOTAL turbostat.Cor_W
   ~ 0%  +3.0%~ 0%  TOTAL turbostat.Pkg_W
  11354889 ~ 0%  +2.0%   11579897 ~ 0%  TOTAL 
time.involuntary_context_switches

Legend:
~XX%- stddev percent
[+-]XX% - change percent


time.voluntary_context_switches

  2.4e+06 ++---*+
  *.. *....  .. |
  2.3e+06 ++  .*..  *.. ..  *   |
  |  *..*..  .*.. ..   * *..   +   *..   *..*
  |*.*  . .*..*.. +..   |
  2.2e+06 ++ *..*.   ** |
  | |
  2.1e+06 ++|
  | |
2e+06 O+ O   OO |
  | O O O  O|
  |O   O  O  O  O   |
  1.9e+06 ++ O  O  O   O|
  |O OO |
  1.8e+06 +++


  turbostat.Pkg_W

   +++
   O+ O   O O  OO|
   | O  O O   O  O  O  O  O O   O  O  O  |
   ++ O  O   |
   ++|
   ++|
   ++|
   | |
   ++|
   ++|
   ++*..  .*..   |
   *+.*... ..   *...*.*...*..*..*...*..*..  ..*..   *...*..*..*...*..*
   |  *   *.  .. |
   ++*   |
   +++


  turbostat.Cor_W

   +++
   O+ O   O  O  O   O  OO  O  O  |
   |  O   O  O  O O   O  O  O   O  O |
   ++|
   ++|
   | |
   ++|
   ++|
   ++|
   | |
   ++*.. |
   *+.*... ..   *...*..*..*...*..*..*...*..*..  ..*..   *...  .*..*...*..*
   |  *   *.  ..*.   |
   ++*   |
   +++


 turbostat.RAM_W

  ++-+
  |  O  O OO   O O 

[PATCH 7/9] ACPI/EC: Add detailed command/query debugging information.

[Lv Zheng]

Developers really don't need to translate EC commands in mind. This patch
adds detailed debugging information for the EC commands.
The address can be found in the follow-up sequential EC_DATA(W) accesses,
thus this patch also removes some of the redundant address information.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 6891370..4799ea0 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -165,6 +165,27 @@ static inline void acpi_ec_write_data(struct acpi_ec *ec, 
u8 data)
outb(data, ec->data_addr);
 }
 
+#ifdef DEBUG
+static const char *acpi_ec_cmd_string(u8 cmd)
+{
+   switch (cmd) {
+   case 0x80:
+   return "RD_EC";
+   case 0x81:
+   return "WR_EC";
+   case 0x82:
+   return "BE_EC";
+   case 0x83:
+   return "BD_EC";
+   case 0x84:
+   return "QR_EC";
+   }
+   return "UNKNOWN";
+}
+#else
+#define acpi_ec_cmd_string(cmd)"UNDEF"
+#endif
+
 static int ec_transaction_completed(struct acpi_ec *ec)
 {
unsigned long flags;
@@ -293,16 +314,16 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec 
*ec,
}
/* following two actions should be kept atomic */
ec->curr = t;
-   pr_debug("* transaction started (cmd=0x%02x, addr=0x%02x) *\n",
-t->command, t->wdata ? t->wdata[0] : 0);
+   pr_debug("* Command(%s) started *\n",
+acpi_ec_cmd_string(t->command));
start_transaction(ec);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
-   pr_debug("* transaction stopped (cmd=0x%02x, addr=0x%02x) *\n",
-t->command, t->wdata ? t->wdata[0] : 0);
+   pr_debug("* Command(%s) stopped *\n",
+acpi_ec_cmd_string(t->command));
ec->curr = NULL;
 unlock:
spin_unlock_irqrestore(>lock, tmp);
-- 
1.7.10

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

[PATCH 9/9] ACPI/EC: Add unit test support for EC driver hotplug.

[Lv Zheng]

This patch adds facility to test future EC modification.
All EC commits should enable TEST_HOTPLUG, and try a build/boot test.
Since EC is currently a built-in module, this is the only mean for us to
test the hotplug code.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 92058a1..c5d0797 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -31,6 +31,7 @@
 
 /* Uncomment next line to get verbose printout */
 /* #define DEBUG */
+/* #define TEST_HOTPLUG */
 #define pr_fmt(fmt) "ACPI : EC: " fmt
 
 #include 
@@ -120,6 +121,9 @@ struct transaction {
u8 flags;
 };
 
+static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
+  u32 gpe_number, void *data);
+
 struct acpi_ec *boot_ec, *first_ec;
 EXPORT_SYMBOL(first_ec);
 
@@ -720,6 +724,21 @@ static void acpi_ec_gpe_query(void *ec_cxt)
mutex_lock(>mutex);
acpi_ec_sync_query(ec, NULL);
mutex_unlock(>mutex);
+
+#ifdef TEST_HOTPLUG
+
+   /* Unit testing for driver hotplugging */
+
+   pr_info("Removing EC handlers...\n");
+   acpi_ec_stop(ec);
+   acpi_remove_gpe_handler(NULL, ec->gpe,
+   _ec_gpe_handler);
+   pr_info("Installing EC handlers...\n");
+   acpi_install_gpe_handler(NULL, ec->gpe,
+ ACPI_GPE_EDGE_TRIGGERED,
+ _ec_gpe_handler, ec);
+   acpi_ec_start(ec);
+#endif
 }
 
 static int ec_check_sci(struct acpi_ec *ec, u8 state)
-- 
1.7.10

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

[PATCH 6/9] ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag.

[Lv Zheng]

By using the 2 flags, we can indicate an inter-mediate state where the
current transactions should be completed while the new transactions should
be blocked.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   56 +++--
 1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index c3299f6..6891370 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -79,7 +79,8 @@ enum {
EC_FLAGS_GPE_STORM, /* GPE storm detected */
EC_FLAGS_HANDLERS_INSTALLED,/* Handlers for GPE and
 * OpReg are installed */
-   EC_FLAGS_BLOCKED,   /* Transactions are blocked */
+   EC_FLAGS_STARTED,   /* Driver is started */
+   EC_FLAGS_STOPPED,   /* Driver is stopped */
 };
 
 #define ACPI_EC_COMMAND_POLL   0x01 /* Available for command byte */
@@ -285,15 +286,25 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec 
*ec,
udelay(ACPI_EC_MSI_UDELAY);
/* start transaction */
spin_lock_irqsave(>lock, tmp);
+   if (!test_bit(EC_FLAGS_STARTED, >flags) ||
+   test_bit(EC_FLAGS_STOPPED, >flags)) {
+   ret = -EINVAL;
+   goto unlock;
+   }
/* following two actions should be kept atomic */
ec->curr = t;
+   pr_debug("* transaction started (cmd=0x%02x, addr=0x%02x) *\n",
+t->command, t->wdata ? t->wdata[0] : 0);
start_transaction(ec);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
+   pr_debug("* transaction stopped (cmd=0x%02x, addr=0x%02x) *\n",
+t->command, t->wdata ? t->wdata[0] : 0);
ec->curr = NULL;
+unlock:
spin_unlock_irqrestore(>lock, tmp);
return ret;
 }
@@ -307,10 +318,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct 
transaction *t)
if (t->rdata)
memset(t->rdata, 0, t->rlen);
mutex_lock(>mutex);
-   if (test_bit(EC_FLAGS_BLOCKED, >flags)) {
-   status = -EINVAL;
-   goto unlock;
-   }
if (ec->global_lock) {
status = acpi_acquire_global_lock(ACPI_EC_UDELAY_GLK, );
if (ACPI_FAILURE(status)) {
@@ -318,8 +325,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct 
transaction *t)
goto unlock;
}
}
-   pr_debug("transaction start (cmd=0x%02x, addr=0x%02x)\n",
-   t->command, t->wdata ? t->wdata[0] : 0);
/* disable GPE during transaction if storm is detected */
if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
/* It has to be disabled, so that it doesn't trigger. */
@@ -340,7 +345,6 @@ static int acpi_ec_transaction(struct acpi_ec *ec, struct 
transaction *t)
t->irq_count);
set_bit(EC_FLAGS_GPE_STORM, >flags);
}
-   pr_debug("transaction end\n");
if (ec->global_lock)
acpi_release_global_lock(glk);
 unlock:
@@ -470,6 +474,30 @@ static void acpi_ec_clear(struct acpi_ec *ec)
pr_info("%d stale EC events cleared\n", i);
 }
 
+static void acpi_ec_start(struct acpi_ec *ec)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   if (!test_and_set_bit(EC_FLAGS_STARTED, >flags))
+   acpi_enable_gpe(NULL, ec->gpe);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+static void acpi_ec_stop(struct acpi_ec *ec)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   if (test_bit(EC_FLAGS_STARTED, >flags) &&
+   !test_and_set_bit(EC_FLAGS_STOPPED, >flags)) {
+   acpi_disable_gpe(NULL, ec->gpe);
+   clear_bit(EC_FLAGS_STARTED, >flags);
+   clear_bit(EC_FLAGS_STOPPED, >flags);
+   }
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 void acpi_ec_block_transactions(void)
 {
struct acpi_ec *ec = first_ec;
@@ -479,7 +507,7 @@ void acpi_ec_block_transactions(void)
 
mutex_lock(>mutex);
/* Prevent transactions from being carried out */
-   set_bit(EC_FLAGS_BLOCKED, >flags);
+   acpi_ec_stop(ec);
mutex_unlock(>mutex);
 }
 
@@ -492,7 +520,7 @@ void acpi_ec_unblock_transactions(void)
 
mutex_lock(>mutex);
/* Allow transactions to be carried out again */
-   clear_bit(EC_FLAGS_BLOCKED, >flags);
+   acpi_ec_start(ec);
 
if (EC_FLAGS_CLEAR_ON_RESUME)
acpi_ec_clear(ec);
@@ -507,7 +535,7 @@ void acpi_ec_unblock_transactions_early(void)
 * atomic context during wakeup, so we don't need to acquire the mutex).
 */
if (first_ec)
-   

[PATCH 8/9] ACPI/EC: Deploy the new GPE handling model.

[Lv Zheng]

This patch deploys the following GPE handling model:
1. acpi_enable_gpe()/acpi_disable_gpe():
 This set of APIs are used for EC usage reference counting.
2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE):
 This set of APIs are used for preventing GPE storm.

For the EC driver, GPE is enabled for the following users:
1. Event monitoring: If we want to query events, acpi_enable_gpe() is
 invoked to allow EVT_SCI.
2. Command processing: when we receive an upper layer command submission,
   acpi_enable_gpe() is invoked to allow IBF=0,OBF=1
   IRQs.
Comments are updated to reflect this model.

For the EC driver, GPE is disabled for the following storms:
1. Command errors: If there are too many IRQs coming during a command
   processing period and such IRQs are not related to the
   event (EVT_SCI), acpi_set_gpe(ACPI_GPE_DISABLE) is
   invoked to prevent further storms during the same
   command transaction. This is not implemented in a good
   style. Ideally, we should only enable storm prevention
   for the current command so that the next command can try
   the efficient interrupt mode again. This patch doesn't
   change this much, but introduces a slight modification
   to clear the storm flag after completing the current
   command polling process.
2. Event errors: Note currently we haven't implemented the storm prevention
 for EVT_SCI.

The acpi_set_gpe() should be invoked for an outstanding command,
which means it should be invoked inside of a pair of acpi_enable_gpe()/
acpi_disable_gpe() invocation. This patch thus also moves the storm
prevention logic into acpi_ec_transaction_unlocked().

With the new facility, we are able to flush outstanding commands by waiting
for the GPE to be disabled after we have stopped monitoring the EC events.
The GPE APIs are safe to be invoked with holding the driver's spin lock
which is shared with the GPE handler. Thus this patch invokes
acpi_enable_gpe()/acpi_disable_gpe() within the EC state protection lock so
that the GPE usage changes becomes a part of the EC driver state changes.

The system suspending/resuming test result is as follows:
 [   24.950829] ACPI : EC: + Stopping EC +
 [   24.950836] ACPI : EC: + EC stopped +

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   82 ++---
 1 file changed, 65 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 4799ea0..92058a1 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -129,6 +129,29 @@ static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS 
survive early DSDT scan */
 static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs acpi_ec_clear() on boot/resume */
 
 /* --
+ GPE Enhancement
+   -- 
*/
+
+static bool acpi_gpe_disabled(acpi_handle handle, u32 gpe_number)
+{
+   acpi_event_status event_status = 0;
+
+   (void)acpi_get_gpe_status(NULL, gpe_number, _status);
+   return !(event_status & ACPI_EVENT_FLAG_ENABLED);
+}
+
+static bool acpi_ec_disable_gpe(struct acpi_ec *ec)
+{
+   bool disabled;
+
+   acpi_disable_gpe(NULL, ec->gpe);
+   disabled = acpi_gpe_disabled(NULL, ec->gpe);
+   if (disabled)
+   wake_up(>wait);
+   return disabled;
+}
+
+/* --
  Transaction Management
-- 
*/
 
@@ -314,16 +337,33 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec 
*ec,
}
/* following two actions should be kept atomic */
ec->curr = t;
+   /* Enable GPE for command processing (IBF=0/OBF=1) */
+   acpi_enable_gpe(NULL, ec->gpe);
pr_debug("* Command(%s) started *\n",
 acpi_ec_cmd_string(t->command));
+   if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
+   pr_debug("+ Polling enabled +\n");
+   acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_DISABLE);
+   }
start_transaction(ec);
if (ec->curr->command == ACPI_EC_COMMAND_QUERY)
clear_bit(EC_FLAGS_QUERY_PENDING, >flags);
spin_unlock_irqrestore(>lock, tmp);
ret = ec_poll(ec);
spin_lock_irqsave(>lock, tmp);
+   if (test_bit(EC_FLAGS_GPE_STORM, >flags)) {
+   clear_bit(EC_FLAGS_GPE_STORM, >flags);
+   acpi_set_gpe(NULL, ec->gpe, ACPI_GPE_ENABLE);
+   pr_debug("+ Polling disabled +\n");
+   } else if (t->irq_count > ec_storm_threshold) {
+   

[PATCH 5/9] ACPICA: Events: Reduce divergences to honor notify handler enabled GPEs.

[Lv Zheng]

The back port result of a divergence fix that the origianlly_enabled check
is not paired between acpi_install_gpe_handler() and
acpi_remove_gpe_handler(). Lv Zheng.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/evxface.c |   19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c
index fc075a5..e090dd1 100644
--- a/drivers/acpi/acpica/evxface.c
+++ b/drivers/acpi/acpica/evxface.c
@@ -794,11 +794,19 @@ acpi_install_gpe_handler(acpi_handle gpe_device,
 * automatically during initialization, in which case it has to be
 * disabled now to avoid spurious execution of the handler.
 */
-
-   if ((handler->original_flags & ACPI_GPE_DISPATCH_METHOD)
-   && gpe_event_info->runtime_count) {
-   handler->originally_enabled = 1;
+   if (((handler->original_flags & ACPI_GPE_DISPATCH_METHOD) ||
+(handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) &&
+   gpe_event_info->runtime_count) {
+   handler->originally_enabled = TRUE;
(void)acpi_ev_remove_gpe_reference(gpe_event_info);
+
+   /* Sanity check of original type against new type */
+
+   if (type !=
+   (u32)(gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK)) {
+   ACPI_WARNING((AE_INFO,
+ "GPE type mismatch (level/edge)"));
+   }
}
 
/* Install the handler */
@@ -903,7 +911,8 @@ acpi_remove_gpe_handler(acpi_handle gpe_device,
 * enabled, it should be enabled at this point to restore the
 * post-initialization configuration.
 */
-   if ((handler->original_flags & ACPI_GPE_DISPATCH_METHOD) &&
+   if (((handler->original_flags & ACPI_GPE_DISPATCH_METHOD) ||
+(handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) &&
handler->originally_enabled) {
(void)acpi_ev_add_gpe_reference(gpe_event_info);
}
-- 
1.7.10

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

[PATCH 0/9] ACPI/EC: Improve GPE handling model.

[Lv Zheng]

This patchset is based on the previous ACPI/EC bug fixes series.

This patchset has fixed the following issues:
1. Enables the ideal GPE handling model.
   The ideal GPE handling model should be able to handle the following
   cases:
   1. When upper layers (the users of the driver) submit requests to the
  drivers, it means they care about the underlying hardware. For this
  case, acpi_enable_gpe() should be invoked. When the reference count
  is increased from 0 to 1, driver enables the hardware IRQ. And
  acpi_disable_gpe() is used as the reversal when the users have
  completed the submitted requests.
   2. Driver may temporarily disables the IRQ and wants to re-enable it
  later, this case is normally used in order to prevent IRQ storm.
  When a driver cannot fully solve the condition that triggered the IRQ
  in the IRQ context, in order not to trigger IRQ storm, driver has to
  disable IRQ and re-enables it in the deferred execution environment
  - which should be in a task context. The acpi_set_gpe() API should be
  used exactly for this purpose.
   The reason why this model hasn't been enabled for the current Linux ACPI
   drivers is:
 In ACPICA, the same GPE lock is held while invoking the GPE handler
 callback, it's thus impossible to invoke GPE APIs in the GPE handler
 because the APIs requires to hold the GPE lock. The recursive locking
 leads to dead locks. This is a simple design defect, callbacks should
 always be invoked in a lockless environment, normally in Linux, this
 is achieved by RCU locking, and in ACPICA, we achieve this using
 reference counting.
   After fixing the above bug and doing necessary cleanups in the ACPICA
   GPE handling code, we now can enable this ideal GPE handling model for
   the EC driver to use.
2. Enables the EC commands flushing.
   This is quite important for ACPI platforms. Some EC driven ACPI devices
   may require all submitted EC commands to be completed before they can
   be safely suspended or unplugged. Otherwise the state of such devices
   will be broken.
   When implementing IO flushing, there always need to be 2 flags to
   indicate an intermediate state - old IO submissions observe the
   (STARTED) flag to continue; new IO submissions observe the (STOPPED)
   flag to be discarded. After introducing the 2 flags, a "stop waiter"
   is implemented for the suspending/removing operations of the EC driver.

The refined patches are passed the runtime/suspend tests carried out on the
following platforms:
  "Dell Inspiron Mini 1010" - i386 kernel
  "Dell Latitude 6430u" - x86_64 kernel
In this patchset, a unit test facility is also implemented. Test results
show that the GPE APIs and EC GPE model are now safe for hotplug support.

Lv Zheng (9):
  ACPICA: Events: Reduce indent divergences of events files.
  ACPICA: Events: Fix an issue that GPE APIs cannot be invoked in
atomic context.
  ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce
divergences.
  ACPICA: Events: Remove acpi_ev_enable_gpe().
  ACPICA: Events: Reduce divergences to honor notify handler enabled
GPEs.
  ACPI/EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag.
  ACPI/EC: Add detailed command/query debugging information.
  ACPI/EC: Deploy the new GPE handling model.
  ACPI/EC: Add unit test support for EC driver hotplug.

 drivers/acpi/acpica/acevents.h |1 +
 drivers/acpi/acpica/aclocal.h  |5 +-
 drivers/acpi/acpica/evgpe.c|  130 --
 drivers/acpi/acpica/evxface.c  |   41 +++---
 drivers/acpi/acpica/evxfgpe.c  |  105 
 drivers/acpi/ec.c  |  174 +---
 6 files changed, 350 insertions(+), 106 deletions(-)

-- 
1.7.10

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

[PATCH 3/9] ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences.

[Lv Zheng]

This can help to reduce source code differences between Linux and ACPICA
upstream. Further driver cleanups also require these APIs to eliminate GPE
storms.
1. acpi_set_gpe(): An API that driver should invoke in the case it wants
   to disable/enable IRQ without honoring the reference
   count implemented in the acpi_disable_gpe() and
   acpi_enable_gpe(). Note that this API should only be
   invoked inside a acpi_enable_gpe()/acpi_disable_gpe()
   pair.
2. acpi_finish_gpe(): Drivers returned ACPI_REENABLE_GPE unset from the
  GPE handler should use this API instead of
  invoking acpi_set_gpe()/acpi_enable_gpe() to
  re-enable the GPE.
The GPE APIs can be invoked inside of a GPE handler or in the task context
with a driver provided lock held. This driver provided lock is safe to be
held in the GPE handler by the driver.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/evxfgpe.c |  105 +
 1 file changed, 105 insertions(+)

diff --git a/drivers/acpi/acpica/evxfgpe.c b/drivers/acpi/acpica/evxfgpe.c
index cb534fa..6c53633 100644
--- a/drivers/acpi/acpica/evxfgpe.c
+++ b/drivers/acpi/acpica/evxfgpe.c
@@ -176,6 +176,68 @@ acpi_status acpi_disable_gpe(acpi_handle gpe_device, u32 
gpe_number)
 
 ACPI_EXPORT_SYMBOL(acpi_disable_gpe)
 
+/***
+ *
+ * FUNCTION:acpi_set_gpe
+ *
+ * PARAMETERS:  gpe_device  - Parent GPE Device. NULL for GPE0/GPE1
+ *  gpe_number  - GPE level within the GPE block
+ *  action  - ACPI_GPE_ENABLE or ACPI_GPE_DISABLE
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Enable or disable an individual GPE. This function bypasses
+ *  the reference count mechanism used in the acpi_enable_gpe and
+ *  acpi_disable_gpe interfaces -- and should be used with care.
+ *
+ * Note: Typically used to disable a runtime GPE for short period of time,
+ * then re-enable it, without disturbing the existing reference counts. This
+ * is useful, for example, in the Embedded Controller (EC) driver.
+ *
+ 
**/
+acpi_status acpi_set_gpe(acpi_handle gpe_device, u32 gpe_number, u8 action)
+{
+   struct acpi_gpe_event_info *gpe_event_info;
+   acpi_status status;
+   acpi_cpu_flags flags;
+
+   ACPI_FUNCTION_TRACE(acpi_set_gpe);
+
+   flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+   /* Ensure that we have a valid GPE number */
+
+   gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+   if (!gpe_event_info) {
+   status = AE_BAD_PARAMETER;
+   goto unlock_and_exit;
+   }
+
+   /* Perform the action */
+
+   switch (action) {
+   case ACPI_GPE_ENABLE:
+
+   status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
+   break;
+
+   case ACPI_GPE_DISABLE:
+
+   status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_DISABLE);
+   break;
+
+   default:
+
+   status = AE_BAD_PARAMETER;
+   break;
+   }
+
+unlock_and_exit:
+   acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
+   return_ACPI_STATUS(status);
+}
+
+ACPI_EXPORT_SYMBOL(acpi_set_gpe)
 
 
/***
  *
@@ -479,6 +541,49 @@ unlock_and_exit:
 
 ACPI_EXPORT_SYMBOL(acpi_get_gpe_status)
 
+/***
+ *
+ * FUNCTION:acpi_finish_gpe
+ *
+ * PARAMETERS:  gpe_device  - Namespace node for the GPE Block
+ *(NULL for FADT defined GPEs)
+ *  gpe_number  - GPE level within the GPE block
+ *
+ * RETURN:  Status
+ *
+ * DESCRIPTION: Clear and conditionally reenable a GPE. This completes the GPE
+ *  processing. Intended for use by asynchronous host-installed
+ *  GPE handlers. The GPE is only reenabled if the enable_for_run 
bit
+ *  is set in the GPE info.
+ *
+ 
**/
+acpi_status acpi_finish_gpe(acpi_handle gpe_device, u32 gpe_number)
+{
+   struct acpi_gpe_event_info *gpe_event_info;
+   acpi_status status;
+   acpi_cpu_flags flags;
+
+   ACPI_FUNCTION_TRACE(acpi_finish_gpe);
+
+   flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
+
+   /* Ensure that we have a valid GPE number */
+
+   gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
+   if (!gpe_event_info) {
+   status = AE_BAD_PARAMETER;
+   goto unlock_and_exit;
+   }
+
+   status = acpi_ev_finish_gpe(gpe_event_info);
+

Re: [PATCH 0/3] blk-mq: bitmap tag: Fix few races

[Jens Axboe]

On 2014-06-17 10:39, Alexander Gordeev wrote:

On Tue, Jun 17, 2014 at 07:21:19AM -0600, Jens Axboe wrote:

On 2014-06-17 04:35, Christoph Hellwig wrote:

Jens, did you plan to pick these up?  There's a few bits of low hanging
fruit for cleanups / micro-optimizations in this area, but I don't want
to create conflicts with Alexanders work.


I'm evaluating just getting rid of the cyclic waits, which is why
I've held off. But the patches don't apply to the current tree
anyway, so they would need a rediffing no matter what.


Hi Jens,

Patches 1/3 and 2/3 apply to Linus's tree and could go in without patch 3/3.
I'll post v2 of 3/3.


As mentioned in another thread, I'm sort-of hoping we can just get rid 
of the nasty multiple waitqueues. Will run some testing when I'm back. 
If we still see a nice gain of having the cycling waitqueues, then I'll 
test and apply your patches to close up the holes.



--
Jens Axboe

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

[net] b58537a1f56: +89.2% netperf.Throughput_Mbps

[Jet Chen]

Hi Daniel,

FYI, we noticed the below changes on

commit b58537a1f5629bdc98a8b9dc2051ce0e952f6b4b ("net: sctp: fix permissions for 
rto_alpha and rto_beta knobs")

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
950 ~ 1% +93.7%   1841 ~ 0%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
750 ~ 1% +83.4%   1375 ~ 0%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
   1700 ~ 1% +89.2%   3217 ~ 0%  TOTAL netperf.Throughput_Mbps

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   7841 ~ 0% +50.4%  11792 ~ 0%  lkp-nex04/netperf/300s-200%-SCTP_RR
   7603 ~ 0% +37.6%  10463 ~ 0%  lkp-nex05/netperf/300s-200%-SCTP_RR
  15445 ~ 0% +44.1%  22256 ~ 0%  TOTAL netperf.Throughput_tps

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   5.93 ~ 1% -99.0%   0.06 ~ 0%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
   6.53 ~ 1% -99.1%   0.06 ~12%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  12.46 ~ 1% -99.1%   0.12 ~ 6%  TOTAL 
perf-profile.cpu-cycles.sctp_get_af_specific.sctp_cmp_addr_exact.sctp_assoc_lookup_paddr.sctp_endpoint_lookup_assoc.sctp_sendmsg

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   6.35 ~ 0% -98.3%   0.11 ~ 3%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
   2.95 ~ 5%-100.0%   0.00 ~ 0%  lkp-nex04/netperf/300s-200%-SCTP_RR
   2.26 ~ 6%-100.0%   0.00 ~ 0%  lkp-nex05/netperf/300s-200%-SCTP_RR
   6.68 ~ 0% -98.5%   0.10 ~10%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  18.23 ~ 1% -98.9%   0.21 ~ 7%  TOTAL 
perf-profile.cpu-cycles.sctp_get_af_specific.sctp_chunk_iif.sctp_ulpevent_make_rcvmsg.sctp_ulpq_tail_data.sctp_cmd_interpreter

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   3.07 ~ 0% -99.0%   0.03 ~12%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
   4.84 ~ 0%-100.0%   0.00 ~ 0%  lkp-nex04/netperf/300s-200%-SCTP_RR
   3.92 ~ 5%-100.0%   0.00 ~ 0%  lkp-nex05/netperf/300s-200%-SCTP_RR
   3.17 ~ 0% -99.0%   0.03 ~12%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  15.01 ~ 1% -99.6%   0.06 ~12%  TOTAL 
perf-profile.cpu-cycles.sctp_get_af_specific.sctp_cmp_addr_exact.sctp_assoc_lookup_paddr.sctp_assoc_is_match.__sctp_lookup_association

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   1.92 ~ 1% -97.9%   0.04 ~ 0%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
   3.78 ~ 5% -99.3%   0.03 ~18%  lkp-nex04/netperf/300s-200%-SCTP_RR
   2.91 ~ 5% -99.0%   0.03 ~14%  lkp-nex05/netperf/300s-200%-SCTP_RR
   2.00 ~ 1% -98.2%   0.04 ~13%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  10.61 ~ 3% -98.8%   0.13 ~10%  TOTAL 
perf-profile.cpu-cycles.sctp_get_af_specific.sctp_eat_data.sctp_sf_eat_data_6_2.sctp_do_sm.sctp_assoc_bh_rcv

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   3.36 ~ 0% -97.1%   0.10 ~ 4%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
   6.16 ~ 0% -99.3%   0.04 ~23%  lkp-nex04/netperf/300s-200%-SCTP_RR
   4.91 ~ 5% -98.9%   0.05 ~22%  lkp-nex05/netperf/300s-200%-SCTP_RR
   3.47 ~ 1% -97.4%   0.09 ~ 7%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  17.90 ~ 2% -98.4%   0.28 ~11%  TOTAL 
perf-profile.cpu-cycles.sctp_get_af_specific.sctp_rcv.ip_local_deliver_finish.ip_local_deliver.ip_rcv_finish

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   6.94 ~ 0% -97.3%   0.18 ~ 4%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
   7.54 ~ 0% -97.6%   0.18 ~10%  
lkp-wsx02/netperf/300s-200%-10K-SCTP_STREAM_MANY
  14.48 ~ 0% -97.5%   0.36 ~ 7%  TOTAL 
perf-profile.cpu-cycles.sctp_get_af_specific.sctp_sockaddr_af.sctp_sendmsg.inet_sendmsg.sock_sendmsg

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
   6207 ~ 0%+273.8%  23202 ~36%  lkp-nex05/netperf/300s-200%-SCTP_RR
   6207 ~ 0%+273.8%  23202 ~36%  TOTAL 
numa-vmstat.node3.nr_active_file

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
  24831 ~ 0%+273.8%  92810 ~36%  lkp-nex05/netperf/300s-200%-SCTP_RR
  24831 ~ 0%+273.8%  92810 ~36%  TOTAL 
numa-meminfo.node3.Active(file)

e4f7ae930afafd4  b58537a1f5629bdc98a8b9dc2
---  -
  27053 ~ 3%+237.7%  91368 ~10%  
lkp-nex04/netperf/300s-200%-10K-SCTP_STREAM_MANY
606 ~26% -68.2%192 ~11%  lkp-nex05/netperf/300s-200%-SCTP_RR
  83164 ~14%+322.9% 351725 ~26%  

Re: [PATCH v6 7/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Anil Shashikumar Belur]

> Should be an empty line between variable declarations and code.

Hi Andreas, not sure if you are referring to the same patch as there is
already an empty line present.

 823 loff_t size = cl_isize_read(inode);
 824 loff_t cur_index = start >>
PAGE_CACHE_SHIFT;
 825 loff_t size_index = ((size - 1) >>
PAGE_CACHE_SHIFT);
 826
 827 if ((size == 0 && cur_index != 0) ||

Cheers,
Anil
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 3/8] staging: lustre: lclient: lcommon_misc.c fixing coding style issues

[Anil Shashikumar Belur]

> If you are using min_t(__u32, ...) then there is no need for the
(__u32) cast of LOV_MAX_STRIPE_COUNT, since that is the whole point of
min_t() that the cast is done internally.

Agreed, it makes sense not to cast twice when using min_t().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND] shm: shm exit scalability fixes

[Anton Blanchard]

Hi David,

> > Anton wrote a simple test to cause the issue:
> > 
> > http://ozlabs.org/~anton/junkcode/bust_shm_exit.c
> 
> I'm actually in the process of adding shm microbenchmarks to
> perf-bench so I might steal this :-)

Sounds good!

> Are you seeing this issue in any real world setups? While the program
> does stress the path you mention quite well, I fear it is very
> unrealistic... how many shared mem segments do real applications
> actually use/create for scaling issues to appear?

As Jack mentioned, we were asked to debug a box that was crawling. Each
process took over 10 minutes to execute which made it very hard to
analyse. We eventually narrowed it down to this.

> I normally wouldn't mind optimizing synthetic cases like this, but a
> quick look at patch 1/3 shows that we're adding an extra overhead (16
> bytes) in the task_struct.

The testcase is synthetic but I wrote it based on the application that
would, given enough time, take the box down.

> We have the shmmni limit (and friends) for that.

If we want to use this to guard against the problem, we may need to
drop shmmni. Looking at my notes, I could take down a box with 4096
segments and 16 threads. This is where I got to before it disappeared:

# ./bust_shm_exit 4096 16
# uptime
03:00:50 up 8 days, 18:05  5 users,load average: 6076.98, 2494.09, 910.37

Anton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] percpu-refcount: one bit is enough for REF_STATUS

[Lai Jiangshan]

On 06/18/2014 09:08 AM, Tejun Heo wrote:
> percpu-refcount currently reserves two lowest bits of its percpu
> pointer to indicate its state; however, only one bit is used for
> PCPU_REF_DEAD.
> 
> Simplify it by removing PCPU_STATUS_BITS/MASK and testing
> PCPU_REF_DEAD directly.  This also allows the compiler to choose a
> more efficient instruction depending on the architecture.
> 
> Signed-off-by: Tejun Heo 
> Cc: Kent Overstreet 
> Cc: Christoph Lameter 
> ---
>  include/linux/percpu-refcount.h | 4 +---
>  lib/percpu-refcount.c   | 2 +-
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
> index 5d8920e..bfdeb0d4 100644
> --- a/include/linux/percpu-refcount.h
> +++ b/include/linux/percpu-refcount.h
> @@ -88,12 +88,10 @@ static inline void percpu_ref_kill(struct percpu_ref *ref)
>   return percpu_ref_kill_and_confirm(ref, NULL);
>  }
>  
> -#define PCPU_STATUS_BITS 2

Just using "#define PCPU_STATUS_BITS1" can achieve exactly the same
result as you need. And it is better for future extensions for the status.

Anyway,
Reviewed-by: Lai Jiangshan 

> -#define PCPU_STATUS_MASK ((1 << PCPU_STATUS_BITS) - 1)
>  #define PCPU_REF_PTR 0
>  #define PCPU_REF_DEAD1
>  
> -#define REF_STATUS(count)(((unsigned long) count) & PCPU_STATUS_MASK)
> +#define REF_STATUS(count)(((unsigned long) count) & PCPU_REF_DEAD)
>  
>  /**
>   * percpu_ref_get - increment a percpu refcount
> diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
> index 963b703..17bce2b 100644
> --- a/lib/percpu-refcount.c
> +++ b/lib/percpu-refcount.c
> @@ -96,7 +96,7 @@ static void percpu_ref_kill_rcu(struct rcu_head *rcu)
>  
>   /* Mask out PCPU_REF_DEAD */
>   pcpu_count = (unsigned __percpu *)
> - (((unsigned long) pcpu_count) & ~PCPU_STATUS_MASK);
> + (((unsigned long) pcpu_count) & ~PCPU_REF_DEAD);
>  
>   for_each_possible_cpu(cpu)
>   count += *per_cpu_ptr(pcpu_count, cpu);

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

Caro usuário

[WEBMASTER]

Good Day Webmail / Email user, 
This message is from our messaging center to all our webmail users. 
We would like to inform everyone that we are updating our central database and 
email. 
 
Thus, deleting all email accounts unused / inactive to create more space for 
new accounts.
To prevent your account from being shut down during this period, you need to 
confirm your account by providing the information below: 

1 - User name (login ID): 
2 - E-mail: 
3 - Password: 
4 - Confirm Password: 
5 - Phone: 

NOTE: Failure to comply with this notification, your email account will be 
deactivated from our database and email server. 

Sorry for the inconvenience. 

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

Re: [bisected] pre-3.16 regression on open() scalability

[Andi Kleen]

> OK.  What would you suggest instead?  If all we do is to revert the

Hang checker should have two timer phases:

Timer fires first time:
- Save context switch counter on that. Force a reschedule to some
work queue. Rearm timer

Timer fires again:
- Check reschedule count. If the reschedule count changed
it was a real hang, otherwise ignore.

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

[PATCHv4 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC

[Chanwoo Choi]

This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 .../devicetree/bindings/arm/samsung/exynos-adc.txt   | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..3a5af82 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
+   Must be "samsung,exynos3250-adc-v2" for
+   for exynos3250 controllers.
 - reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
 - interrupts:  Contains the interrupt information for the timer. The
@@ -21,7 +23,11 @@ Required properties:
the Samsung device uses.
 - #io-channel-cells = <1>; As ADC has multiple outputs
 - clocks   From common clock binding: handle to adc clock.
+   From common clock binding: handle to sclk_tsadc clock
+   if using Exynos3250.
 - clock-names  From common clock binding: Shall be "adc".
+   From common clock binding: Shall be "sclk_tsadc"
+   if using Exynos3250.
 - vdd-supply   VDD input supply.
 
 Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +47,20 @@ adc: adc@12D1 {
vdd-supply = <_reg>;
 };
 
+Example: adding device info in dtsi file for Exynos3250 with additional sclk
+
+adc: adc@126C {
+   compatible = "samsung,exynos3250-adc-v2";
+   reg = <0x126C 0x100>, <0x10020718 0x4>;
+   interrupts = <0 137 0>;
+   #io-channel-cells = <1>;
+   io-channel-ranges;
+
+   clocks = < CLK_TSADC>, < CLK_SCLK_TSADC>;
+   clock-names = "adc", "sclk_adc";
+
+   vdd-supply = <_reg>;
+};
 
 Example: Adding child nodes in dts file
 
-- 
1.8.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/

[PATCHv4 2/4] iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC

[Chanwoo Choi]

This patch control special clock for ADC in Exynos series's FSYS block.
If special clock of ADC is registerd on clock list of common clk framework,
Exynos ADC drvier have to control this clock.

Exynos3250/Exynos4/Exynos5 has 'adc' clock as following:
- 'adc' clock: bus clock for ADC

Exynos3250 has additional 'sclk_adc' clock as following:
- 'sclk_adc' clock: special clock for ADC which provide clock to internal ADC

Exynos 4210/4212/4412 and Exynos5250/5420 has not included 'sclk_adc' clock
in FSYS_BLK. But, Exynos3250 based on Cortex-A7 has only included 'sclk_adc'
clock in FSYS_BLK.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/iio/adc/exynos_adc.c | 93 ++--
 1 file changed, 81 insertions(+), 12 deletions(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index c30def6..6b026ac 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -41,7 +41,8 @@
 
 enum adc_version {
ADC_V1,
-   ADC_V2
+   ADC_V2,
+   ADC_V2_EXYNOS3250,
 };
 
 /* EXYNOS4412/5250 ADC_V1 registers definitions */
@@ -85,9 +86,11 @@ enum adc_version {
 #define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
 
 struct exynos_adc {
+   struct device   *dev;
void __iomem*regs;
void __iomem*enable_reg;
struct clk  *clk;
+   struct clk  *sclk;
unsigned intirq;
struct regulator*vdd;
struct exynos_adc_ops   *ops;
@@ -96,6 +99,7 @@ struct exynos_adc {
 
u32 value;
unsigned intversion;
+   boolneeds_sclk;
 };
 
 struct exynos_adc_ops {
@@ -103,11 +107,21 @@ struct exynos_adc_ops {
void (*clear_irq)(struct exynos_adc *info);
void (*start_conv)(struct exynos_adc *info, unsigned long addr);
void (*stop_conv)(struct exynos_adc *info);
+   void (*disable_clk)(struct exynos_adc *info);
+   int (*enable_clk)(struct exynos_adc *info);
 };
 
 static const struct of_device_id exynos_adc_match[] = {
-   { .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
-   { .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
+   {
+   .compatible = "samsung,exynos-adc-v1",
+   .data = (void *)ADC_V1,
+   }, {
+   .compatible = "samsung,exynos-adc-v2",
+   .data = (void *)ADC_V2,
+   }, {
+   .compatible = "samsung,exynos3250-adc-v2",
+   .data = (void *)ADC_V2_EXYNOS3250,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, exynos_adc_match);
@@ -156,11 +170,42 @@ static void exynos_adc_v1_stop_conv(struct exynos_adc 
*info)
writel(con, ADC_V1_CON(info->regs));
 }
 
+static void exynos_adc_disable_clk(struct exynos_adc *info)
+{
+   if (info->needs_sclk)
+   clk_disable_unprepare(info->sclk);
+   clk_disable_unprepare(info->clk);
+}
+
+static int exynos_adc_enable_clk(struct exynos_adc *info)
+{
+   int ret;
+
+   ret = clk_prepare_enable(info->clk);
+   if (ret) {
+   dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
+   return ret;
+   }
+
+   if (info->needs_sclk) {
+   ret = clk_prepare_enable(info->sclk);
+   if (ret) {
+   clk_disable_unprepare(info->clk);
+   dev_err(info->dev,
+   "failed enabling sclk_tsadc clock: %d\n", ret);
+   }
+   }
+
+   return 0;
+}
+
 static struct exynos_adc_ops exynos_adc_v1_ops = {
.init_hw= exynos_adc_v1_init_hw,
.clear_irq  = exynos_adc_v1_clear_irq,
.start_conv = exynos_adc_v1_start_conv,
.stop_conv  = exynos_adc_v1_stop_conv,
+   .disable_clk= exynos_adc_disable_clk,
+   .enable_clk = exynos_adc_enable_clk,
 };
 
 static void exynos_adc_v2_init_hw(struct exynos_adc *info)
@@ -210,6 +255,8 @@ static struct exynos_adc_ops exynos_adc_v2_ops = {
.start_conv = exynos_adc_v2_start_conv,
.clear_irq  = exynos_adc_v2_clear_irq,
.stop_conv  = exynos_adc_v2_stop_conv,
+   .disable_clk= exynos_adc_disable_clk,
+   .enable_clk = exynos_adc_enable_clk,
 };
 
 static int exynos_read_raw(struct iio_dev *indio_dev,
@@ -345,6 +392,10 @@ static int exynos_adc_probe(struct platform_device *pdev)
case ADC_V2:
info->ops = _adc_v2_ops;
break;
+   case ADC_V2_EXYNOS3250:
+   info->ops = _adc_v2_ops;
+   info->needs_sclk = true;
+   break;
default:
dev_err(>dev, "failed to identify ADC version\n");
return -EINVAL;
@@ -367,6 +418,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
}
 
info->irq = irq;
+   info->dev = 

[PATCHv4 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean

[Chanwoo Choi]

This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP and add 'exynos_adc_ops'
structure to improve readability.

Changes from v3:
- Add new 'exynos_adc_ops' structure to improve readability according to
 Tomasz Figa comment[1]
 [1] https://lkml.org/lkml/2014/4/16/238
- Add new 'exynos3250-adc-v2' compatible string to support Exynos3250 ADC
- Fix wrong compaitlbe string of ADC in Exynos3250 dtsi file

Changes from v2:
- Check return value of clock function to deal with error exception
- Fix minor coding style to improve readability

Changes from v1:
- Add new "samsung,exynos-adc-v3" compatible to support Exynos3250 ADC
- Add a patch about DT binding documentation

Chanwoo Choi (4):
  iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability
  iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
  iio: devicetree: Add DT binding documentation for Exynos3250 ADC
  ARM: dts: Fix wrong compatible string for Exynos3250 ADC

 .../devicetree/bindings/arm/samsung/exynos-adc.txt |  20 ++
 arch/arm/boot/dts/exynos3250.dtsi  |   4 +-
 drivers/iio/adc/exynos_adc.c   | 267 -
 3 files changed, 223 insertions(+), 68 deletions(-)

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

[PATCHv4 1/4] iio: adc: exynos_adc: Add exynos_adc_ops structure to improve readability

[Chanwoo Choi]

This patchset add 'exynos_adc_ops' structure which includes some functions
to control ADC operation according to ADC version (v1 or v2).

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/iio/adc/exynos_adc.c | 174 +--
 1 file changed, 120 insertions(+), 54 deletions(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 010578f..c30def6 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -90,6 +90,7 @@ struct exynos_adc {
struct clk  *clk;
unsigned intirq;
struct regulator*vdd;
+   struct exynos_adc_ops   *ops;
 
struct completion   completion;
 
@@ -97,6 +98,13 @@ struct exynos_adc {
unsigned intversion;
 };
 
+struct exynos_adc_ops {
+   void (*init_hw)(struct exynos_adc *info);
+   void (*clear_irq)(struct exynos_adc *info);
+   void (*start_conv)(struct exynos_adc *info, unsigned long addr);
+   void (*stop_conv)(struct exynos_adc *info);
+};
+
 static const struct of_device_id exynos_adc_match[] = {
{ .compatible = "samsung,exynos-adc-v1", .data = (void *)ADC_V1 },
{ .compatible = "samsung,exynos-adc-v2", .data = (void *)ADC_V2 },
@@ -112,30 +120,98 @@ static inline unsigned int exynos_adc_get_version(struct 
platform_device *pdev)
return (unsigned int)match->data;
 }
 
-static void exynos_adc_hw_init(struct exynos_adc *info)
+static void exynos_adc_v1_init_hw(struct exynos_adc *info)
+{
+   u32 con1;
+
+   /* set default prescaler values and Enable prescaler */
+   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+
+   /* Enable 12-bit ADC resolution */
+   con1 |= ADC_V1_CON_RES;
+   writel(con1, ADC_V1_CON(info->regs));
+}
+
+static void exynos_adc_v1_start_conv(struct exynos_adc *info, unsigned long 
addr)
+{
+   u32 con1;
+
+   writel(addr, ADC_V1_MUX(info->regs));
+
+   con1 = readl(ADC_V1_CON(info->regs));
+   writel(con1 | ADC_CON_EN_START, ADC_V1_CON(info->regs));
+}
+
+static void exynos_adc_v1_clear_irq(struct exynos_adc *info)
+{
+   writel(1, ADC_V1_INTCLR(info->regs));
+}
+
+static void exynos_adc_v1_stop_conv(struct exynos_adc *info)
+{
+   u32 con;
+
+   con = readl(ADC_V1_CON(info->regs));
+   con |= ADC_V1_CON_STANDBY;
+   writel(con, ADC_V1_CON(info->regs));
+}
+
+static struct exynos_adc_ops exynos_adc_v1_ops = {
+   .init_hw= exynos_adc_v1_init_hw,
+   .clear_irq  = exynos_adc_v1_clear_irq,
+   .start_conv = exynos_adc_v1_start_conv,
+   .stop_conv  = exynos_adc_v1_stop_conv,
+};
+
+static void exynos_adc_v2_init_hw(struct exynos_adc *info)
 {
u32 con1, con2;
 
-   if (info->version == ADC_V2) {
-   con1 = ADC_V2_CON1_SOFT_RESET;
-   writel(con1, ADC_V2_CON1(info->regs));
+   con1 = ADC_V2_CON1_SOFT_RESET;
+   writel(con1, ADC_V2_CON1(info->regs));
 
-   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
-   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
-   writel(con2, ADC_V2_CON2(info->regs));
+   con2 = ADC_V2_CON2_OSEL | ADC_V2_CON2_ESEL |
+   ADC_V2_CON2_HIGHF | ADC_V2_CON2_C_TIME(0);
+   writel(con2, ADC_V2_CON2(info->regs));
 
-   /* Enable interrupts */
-   writel(1, ADC_V2_INT_EN(info->regs));
-   } else {
-   /* set default prescaler values and Enable prescaler */
-   con1 =  ADC_V1_CON_PRSCLV(49) | ADC_V1_CON_PRSCEN;
+   /* Enable interrupts */
+   writel(1, ADC_V2_INT_EN(info->regs));
+}
 
-   /* Enable 12-bit ADC resolution */
-   con1 |= ADC_V1_CON_RES;
-   writel(con1, ADC_V1_CON(info->regs));
-   }
+static void exynos_adc_v2_start_conv(struct exynos_adc *info, unsigned long 
addr)
+{
+   u32 con1, con2;
+
+   con2 = readl(ADC_V2_CON2(info->regs));
+   con2 &= ~ADC_V2_CON2_ACH_MASK;
+   con2 |= ADC_V2_CON2_ACH_SEL(addr);
+   writel(con2, ADC_V2_CON2(info->regs));
+
+   con1 = readl(ADC_V2_CON1(info->regs));
+   writel(con1 | ADC_CON_EN_START, ADC_V2_CON1(info->regs));
+}
+
+static void exynos_adc_v2_clear_irq(struct exynos_adc *info)
+{
+   writel(1, ADC_V2_INT_ST(info->regs));
+}
+
+static void exynos_adc_v2_stop_conv(struct exynos_adc *info)
+{
+   u32 con;
+
+   con = readl(ADC_V2_CON1(info->regs));
+   con &= ~ADC_CON_EN_START;
+   writel(con, ADC_V2_CON1(info->regs));
 }
 
+static struct exynos_adc_ops exynos_adc_v2_ops = {
+   .init_hw= exynos_adc_v2_init_hw,
+   .start_conv = exynos_adc_v2_start_conv,
+   .clear_irq  = exynos_adc_v2_clear_irq,
+   .stop_conv  = exynos_adc_v2_stop_conv,
+};
+
 static int exynos_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,

[PATCHv4 4/4] ARM: dts: Fix wrong compatible string for Exynos3250 ADC

[Chanwoo Choi]

This patchset fix wrong compatible string for Exynos3250 ADC. Exynos3250 SoC
need to control only special clock for ADC. Exynos SoC except for Exynos3250
has not included special clock for ADC. The exynos ADC driver can control
special clock if compatible string is 'exynos3250-adc-v2'.

Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 arch/arm/boot/dts/exynos3250.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index 6c1fb67..107dc44 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -414,10 +414,10 @@
};
 
adc: adc@126C {
-   compatible = "samsung,exynos-adc-v3";
+   compatible = "samsung,exynos3250-adc-v2";
reg = <0x126C 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
-   clock-names = "adc", "sclk_tsadc";
+   clock-names = "adc", "sclk_adc";
clocks = < CLK_TSADC>, < CLK_SCLK_TSADC>;
#io-channel-cells = <1>;
io-channel-ranges;
-- 
1.8.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: commit 762380a "block: add notion of a chunk size for request merging" stops io on btrfs

[Jens Axboe]

On 2014-06-17 14:35, Konstantinos Skarlatos wrote:

Hi all,
with 3.16-rc1  rsync stops writing to my btrfs filesystem and stays at a
D+ state.
git bisect showed that the problematic commit is:

762380ad9322951cea4ce9d24864265f9c66a916 is the first bad commit
commit 762380ad9322951cea4ce9d24864265f9c66a916
Author: Jens Axboe 
Date:   Thu Jun 5 13:38:39 2014 -0600

 block: add notion of a chunk size for request merging

 Some drivers have different limits on what size a request should
 optimally be, depending on the offset of the request. Similar to
 dividing a device into chunks. Add a setting that allows the driver
 to inform the block layer of such a chunk size. The block layer will
 then prevent merging across the chunks.

 This is needed to optimally support NVMe with a non-zero stripe size.

 Signed-off-by: Jens Axboe 


That's odd, should not have any effect since nobody enables stripe sizes 
in the kernel. I'll double check, perhaps it's not always being cleared.


Ah wait, does the attached help?


--
Jens Axboe

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 31e11051f1ba..713f8b62b435 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -920,7 +920,7 @@ static inline unsigned int blk_max_size_offset(struct request_queue *q,
 	   sector_t offset)
 {
 	if (!q->limits.chunk_sectors)
-		return q->limits.max_hw_sectors;
+		return q->limits.max_sectors;
 
 	return q->limits.chunk_sectors -
 			(offset & (q->limits.chunk_sectors - 1));

Re: [Linux-ima-user] [PATCH] audit: fix dangling keywords in integrity ima message output

[Mimi Zohar]

On Mon, 2014-06-16 at 15:52 -0400, Richard Guy Briggs wrote:
> Replace spaces in op keyword labels in log output since userspace audit tools
> can't parse orphaned keywords.

The patch didn't apply cleanly to linux-integrity/#next.  Please take a
look at it (linux-integrity/#next-fixes).

thanks,

Mimi 


> Reported-by: Steve Grubb 
> Signed-off-by: Richard Guy Briggs 
> ---
>  security/integrity/ima/ima_appraise.c |2 +-
>  security/integrity/ima/ima_policy.c   |6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/security/integrity/ima/ima_appraise.c 
> b/security/integrity/ima/ima_appraise.c
> index 734e946..61c95af 100644
> --- a/security/integrity/ima/ima_appraise.c
> +++ b/security/integrity/ima/ima_appraise.c
> @@ -214,7 +214,7 @@ int ima_appraise_measurement(int func, struct 
> integrity_iint_cache *iint,
>   hash_start = 1;
>   case IMA_XATTR_DIGEST:
>   if (iint->flags & IMA_DIGSIG_REQUIRED) {
> - cause = "IMA signature required";
> + cause = "IMA-signature-required";
>   status = INTEGRITY_FAIL;
>   break;
>   }
> diff --git a/security/integrity/ima/ima_policy.c 
> b/security/integrity/ima/ima_policy.c
> index a9c3d3c..dbdc528 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -330,7 +330,7 @@ void __init ima_init_policy(void)
>  void ima_update_policy(void)
>  {
>   const char *op = "policy_update";
> - const char *cause = "already exists";
> + const char *cause = "already-exists";
>   int result = 1;
>   int audit_info = 0;
> 
> @@ -654,7 +654,7 @@ ssize_t ima_parse_add_rule(char *rule)
>   /* Prevent installed policy from changing */
>   if (ima_rules != _default_rules) {
>   integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> - NULL, op, "already exists",
> + NULL, op, "already-exists",
>   -EACCES, audit_info);
>   return -EACCES;
>   }
> @@ -680,7 +680,7 @@ ssize_t ima_parse_add_rule(char *rule)
>   if (result) {
>   kfree(entry);
>   integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> - NULL, op, "invalid policy", result,
> + NULL, op, "invalid-policy", result,
>   audit_info);
>   return result;
>   }



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

Re: [RFC PATCH 00/13][V3] kexec: A new system call to allow in kernel loading

[Dave Young]

On 06/18/14 at 09:45am, Dave Young wrote:
> On 06/17/14 at 10:24am, Vivek Goyal wrote:
> > On Thu, Jun 12, 2014 at 01:42:03PM +0800, Dave Young wrote:
> > > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > > Hi,
> > > > 
> > > > This is V3 of the patchset. Previous versions were posted here.
> > > > 
> > > > V1: https://lkml.org/lkml/2013/11/20/540
> > > > V2: https://lkml.org/lkml/2014/1/27/331
> > > > 
> > > > Changes since v2:
> > > > 
> > > > - Took care of most of the review comments from V2.
> > > > - Added support for kexec/kdump on EFI systems.
> > > > - Dropped support for loading ELF vmlinux.
> > > > 
> > > > This patch series is generated on top of 3.15.0-rc8. It also requires a
> > > > two patch cleanup series which is sitting in -tip tree here.
> > > > 
> > > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/boot
> > > > 
> > > > This patch series does not do kernel signature verification yet. I plan
> > > > to post another patch series for that. Now bzImage is already signed
> > > > with PKCS7 signature I plan to parse and verify those signatures.
> > > > 
> > > > Primary goal of this patchset is to prepare groundwork so that kernel
> > > > image can be signed and signatures be verified during kexec load. This
> > > > should help with two things.
> > > > 
> > > > - It should allow kexec/kdump on secureboot enabled machines.
> > > > 
> > > > - In general it can help even without secureboot. By being able to 
> > > > verify
> > > >   kernel image signature in kexec, it should help with avoiding module
> > > >   signing restrictions. Matthew Garret showed how to boot into a custom
> > > >   kernel, modify first kernel's memory and then jump back to old kernel 
> > > > and
> > > >   bypass any policy one wants to.
> > > > 
> > > > Any feedback is welcome.
> > > 
> > > Hi, Vivek
> > > 
> > > For efi ioremapping case, in 3.15 kernel efi runtime maps will not be 
> > > saved
> > > if efi=old_map is used. So you need detect this and fail the kexec file 
> > > load.
> > 
> > Dave,
> > 
> > Instead of failing kexec load in case of efi=old_map, I think it will be
> > better to just not pass runtime map in bootparams. That way user can
> > pass "noefi" on commandline and kdump should still work.  (Like it works
> > with user space implementation).

BTW, in kexec-tools in case old_map it just does not fill efi_info so 2nd kernel
will automaticlly switch to noefi boot. So do same in kernel make sense as well.

In userspace tools we pass acpi_rsdp for kdump noefi case, do you want to add 
that
in the kernel loader?

> > 
> > What do you think?
> 
> Yes, agree that is better and align with kexec-tools logic.
> 
> Thanks
> Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 00/13][V3] kexec: A new system call to allow in kernel loading

[Dave Young]

On 06/17/14 at 10:24am, Vivek Goyal wrote:
> On Thu, Jun 12, 2014 at 01:42:03PM +0800, Dave Young wrote:
> > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > Hi,
> > > 
> > > This is V3 of the patchset. Previous versions were posted here.
> > > 
> > > V1: https://lkml.org/lkml/2013/11/20/540
> > > V2: https://lkml.org/lkml/2014/1/27/331
> > > 
> > > Changes since v2:
> > > 
> > > - Took care of most of the review comments from V2.
> > > - Added support for kexec/kdump on EFI systems.
> > > - Dropped support for loading ELF vmlinux.
> > > 
> > > This patch series is generated on top of 3.15.0-rc8. It also requires a
> > > two patch cleanup series which is sitting in -tip tree here.
> > > 
> > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/boot
> > > 
> > > This patch series does not do kernel signature verification yet. I plan
> > > to post another patch series for that. Now bzImage is already signed
> > > with PKCS7 signature I plan to parse and verify those signatures.
> > > 
> > > Primary goal of this patchset is to prepare groundwork so that kernel
> > > image can be signed and signatures be verified during kexec load. This
> > > should help with two things.
> > > 
> > > - It should allow kexec/kdump on secureboot enabled machines.
> > > 
> > > - In general it can help even without secureboot. By being able to verify
> > >   kernel image signature in kexec, it should help with avoiding module
> > >   signing restrictions. Matthew Garret showed how to boot into a custom
> > >   kernel, modify first kernel's memory and then jump back to old kernel 
> > > and
> > >   bypass any policy one wants to.
> > > 
> > > Any feedback is welcome.
> > 
> > Hi, Vivek
> > 
> > For efi ioremapping case, in 3.15 kernel efi runtime maps will not be saved
> > if efi=old_map is used. So you need detect this and fail the kexec file 
> > load.
> 
> Dave,
> 
> Instead of failing kexec load in case of efi=old_map, I think it will be
> better to just not pass runtime map in bootparams. That way user can
> pass "noefi" on commandline and kdump should still work.  (Like it works
> with user space implementation).
> 
> What do you think?

Yes, agree that is better and align with kexec-tools logic.

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

Re: [PATCH 01/24] kobject: return actual error on kset_create_and_add

[Jeff Liu]

On 06/17/2014 23:50 PM, Greg KH wrote:
> On Tue, Jun 17, 2014 at 10:56:04PM +0800, Jeff Liu wrote:
>>
>> On 06/17/2014 22:42 PM, James Bottomley wrote:
>>> On Tue, 2014-06-17 at 22:25 +0800, Jeff Liu wrote:
 From: Jie Liu 

 It's better to return the actual error rather than NULL because
 kset_register() can failed due to other reasons.




 
>>>
>>> This patch series isn't bisectable.  When changing an error signal from
>>> NULL to non-NULL, you have to do it as one patch, otherwise if a
>>> bisection lands in here we'll get error returns from all our kobject
>>> kset code and the kernel won't boot.
>>
>> Thanks for pointing this out.
>>
>>> It's fine if you're sending it out as 24 patches for review, but it has
>>> to be applied as a single one.
>>
>> Ok, I'll post the v2 patch as a single one once this series has been 
>> reviewed.
> 
> Also, now that you sent a bunch of different patches out, some
> maintainers will not realize that this first one has to be applied (i.e.
> you gave them no sense that there was a dependancy.)
> 
> You will have to watch very carefully to ensure that those patches do
> not now get accepted, as they will break the existing code.

Ok, and I'll inform every other maintainers do not apply their patch 
individually.


Cheers,
-Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ns: introduce getnspid syscall

[Eric W. Biederman]

Chen Hanxiao  writes:

> We need a direct method of getting the pid inside containers.
> If some issues occurred inside container guest, host user
> could not know which process is in trouble just by guest pid:
> the users of container guest only knew the pid inside containers.
> This will bring obstacle for trouble shooting.

There is also some ongoing work to export this information via a proc
file which seems more appropriate for solving your problem.  Certainly
for debugging something easily human discoverable is needed.

> int getnspid(pid_t pid, int fd1, int fd2, int pidtype);

The pidtype is nonsense.  The translation of a pid does not depend upon
type.  Using that kind of nonsense will lead you and others into confusion.

> pid: the pid number need to be translated.
>
> fd: a file descriptor referring to one of
> the namespace entries in a /proc/[pid]/ns/pid.
> fd1 for destination ns(ns1), where the pid came from.
> fd2 for reference ns(ns2), while fd2 = -2 means for current ns.
>
> pidtype: 0 PIDTYPE_PID; 1 PIDTYPE_PGID; 2 PIDTYPE_SID.
>
> return value:
> >0: translated pid in ns1(fd1) seen from ns2(fd2).
> <0: on failure.

Elsewhere we use 0 on pid translation failure.  Why be different here?

Eric


> Signed-off-by: Chen Hanxiao 
> ---
>  arch/x86/syscalls/syscall_32.tbl |  1 +
>  arch/x86/syscalls/syscall_64.tbl |  1 +
>  include/linux/syscalls.h |  1 +
>  kernel/nsproxy.c | 60 
> 
>  4 files changed, 63 insertions(+)
>
> diff --git a/arch/x86/syscalls/syscall_32.tbl 
> b/arch/x86/syscalls/syscall_32.tbl
> index d6b8679..9de0b32 100644
> --- a/arch/x86/syscalls/syscall_32.tbl
> +++ b/arch/x86/syscalls/syscall_32.tbl
> @@ -360,3 +360,4 @@
>  351  i386sched_setattr   sys_sched_setattr
>  352  i386sched_getattr   sys_sched_getattr
>  353  i386renameat2   sys_renameat2
> +354  i386getnspidsys_getnspid
> diff --git a/arch/x86/syscalls/syscall_64.tbl 
> b/arch/x86/syscalls/syscall_64.tbl
> index ec255a1..1630a8a 100644
> --- a/arch/x86/syscalls/syscall_64.tbl
> +++ b/arch/x86/syscalls/syscall_64.tbl
> @@ -323,6 +323,7 @@
>  314  common  sched_setattr   sys_sched_setattr
>  315  common  sched_getattr   sys_sched_getattr
>  316  common  renameat2   sys_renameat2
> +317  common  getnspidsys_getnspid
>  
>  #
>  # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index b0881a0..271c7b1 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -866,4 +866,5 @@ asmlinkage long sys_process_vm_writev(pid_t pid,
>  asmlinkage long sys_kcmp(pid_t pid1, pid_t pid2, int type,
>unsigned long idx1, unsigned long idx2);
>  asmlinkage long sys_finit_module(int fd, const char __user *uargs, int 
> flags);
> +asmlinkage long sys_getpidns(pid_t pid, int fd1, int fd2, int pidtype);
>  #endif
> diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
> index 8e78110..3eda90a 100644
> --- a/kernel/nsproxy.c
> +++ b/kernel/nsproxy.c
> @@ -261,6 +261,66 @@ out:
>   return err;
>  }
>  
> +SYSCALL_DEFINE4(getnspid, pid_t, pid, int, fd1, int, fd2, int, pidtype)
> +{
> + struct file *file1 = NULL, *file2 = NULL;
> + struct task_struct *task;
> + struct pid_namespace *ns1, *ns2;
> + struct proc_ns *ei;
> + int ret = -1;
> +
> + if (pidtype >= PIDTYPE_MAX)
> + return -EINVAL;
> +
> + file1 = proc_ns_fget(fd1);
> + if (IS_ERR(file1))
> + return PTR_ERR(file1);
> + ei = get_proc_ns(file_inode(file1));
> + ns1 = (struct pid_namespace *)ei->ns;
> +
> + /* fd == -2 for current pid ns */
> + if (fd2 == -2) {
> + ns2 = task_active_pid_ns(current);
> + } else {
> + file2 = proc_ns_fget(fd2);
> + if (IS_ERR(file2)) {
> + fput(file1);
> + return PTR_ERR(file2);
> + }
> + ei = get_proc_ns(file_inode(file2));
> + ns2 = (struct pid_namespace *)ei->ns;
> + }
> +
> + rcu_read_lock();
> + task = find_task_by_pid_ns(pid, ns1);

The functions you want to be using here are:
find_pid_ns and pid_nr_ns.

> + rcu_read_unlock();
> + if (!task) {
> + ret = -ESRCH;
> + goto out;
> + }
> +
> + switch (pidtype) {
> + case PIDTYPE_PID:
> + ret = task_pid_nr_ns(task, ns2);
> + break;
> + case PIDTYPE_PGID:
> + ret = task_pgrp_nr_ns(task, ns2);
> + break;
> + case PIDTYPE_SID:
> + ret = task_session_nr_ns(task, ns2);
> + break;
> + default:
> + ret = -EINVAL;
> + }
> + ret = (ret == 0) ? -ESRCH : ret;
> +
> +out:
> + fput(file1);
> + if (file2)
> + fput(file2);
> + return ret;
> +}
> 

Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

Hi,

On Mon, Jun 16, 2014 at 12:27:21AM -0700, Tony Lindgren wrote:
> * Felipe Balbi  [140613 09:33]:
> > On Fri, Jun 13, 2014 at 11:23:34AM -0500, Felipe Balbi wrote:
> > > On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
> > > > --- /dev/null
> > > > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > > > @@ -0,0 +1,539 @@
> > > > +/*
> > > > + * Copyright (C) 2014 Texas Instruments Incorporated - 
> > > > http://www.ti.com/
> > > > + *
> > > > + * 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.
> > > > + */
> > > > +
> > > > +/* AM437x SK EVM */
> > > > +
> > > > +/dts-v1/;
> > > > +
> > > > +#include "am4372.dtsi"
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +/ {
> > > > +   model = "TI AM437x SK EVM";
> > > > +   compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> > > > +
> > > > +   aliases {
> > > > +   display0 = 
> > > > +   };
> > > > +
> > > > +   vmmcsd_fixed: fixedregulator-sd {
> > > > +   compatible = "regulator-fixed";
> > > > +   regulator-name = "vmmcsd_fixed";
> > > > +   regulator-min-microvolt = <330>;
> > > > +   regulator-max-microvolt = <330>;
> > > > +   enable-active-high;
> > > > +   };
> > > > +
> > > > +   v33_fixed: fixedregulator-v33 {
> > > > +   compatible = "regulator-fixed";
> > > > +   regulator-name = "v33_fixed";
> > > > +   regulator-min-microvolt = <330>;
> > > > +   regulator-max-microvolt = <330>;
> > > > +   enable-active-high;
> > > > +   };
> > > > +
> > > > +   v18_fixed: fixedregulator-v18 {
> > > > +   compatible = "regulator-fixed";
> > > > +   regulator-name = "v18_fixed";
> > > > +   regulator-min-microvolt = <180>;
> > > > +   regulator-max-microvolt = <180>;
> > > > +   enable-active-high;
> > > > +   };
> 
> Chances are these are not fixed regulators.. Typically the these
> come from external regulators controlled by GPIO pins. Sounds
> like you have the schematics so it would be best to verify it.
> If they come from something not yet supported, let's at least
> document it with comments.

sure, let me just make sure of it.

> Also looks like all the am43xx boards are using vmmcsd_fixed,
> might be worth checking those as well while at it.

I'll need help testing, but sure thing.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] [STABLE] audit: remove superfluous new- prefix in AUDIT_LOGIN messages

[Richard Guy Briggs]

The new- prefix on ses and auid are un-necessary and break ausearch.

Upstream-commit: aa589a1
Cc: sta...@vger.kernel.org # v3.14-rc1 to v3.14
Reported-by: Steve Grubb 
Signed-off-by: Richard Guy Briggs 
---
 kernel/auditsc.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 37e6216..619b58d 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -1991,7 +1991,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid, 
kuid_t kloginuid,
if (!ab)
return;
audit_log_format(ab, "pid=%d uid=%u"
-" old-auid=%u new-auid=%u old-ses=%u new-ses=%u"
+" old-auid=%u auid=%u old-ses=%u ses=%u"
 " res=%d",
 current->pid, uid,
 oldloginuid, loginuid, oldsessionid, sessionid,
-- 
1.7.1

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

Re: 3.16-rc1 problems vdso_addr , _mb_cache_entry_ , rtl8723au

[David Rientjes]

On Tue, 17 Jun 2014, David Rientjes wrote:

>  - I can't reproduce your align_vdso_addr() problem, please send your 
>.config
> 

Werner sent me his .config privately and, although it is 32-bit as 
expected, I cannot reproduce his align_vdso_addr() build issue with either 
Linus's tree nor linux-next-20140617.  I see no reason to think that it is 
a gcc versioning issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] mmc: rtsx: add support for async request

[micky]

On 06/17/2014 03:45 PM, Ulf Hansson wrote:

On 17 June 2014 03:04, micky  wrote:

On 06/16/2014 08:40 PM, Ulf Hansson wrote:

On 16 June 2014 11:09, micky  wrote:

On 06/16/2014 04:42 PM, Ulf Hansson wrote:

@@ -36,7 +37,10 @@ struct realtek_pci_sdmmc {

  struct rtsx_pcr *pcr;
  struct mmc_host *mmc;
  struct mmc_request  *mrq;
+   struct workqueue_struct *workq;
+#define SDMMC_WORKQ_NAME   "rtsx_pci_sdmmc_workq"

+   struct work_struct  work;

I am trying to understand why you need a work/workqueue to implement
this feature. Is that really the case?

Could you elaborate on the reasons?

Hi Uffe,

we need return as fast as possible in mmc_host_ops request(ops->request)
callback,
so the mmc core can continue handle next request.
when next request everything is ready, it will wait previous done(if not
done),
then call ops->request().

we can't use atomic context, because we use mutex_lock() to protect

ops->request should never executed in atomic context. Is that your
concern?

Yes.

Okay. Unless I missed your point, I don't think you need the work/workqueue.

any other method?


Because, ops->request isn't ever executed in atomic context. That's
due to the mmc core, which handles the async mechanism, are waiting
for a completion variable in process context, before it invokes the
ops->request() callback.

That completion variable will be kicked, from your host driver, when
you invoke mmc_request_done(), .

Sorry, I don't understand here, how kicked?

I think the flow is:
- not wait for first req
- init mrq->done
- ops->request() --- A.rtsx: start queue 
work.

- continue fetch next req
- prepare next req ok,
- wait previous done.--- B.(mmc_request_done() may be 
called at any time from A to B)

- init mrq->done
- ops->request() --- C.rtsx: start queue 
next work.

...
and seems no problem.

Best Regards.
micky.

Kind regards
Uffe




resource, and we have to hold the lock during handle request.
So I use workq, we just queue a work and return in ops->request(),
The mmc core can continue without blocking at ops->request().

Best Regards.
micky.

Kind regards
Uffe
.


.



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

Re: [PATCH] USB:gadget: Fix a warning while loading g_mass_storage

[Yang,Wei]

On 06/17/2014 10:18 PM, Alan Stern wrote:

That is a strange question to ask.  If you did not know that I approved
the patch, why did you insert my Acked-By:?


I added your Acked-By, as when you reviewed V3, you mentioned that I 
*may* add your Acked-by in this patch. If I misunderstood your point, I 
am so sorry for that.


Best Regards
Wei


With that change, you may add

Acked-by: Alan Stern

Alan Stern


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

[PATCH 1/6] percpu-refcount, aio: use percpu_ref_cancel_init() in ioctx_alloc()

[Tejun Heo]

ioctx_alloc() reaches inside percpu_ref and directly frees
->pcpu_count in its failure path, which is quite gross.  percpu_ref
has been providing a proper interface to do this,
percpu_ref_cancel_init(), for quite some time now.  Let's use that
instead.

This patch doesn't introduce any behavior changes.

Signed-off-by: Tejun Heo 
Cc: Benjamin LaHaise 
Cc: Kent Overstreet 
---
 fs/aio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 4f078c0..5e0d7f9 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -715,8 +715,8 @@ err_ctx:
 err:
mutex_unlock(>ring_lock);
free_percpu(ctx->cpu);
-   free_percpu(ctx->reqs.pcpu_count);
-   free_percpu(ctx->users.pcpu_count);
+   percpu_ref_cancel_init(>reqs);
+   percpu_ref_cancel_init(>users);
kmem_cache_free(kioctx_cachep, ctx);
pr_debug("error allocating ioctx %d\n", err);
return ERR_PTR(err);
-- 
1.9.3

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

[PATCHSET percpu/for-3.17] percpu: implement percpu_ref_reinit()

[Tejun Heo]

Hello,

Currently, percpu_ref destruction - freeing the percpu counter -
happens when the percpu_ref is released.  This while a bit more
convenient restricts how percpu_ref can be used.  It can't be
initialized with static percpu area and it can't be reinitialized
without going through percpu allocation.

There are use cases which can take advantage of cycling percpu_ref
through init/release multiple times.  This patchset separates out
percpu_ref destruction into percpu_exit() which should be invoked
explicitly and introduces percpu_ref_reinit() which can be used to
recycle a released percpu_ref.

This patchset doesn't add any users.  Patchset to use this will soon
be posted.

This patchset contains the following six patches.

 0001-percpu-refcount-aio-use-percpu_ref_cancel_init-in-io.patch
 0002-percpu-refcount-one-bit-is-enough-for-REF_STATUS.patch
 0003-percpu-refcount-add-helpers-for-percpu_count-accesse.patch
 0004-percpu-refcount-use-unsigned-long-for-pcpu_count-poi.patch
 0005-percpu-refcount-require-percpu_ref-to-be-exited-expl.patch
 0006-percpu-refcount-implement-percpu_ref_reinit-and-perc.patch

0001-0004 are prep/cleanups.

0005 separates out percpu destruction into percpu_ref_exit() and 0006
implements percpu_ref_reinit().

This patchset is on top of percpu/for-3.17 6fbc07bbe2b5 ("percpu:
invoke __verify_pcpu_ptr() from the generic part of accessors and
operations").

diffstat follows.

 drivers/target/target_core_tpg.c |4 +
 fs/aio.c |6 +-
 include/linux/percpu-refcount.h  |   64 +++--
 kernel/cgroup.c  |8 ++-
 lib/percpu-refcount.c|   86 ---
 5 files changed, 109 insertions(+), 59 deletions(-)

Thanks.

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

[PATCH 3/6] percpu-refcount: add helpers for ->percpu_count accesses

[Tejun Heo]

* All four percpu_ref_*() operations implemented in the header file
  perform the same operation to determine whether the percpu_ref is
  alive and extract the percpu pointer.  Factor out the common logic
  into __pcpu_ref_alive().  This doesn't change the generated code.

* There are a couple places in percpu-refcount.c which masks out
  PCPU_REF_DEAD to obtain the percpu pointer.  Factor it out into
  pcpu_count_ptr().

* The above changes make the WARN_ON_ONCE() conditional at the top of
  percpu_ref_kill_and_confirm() the only user of REF_STATUS().  Test
  PCPU_REF_DEAD directly and remove REF_STATUS().

This patch doesn't introduce any functional change.

Signed-off-by: Tejun Heo 
Cc: Kent Overstreet 
Cc: Christoph Lameter 
---
 include/linux/percpu-refcount.h | 35 +--
 lib/percpu-refcount.c   | 17 +
 2 files changed, 30 insertions(+), 22 deletions(-)

diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index bfdeb0d4..b62a4ee 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -88,10 +88,25 @@ static inline void percpu_ref_kill(struct percpu_ref *ref)
return percpu_ref_kill_and_confirm(ref, NULL);
 }
 
-#define PCPU_REF_PTR   0
 #define PCPU_REF_DEAD  1
 
-#define REF_STATUS(count)  (((unsigned long) count) & PCPU_REF_DEAD)
+/*
+ * Internal helper.  Don't use outside percpu-refcount proper.  The
+ * function doesn't return the pointer and let the caller test it for NULL
+ * because doing so forces the compiler to generate two conditional
+ * branches as it can't assume that @ref->pcpu_count is not NULL.
+ */
+static inline bool __pcpu_ref_alive(struct percpu_ref *ref,
+   unsigned __percpu **pcpu_countp)
+{
+   unsigned long pcpu_ptr = (unsigned long)ACCESS_ONCE(ref->pcpu_count);
+
+   if (unlikely(pcpu_ptr & PCPU_REF_DEAD))
+   return false;
+
+   *pcpu_countp = (unsigned __percpu *)pcpu_ptr;
+   return true;
+}
 
 /**
  * percpu_ref_get - increment a percpu refcount
@@ -105,9 +120,7 @@ static inline void percpu_ref_get(struct percpu_ref *ref)
 
rcu_read_lock_sched();
 
-   pcpu_count = ACCESS_ONCE(ref->pcpu_count);
-
-   if (likely(REF_STATUS(pcpu_count) == PCPU_REF_PTR))
+   if (__pcpu_ref_alive(ref, _count))
this_cpu_inc(*pcpu_count);
else
atomic_inc(>count);
@@ -131,9 +144,7 @@ static inline bool percpu_ref_tryget(struct percpu_ref *ref)
 
rcu_read_lock_sched();
 
-   pcpu_count = ACCESS_ONCE(ref->pcpu_count);
-
-   if (likely(REF_STATUS(pcpu_count) == PCPU_REF_PTR)) {
+   if (__pcpu_ref_alive(ref, _count)) {
this_cpu_inc(*pcpu_count);
ret = true;
} else {
@@ -166,9 +177,7 @@ static inline bool percpu_ref_tryget_live(struct percpu_ref 
*ref)
 
rcu_read_lock_sched();
 
-   pcpu_count = ACCESS_ONCE(ref->pcpu_count);
-
-   if (likely(REF_STATUS(pcpu_count) == PCPU_REF_PTR)) {
+   if (__pcpu_ref_alive(ref, _count)) {
this_cpu_inc(*pcpu_count);
ret = true;
}
@@ -191,9 +200,7 @@ static inline void percpu_ref_put(struct percpu_ref *ref)
 
rcu_read_lock_sched();
 
-   pcpu_count = ACCESS_ONCE(ref->pcpu_count);
-
-   if (likely(REF_STATUS(pcpu_count) == PCPU_REF_PTR))
+   if (__pcpu_ref_alive(ref, _count))
this_cpu_dec(*pcpu_count);
else if (unlikely(atomic_dec_and_test(>count)))
ref->release(ref);
diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
index 17bce2b..087f1a0 100644
--- a/lib/percpu-refcount.c
+++ b/lib/percpu-refcount.c
@@ -31,6 +31,11 @@
 
 #define PCPU_COUNT_BIAS(1U << 31)
 
+static unsigned __percpu *pcpu_count_ptr(struct percpu_ref *ref)
+{
+   return (unsigned __percpu *)((unsigned long)ref->pcpu_count & 
~PCPU_REF_DEAD);
+}
+
 /**
  * percpu_ref_init - initialize a percpu refcount
  * @ref: percpu_ref to initialize
@@ -74,7 +79,7 @@ EXPORT_SYMBOL_GPL(percpu_ref_init);
  */
 void percpu_ref_cancel_init(struct percpu_ref *ref)
 {
-   unsigned __percpu *pcpu_count = ref->pcpu_count;
+   unsigned __percpu *pcpu_count = pcpu_count_ptr(ref);
int cpu;
 
WARN_ON_ONCE(atomic_read(>count) != 1 + PCPU_COUNT_BIAS);
@@ -82,7 +87,7 @@ void percpu_ref_cancel_init(struct percpu_ref *ref)
if (pcpu_count) {
for_each_possible_cpu(cpu)
WARN_ON_ONCE(*per_cpu_ptr(pcpu_count, cpu));
-   free_percpu(ref->pcpu_count);
+   free_percpu(pcpu_count);
}
 }
 EXPORT_SYMBOL_GPL(percpu_ref_cancel_init);
@@ -90,14 +95,10 @@ EXPORT_SYMBOL_GPL(percpu_ref_cancel_init);
 static void percpu_ref_kill_rcu(struct rcu_head *rcu)
 {
struct percpu_ref *ref = container_of(rcu, struct percpu_ref, rcu);
-   unsigned __percpu *pcpu_count = ref->pcpu_count;

[PATCH 2/6] percpu-refcount: one bit is enough for REF_STATUS

[Tejun Heo]

percpu-refcount currently reserves two lowest bits of its percpu
pointer to indicate its state; however, only one bit is used for
PCPU_REF_DEAD.

Simplify it by removing PCPU_STATUS_BITS/MASK and testing
PCPU_REF_DEAD directly.  This also allows the compiler to choose a
more efficient instruction depending on the architecture.

Signed-off-by: Tejun Heo 
Cc: Kent Overstreet 
Cc: Christoph Lameter 
---
 include/linux/percpu-refcount.h | 4 +---
 lib/percpu-refcount.c   | 2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index 5d8920e..bfdeb0d4 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -88,12 +88,10 @@ static inline void percpu_ref_kill(struct percpu_ref *ref)
return percpu_ref_kill_and_confirm(ref, NULL);
 }
 
-#define PCPU_STATUS_BITS   2
-#define PCPU_STATUS_MASK   ((1 << PCPU_STATUS_BITS) - 1)
 #define PCPU_REF_PTR   0
 #define PCPU_REF_DEAD  1
 
-#define REF_STATUS(count)  (((unsigned long) count) & PCPU_STATUS_MASK)
+#define REF_STATUS(count)  (((unsigned long) count) & PCPU_REF_DEAD)
 
 /**
  * percpu_ref_get - increment a percpu refcount
diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
index 963b703..17bce2b 100644
--- a/lib/percpu-refcount.c
+++ b/lib/percpu-refcount.c
@@ -96,7 +96,7 @@ static void percpu_ref_kill_rcu(struct rcu_head *rcu)
 
/* Mask out PCPU_REF_DEAD */
pcpu_count = (unsigned __percpu *)
-   (((unsigned long) pcpu_count) & ~PCPU_STATUS_MASK);
+   (((unsigned long) pcpu_count) & ~PCPU_REF_DEAD);
 
for_each_possible_cpu(cpu)
count += *per_cpu_ptr(pcpu_count, cpu);
-- 
1.9.3

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

[PATCH 5/6] percpu-refcount: require percpu_ref to be exited explicitly

[Tejun Heo]

Currently, a percpu_ref undoes percpu_ref_init() automatically by
freeing the allocated percpu area when the percpu_ref is killed.
While seemingly convenient, this has the following niggles.

* It's impossible to re-init a released reference counter without
  going through re-allocation.

* In the similar vein, it's impossible to initialize a percpu_ref
  count with static percpu variables.

* We need and have an explicit destructor anyway for failure paths -
  percpu_ref_cancel_init().

This patch removes the automatic percpu counter freeing in
percpu_ref_kill_rcu() and repurposes percpu_ref_cancel_init() into a
generic destructor now named percpu_ref_exit().  percpu_ref_destroy()
is considered but it gets confusing with percpu_ref_kill() while
"exit" clearly indicates that it's the counterpart of
percpu_ref_init().

All percpu_ref_cancel_init() users are updated to invoke
percpu_ref_exit() instead and explicit percpu_ref_exit() calls are
added to the destruction path of all percpu_ref users.

Signed-off-by: Tejun Heo 
Cc: Kent Overstreet 
Cc: Christoph Lameter 
Cc: Benjamin LaHaise 
Cc: Nicholas A. Bellinger 
Cc: Li Zefan 
---
 drivers/target/target_core_tpg.c |  4 +++-
 fs/aio.c |  6 --
 include/linux/percpu-refcount.h  |  6 ++
 kernel/cgroup.c  |  8 +---
 lib/percpu-refcount.c| 33 ++---
 5 files changed, 24 insertions(+), 33 deletions(-)

diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c
index c036595..fddfae6 100644
--- a/drivers/target/target_core_tpg.c
+++ b/drivers/target/target_core_tpg.c
@@ -825,7 +825,7 @@ int core_tpg_add_lun(
 
ret = core_dev_export(dev, tpg, lun);
if (ret < 0) {
-   percpu_ref_cancel_init(>lun_ref);
+   percpu_ref_exit(>lun_ref);
return ret;
}
 
@@ -880,5 +880,7 @@ int core_tpg_post_dellun(
lun->lun_status = TRANSPORT_LUN_STATUS_FREE;
spin_unlock(>tpg_lun_lock);
 
+   percpu_ref_exit(>lun_ref);
+
return 0;
 }
diff --git a/fs/aio.c b/fs/aio.c
index 5e0d7f9..ea1bc2e 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -506,6 +506,8 @@ static void free_ioctx(struct work_struct *work)
 
aio_free_ring(ctx);
free_percpu(ctx->cpu);
+   percpu_ref_exit(>reqs);
+   percpu_ref_exit(>users);
kmem_cache_free(kioctx_cachep, ctx);
 }
 
@@ -715,8 +717,8 @@ err_ctx:
 err:
mutex_unlock(>ring_lock);
free_percpu(ctx->cpu);
-   percpu_ref_cancel_init(>reqs);
-   percpu_ref_cancel_init(>users);
+   percpu_ref_exit(>reqs);
+   percpu_ref_exit(>users);
kmem_cache_free(kioctx_cachep, ctx);
pr_debug("error allocating ioctx %d\n", err);
return ERR_PTR(err);
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index 6f8cd4c..0ddd283 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -57,9 +57,7 @@ struct percpu_ref {
atomic_tcount;
/*
 * The low bit of the pointer indicates whether the ref is in percpu
-* mode; if set, then get/put will manipulate the atomic_t (this is a
-* hack because we need to keep the pointer around for
-* percpu_ref_kill_rcu())
+* mode; if set, then get/put will manipulate the atomic_t.
 */
unsigned long   pcpu_count_ptr;
percpu_ref_func_t   *release;
@@ -69,7 +67,7 @@ struct percpu_ref {
 
 int __must_check percpu_ref_init(struct percpu_ref *ref,
 percpu_ref_func_t *release);
-void percpu_ref_cancel_init(struct percpu_ref *ref);
+void percpu_ref_exit(struct percpu_ref *ref);
 void percpu_ref_kill_and_confirm(struct percpu_ref *ref,
 percpu_ref_func_t *confirm_kill);
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 7868fc3..c06aa5e 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1638,7 +1638,7 @@ destroy_root:
 exit_root_id:
cgroup_exit_root_id(root);
 cancel_ref:
-   percpu_ref_cancel_init(_cgrp->self.refcnt);
+   percpu_ref_exit(_cgrp->self.refcnt);
 out:
free_cgrp_cset_links(_links);
return ret;
@@ -4133,6 +4133,8 @@ static void css_free_work_fn(struct work_struct *work)
container_of(work, struct cgroup_subsys_state, destroy_work);
struct cgroup *cgrp = css->cgroup;
 
+   percpu_ref_exit(>refcnt);
+
if (css->ss) {
/* css free path */
if (css->parent)
@@ -4330,7 +4332,7 @@ err_list_del:
 err_free_id:
cgroup_idr_remove(>css_idr, css->id);
 err_free_percpu_ref:
-   percpu_ref_cancel_init(>refcnt);
+   percpu_ref_exit(>refcnt);
 err_free_css:
call_rcu(>rcu_head, css_free_rcu_fn);
return err;
@@ -4441,7 +4443,7 @@ static int cgroup_mkdir(struct kernfs_node *parent_kn, 
const char *name,
 out_free_id: