date:20120913

On Thu, Sep 13, 2012 at 11:02:14AM -0700, Randy Dunlap wrote:
> On 09/11/2012 01:28 PM, Aristeu Rozanski wrote:
> 
> 
> +/**
> + * simple_xattr_set: xattr SET operation for in-memory/pseudo filesystems
> 
> The format for the function name/description uses '-', not ':', as:
> 
>  * simple_xattr_set - xattr SET operation for in-memory/pseudo filesystems
> 
> + * @xattrs: simple_xattr list
> + * @name: name of the new extended attribute
> + * @value: value of the new extended attribute. If NULL, will remove the
> + *  attribute
> 
> Missing @size parameter description.

Updated the patch in place accordingly.  Thanks.

>From 4895768b6aab55bbdbebcf2da090cb1a5ccf5463 Mon Sep 17 00:00:00 2001
From: Aristeu Rozanski 
Date: Tue, 11 Sep 2012 16:28:11 -0400
Subject: [PATCH] fs: add missing documentation to simple_xattr functions

v2: add function documentation instead of adding a separate file under
Documentation/

tj: Updated comment a bit and rolled in Randy's suggestions.

Cc: Li Zefan 
Cc: Tejun Heo 
Cc: Hugh Dickins 
Cc: Hillf Danton 
Cc: Lennart Poettering 
Cc: Randy Dunlap 
Signed-off-by: Aristeu Rozanski 
Signed-off-by: Tejun Heo 
---
 fs/xattr.c |   18 --
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index e17e773..f053c11 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -892,8 +892,19 @@ out:
 
 }
 
-/*
- * xattr SET operation for in-memory/pseudo filesystems
+/**
+ * simple_xattr_set - xattr SET operation for in-memory/pseudo filesystems
+ * @xattrs: target simple_xattr list
+ * @name: name of the new extended attribute
+ * @value: value of the new xattr. If %NULL, will remove the attribute
+ * @size: size of the new xattr
+ * @flags: %XATTR_{CREATE|REPLACE}
+ *
+ * %XATTR_CREATE is set, the xattr shouldn't exist already; otherwise fails
+ * with -EEXIST.  If %XATTR_REPLACE is set, the xattr should exist;
+ * otherwise, fails with -ENODATA.
+ *
+ * Returns 0 on success, -errno on failure.
  */
 int simple_xattr_set(struct simple_xattrs *xattrs, const char *name,
 const void *value, size_t size, int flags)
@@ -950,6 +961,9 @@ ssize_t simple_xattr_list(struct simple_xattrs *xattrs, 
char *buffer,
return used;
 }
 
+/*
+ * Adds an extended attribute to the list
+ */
 void simple_xattr_list_add(struct simple_xattrs *xattrs,
   struct simple_xattr *new_xattr)
 {
-- 
1.7.7.3

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

Re: [PATCH] Xen backend support for paged out grant targets.

2012-09-13 Thread Ian Campbell

On Thu, 2012-09-13 at 18:28 +0100, Andres Lagar-Cavilla wrote:
> 
> * Add placeholder in array of grant table error descriptions for
> unrelated error code we jump over. 

Why not just define it, it's listed here:
http://xenbits.xen.org/docs/unstable/hypercall/include,public,grant_table.h.html#Enum_grant_status

I notice the specific wording of the error msg is different here too.
It'd probably be best to use the same wording as the Xen definition, so
all OSes end up with the same name for the same condition (else bug
reports will be confusing).

Ian.

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

Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator

2012-09-13 Thread Federico Vaga

> Well, there is some documentation here:
> 
>   https://lwn.net/Articles/447435/

I know this, I learned from this page :)

What I'm saying is that I don't know what to write inside the code to 
make it clearer than now. I think is clear, because if you know the 
videobuf2, you know what I'm doing in each vb2_mem_ops. I suppose that 
this is the reason why there are no comments inside the other memory 
allocator. Maybe I am wrong.

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

BUG at mm/huge_memory.c:1428!

2012-09-13 Thread Jiri Slaby

Hi,

I've just get the following BUG with today's -next. It happens every
time I try to update packages.

kernel BUG at mm/huge_memory.c:1428!
invalid opcode:  [#1] SMP
Modules linked in:
CPU 1
Pid: 3087, comm: zypper Tainted: GW
3.6.0-rc5-next-20120913_64+ #45 Bochs Bochs
RIP: 0010:[]  []
split_huge_page+0x6d4/0x830
RSP: 0018:880046223ce8  EFLAGS: 00010296
RAX: 002f RBX: 880043e9d170 RCX: 00dc
RDX: 004c RSI: 0046 RDI: 81b3c05c
RBP: 880046223d58 R08: 000a R09: 01b0
R10:  R11: 01af R12: 
R13: eae6 R14: 7f7ff561a000 R15: 8800453aa880
FS:  7f869800() GS:88004970() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 03611000 CR3: 4506e000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process zypper (pid: 3087, threadinfo 880046222000, task
880043cf5330)
Stack:
 880047810480 880043ee1980 880047808c40 880043ee19b0
 880046223dc8 0296 7f7ff581a000 0007f7ff561a
 8110e8c1 eae6 8800453aa880 88004635abd0
Call Trace:
 [] ? anon_vma_clone+0x41/0x140
 [] __split_huge_page_pmd+0x5f/0xb0
 [] split_huge_page_address+0x75/0x80
 [] __vma_adjust_trans_huge+0x9b/0xf0
 [] vma_adjust+0x564/0x5d0
 [] __split_vma.isra.34+0x1cb/0x1e0
 [] do_munmap+0xf5/0x400
 [] sys_mremap+0x2fb/0x520
 [] ? do_page_fault+0x9/0x10
 [] system_call_fastpath+0x16/0x1b
Code: 4e 00 0f 0b f3 90 49 8b 45 00 a9 00 00 80 00 75 f3 e9 de fa ff ff
48 c7 c6 18 58 94 81 48 c7 c7 49 ba 92 81 31 c0 e8 b6 07 4e 00 <0f> 0b
41 8b 55 18 48 c7 c7 f8 57 94 81 31 c0 8b 75 bc 83 c2 01

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

Re: [PATCH] block: Document lack of ordering of submit_bio/generic_make_request

On Thu, Sep 13, 2012 at 01:40:30PM +1000, joseph.glanvi...@orionvm.com.au wrote:
> From: Joseph Glanville 
> 
> It is worth noting here that the block layer makes no attempt
> to preserve the order of requests and that upper layers like
> journaling filesystems that require such ordering need to do so
> explicity.
> 
> Signed-off-by: Joseph Glanville 

Acked-by: Tejun Heo 

Thank you.

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

Re: [PATCH] powerpc/smp: Do not disable IPI interrupts during suspend

2012-09-13 Thread Kumar Gala


On Aug 10, 2012, at 7:40 AM, Kumar Gala wrote:

> 
> On Aug 2, 2012, at 5:04 AM, Zhao Chenhui wrote:
> 
>> On Sat, Jul 28, 2012 at 08:20:31AM +1000, Benjamin Herrenschmidt wrote:
>>> On Fri, 2012-07-27 at 16:58 -0500, Kumar Gala wrote:
 On Jul 20, 2012, at 7:47 AM, Zhao Chenhui wrote:
 
> During suspend, all interrupts including IPI will be disabled. In this 
> case,
> the suspend process will hang in SMP. To prevent this, pass the flag
> IRQF_NO_SUSPEND when requesting IPI irq.
> 
> Signed-off-by: Zhao Chenhui 
> Signed-off-by: Li Yang 
> ---
> arch/powerpc/kernel/smp.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
 
 BenH,
 
 Can you ack?
>>> 
>>> No I'll merge it but not until it's been in next for a bit unless you
>>> have some strong emergency there, it's on my mental list of things to
>>> shovel into next after rc1.
>>> 
>>> Curiosity: didn't we use to disable all non-boot CPUs on suspend ?
>>> 
>>> Cheers,
>>> Ben.
>> 
>> Yes, we disabled all non-boot CPUs on suspend by calling 
>> disable_nonboot_cpus().
>> The disable_nonboot_cpus() needs IPIs to work. But prior to
>> calling disable_nonboot_cpus(), the IPIs are disabled in dpm_suspend_noirq().
>> 
>> -Chenhui
> 
> Benh, Ack?

Ben?

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

Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.

2012-09-13 Thread Jerome Glisse

On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
 wrote:
> PDE/PTE update code uses CP ring for memory writes.
> All page table entries are preallocated for now in alloc_pt().
>
> It is made as whole because it's hard to divide it to several patches
> that compile and doesn't break anything being applied separately.
>
> Tested on cayman card.
>
> Signed-off-by: Dmitry Cherkasov 
> ---
> I couldn't test in on SI card, so would be happy if someone could check it 
> there.

I wonder how this could have work as you don't set
PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1
page.

Cheers,
Jerome

>
>  drivers/gpu/drm/radeon/ni.c  |   64 ++---
>  drivers/gpu/drm/radeon/radeon.h  |   79 +++---
>  drivers/gpu/drm/radeon/radeon_asic.c |1 +
>  drivers/gpu/drm/radeon/radeon_asic.h |   13 +++--
>  drivers/gpu/drm/radeon/radeon_gart.c |   88 
> ++
>  drivers/gpu/drm/radeon/si.c  |4 +-
>  6 files changed, 210 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index b238216..31d9027 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -782,7 +782,7 @@ static int cayman_pcie_gart_enable(struct radeon_device 
> *rdev)
>(u32)(rdev->dummy_page.addr >> 12));
> WREG32(VM_CONTEXT1_CNTL2, 0);
> WREG32(VM_CONTEXT1_CNTL, 0);
> -   WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(0) |
> +   WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
> RANGE_PROTECTION_FAULT_ENABLE_DEFAULT);
>
> cayman_pcie_gart_tlb_flush(rdev);
> @@ -1517,37 +1517,65 @@ uint32_t cayman_vm_page_flags(struct radeon_device 
> *rdev, uint32_t flags)
> return r600_flags;
>  }
>
> -/**
> - * cayman_vm_set_page - update the page tables using the CP
> - *
> - * @rdev: radeon_device pointer
> - *
> - * Update the page tables using the CP (cayman-si).
> - */
> -void cayman_vm_set_page(struct radeon_device *rdev, struct radeon_vm *vm,
> -   unsigned pfn, struct ttm_mem_reg *mem,
> -   unsigned npages, uint32_t flags)
> +void cayman_vm_set_page(struct radeon_device *rdev,
> +   struct ttm_mem_reg *mem,
> +   uint64_t pte_gpu_addr,
> +   uint64_t mem_pfn_offset,
> +   unsigned count, uint32_t flags)
>  {
> struct radeon_ring *ring = >ring[rdev->asic->vm.pt_ring_index];
> -   uint64_t addr, pt = vm->pt_gpu_addr + pfn * 8;
> +   uint64_t addr;
> int i;
>
> addr = flags = cayman_vm_page_flags(rdev, flags);
>
> -   radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + npages * 2));
> -   radeon_ring_write(ring, pt & 0x);
> -   radeon_ring_write(ring, (pt >> 32) & 0xff);
> -   for (i = 0; i < npages; ++i) {
> +   radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + count * 2));
> +   radeon_ring_write(ring, pte_gpu_addr & 0x);
> +   radeon_ring_write(ring, (pte_gpu_addr >> 32) & 0xff);
> +   for (i = 0; i < count; ++i) {
> if (mem) {
> -   addr = radeon_vm_get_addr(rdev, mem, i);
> +   addr = radeon_vm_get_addr(rdev, mem,
> + i + mem_pfn_offset);
> addr = addr & 0xF000ULL;
> addr |= flags;
> }
> +
> +   radeon_ring_write(ring, addr & 0x);
> +   radeon_ring_write(ring, (addr >> 32) & 0x);
> +   }
> +}
> +
> +void cayman_vm_set_pdes(struct radeon_device *rdev,
> +   struct ttm_mem_reg *mem,
> +   struct radeon_vm *vm,
> +   uint64_t pde_index,
> +   unsigned pde_count, uint32_t flags)
> +{
> +   struct radeon_ring *ring = >ring[rdev->asic->vm.pt_ring_index];
> +   uint64_t addr;
> +   int i;
> +   uint64_t pde_gpu_addr = RADEON_BASE_GPU_ADDR(vm) +
> +   PDE_OFFSET(rdev, pde_index);
> +
> +   addr = 0;
> +
> +   radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + pde_count * 2));
> +   radeon_ring_write(ring, pde_gpu_addr & 0x);
> +   radeon_ring_write(ring, (pde_gpu_addr >> 32) & 0xff);
> +
> +   for (i = 0; i < pde_count; ++i) {
> +   addr = RADEON_BASE_GPU_ADDR(vm) +
> +   PTE_OFFSET(rdev, i + pde_index, 0);
> +   addr = addr & 0xF000ULL;
> +   addr |= flags;
> +
> radeon_ring_write(ring, addr & 0x);
> radeon_ring_write(ring, (addr >> 32) & 0x);
> }
>  }
>
> +
> +
>  /**
>   * cayman_vm_flush - vm flush using the CP
>   *
> @@ -1571,7 +1599,7 @@ void cayman_vm_flush(struct radeon_device

Re: [PATCH 07/24] Staging: ipack/devices/ipoctal: Store isr masks in ipoctal_channel

2012-09-13 Thread Joe Perches

On Thu, 2012-09-13 at 20:49 +0300, Dan Carpenter wrote:
> On Thu, Sep 13, 2012 at 08:43:12PM +0300, Dan Carpenter wrote:
> > On Wed, Sep 12, 2012 at 02:55:29PM +0200, Samuel Iglesias Gonsalvez wrote:
> > > From: Jens Taprogge 
> > > 
> > > This way interrupt handling becomes independent of the channel number.
> > > 
> > > Signed-off-by: Jens Taprogge 
> > > Signed-off-by: Samuel Iglesias Gonsalvez 
> > > ---
> > > @@ -213,7 +206,7 @@ static int ipoctal_irq_handler(void *arg)
> > >   }
> > >  
> > >   /* RX data */
> > > - if (isr_rx_rdy && (sr & SR_RX_READY)) {
> > > + if ((isr && channel->isr_rx_rdy_mask) && (sr & SR_RX_READY)) {
> >  ^^
> > Bitwise AND intended here I think.
> > 
> 
> Never mind.  It gets silently fixed in the next patch.

Nope, you were right the first time.

It shouldn't be silently fixed,

The best path is to rework the original patch
to fix the misuse or the worse path is that the
subsequent patch log should mention the fix.


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

Re: [PATCH 3/4] videobuf2-dma-streaming: new videobuf2 memory allocator

2012-09-13 Thread Federico Vaga

In data giovedì 13 settembre 2012 11:45:31, Jonathan Corbet ha scritto:
> On Thu, 13 Sep 2012 17:46:32 +0200
> 
> Federico Vaga  wrote:
> > > A few words explaining why this memory handling module is required
> > > or
> > > beneficial will definitely improve the commit :)
> > 
> > ok, I will write some lines
> 
> In general, all of these patches need *much* better changelogs (i.e.
> they need changelogs).  What are you doing, and *why* are you doing
> it?  The future will want to know.

I can improve the comment about the ADV7180: it is not clear why I'm 
removing that functions. (and the memory allocator commit is also in the 
todo list).

The STA2X11_VIP commit, I think is clear, I convert it to use videobu2 
and control framework. I can add some extra lines to explain why: 
because videobuf is obsolete

> I'm going to try to look at the actual code, but time isn't something
> I have a lot of, still...

The actual code is the same of the previous one with yours (plural) 
suggestions from the RFC submission (few week ago). I did not write 
anything else.

-- 
Federico Vaga
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/2] fs: add missing documentation to simple_xattr functions

2012-09-13 Thread Aristeu Rozanski

On Thu, Sep 13, 2012 at 11:11:24AM -0700, Tejun Heo wrote:
> Updated the patch in place accordingly.  Thanks.
> 
> From 4895768b6aab55bbdbebcf2da090cb1a5ccf5463 Mon Sep 17 00:00:00 2001
> From: Aristeu Rozanski 
> Date: Tue, 11 Sep 2012 16:28:11 -0400
> Subject: [PATCH] fs: add missing documentation to simple_xattr functions
> 
> v2: add function documentation instead of adding a separate file under
> Documentation/
> 
> tj: Updated comment a bit and rolled in Randy's suggestions.

Thanks Tejun, Randy

-- 
Aristeu

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

RE: [PATCH 1/2] HID: hid-sensor-hub: Clear HID_CLAIMED_INPUT bit earlier

2012-09-13 Thread Pandruvada, Srinivas

Hi Axel,

We don't need this anymore as when connect_mask is 0, the hid_connect will not 
be called.
So we don't need hdev->claimed = HID_CLAIMED_INPUT anymore.

Thanks for the review.

-Srinivas

-Original Message-
From: Axel Lin [mailto:axel@gmail.com] 
Sent: Thursday, September 13, 2012 6:25 AM
To: Jiri Kosina
Cc: Pandruvada, Srinivas; Jonathan Cameron; linux-in...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] HID: hid-sensor-hub: Clear HID_CLAIMED_INPUT bit 
earlier

2012/9/13 Axel Lin :
> Clear HID_CLAIMED_INPUT bit of hdev->claimed, this prevents calling
> hidinput_disconnect() in hid_disconnect(), which is called by hid_hw_stop().
>
> We need to clear HID_CLAIMED_INPUT bit earlier rather than in
> sensor_hub_remove() because we also call hid_hw_stop() in 
> sensor_hub_probe error handling.
>
> Also adds comments for why we set hdev->claimed = HID_CLAIMED_INPUT.
>
> Signed-off-by: Axel Lin 
> ---
> Hi srinivas,
> I don't have this hardware, I'd appreciate if you can test these patches.
> Axel
>
>  drivers/hid/hid-sensor-hub.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-sensor-hub.c 
> b/drivers/hid/hid-sensor-hub.c index 4ac759c..50bc8c7 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -539,8 +539,11 @@ static int sensor_hub_probe(struct hid_device *hdev,
> }
> INIT_LIST_HEAD(>inputs);
>
> +   /* We don't use hidinput but hid_hw_start() fails if nothing is
> +* claimed. So spoof claimed input. */
> hdev->claimed = HID_CLAIMED_INPUT;
> ret = hid_hw_start(hdev, 0);

I check the implementation of hid_hw_start again, it looks hid_hw_start allows 
connect_mask to be 0.
So we don't need setting  "hdev->claimed = HID_CLAIMED_INPUT;" here.
Comments?

Axel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] HID: hid-sensor-hub: Fix sensor_hub_probe error handling

2012-09-13 Thread Pandruvada, Srinivas

Agreed. It works.

Thanks,
Srinivas

-Original Message-
From: Axel Lin [mailto:axel@gmail.com] 
Sent: Wednesday, September 12, 2012 6:40 PM
To: Jiri Kosina
Cc: Pandruvada, Srinivas; Jonathan Cameron; linux-in...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] HID: hid-sensor-hub: Fix sensor_hub_probe error handling

Fix below issues in sensor_hub_probe error handling:
1. In the case of goto err_close, hid_hw_stop(hdev) is called twice. Fix it.
2. If fails to allocate MFD device name, we also need to free all
   successfully allocated names in previous iterations.

Signed-off-by: Axel Lin 
---
 drivers/hid/hid-sensor-hub.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c index 
50bc8c7..8bd7620 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -584,7 +584,7 @@ static int sensor_hub_probe(struct hid_device *hdev,
hid_err(hdev,
"Failed MFD device name\n");
ret = -ENOMEM;
-   goto err_free_cells;
+   goto err_free_names;
}
sd->hid_sensor_hub_client_devs[
sd->hid_sensor_client_cnt].name = name; @@ 
-608,10 +608,8 @@ static int sensor_hub_probe(struct hid_device *hdev,
 err_free_names:
for (i = 0; i < sd->hid_sensor_client_cnt ; ++i)
kfree(sd->hid_sensor_hub_client_devs[i].name);
-err_free_cells:
kfree(sd->hid_sensor_hub_client_devs);
 err_close:
-   hid_hw_stop(hdev);
hid_hw_close(hdev);
 err_stop_hw:
hid_hw_stop(hdev);
--
1.7.9.5

Re: qemu-kvm loops after kernel udpate

2012-09-13 Thread Jiri Slaby

On 09/13/2012 11:59 AM, Avi Kivity wrote:
> On 09/12/2012 09:11 PM, Jiri Slaby wrote:
>> On 09/12/2012 10:18 AM, Avi Kivity wrote:
>>> On 09/12/2012 11:13 AM, Jiri Slaby wrote:

>  Please provide the output of vmxcap
> (http://goo.gl/c5lUO),

   Unrestricted guest   no
>>>
>>> The big real mode fixes.
>>>
>>>

> and a snapshot of kvm_stat while the guest is hung.

 kvm statistics

  exits  6778198  615942
  host_state_reload 1988 187
  irq_exits 1523 138
  mmu_cache_miss   4   0
  fpu_reload   1   0
>>>
>>> Please run this as root so we get the tracepoint based output; and press
>>> 'x' when it's running so we get more detailed output.
>>
>> kvm statistics
>>
>>  kvm_exit  13798699  330708
>>  kvm_entry 13799110  330708
>>  kvm_page_fault13793650  330604
>>  kvm_exit(EXCEPTION_NMI)6188458  330604
>>  kvm_exit(EXTERNAL_INTERRUPT)  2169 105
>>  kvm_exit(TPR_BELOW_THRESHOLD)   82   0
>>  kvm_exit(IO_INSTRUCTION) 6   0
> 
> Strange, it's unable to fault in the very first page.
> 
> Please provide a trace as per http://www.linux-kvm.org/page/Tracing (but
> append -e kvmmmu to the command line).

Attached. Does it make sense? It wrote things like:
  failed to read event print fmt for kvm_mmu_unsync_page
to the stderr.

thanks,
-- 
js
suse labs
version = 6
CPU 0 is empty
cpus=2
qemu-kvm-6170  [001]   457.811896: kvm_mmu_get_page: [FAILED TO 
PARSE] gfn=0 role=122882 root_count=0 unsync=0 created=1
qemu-kvm-6170  [001]   457.811899: kvm_mmu_get_page: [FAILED TO 
PARSE] gfn=262144 role=122882 root_count=0 unsync=0 created=1
qemu-kvm-6170  [001]   457.811900: kvm_mmu_get_page: [FAILED TO 
PARSE] gfn=524288 role=122882 root_count=0 unsync=0 created=1
qemu-kvm-6170  [001]   457.811902: kvm_mmu_get_page: [FAILED TO 
PARSE] gfn=786432 role=122882 root_count=0 unsync=0 created=1
qemu-kvm-6171  [001]   462.416705: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=786432 role=122882 root_count=1 unsync=0
qemu-kvm-6171  [001]   462.416712: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=524288 role=122882 root_count=1 unsync=0
qemu-kvm-6171  [001]   462.416715: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=262144 role=122882 root_count=1 unsync=0
qemu-kvm-6171  [001]   462.416717: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=0 role=122882 root_count=1 unsync=0
qemu-kvm-6171  [001]   462.485197: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=0 role=253954 root_count=0 unsync=0
qemu-kvm-6171  [001]   462.485202: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=262144 role=253954 root_count=0 unsync=0
qemu-kvm-6171  [001]   462.485205: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=524288 role=253954 root_count=0 unsync=0
qemu-kvm-6171  [001]   462.485209: kvm_mmu_prepare_zap_page: [FAILED TO 
PARSE] gfn=786432 role=253954 root_count=0 unsync=0

Re: [PATCH v3 13/20] Input: bcm5974 - Drop pressure and width emulation

2012-09-13 Thread Henrik Rydberg

On Wed, Sep 12, 2012 at 11:57:24PM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 01, 2012 at 09:47:08PM +0200, Henrik Rydberg wrote:
> > The ABS_PRESSURE and ABS_WIDTH have special scales, and were initially
> > added solely for thumb and palm recognition in the synaptics driver.
> > This never really get used, however, and userspace quickly moved to
> > MT solutions instead. This patch drops the unused events.
> 
> How can you know that? There could still be people using ST emulation
> with this device. I think we should keep it.

Alright, maybe we need to carry this still. Probability = macbook *
old_userland * new_kernel * working_synaptics * tuned_palm_parameters,
must be a pretty large number. ;-)

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

Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.

2012-09-13 Thread Alex Deucher

On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse  wrote:
> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
>  wrote:
>> PDE/PTE update code uses CP ring for memory writes.
>> All page table entries are preallocated for now in alloc_pt().
>>
>> It is made as whole because it's hard to divide it to several patches
>> that compile and doesn't break anything being applied separately.
>>
>> Tested on cayman card.
>>
>> Signed-off-by: Dmitry Cherkasov 
>> ---
>> I couldn't test in on SI card, so would be happy if someone could check it 
>> there.
>
> I wonder how this could have work as you don't set
> PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1
> page.

I think PAGE_TABLE_BLOCK_SIZE refers number of 4k pages used for PTE
entries per PDE.  E.g., 1 4k page contains 512 64 bit PTEs. so if
BLOCK_SIZE is set to 1 page, each PDE points to 1 page (4k) or PTE
entries.  If BLOCK_SIZE is 2, each PDE points to 2 pages (8k) or PTEs,
etc.

Alex

>
> Cheers,
> Jerome
>
>>
>>  drivers/gpu/drm/radeon/ni.c  |   64 ++---
>>  drivers/gpu/drm/radeon/radeon.h  |   79 +++---
>>  drivers/gpu/drm/radeon/radeon_asic.c |1 +
>>  drivers/gpu/drm/radeon/radeon_asic.h |   13 +++--
>>  drivers/gpu/drm/radeon/radeon_gart.c |   88 
>> ++
>>  drivers/gpu/drm/radeon/si.c  |4 +-
>>  6 files changed, 210 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
>> index b238216..31d9027 100644
>> --- a/drivers/gpu/drm/radeon/ni.c
>> +++ b/drivers/gpu/drm/radeon/ni.c
>> @@ -782,7 +782,7 @@ static int cayman_pcie_gart_enable(struct radeon_device 
>> *rdev)
>>(u32)(rdev->dummy_page.addr >> 12));
>> WREG32(VM_CONTEXT1_CNTL2, 0);
>> WREG32(VM_CONTEXT1_CNTL, 0);
>> -   WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(0) |
>> +   WREG32(VM_CONTEXT1_CNTL, ENABLE_CONTEXT | PAGE_TABLE_DEPTH(1) |
>> RANGE_PROTECTION_FAULT_ENABLE_DEFAULT);
>>
>> cayman_pcie_gart_tlb_flush(rdev);
>> @@ -1517,37 +1517,65 @@ uint32_t cayman_vm_page_flags(struct radeon_device 
>> *rdev, uint32_t flags)
>> return r600_flags;
>>  }
>>
>> -/**
>> - * cayman_vm_set_page - update the page tables using the CP
>> - *
>> - * @rdev: radeon_device pointer
>> - *
>> - * Update the page tables using the CP (cayman-si).
>> - */
>> -void cayman_vm_set_page(struct radeon_device *rdev, struct radeon_vm *vm,
>> -   unsigned pfn, struct ttm_mem_reg *mem,
>> -   unsigned npages, uint32_t flags)
>> +void cayman_vm_set_page(struct radeon_device *rdev,
>> +   struct ttm_mem_reg *mem,
>> +   uint64_t pte_gpu_addr,
>> +   uint64_t mem_pfn_offset,
>> +   unsigned count, uint32_t flags)
>>  {
>> struct radeon_ring *ring = >ring[rdev->asic->vm.pt_ring_index];
>> -   uint64_t addr, pt = vm->pt_gpu_addr + pfn * 8;
>> +   uint64_t addr;
>> int i;
>>
>> addr = flags = cayman_vm_page_flags(rdev, flags);
>>
>> -   radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + npages * 2));
>> -   radeon_ring_write(ring, pt & 0x);
>> -   radeon_ring_write(ring, (pt >> 32) & 0xff);
>> -   for (i = 0; i < npages; ++i) {
>> +   radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + count * 2));
>> +   radeon_ring_write(ring, pte_gpu_addr & 0x);
>> +   radeon_ring_write(ring, (pte_gpu_addr >> 32) & 0xff);
>> +   for (i = 0; i < count; ++i) {
>> if (mem) {
>> -   addr = radeon_vm_get_addr(rdev, mem, i);
>> +   addr = radeon_vm_get_addr(rdev, mem,
>> + i + mem_pfn_offset);
>> addr = addr & 0xF000ULL;
>> addr |= flags;
>> }
>> +
>> +   radeon_ring_write(ring, addr & 0x);
>> +   radeon_ring_write(ring, (addr >> 32) & 0x);
>> +   }
>> +}
>> +
>> +void cayman_vm_set_pdes(struct radeon_device *rdev,
>> +   struct ttm_mem_reg *mem,
>> +   struct radeon_vm *vm,
>> +   uint64_t pde_index,
>> +   unsigned pde_count, uint32_t flags)
>> +{
>> +   struct radeon_ring *ring = >ring[rdev->asic->vm.pt_ring_index];
>> +   uint64_t addr;
>> +   int i;
>> +   uint64_t pde_gpu_addr = RADEON_BASE_GPU_ADDR(vm) +
>> +   PDE_OFFSET(rdev, pde_index);
>> +
>> +   addr = 0;
>> +
>> +   radeon_ring_write(ring, PACKET3(PACKET3_ME_WRITE, 1 + pde_count * 
>> 2));
>> +   radeon_ring_write(ring, pde_gpu_addr & 0x);
>> +   radeon_ring_write(ring, (pde_gpu_addr >> 32) & 0xff);
>> +
>> +   for (i = 0; i < pde_count; ++i) {
>> +

Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.

2012-09-13 Thread Jerome Glisse

On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher  wrote:
> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse  wrote:
>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
>>  wrote:
>>> PDE/PTE update code uses CP ring for memory writes.
>>> All page table entries are preallocated for now in alloc_pt().
>>>
>>> It is made as whole because it's hard to divide it to several patches
>>> that compile and doesn't break anything being applied separately.
>>>
>>> Tested on cayman card.
>>>
>>> Signed-off-by: Dmitry Cherkasov 
>>> ---
>>> I couldn't test in on SI card, so would be happy if someone could check it 
>>> there.
>>
>> I wonder how this could have work as you don't set
>> PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1
>> page.
>
> I think PAGE_TABLE_BLOCK_SIZE refers number of 4k pages used for PTE
> entries per PDE.  E.g., 1 4k page contains 512 64 bit PTEs. so if
> BLOCK_SIZE is set to 1 page, each PDE points to 1 page (4k) or PTE
> entries.  If BLOCK_SIZE is 2, each PDE points to 2 pages (8k) or PTEs,
> etc.
>
> Alex
>

If so then it's ok

Cheers,
Jerome
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/24] Staging: ipack/devices/ipoctal: Store isr masks in ipoctal_channel

2012-09-13 Thread Jens Taprogge

On Thu, Sep 13, 2012 at 11:19:17AM -0700, Joe Perches wrote:
> On Thu, 2012-09-13 at 20:49 +0300, Dan Carpenter wrote:
> > On Thu, Sep 13, 2012 at 08:43:12PM +0300, Dan Carpenter wrote:
> > > On Wed, Sep 12, 2012 at 02:55:29PM +0200, Samuel Iglesias Gonsalvez wrote:
> > > > From: Jens Taprogge 
> > > > 
> > > > This way interrupt handling becomes independent of the channel number.
> > > > 
> > > > Signed-off-by: Jens Taprogge 
> > > > Signed-off-by: Samuel Iglesias Gonsalvez 
> > > > ---
> > > > @@ -213,7 +206,7 @@ static int ipoctal_irq_handler(void *arg)
> > > > }
> > > >  
> > > > /* RX data */
> > > > -   if (isr_rx_rdy && (sr & SR_RX_READY)) {
> > > > +   if ((isr && channel->isr_rx_rdy_mask) && (sr & 
> > > > SR_RX_READY)) {
> > >  ^^
> > > Bitwise AND intended here I think.
> > > 
> > 
> > Never mind.  It gets silently fixed in the next patch.
> 
> Nope, you were right the first time.
> 
> It shouldn't be silently fixed,
> 
> The best path is to rework the original patch
> to fix the misuse or the worse path is that the
> subsequent patch log should mention the fix.

I am sorry this slipped through.  The patches are already in
staging-next.  What is the best action to take now?  Should I prepare
the two patches with the issue fixed?

Best Regards,
Jens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: i2c:clk: preparation for switch to common clock framework

2012-09-13 Thread Karicheri, Muralidharan

>> -Original Message-
>> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
>> Sent: Thursday, September 13, 2012 5:30 AM
>> To: Karicheri, Muralidharan
>> Cc: Nori, Sekhar; Hilman, Kevin; kh...@linux-fr.org; ben-li...@fluff.org; 
>> davinci-linux-
>> open-sou...@linux.davincidsp.com; linux-...@vger.kernel.org; linux-
>> ker...@vger.kernel.org
>> Subject: Re: i2c:clk: preparation for switch to common clock framework
>> 
>> On Thu, Aug 30, 2012 at 06:10:36PM -, m-kariche...@ti.com wrote:
>> > As a first step towards migrating davinci platforms to use common
>> > clock framework, replace all instances of clk_enable() with
>> > clk_prepare_enable() and clk_disable() with clk_disable_unprepare().
>> > Until the platform is switched to use the CONFIG_HAVE_CLK_PREPARE
>> > Kconfig variable, this just adds a might_sleep() call and would work 
>> > without any issues.
>> >
>> > This will make it easy later to switch to common clk based
>> > implementation of clk driver from DaVinci specific driver.
>> >
>> > Signed-off-by: Murali Karicheri 
>> 
>> Subject had "i2c:clk" where "i2c: davinci" would be more precise.
>> 
>> Fixed that and pushed to -next.
>> 
>> Thanks,
>> 
>>Wolfram

Wolfram,

Thanks for pushing this to -next. Greatly appreciated.

Murali
>> 
>> --
>> Pengutronix e.K.   | Wolfram Sang|
>> Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: rcu self-detected stall messages on OMAP3, 4 boards

2012-09-13 Thread Paul Walmsley

Hi Paul,

thanks for the reply,

On Wed, 12 Sep 2012, Paul E. McKenney wrote:

> Interesting.  I am assuming that the interrupt in the stack below came
> from idle, if not, please let me know what.

According to the exception stack section in the original traceback, it
appears that the serial interrupt took the SoC out of idle.

> Could you please reproduce with CONFIG_RCU_CPU_STALL_INFO=y?  That would
> give me a bit more information about why RCU thought that there was
> a stall.  (CCing Becky Bruce, who saw something similar recently.)

At the bottom of this mail is a series of tracebacks with
CONFIG_RCU_CPU_STALL_INFO=y.  Unlike the traceback that was sent in
the last message, these were not triggered by serial activity.  These
appeared every 300 seconds.

> Subodh Nijsure (also CCed) reported something that might be similar on
> ARM, and also reported that setting the following got rid of the stalls:
> 
>   CONFIG_CPU_IDLE=y
>   CONFIG_CPU_IDLE_GOV_LADDER=y
>   CONFIG_CPU_IDLE_GOV_MENU=y
> 
> At which point he was happy, which was good, but which also left the
> underlying problem unsolved.  Do these affect your system?  If so,
> do they cause a different ARM idle loop to be executed?

Will give this a try.  What board was Subodh using?


- Paul


Debian GNU/Linux wheezy/sid armel ttyO2

armel login: [  305.942108] INFO: rcu_sched self-detected stall on CPU
[  305.944946]  1: (7 GPs behind) idle=57b/1/0 
[  305.947265]   (t=22811 jiffies)
[  305.949066] [] (unwind_backtrace+0x0/0xf0) from [] 
(rcu_check_callbacks+0x1b0/0x678)
[  305.954223] [] (rcu_check_callbacks+0x1b0/0x678) from [] 
(update_process_times+0x38/0x68)
[  305.959625] [] (update_process_times+0x38/0x68) from [] 
(tick_sched_timer+0x80/0xec)
[  305.964813] [] (tick_sched_timer+0x80/0xec) from [] 
(__run_hrtimer+0x7c/0x1e0)
[  305.969696] [] (__run_hrtimer+0x7c/0x1e0) from [] 
(hrtimer_interrupt+0x11c/0x2d0)
[  305.974731] [] (hrtimer_interrupt+0x11c/0x2d0) from [] 
(twd_handler+0x30/0x44)
[  305.979644] [] (twd_handler+0x30/0x44) from [] 
(handle_percpu_devid_irq+0x90/0x13c)
[  305.984741] [] (handle_percpu_devid_irq+0x90/0x13c) from 
[] (generic_handle_irq+0x30/0x48)
[  305.990234] [] (generic_handle_irq+0x30/0x48) from [] 
(handle_IRQ+0x4c/0xac)
[  305.995025] [] (handle_IRQ+0x4c/0xac) from [] 
(gic_handle_irq+0x28/0x5c)
[  305.999633] [] (gic_handle_irq+0x28/0x5c) from [] 
(__irq_svc+0x44/0x5c)
[  306.004180] Exception stack(0xde86ff88 to 0xde86ffd0)
[  306.006927] ff80:   0003c6d0 0001  de8660c0 
de86e000 c07c23c8
[  306.011383] ffa0: c0504590 c0749e20  411fc092 c074a040  
0001 de86ffd0
[  306.015838] ffc0: 0003c6d1 c0014f50 2113 
[  306.018585] [] (__irq_svc+0x44/0x5c) from [] 
(default_idle+0x20/0x44)
[  306.023040] [] (default_idle+0x20/0x44) from [] 
(cpu_idle+0x9c/0x114)
[  306.027526] [] (cpu_idle+0x9c/0x114) from [<804f1af4>] (0x804f1af4)
[  602.004486] INFO: rcu_sched detected stalls on CPUs/tasks:
[  602.007476]  (detected by 0, t=60707 jiffies)
[  602.009857] INFO: Stall ended before state dump start
[  906.027893] INFO: rcu_sched self-detected stall on CPU
[  906.030700]  1: (6 GPs behind) idle=647/1/0 
[  906.033020]   (t=38379 jiffies)
[  906.034790] [] (unwind_backtrace+0x0/0xf0) from [] 
(rcu_check_callbacks+0x1b0/0x678)
[  906.039947] [] (rcu_check_callbacks+0x1b0/0x678) from [] 
(update_process_times+0x38/0x68)
[  906.045349] [] (update_process_times+0x38/0x68) from [] 
(tick_sched_timer+0x80/0xec)
[  906.050537] [] (tick_sched_timer+0x80/0xec) from [] 
(__run_hrtimer+0x7c/0x1e0)
[  906.055419] [] (__run_hrtimer+0x7c/0x1e0) from [] 
(hrtimer_interrupt+0x11c/0x2d0)
[  906.060424] [] (hrtimer_interrupt+0x11c/0x2d0) from [] 
(twd_handler+0x30/0x44)
[  906.065307] [] (twd_handler+0x30/0x44) from [] 
(handle_percpu_devid_irq+0x90/0x13c)
[  906.070434] [] (handle_percpu_devid_irq+0x90/0x13c) from 
[] (generic_handle_irq+0x30/0x48)
[  906.075897] [] (generic_handle_irq+0x30/0x48) from [] 
(handle_IRQ+0x4c/0xac)
[  906.080688] [] (handle_IRQ+0x4c/0xac) from [] 
(gic_handle_irq+0x28/0x5c)
[  906.085296] [] (gic_handle_irq+0x28/0x5c) from [] 
(__irq_svc+0x44/0x5c)
[  906.089843] Exception stack(0xde86ff88 to 0xde86ffd0)
[  906.092590] ff80:   0003cb06 0001  de8660c0 
de86e000 c07c23c8
[  906.097045] ffa0: c0504590 c0749e20  411fc092 c074a040  
0001 de86ffd0
[  906.101501] ffc0: 0003cb07 c0014f50 2113 
[  906.104278] [] (__irq_svc+0x44/0x5c) from [] 
(default_idle+0x20/0x44)
[  906.108734] [] (default_idle+0x20/0x44) from [] 
(cpu_idle+0x9c/0x114)
[  906.113189] [] (cpu_idle+0x9c/0x114) from [<804f1af4>] (0x804f1af4)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL 0/5] MSM changes for 3.7 merge window

Following are 5 pull requests for the MSM SoC.  The first 5 are
cleanups, fixes, devicetree, and some board changes that finally allow
us to build more than one SoC into a single kernel image.

The fifth patch is my merge, which can be used as a reference to the
intended merge resolution.

David

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

[PATCH RT 2/2] Linux 3.0.42-rt64-rc1

From: Steven Rostedt 

---
 localversion-rt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index b0e8dd7..c64934c 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt63
+-rt64-rc1
-- 
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 RT 1/2] fix printk flush of messages

From: Frank Rowand 

Reverse preempt-rt-allow-immediate-magic-sysrq-output-for-preempt_rt_full.patch

The problem addressed by that patch does not exist after applying
console-make-rt-friendly-update.patch

Signed-off-by: Frank Rowand 
Link: http://lkml.kernel.org/r/4fb44ef1.9050...@am.sony.com
Signed-off-by: Steven Rostedt 
---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c |2 +-
 drivers/tty/sysrq.c |   23 ---
 include/linux/sysrq.h   |5 -
 kernel/printk.c |5 ++---
 lib/Kconfig.debug   |   22 --
 5 files changed, 3 insertions(+), 54 deletions(-)

diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c 
b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index 2a75c84..9488da7 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1225,7 +1225,7 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
 {
struct uart_cpm_port *pinfo = _uart_ports[co->index];
unsigned long flags;
-   int nolock = oops_in_progress || sysrq_in_progress;
+   int nolock = oops_in_progress;
 
if (unlikely(nolock)) {
local_irq_save(flags);
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 5219738..43db715 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -492,23 +492,6 @@ static void __sysrq_put_key_op(int key, struct 
sysrq_key_op *op_p)
 sysrq_key_table[i] = op_p;
 }
 
-#ifdef CONFIG_MAGIC_SYSRQ_FORCE_PRINTK
-
-int sysrq_in_progress;
-
-static void set_sysrq_in_progress(int value)
-{
-   sysrq_in_progress = value;
-}
-
-#else
-
-static void set_sysrq_in_progress(int value)
-{
-}
-
-#endif
-
 void __handle_sysrq(int key, bool check_mask)
 {
struct sysrq_key_op *op_p;
@@ -517,9 +500,6 @@ void __handle_sysrq(int key, bool check_mask)
unsigned long flags;
 
spin_lock_irqsave(_key_table_lock, flags);
-
-   set_sysrq_in_progress(1);
-
/*
 * Raise the apparent loglevel to maximum so that the sysrq header
 * is shown to provide the user with positive feedback.  We do not
@@ -561,9 +541,6 @@ void __handle_sysrq(int key, bool check_mask)
printk("\n");
console_loglevel = orig_log_level;
}
-
-   set_sysrq_in_progress(0);
-
spin_unlock_irqrestore(_key_table_lock, flags);
 }
 
diff --git a/include/linux/sysrq.h b/include/linux/sysrq.h
index d224c0b..7faf933 100644
--- a/include/linux/sysrq.h
+++ b/include/linux/sysrq.h
@@ -38,11 +38,6 @@ struct sysrq_key_op {
int enable_mask;
 };
 
-#ifdef CONFIG_MAGIC_SYSRQ_FORCE_PRINTK
-extern int sysrq_in_progress;
-#else
-#define sysrq_in_progress 0
-#endif
 #ifdef CONFIG_MAGIC_SYSRQ
 
 /* Generic SysRq interface -- you may call it from any device driver, supplying
diff --git a/kernel/printk.c b/kernel/printk.c
index f2c459f..ea71fae 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -834,8 +833,8 @@ static int console_trylock_for_printk(unsigned int cpu, 
unsigned long flags)
__releases(_lock)
 {
 #ifdef CONFIG_PREEMPT_RT_FULL
-   int lock = (!early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
-   (preempt_count() <= 1)) || sysrq_in_progress;
+   int lock = !early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
+   (preempt_count() <= 1);
 #else
int lock = 1;
 #endif
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 383b565..1685473 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -62,28 +62,6 @@ config MAGIC_SYSRQ
  keys are documented in . Don't say Y
  unless you really know what this hack does.
 
-config MAGIC_SYSRQ_FORCE_PRINTK
-   bool "Force printk from Magic SysRq"
-   depends on MAGIC_SYSRQ && PREEMPT_RT_FULL
-   default n
-   help
- Allow the output from Magic SysRq to be output immediately, even if
- this causes large latencies.  This can cause performance problems
- for real-time processes.
-
- If PREEMPT_RT_FULL, printk() will not try to acquire the console lock
- when interrupts or preemption are disabled.  If the console lock is
- not acquired the printk() output will be buffered, but will not be
- output immediately.  Some drivers call into the Magic SysRq code
- with interrupts or preemption disabled, so the output of Magic SysRq
- will be buffered instead of printing immediately if this option is
- not selected.
-
- Even with this option selected, Magic SysRq output will be delayed
- if the attempt to acquire the console lock fails.
-
- Don't say Y unless you really know what this hack does.
-
 config STRIP_ASM_SYMS
bool "Strip assembler-generated symbols

[PATCH RT 0/2] [ANNOUNCE] 3.0.42-rt64-rc1 stable review

Dear RT Folks,

This is the RT stable review cycle of patch 3.0.42-rt64-rc1.

Note: The patches have not been uploaded to kernel.org yet. I've
recently changed the subkey that I use to sign the patches as the
old subkey is about to expire. But unfortunately, kernel.org has
not updated its key ring, and is refusing my current subkey.

I have a ticket open with kernel.org to resolve the issue. But until
then, this mailing is the only place the patches exist.

Please scream at me if I messed something up. Please test the patches too.

The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the
final release is.

If all goes well, this patch will be converted to the next main release
on 9/17/2012.

Enjoy,

-- Steve

To build 3.0.42-rt64-rc1 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz

http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.42.xz

http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.42-rt64-rc1.patch.xz

You can also build from 3.0.42-rt63 by applying the incremental patch:

http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/incr/patch-3.0.42-rt63-rt64-rc1.patch.xz

Changes from 3.0.42-rt63:

---

Frank Rowand (1):
fix printk flush of messages

Steven Rostedt (1):
Linux 3.0.42-rt64-rc1

drivers/tty/serial/cpm_uart/cpm_uart_core.c |2 +-
drivers/tty/sysrq.c | 23 ---
include/linux/sysrq.h |5 -
kernel/printk.c |5 ++---
lib/Kconfig.debug | 22 --
localversion-rt |2 +-
6 files changed, 4 insertions(+), 55 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[GIT PULL 1/5] msm cleanups

The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git 
tags/msm-cleanup-for-3.7

for you to fetch changes up to e63770acb3c1e7334885ed4673aed1375f93484a:

  ARM: msm: Remove uncompiled board-msm7x27 (2012-09-13 11:13:08 -0700)


Various cleanups for the msm targets.  Most of this is removing dead
code, along with a fix of a sparse warning, a list fix from a semantic
patch, and marking some functions as static.


Stephen Boyd (6):
  ARM: msm: Remove msm_hw_reset_hook
  ARM: msm: clock-pcom: Mark functions static
  ARM: msm: Remove unused idle.c
  ARM: msm: Fix sparse warnings due to incorrect type
  ARM: msm: Remove unused acpuclock-arm11
  ARM: msm: Remove uncompiled board-msm7x27

Wei Yongjun (1):
  ARM: msm: dma: use list_move_tail instead of list_del/list_add_tail

 arch/arm/mach-msm/Makefile  |   4 +-
 arch/arm/mach-msm/acpuclock-arm11.c | 525 
 arch/arm/mach-msm/acpuclock.h   |  32 --
 arch/arm/mach-msm/board-mahimahi.c  |   1 -
 arch/arm/mach-msm/board-msm7x27.c   | 170 ---
 arch/arm/mach-msm/board-sapphire.c  |   1 -
 arch/arm/mach-msm/clock-pcom.c  |  18 +-
 arch/arm/mach-msm/dma.c |   3 +-
 arch/arm/mach-msm/idle.c|  49 ---
 arch/arm/mach-msm/include/mach/board.h  |  10 -
 arch/arm/mach-msm/include/mach/system.h |  19 --
 arch/arm/mach-msm/io.c  |   3 +-
 arch/arm/mach-msm/proc_comm.c   |   1 -
 arch/arm/mach-msm/smd.c |   7 -
 arch/arm/mach-msm/timer.c   |   2 +-
 15 files changed, 14 insertions(+), 831 deletions(-)
 delete mode 100644 arch/arm/mach-msm/acpuclock-arm11.c
 delete mode 100644 arch/arm/mach-msm/acpuclock.h
 delete mode 100644 arch/arm/mach-msm/board-msm7x27.c
 delete mode 100644 arch/arm/mach-msm/idle.c
 delete mode 100644 arch/arm/mach-msm/include/mach/system.h

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

[GIT PULL 2/5] msm non-critical fixes

The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git 
tags/msm-fix-noncrit-for-3.7

for you to fetch changes up to 10717e04d3502cf4a8aa6408d59093e2bbb4645b:

  ARM: msm: Fix early debug uart mapping on some memory configs (2012-09-13 
10:48:35 -0700)


Some non-critical fixes for msm platforms.  The missing FPGA init call
fix is necessary to compile the 8660 target.  The iomapping calls are
needed to prevent duplicate mappings with differing attributes.  And,
the debug UART change keeps the debug UART working on targets with
more than 512MB of memory.


David Brown (1):
  ARM: msm: Remove call to missing FPGA init on 8660

Rohit Vaswani (2):
  ARM: msm: io: Remove 7x30 iomap region from 7x00
  ARM: msm: io: Change the default static iomappings to be shared

Stephen Boyd (1):
  ARM: msm: Fix early debug uart mapping on some memory configs

 arch/arm/mach-msm/board-msm8x60.c   |  5 -
 arch/arm/mach-msm/include/mach/msm_iomap-8960.h |  2 +-
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h |  2 +-
 arch/arm/mach-msm/io.c  | 25 +
 4 files changed, 15 insertions(+), 19 deletions(-)

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

[GIT PULL 3/5] msm devicetree changes

The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git 
tags/msm-dt-for-3.7

for you to fetch changes up to 0607fa5884f1759b396a0e1c07be561515daddc8:

  ARM: msm: Remove non-DT targets from 8960 (2012-09-13 11:17:01 -0700)


These patches migrate both the 8660 and 8960 targets on msm to be
devicetree only.  This also sets most of the frame in place necessary
to build both targets into the same image.

There's a couple of cleanups in here that are kept in this series
because they are intimately tied to the changes necessary to support
the devicetree conversions.


Stephen Boyd (11):
  ARM: msm: Add handle_irq handler for 8660 DT machine
  ARM: msm: Add msm8660-surf.dts to Makefile.boot
  ARM: msm: Don't touch GIC registers outside of GIC code
  ARM: msm: Allow timer.c to compile on multiple targets
  ARM: msm: Add DT support to msm_timer
  ARM: msm: Move 8660 to DT timer
  ARM: msm: Make 8660 a DT only target
  ARM: msm: Rename board-msm8x60 to signify its DT only status
  ARM: msm: Move io mapping prototypes to common.h
  ARM: msm: Add DT support for 8960
  ARM: msm: Remove non-DT targets from 8960

 .../devicetree/bindings/arm/msm/timer.txt  |  38 +
 arch/arm/boot/dts/msm8660-surf.dts |  19 ++-
 arch/arm/boot/dts/msm8960-cdp.dts  |  41 +
 arch/arm/mach-msm/Kconfig  |  41 +
 arch/arm/mach-msm/Makefile |   4 +-
 arch/arm/mach-msm/Makefile.boot|   3 +
 arch/arm/mach-msm/board-dt-8660.c  |  68 
 arch/arm/mach-msm/board-dt-8960.c  |  49 ++
 arch/arm/mach-msm/board-halibut.c  |   5 +-
 arch/arm/mach-msm/board-msm7x30.c  |   9 +-
 arch/arm/mach-msm/board-msm8960.c  | 122 --
 arch/arm/mach-msm/board-msm8x60.c  | 166 --
 arch/arm/mach-msm/board-qsd8x50.c  |   7 +-
 arch/arm/mach-msm/board-trout.c|   5 +-
 arch/arm/mach-msm/common.h |  30 
 arch/arm/mach-msm/devices-msm8960.c|  85 --
 arch/arm/mach-msm/include/mach/board.h |   3 -
 arch/arm/mach-msm/include/mach/msm_iomap-7x00.h|   7 -
 arch/arm/mach-msm/include/mach/msm_iomap-7x30.h|   4 -
 arch/arm/mach-msm/include/mach/msm_iomap-8960.h|   4 -
 arch/arm/mach-msm/include/mach/msm_iomap-8x50.h|   4 -
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h|   4 -
 arch/arm/mach-msm/io.c |   2 +
 arch/arm/mach-msm/platsmp.c|   8 -
 arch/arm/mach-msm/timer.c  | 186 -
 25 files changed, 412 insertions(+), 502 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/timer.txt
 create mode 100644 arch/arm/boot/dts/msm8960-cdp.dts
 create mode 100644 arch/arm/mach-msm/board-dt-8660.c
 create mode 100644 arch/arm/mach-msm/board-dt-8960.c
 delete mode 100644 arch/arm/mach-msm/board-msm8960.c
 delete mode 100644 arch/arm/mach-msm/board-msm8x60.c
 create mode 100644 arch/arm/mach-msm/common.h
 delete mode 100644 arch/arm/mach-msm/devices-msm8960.c

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

[PATCH] USB: omninet: fix potential tty NULL dereference

2012-09-13 Thread Alexey Khoroshilov

Add check for return value of tty_port_tty_get,
since it can return NULL after port hangup that may happen anytime.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/usb/serial/omninet.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/omninet.c b/drivers/usb/serial/omninet.c
index 6f3d705..493c892 100644
--- a/drivers/usb/serial/omninet.c
+++ b/drivers/usb/serial/omninet.c
@@ -185,10 +185,12 @@ static void omninet_read_bulk_callback(struct urb *urb)
 
if (urb->actual_length && header->oh_len) {
struct tty_struct *tty = tty_port_tty_get(>port);
-   tty_insert_flip_string(tty, data + OMNINET_DATAOFFSET,
+   if (tty) {
+   tty_insert_flip_string(tty, data + OMNINET_DATAOFFSET,
header->oh_len);
-   tty_flip_buffer_push(tty);
-   tty_kref_put(tty);
+   tty_flip_buffer_push(tty);
+   tty_kref_put(tty);
+   }
}
 
/* Continue trying to always read  */
-- 
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/

[GIT PULL 4/5] msm board changes

The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git 
tags/msm-board-for-3.7

for you to fetch changes up to 33fcb13dc543af610c7c930dbfeeed6e6ed02376:

  ARM: msm: Allow 8960 and 8660 to compile together (2012-09-13 11:17:47 -0700)


Final parts to allow msm8660 and msm8960 to build into the same
kernel.  This won't work without the changes from msm-dt-for-3.7.


Stephen Boyd (2):
  ARM: msm: Allow msm_iomap-8x60 and msm_iomap-8960 to coexist
  ARM: msm: Allow 8960 and 8660 to compile together

 arch/arm/mach-msm/Kconfig   |  8 ++--
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 11 ---
 arch/arm/mach-msm/include/mach/msm_iomap.h  |  3 +--
 arch/arm/mach-msm/io.c  |  2 --
 4 files changed, 7 insertions(+), 17 deletions(-)

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

[GIT PULL 5/5] msm all changes

The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git 
tags/msm-merged-for-3.7

for you to fetch changes up to 9b9b5ed018ac77127140d41fbfbe0224fad1d088:

  Merge branch '36/board' into 36/merged (2012-09-13 11:23:22 -0700)



This is a merge of the following tags:
msm-board-for-3.7
msm-cleanup-for-3.7
msm-dt-for-3.7
msm-fix-noncrit-for-3.7

mostly to show the correct merge resolution.  There's a trivial merge
resolve in arch/arm/mach-msm/io.c.

The rename of arch/arm/mach-msm/board-msm8x60.c to
arch/arm/mach-msm/board-dt-8660.c seems to have confused git, causing
it to drop
  ARM: msm: Remove call to missing FPGA init on 8660
so this merge resolution fixes that.


David Brown (5):
  ARM: msm: Remove call to missing FPGA init on 8660
  Merge branch '36/cleanup' into 36/merged
  Merge branch '36/fix-noncrit' into 36/merged
  Merge branch '36/dt' into 36/merged
  Merge branch '36/board' into 36/merged

Rohit Vaswani (2):
  ARM: msm: io: Remove 7x30 iomap region from 7x00
  ARM: msm: io: Change the default static iomappings to be shared

Stephen Boyd (20):
  ARM: msm: Remove msm_hw_reset_hook
  ARM: msm: clock-pcom: Mark functions static
  ARM: msm: Remove unused idle.c
  ARM: msm: Fix early debug uart mapping on some memory configs
  ARM: msm: Add handle_irq handler for 8660 DT machine
  ARM: msm: Add msm8660-surf.dts to Makefile.boot
  ARM: msm: Fix sparse warnings due to incorrect type
  ARM: msm: Remove unused acpuclock-arm11
  ARM: msm: Remove uncompiled board-msm7x27
  ARM: msm: Don't touch GIC registers outside of GIC code
  ARM: msm: Allow timer.c to compile on multiple targets
  ARM: msm: Add DT support to msm_timer
  ARM: msm: Move 8660 to DT timer
  ARM: msm: Make 8660 a DT only target
  ARM: msm: Rename board-msm8x60 to signify its DT only status
  ARM: msm: Move io mapping prototypes to common.h
  ARM: msm: Add DT support for 8960
  ARM: msm: Remove non-DT targets from 8960
  ARM: msm: Allow msm_iomap-8x60 and msm_iomap-8960 to coexist
  ARM: msm: Allow 8960 and 8660 to compile together

Wei Yongjun (1):
  ARM: msm: dma: use list_move_tail instead of list_del/list_add_tail

 .../devicetree/bindings/arm/msm/timer.txt  |  38 ++
 arch/arm/boot/dts/msm8660-surf.dts |  19 +-
 arch/arm/boot/dts/msm8960-cdp.dts  |  41 ++
 arch/arm/mach-msm/Kconfig  |  49 +-
 arch/arm/mach-msm/Makefile |   8 +-
 arch/arm/mach-msm/Makefile.boot|   3 +
 arch/arm/mach-msm/acpuclock-arm11.c| 525 -
 arch/arm/mach-msm/acpuclock.h  |  32 --
 arch/arm/mach-msm/board-dt-8660.c  |  63 +++
 arch/arm/mach-msm/board-dt-8960.c  |  49 ++
 arch/arm/mach-msm/board-halibut.c  |   5 +-
 arch/arm/mach-msm/board-mahimahi.c |   1 -
 arch/arm/mach-msm/board-msm7x27.c  | 170 ---
 arch/arm/mach-msm/board-msm7x30.c  |   9 +-
 arch/arm/mach-msm/board-msm8960.c  | 122 -
 arch/arm/mach-msm/board-msm8x60.c  | 166 ---
 arch/arm/mach-msm/board-qsd8x50.c  |   7 +-
 arch/arm/mach-msm/board-sapphire.c |   1 -
 arch/arm/mach-msm/board-trout.c|   5 +-
 arch/arm/mach-msm/clock-pcom.c |  18 +-
 arch/arm/mach-msm/common.h |  30 ++
 arch/arm/mach-msm/devices-msm8960.c|  85 
 arch/arm/mach-msm/dma.c|   3 +-
 arch/arm/mach-msm/idle.c   |  49 --
 arch/arm/mach-msm/include/mach/board.h |  13 -
 arch/arm/mach-msm/include/mach/msm_iomap-7x00.h|   7 -
 arch/arm/mach-msm/include/mach/msm_iomap-7x30.h|   4 -
 arch/arm/mach-msm/include/mach/msm_iomap-8960.h|   6 +-
 arch/arm/mach-msm/include/mach/msm_iomap-8x50.h|   4 -
 arch/arm/mach-msm/include/mach/msm_iomap-8x60.h|  17 +-
 arch/arm/mach-msm/include/mach/msm_iomap.h |   3 +-
 arch/arm/mach-msm/include/mach/system.h|  19 -
 arch/arm/mach-msm/io.c |  32 +-
 arch/arm/mach-msm/platsmp.c|   8 -
 arch/arm/mach-msm/proc_comm.c  |   1 -
 arch/arm/mach-msm/smd.c|   7 -
 arch/arm/mach-msm/timer.c  | 188 ++--
 37 files changed, 443 insertions(+), 1364 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/msm/timer.txt
 create mode 100644

[PATCH RT 0/2] [ANNOUNCE] 3.2.28-rt43-rc1 stable review

Dear RT Folks,

This is the RT stable review cycle of patch 3.2.28-rt43-rc1.

Please scream at me if I messed something up. Please test the patches too.

I have a ticket open with kernel.org to resolve the issue. But until
then, this mailing is the only place the patches exist.

The -rc release will be uploaded to kernel.org and will be deleted when
the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the
final release is.

If all goes well, this patch will be converted to the next main release
on 9/17/2012.

Enjoy,

-- Steve

To build 3.2.28-rt43-rc1 directly, the following patches should be applied:

http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.28.xz

http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.28-rt43-rc1.patch.xz

You can also build from 3.2.28-rt42 by applying the incremental patch:

http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/incr/patch-3.2.28-rt42-rt43-rc1.patch.xz

Changes from 3.2.28-rt42:

---

Frank Rowand (1):
fix printk flush of messages

Steven Rostedt (1):
Linux 3.2.28-rt43-rc1

[PATCH RT 2/2] Linux 3.2.28-rt43-rc1

From: Steven Rostedt 

---
 localversion-rt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index 8bdfb9a..d5a74ba 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt42
+-rt43-rc1
-- 
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 RT 1/2] fix printk flush of messages

From: Frank Rowand 

Reverse preempt-rt-allow-immediate-magic-sysrq-output-for-preempt_rt_full.patch

The problem addressed by that patch does not exist after applying
console-make-rt-friendly-update.patch

Signed-off-by: Frank Rowand 
Link: http://lkml.kernel.org/r/4fb44ef1.9050...@am.sony.com
Signed-off-by: Steven Rostedt 
---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c |2 +-
 drivers/tty/sysrq.c |   23 ---
 include/linux/sysrq.h   |5 -
 kernel/printk.c |5 ++---
 lib/Kconfig.debug   |   22 --
 5 files changed, 3 insertions(+), 54 deletions(-)

diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c 
b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index a8b0559..b418947 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1226,7 +1226,7 @@ static void cpm_uart_console_write(struct console *co, 
const char *s,
 {
struct uart_cpm_port *pinfo = _uart_ports[co->index];
unsigned long flags;
-   int nolock = oops_in_progress || sysrq_in_progress;
+   int nolock = oops_in_progress;
 
if (unlikely(nolock)) {
local_irq_save(flags);
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 5219738..43db715 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -492,23 +492,6 @@ static void __sysrq_put_key_op(int key, struct 
sysrq_key_op *op_p)
 sysrq_key_table[i] = op_p;
 }
 
-#ifdef CONFIG_MAGIC_SYSRQ_FORCE_PRINTK
-
-int sysrq_in_progress;
-
-static void set_sysrq_in_progress(int value)
-{
-   sysrq_in_progress = value;
-}
-
-#else
-
-static void set_sysrq_in_progress(int value)
-{
-}
-
-#endif
-
 void __handle_sysrq(int key, bool check_mask)
 {
struct sysrq_key_op *op_p;
@@ -517,9 +500,6 @@ void __handle_sysrq(int key, bool check_mask)
unsigned long flags;
 
spin_lock_irqsave(_key_table_lock, flags);
-
-   set_sysrq_in_progress(1);
-
/*
 * Raise the apparent loglevel to maximum so that the sysrq header
 * is shown to provide the user with positive feedback.  We do not
@@ -561,9 +541,6 @@ void __handle_sysrq(int key, bool check_mask)
printk("\n");
console_loglevel = orig_log_level;
}
-
-   set_sysrq_in_progress(0);
-
spin_unlock_irqrestore(_key_table_lock, flags);
 }
 
diff --git a/include/linux/sysrq.h b/include/linux/sysrq.h
index d224c0b..7faf933 100644
--- a/include/linux/sysrq.h
+++ b/include/linux/sysrq.h
@@ -38,11 +38,6 @@ struct sysrq_key_op {
int enable_mask;
 };
 
-#ifdef CONFIG_MAGIC_SYSRQ_FORCE_PRINTK
-extern int sysrq_in_progress;
-#else
-#define sysrq_in_progress 0
-#endif
 #ifdef CONFIG_MAGIC_SYSRQ
 
 /* Generic SysRq interface -- you may call it from any device driver, supplying
diff --git a/kernel/printk.c b/kernel/printk.c
index 66e83e5..85d8795 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -835,8 +834,8 @@ static int console_trylock_for_printk(unsigned int cpu, 
unsigned long flags)
 {
int retval = 0, wake = 0;
 #ifdef CONFIG_PREEMPT_RT_FULL
-   int lock = (!early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
-   (preempt_count() <= 1)) || sysrq_in_progress;
+   int lock = !early_boot_irqs_disabled && !irqs_disabled_flags(flags) &&
+   (preempt_count() <= 1);
 #else
int lock = 1;
 #endif
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 13a937b..c347db3 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -62,28 +62,6 @@ config MAGIC_SYSRQ
  keys are documented in . Don't say Y
  unless you really know what this hack does.
 
-config MAGIC_SYSRQ_FORCE_PRINTK
-   bool "Force printk from Magic SysRq"
-   depends on MAGIC_SYSRQ && PREEMPT_RT_FULL
-   default n
-   help
- Allow the output from Magic SysRq to be output immediately, even if
- this causes large latencies.  This can cause performance problems
- for real-time processes.
-
- If PREEMPT_RT_FULL, printk() will not try to acquire the console lock
- when interrupts or preemption are disabled.  If the console lock is
- not acquired the printk() output will be buffered, but will not be
- output immediately.  Some drivers call into the Magic SysRq code
- with interrupts or preemption disabled, so the output of Magic SysRq
- will be buffered instead of printing immediately if this option is
- not selected.
-
- Even with this option selected, Magic SysRq output will be delayed
- if the attempt to acquire the console lock fails.
-
- Don't say Y unless you really know what this hack does.
-
 config STRIP_ASM_SYMS
bool "Strip assembler-generated

[GIT PULL 1/5] msm cleanups (resend)

[resending to proper In-Reply-To]

The following changes since commit 28a33cbc24e4256c143dce96c7d93bf423229f92:

  Linux 3.5 (2012-07-21 13:58:29 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git 
tags/msm-cleanup-for-3.7

for you to fetch changes up to e63770acb3c1e7334885ed4673aed1375f93484a:

  ARM: msm: Remove uncompiled board-msm7x27 (2012-09-13 11:13:08 -0700)


Various cleanups for the msm targets.  Most of this is removing dead
code, along with a fix of a sparse warning, a list fix from a semantic
patch, and marking some functions as static.


Stephen Boyd (6):
  ARM: msm: Remove msm_hw_reset_hook
  ARM: msm: clock-pcom: Mark functions static
  ARM: msm: Remove unused idle.c
  ARM: msm: Fix sparse warnings due to incorrect type
  ARM: msm: Remove unused acpuclock-arm11
  ARM: msm: Remove uncompiled board-msm7x27

Wei Yongjun (1):
  ARM: msm: dma: use list_move_tail instead of list_del/list_add_tail

 arch/arm/mach-msm/Makefile  |   4 +-
 arch/arm/mach-msm/acpuclock-arm11.c | 525 
 arch/arm/mach-msm/acpuclock.h   |  32 --
 arch/arm/mach-msm/board-mahimahi.c  |   1 -
 arch/arm/mach-msm/board-msm7x27.c   | 170 ---
 arch/arm/mach-msm/board-sapphire.c  |   1 -
 arch/arm/mach-msm/clock-pcom.c  |  18 +-
 arch/arm/mach-msm/dma.c |   3 +-
 arch/arm/mach-msm/idle.c|  49 ---
 arch/arm/mach-msm/include/mach/board.h  |  10 -
 arch/arm/mach-msm/include/mach/system.h |  19 --
 arch/arm/mach-msm/io.c  |   3 +-
 arch/arm/mach-msm/proc_comm.c   |   1 -
 arch/arm/mach-msm/smd.c |   7 -
 arch/arm/mach-msm/timer.c   |   2 +-
 15 files changed, 14 insertions(+), 831 deletions(-)
 delete mode 100644 arch/arm/mach-msm/acpuclock-arm11.c
 delete mode 100644 arch/arm/mach-msm/acpuclock.h
 delete mode 100644 arch/arm/mach-msm/board-msm7x27.c
 delete mode 100644 arch/arm/mach-msm/idle.c
 delete mode 100644 arch/arm/mach-msm/include/mach/system.h

-- 
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: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

2012-09-13 Thread Andrew Morton

On Tue, 11 Sep 2012 17:47:16 +0100
Will Deacon  wrote:

> From: Steve Capper 
> 
> Different architectures have slightly different pre-requisites for supporting
> Transparent Huge Pages. To simplify the layout of mm/Kconfig, a new option
> HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each architecture's
> Kconfig file (at the moment x86, with ARM being set in a future patch).
> 
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1297,6 +1297,10 @@ config ILLEGAL_POINTER_VALUE
> default 0 if X86_32
> default 0xdead if X86_64
>  
> +config HAVE_ARCH_TRANSPARENT_HUGEPAGE
> +   def_bool y
> +   depends on MMU
> +
>  source "mm/Kconfig"
>  
>  config HIGHPTE
> diff --git a/mm/Kconfig b/mm/Kconfig
> index d5c8019..3322342 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
>  
>  config TRANSPARENT_HUGEPAGE
>   bool "Transparent Hugepage Support"
> - depends on X86 && MMU
> + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE
>   select COMPACTION
>   help
> Transparent Hugepages allows the kernel to use huge pages and

We need to talk with Gerald concerning
http://ozlabs.org/~akpm/mmotm/broken-out/thp-x86-introduce-have_arch_transparent_hugepage.patch


I did this.  Please check.

From: Steve Capper 
Subject: mm: introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE

Different architectures have slightly different pre-requisites for
supporting Transparent Huge Pages.  To simplify the layout of mm/Kconfig,
a new option HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each
architecture's Kconfig file (at the moment x86, with ARM being set in a
future patch).

Signed-off-by: Steve Capper 
Signed-off-by: Will Deacon 
Cc: Arnd Bergmann 
Cc: Catalin Marinas 
Cc: Kirill A. Shutemov 
Cc: Michal Hocko 
Cc: Gerald Schaefer 
Cc: Andrea Arcangeli 
Signed-off-by: Andrew Morton 
---

 arch/x86/Kconfig |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff -puN arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage 
arch/x86/Kconfig
--- a/arch/x86/Kconfig~mm-introduce-have_arch_transparent_hugepage
+++ a/arch/x86/Kconfig
@@ -83,7 +83,6 @@ config X86
select IRQ_FORCED_THREADING
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_BPF_JIT if X86_64
-   select HAVE_ARCH_TRANSPARENT_HUGEPAGE
select CLKEVT_I8253
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_IOMAP
@@ -1330,6 +1329,10 @@ config ILLEGAL_POINTER_VALUE
default 0 if X86_32
default 0xdead if X86_64
 
+config HAVE_ARCH_TRANSPARENT_HUGEPAGE
+   def_bool y
+   depends on MMU
+
 source "mm/Kconfig"
 
 config HIGHPTE

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] drivers/video/gbefb.c: use devm_ functions

2012-09-13 Thread Geert Uytterhoeven

On Thu, Aug 23, 2012 at 10:37 PM, Florian Tobias Schandinat
 wrote:
> On 07/31/2012 04:39 PM, Damien Cassou wrote:
>> From: Damien Cassou 
>>
>> The various devm_ functions allocate memory that is released when a driver
>> detaches.  This patch uses these functions for data that is allocated in
>> the probe function of a platform device and is only freed in the remove
>> function.
>>
>> Signed-off-by: Damien Cassou 
>
> Applied.

>> diff --git a/drivers/video/gbefb.c b/drivers/video/gbefb.c
>> index 7e7b7a9..9b79d38 100644
>> --- a/drivers/video/gbefb.c
>> +++ b/drivers/video/gbefb.c
>> @@ -1156,7 +1156,8 @@ static int __devinit gbefb_probe(struct 
>> platform_device *p_dev)
>>   goto out_release_framebuffer;
>>   }
>>
>> - gbe = (struct sgi_gbe *) ioremap(GBE_BASE, sizeof(struct sgi_gbe));
>> + gbe = (struct sgi_gbe *) devm_ioremap(_dev->dev, GBE_BASE,
>> +   sizeof(struct sgi_gbe));

drivers/video/gbefb.c:1159:16: error: implicit declaration of function
'devm_ioremap' [-Werror=implicit-function-declaration]
drivers/video/gbefb.c:1179:3: error: implicit declaration of function
'devm_ioremap_nocache' [-Werror=implicit-function-declaration]

http://kisskb.ellerman.id.au/kisskb/buildresult/7187731/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: cma: Discard clean pages during contiguous allocation instead of migration

2012-09-13 Thread Geert Uytterhoeven

On Tue, Sep 11, 2012 at 2:41 AM, Minchan Kim  wrote:
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -674,8 +674,10 @@ static enum page_references page_check_references(struct 
> page *page,
>  static unsigned long shrink_page_list(struct list_head *page_list,
>   struct zone *zone,
>   struct scan_control *sc,
> + enum ttu_flags ttu_flags,

"enum ttu_flags" is defined on CONFIG_MMU=y only, causing on nommu:

mm/vmscan.c:677:26: error: parameter 4 ('ttu_flags') has incomplete type
mm/vmscan.c:987:5: error: 'TTU_UNMAP' undeclared (first use in this function)
mm/vmscan.c:987:15: error: 'TTU_IGNORE_ACCESS' undeclared (first use
in this function)
mm/vmscan.c:1312:56: error: 'TTU_UNMAP' undeclared (first use in this function)

E.g.
http://kisskb.ellerman.id.au/kisskb/buildresult/7191694/ (h8300-defconfig)
http://kisskb.ellerman.id.au/kisskb/buildresult/7191858/ (sh-allnoconfig)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/24] Staging: ipack/devices/ipoctal: Store isr masks in ipoctal_channel

2012-09-13 Thread Dan Carpenter

On Thu, Sep 13, 2012 at 08:43:46PM +0200, Jens Taprogge wrote:
> On Thu, Sep 13, 2012 at 11:19:17AM -0700, Joe Perches wrote:
> > On Thu, 2012-09-13 at 20:49 +0300, Dan Carpenter wrote:
> > > On Thu, Sep 13, 2012 at 08:43:12PM +0300, Dan Carpenter wrote:
> > > > On Wed, Sep 12, 2012 at 02:55:29PM +0200, Samuel Iglesias Gonsalvez 
> > > > wrote:
> > > > > From: Jens Taprogge 
> > > > > 
> > > > > This way interrupt handling becomes independent of the channel number.
> > > > > 
> > > > > Signed-off-by: Jens Taprogge 
> > > > > Signed-off-by: Samuel Iglesias Gonsalvez 
> > > > > ---
> > > > > @@ -213,7 +206,7 @@ static int ipoctal_irq_handler(void *arg)
> > > > >   }
> > > > >  
> > > > >   /* RX data */
> > > > > - if (isr_rx_rdy && (sr & SR_RX_READY)) {
> > > > > + if ((isr && channel->isr_rx_rdy_mask) && (sr & 
> > > > > SR_RX_READY)) {
> > > >  ^^
> > > > Bitwise AND intended here I think.
> > > > 
> > > 
> > > Never mind.  It gets silently fixed in the next patch.
> > 
> > Nope, you were right the first time.
> > 
> > It shouldn't be silently fixed,
> > 
> > The best path is to rework the original patch
> > to fix the misuse or the worse path is that the
> > subsequent patch log should mention the fix.
> 
> I am sorry this slipped through.  The patches are already in
> staging-next.  What is the best action to take now?  Should I prepare
> the two patches with the issue fixed?

If it weren't in staging-next then, yeah, it probably would have
been better to resend those two patches.  You could send them by
themselves without resending any of the others.  But once they hit
staging-next, it's too late.

No stress.

regards,
dan carpenter

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

Re: [PATCH 1/2] module: add syscall to load module from fd

2012-09-13 Thread Mimi Zohar

On Wed, 2012-09-12 at 17:04 +0930, Rusty Russell wrote:
> "H. Peter Anvin"  writes:
> 
> > On 09/06/2012 11:13 AM, Kees Cook wrote:
> >> Instead of (or in addition to) kernel module signing, being able to reason
> >> about the origin of a kernel module would be valuable in situations
> >> where an OS already trusts a specific file system, file, etc, due to
> >> things like security labels or an existing root of trust to a partition
> >> through things like dm-verity.
> >>
> >> This introduces a new syscall (currently only on x86), similar to
> >> init_module, that has only two arguments. The first argument is used as
> >> a file descriptor to the module and the second argument is a pointer to
> >> the NULL terminated string of module arguments.
> >>
> >
> > Please use the standard naming convention, which is an f- prefix (i.e. 
> > finit_module()).
> 
> Good point; I just did a replace here.

Have you pushed out the changes?  And if so, to where?

thanks,

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Drbd-dev] FLUSH/FUA documentation & code discrepancy

Hello, Joseph.

On Thu, Sep 13, 2012 at 01:10:13PM +1000, Joseph Glanville wrote:
> While reviewing some of the documentation in Documentation/block I
> found there is still out of date references to the old barrier code.
> Should this also be removed?
> I am not sufficiently confident of my understanding of the block layer
> to do a through review/update of the Documentation/block stuff but my
> untrained eye suggests maybe that such a undertaking is probably abit
> overdue.

Please be my guest.  I'll be happy to review it.

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/

Re: [PATCH] mm: bootmem: use phys_addr_t for physical addresses

Hello, Cyril.

On Wed, Sep 12, 2012 at 08:40:58PM -0400, Cyril Chemparathy wrote:
> You probably missed the lowmem bit from my response?
> 
> This system has all of its memory outside the 4GB physical address
> space.  This includes lowmem, which is permanently mapped into the
> kernel virtual address space as usual.

Yeah, I understand that and as a short-term solution we maybe can add
a check to verify that the goal and limits are under lowmem and fail
with NULL if not, but it still is a broken interface and I'd rather
not mess with it when memblock is already there.  Converting to
memblock usually isn't too much work although it expectedly involves
some subtleties and fallouts for a while.

Do you recall what the problem was with sparsemem and memblock?  I
don't think I'll directly work on arm but I'll be happy to help on
memblock issues.

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/

Re: [RE-RESEND][PATCH] audit: replace defines with C stubs

2012-09-13 Thread Geert Uytterhoeven

On Tue, Aug 7, 2012 at 2:40 AM, Kees Cook  wrote:
> This replaces the #defines used when CONFIG_AUDIT or CONFIG_AUDIT_SYSCALLS
> are disabled so we get type checking during those builds.
>
> Suggested-by: Andrew Morton 
> Signed-off-by: Kees Cook 

JFYI, the change

-#define audit_syscall_entry(ta,a,b,c,d,e) do { ; } while (0)
+static inline void audit_syscall_entry(int arch, int major, unsigned long a0,
+  unsigned long a1, unsigned long a2,
+  unsigned long a3)
+{ }

uncovers a bug on OpenRISC.

Before,

audit_syscall_entry(audit_arch(), regs->gpr[11],
regs->gpr[3], regs->gpr[4],
regs->gpr[5], regs->gpr[6]);

just expanded to nothing if CONFIG_AUDITSYSCALL was not set.
Now, it fails to compile with:

arch/openrisc/kernel/ptrace.c:190:2: error: implicit declaration of
function 'audit_arch'
http://kisskb.ellerman.id.au/kisskb/buildresult/7191698/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Xen backend support for paged out grant targets.

2012-09-13 Thread Andres Lagar-Cavilla


On Sep 13, 2012, at 2:11 PM, Ian Campbell wrote:

> On Thu, 2012-09-13 at 18:28 +0100, Andres Lagar-Cavilla wrote:
>> 
>> * Add placeholder in array of grant table error descriptions for
>> unrelated error code we jump over. 
> 
> Why not just define it, it's listed here:
> http://xenbits.xen.org/docs/unstable/hypercall/include,public,grant_table.h.html#Enum_grant_status
Well, a) we'd be defining something no one will be using (for the moment) b) I 
would be signing-off on something unrelated.
> 
> I notice the specific wording of the error msg is different here too.
That should not be, I'll re-spin the patch.

Thanks
Andres

> It'd probably be best to use the same wording as the Xen definition, so
> all OSes end up with the same name for the same condition (else bug
> reports will be confusing).
> 
> Ian.
> 

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

Really needs pulling

2012-09-13 Thread Rich Lawlman

Linux needs to drop USB support, as it's old, troublesome, useless and
superseded by wireless technologies. We need to drive people's
attention away from such rubbish, and instead endorse futureproof
devices such as Serial Port.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: use kasprintf() in pinmux_request_gpio()

2012-09-13 Thread Thomas Petazzoni

Instead of using a temporary buffer, snprintf() and kstrdup(), just
use kasprintf() that does the same thing in just oneline.

Signed-off-by: Thomas Petazzoni 
---
 drivers/pinctrl/pinmux.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 3d5ac73..9301a7a 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -232,14 +232,11 @@ int pinmux_request_gpio(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin, unsigned gpio)
 {
-   char gpiostr[16];
const char *owner;
int ret;
 
/* Conjure some name stating what chip and pin this is taken by */
-   snprintf(gpiostr, 15, "%s:%d", range->name, gpio);
-
-   owner = kstrdup(gpiostr, GFP_KERNEL);
+   owner = kasprintf(GFP_KERNEL, "%s:%d", range->name, gpio);
if (!owner)
return -EINVAL;
 
-- 
1.7.9.5

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

Re: [PATCH v2] arm: omap: hwmod: make phy_48m as the main_clk of ocp2scp

2012-09-13 Thread Paul Walmsley

On Thu, 13 Sep 2012, Paul Walmsley wrote:

> Okay so is this an Acked-by for this patch? :-)
> 
> If so I'll take it.

Just realized that's what your reply was, so have queued the patch for 
3.7.


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

[PATCH v2 0/4]: ezusb cleanup, FX2 support, firmware downloading support

Hello, 

this is V2 of a patches-series for controllers using the ezusb-functions.

ezusb: remove dependency to usb_serial interface
euzsb: add support for Cypress FX2LP
ezusb: add functions for firmware download
ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

-- 
René Bürgel

SOHARD Embedded Systems GmbH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gmux: Fix backlight set function

2012-09-13 Thread Grant Likely

In commit 7e30ed6b, "gmux: Add generic write32 function", the new
gmux_write32() function didn't include the io offset when writing
registers. This means that backlight update writes never go to the right
place. This patch fixes it.

Tested on Apple Macbook 8,3

Signed-off-by: Grant Likely 
Cc: Matthew Garrett 
---
 drivers/platform/x86/apple-gmux.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index dfb1a92..ee21056 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -101,7 +101,7 @@ static void gmux_pio_write32(struct apple_gmux_data 
*gmux_data, int port,
 
for (i = 0; i < 4; i++) {
tmpval = (val >> (i * 8)) & 0xff;
-   outb(tmpval, port + i);
+   outb(tmpval, gmux_data->iostart + port + i);
}
 }
 
-- 
1.7.9.5

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

Re: [PATCH v2 0/4]: ezusb cleanup, FX2 support, firmware downloading support

This patch removes the dependency on the usb_serial interface and names 
some magic constants

Signed-off-by: René Bürgel 
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 800e8eb..3048b52d 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -9,24 +9,24 @@
  */
 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 /* EZ-USB Control and Status Register.  Bit 0 controls 8051 reset */
 #define CPUCS_REG0x7F92
 
-int ezusb_writememory(struct usb_serial *serial, int address,
+/* Command for writing to internal memory */
+#define WRITE_INT_RAM 0xA0
+
+int ezusb_writememory(struct usb_device *dev, int address,
unsigned char *data, int length, __u8 request)
 {
int result;
unsigned char *transfer_buffer;
 
-   if (!serial->dev) {
+   if (!dev) {
printk(KERN_ERR "ezusb: %s - no physical device present, "
   "failing.\n", __func__);
return -ENODEV;
@@ -34,25 +34,25 @@ int ezusb_writememory(struct usb_serial *serial, int 
address,
 
transfer_buffer = kmemdup(data, length, GFP_KERNEL);
if (!transfer_buffer) {
-   dev_err(>dev->dev, "%s - kmalloc(%d) failed.\n",
+   dev_err(>dev, "%s - kmalloc(%d) failed.\n",
__func__, length);
return -ENOMEM;
}
-   result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
-request, 0x40, address, 0, transfer_buffer, length, 3000);
+   result = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
+USB_DIR_OUT | USB_TYPE_VENDOR | 
USB_RECIP_DEVICE,
+address, 0, transfer_buffer, length, 3000);
+
kfree(transfer_buffer);
return result;
 }
 EXPORT_SYMBOL_GPL(ezusb_writememory);
 
-int ezusb_set_reset(struct usb_serial *serial, unsigned char reset_bit)
+int ezusb_set_reset(struct usb_device *dev, unsigned char reset_bit)
 {
-   int response;
-
-   response = ezusb_writememory(serial, CPUCS_REG, _bit, 1, 0xa0);
+   int response = ezusb_writememory(dev, CPUCS_REG, _bit, 1, 
WRITE_INT_RAM);
if (response < 0)
-   dev_err(>dev->dev, "%s- %d failed\n",
-   __func__, reset_bit);
+   dev_err(>dev, "%s-%d failed: %d\n",
+   __func__, reset_bit, response);
return response;
 }
 EXPORT_SYMBOL_GPL(ezusb_set_reset);
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index af0b70e..f0d4f3f 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -1241,12 +1241,12 @@ static int keyspan_fake_startup(struct usb_serial 
*serial)
dbg("Uploading Keyspan %s firmware.", fw_name);
 
/* download the firmware image */
-   response = ezusb_set_reset(serial, 1);
+   response = ezusb_set_reset(serial->dev, 1);
 
record = (const struct ihex_binrec *)fw->data;
 
while (record) {
-   response = ezusb_writememory(serial, be32_to_cpu(record->addr),
+   response = ezusb_writememory(serial->dev, 
be32_to_cpu(record->addr),
 (unsigned char *)record->data,
 be16_to_cpu(record->len), 0xa0);
if (response < 0) {
@@ -1260,7 +1260,7 @@ static int keyspan_fake_startup(struct usb_serial *serial)
release_firmware(fw);
/* bring device out of reset. Renumeration will occur in a
   moment and the new device will bind to the real driver */
-   response = ezusb_set_reset(serial, 0);
+   response = ezusb_set_reset(serial->dev, 0);
 
/* we don't want this device to have a driver assigned to it. */
return 1;
diff --git a/drivers/usb/serial/keyspan_pda.c b/drivers/usb/serial/keyspan_pda.c
index a4ac3cf..1290b6f 100644
--- a/drivers/usb/serial/keyspan_pda.c
+++ b/drivers/usb/serial/keyspan_pda.c
@@ -682,7 +682,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
const struct firmware *fw;
 
/* download the firmware here ... */
-   response = ezusb_set_reset(serial, 1);
+   response = ezusb_set_reset(serial->dev, 1);
 
if (0) { ; }
 #ifdef KEYSPAN
@@ -707,7 +707,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
record = (const struct ihex_binrec *)fw->data;
 
while (record) {
-   response = ezusb_writememory(serial, be32_to_cpu(record->addr),
+   response = ezusb_writememory(serial->dev, 
be32_to_cpu(record->addr),
 (unsigned char *)record->data,
 be16_to_cpu(record->len), 0xa0);
if

[PATCH 1/4]: ezusb: remove dependency to usb_serial interface

This patch removes the dependency on the usb_serial interface and names 
some magic constants

Signed-off-by: René Bürgel 
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 800e8eb..3048b52d 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -9,24 +9,24 @@
  */
 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 /* EZ-USB Control and Status Register.  Bit 0 controls 8051 reset */
 #define CPUCS_REG0x7F92
 
-int ezusb_writememory(struct usb_serial *serial, int address,
+/* Command for writing to internal memory */
+#define WRITE_INT_RAM 0xA0
+
+int ezusb_writememory(struct usb_device *dev, int address,
unsigned char *data, int length, __u8 request)
 {
int result;
unsigned char *transfer_buffer;
 
-   if (!serial->dev) {
+   if (!dev) {
printk(KERN_ERR "ezusb: %s - no physical device present, "
   "failing.\n", __func__);
return -ENODEV;
@@ -34,25 +34,25 @@ int ezusb_writememory(struct usb_serial *serial, int 
address,
 
transfer_buffer = kmemdup(data, length, GFP_KERNEL);
if (!transfer_buffer) {
-   dev_err(>dev->dev, "%s - kmalloc(%d) failed.\n",
+   dev_err(>dev, "%s - kmalloc(%d) failed.\n",
__func__, length);
return -ENOMEM;
}
-   result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
-request, 0x40, address, 0, transfer_buffer, length, 3000);
+   result = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
+USB_DIR_OUT | USB_TYPE_VENDOR | 
USB_RECIP_DEVICE,
+address, 0, transfer_buffer, length, 3000);
+
kfree(transfer_buffer);
return result;
 }
 EXPORT_SYMBOL_GPL(ezusb_writememory);
 
-int ezusb_set_reset(struct usb_serial *serial, unsigned char reset_bit)
+int ezusb_set_reset(struct usb_device *dev, unsigned char reset_bit)
 {
-   int response;
-
-   response = ezusb_writememory(serial, CPUCS_REG, _bit, 1, 0xa0);
+   int response = ezusb_writememory(dev, CPUCS_REG, _bit, 1, 
WRITE_INT_RAM);
if (response < 0)
-   dev_err(>dev->dev, "%s- %d failed\n",
-   __func__, reset_bit);
+   dev_err(>dev, "%s-%d failed: %d\n",
+   __func__, reset_bit, response);
return response;
 }
 EXPORT_SYMBOL_GPL(ezusb_set_reset);
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index af0b70e..f0d4f3f 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -1241,12 +1241,12 @@ static int keyspan_fake_startup(struct usb_serial 
*serial)
dbg("Uploading Keyspan %s firmware.", fw_name);
 
/* download the firmware image */
-   response = ezusb_set_reset(serial, 1);
+   response = ezusb_set_reset(serial->dev, 1);
 
record = (const struct ihex_binrec *)fw->data;
 
while (record) {
-   response = ezusb_writememory(serial, be32_to_cpu(record->addr),
+   response = ezusb_writememory(serial->dev, 
be32_to_cpu(record->addr),
 (unsigned char *)record->data,
 be16_to_cpu(record->len), 0xa0);
if (response < 0) {
@@ -1260,7 +1260,7 @@ static int keyspan_fake_startup(struct usb_serial *serial)
release_firmware(fw);
/* bring device out of reset. Renumeration will occur in a
   moment and the new device will bind to the real driver */
-   response = ezusb_set_reset(serial, 0);
+   response = ezusb_set_reset(serial->dev, 0);
 
/* we don't want this device to have a driver assigned to it. */
return 1;
diff --git a/drivers/usb/serial/keyspan_pda.c b/drivers/usb/serial/keyspan_pda.c
index a4ac3cf..1290b6f 100644
--- a/drivers/usb/serial/keyspan_pda.c
+++ b/drivers/usb/serial/keyspan_pda.c
@@ -682,7 +682,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
const struct firmware *fw;
 
/* download the firmware here ... */
-   response = ezusb_set_reset(serial, 1);
+   response = ezusb_set_reset(serial->dev, 1);
 
if (0) { ; }
 #ifdef KEYSPAN
@@ -707,7 +707,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
record = (const struct ihex_binrec *)fw->data;
 
while (record) {
-   response = ezusb_writememory(serial, be32_to_cpu(record->addr),
+   response = ezusb_writememory(serial->dev, 
be32_to_cpu(record->addr),
 (unsigned char *)record->data,
 be16_to_cpu(record->len), 0xa0);
if

[PATCH v2 0/4]: ezusb cleanup, FX2 support, firmware downloading support

Hello,

this is V2 of a patches-series for controllers using the ezusb-functions.

ezusb: remove dependency to usb_serial interface
euzsb: add support for Cypress FX2LP
ezusb: add functions for firmware download
ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

--
René Bürgel

SOHARD Embedded Systems GmbH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: Documentation change for inkern interface.

2012-09-13 Thread Jonathan Cameron

On 09/08/2012 08:42 PM, anish kumar wrote:
> From: anish kumar 
> 
> This commit- 314be14bb renamed the _st_ functions to loose the bit
> that was meant for staging version but forgot to change
> the documentation which still have _st_ sprinkled in some of the
> places.
> 
> Signed-off-by: anish kumar 
merge to togreg branch of

git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git

> ---
>  drivers/staging/iio/Documentation/inkernel.txt |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/iio/Documentation/inkernel.txt 
> b/drivers/staging/iio/Documentation/inkernel.txt
> index a05823e..ab52840 100644
> --- a/drivers/staging/iio/Documentation/inkernel.txt
> +++ b/drivers/staging/iio/Documentation/inkernel.txt
> @@ -48,11 +48,11 @@ There are then a number of functions that can be used to 
> get information
>  about this channel such as it's current reading.
>  
>  e.g.
> -iio_st_read_channel_raw() - get a reading
> -iio_st_read_channel_type() - get the type of channel
> +iio_read_channel_raw() - get a reading
> +iio_get_channel_type() - get the type of channel
>  
>  There is also provision for retrieving all of the channels associated
>  with a given consumer.  This is useful for generic drivers such as
>  iio_hwmon where the number and naming of channels is not known by the
> -consumer driver.  To do this, use iio_st_channel_get_all.
> +consumer driver.  To do this, use iio_channel_get_all.
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/4]: ezusb cleanup, FX2 support, firmware downloading support

This patch removes the dependency on the usb_serial interface and names 
some magic constants

Signed-off-by: René Bürgel 
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 800e8eb..3048b52d 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -9,24 +9,24 @@
  */
 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 
 /* EZ-USB Control and Status Register.  Bit 0 controls 8051 reset */
 #define CPUCS_REG0x7F92
 
-int ezusb_writememory(struct usb_serial *serial, int address,
+/* Command for writing to internal memory */
+#define WRITE_INT_RAM 0xA0
+
+int ezusb_writememory(struct usb_device *dev, int address,
unsigned char *data, int length, __u8 request)
 {
int result;
unsigned char *transfer_buffer;
 
-   if (!serial->dev) {
+   if (!dev) {
printk(KERN_ERR "ezusb: %s - no physical device present, "
   "failing.\n", __func__);
return -ENODEV;
@@ -34,25 +34,25 @@ int ezusb_writememory(struct usb_serial *serial, int 
address,
 
transfer_buffer = kmemdup(data, length, GFP_KERNEL);
if (!transfer_buffer) {
-   dev_err(>dev->dev, "%s - kmalloc(%d) failed.\n",
+   dev_err(>dev, "%s - kmalloc(%d) failed.\n",
__func__, length);
return -ENOMEM;
}
-   result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
-request, 0x40, address, 0, transfer_buffer, length, 3000);
+   result = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
+USB_DIR_OUT | USB_TYPE_VENDOR | 
USB_RECIP_DEVICE,
+address, 0, transfer_buffer, length, 3000);
+
kfree(transfer_buffer);
return result;
 }
 EXPORT_SYMBOL_GPL(ezusb_writememory);
 
-int ezusb_set_reset(struct usb_serial *serial, unsigned char reset_bit)
+int ezusb_set_reset(struct usb_device *dev, unsigned char reset_bit)
 {
-   int response;
-
-   response = ezusb_writememory(serial, CPUCS_REG, _bit, 1, 0xa0);
+   int response = ezusb_writememory(dev, CPUCS_REG, _bit, 1, 
WRITE_INT_RAM);
if (response < 0)
-   dev_err(>dev->dev, "%s- %d failed\n",
-   __func__, reset_bit);
+   dev_err(>dev, "%s-%d failed: %d\n",
+   __func__, reset_bit, response);
return response;
 }
 EXPORT_SYMBOL_GPL(ezusb_set_reset);
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index af0b70e..f0d4f3f 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -1241,12 +1241,12 @@ static int keyspan_fake_startup(struct usb_serial 
*serial)
dbg("Uploading Keyspan %s firmware.", fw_name);
 
/* download the firmware image */
-   response = ezusb_set_reset(serial, 1);
+   response = ezusb_set_reset(serial->dev, 1);
 
record = (const struct ihex_binrec *)fw->data;
 
while (record) {
-   response = ezusb_writememory(serial, be32_to_cpu(record->addr),
+   response = ezusb_writememory(serial->dev, 
be32_to_cpu(record->addr),
 (unsigned char *)record->data,
 be16_to_cpu(record->len), 0xa0);
if (response < 0) {
@@ -1260,7 +1260,7 @@ static int keyspan_fake_startup(struct usb_serial *serial)
release_firmware(fw);
/* bring device out of reset. Renumeration will occur in a
   moment and the new device will bind to the real driver */
-   response = ezusb_set_reset(serial, 0);
+   response = ezusb_set_reset(serial->dev, 0);
 
/* we don't want this device to have a driver assigned to it. */
return 1;
diff --git a/drivers/usb/serial/keyspan_pda.c b/drivers/usb/serial/keyspan_pda.c
index a4ac3cf..1290b6f 100644
--- a/drivers/usb/serial/keyspan_pda.c
+++ b/drivers/usb/serial/keyspan_pda.c
@@ -682,7 +682,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
const struct firmware *fw;
 
/* download the firmware here ... */
-   response = ezusb_set_reset(serial, 1);
+   response = ezusb_set_reset(serial->dev, 1);
 
if (0) { ; }
 #ifdef KEYSPAN
@@ -707,7 +707,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
record = (const struct ihex_binrec *)fw->data;
 
while (record) {
-   response = ezusb_writememory(serial, be32_to_cpu(record->addr),
+   response = ezusb_writememory(serial->dev, 
be32_to_cpu(record->addr),
 (unsigned char *)record->data,
 be16_to_cpu(record->len), 0xa0);
if

Re: [PATCH v3 09/31] arm64: Cache maintenance routines

2012-09-13 Thread Simon Baatz

On Thu, Sep 13, 2012 at 01:38:50PM +0100, Catalin Marinas wrote:
> On Wed, Sep 12, 2012 at 10:55:54PM +0100, Simon Baatz wrote:
> > On Wed, Sep 12, 2012 at 10:29:54AM +0100, Catalin Marinas wrote:
> ...
> 
> > In case of direct I/O (and probably also in other cases like SG_IO)
> > the block layer will see pages from get_user_pages() directly, i.e.
> > also anonymous pages. Many drivers (especially emulated storage
> > drivers like dm-crypt) use flush_dcache_page() after modifying a
> > page. Although flush_dcache_page() is not even supposed to handle
> > anonymous pages, it flushes the kernel mapping of the page because of
> > this code line and everything is well on aliasing D-caches.
> 
> According to the cachetlb.txt document (though not sure architecture
> ports follow it entirely), flush_dcache_page() deliberately shouldn't
> follow anonymous pages. But it seems that we do it on ARM (maybe as an
> alternative to flush_kernel_dcache_page()).
> 
> > Back to arm64 (and possibly to arm with non-aliasing D-caches?), this
> > also means that the saved D-cache flush in the anonymous page case is
> > not only a slight improvement on clarity, but may avoid a
> > considerable number of D-cache flushes in some I/O situations.  (If
> > it is still correct that there are no problems with the I-cache for
> > this use case.)
> 
> The I-cache would be needed if the kernel modifies an executable user
> page. But I don't see a case for this yet. So with non-aliasing D-cache
> the flush_kernel_dcache_page() can be a nop.

Ok, this is true for anon pages. But, if we really need to do the D/I
flush for user mapped page cache pages in flush_dcache_page() then it
should also be done by flush_kernel_dcache_page().  In general, both
flush_dcache_page() and flush_kernel_dcache_page() need to handle the
case in which the kernel modifies such a page. (This means that in
effect, both functions should be the same in the arm64 case.)

> > If now we could additionally avoid to flush the entire I-cache for
> > every page in direct I/O operations with user mapped page cache
> > pages (e.g. direct I/O read into an mmap region)...
> 
> If the page is already mapped, we don't have a later hook to be able to
> flush the caches, so we do it here. We can avoid the I-cache operation
> only if we are sure that the user would not execute code from such page.
> IOW the direct I/O wouldn't write any instructions.
> 
> The powerpc implementation of flush_dcache_page() doesn't even check for
> the existence of a mapping, it always marks the page as dirty. We can do
> the same on arm64 (only leave the clear_bit part of the condition) as
> long as we know that the kernel wouldn't write new code into a page that
> is already mapped.

Yes, but how do we know?


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

[PATCH v2 2/4]: add support for Cypress FX2LP

This Patch adds support for the newer Cypress FX2LP. It also adapts 
three drivers currently using ezusb to the interface change. (whiteheat 
and keyspan[_pda])

Signed-off-by: René Bürgel 
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 3048b52d..351988d 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -14,11 +14,25 @@
 #include 
 #include 
 
-/* EZ-USB Control and Status Register.  Bit 0 controls 8051 reset */
-#define CPUCS_REG0x7F92
+struct ezusb_fx_type {
+   /* EZ-USB Control and Status Register.  Bit 0 controls 8051 reset */
+   unsigned short cpucs_reg;
+   unsigned short max_internal_adress;
+};
 
-/* Command for writing to internal memory */
+struct ezusb_fx_type ezusb_fx1 = {
+   .cpucs_reg = 0x7F92,
+   .max_internal_adress = 0x1B3F,
+};
+
+struct ezusb_fx_type ezusb_fx2 = {
+   .cpucs_reg = 0xE600,
+   .max_internal_adress = 0x3FFF,
+};
+
+/* Commands for writing to memory */
 #define WRITE_INT_RAM 0xA0
+#define WRITE_EXT_RAM 0xA3
 
 int ezusb_writememory(struct usb_device *dev, int address,
unsigned char *data, int length, __u8 request)
@@ -47,13 +61,24 @@ int ezusb_writememory(struct usb_device *dev, int address,
 }
 EXPORT_SYMBOL_GPL(ezusb_writememory);
 
-int ezusb_set_reset(struct usb_device *dev, unsigned char reset_bit)
+int ezusb_set_reset(struct usb_device *dev, unsigned short cpucs_reg,
+unsigned char reset_bit)
 {
-   int response = ezusb_writememory(dev, CPUCS_REG, _bit, 1, 
WRITE_INT_RAM);
+   int response = ezusb_writememory(dev, cpucs_reg, _bit, 1, 
WRITE_INT_RAM);
if (response < 0)
dev_err(>dev, "%s-%d failed: %d\n",
__func__, reset_bit, response);
return response;
 }
-EXPORT_SYMBOL_GPL(ezusb_set_reset);
 
+int ezusb_fx1_set_reset(struct usb_device *dev, unsigned char reset_bit)
+{
+   return ezusb_set_reset(dev, ezusb_fx1.cpucs_reg, reset_bit);
+}
+EXPORT_SYMBOL_GPL(ezusb_fx1_set_reset);
+
+int ezusb_fx2_set_reset(struct usb_device *dev, unsigned char reset_bit)
+{
+   return ezusb_set_reset(dev, ezusb_fx2.cpucs_reg, reset_bit);
+}
+EXPORT_SYMBOL_GPL(ezusb_fx2_set_reset);
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index f0d4f3f..32bebde 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "keyspan.h"
 
 static bool debug;
@@ -1241,7 +1242,7 @@ static int keyspan_fake_startup(struct usb_serial *serial)
dbg("Uploading Keyspan %s firmware.", fw_name);
 
/* download the firmware image */
-   response = ezusb_set_reset(serial->dev, 1);
+   response = ezusb_fx1_set_reset(serial->dev, 1);
 
record = (const struct ihex_binrec *)fw->data;
 
@@ -1260,7 +1261,7 @@ static int keyspan_fake_startup(struct usb_serial *serial)
release_firmware(fw);
/* bring device out of reset. Renumeration will occur in a
   moment and the new device will bind to the real driver */
-   response = ezusb_set_reset(serial->dev, 0);
+   response = ezusb_fx1_set_reset(serial->dev, 0);
 
/* we don't want this device to have a driver assigned to it. */
return 1;
diff --git a/drivers/usb/serial/keyspan_pda.c b/drivers/usb/serial/keyspan_pda.c
index 1290b6f..87c5812 100644
--- a/drivers/usb/serial/keyspan_pda.c
+++ b/drivers/usb/serial/keyspan_pda.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static bool debug;
 
@@ -682,7 +683,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
const struct firmware *fw;
 
/* download the firmware here ... */
-   response = ezusb_set_reset(serial->dev, 1);
+   response = ezusb_fx1_set_reset(serial->dev, 1);
 
if (0) { ; }
 #ifdef KEYSPAN
@@ -722,7 +723,7 @@ static int keyspan_pda_fake_startup(struct usb_serial 
*serial)
release_firmware(fw);
/* bring device out of reset. Renumeration will occur in a moment
   and the new device will bind to the real driver */
-   response = ezusb_set_reset(serial->dev, 0);
+   response = ezusb_fx1_set_reset(serial->dev, 0);
 
/* we want this device to fail to have a driver assigned to it. */
return 1;
diff --git a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c
index fc72591..228eb64 100644
--- a/drivers/usb/serial/whiteheat.c
+++ b/drivers/usb/serial/whiteheat.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "whiteheat.h" /* WhiteHEAT specific commands */
@@ -213,7 +214,7 @@ static int whiteheat_firmware_download(struct usb_serial 
*serial,
goto out;
}
ret = 0;
-   response = ezusb_set_reset(serial->dev, 1);
+   response =

Re: [PATCH v2 3/4]: add functions for firmware download

This patch adds new functions to upload firmware to the controller. The 
drivers currently using ezusb are adapted to use these new functions.

This also fixes a bug occuring during firmware loading in the 
whiteheat-driver:
The driver iterates over an ihex-formatted firmware using ++ on a "const 
struct ihex_binrec*" which leads to faulty results, because ihex data is 
read as length. The function "ihex_next_binrec(record)" has so be used 
to work correctly

Signed-off-by: René Bürgel 
--
diff --git a/drivers/usb/serial/ezusb.c b/drivers/usb/serial/ezusb.c
index 351988d..867a3e1 100644
--- a/drivers/usb/serial/ezusb.c
+++ b/drivers/usb/serial/ezusb.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 struct ezusb_fx_type {
/* EZ-USB Control and Status Register.  Bit 0 controls 8051 reset */
@@ -82,3 +84,80 @@ int ezusb_fx2_set_reset(struct usb_device *dev, unsigned 
char reset_bit)
return ezusb_set_reset(dev, ezusb_fx2.cpucs_reg, reset_bit);
 }
 EXPORT_SYMBOL_GPL(ezusb_fx2_set_reset);
+
+static int ezusb_ihex_firmware_download(struct usb_device *dev,
+   struct ezusb_fx_type fx,
+   const char *firmware_path)
+{
+   int ret = -ENOENT;
+   const struct firmware *firmware = NULL;
+   const struct ihex_binrec *record;
+
+   if (request_ihex_firmware(, firmware_path,
+ >dev)) {
+   dev_err(>dev,
+   "%s - request \"%s\" failed\n",
+   __func__, firmware_path);
+   goto out;
+   }
+
+   ret = ezusb_set_reset(dev, fx.cpucs_reg, 0);
+   if (ret < 0)
+   goto out;
+
+   record = (const struct ihex_binrec *)firmware->data;
+   for (; record; record = ihex_next_binrec(record)) {
+   if (be32_to_cpu(record->addr) > fx.max_internal_adress) {
+   ret = ezusb_writememory(dev, be32_to_cpu(record->addr),
+   (unsigned char *)record->data,
+   be16_to_cpu(record->len), 
WRITE_EXT_RAM);
+   if (ret < 0) {
+   dev_err(>dev, "%s - ezusb_writememory "
+   "failed writing internal memory "
+   "(%d %04X %p %d)\n", __func__, ret,
+   be32_to_cpu(record->addr), record->data,
+   be16_to_cpu(record->len));
+   goto out;
+   }
+   }
+   }
+
+   ret = ezusb_set_reset(dev, fx.cpucs_reg, 1);
+   if (ret < 0)
+   goto out;
+   record = (const struct ihex_binrec *)firmware->data;
+   for (; record; record = ihex_next_binrec(record)) {
+   if (be32_to_cpu(record->addr) <= fx.max_internal_adress) {
+   ret = ezusb_writememory(dev, be32_to_cpu(record->addr),
+   (unsigned char *)record->data,
+   be16_to_cpu(record->len), 
WRITE_INT_RAM);
+   if (ret < 0) {
+   dev_err(>dev, "%s - ezusb_writememory "
+   "failed writing external memory "
+   "(%d %04X %p %d)\n", __func__, ret,
+   be32_to_cpu(record->addr), record->data,
+   be16_to_cpu(record->len));
+   goto out;
+   }
+   }
+   }
+   ret = ezusb_set_reset(dev, fx.cpucs_reg, 0);
+out:
+   release_firmware(firmware);
+   return ret;
+}
+
+int ezusb_fx1_ihex_firmware_download(struct usb_device *dev,
+const char *firmware_path)
+{
+   return ezusb_ihex_firmware_download(dev, ezusb_fx1, firmware_path);
+}
+EXPORT_SYMBOL_GPL(ezusb_fx1_ihex_firmware_download);
+
+int ezusb_fx2_ihex_firmware_download(struct usb_device *dev,
+const char *firmware_path)
+{
+   return ezusb_ihex_firmware_download(dev, ezusb_fx2, firmware_path);
+}
+EXPORT_SYMBOL_GPL(ezusb_fx2_ihex_firmware_download);
+
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 32bebde..523586d 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -38,8 +38,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -1163,10 +1161,7 @@ static void keyspan_close(struct usb_serial_port *port)
 /* download the firmware to a pre-renumeration device */
 static int keyspan_fake_startup(struct usb_serial *serial)
 {
-   int response;
-   const struct ihex_binrec*record;
-   char

Re: [v3 PATCH 1/2] netprio_cgroup: Remove update_netdev_tables() since it is unnecessary

From: "Srivatsa S. Bhat" 
Date: Thu, 13 Sep 2012 12:02:25 +0530

> The update_netdev_tables() function appears to be unnecessary, since the
> write_update_netdev_table() function will adjust the priomaps as and when
> required anyway. So drop the usage of update_netdev_tables() entirely.
> 
> Signed-off-by: Srivatsa S. Bhat 

Applied to net-next
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v3 PATCH 2/2] netprio_cgroup: Use memcpy instead of the for-loop to copy priomap

From: "Srivatsa S. Bhat" 
Date: Thu, 13 Sep 2012 12:02:34 +0530

> Replace the current (inefficient) for-loop with memcpy, to copy priomap.
> 
> Signed-off-by: Srivatsa S. Bhat 

Applied to net-next
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4]: ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc

This patch moves drivers/usb/serial/ezusb.c to drivers/usb/misc/and
adapts Makefiles and Kconfigs

Signed-off-by: René Bürgel 
--
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 1bfcd02..1c63b54 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -244,3 +244,7 @@ config USB_YUREX
  To compile this driver as a module, choose M here: the
  module will be called yurex.
 
+config USB_EZUSB
+   bool "Functions for loading firmware on EZUSB chips"
+   help
+   Say Y here if you need EZUSB device support.
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 796ce7e..f1f7815 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_USB_CYPRESS_CY7C63)  += cypress_cy7c63.o
 obj-$(CONFIG_USB_CYTHERM)  += cytherm.o
 obj-$(CONFIG_USB_EMI26)+= emi26.o
 obj-$(CONFIG_USB_EMI62)+= emi62.o
+obj-$(CONFIG_USB_EZUSB)+= ezusb.o
 obj-$(CONFIG_USB_FTDI_ELAN)+= ftdi-elan.o
 obj-$(CONFIG_USB_IDMOUSE)  += idmouse.o
 obj-$(CONFIG_USB_IOWARRIOR)+= iowarrior.o
diff --git a/drivers/usb/misc/ezusb.c b/drivers/usb/misc/ezusb.c
new file mode 100644
index 000..867a3e1
--- /dev/null
+++ b/drivers/usb/misc/ezusb.c
@@ -0,0 +1,163 @@
+/*
+ * EZ-USB specific functions used by some of the USB to Serial drivers.
+ *
+ * Copyright (C) 1999 - 2002 Greg Kroah-Hartman (g...@kroah.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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct ezusb_fx_type {
+   /* EZ-USB Control and Status Register.  Bit 0 controls 8051 reset */
+   unsigned short cpucs_reg;
+   unsigned short max_internal_adress;
+};
+
+struct ezusb_fx_type ezusb_fx1 = {
+   .cpucs_reg = 0x7F92,
+   .max_internal_adress = 0x1B3F,
+};
+
+struct ezusb_fx_type ezusb_fx2 = {
+   .cpucs_reg = 0xE600,
+   .max_internal_adress = 0x3FFF,
+};
+
+/* Commands for writing to memory */
+#define WRITE_INT_RAM 0xA0
+#define WRITE_EXT_RAM 0xA3
+
+int ezusb_writememory(struct usb_device *dev, int address,
+   unsigned char *data, int length, __u8 request)
+{
+   int result;
+   unsigned char *transfer_buffer;
+
+   if (!dev) {
+   printk(KERN_ERR "ezusb: %s - no physical device present, "
+  "failing.\n", __func__);
+   return -ENODEV;
+   }
+
+   transfer_buffer = kmemdup(data, length, GFP_KERNEL);
+   if (!transfer_buffer) {
+   dev_err(>dev, "%s - kmalloc(%d) failed.\n",
+   __func__, length);
+   return -ENOMEM;
+   }
+   result = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,
+USB_DIR_OUT | USB_TYPE_VENDOR | 
USB_RECIP_DEVICE,
+address, 0, transfer_buffer, length, 3000);
+
+   kfree(transfer_buffer);
+   return result;
+}
+EXPORT_SYMBOL_GPL(ezusb_writememory);
+
+int ezusb_set_reset(struct usb_device *dev, unsigned short cpucs_reg,
+unsigned char reset_bit)
+{
+   int response = ezusb_writememory(dev, cpucs_reg, _bit, 1, 
WRITE_INT_RAM);
+   if (response < 0)
+   dev_err(>dev, "%s-%d failed: %d\n",
+   __func__, reset_bit, response);
+   return response;
+}
+
+int ezusb_fx1_set_reset(struct usb_device *dev, unsigned char reset_bit)
+{
+   return ezusb_set_reset(dev, ezusb_fx1.cpucs_reg, reset_bit);
+}
+EXPORT_SYMBOL_GPL(ezusb_fx1_set_reset);
+
+int ezusb_fx2_set_reset(struct usb_device *dev, unsigned char reset_bit)
+{
+   return ezusb_set_reset(dev, ezusb_fx2.cpucs_reg, reset_bit);
+}
+EXPORT_SYMBOL_GPL(ezusb_fx2_set_reset);
+
+static int ezusb_ihex_firmware_download(struct usb_device *dev,
+   struct ezusb_fx_type fx,
+   const char *firmware_path)
+{
+   int ret = -ENOENT;
+   const struct firmware *firmware = NULL;
+   const struct ihex_binrec *record;
+
+   if (request_ihex_firmware(, firmware_path,
+ >dev)) {
+   dev_err(>dev,
+   "%s - request \"%s\" failed\n",
+   __func__, firmware_path);
+   goto out;
+   }
+
+   ret = ezusb_set_reset(dev, fx.cpucs_reg, 0);
+   if (ret < 0)
+   goto out;
+
+   record = (const struct ihex_binrec *)firmware->data;
+   for (; record; record = ihex_next_binrec(record)) {
+   if (be32_to_cpu(record->addr) > fx.max_internal_adress) {
+

[PATCH -mm] enable CONFIG_COMPACTION by default

2012-09-13 Thread Rik van Riel

Now that lumpy reclaim has been removed, compaction is the
only way left to free up contiguous memory areas. It is time
to just enable CONFIG_COMPACTION by default.

Signed-off-by: Rik van Riel 

diff --git a/mm/Kconfig b/mm/Kconfig
index d5c8019..32ea0ef 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -191,6 +191,7 @@ config SPLIT_PTLOCK_CPUS
 # support for memory compaction
 config COMPACTION
bool "Allow for memory compaction"
+   def_bool y
select MIGRATION
depends on MMU
help
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RT 0/2] [ANNOUNCE] 3.0.42-rt64-rc1 stable review

On Thu, 2012-09-13 at 14:52 -0400, Steven Rostedt wrote:

> 
> Note: The patches have not been uploaded to kernel.org yet. I've
> recently changed the subkey that I use to sign the patches as the
> old subkey is about to expire. But unfortunately, kernel.org has
> not updated its key ring, and is refusing my current subkey.
> 
> I have a ticket open with kernel.org to resolve the issue. But until
> then, this mailing is the only place the patches exist.
> 

Issue is solved, patches are up.

-- Steve

> 
> To build 3.0.42-rt64-rc1 directly, the following patches should be applied:
> 
>   http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz
> 
>   http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.42.xz
> 
>   
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.42-rt64-rc1.patch.xz
> 
> You can also build from 3.0.42-rt63 by applying the incremental patch:
> 
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/incr/patch-3.0.42-rt63-rt64-rc1.patch.xz
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4]: ezusb cleanup, FX2 support, firmware downloading support

please ignore this thread, i'm still new to this mailing list stuff :/
I'll do my best to avoid such noise in the future

- Ursprüngliche Mail -
> Hello,
> 
> this is V2 of a patches-series for controllers using the
> ezusb-functions.
> 
> ezusb: remove dependency to usb_serial interface
> euzsb: add support for Cypress FX2LP
> ezusb: add functions for firmware download
> ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc
> 
> --
> René Bürgel
> 
> SOHARD Embedded Systems GmbH
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RT 0/2] [ANNOUNCE] 3.2.28-rt43-rc1 stable review

On Thu, 2012-09-13 at 14:57 -0400, Steven Rostedt wrote:

> 
> Note: The patches have not been uploaded to kernel.org yet. I've
> recently changed the subkey that I use to sign the patches as the
> old subkey is about to expire. But unfortunately, kernel.org has
> not updated its key ring, and is refusing my current subkey.
> 
> I have a ticket open with kernel.org to resolve the issue. But until
> then, this mailing is the only place the patches exist.
> 

Issue is solved, patches are up.

-- Steve


> To build 3.2.28-rt43-rc1 directly, the following patches should be applied:
> 
>   http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz
> 
>   http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.28.xz
> 
>   
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.28-rt43-rc1.patch.xz
> 
> You can also build from 3.2.28-rt42 by applying the incremental patch:
> 
> http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/incr/patch-3.2.28-rt42-rt43-rc1.patch.xz
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf, tools: Stop perf stat -p when profiled process exits v3


On 9/13/12 9:58 AM, Andi Kleen wrote:

From: Andi Kleen 

When counting a process with perf stat -p check if the process died
and exit collection if yes.

v2: Add more checks, handle non -p again. Handle /proc not there.
v3: Handle multi pid case. Fix non /proc error path
Signed-off-by: Andi Kleen 
---
  tools/perf/builtin-stat.c |   14 +-
  1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 861f0ae..b5e7df2 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -536,7 +536,19 @@ static int run_perf_stat(int argc __used, const char 
**argv)
if (WIFSIGNALED(status))
psignal(WTERMSIG(status), argv[0]);
} else {
-   while(!done) sleep(1);
+   char piddir[40];
+   int check_proc = target.pid &&
+access("/proc", X_OK) == 0 &&
+!strchr(target.pid, ',');
+   if (check_proc)
+   snprintf(piddir, sizeof piddir, "/proc/%d",
+atoi(target.pid));
+   while(!done) {
+   sleep(1);
+   if (check_proc && access(piddir, X_OK) < 0 &&
+   errno == ENOENT)
+   break;
+   }
}


I still think this is the wrong approach. A more complete solution would 
monitor all of the targets given by the user. e.g.,


1. create a perf_target__parse_pid - all it needs to do is:
   struct strlist *slist = strlist__new(false, pid_str);
and save that into the target struct. That line is currently done in 
thread_map.c, thread_map__new_by_pid_str() and 
thread_map__new_by_tid_str. Those functions can be altered to take the 
slist instead of the string.


2. create a perf_target__is_alive that runs through each entry in the 
slist (strlist__for_each(pos, slist)) and checks that it still exists. 
As long as 1 target is alive it returns true. If no pid or tid is 
specified it always returns true.


The is_alive function can be used by perf-top, perf-stat and perf-record 
to know that its target has died so it can stop monitoring.



David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gmux: Fix backlight set function

2012-09-13 Thread Seth Forshee

On Thu, Sep 13, 2012 at 09:02:35PM +0100, Grant Likely wrote:
> In commit 7e30ed6b, "gmux: Add generic write32 function", the new
> gmux_write32() function didn't include the io offset when writing
> registers. This means that backlight update writes never go to the right
> place. This patch fixes it.
> 
> Tested on Apple Macbook 8,3
> 
> Signed-off-by: Grant Likely 
> Cc: Matthew Garrett 

I sent a patch for this several weeks ago [1], just waiting for Matthew
to pick it up.

Seth

[1] https://lkml.org/lkml/2012/8/21/721

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf, tools: Stop perf stat -p when profiled process exits v3

2012-09-13 Thread Andi Kleen

> The is_alive function can be used by perf-top, perf-stat and perf-record 
> to know that its target has died so it can stop monitoring.
 
Sorry that's to complicated and overengineered for me.
My simple patch works for me at least. It's not solving world hunger,
but it wasn't intended to do that.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gmux: Fix backlight set function

2012-09-13 Thread Matthew Garrett

Sorry, I am literally catching up on these right now.

-- 
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] gmux: Fix backlight set function

2012-09-13 Thread David Woodhouse

On Thu, 2012-09-13 at 21:02 +0100, Grant Likely wrote:
> In commit 7e30ed6b, "gmux: Add generic write32 function", the new
> gmux_write32() function didn't include the io offset when writing
> registers. This means that backlight update writes never go to the
> right
> place. This patch fixes it.
> 
> Tested on Apple Macbook 8,3 

Aha, thanks. I was going to have to get to that in the next few days.

I also noticed that since updating to the latest kernel and the latest
version of all the patches, I never get Intel graphics output working
after switching. And even the Radeon doesn't work right, if I switch
away and back. X just locks up after a few seconds and the graphics
engine isn't responding.

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] power: battery: Generic battery driver using IIO

2012-09-13 Thread Jonathan Cameron

On 09/13/2012 05:16 PM, anish kumar wrote:
> From: anish kumar 
>
> In this version:
> Addressed concerns raised by lars:
> a. made the adc_bat per device.
> b. get the IIO channel using hardcoded channel names.
Couple of bits related to this inline..

> c. Minor issues related to gpio_is_valid and some code
>refactoring.
>
> Signed-off-by: anish kumar 
> ---
>  drivers/power/generic-adc-battery.c   |  460 
> +
>  include/linux/power/generic-adc-battery.h |   33 ++
>  2 files changed, 493 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/power/generic-adc-battery.c
>  create mode 100644 include/linux/power/generic-adc-battery.h
>
> diff --git a/drivers/power/generic-adc-battery.c 
> b/drivers/power/generic-adc-battery.c
> new file mode 100644
> index 000..003e0e1
> --- /dev/null
> +++ b/drivers/power/generic-adc-battery.c
> @@ -0,0 +1,460 @@
> +/*
> + * Generic battery driver code using IIO
> + * Copyright (C) 2012, Anish Kumar 
> + * based on jz4740-battery.c
> + * based on s3c_adc_battery.c
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file COPYING in the main directory of this archive for
> + * more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define to_generic_bat(ptr)  \
> + container_of(ptr, struct generic_adc_bat, ptr)
> +
> +enum chan_type {
> + VOLTAGE = 0,
> + CURRENT,
> + POWER,
> + MAX_CHAN_TYPE
> +};
> +
> +#define CHAN_MAX_NAME 30
> +/*
> + * channel_name suggests the standard channel names for commonly used
> + * channel types.
> + */
const
> +char channel_name[][CHAN_MAX_NAME + 1] = {
> + [VOLTAGE]   = "voltage",
> + [CURRENT]   = "current",
> + [POWER] = "power",
> +};
> +
> +struct generic_adc_bat {
> + struct power_supply psy;
> + struct iio_channel  **channel;
> + struct iio_battery_platform_data*pdata;
> + struct delayed_work bat_work;
> + int was_plugged;
> + int volt_value;
> + int cur_value;
> + int level;
> + int status;
> + int cable_plugged:1;
> +};
> +
> +static void generic_adc_bat_ext_power_changed(struct power_supply *psy)
> +{
> + struct generic_adc_bat *adc_bat;
> + adc_bat = to_generic_bat(psy);
> +
> + schedule_delayed_work(_bat->bat_work,
> + msecs_to_jiffies(adc_bat->pdata->jitter_delay));
> +}
> +
> +static enum power_supply_property bat_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> + POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN,
> + POWER_SUPPLY_PROP_CHARGE_NOW,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_TECHNOLOGY,
> + POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
> + POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
> + POWER_SUPPLY_PROP_MODEL_NAME,
> +};
> +
> +/*
> + * This properties are set based on the received platform data and this
> + * should correspond one-to-one with enum chan_type.
> + */
> +static enum power_supply_property dyn_props[] = {
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_POWER_NOW,
> +};
> +
> +static int charge_finished(struct generic_adc_bat *adc_bat)
> +{
> + return adc_bat->pdata->gpio_inverted ?
> + !gpio_get_value(adc_bat->pdata->gpio_charge_finished) :
> + gpio_get_value(adc_bat->pdata->gpio_charge_finished);
> +}
> +
> +long read_scale_channel(struct generic_adc_bat *adc_bat,
> + enum power_supply_property psp)
> +{
> + int scaleint, scalepart, iio_val, ret = 0;
> + int result = 0;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_POWER_NOW:
> + ret = iio_read_channel_raw(adc_bat->channel[POWER],
> + _val);
> + ret = iio_read_channel_scale(adc_bat->channel[POWER],
> + , );
> + if (ret < 0)
> + return ret;
> + break;
> + case POWER_SUPPLY_PROP_VOLTAGE_NOW:
> + ret = iio_read_channel_raw(adc_bat->channel[VOLTAGE],
> + _val);
> + ret = iio_read_channel_scale(adc_bat->channel[VOLTAGE],
> + , );
> + if (ret < 0)
> + return ret;
> + break;
> + case POWER_SUPPLY_PROP_CURRENT_NOW:
> + ret = iio_read_channel_raw(adc_bat->channel[CURRENT],
> + _val);
> + ret = iio_read_channel_scale(adc_bat->channel[CURRENT],
> + , );
> + if (ret < 0)
> + return ret;
> +

Re: [PATCH -mm] enable CONFIG_COMPACTION by default

2012-09-13 Thread Rafael Aquini

On Thu, Sep 13, 2012 at 04:21:04PM -0400, Rik van Riel wrote:
> Now that lumpy reclaim has been removed, compaction is the
> only way left to free up contiguous memory areas. It is time
> to just enable CONFIG_COMPACTION by default.
> 
> Signed-off-by: Rik van Riel 
> 
> diff --git a/mm/Kconfig b/mm/Kconfig
> index d5c8019..32ea0ef 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -191,6 +191,7 @@ config SPLIT_PTLOCK_CPUS
>  # support for memory compaction
>  config COMPACTION
>   bool "Allow for memory compaction"
> + def_bool y
>   select MIGRATION
>   depends on MMU
>   help
>

Acked-by: Rafael Aquini  

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

Hello, guys.

Here's the write-up I promised last week about what I think are the
problems in cgroup and what the current plans are.

First of all, it's a mess.  Shame on me.  Shame on you.  Shame on all
of us for allowing this mess.  Let's all tremble in shame for solid
ten seconds before proceeding.

I'll list the issues I currently see with cgroup (easier ones first).
I think I now have at least tentative plans for all of them and will
list them together with the prospective asignees (my wish mostly).
Unfortunately, some of the plans involve userland visible changes
which would at least cause some discomfort and require adjustments on
their part.

1. cpu and cpuacct

  They cover the same resources and the scheduler cgroup code ends up
  having to traverse two separate cgroup trees to update the stats.
  With nested cgroups, the overhead isn't insignificant and it
  generally is silly.

  While the use cases for having cpuacct on a separate and likely more
  granular hierarchy, are somewhat valid, the consensus seems that
  it's just not worth the trouble and cpuacct should be removed in the
  long term and we shouldn't allow overlapping controllers for the
  same resource, especially accounting ones.

  Solution:

  * Whine if cpuacct is not co-mounted with cpu.

  * Make sure cpu has all the stats of cpuacct.  If cpu and cpuacct
are comounted, don't really mount cpuacct but tell cpu that the
user requested it.  cpu is updated to create aliases for cpuacct.*
files in such cases.  This involves special casing cpuacct in
cgroup core but I much prefer one-off exception case to adding a
generic mechanism for this.

  * After a while, we can just remove cpuacct completely.

  * Later on, phase out the aliases too.

  Who:

  Me, working on it.

2. memcg's __DEPRECATED_clear_css_refs

  This is a remnant of another weird design decision of requiring
  synchronous draining of refcnts on cgroup removal and allowing
  subsystems to veto cgroup removal - what's the userspace supposed to
  do afterwards?  Note that this also hinders co-mounting different
  controllers.

  The behavior could be useful for development and debugging but it
  unnecessarily interlocks userland visible behavior with in-kernel
  implementation details.  To me, it seems outright wrong (either
  implement proper severing semantics in the controller or do full
  refcnting) and disallows, for example, lazy drain of caching refs.
  Also, it complicates the removal path with try / commit / revert
  logic which has never been fully correct since the beginning.

  Currently, the only left user is memcg.

  Solution:

  * Update memcg->pre_destroy() such that it never fails.

  * Drop __DEPRECATED_clear_css_refs and all related logic.
Convert pre_destroy() to return void.

  Who:

  KAMEZAWA, Michal, PLEASE.  I will make __DEPRECATED_clear_css_refs
  trigger WARN sooner or later.  Let's please get this settled.

3. cgroup_mutex usage outside cgroup core

  This is another thing which is simply broken.  Given the way cgroup
  is structured and used, nesting cgroup_mutex inside any other
  commonly used lock simply doesn't work - it's held while invoking
  controller callbacks which then interact and synchronize with
  various core subsystems.

  There are currently three external cgroup_mutex users - cpuset,
  memcontrol and cgroup_freezer.

  Solution:

  Well, we should just stop doing it - use a separate nested lock
  (which seems possible for cgroup_freezer) or track and mange task
  in/egress some other way.

  Who:

  I'll do the cgroup_freezer.  I'm hoping PeterZ or someone who's
  familiar with the code base takes care of cpuset.  Michal, can you
  please take care of memcg?

4. Make disabled controllers cheaper

  Mostly through the use of static_keys, I suppose.  Making this
  easier AFAICS depends on resolving #2.  The lock dependency loop
  from #2 makes using static_keys from cgroup callbacks extremely
  nasty.

  Solution:

  Fix #2 and support common pattern from cgroup core.

  Who:

  Dunno.  Let's see.

5. I CAN HAZ HIERARCHIES?

  The cpu ones handle nesting correctly - parent's accounting includes
  children's, parent's configuration affects children's unless
  explicitly overridden, and children's limits nest inside parent's.

  memcg asked itself the existential question of to be hierarchical or
  not and then got confused and decided to become both.

  When faced with the same question, blkio and cgroup_freezer just
  gave up and decided to allow nesting and then ignore it - brilliant.

  And there are others which kinda sorta try to handle hierarchy but
  only goes way-half.

  This one is screwed up embarrassingly badly.  We failed to establish
  one of the most basic semantics and can't even define what a cgroup
  hierarchy is - it depends on each controller and they're mostly
  wacky!

  Fortunately, I don't think it will be prohibitively difficult to dig
  ourselves out of this hole.

[PATCH 0/3 v3] perf: precise mode and exclude_guest

Hopefully this wraps up the precise mode-exclude_guest dependency.
I'm sure someone will let me know if I screwed up the attribution
in the second patch.

David Ahern (2):
  perf tool: precise mode requires exclude_guest
  perf tool: give user better message if precise is not supported

Peter Zijlstra (1):
  perf: require exclude_guest to use PEBS - kernel side enforcement

v3: removed extra tab in patch 2
v2: updated commit messages for patches 1 and 2

 arch/x86/kernel/cpu/perf_event.c |6 ++
 tools/perf/builtin-record.c  |5 +
 tools/perf/builtin-top.c |4 
 tools/perf/util/parse-events.c   |3 +++
 4 files changed, 18 insertions(+)

-- 
1.7.10.1

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

[PATCH 1/3] perf tool: precise mode requires exclude_guest

Summary of events per Peter:

  "Intel PEBS in VT-x context uses the DS address as a guest linear address,
  even though its programmed by the host as a host linear address. This
  either results in guest memory corruption and or the hardware faulting and
  'crashing' the virtual machine.  Therefore we have to disable PEBS on VT-x
  enter and re-enable on VT-x exit, enforcing a strict exclude_guest.

  AMB IBS does work but doesn't currently support exclude_* at all,
  setting an exclude_* bit will make it fail."

This patch handles userspace perf command, setting the exclude_guest
attribute if precise mode is requested, but only if a user has not
specified a request for guest or host only profiling (G or H attribute).

Kernel side AMD currently ignores all exclude_* bits, so there is no impact
to existing IBS code paths. Robert Richter has a patch where IBS code will
return EINVAL if an exclude_* bit is set. When this goes in it means use
of :p on AMD with IBS will first fail with EINVAL (because exclude_guest
will be set). Then the existing fallback code within perf will unset
exclude_guest and try again. The second attempt will succeed if the CPU
supports IBS profiling.

Signed-off-by: David Ahern 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Robert Richter 
Cc: Gleb Natapov 
Cc: Avi Kivity 
Link: https://lkml.org/lkml/2012/7/9/264
---
 tools/perf/util/parse-events.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 44afcf4..696cc7e 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -694,6 +694,9 @@ static int get_event_modifier(struct event_modifier *mod, 
char *str,
eH = 0;
} else if (*str == 'p') {
precise++;
+   /* use of precise requires exclude_guest */
+   if (!exclude_GH)
+   eG = 1;
} else
break;
 
-- 
1.7.10.1

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

[PATCH 3/3 v2] perf tool: give user better message if precise is not supported

Platforms (e.g., VM's) without support for precise mode get a confusing
error message. e.g.,
$ perf record -e cycles:p -a -- sleep 1

  Error: sys_perf_event_open() syscall returned with 95 (Operation not
  supported).  /bin/dmesg may provide additional information.

  No hardware sampling interrupt available. No APIC? If so then you can
  boot the kernel with the "lapic" boot parameter to force-enable it.
  sleep: Terminated

which is not clear that precise mode might be the root problem. With this
patch:

$ perf record -e cycles:p -fo /tmp/perf.data -- sleep 1
  Error:
  'precise' request may not be supported. Try removing 'p' modifier
  sleep: Terminated

v2: softened message to 'may not be' supported per Robert's suggestion

Signed-off-by: David Ahern 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Robert Richter 
---
 tools/perf/builtin-record.c |5 +
 tools/perf/builtin-top.c|4 
 2 files changed, 9 insertions(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index c643ed6..385e272 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -294,6 +294,11 @@ try_again:
  perf_evsel__name(pos));
rc = -err;
goto out;
+   } else if ((err == EOPNOTSUPP) && (attr->precise_ip)) {
+   ui__error("\'precise\' request may not be 
supported. "
+ "Try removing 'p' modifier\n");
+   rc = -err;
+   goto out;
}
 
printf("\n");
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 5550754..1d1c98c 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -976,6 +976,10 @@ try_again:
ui__error("Too many events are opened.\n"
"Try again after reducing the 
number of events\n");
goto out_err;
+   } else if ((err == EOPNOTSUPP) && (attr->precise_ip)) {
+   ui__error("\'precise\' request may not be 
supported. "
+ "Try removing 'p' modifier\n");
+   goto out_err;
}
 
ui__error("The sys_perf_event_open() syscall "
-- 
1.7.10.1

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

Re: [PATCH] memory cgroup: update root memory cgroup when node is onlined

2012-09-13 Thread Johannes Weiner

Hi,

On Thu, Sep 13, 2012 at 03:14:28PM +0800, Wen Congyang wrote:
> root_mem_cgroup->info.nodeinfo is initialized when the system boots.
> But NODE_DATA(nid) is null if the node is not onlined, so
> root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone contains
> an invalid pointer. If we use numactl to bind a program to the node
> after onlining the node and its memory, it will cause the kernel
> panicked:

Is there any chance we could get rid of the zone backpointer in lruvec
again instead?  Adding new nodes is a rare event and so updating every
single memcg in the system might be just borderline crazy.  But can't
we just go back to passing the zone along with the lruvec down
vmscan.c paths?  I agree it's ugly to pass both, given their
relationship.  But I don't think the backpointer is any cleaner but in
addition less robust.

That being said, the crashing code in particular makes me wonder:

static __always_inline void add_page_to_lru_list(struct page *page,
struct lruvec *lruvec, enum lru_list lru)
{
int nr_pages = hpage_nr_pages(page);
mem_cgroup_update_lru_size(lruvec, lru, nr_pages);
list_add(>lru, >lists[lru]);
__mod_zone_page_state(lruvec_zone(lruvec), NR_LRU_BASE + lru, nr_pages);
}

Why did we ever pass zone in here and then felt the need to replace it
with lruvec->zone in fa9add6 "mm/memcg: apply add/del_page to lruvec"?
A page does not roam between zones, its zone is a static property that
can be retrieved with page_zone().

Johannes

> [   63.413436] BUG: unable to handle kernel NULL pointer dereference at 
> 0f60
> [   63.414161] IP: [] __mod_zone_page_state+0x9/0x60
> [   63.414161] PGD 0 
> [   63.414161] Oops:  [#1] SMP 
> [   63.414161] Modules linked in: acpi_memhotplug binfmt_misc dm_mirror 
> dm_region_hash dm_log dm_mod ppdev sg microcode pcspkr virtio_console 
> virtio_balloon snd_intel8x0 snd_ac9
> 7_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd soundcore 
> snd_page_alloc e1000 i2c_piix4 i2c_core floppy parport_pc parport sr_mod 
> cdrom virtio_blk pata_acpi ata_g
> eneric ata_piix libata scsi_mod
> [   63.414161] CPU 2 
> [   63.414161] Pid: 1219, comm: numactl Not tainted 3.6.0-rc5+ #180 Bochs 
> Bochs
> ...
> [   63.414161] Process numactl (pid: 1219, threadinfo 880039abc000, task 
> 8800383c4ce0)
> [   63.414161] Stack:
> [   63.414161]  880039abdaf8 8117390f 880039abdaf8 
> 8167c601
> [   63.414161]  81174162 88003a480f00 0001 
> 8800395e
> [   63.414161]  88003dbd0e80 0282 880039abdb48 
> 81174181
> [   63.414161] Call Trace:
> [   63.414161]  [] __pagevec_lru_add_fn+0xdf/0x140
> [   63.414161]  [] ? pagevec_lru_move_fn+0x92/0x100
> [   63.414161]  [] pagevec_lru_move_fn+0xb1/0x100
> [   63.414161]  [] ? lru_add_page_tail+0x1b0/0x1b0
> [   63.414161]  [] ? exec_mmap+0x121/0x230
> [   63.414161]  [] __pagevec_lru_add+0x1c/0x30
> [   63.414161]  [] lru_add_drain_cpu+0xa3/0x130
> [   63.414161]  [] lru_add_drain+0x2f/0x40
> [   63.414161]  [] exit_mmap+0x69/0x160
> [   63.414161]  [] ? lock_release_holdtime+0x35/0x1a0
> [   63.414161]  [] mmput+0x77/0x100
> [   63.414161]  [] exec_mmap+0x170/0x230
> [   63.414161]  [] flush_old_exec+0xd2/0x140
> [   63.414161]  [] load_elf_binary+0x32a/0xe70
> [   63.414161]  [] ? trace_hardirqs_off+0xd/0x10
> [   63.414161]  [] ? local_clock+0x6f/0x80
> [   63.414161]  [] ? lock_release_holdtime+0x35/0x1a0
> [   63.414161]  [] ? __lock_release+0x133/0x1a0
> [   63.414161]  [] ? search_binary_handler+0x1a7/0x4a0
> [   63.414161]  [] search_binary_handler+0x1b3/0x4a0
> [   63.414161]  [] ? search_binary_handler+0x54/0x4a0
> [   63.414161]  [] ? set_brk+0xe0/0xe0
> [   63.414161]  [] do_execve_common+0x26f/0x320
> [   63.414161]  [] ? kmem_cache_alloc+0x113/0x220
> [   63.414161]  [] do_execve+0x3a/0x40
> [   63.414161]  [] sys_execve+0x4a/0x80
> [   63.414161]  [] stub_execve+0x6c/0xc0
> [   63.414161] Code: ff 03 00 00 48 c1 e7 0b 48 c1 e2 07 48 29 d7 48 03 3c c5 
> c0 27 d2 81 e8 a6 fe ff ff c9 c3 0f 1f 40 00 55 48 89 e5 0f 1f 44 00 00 <48> 
> 8b 4f 60 89 f6 48 8d 44 31 40 65 44 8a 40 02 45 0f be c0 41 
> 
> The reason is that we don't update 
> root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone
> when onlining the node, and we try to access it.
> 
> Signed-off-by: Wen Congyang 
> Reported-by: Tang Chen 
> ---
>  include/linux/memcontrol.h |7 +++
>  mm/memcontrol.c|   14 ++
>  mm/memory_hotplug.c|2 ++
>  3 files changed, 23 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 8d9489f..87d8b77 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -182,6 +182,9 @@ unsigned long mem_cgroup_soft_limit_reclaim(struct zone 
> *zone, int order,
>   unsigned long

[PATCH 2/3] perf: require exclude_guest to use PEBS - kernel side enforcement

From: Peter Zijlstra 

Per Peter:
  "Intel PEBS in VT-x context uses the DS address as a guest linear address,
  even though its programmed by the host as a host linear address. This
  either results in guest memory corruption and or the hardware faulting and
  'crashing' the virtual machine.  Therefore we have to disable PEBS on VT-x
  enter and re-enable on VT-x exit, enforcing a strict exclude_guest.

This patch enforces exclude_guest kernel side.

Signed-off-by: David Ahern 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Robert Richter 
Cc: Gleb Natapov 
Cc: Avi Kivity 
Link: https://lkml.org/lkml/2012/7/9/298
---
 arch/x86/kernel/cpu/perf_event.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
index 915b876..4bc96c5 100644
--- a/arch/x86/kernel/cpu/perf_event.c
+++ b/arch/x86/kernel/cpu/perf_event.c
@@ -338,6 +338,9 @@ int x86_setup_perfctr(struct perf_event *event)
/* BTS is currently only allowed for user-mode. */
if (!attr->exclude_kernel)
return -EOPNOTSUPP;
+
+   if (!attr->exclude_guest)
+   return -EOPNOTSUPP;
}
 
hwc->config |= config;
@@ -380,6 +383,9 @@ int x86_pmu_hw_config(struct perf_event *event)
if (event->attr.precise_ip) {
int precise = 0;
 
+   if (!event->attr.exclude_guest)
+   return -EOPNOTSUPP;
+
/* Support for constant skid */
if (x86_pmu.pebs_active && !x86_pmu.pebs_broken) {
precise++;
-- 
1.7.10.1

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

Re: [PATCH] of: specify initrd location using 64-bit

2012-09-13 Thread Rob Herring

On 09/13/2012 01:47 AM, Sebastian Andrzej Siewior wrote:
> On 09/13/2012 12:08 AM, Rob Herring wrote:
>>> Geert is right here. If it is a physical address, it should be
>>> phys_addr_t.
>>
>> While generally true, for the DT specific code I think it should be a
>> fixed u64. The size of the address is defined by the FDT, not the
>> kernel. It is very likely we could have a FDT that specifies addresses
>> in 64-bit values, but then we boot a kernel is compiled for !LPAE.
>> phys_addr_t is currently sized based on LPAE setting.
> 
> If your kernel is 32bit without PAE and your DTB address is >32ibt than
> you can't handle it. If you don't notice this in your dt code than you
> remap the wrong memory ioremap().

The size of the initrd fields are set by #address-cells properties and
determined when you create the dtb. The address to load the initrd is
decided by the bootloader/user and set at that point later in time. The
dtb should not be tied to the kernel you are booting. Obviously, if you
want to boot a non-PAE kernel, everything has to be placed at <4GB.

I can boot i386 and i386-pae kernels on an i386-pae machines. I expect
to generally be able to do that on ARM. Perhaps some SOCs like this one
will not allow that, it is not always true.

Rob

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf: add /proc/perf_events file for dump perf events info

On 7/5/12 7:02 AM, Jovi Zhang wrote:

  From 91fbcca37a2c9979083f4b9a6fa9c1875fc2886f Mon Sep 17 00:00:00 2001
From: Jovi Zhang 
Date: Fri, 6 Jul 2012 00:05:40 +0800
Subject: [PATCH] perf: add /proc/perf_events file for dump perf events info

This new /proc/perf_events file is used for real time dump all
perf events info in whole system wide machine, this patch also add
a new field perf_entry in struct perf_event, for connect to
global list perf_events_list.

Applied your patch to see if sheds light on a problem. Saw this 
compiling the kernel:

kernel/events/proc_perf_events.c: In function ‘perf_events_proc_show’:
kernel/events/proc_perf_events.c:175:5: warning: format ‘%llu’ expects 
argument of type ‘long long unsigned int’, but argument 3 has type ‘long 
int’ [-Wformat]

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 9/9] drivers/isdn/gigaset/common.c: Remove useless kfree

From: Tilman Schmidt 
Date: Thu, 13 Sep 2012 11:52:27 +0200

> Am 12.09.2012 17:06, schrieb Peter Senna Tschudin:
>> From: Peter Senna Tschudin 
>> 
>> Remove useless kfree() and clean up code related to the removal.
>> 
>> The semantic patch that finds this problem is as follows:
> [...]
>> 
>> Signed-off-by: Peter Senna Tschudin 
> 
> Acked-by: Tilman Schmidt 

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

Re: [PATCH net-next] drivers/net: Enable IOMMU pass through for be2net