[PATCH] arch:arm:mm:Aligning the module end and Correction in

2015-11-16 Thread Shailendra Verma
From: Shailendra Verma 

The module end was not aligned as of module start and boundary
check for module end is not proper.This out of bound value of
module end can produce undesired results.

Reported-by: Hillf Danton 
Signed-off-by: Shailendra Verma 
Reviewed-by: Ravikant Bijendra Sharma 
---
 linux-4.3-rc6/arch/arm/mm/pageattr.c |   11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/linux-4.3-rc6/arch/arm/mm/pageattr.c 
b/linux-4.3-rc6/arch/arm/mm/pageattr.c
index cf30daf..17f103c 100644
--- a/linux-4.3-rc6/arch/arm/mm/pageattr.c
+++ b/linux-4.3-rc6/arch/arm/mm/pageattr.c
@@ -43,16 +43,15 @@ static int change_memory_common(unsigned long addr, int 
numpages,
int ret;
struct page_change_data data;
 
-   if (!IS_ALIGNED(addr, PAGE_SIZE)) {
-   start &= PAGE_MASK;
-   end = start + size;
-   WARN_ON_ONCE(1);
-   }
+   if (WARN_ON_ONCE(!IS_ALIGNED(addr, PAGE_SIZE))) {
+   start &= PAGE_MASK;
+   end = PAGE_ALIGN(end);
+   }
 
if (start < MODULES_VADDR || start >= MODULES_END)
return -EINVAL;
 
-   if (end < MODULES_VADDR || start >= MODULES_END)
+   if (end < MODULES_VADDR || end >= MODULES_END)
return -EINVAL;
 
data.set_mask = set_mask;
-- 
1.7.9.5

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


[PATCH] arch:arm:mm:Aligning the module end address.

2015-11-16 Thread Shailendra Verma
From: Shailendra Verma 

The module end was not aligned as of module start, so
aligning end also.

Signed-off-by: Shailendra Verma 
Reviewed-by: Ravikant Bijendra Sharma 
---
 linux-4.3-rc6/arch/arm64/mm/pageattr.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/linux-4.3-rc6/arch/arm64/mm/pageattr.c 
b/linux-4.3-rc6/arch/arm64/mm/pageattr.c
index e47ed1c..70e7a4c 100644
--- a/linux-4.3-rc6/arch/arm64/mm/pageattr.c
+++ b/linux-4.3-rc6/arch/arm64/mm/pageattr.c
@@ -45,10 +45,9 @@ static int change_memory_common(unsigned long addr, int 
numpages,
int ret;
struct page_change_data data;
 
-   if (!IS_ALIGNED(addr, PAGE_SIZE)) {
+   if (WARN_ON_ONCE(!IS_ALIGNED(addr, PAGE_SIZE))) {
start &= PAGE_MASK;
-   end = start + size;
-   WARN_ON_ONCE(1);
+   end = PAGE_ALIGN(end);
}
 
if (start < MODULES_VADDR || start >= MODULES_END)
-- 
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] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity

2015-11-16 Thread chunfeng yun
Hi,
On Mon, 2015-11-16 at 22:16 -0800, Greg KH wrote:
> On Tue, Nov 17, 2015 at 02:02:58PM +0800, Chunfeng Yun wrote:
> > when use the default value 8 of RG_USB20_SQTH, the HS receiver
> > sensitivity test of HQA will fail, set it as 2 to fix up the
> > issue.
> > 
> > Change-Id: Ia5bdbbfc8ebb170d3ef26007e665b7350b6d28ab
> 
> What is this field for?  Hint, it should never be there for a patch you
> submit upstream as it means nothing...
> 
I'm sorry for forgetting remove it. 
And I will remove change-id in next round after review

Thanks a lot

> greg k-h


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


Re: [PATCH] dmaengine: bcm2835-dma: Convert to use DMA pool

2015-11-16 Thread Peter Ujfalusi
Hi,

On 11/16/2015 01:09 PM, Peter Ujfalusi wrote:
> f93178291712 dmaengine: bcm2835-dma: Fix memory leak when stopping a
>running transfer
> 
> Fixed the memleak, but introduced another issue: the terminate_all callback
> might be called with interrupts disabled and the dma_free_coherent() is
> not allowed to be called when IRQs are disabled.
> Convert the driver to use dma_pool_* for managing the list of control
> blocks for the transfer.

FWIW: the patch has been tested and verified on Raspbery Pi:
https://github.com/raspberrypi/linux/pull/1178#issuecomment-157026794
https://github.com/raspberrypi/linux/pull/1178#issuecomment-157030190

It needed some modification since the Raspberry Pi kernel have non upstreamed
changes in bcm2835-dma driver (slave_sg support for example).

It would be great if this patch can make it to 4.4 as a fix.

Thanks,
Péter

> 
> Fixes: f93178291712 ("dmaengine: bcm2835-dma: Fix memory leak when stopping a 
> running transfer")
> Signed-off-by: Peter Ujfalusi 
> ---
> Hi,
> 
> It was brought to my attention that the memleak fix broke the bcm2835 DMA. I 
> did
> not noticed the use of dma_free_coherent() in the driver when I did the 
> memleak
> fix.
> Since the driver does leaking memory every time the audio is stopped, the 
> other
> option is to convert it to use DMA pool.
> I do not have access the Raspberry Pi, so I can not test this patch but it
> compiles ;)
> Can someone test this one out if it is working?
> 
> Regards,
> Peter
> 
>  drivers/dma/bcm2835-dma.c | 78 
> ---
>  1 file changed, 54 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> index c92d6a70ccf3..996c4b00d323 100644
> --- a/drivers/dma/bcm2835-dma.c
> +++ b/drivers/dma/bcm2835-dma.c
> @@ -31,6 +31,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -62,6 +63,11 @@ struct bcm2835_dma_cb {
>   uint32_t pad[2];
>  };
>  
> +struct bcm2835_cb_entry {
> + struct bcm2835_dma_cb *cb;
> + dma_addr_t paddr;
> +};
> +
>  struct bcm2835_chan {
>   struct virt_dma_chan vc;
>   struct list_head node;
> @@ -72,18 +78,18 @@ struct bcm2835_chan {
>  
>   int ch;
>   struct bcm2835_desc *desc;
> + struct dma_pool *cb_pool;
>  
>   void __iomem *chan_base;
>   int irq_number;
>  };
>  
>  struct bcm2835_desc {
> + struct bcm2835_chan *c;
>   struct virt_dma_desc vd;
>   enum dma_transfer_direction dir;
>  
> - unsigned int control_block_size;
> - struct bcm2835_dma_cb *control_block_base;
> - dma_addr_t control_block_base_phys;
> + struct bcm2835_cb_entry *cb_list;
>  
>   unsigned int frames;
>   size_t size;
> @@ -143,10 +149,13 @@ static inline struct bcm2835_desc *to_bcm2835_dma_desc(
>  static void bcm2835_dma_desc_free(struct virt_dma_desc *vd)
>  {
>   struct bcm2835_desc *desc = container_of(vd, struct bcm2835_desc, vd);
> - dma_free_coherent(desc->vd.tx.chan->device->dev,
> - desc->control_block_size,
> - desc->control_block_base,
> - desc->control_block_base_phys);
> + int i;
> +
> + for (i = 0; i < desc->frames; i++)
> + dma_pool_free(desc->c->cb_pool, desc->cb_list[i].cb,
> +   desc->cb_list[i].paddr);
> +
> + kfree(desc->cb_list);
>   kfree(desc);
>  }
>  
> @@ -199,7 +208,7 @@ static void bcm2835_dma_start_desc(struct bcm2835_chan *c)
>  
>   c->desc = d = to_bcm2835_dma_desc(&vd->tx);
>  
> - writel(d->control_block_base_phys, c->chan_base + BCM2835_DMA_ADDR);
> + writel(d->cb_list[0].paddr, c->chan_base + BCM2835_DMA_ADDR);
>   writel(BCM2835_DMA_ACTIVE, c->chan_base + BCM2835_DMA_CS);
>  }
>  
> @@ -232,9 +241,16 @@ static irqreturn_t bcm2835_dma_callback(int irq, void 
> *data)
>  static int bcm2835_dma_alloc_chan_resources(struct dma_chan *chan)
>  {
>   struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
> + struct device *dev = c->vc.chan.device->dev;
> +
> + dev_dbg(dev, "Allocating DMA channel %d\n", c->ch);
>  
> - dev_dbg(c->vc.chan.device->dev,
> - "Allocating DMA channel %d\n", c->ch);
> + c->cb_pool = dma_pool_create(dev_name(dev), dev,
> +  sizeof(struct bcm2835_dma_cb), 0, 0);
> + if (!c->cb_pool) {
> + dev_err(dev, "unable to allocate descriptor pool\n");
> + return -ENOMEM;
> + }
>  
>   return request_irq(c->irq_number,
>   bcm2835_dma_callback, 0, "DMA IRQ", c);
> @@ -246,6 +262,7 @@ static void bcm2835_dma_free_chan_resources(struct 
> dma_chan *chan)
>  
>   vchan_free_chan_resources(&c->vc);
>   free_irq(c->irq_number, c);
> + dma_pool_destroy(c->cb_pool);
>  
>   dev_dbg(c->vc.chan.device->dev, "Freeing DMA channel %u\n", c->ch);
>  }
> @@ -261,8 +278,7 @@ static size_t bcm2835_dma_desc

Re: [PATCH V4] mm: fix kernel crash in khugepaged thread

2015-11-16 Thread Vlastimil Babka
On 17.11.2015 4:58, yalin wang wrote:
> 
>> On Nov 17, 2015, at 10:43, Steven Rostedt  wrote:
>>
>> On Tue, 17 Nov 2015 10:21:47 +0800
>> yalin wang  wrote:
>>
>>
>>
>> Because the print_fmt has nothing to do with the fields. You can have
>> as your print_fmt as:
>>
>>  TP_printk("Message = %s", "hello dolly!")
>>
>> And both userspace and the kernel with process that correctly (if I got
>> string processing working in userspace, which I believe I do). The
>> string is processed, it's not dependent on TP_STRUCT__entry() unless it
>> references a field there. Which can also be used too:
>>
>>  TP_printk("Message = %s", __entry->musical ? "Hello dolly!" :
>>  "Death Trap!")
>>
>> userspace will see in the entry:
>>
>> print_fmt: "Message = %s", REC->musical ? "Hello dolly!" : "Death Trap!"
>>
>> as long as the field "musical" exists, all is well.
>>
>> -- Steve
> Aha,  i see.
> Thanks very much for your explanation.
> Better print fat is :   
> TP_printk("mm=%p, scan_pfn=%s, writable=%d, referenced=%d, none_or_zero=%d, 
> status=%s, unmapped=%d",
>__entry->mm,
>   __entry->pfn == (-1UL) ? "(null)" :  itoa(buff,  __entry->pin, 
> 10), …..)
> 
> is this possible ?

I doubt so.

Why don't we just do (with %lx):
 __entry->pfn != -1UL ? __entry->pfn : 0,

Status already tells us that it's not a real pfn 0 (which I doubt would be
userspace-mapped and thus reachable by khugepaged anyway?).
Also it's what some other tracepoints do, see e.g. mm_page class in
include/trace/events/kmem.h.

> 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 1/2 (v2)] leds-bcm6328: Reuse bcm6328_led_set() instead of copying its functionality

2015-11-16 Thread Simon Arlott
On 16/11/15 21:33, Álvaro Fernández Rojas wrote:
> Still wrong, you are setting the led value after unlocking the spinlock.

I have to unlock it because bcm6328_led_set() locks that spinlock.

> El 16/11/2015 a las 21:24, Simon Arlott escribió:
>> When ensuring a consistent initial LED state in bcm6328_led (as they may
>> be blinking instead of on/off), the LED register is set using an inverted
>> copy of bcm6328_led_set(). To avoid further errors relating to active low
>> handling, call this function directly instead.
>>
>> As bcm6328_led_set() acquires the same spinlock again when updating the
>> register, it is called after unlocking.
>>
>> Signed-off-by: Simon Arlott 
>> ---
>>   drivers/leds/leds-bcm6328.c | 8 ++--
>>   1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/leds/leds-bcm6328.c b/drivers/leds/leds-bcm6328.c
>> index c7ea5c6..95d0cf9 100644
>> --- a/drivers/leds/leds-bcm6328.c
>> +++ b/drivers/leds/leds-bcm6328.c
>> @@ -314,14 +314,10 @@ static int bcm6328_led(struct device *dev, struct 
>> device_node *nc, u32 reg,
>>  } else {
>>  led->cdev.brightness = LED_OFF;
>>  }
>> -
>> -if ((led->active_low && led->cdev.brightness == LED_FULL) ||
>> -(!led->active_low && led->cdev.brightness == LED_OFF))
>> -bcm6328_led_mode(led, BCM6328_LED_MODE_ON);
>> -else
>> -bcm6328_led_mode(led, BCM6328_LED_MODE_OFF);
>>  spin_unlock_irqrestore(lock, flags);
>>   
>> +bcm6328_led_set(&led->cdev, led->cdev.brightness);
>> +
>>  led->cdev.brightness_set = bcm6328_led_set;
>>  led->cdev.blink_set = bcm6328_blink_set;
>>   
> 


-- 
Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] brcmnand: Clear EXT_ADDR error registers in PIO mode

2015-11-16 Thread Simon Arlott
On 17/11/15 00:40, Brian Norris wrote:
> + bcm-kernel-feedback-list
> 
> On Mon, Nov 16, 2015 at 10:05:39PM +, Simon Arlott wrote:
>> If an error occurs in flash above 4GB in PIO mode then the EXT_ADDR
>> registers will be set to the location of the error and never cleared.
>> 
>> Reset them to 0 before reading.
>> 
>> Signed-off-by: Simon Arlott 
> 
> Patch looks OK. Did you see this problem in practice, or is this just
> theoretical? I thought the documentation seemed to suggest these
> registers were cleared together with their non-_EXT counterparts. But
> implementation definitely trumps documentation for HW.

It's theoretical (I don't have 4GB+ flash), but the Broadcom version of
the NAND driver does this.

> Brian
> 
>> ---
>>  drivers/mtd/nand/brcmnand/brcmnand.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
>> b/drivers/mtd/nand/brcmnand/brcmnand.c
>> index 12c6190..2c8f67f 100644
>> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
>> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
>> @@ -1400,6 +1400,8 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, 
>> struct nand_chip *chip,
>>  /* Clear error addresses */
>>  brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_ADDR, 0);
>>  brcmnand_write_reg(ctrl, BRCMNAND_CORR_ADDR, 0);
>> +brcmnand_write_reg(ctrl, BRCMNAND_UNCORR_EXT_ADDR, 0);
>> +brcmnand_write_reg(ctrl, BRCMNAND_CORR_EXT_ADDR, 0);
>>  
>>  brcmnand_write_reg(ctrl, BRCMNAND_CMD_EXT_ADDRESS,
>>  (host->cs << 16) | ((addr >> 32) & 0x));
>> -- 
>> 2.1.4
>> 
>> -- 
>> Simon Arlott
> 


-- 
Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sound/soc/davinci: fix error case in mcasp_set_ctl_reg

2015-11-16 Thread Peter Ujfalusi
On 11/16/2015 07:40 PM, Pavel Machek wrote:
> 
> This fixes typo in comment and fixes mcasp_set_ctl_reg to actually
> printk on error as author wanted, and cleans it up. Yes, i will end up
> being 1001 in the old code.

Yeah, the original code had the additional GBLCTL register check after the
timeout. Which was pointless IMHO.
I'm fine with the change, but...

> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/sound/soc/davinci/davinci-mcasp.c 
> b/sound/soc/davinci/davinci-mcasp.c
> index b960e62..a739ca8 100644
> --- a/sound/soc/davinci/davinci-mcasp.c
> +++ b/sound/soc/davinci/davinci-mcasp.c
> @@ -148,15 +150,14 @@ static void mcasp_set_ctl_reg(struct davinci_mcasp 
> *mcasp, u32 ctl_reg, u32 val)
>  
>   mcasp_set_bits(mcasp, ctl_reg, val);
>  
> - /* programming GBLCTL needs to read back from GBLCTL and verfiy */
> + /* programming GBLCTL needs to read back from GBLCTL and verify */
>   /* loop count is to avoid the lock-up */
> - for (i = 0; i < 1000; i++) {
> + for (i = 0; i <= 1000; i++) {

Does it really make any difference to change this from looping 1000 times to
1001 times?

>   if ((mcasp_get_reg(mcasp, ctl_reg) & val) == val)
> - break;
> + return;
>   }
>  
> - if (i == 1000 && ((mcasp_get_reg(mcasp, ctl_reg) & val) != val))
> - printk(KERN_ERR "GBLCTL write error\n");
> + printk(KERN_ERR "GBLCTL write error\n");

Can you change this to dev_err(mcasp->dev, ...);

>  }
>  
>  static bool mcasp_is_synchronous(struct davinci_mcasp *mcasp)
> 
> 

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


Re: kernel oops on mmotm-2015-10-15-15-20

2015-11-16 Thread Minchan Kim
On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote:
> On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote:
> > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote:
> > > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote:
> > > > During the test with MADV_FREE on kernel I applied your patches,
> > > > I couldn't see any problem.
> > > > 
> > > > However, in this round, I did another test which is same one
> > > > I attached but a liitle bit different because it doesn't do
> > > > (memcg things/kill/swapoff) for testing program long-live test.
> > > 
> > > Could you share updated test?
> > 
> > It's part of my testing suite so I should factor it out.
> > I will send it when I go to office tomorrow.
> 
> Thanks.
> 
> > > And could you try to reproduce it on clean mmotm-2015-11-10-15-53?
> > 
> > Befor leaving office, I queued it up and result is below.
> > It seems you fixed already but didn't apply it to mmotm yet. Right?
> > Anyway, please confirm and say to me what I should add more patches
> > into mmotm-2015-11-10-15-53 for follow up your recent many bug
> > fix patches.
> 
> The two my patches which are not in the mmotm-2015-11-10-15-53 release:
> 
> http://lkml.kernel.org/g/1447236557-68682-1-git-send-email-kirill.shute...@linux.intel.com
> http://lkml.kernel.org/g/1447236567-68751-1-git-send-email-kirill.shute...@linux.intel.com

1. mm: fix __page_mapcount()
2. thp: fix leak due split_huge_page() vs. exit race

If I missed some patches, let me know it.

I applied above two patches based on mmotm-2015-11-10-15-53 and tested again.
But unfortunately, the result was below.

Now, I am making test program I can send to you but it seems to be not easy
because small changes for factoring it out from testing suite seems to change
something(ex, timing) and makes hard to reproduce. I will try it again.


page:ea240080 count:2 mapcount:1 mapping:88007eff3321 
index:0x60e02
flags: 0x40040018(uptodate|dirty|swapbacked)
page dumped because: VM_BUG_ON_PAGE(!PageLocked(page))
page->mem_cgroup:880077cf0c00
[ cut here ]
kernel BUG at mm/huge_memory.c:3272!
invalid opcode:  [#1] SMP 
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 8 PID: 59 Comm: khugepaged Not tainted 4.3.0-mm1-kirill+ #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880073441a40 ti: 88007344c000 task.ti: 88007344c000
RIP: 0010:[]  [] 
split_huge_page_to_list+0x8fb/0x910
RSP: 0018:88007344f968  EFLAGS: 00010286
RAX: 0021 RBX: ea240080 RCX: 
RDX: 0001 RSI: 0246 RDI: 821df4d8
RBP: 88007344f9e8 R08:  R09: 880bc600
R10: 8163e2c0 R11: 4b47 R12: ea240080
R13: ea240088 R14: ea240080 R15: 
FS:  () GS:88007830() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 7ffd59edcd68 CR3: 01808000 CR4: 06a0
Stack:
 cccd ea240080 88007344fa00 ea240088
 88007344fa00  88007344f9e8 810f0200
 ea24   ea240080
Call Trace:
 [] ? __lock_page+0xa0/0xb0
 [] deferred_split_scan+0x115/0x240
 [] ? list_lru_count_one+0x1c/0x30
 [] shrink_slab.part.42+0x1e3/0x350
 [] shrink_zone+0x26a/0x280
 [] do_try_to_free_pages+0x12d/0x3b0
 [] try_to_free_pages+0xb4/0x140
 [] __alloc_pages_nodemask+0x459/0x920
 [] ? trace_event_raw_event_tick_stop+0xd0/0xd0
 [] khugepaged+0x155/0x1b10
 [] ? prepare_to_wait_event+0xf0/0xf0
 [] ? __split_huge_pmd_locked+0x4e0/0x4e0
 [] kthread+0xc9/0xe0
 [] ? kthread_park+0x60/0x60
 [] ret_from_fork+0x3f/0x70
 [] ? kthread_park+0x60/0x60
Code: ff ff 48 c7 c6 00 cd 77 81 4c 89 f7 e8 df ce fc ff 0f 0b 48 83 e8 01 e9 
94 f7 ff ff 48 c7 c6 80 bb 77 81 4c 89 f7 e8 c5 ce fc ff <0f> 0b 48 c7 c6 48 c9 
77 81 4c 89 e7 e8 b4 ce fc ff 0f 0b 66 90 
RIP  [] split_huge_page_to_list+0x8fb/0x910
 RSP 
---[ end trace 0ee39378e850d8de ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/2] security/capability.h: cap_issubset/isclear can be boolean

2015-11-16 Thread Yaowei Bai
This patch makes cap_issubset/isclear return bool due to these
functions only using either one or zero as their return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/capability.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index b032003..f314275 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -145,24 +145,24 @@ static inline kernel_cap_t cap_invert(const kernel_cap_t 
c)
return dest;
 }
 
-static inline int cap_isclear(const kernel_cap_t a)
+static inline bool cap_isclear(const kernel_cap_t a)
 {
unsigned __capi;
CAP_FOR_EACH_U32(__capi) {
if (a.cap[__capi] != 0)
-   return 0;
+   return false;
}
-   return 1;
+   return true;
 }
 
 /*
  * Check if "a" is a subset of "set".
- * return 1 if ALL of the capabilities in "a" are also in "set"
- * cap_issubset(0101, ) will return 1
- * return 0 if ANY of the capabilities in "a" are not in "set"
- * cap_issubset(, 0101) will return 0
+ * return true if ALL of the capabilities in "a" are also in "set"
+ * cap_issubset(0101, ) will return true
+ * return false if ANY of the capabilities in "a" are not in "set"
+ * cap_issubset(, 0101) will return false
  */
-static inline int cap_issubset(const kernel_cap_t a, const kernel_cap_t set)
+static inline bool cap_issubset(const kernel_cap_t a, const kernel_cap_t set)
 {
kernel_cap_t dest;
dest = cap_drop(a, set);
-- 
1.9.1



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


[PATCH 1/2] security: remove unused cap_is_fs_cap function

2015-11-16 Thread Yaowei Bai
Since commit 3bc1fa8a ("LSM: remove BSD secure level security module")
there is no user of cap_is_fs_cap any more, so remove it.

Signed-off-by: Yaowei Bai 
---
 include/linux/capability.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index af9f0b9..b032003 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -171,12 +171,6 @@ static inline int cap_issubset(const kernel_cap_t a, const 
kernel_cap_t set)
 
 /* Used to decide between falling back on the old suser() or fsuser(). */
 
-static inline int cap_is_fs_cap(int cap)
-{
-   const kernel_cap_t __cap_fs_set = CAP_FS_SET;
-   return !!(CAP_TO_MASK(cap) & __cap_fs_set.cap[CAP_TO_INDEX(cap)]);
-}
-
 static inline kernel_cap_t cap_drop_fs_set(const kernel_cap_t a)
 {
const kernel_cap_t __cap_fs_set = CAP_FS_SET;
-- 
1.9.1



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


[PATCH] SCSI-aic94xx: Delete unnecessary checks before the function call "kmem_cache_destroy"

2015-11-16 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 17 Nov 2015 08:14:52 +0100

The kmem_cache_destroy() function tests whether its argument is NULL
and then returns immediately. Thus the test around the calls is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/scsi/aic94xx/aic94xx_init.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/aic94xx/aic94xx_init.c 
b/drivers/scsi/aic94xx/aic94xx_init.c
index 662b232..ab93049 100644
--- a/drivers/scsi/aic94xx/aic94xx_init.c
+++ b/drivers/scsi/aic94xx/aic94xx_init.c
@@ -660,12 +660,9 @@ Err:
 
 static void asd_destroy_global_caches(void)
 {
-   if (asd_dma_token_cache)
-   kmem_cache_destroy(asd_dma_token_cache);
+   kmem_cache_destroy(asd_dma_token_cache);
asd_dma_token_cache = NULL;
-
-   if (asd_ascb_cache)
-   kmem_cache_destroy(asd_ascb_cache);
+   kmem_cache_destroy(asd_ascb_cache);
asd_ascb_cache = NULL;
 }
 
-- 
2.6.2

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


Re: [PATCH V1 10/10] acpi, gicv3, its: Use MADT ITS subtable to do PCI/MSI domain initialization.

2015-11-16 Thread Huang Shijie
On Sat, Oct 24, 2015 at 03:58:17PM +0200, Tomasz Nowicki wrote:
Hi Tomasz,
> 
> Indeed, I will rebase after some more comments related to other patches in
> this series.
> 
Do you have any update about this patch set?
I want to test this patch set, but I met the fail when I git-am this
patch set to linux-next tree.

thanks
Huang Shijie

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] alarmtimer: fix unexpected rtc interrupt when system resume from S3

2015-11-16 Thread Lee, Zhuo-hao
>> (1). alarmtimer create a rtc wake up timer however alarmtimer won't
>>  remove that timer if the system wake up earlier

>That's hardly a bug. That's a slight incorrectness which needs to be fixed.
I think this timer is useless after system resume. For the correctness, I think 
it should be fixed.
Do you agree? Or do you have any other suggestions? :)

>> (2). rtc wake up timer will trigger hpet_rtc_interrupt continuously 
>> until timer timeout.

>> This patch only fixed (1). Fixing (1) can avoid (2).
>> However, The (2) is another story which it is not covered by this patch.

>And that's the real interesting question. Why is hpet_rtc_interrupt 
>continously triggered?

I think this is caused by driver implementation. 
My explanation for the continuous  hpet_rtc_interrupt():
1. In hpet_rtc_timer_init(), it will set "delta" to 1/64 seconds in AIE mode 
(about 16ms, because of the value DEFAULT_RTC_SHIFT), 
 that will cause hpet_rtc_interrupt() be triggered in every 16ms if the 
wakeup time (global variable hpet_alarm_time) is not reached.
2. When someone calls rtc_timer_start (ex: alarmtimer_suspend ), hpet driver 
will set timeout value (current time + delta) 
 to hpet_alarm_time, and then enable hpet timer.
3. In hpet_rtc_interrupt(), it will call hpet_rtc_timer_reinit() to reinit 
timer and add "delta" to 
 the hpet_t1_cmp for the next timeout value ( so we will receive an 
interrupt after 16ms).
 If hpet_alarm_time is reached, the irq_handler() will be called, the 
hpet_rtc_flags will be set to 0 and the hpet timer will be disable.
 Otherwise, we will receive an interrupt in each 16ms.
If the logic of 1,2,3 are correct, no bugs inside, maybe we can redesign the 
driver to reduce this periodic interrupt.

The following call path enable hpet timer when system go to suspend, just for 
you reference :)
alarmtimer_suspend
--rtc_timer_start
rtc_timer_enqueue
--__rtc_set_alarm
cmos_set_alarm
--cmos_irq_enable
hpet_set_rtc_irq_bit

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


[PATCH 2/2] fs/ceph: ceph_frag_contains_value can be boolean

2015-11-16 Thread Yaowei Bai
This patch makes ceph_frag_contains_value return bool to improve
readability due to this particular function only using either one or
zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/ceph/ceph_frag.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/ceph/ceph_frag.h b/include/linux/ceph/ceph_frag.h
index 970ba5c..b827e06 100644
--- a/include/linux/ceph/ceph_frag.h
+++ b/include/linux/ceph/ceph_frag.h
@@ -40,7 +40,7 @@ static inline __u32 ceph_frag_mask_shift(__u32 f)
return 24 - ceph_frag_bits(f);
 }
 
-static inline int ceph_frag_contains_value(__u32 f, __u32 v)
+static inline bool ceph_frag_contains_value(__u32 f, __u32 v)
 {
return (v & ceph_frag_mask(f)) == ceph_frag_value(f);
 }
-- 
1.9.1



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


[PATCH 1/2] fs/ceph: remove unused functions in ceph_frag.h

2015-11-16 Thread Yaowei Bai
These functions were introduced in commit 3d14c5d2b ("ceph: factor
out libceph from Ceph file system"). Howover, there's no user of
these functions since then, so remove them for simplicity.

Signed-off-by: Yaowei Bai 
---
 include/linux/ceph/ceph_frag.h | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/include/linux/ceph/ceph_frag.h b/include/linux/ceph/ceph_frag.h
index 5babb8e..970ba5c 100644
--- a/include/linux/ceph/ceph_frag.h
+++ b/include/linux/ceph/ceph_frag.h
@@ -44,42 +44,7 @@ static inline int ceph_frag_contains_value(__u32 f, __u32 v)
 {
return (v & ceph_frag_mask(f)) == ceph_frag_value(f);
 }
-static inline int ceph_frag_contains_frag(__u32 f, __u32 sub)
-{
-   /* is sub as specific as us, and contained by us? */
-   return ceph_frag_bits(sub) >= ceph_frag_bits(f) &&
-  (ceph_frag_value(sub) & ceph_frag_mask(f)) == ceph_frag_value(f);
-}
 
-static inline __u32 ceph_frag_parent(__u32 f)
-{
-   return ceph_frag_make(ceph_frag_bits(f) - 1,
-ceph_frag_value(f) & (ceph_frag_mask(f) << 1));
-}
-static inline int ceph_frag_is_left_child(__u32 f)
-{
-   return ceph_frag_bits(f) > 0 &&
-   (ceph_frag_value(f) & (0x100 >> ceph_frag_bits(f))) == 0;
-}
-static inline int ceph_frag_is_right_child(__u32 f)
-{
-   return ceph_frag_bits(f) > 0 &&
-   (ceph_frag_value(f) & (0x100 >> ceph_frag_bits(f))) == 1;
-}
-static inline __u32 ceph_frag_sibling(__u32 f)
-{
-   return ceph_frag_make(ceph_frag_bits(f),
- ceph_frag_value(f) ^ (0x100 >> ceph_frag_bits(f)));
-}
-static inline __u32 ceph_frag_left_child(__u32 f)
-{
-   return ceph_frag_make(ceph_frag_bits(f)+1, ceph_frag_value(f));
-}
-static inline __u32 ceph_frag_right_child(__u32 f)
-{
-   return ceph_frag_make(ceph_frag_bits(f)+1,
- ceph_frag_value(f) | (0x100 >> (1+ceph_frag_bits(f;
-}
 static inline __u32 ceph_frag_make_child(__u32 f, int by, int i)
 {
int newbits = ceph_frag_bits(f) + by;
-- 
1.9.1



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


Re: [PATCH, resend] scsi: advansys: fix big-endian builds

2015-11-16 Thread Hannes Reinecke
On 11/16/2015 05:49 PM, Arnd Bergmann wrote:
> Building the advansys driver in a big-endian configuration such as
> ARM allmodconfig shows a warning:
> 
>  drivers/scsi/advansys.c: In function 'adv_build_req':
>  include/uapi/linux/byteorder/big_endian.h:32:26: warning: large integer 
> implicitly truncated to unsigned type [-Woverflow]
>   #define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
>  drivers/scsi/advansys.c:7806:22: note: in expansion of macro 'cpu_to_le32'
>scsiqp->sense_len = cpu_to_le32(SCSI_SENSE_BUFFERSIZE);
> 
> It turns out that the commit that introduced this used the cpu_to_le32()
> incorrectly on an 8-bit field, which results in the sense_len to always
> be set to zero, as the SCSI_SENSE_BUFFERSIZE value gets moved to upper
> byte of the 32-bit intermediate.
> 
> This removes the cpu_to_le32() call to restore the original version.
> 
> I found this only by looking at the compiler output and have not done
> a full review for possible further endianess bugs in the same driver.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 811ddc057aac ("advansys: use DMA-API for mapping sense buffer")
> Cc: sta...@vger.kernel.org # v4.2+
> ---
> Using wi...@linux.intel.com, as the address listed in MAINTAINERS
> failed:
> 
> Failed to transport message. Message sending failed since the following 
> recipients were rejected by the server: matt...@wil.cx (The server responded: 
> Requested action not taken: mailbox unavailable invalid DNS MX or A/ 
> resource record)
> 
> Geert found the same bug and submitted the same patch earlier:
> https://lkml.org/lkml/2015/6/24/89
> 
> Neither one has been reviewed or accepted so far. Can we get one of the
> two merged please?
> 
> diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
> index 4305178e4e01..1c1cd657c380 100644
> --- a/drivers/scsi/advansys.c
> +++ b/drivers/scsi/advansys.c
> @@ -7803,7 +7803,7 @@ adv_build_req(struct asc_board *boardp, struct 
> scsi_cmnd *scp,
>   return ASC_BUSY;
>   }
>   scsiqp->sense_addr = cpu_to_le32(sense_addr);
> - scsiqp->sense_len = cpu_to_le32(SCSI_SENSE_BUFFERSIZE);
> + scsiqp->sense_len = SCSI_SENSE_BUFFERSIZE;
>  
>   /* Build ADV_SCSI_REQ_Q */
>  
> 
Ho-hum. You are right.

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries & Storage
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 02/12] x86: fixmap: add permanent fixmap for xhci debug port

2015-11-16 Thread Lu Baolu
xHCI compatible USB3 host controller may provide debug capability
which enables low-level system debug over USB. In order to probing
this debug capability, Linux kernel needs to map and access the
mmio of the host controller during early boot.

This patch adds permenent fixmap pages in fixed_addresses table for
xHCI mmio access.

Signed-off-by: Lu Baolu 
---
 arch/x86/include/asm/fixmap.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index f80d700..fbf452f 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -82,6 +82,10 @@ enum fixed_addresses {
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   FIX_XDBC_BASE,
+   FIX_XDBC_END = FIX_XDBC_BASE + 15,
+#endif
 #ifdef CONFIG_X86_LOCAL_APIC
FIX_APIC_BASE,  /* local (CPU) APIC) -- required for SMP or not */
 #endif
-- 
2.1.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 v4 03/12] usb: xhci: dbc: probe and setup xhci debug capability

2015-11-16 Thread Lu Baolu
xHCI debug capability (DbC) is an optional functionality provided
by an xHCI host controller. Software learns this capability by
walking through the extended capability list in mmio of the host.

This patch introduces the code to probe and initialize the debug
capability hardware during early boot. With hardware initialization
done, the debug target (system under debug which has DbC enabled)
will present a debug device through the debug port. The debug device
is fully compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link between the
debug host and target.

Signed-off-by: Lu Baolu 
---
 MAINTAINERS  |   7 +
 arch/x86/Kconfig.debug   |  12 +
 drivers/usb/early/Makefile   |   1 +
 drivers/usb/early/xhci-dbc.c | 787 +++
 include/linux/usb/xhci-dbc.h | 187 ++
 5 files changed, 994 insertions(+)
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 include/linux/usb/xhci-dbc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e9caa4b..3d7e0cf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11250,6 +11250,13 @@ S: Supported
 F: drivers/usb/host/xhci*
 F: drivers/usb/host/pci-quirks*
 
+USB XHCI DEBUG PORT
+M: Lu Baolu 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/usb/early/xhci-dbc.c
+F: include/linux/usb/xhci-dbc.h
+
 USB ZD1201 DRIVER
 L: linux-wirel...@vger.kernel.org
 W: http://linux-lc100020.sourceforge.net
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 137dfa9..e450f88 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -65,6 +65,18 @@ config EARLY_PRINTK_EFI
  This is useful for kernel debugging when your machine crashes very
  early before the console code is initialized.
 
+config EARLY_PRINTK_XDBC
+   bool "Early printk via xHCI debug port"
+   depends on EARLY_PRINTK && PCI
+   ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
 config X86_PTDUMP_CORE
def_bool n
 
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..2db5906 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..22a1de9
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,787 @@
+/**
+ * xhci-dbc.c - xHCI debug capability driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ * Some code shared with EHCI debug port and xHCI driver.
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+#include "../host/xhci.h"
+
+#defineXDBC_PROTOCOL   1   /* GNU Remote Debug Command Set 
*/
+#defineXDBC_VENDOR_ID  0x1d6b  /* Linux Foundation 0x1d6b */
+#defineXDBC_PRODUCT_ID 0x0004  /* __le16 idProduct; device 
0004 */
+#defineXDBC_DEVICE_REV 0x0010  /* 0.10 */
+
+static struct xdbc_state xdbc_stat;
+static struct xdbc_state *xdbcp = &xdbc_stat;
+
+#ifdef DBC_DEBUG
+/* place holder */
+#definexdbc_trace  printk
+static void xdbc_dbg_dump_regs(char *str)
+{
+   if (!xdbcp->xdbc_reg) {
+   xdbc_trace("register not mapped\n");
+   return;
+   }
+
+   xdbc_trace("XDBC registers: %s\n", str);
+   xdbc_trace("  Capability: %08x\n",
+   readl(&xdbcp->xdbc_reg->capability));
+   xdbc_trace("  Door bell: %08x\n",
+   readl(&xdbcp->xdbc_reg->doorbell));
+   xdbc_trace("  Event Ring Segment Table Size: %08x\n",
+   readl(&xdbcp->xdbc_reg->ersts));
+   xdbc_trace("  Event Ring Segment Table Base Address: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->erstba));
+   xdbc_trace("  Event Ring Dequeue Pointer: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->erdp));
+   xdbc_trace("  Port status and control: %08x\n",
+   readl(&xdbcp->xdbc_reg->portsc));
+   xdbc_trace("  Debug Capability Context Pointer: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->dccp));
+   xdbc_trace("  Device Descriptor Info Re

[PATCH v4 01/12] usb: xhci: add sysfs file for xHCI debug port

2015-11-16 Thread Lu Baolu
This patch adds a sysfs file for users to check 1) whether the debug
capability is implemented by hardware; 2) if supported, which state
does it stay at.

With a host that supports debug port, a file named "debug_port_state"
will be created under the device sysfs directory. Reading this file
will show users the state (disabled, enabled or configured) of the
debug port.

With a host that does NOT support debug port, "debug_port_state" file
won't be created.

Signed-off-by: Lu Baolu 
---
 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 23 +++
 drivers/usb/host/Makefile  |  2 +-
 drivers/usb/host/xhci-ext-caps.h   | 14 +++-
 drivers/usb/host/xhci-sysfs.c  | 80 ++
 drivers/usb/host/xhci.c|  4 ++
 drivers/usb/host/xhci.h|  4 ++
 6 files changed, 125 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 drivers/usb/host/xhci-sysfs.c

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd 
b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
new file mode 100644
index 000..dd3e722
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
@@ -0,0 +1,23 @@
+What:  /sys/bus/pci/drivers/xhci_hcd/.../debug_port_state
+Date:  November 2015
+KernelVersion: 4.3.0
+Contact:   Lu Baolu 
+Description:
+   This file is designed for users to check the state of a
+   USB3 debug port. On a machine which supports USB3 debug
+   port, this file will be created. Reading this file will
+   show the state (disabled, enabled or configured) of the
+   debug port. On a machine that doesn't support USB3 debug
+   port, this file doesn't exist.
+
+   The state of a debug port could be:
+   1) disabled: The debug port is not enabled and the root
+   port has been switched to xHCI host as a normal
+   root port.
+   2) enabled: The debug port is enabled. The debug port
+   has been assigned to debug capability. The debug
+   capability is able to handle the control requests
+   defined in USB3 spec.
+   3) configured: The debug port has been enumerated by the
+   debug host as a debug device. The debug port is
+   in use now.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index e7558ab..810c304 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -12,7 +12,7 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
-xhci-hcd-y += xhci-trace.o
+xhci-hcd-y += xhci-trace.o xhci-sysfs.o
 
 xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index 9fe3225..12c87e5 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -49,8 +49,15 @@
 #define XHCI_EXT_CAPS_PM   3
 #define XHCI_EXT_CAPS_VIRT 4
 #define XHCI_EXT_CAPS_ROUTE5
-/* IDs 6-9 reserved */
+#define XHCI_EXT_CAPS_LOCALMEM 6
+/* IDs 7-9 reserved */
 #define XHCI_EXT_CAPS_DEBUG10
+/* IDs 192-255 vendor specific */
+#define XHCI_EXT_CAPS_VEN_START192
+#define XHCI_EXT_CAPS_VEN_END  255
+#define XHCI_EXT_CAPS_VENDOR(p)(((p) >= XHCI_EXT_CAPS_VEN_START) && \
+   ((p) <= XHCI_EXT_CAPS_VEN_END))
+#define XHCI_EXT_MAX_CAPID XHCI_EXT_CAPS_VEN_END
 /* USB Legacy Support Capability - section 7.1.1 */
 #define XHCI_HC_BIOS_OWNED (1 << 16)
 #define XHCI_HC_OS_OWNED   (1 << 24)
@@ -73,6 +80,11 @@
 #define XHCI_HLC   (1 << 19)
 #define XHCI_BLC   (1 << 20)
 
+/* Debug capability - section 7.6.8 */
+#define XHCI_DBC_DCCTRL0x20
+#define XHCI_DBC_DCCTRL_DCR(1 << 0)
+#defineXHCI_DBC_DCCTRL_DCE (1 << 31)
+
 /* command register values to disable interrupts and halt the HC */
 /* start/stop HC execution - do not write unless HC is halted*/
 #define XHCI_CMD_RUN   (1 << 0)
diff --git a/drivers/usb/host/xhci-sysfs.c b/drivers/usb/host/xhci-sysfs.c
new file mode 100644
index 000..365858f
--- /dev/null
+++ b/drivers/usb/host/xhci-sysfs.c
@@ -0,0 +1,80 @@
+/*
+ * sysfs interface for xHCI host controller driver
+ *
+ * Copyright (C) 2015 Intel Corp.
+ *
+ * Author: Lu Baolu 
+ *
+ * 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 "xhci.h"
+
+/*
+ * Return the register offset of a extended capability specified
+ * by @cap_id. Return 0 if @cap_id capabil

[PATCH v4 00/12] usb: early: add support for early printk through USB3 debug port

2015-11-16 Thread Lu Baolu
Hi,

This patch series adds support for early printk through USB3 debug port.
USB3 debug port is described in xHCI specification as an optional extended
capability.

The first patch adds a file in sysfs, through which users can check
whether the debug capability is supported by a specific host controller,
and the hardware state.

Patch 2 to 10 add the driver for xHCI debug capability. It interfaces with
the register set and provides the required ops (read/write/control) to upper
layers. Early printk is one consumer of these ops. The hooks for early printk
are introduced in patch 9. This design is similar to what we have done in
drivers/usb/early/ehci-dbgp.c.

Patch 11 is a minor change to usb_debug module. This change is required to
bind usb_debug with the USB3 debug device.

Patch 12 is the design document and user guide.

Change log:
v1->v2:
(1) Patch 1 re-implemented. "debugfs" has been replaced with sysfs.
The scope reduced from all extended capabilities to debug port
specific.
(2) Patch 11 changed. Removed unnecessary .bulk_out_size setting.

v2->v3:
(1) Patch 11 got acked by Johan Hovold.

v3->v4:
(1) Patch 1 code refactored by using xhci_find_ext_cap_by_id() helper.
(2) Patch 3 "bus hung state" changed to "port hung state" in commit message.
(3) Patch 12 added verified platform information.

Lu Baolu (12):
  usb: xhci: add sysfs file for xHCI debug port
  x86: fixmap: add permanent fixmap for xhci debug port
  usb: xhci: dbc: probe and setup xhci debug capability
  usb: xhci: dbc: add support for Intel xHCI dbc quirk
  usb: xhci: dbc: add debug buffer
  usb: xhci: dbc: add bulk out and bulk in interfaces
  usb: xhci: dbc: handle dbc-configured exit
  usb: xhci: dbc: handle endpoint stall
  x86: early_printk: add USB3 debug port earlyprintk support
  usb: xhci: dbc: add handshake between debug target and host
  usb: serial: usb_debug: add support for dbc debug device
  usb: doc: add document for xHCI DbC driver

 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd |   23 +
 Documentation/kernel-parameters.txt|1 +
 Documentation/usb/xhci-dbc.txt |  325 +
 MAINTAINERS|8 +
 arch/x86/Kconfig.debug |   12 +
 arch/x86/include/asm/fixmap.h  |4 +
 arch/x86/kernel/early_printk.c |5 +
 drivers/usb/early/Makefile |1 +
 drivers/usb/early/xhci-dbc.c   | 1407 
 drivers/usb/host/Makefile  |2 +-
 drivers/usb/host/xhci-ext-caps.h   |   14 +-
 drivers/usb/host/xhci-sysfs.c  |   80 ++
 drivers/usb/host/xhci.c|4 +
 drivers/usb/host/xhci.h|4 +
 drivers/usb/serial/usb_debug.c |   28 +-
 include/linux/usb/xhci-dbc.h   |  224 
 16 files changed, 2137 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 Documentation/usb/xhci-dbc.txt
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/host/xhci-sysfs.c
 create mode 100644 include/linux/usb/xhci-dbc.h

Thanks,
-Baolu
-- 
2.1.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 v4 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

2015-11-16 Thread Lu Baolu
On Intel platforms, if the debug target is connected with debug
host, enabling DCE bit in command register leads to a port hung
state. In the hung state, the host system will not see a port
connected status bit set. Hence debug target fails to be probed.

The state could be resolved by performing a port reset to the
debug port from the host xHCI. This patch introduces this work
around.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 52 
 include/linux/usb/xhci-dbc.h |  2 ++
 2 files changed, 54 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 22a1de9..6b23f09 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -255,6 +255,8 @@ static void __iomem *xdbc_map_pci_mmio(u32 bus,
xdbcp->bar = bar;
xdbcp->xhci_base = base;
xdbcp->xhci_length = sz64;
+   xdbcp->vendor = read_pci_config_16(bus, dev, func, PCI_VENDOR_ID);
+   xdbcp->device = read_pci_config_16(bus, dev, func, PCI_DEVICE_ID);
 
if (length)
*length = sz64;
@@ -651,6 +653,52 @@ static int xdbc_mem_init(void)
return 0;
 }
 
+static void xdbc_reset_debug_port_callback(int cap_offset, void *data)
+{
+   u8 major;
+   u32 val, port_offset, port_count;
+   u32 cap_length;
+   void __iomem *ops_reg;
+   void __iomem *portsc;
+   int i;
+
+   val = readl(xdbcp->xhci_base + cap_offset);
+   major = (u8) XHCI_EXT_PORT_MAJOR(val);
+
+   /* only reset super-speed port */
+   if (major != 0x3)
+   return;
+
+   val = readl(xdbcp->xhci_base + cap_offset + 8);
+   port_offset = XHCI_EXT_PORT_OFF(val);
+   port_count = XHCI_EXT_PORT_COUNT(val);
+   xdbc_trace("Extcap Port offset %d count %d\n",
+   port_offset, port_count);
+
+   cap_length = readl(xdbcp->xhci_base) & 0xff;
+   ops_reg = xdbcp->xhci_base + cap_length;
+
+   port_offset--;
+   for (i = port_offset; i < (port_offset + port_count); i++) {
+   portsc = ops_reg + 0x400 + i * 0x10;
+   val = readl(portsc);
+   /* reset the port if CCS bit is cleared */
+   if (!(val & 0x1))
+   writel(val | (1 << 4), portsc);
+   }
+}
+
+static void xdbc_reset_debug_port(void)
+{
+   xdbc_walk_excap(xdbcp->bus,
+   xdbcp->dev,
+   xdbcp->func,
+   XHCI_EXT_CAPS_PROTOCOL,
+   false,
+   xdbc_reset_debug_port_callback,
+   NULL);
+}
+
 /*
  * xdbc_start: start DbC
  *
@@ -669,6 +717,10 @@ static int xdbc_start(void)
return -ENODEV;
}
 
+   /* reset port to avoid bus hang */
+   if (xdbcp->vendor == PCI_VENDOR_ID_INTEL)
+   xdbc_reset_debug_port();
+
/* wait for port connection */
if (handshake(&xdbcp->xdbc_reg->portsc, PORTSC_CCS,
PORTSC_CCS, 500, 100) < 0) {
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 153fb87..fc0ef9a 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -128,6 +128,8 @@ struct xdbc_state {
u32 dev;
u32 func;
u8  bar;
+   u16 vendor;
+   u16 device;
void __iomem*xhci_base;
size_t  xhci_length;
 #defineXDBC_PCI_MAX_BUSES  256
-- 
2.1.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 v4 06/12] usb: xhci: dbc: add bulk out and bulk in interfaces

2015-11-16 Thread Lu Baolu
This patch adds interfaces for bulk out and bulk in ops. These
interfaces could be used to implement early printk bootconsole
or hook to various system debuggers.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 373 +++
 include/linux/usb/xhci-dbc.h |  30 
 2 files changed, 403 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index b36a527..f51daa4 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -219,11 +219,21 @@ static void xdbc_dbg_dump_data(char *str)
xdbc_dbg_dump_string("String Descriptor:");
 }
 
+static void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str)
+{
+   xdbc_trace("DBC trb: %s\n", str);
+   xdbc_trace("@%016llx %08x %08x %08x %08x\n", (u64)__pa(trb),
+   le32_to_cpu(trb->field[0]),
+   le32_to_cpu(trb->field[1]),
+   le32_to_cpu(trb->field[2]),
+   le32_to_cpu(trb->field[3]));
+}
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
 static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
+static inline void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str) { }
 #endif /* DBC_DEBUG */
 
 /*
@@ -334,6 +344,7 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
static char in_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char out_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char table_page[PAGE_SIZE] __aligned(PAGE_SIZE);
+   static char bulk_buf_page[PAGE_SIZE] __aligned(PAGE_SIZE);
 
switch (type) {
case XDBC_PAGE_EVENT:
@@ -348,6 +359,9 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
case XDBC_PAGE_TABLE:
virt = (void *)table_page;
break;
+   case XDBC_PAGE_BUFFER:
+   virt = (void *)bulk_buf_page;
+   break;
default:
return NULL;
}
@@ -707,6 +721,12 @@ static int xdbc_mem_init(void)
dev_info = cpu_to_le32((XDBC_DEVICE_REV << 16) | XDBC_PRODUCT_ID);
writel(dev_info, &xdbcp->xdbc_reg->devinfo2);
 
+   /* get and store the transfer buffer */
+   xdbcp->out_buf = xdbc_get_page(&xdbcp->out_dma,
+   XDBC_PAGE_BUFFER);
+   xdbcp->in_buf = xdbcp->out_buf + XDBC_MAX_PACKET;
+   xdbcp->in_dma = xdbcp->out_dma + XDBC_MAX_PACKET;
+
return 0;
 }
 
@@ -802,6 +822,9 @@ static int xdbc_start(void)
 
xdbc_trace("root hub port number %d\n", DCST_DPN(status));
 
+   xdbcp->in_ep_state = EP_RUNNING;
+   xdbcp->out_ep_state = EP_RUNNING;
+
xdbc_trace("DbC is running now, control 0x%08x\n",
readl(&xdbcp->xdbc_reg->control));
 
@@ -895,3 +918,353 @@ int __init early_xdbc_init(char *s)
 
return 0;
 }
+
+static void xdbc_queue_trb(struct xdbc_ring *ring,
+   u32 field1, u32 field2, u32 field3, u32 field4)
+{
+   struct xdbc_trb *trb, *link_trb;
+
+   trb = ring->enqueue;
+   trb->field[0] = cpu_to_le32(field1);
+   trb->field[1] = cpu_to_le32(field2);
+   trb->field[2] = cpu_to_le32(field3);
+   trb->field[3] = cpu_to_le32(field4);
+
+   xdbc_dbg_dump_trb(trb, "enqueue trb");
+
+   ++(ring->enqueue);
+   if (ring->enqueue >= &ring->segment->trbs[TRBS_PER_SEGMENT - 1]) {
+   link_trb = ring->enqueue;
+   if (ring->cycle_state)
+   link_trb->field[3] |= cpu_to_le32(TRB_CYCLE);
+   else
+   link_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
+
+   ring->enqueue = ring->segment->trbs;
+   ring->cycle_state ^= 1;
+   }
+}
+
+static void xdbc_ring_doorbell(int target)
+{
+   writel(DOOR_BELL_TARGET(target), &xdbcp->xdbc_reg->doorbell);
+}
+
+static void xdbc_handle_port_status(struct xdbc_trb *evt_trb)
+{
+   u32 port_reg;
+
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+
+   if (port_reg & PORTSC_CSC) {
+   xdbc_trace("%s: connect status change event\n", __func__);
+   writel(port_reg | PORTSC_CSC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PRC) {
+   xdbc_trace("%s: port reset change event\n", __func__);
+   writel(port_reg | PORTSC_PRC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PLC) {
+   xdbc_trace("%s: port link status change event\n", __func__);
+   writel(port_reg | PORTSC_PLC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_CEC) {
+   xdbc_trace("%s: config error change\n", __func__)

[PATCH v4 07/12] usb: xhci: dbc: handle dbc-configured exit

2015-11-16 Thread Lu Baolu
DbC might exit configured state in some cases (refer to 7.6.4.4 in
xHCI spec 1.1). Software needs detect and clear this situation by
clearing DCCTRL.DCR and wait until the DbC configured before read
or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index f51daa4..8a5a51f 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1153,6 +1153,29 @@ static int xdbc_wait_until_bulk_done(struct xdbc_trb 
*trb, int loops)
return -EIO;
 }
 
+static int xdbc_wait_until_dbc_configured(void)
+{
+   int timeout = 0;
+   u32 reg;
+
+   /* Port exits configured state */
+   reg = readl(&xdbcp->xdbc_reg->control);
+   if (!(reg & CTRL_DRC))
+   return 0;
+
+   /* clear run change bit (RW1C) */
+   writel(reg | CTRL_DRC, &xdbcp->xdbc_reg->control);
+
+   do {
+   if (readl(&xdbcp->xdbc_reg->control) & CTRL_DCR)
+   return 0;
+
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1167,6 +1190,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EINVAL;
}
 
+   if (xdbc_wait_until_dbc_configured()) {
+   xdbc_trace("%s: hardware not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? &xdbcp->in_ring : &xdbcp->out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
2.1.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 v4 08/12] usb: xhci: dbc: handle endpoint stall

2015-11-16 Thread Lu Baolu
In case of endpoint stall, software is able to detect the situation
by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
framework to handle endpoint stall. When software detects endpoint
stall situation, it should wait until endpoint is recovered before
read or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 8a5a51f..aaf655f 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1176,6 +1176,37 @@ static int xdbc_wait_until_dbc_configured(void)
return -ETIMEDOUT;
 }
 
+static int xdbc_wait_until_epstall_cleared(bool read)
+{
+   int timeout = 0;
+
+   if (read) {
+   do {
+   if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HIT)) {
+   xdbcp->in_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->in_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   } else {
+   do {
+   if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HOT)) {
+   xdbcp->out_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->out_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   }
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1195,6 +1226,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EPERM;
}
 
+   if (xdbc_wait_until_epstall_cleared(read)) {
+   xdbc_trace("%s: endpoint not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? &xdbcp->in_ring : &xdbcp->out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
2.1.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 v4 10/12] usb: xhci: dbc: add handshake between debug target and host

2015-11-16 Thread Lu Baolu
After DbC setup, debug target needs to wait until tty driver and
application (e.g. mincom) on debug taget start.  Otherwise, out
messages might be ignored.

This patch adds a ping/pong mechanism between debug target and
host. Debug target will be waiting there until user presses 'Y'
or 'y' in the tty application.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 68a7139..b75c523 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,6 +32,9 @@
 static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = &xdbc_stat;
 
+static int early_xdbc_read(struct console *con, char *str, unsigned n);
+static void early_xdbc_write(struct console *con, const char *str, u32 n);
+
 #ifdef DBC_DEBUG
 #defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
 #defineMSG_MAX_LINE128
@@ -873,8 +876,12 @@ int __init early_xdbc_init(char *s)
 {
u32 bus = 0, dev = 0, func = 0;
unsigned long dbgp_num = 0;
+   char *ping = "Press Y to continue...\n";
+   char pong[64];
+   size_t size;
u32 offset;
int ret;
+   int retry = 20;
 
if (!early_pci_allowed())
return -EPERM;
@@ -917,6 +924,21 @@ int __init early_xdbc_init(char *s)
return ret;
}
 
+   while (retry > 0) {
+   early_xdbc_write(NULL, ping, strlen(ping));
+   size = early_xdbc_read(NULL, pong, 64);
+   if (size > 0) {
+   xdbc_trace("%s: pong message: %s\n", __func__, pong);
+   if (pong[0] == 'Y' || pong[0] == 'y')
+   break;
+   } else {
+   xdbc_trace("%s: pong message error %d\n",
+   __func__, size);
+   }
+
+   retry--;
+   }
+
return 0;
 }
 
@@ -1338,6 +1360,11 @@ int xdbc_bulk_write(const char *bytes, int size)
  * Start a bulk-in or bulk-out transfer, wait until transfer completion
  * or error. Return the count of actually transferred bytes or error.
  */
+static int early_xdbc_read(struct console *con, char *str, unsigned n)
+{
+   return xdbc_bulk_read(str, n, 0);
+}
+
 static void early_xdbc_write(struct console *con, const char *str, u32 n)
 {
int chunk, ret;
-- 
2.1.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 3/5] fs/dcache.c: is_subdir can be boolean

2015-11-16 Thread Yaowei Bai
This patch makes is_subdir return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 fs/dcache.c| 14 +++---
 include/linux/fs.h |  2 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 5c33aeb..670f789 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -3303,18 +3303,18 @@ out:
  * @new_dentry: new dentry
  * @old_dentry: old dentry
  *
- * Returns 1 if new_dentry is a subdirectory of the parent (at any depth).
- * Returns 0 otherwise.
+ * Returns true if new_dentry is a subdirectory of the parent (at any depth).
+ * Returns false otherwise.
  * Caller must ensure that "new_dentry" is pinned before calling is_subdir()
  */
   
-int is_subdir(struct dentry *new_dentry, struct dentry *old_dentry)
+bool is_subdir(struct dentry *new_dentry, struct dentry *old_dentry)
 {
-   int result;
+   bool result;
unsigned seq;
 
if (new_dentry == old_dentry)
-   return 1;
+   return true;
 
do {
/* for restarting inner loop in case of seq retry */
@@ -3325,9 +3325,9 @@ int is_subdir(struct dentry *new_dentry, struct dentry 
*old_dentry)
 */
rcu_read_lock();
if (d_ancestor(old_dentry, new_dentry))
-   result = 1;
+   result = true;
else
-   result = 0;
+   result = false;
rcu_read_unlock();
} while (read_seqretry(&rename_lock, seq));
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index aab8094..4b23def 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2532,7 +2532,7 @@ extern ssize_t __kernel_write(struct file *, const char 
*, size_t, loff_t *);
 extern struct file * open_exec(const char *);
  
 /* fs/dcache.c -- generic fs support functions */
-extern int is_subdir(struct dentry *, struct dentry *);
+extern bool is_subdir(struct dentry *, struct dentry *);
 extern bool path_is_under(struct path *, struct path *);
 
 extern char *file_path(struct file *, char *, int);
-- 
1.9.1



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


[PATCH 1/5] fs/block_dev.c: make sb_is_blkdev_sb return bool when CONFIG_BLOCK undefined

2015-11-16 Thread Yaowei Bai
Currently when CONFIG_BLOCK is defined sb_is_blkdev_sb returns bool,
while when CONFIG_BLOCK is not defined it returns int. Let's keep
consistent to make sb_is_blkdev_sb return bool as well when CONFIG_BLOCK
isn't defined.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/fs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa5142..11505af 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2291,9 +2291,9 @@ static inline void iterate_bdevs(void (*f)(struct 
block_device *, void *), void
 {
 }
 
-static inline int sb_is_blkdev_sb(struct super_block *sb)
+static inline bool sb_is_blkdev_sb(struct super_block *sb)
 {
-   return 0;
+   return false;
 }
 #endif
 extern int sync_filesystem(struct super_block *);
-- 
1.9.1



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


[PATCH v4 11/12] usb: serial: usb_debug: add support for dbc debug device

2015-11-16 Thread Lu Baolu
This patch add dbc debug device support in usb_debug driver.

Signed-off-by: Lu Baolu 
Acked-by: Johan Hovold 
---
 drivers/usb/serial/usb_debug.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
 };
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+   { USB_DEVICE(0x0525, 0x127a) },
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
 
 /* This HW really does not support a serial break, so one will be
  * emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
 };
 
+static struct usb_serial_driver dbc_device = {
+   .driver = {
+   .owner =THIS_MODULE,
+   .name = "xhci_dbc",
+   },
+   .id_table = dbc_id_table,
+   .num_ports =1,
+   .break_ctl =usb_debug_break_ctl,
+   .process_read_urb = usb_debug_process_read_urb,
+};
+
 static struct usb_serial_driver * const serial_drivers[] = {
-   &debug_device, NULL
+   &debug_device, &dbc_device, NULL
 };
 
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
 MODULE_LICENSE("GPL");
-- 
2.1.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 2/5] fs/namespace.c: path_is_under can be boolean

2015-11-16 Thread Yaowei Bai
This patch makes path_is_under return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 fs/namespace.c | 4 ++--
 include/linux/fs.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 0570729..b27156f 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2939,9 +2939,9 @@ bool is_path_reachable(struct mount *mnt, struct dentry 
*dentry,
return &mnt->mnt == root->mnt && is_subdir(dentry, root->dentry);
 }
 
-int path_is_under(struct path *path1, struct path *path2)
+bool path_is_under(struct path *path1, struct path *path2)
 {
-   int res;
+   bool res;
read_seqlock_excl(&mount_lock);
res = is_path_reachable(real_mount(path1->mnt), path1->dentry, path2);
read_sequnlock_excl(&mount_lock);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 11505af..aab8094 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2533,7 +2533,7 @@ extern struct file * open_exec(const char *);
  
 /* fs/dcache.c -- generic fs support functions */
 extern int is_subdir(struct dentry *, struct dentry *);
-extern int path_is_under(struct path *, struct path *);
+extern bool path_is_under(struct path *, struct path *);
 
 extern char *file_path(struct file *, char *, int);
 
-- 
1.9.1



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


[PATCH v4 05/12] usb: xhci: dbc: add debug buffer

2015-11-16 Thread Lu Baolu
"printk" is not suitable for dbc debugging especially when console
is in usage. This patch adds a debug buffer in dbc driver and puts
the debug messages in this local buffer. The debug buffer could be
dumped whenever the console is not in use. This part of code will
not be visible unless DBC_DEBUG is defined.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 62 ++--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 6b23f09..b36a527 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = &xdbc_stat;
 
 #ifdef DBC_DEBUG
-/* place holder */
-#definexdbc_trace  printk
+#defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
+#defineMSG_MAX_LINE128
+static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
+static void xdbc_trace(const char *fmt, ...)
+{
+   int i, size;
+   va_list args;
+   static int pos;
+   char temp_buf[MSG_MAX_LINE];
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   return;
+
+   memset(temp_buf, 0, MSG_MAX_LINE);
+   va_start(args, fmt);
+   vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
+   va_end(args);
+
+   i = 0;
+   size = strlen(temp_buf);
+   while (i < size) {
+   xdbc_debug_buf[pos] = temp_buf[i];
+   pos++;
+   i++;
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   break;
+   }
+}
+
+static void xdbc_dump_debug_buffer(void)
+{
+   int index = 0;
+   int count = 0;
+   char dump_buf[MSG_MAX_LINE];
+
+   xdbc_trace("The end of DbC trace buffer\n");
+   pr_notice("DBC debug buffer:\n");
+   memset(dump_buf, 0, MSG_MAX_LINE);
+
+   while (index < XDBC_DEBUG_BUF_SIZE) {
+   if (!xdbc_debug_buf[index])
+   break;
+
+   if (xdbc_debug_buf[index] == '\n' ||
+   count >= MSG_MAX_LINE - 1) {
+   pr_notice("DBC: @%08x %s\n", index, dump_buf);
+   memset(dump_buf, 0, MSG_MAX_LINE);
+   count = 0;
+   } else {
+   dump_buf[count] = xdbc_debug_buf[index];
+   count++;
+   }
+
+   index++;
+   }
+}
+
 static void xdbc_dbg_dump_regs(char *str)
 {
if (!xdbcp->xdbc_reg) {
@@ -165,6 +221,7 @@ static void xdbc_dbg_dump_data(char *str)
 
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
+static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
 #endif /* DBC_DEBUG */
@@ -832,6 +889,7 @@ int __init early_xdbc_init(char *s)
pr_notice("failed to setup xHCI DbC connection\n");
xdbcp->xhci_base = NULL;
xdbcp->xdbc_reg = NULL;
+   xdbc_dump_debug_buffer();
return ret;
}
 
-- 
2.1.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 v4 12/12] usb: doc: add document for xHCI DbC driver

2015-11-16 Thread Lu Baolu
Add Documentation/usb/xhci-dbc.txt. This document includes
development status and user guide for USB3 debug port.

Signed-off-by: Lu Baolu 
---
 Documentation/usb/xhci-dbc.txt | 325 +
 MAINTAINERS|   1 +
 drivers/usb/early/xhci-dbc.c   |   3 +
 3 files changed, 329 insertions(+)
 create mode 100644 Documentation/usb/xhci-dbc.txt

diff --git a/Documentation/usb/xhci-dbc.txt b/Documentation/usb/xhci-dbc.txt
new file mode 100644
index 000..441b40c
--- /dev/null
+++ b/Documentation/usb/xhci-dbc.txt
@@ -0,0 +1,325 @@
+xHCI debug capability driver
+
+ Lu Baolu 
+
+Last-updated: September 2015
+
+
+   Contents:
+   -
+   * What is xHCI DbC?
+   * Debug topologies
+   * Debug stacks
+   * Port Multiplexing
+   * Hardware initialization
+   * External reset
+   * Port reset
+   * Interrupt/DMA/Memory during early boot
+   * Endpoint STALL
+   * Debug device information
+   * How to use DbC early printk?
+   * Limitations
+
+   What is xHCI DbC?
+   -
+
+The xHCI Debugging Capability defined in section 7.6 of xHCI spec 1.1
+provides an optional functionality that enables low-level system debug
+over USB. It provides a means of connecting two systems where one system
+is a Debug Host and the other a Debug Target (System Under Test). The
+Debug Capability provides an interface that is completely independent
+of the xHCI interface. A Debug Target enumerates as a USB debug device
+to the Debug Host, allowing a Debug Host to access a Debug Target through
+the standard USB software stack.
+
+   Debug topologies
+   
+
+Multiple Debug Targets may be attached to a single Debug Host. Debug
+Targets may be connected to any downstream facing port below a Debug
+Host (i.e. anywhere in the fabric, root port or external hub puts).
+A Debug Target may only connect to a Debug Host through a Root Hub port
+of the target. That means connection of a Debug Target to a Debug Host
+through the ports of an external hub is not supported.
+
+Below is a typical connection between Debug Host and Debug target. Two
+Debug targets are connected to a single Debug host.
+
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+  || |
+  ||_|
+  |_
+|
+ ___|
+|   HUB  |  |  Debug Target  |
+||  ||
+| Superspeed hub |  |  xHC with DbC  |
+||  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+   Debug stacks
+   
+
+Below is a software stack diagram of both Debug Host and Debug Target.
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|   debug App|  ||
+||  | system debug   |
+|   usb_debug|  | hooks  |
+||  ||
+|usbcore |  ||
+||  |debug capability|
+|xhci_hcd|  | driver |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+
+   Port Multiplexing
+   -
+
+A debug port is always multiplexed with the first xHCI root hub port.
+Whenever debug capability is supported and enabled, and the first root
+hub port is detected to be connected to a downstream super-speed port
+of a Debug Host, the root hub port is assigned to the debug capability
+and operating i

[PATCH v4 09/12] x86: early_printk: add USB3 debug port earlyprintk support

2015-11-16 Thread Lu Baolu
Add support for early printk by writing debug messages to the USB3
debug port. Users can use this type of early printk by specifying
kernel parameter of "earlyprintk=xdbc". This gives users a chance
of providing debug output.

Signed-off-by: Lu Baolu 
---
 Documentation/kernel-parameters.txt |  1 +
 arch/x86/kernel/early_printk.c  |  5 +
 drivers/usb/early/xhci-dbc.c| 43 +
 include/linux/usb/xhci-dbc.h|  5 +
 4 files changed, 54 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index f8aae63..cb879cd 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1049,6 +1049,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+   earlyprintk=xdbc[xhciController#]
 
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 21bf924..ba4c471 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -373,6 +374,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "dbgp", 4) && !early_dbgp_init(buf + 4))
early_console_register(&early_dbgp_console, keep);
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   if (!strncmp(buf, "xdbc", 4) && !early_xdbc_init(buf + 4))
+   early_console_register(&early_xdbc_console, keep);
+#endif
 #ifdef CONFIG_HVC_XEN
if (!strncmp(buf, "xen", 3))
early_console_register(&xenboot_console, keep);
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index aaf655f..68a7139 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -10,6 +10,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include 
 #include 
 #include 
 #include 
@@ -1332,3 +1333,45 @@ int xdbc_bulk_write(const char *bytes, int size)
 
return ret;
 }
+
+/*
+ * Start a bulk-in or bulk-out transfer, wait until transfer completion
+ * or error. Return the count of actually transferred bytes or error.
+ */
+static void early_xdbc_write(struct console *con, const char *str, u32 n)
+{
+   int chunk, ret;
+   static char buf[XDBC_MAX_PACKET];
+   int use_cr = 0;
+
+   if (!xdbcp->xdbc_reg)
+   return;
+   memset(buf, 0, XDBC_MAX_PACKET);
+   while (n > 0) {
+   for (chunk = 0; chunk < XDBC_MAX_PACKET && n > 0;
+str++, chunk++, n--) {
+   if (!use_cr && *str == '\n') {
+   use_cr = 1;
+   buf[chunk] = '\r';
+   str--;
+   n++;
+   continue;
+   }
+   if (use_cr)
+   use_cr = 0;
+   buf[chunk] = *str;
+   }
+   if (chunk > 0) {
+   ret = xdbc_bulk_write(buf, chunk);
+   if (ret < 0)
+   break;
+   }
+   }
+}
+
+struct console early_xdbc_console = {
+   .name = "earlyxdbc",
+   .write =early_xdbc_write,
+   .flags =CON_PRINTBUFFER,
+   .index =-1,
+};
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 289ba58..a556eb8 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -216,4 +216,9 @@ struct xdbc_state {
 #definexdbc_read64(regs)   xhci_read_64(NULL, (regs))
 #definexdbc_write64(val, regs) xhci_write_64(NULL, (val), (regs))
 
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+extern int early_xdbc_init(char *s);
+extern struct console early_xdbc_console;
+#endif /* CONFIG_EARLY_PRINTK_XDBC */
+
 #endif /* __LINUX_XHCI_DBC_H */
-- 
2.1.4

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


Re: Hit regression with TCP_TW REUSE/RECYCLE

2015-11-16 Thread Ethan Zhao
Tested the same case with 4.4-RC1, it was fixed in 4.4-RC1.
But don't know which commit fixed it.

 # echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
 # cat /proc/sys/net/ipv4/ip_local_port_range
102465535
 # echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
 #  cat /proc/sys/net/ipv4/tcp_tw_reuse
1
 # echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
 #  cat /proc/sys/net/ipv4/tcp_tw_reuse
1
 # ./accept -n 5 -r &
[1] 11866
 # port: 7954
ninst: 5
reuseport: 1

 # ./connect -i 127.0.0.1 -n 5 -d 10
78578.50
 # uname -a
Linux localhost.localdomain 4.4.0-rc1 #49 SMP Tue Nov 17 15:04:18 KST
2015 x86_64 x86_64 x86_64 GNU/Linux



Thanks,
Ethan

On Sun, Nov 15, 2015 at 12:14 PM, Ethan Zhao  wrote:
> Hi,
>
>When we tested network with following case, found there is
> regression with stable 4.1 kernel, connect() returns EADDRNOTAVAIL,
> while a pretty old kernel 3.8 doesn't.  anybody knows about this issue
> and if it was fixed later ? (I am looking for devices and will do a
> test with the last stable).
>
>
> #echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
> #echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
> #echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
> #./accept -n 5 -r &
> #./connect -i 127.0.0.1 -n 5 -d 10
>
>
> 
> connect.c
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> static void
> usage(const char *cmd)
> {
> fprintf(stderr, "Usage: %s -i IPv4 [-p port] "
> "[-n n_instance] [-d duration]\n", cmd);
> exit(1);
> }
>
> static int global_run = 1;
>
> static void
> signal_handler(int signum)
> {
> global_run = 0;
> }
>
> static void
> connect_loop(const struct sockaddr_in *in, const int duration, u_long *result)
> {
> struct itimerval it;
> int sock;
> u_long count = 0;
>
> if (signal(SIGALRM, signal_handler) == SIG_ERR) {
> fprintf(stderr, "signal() failed: %s\n", strerror(errno));
> return;
> }
>
> it.it_interval.tv_sec = 0;
> it.it_interval.tv_usec = 0;
> it.it_value.tv_sec = duration;
> it.it_value.tv_usec = 0;
> if (setitimer(ITIMER_REAL, &it, NULL) < 0) {
> fprintf(stderr, "setitimer() failed: %s\n", strerror(errno));
> return;
> }
>
> while (global_run) {
> sock = socket(AF_INET, SOCK_STREAM, 0);
> if (sock < 0) {
> fprintf(stderr, "socket() failed: %s\n", strerror(errno));
> }
> if (connect(sock, (const struct sockaddr *)in, sizeof(*in)) < 0) {
> fprintf(stderr, "connect() failed: %s\n", strerror(errno));
> }
> count++;
> close(sock);
> }
>
> *result = count;
> }
>
> int
> main(int argc, char *argv[])
> {
> char *bname;
> struct sockaddr_in in;
> int opt, port, ninst, duration, i;
> ulong *result, sum;
>
> memset(&in, 0, sizeof(in));
> in.sin_family = AF_INET;
>
> port = 7954;
> ninst = 1;
> duration = 10;
> bname = basename(argv[0]);
> while ((opt = getopt(argc, argv, "i:p:n:d:")) != -1) {
> switch (opt) {
> case 'i':
> if (inet_pton(AF_INET, optarg, &in.sin_addr) <= 0) {
> fprintf(stderr, "Invalid IPv4 address: %s\n", optarg);
> usage(bname);
> }
> break;
> case 'p':
> port = atoi(optarg);
> break;
> case 'n':
> ninst = atoi(optarg);
> break;
> case 'd':
> duration = atoi(optarg);
> break;
> default:
> usage(bname);
> }
> }
>
> if (port == 0 || ninst < 1 || duration < 1
> || in.sin_addr.s_addr == INADDR_ANY) {
> usage(bname);
> }
>
> in.sin_port = htons(port);
>
> result = mmap(NULL, ninst * sizeof(u_long), PROT_READ | PROT_WRITE,
> MAP_ANON | MAP_SHARED, -1, 0);
> if (result == MAP_FAILED) {
> fprintf(stderr, "mmap() failed: %s\n", strerror(errno));
> exit(1);
> }
> memset(result, 0, ninst * sizeof(u_long));
>
> for (i = 0; i < ninst; i++) {
> pid_t pid;
> pid = fork();
> if (pid == 0) { /* fork() succeeded, in child */
> connect_loop(&in, duration, &result[i]);
> exit(0);
> } else {
> if (pid < 0) { /* fork() failed */
> fprintf(stderr, "fork() failed: %s\n", strerror(errno));
> exit(1);
> }
> }
> }
>
> /* waiting for all children to terminate */
> while (wait(NULL)) {
> if (errno == ECHILD) {
> break;
> }
> }
>
> sum = 0;
> for (i = 0; i < ninst; i++) {
> sum += result[i];
> }
> printf("%.2f\n", (double)sum / (double)duration);
>
> exit(0);
> }
>

Re: [PATCH v3 1/5] spi: introduce mmap read support for spi flash devices

2015-11-16 Thread Vignesh R
Hi Brian,

On 11/13/2015 09:35 PM, Cyrille Pitchen wrote:

[...]

> 
> In September I've sent a series of patches to enhance the support of QSPI 
> flash
> memories. Patch 4 was dedicated to the m25p80 driver and set the
> rx_nbits / tx_nbits fields of spi_transfer struct(s) in order to configure the
> number of I/O lines independently for the opcode, address and data parts.
> The work was done for m25p80_read() but also for _read_reg(), _write_reg() and
> _write().
> The patched m25p80 driver was then tested with an at25 memory to check non-
> regression.
> 
> This series of patches also added 4 enum spi_protocol fields inside struct
> spi_nor so the spi-nor framework can tell the (Q)SPI controller driver what 
> SPI
> protocol should be use for erase, read, write and register read/write
> operations, depending on the memory manufacturer and the command opcode.
> This was done to better support Micron, Spansion and Macronix QSPI memories.
> 
> I have tested the series with Micron QSPI memories and Atmel QSPI controller
> and I guess Marek also tested it on his side with Spansion QSPI memories and
> another QSPI controller.
> 
> So if it can help other developers to develop QSPI controller drivers, the
> series is still available there:
> 
> for the whole series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371170.html
> 
> for patch 4 (depends on patch 2 for enum spi_protocol):
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/371173.html
> 

Should I rebase my next version on top of above patches by Cyrille or
shall I post on top of 4.4-rc1?

-- 
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RFC V3 0/3] basic busy polling support for vhost_net

2015-11-16 Thread Jason Wang


On 11/13/2015 05:20 PM, Jason Wang wrote:
>
> On 11/12/2015 08:02 PM, Felipe Franciosi wrote:
>> Hi Jason,
>>
>> I understand your busy loop timeout is quite conservative at 50us. Did you 
>> try any other values?
> I've also tried 20us. And results shows 50us was better in:
>
> - very small packet tx (e.g 64bytes at most 46% improvement)
> - TCP_RR (at most 11% improvement)
>
> But I will test bigger values. In fact, for net itself, we can be even
> more aggressive: make vhost poll forever but I haven't tired this.
>
>> Also, did you measure how polling affects many VMs talking to each other 
>> (e.g. 20 VMs on each host, perhaps with several vNICs each, transmitting to 
>> a corresponding VM/vNIC pair on another host)?
> Not yet, in my todo list.
>
>>
>> On a complete separate experiment (busy waiting on storage I/O rings on 
>> Xen), I have observed that bigger timeouts gave bigger benefits. On the 
>> other hand, all cases that contended for CPU were badly hurt with any sort 
>> of polling.
>>
>> The cases that contended for CPU consisted of many VMs generating workload 
>> over very fast I/O devices (in that case, several NVMe devices on a single 
>> host). And the metric that got affected was aggregate throughput from all 
>> VMs.
>>
>> The solution was to determine whether to poll depending on the host's 
>> overall CPU utilisation at that moment. That gave me the best of both worlds 
>> as polling made everything faster without slowing down any other metric.
> You mean a threshold and exit polling when it exceeds this? I use a
> simpler method: just exit the busy loop when there's more than one
> processes is in running state. I test this method in the past for socket
> busy read (http://www.gossamer-threads.com/lists/linux/kernel/1997531)
> which seems can solve the issue. But haven't tested this for vhost
> polling. Will run some simple test (e.g pin two vhost threads in one
> host cpu), and see how well it perform.
>
> Thanks

Run simple test like:

- starting two VMs, each vm has one vcpu
- pin both two vhost threads of VMs to cpu 0
- pin vcpu0 of VM1 to cpu1
- pin vcpu0 of VM2 to cpu2

Try two TCP_RR netperf tests in parallell:

/busy loop timeouts/trate1+trate2/-+%/
/no busy loop/13966.76+13987.31/+0%/
/20us/14097.89+14088.82/+0.08%)
/50us/15103.98+15103.73/+8.06%/


Busy loop can still give improvements even if two vhost threads are
contending one cpu on host.

>
>> Thanks,
>> Felipe
>>
>>
>>
>> On 12/11/2015 10:20, "kvm-ow...@vger.kernel.org on behalf of Jason Wang" 
>>  wrote:
>>
>>> On 11/12/2015 06:16 PM, Jason Wang wrote:
 Hi all:

 This series tries to add basic busy polling for vhost net. The idea is
 simple: at the end of tx/rx processing, busy polling for new tx added
 descriptor and rx receive socket for a while. The maximum number of
 time (in us) could be spent on busy polling was specified ioctl.

 Test were done through:

 - 50 us as busy loop timeout
 - Netperf 2.6
 - Two machines with back to back connected ixgbe
 - Guest with 1 vcpu and 1 queue

 Results:
 - For stream workload, ioexits were reduced dramatically in medium
   size (1024-2048) of tx (at most -39%) and almost all rx (at most
   -79%) as a result of polling. This compensate for the possible
   wasted cpu cycles more or less. That porbably why we can still see
   some increasing in the normalized throughput in some cases.
 - Throughput of tx were increased (at most 105%) expect for the huge
   write (16384). And we can send more packets in the case (+tpkts were
   increased).
 - Very minor rx regression in some cases.
 - Improvemnt on TCP_RR (at most 16%).
>>> Forget to mention, the following test results by order are:
>>>
>>> 1) Guest TX
>>> 2) Guest RX
>>> 3) TCP_RR
>>>
 size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/
64/ 1/   +9%/  -17%/   +5%/  +10%/   -2%
64/ 2/   +8%/  -18%/   +6%/  +10%/   -1%
64/ 4/   +4%/  -21%/   +6%/  +10%/   -1%
64/ 8/   +9%/  -17%/   +6%/   +9%/   -2%
   256/ 1/  +20%/   -1%/  +15%/  +11%/   -9%
   256/ 2/  +15%/   -6%/  +15%/   +8%/   -8%
   256/ 4/  +17%/   -4%/  +16%/   +8%/   -8%
   256/ 8/  -61%/  -69%/  +16%/  +10%/  -10%
   512/ 1/  +15%/   -3%/  +19%/  +18%/  -11%
   512/ 2/  +19%/0%/  +19%/  +13%/  -10%
   512/ 4/  +18%/   -2%/  +18%/  +15%/  -10%
   512/ 8/  +17%/   -1%/  +18%/  +15%/  -11%
  1024/ 1/  +25%/   +4%/  +27%/  +16%/  -21%
  1024/ 2/  +28%/   +8%/  +25%/  +15%/  -22%
  1024/ 4/  +25%/   +5%/  +25%/  +14%/  -21%
  1024/ 8/  +27%/   +7%/  +25%/  +16%/  -21%
  2048/ 1/  +32%/  +12%/  +31%/  +22%/  -38%
  2048/ 2/  +33%/  +12%/  +30%/  +23%/  -36%
  2048/ 4/  +31%/  +10%/  +31%/  +24%/  -37%
  2048/ 8/ +105%/  +75%/  +33%/  +23%/  -39%
 16384/ 1/0%/  -14%/   +2%/ 

Re: [PATCH v6 9/9] drivers: soc: Add support for Exynos PMU driver

2015-11-16 Thread Krzysztof Kozlowski
On 17.11.2015 15:05, Pankaj Dubey wrote:
> This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
> to "drivers/soc/samsung". This driver is mainly used for setting misc
> bits of register from PMU IP of Exynos SoC which will be required to
> configure before Suspend/Resume. Currently all these settings are done
> in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
> support, there is a need of this PMU driver in driver/* folder.
> 
> This driver uses existing DT binding information and there should
> be no functionality change in the supported platforms.
> 
> Signed-off-by: Amit Daniel Kachhap 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm/mach-exynos/Kconfig   | 1 +
>  arch/arm/mach-exynos/Makefile  | 4 +---
>  drivers/soc/samsung/Kconfig| 4 
>  drivers/soc/samsung/Makefile   | 2 ++
>  arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c | 0
>  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h | 0
>  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c | 0
>  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c| 0
>  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c | 0
>  {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c | 0
>  10 files changed, 8 insertions(+), 3 deletions(-)
>  rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (100%)
>  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h (100%)
>  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c (100%)
>  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c (100%)
>  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c (100%)
>  rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c (100%)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2 2/3] staging: ion: Add files for parsing the devicetree

2015-11-16 Thread Dan Carpenter
On Mon, Nov 16, 2015 at 04:57:34PM -0800, Laura Abbott wrote:
> + for_each_available_child_of_node(dt_node, node) {
> + struct platform_device *heap_pdev;
> +
> + ret = ion_parse_dt_heap_common(node, &heaps[i], compatible);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + heap_pdev = of_platform_device_create(node, heaps[i].name,
> + &pdev->dev);

We should free these if something fails later in the function.

> + if (!pdev)
> + return ERR_PTR(-ENOMEM);
> + heap_pdev->dev.platform_data = &heaps[i];
> +
> + heaps[i].priv = &heap_pdev->dev;
> +
> + ret = ion_setup_heap_common(pdev, node, &heaps[i]);
> + if (ret)
> + return ERR_PTR(ret);


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 v5 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

2015-11-16 Thread Kishon Vijay Abraham I
Hi,

On Monday 09 November 2015 10:56 AM, Alim Akhtar wrote:
> From: Seungwon Jeon 
> 
> This patch introduces Exynos UFS PHY driver. This driver
> supports to deal with phy calibration and power control
> according to UFS host driver's behavior.
> 
> Signed-off-by: Seungwon Jeon 
> Signed-off-by: Alim Akhtar 
> Cc: Kishon Vijay Abraham I 
> ---
>  drivers/phy/Kconfig|7 ++
>  drivers/phy/Makefile   |1 +
>  drivers/phy/phy-exynos-ufs.c   |  241 
> 
>  drivers/phy/phy-exynos-ufs.h   |   85 +
>  drivers/phy/phy-exynos7-ufs.h  |   89 +
>  include/linux/phy/phy-exynos-ufs.h |   85 +
>  6 files changed, 508 insertions(+)
>  create mode 100644 drivers/phy/phy-exynos-ufs.c
>  create mode 100644 drivers/phy/phy-exynos-ufs.h
>  create mode 100644 drivers/phy/phy-exynos7-ufs.h
>  create mode 100644 include/linux/phy/phy-exynos-ufs.h
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 7eb5859dd035..7d38a92e0297 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -389,4 +389,11 @@ config PHY_CYGNUS_PCIE
> Enable this to support the Broadcom Cygnus PCIe PHY.
> If unsure, say N.
>  
> +config PHY_EXYNOS_UFS
> + tristate "EXYNOS SoC series UFS PHY driver"
> + depends on OF && ARCH_EXYNOS || COMPILE_TEST
> + select GENERIC_PHY
> + help
> +   Support for UFS PHY on Samsung EXYNOS chipsets.
> +
>  endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 075db1a81aa5..9bec4d1a89e1 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)  += 
> phy-armada375-usb2.o
>  obj-$(CONFIG_BCM_KONA_USB2_PHY)  += phy-bcm-kona-usb2.o
>  obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+= phy-exynos-dp-video.o
>  obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)  += phy-exynos-mipi-video.o
> +obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
>  obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o
>  obj-$(CONFIG_PHY_PXA_28NM_USB2)  += phy-pxa-28nm-usb2.o
>  obj-$(CONFIG_PHY_PXA_28NM_HSIC)  += phy-pxa-28nm-hsic.o
> diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
> new file mode 100644
> index ..cb1aeaa3d4eb
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-ufs.c
> @@ -0,0 +1,241 @@
> +/*
> + * UFS PHY driver for Samsung EXYNOS SoC
> + *
> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
> + * Author: Seungwon Jeon 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "phy-exynos-ufs.h"
> +
> +#define for_each_phy_lane(phy, i) \
> + for (i = 0; i < (phy)->lane_cnt; i++)
> +#define for_each_phy_cfg(cfg) \
> + for (; (cfg)->id; (cfg)++)
> +
> +#define PHY_DEF_LANE_CNT 1
> +
> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
> + const struct exynos_ufs_phy_cfg *cfg, u8 lane)
> +{
> + enum {LANE_0, LANE_1}; /* lane index */
> +
> + switch (lane) {
> + case LANE_0:
> + writel(cfg->val, (phy)->reg_pma + cfg->off_0);
> + break;
> + case LANE_1:
> + if (cfg->id == PHY_TRSV_BLK)
> + writel(cfg->val, (phy)->reg_pma + cfg->off_1);
> + break;
> + }
> +}
> +
> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
> +{
> + if (IS_PWR_MODE_ANY(desc))
> + return true;
> +
> + if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
> + return true;
> +
> + if (COMP_PWR_MODE(required_pwr, desc))
> + return true;
> +
> + if (COMP_PWR_MODE_MD(required_pwr, desc) &&
> + COMP_PWR_MODE_GEAR(required_pwr, desc) &&
> + COMP_PWR_MODE_SER(required_pwr, desc))
> + return true;
> +
> + return false;
> +}
> +
> +int exynos_ufs_phy_calibrate(struct phy *phy,
> + enum phy_cfg_tag tag, u8 pwr)

This is similar to the first version of your patch without EXPORT_SYMBOL.

I think you have to create a new generic PHY_OPS for calibrate PHY while making
sure that it is as generic as possible (which means calibrate_phy shouldn't
have tag and pwr arguments or a strong justification as to why those arguments
are required in a generic API).
> +{
> + struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
> + struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
> + const struct exynos_ufs_phy_cfg *cfg;
> + int i;
> +
> + if (unlikely(tag < CFG_PRE_INIT || tag >= CFG_TAG_MAX)) {
> + 

Re: [PATCH] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity

2015-11-16 Thread Greg KH
On Tue, Nov 17, 2015 at 02:02:58PM +0800, Chunfeng Yun wrote:
> when use the default value 8 of RG_USB20_SQTH, the HS receiver
> sensitivity test of HQA will fail, set it as 2 to fix up the
> issue.
> 
> Change-Id: Ia5bdbbfc8ebb170d3ef26007e665b7350b6d28ab

What is this field for?  Hint, it should never be there for a patch you
submit upstream as it means nothing...

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


[PATCH v6 9/9] drivers: soc: Add support for Exynos PMU driver

2015-11-16 Thread Pankaj Dubey
This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
to "drivers/soc/samsung". This driver is mainly used for setting misc
bits of register from PMU IP of Exynos SoC which will be required to
configure before Suspend/Resume. Currently all these settings are done
in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
support, there is a need of this PMU driver in driver/* folder.

This driver uses existing DT binding information and there should
be no functionality change in the supported platforms.

Signed-off-by: Amit Daniel Kachhap 
Signed-off-by: Pankaj Dubey 
---
 arch/arm/mach-exynos/Kconfig   | 1 +
 arch/arm/mach-exynos/Makefile  | 4 +---
 drivers/soc/samsung/Kconfig| 4 
 drivers/soc/samsung/Makefile   | 2 ++
 arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c | 0
 {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h | 0
 {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c | 0
 {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c| 0
 {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c | 0
 {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c | 0
 10 files changed, 8 insertions(+), 3 deletions(-)
 rename arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c (100%)
 rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h (100%)
 rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c (100%)
 rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c (100%)
 rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c (100%)
 rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c (100%)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..874cb38 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,6 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
+   select EXYNOS_PMU
select EXYNOS_SROM if PM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2d58063..34d29df 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,9 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
-I$(srctree)/$(src)/include -I$(srctree)
 
 # Core
 
-obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o \
-   exynos3250-pmu.o exynos4-pmu.o \
-   exynos5250-pmu.o exynos5420-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o exynos-smc.o firmware.o
 
 obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
 obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..5855469 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -10,4 +10,8 @@ config EXYNOS_SROM
bool
depends on ARM && ARCH_EXYNOS && PM
 
+config EXYNOS_PMU
+   bool
+   depends on ARM && ARCH_EXYNOS
+
 endmenu
diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
index 9c554d5..cef7970 100644
--- a/drivers/soc/samsung/Makefile
+++ b/drivers/soc/samsung/Makefile
@@ -1 +1,3 @@
 obj-$(CONFIG_EXYNOS_SROM)  += exynos-srom.o
+obj-$(CONFIG_EXYNOS_PMU)   += exynos-pmu.o exynos3250-pmu.o exynos4-pmu.o \
+   exynos5250-pmu.o exynos5420-pmu.o
diff --git a/arch/arm/mach-exynos/pmu.c b/drivers/soc/samsung/exynos-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/pmu.c
rename to drivers/soc/samsung/exynos-pmu.c
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/drivers/soc/samsung/exynos-pmu.h
similarity index 100%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to drivers/soc/samsung/exynos-pmu.h
diff --git a/arch/arm/mach-exynos/exynos3250-pmu.c 
b/drivers/soc/samsung/exynos3250-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos3250-pmu.c
rename to drivers/soc/samsung/exynos3250-pmu.c
diff --git a/arch/arm/mach-exynos/exynos4-pmu.c 
b/drivers/soc/samsung/exynos4-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos4-pmu.c
rename to drivers/soc/samsung/exynos4-pmu.c
diff --git a/arch/arm/mach-exynos/exynos5250-pmu.c 
b/drivers/soc/samsung/exynos5250-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos5250-pmu.c
rename to drivers/soc/samsung/exynos5250-pmu.c
diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c 
b/drivers/soc/samsung/exynos5420-pmu.c
similarity index 100%
rename from arch/arm/mach-exynos/exynos5420-pmu.c
rename to drivers/soc/samsung/exynos5420-pmu.c
-- 
2.4.5

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

[PATCH v6 8/9] ARM: EXYNOS: rearrange static and non-static functions of PMU driver

2015-11-16 Thread Pankaj Dubey
This patch moves exynos_sys_powerdown_conf function above all
static functions, to avoid confusion causing due to mixing of
static-nonstatic-static functions and to improve readability of this
driver.

Signed-off-by: Pankaj Dubey 
Suggested-by: Krzysztof Kozlowski 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/pmu.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 01cb649..a7741d4 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -39,23 +39,6 @@ u32 pmu_raw_readl(u32 offset)
return readl_relaxed(pmu_base_addr + offset);
 }
 
-static void exynos_power_off(void)
-{
-   unsigned int tmp;
-
-   pr_info("Power down.\n");
-   tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
-   tmp ^= (1 << 8);
-   pmu_raw_writel(tmp, EXYNOS_PS_HOLD_CONTROL);
-
-   /* Wait a little so we don't give a false warning below */
-   mdelay(100);
-
-   pr_err("Power down failed, please power off system manually.\n");
-   while (1)
-   ;
-}
-
 void exynos_sys_powerdown_conf(enum sys_powerdown mode)
 {
unsigned int i;
@@ -85,6 +68,23 @@ void exynos_sys_powerdown_conf(enum sys_powerdown mode)
}
 }
 
+static void exynos_power_off(void)
+{
+   unsigned int tmp;
+
+   pr_info("Power down.\n");
+   tmp = pmu_raw_readl(EXYNOS_PS_HOLD_CONTROL);
+   tmp ^= (1 << 8);
+   pmu_raw_writel(tmp, EXYNOS_PS_HOLD_CONTROL);
+
+   /* Wait a little so we don't give a false warning below */
+   mdelay(100);
+
+   pr_err("Power down failed, please power off system manually.\n");
+   while (1)
+   ;
+}
+
 static int pmu_restart_notify(struct notifier_block *this,
unsigned long code, void *unused)
 {
-- 
2.4.5

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


[PATCH v6 7/9] ARM: EXYNOS: split up exynos5420 SoC specific PMU data

2015-11-16 Thread Pankaj Dubey
This patch splits up mach-exynos/pmu.c file, and moves exynos5420,
PMU configuration data and functions handing data into exynos5420
SoC specific PMU file mach-exynos/exynos5420-pmu.c.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/Makefile |   2 +-
 arch/arm/mach-exynos/exynos-pmu.h |   1 +
 arch/arm/mach-exynos/exynos5420-pmu.c | 280 ++
 arch/arm/mach-exynos/pmu.c| 263 ---
 4 files changed, 282 insertions(+), 264 deletions(-)
 create mode 100644 arch/arm/mach-exynos/exynos5420-pmu.c

diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index bfb23a5..2d58063 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -11,7 +11,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
-I$(srctree)/$(src)/include -I$(srctree)
 
 obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o \
exynos3250-pmu.o exynos4-pmu.o \
-   exynos5250-pmu.o
+   exynos5250-pmu.o exynos5420-pmu.o
 
 obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
 obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/arch/arm/mach-exynos/exynos-pmu.h
index 85c858d..a469e36 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -37,6 +37,7 @@ extern const struct exynos_pmu_data exynos4210_pmu_data;
 extern const struct exynos_pmu_data exynos4212_pmu_data;
 extern const struct exynos_pmu_data exynos4412_pmu_data;
 extern const struct exynos_pmu_data exynos5250_pmu_data;
+extern const struct exynos_pmu_data exynos5420_pmu_data;
 
 extern void pmu_raw_writel(u32 val, u32 offset);
 extern u32 pmu_raw_readl(u32 offset);
diff --git a/arch/arm/mach-exynos/exynos5420-pmu.c 
b/arch/arm/mach-exynos/exynos5420-pmu.c
new file mode 100644
index 000..b962fb6
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos5420-pmu.c
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS5420 - CPU PMU (Power Management Unit) support
+ *
+ * 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 "exynos-pmu.h"
+
+static struct exynos_pmu_conf exynos5420_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+   { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_ARM_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_ARM_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_ARM_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE0_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE1_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE2_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE2_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_CORE3_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_LOCAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_DIS_IRQ_KFC_CORE3_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5_ISP_ARM_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x1, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5420_ARM_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_COMMON_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS5_ARM_L2_SYS_PWR_REG,   { 0x0, 0x0, 0x0} },
+   { EXYNOS5420_KFC_L2_SYS_PWR_REG,   

[PATCH v6 6/9] ARM: EXYNOS: split up exynos5250 SoC specific PMU data

2015-11-16 Thread Pankaj Dubey
This patch splits up mach-exynos/pmu.c file, and moves exynos5250,
PMU configuration data and functions handing data into exynos5250
SoC specific PMU file mach-exynos/exynos5250-pmu.c.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/Makefile |   4 +-
 arch/arm/mach-exynos/exynos-pmu.h |   1 +
 arch/arm/mach-exynos/exynos5250-pmu.c | 195 ++
 arch/arm/mach-exynos/pmu.c| 180 ---
 4 files changed, 199 insertions(+), 181 deletions(-)
 create mode 100644 arch/arm/mach-exynos/exynos5250-pmu.c

diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 8969683..bfb23a5 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,9 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
-I$(srctree)/$(src)/include -I$(srctree)
 
 # Core
 
-obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o 
exynos3250-pmu.o exynos4-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o \
+   exynos3250-pmu.o exynos4-pmu.o \
+   exynos5250-pmu.o
 
 obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
 obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/arch/arm/mach-exynos/exynos-pmu.h
index 3d21aad..85c858d 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -36,6 +36,7 @@ extern const struct exynos_pmu_data exynos3250_pmu_data;
 extern const struct exynos_pmu_data exynos4210_pmu_data;
 extern const struct exynos_pmu_data exynos4212_pmu_data;
 extern const struct exynos_pmu_data exynos4412_pmu_data;
+extern const struct exynos_pmu_data exynos5250_pmu_data;
 
 extern void pmu_raw_writel(u32 val, u32 offset);
 extern u32 pmu_raw_readl(u32 offset);
diff --git a/arch/arm/mach-exynos/exynos5250-pmu.c 
b/arch/arm/mach-exynos/exynos5250-pmu.c
new file mode 100644
index 000..3fac425
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos5250-pmu.c
@@ -0,0 +1,195 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS5250 - CPU PMU (Power Management Unit) support
+ *
+ * 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 "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos5250_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+   { EXYNOS5_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS5_FSYS_ARM_SYS_PWR_REG, { 0x1, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_FSYS_ARM_CENTRAL_SYS_PWR_REG, { 0x1, 0x1, 0x1} },
+   { EXYNOS5_ISP_ARM_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS5_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS5_ARM_COMMON_SYS_PWR_REG,   { 0x0, 0x0, 0x2} },
+   { EXYNOS5_ARM_L2_SYS_PWR_REG,   { 0x3, 0x3, 0x3} },
+   { EXYNOS5_ARM_L2_OPTION,{ 0x10, 0x10, 0x0 } },
+   { EXYNOS5_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+   { EXYNOS5_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x0, 0x1} },
+   { EXYNOS5_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+   { EXYNOS5_CMU_ACLKSTOP_SYSMEM_SYS_PWR_REG,  { 0x1, 0x0, 0x1} },
+   { EXYNOS5_CMU_SCLKSTOP_SYSMEM_SYS_PWR_REG,  { 0x1, 0x0, 0x1} },
+   { EXYNOS5_CMU_RESET_SYSMEM_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+   { EXYNOS5_DRAM_FREQ_DOWN_SYS_PWR_REG,   { 0x1, 0x1, 0x1} },
+   { EXYNOS5_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 0x1} },
+   { EXYNOS5_DDRPHY_DLLLOCK_SYS_PWR_REG,   { 0x1, 0x1, 0x1} },
+   { EXYNOS5_APLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_MPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_VPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_EPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x1, 0x0} },
+   { EXYNOS5_BPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_CPLL_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_MPLLUSER_SYSCLK_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS5_BPLLUSER_SYSCLK_SYS_PWR_REG,

Re: [PATCH 1/7] phy: brcmstb-sata: add missing of_node_put

2015-11-16 Thread Julia Lawall


On Mon, 16 Nov 2015, Brian Norris wrote:

> On Mon, Nov 16, 2015 at 12:33:14PM +0100, Julia Lawall wrote:
> > for_each_available_child_of_node performs an of_node_get on each iteration,
> > so a return from the middle of the loop requires an of_node_put.
> > 
> > A simplified version of the semantic patch that finds this problem is as
> > follows (http://coccinelle.lip6.fr):
> > 
> > // 
> > @@
> > expression root,e;
> > local idexpression child;
> > @@
> > 
> >  for_each_available_child_of_node(root, child) {
> >... when != of_node_put(child)
> >when != e = child
> > (
> >return child;
> > |
> > *  return ...;
> > )
> >...
> >  }
> > // 
> > 
> > Signed-off-by: Julia Lawall 
> > 
> > ---
> 
> For this patch:
> 
> Acked-by: Brian Norris 
> 
> >  drivers/phy/phy-brcmstb-sata.c |   17 -
> >  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> [snip patch, which fixes of_node_put() handling for
> for_each_available_child_of_node() loop, which creates PHY devices with
> devm_phy_create()]
> 
> This reminds me of a potential problem I'm looking at in other
> subsystems: from code reading (I haven't seen any issues in practice,
> probably because I don't use OF_DYNAMIC) it looks like device-creating
> infrastructure like the PHY subsystem should be acquiring a reference to
> the device_node when they stash it away. But drivers/phy/phy-core.c does
> not do this, AFAICT.
> 
> See phy_create(), which does
> 
>   phy->dev.of_node = node ?: dev->of_node;
> 
> and later might reuse this of_node pointer, even though it never called
> of_node_get() on this node.
> 
> Potential patch to fix this (not tested).
> 
> Signed-off-by: Brian Norris 
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index fc48fac003a6..8df29caeeef9 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -697,6 +697,7 @@ struct phy *phy_create(struct device *dev, struct 
> device_node *node,
>   phy->dev.class = phy_class;
>   phy->dev.parent = dev;
>   phy->dev.of_node = node ?: dev->of_node;
> + of_node_get(phy->dev.of_node);

Why not put of_node_get around dev->of_node?

julia

>   phy->id = id;
>   phy->ops = ops;
>  
> @@ -726,6 +727,7 @@ struct phy *phy_create(struct device *dev, struct 
> device_node *node,
>   return phy;
>  
>  put_dev:
> + of_node_put(phy->dev.of_node);
>   put_device(&phy->dev);  /* calls phy_release() which frees resources */
>   return ERR_PTR(ret);
>  
> @@ -775,6 +777,7 @@ EXPORT_SYMBOL_GPL(devm_phy_create);
>   */
>  void phy_destroy(struct phy *phy)
>  {
> + of_node_put(phy->dev.of_node);
>   pm_runtime_disable(&phy->dev);
>   device_unregister(&phy->dev);
>  }
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH v6 5/9] ARM: EXYNOS: split up exynos4 SoC specific PMU data

2015-11-16 Thread Pankaj Dubey
This patch splits up mach-exynos/pmu.c file, and moves exynos4210,
exynos4412 and exynos4212 PMU configuration data and functions handing
data into a common exynos4 SoC specific PMU file mach-exynos/exynos4-pmu.c.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/Makefile  |   2 +-
 arch/arm/mach-exynos/exynos-pmu.h  |   3 +
 arch/arm/mach-exynos/exynos4-pmu.c | 222 +
 arch/arm/mach-exynos/pmu.c | 207 --
 4 files changed, 226 insertions(+), 208 deletions(-)
 create mode 100644 arch/arm/mach-exynos/exynos4-pmu.c

diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index e869f86..8969683 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
-I$(srctree)/$(src)/include -I$(srctree)
 
 # Core
 
-obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o 
exynos3250-pmu.o
+obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o 
exynos3250-pmu.o exynos4-pmu.o
 
 obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
 obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/arch/arm/mach-exynos/exynos-pmu.h
index 5d09fa3..3d21aad 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -33,6 +33,9 @@ struct exynos_pmu_data {
 extern void __iomem *pmu_base_addr;
 /* list of all exported SoC specific data */
 extern const struct exynos_pmu_data exynos3250_pmu_data;
+extern const struct exynos_pmu_data exynos4210_pmu_data;
+extern const struct exynos_pmu_data exynos4212_pmu_data;
+extern const struct exynos_pmu_data exynos4412_pmu_data;
 
 extern void pmu_raw_writel(u32 val, u32 offset);
 extern u32 pmu_raw_readl(u32 offset);
diff --git a/arch/arm/mach-exynos/exynos4-pmu.c 
b/arch/arm/mach-exynos/exynos4-pmu.c
new file mode 100644
index 000..bc4fa73
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos4-pmu.c
@@ -0,0 +1,222 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS4 - CPU PMU(Power Management Unit) support
+ *
+ * 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 "exynos-pmu.h"
+
+static const struct exynos_pmu_conf exynos4210_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, LPA, SLEEP } */
+   { S5P_ARM_CORE0_LOWPWR, { 0x0, 0x0, 0x2 } },
+   { S5P_DIS_IRQ_CORE0,{ 0x0, 0x0, 0x0 } },
+   { S5P_DIS_IRQ_CENTRAL0, { 0x0, 0x0, 0x0 } },
+   { S5P_ARM_CORE1_LOWPWR, { 0x0, 0x0, 0x2 } },
+   { S5P_DIS_IRQ_CORE1,{ 0x0, 0x0, 0x0 } },
+   { S5P_DIS_IRQ_CENTRAL1, { 0x0, 0x0, 0x0 } },
+   { S5P_ARM_COMMON_LOWPWR,{ 0x0, 0x0, 0x2 } },
+   { S5P_L2_0_LOWPWR,  { 0x2, 0x2, 0x3 } },
+   { S5P_L2_1_LOWPWR,  { 0x2, 0x2, 0x3 } },
+   { S5P_CMU_ACLKSTOP_LOWPWR,  { 0x1, 0x0, 0x0 } },
+   { S5P_CMU_SCLKSTOP_LOWPWR,  { 0x1, 0x0, 0x0 } },
+   { S5P_CMU_RESET_LOWPWR, { 0x1, 0x1, 0x0 } },
+   { S5P_APLL_SYSCLK_LOWPWR,   { 0x1, 0x0, 0x0 } },
+   { S5P_MPLL_SYSCLK_LOWPWR,   { 0x1, 0x0, 0x0 } },
+   { S5P_VPLL_SYSCLK_LOWPWR,   { 0x1, 0x0, 0x0 } },
+   { S5P_EPLL_SYSCLK_LOWPWR,   { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_GPS_ALIVE_LOWPWR, { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_GPSALIVE_LOWPWR,{ 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_CAM_LOWPWR,   { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_TV_LOWPWR,{ 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_MFC_LOWPWR,   { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_G3D_LOWPWR,   { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_LCD0_LOWPWR,  { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_LCD1_LOWPWR,  { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_MAUDIO_LOWPWR,{ 0x1, 0x1, 0x0 } },
+   { S5P_CMU_CLKSTOP_GPS_LOWPWR,   { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_CAM_LOWPWR, { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_TV_LOWPWR,  { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_MFC_LOWPWR, { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_G3D_LOWPWR, { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_LCD0_LOWPWR,{ 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_LCD1_LOWPWR,{ 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_MAUDIO_LOWPWR,  { 0x1, 0x1, 0x0 } },
+   { S5P_CMU_RESET_GPS_LOWPWR, { 0x1, 0x1, 0x0 } },
+   { S5P_TOP_BUS_LOWPWR,   {

[PATCH v6 4/9] ARM: EXYNOS: split up exynos3250 SoC specific PMU data

2015-11-16 Thread Pankaj Dubey
This patch splits up mach-exynos/pmu.c file, and moves exynos3250 PMU
configuration data and functions handing those data into exynos3250
SoC specific PMU file mach-exynos/exynos3250-pmu.c.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/Makefile |   2 +-
 arch/arm/mach-exynos/exynos-pmu.h |  39 +++
 arch/arm/mach-exynos/exynos.c |   2 -
 arch/arm/mach-exynos/exynos3250-pmu.c | 175 
 arch/arm/mach-exynos/pmu.c| 184 +-
 5 files changed, 219 insertions(+), 183 deletions(-)
 create mode 100644 arch/arm/mach-exynos/exynos-pmu.h
 create mode 100644 arch/arm/mach-exynos/exynos3250-pmu.c

diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 2f30676..e869f86 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -9,7 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += 
-I$(srctree)/$(src)/include -I$(srctree)
 
 # Core
 
-obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o
+obj-$(CONFIG_ARCH_EXYNOS)  += exynos.o pmu.o exynos-smc.o firmware.o 
exynos3250-pmu.o
 
 obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
 obj-$(CONFIG_PM_SLEEP) += suspend.o
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/arch/arm/mach-exynos/exynos-pmu.h
new file mode 100644
index 000..5d09fa3
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos-pmu.h
@@ -0,0 +1,39 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Header for EXYNOS PMU Driver support
+ *
+ * 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.
+ */
+
+#ifndef __EXYNOS_PMU_H
+#define __EXYNOS_PMU_H
+
+#include 
+
+#define PMU_TABLE_END  (-1U)
+
+struct exynos_pmu_conf {
+   unsigned int offset;
+   u8 val[NUM_SYS_POWERDOWN];
+};
+
+struct exynos_pmu_data {
+   const struct exynos_pmu_conf *pmu_config;
+   const struct exynos_pmu_conf *pmu_config_extra;
+
+   void (*pmu_init)(void);
+   void (*powerdown_conf)(enum sys_powerdown);
+   void (*powerdown_conf_extra)(enum sys_powerdown);
+};
+
+extern void __iomem *pmu_base_addr;
+/* list of all exported SoC specific data */
+extern const struct exynos_pmu_data exynos3250_pmu_data;
+
+extern void pmu_raw_writel(u32 val, u32 offset);
+extern u32 pmu_raw_readl(u32 offset);
+#endif /* __EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 5d68ce8..ce368c8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -33,8 +33,6 @@
 #include "common.h"
 #include "mfc.h"
 
-void __iomem *pmu_base_addr;
-
 static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S5P_VA_CMU,
diff --git a/arch/arm/mach-exynos/exynos3250-pmu.c 
b/arch/arm/mach-exynos/exynos3250-pmu.c
new file mode 100644
index 000..20b3ab8
--- /dev/null
+++ b/arch/arm/mach-exynos/exynos3250-pmu.c
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2011-2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * EXYNOS3250 - CPU PMU (Power Management Unit) support
+ *
+ * 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 "exynos-pmu.h"
+
+static struct exynos_pmu_conf exynos3250_pmu_config[] = {
+   /* { .offset = offset, .val = { AFTR, W-AFTR, SLEEP } */
+   { EXYNOS3_ARM_CORE0_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE0_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE0_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS3_ARM_CORE1_SYS_PWR_REG,{ 0x0, 0x0, 0x2} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE1_LOCAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ARM_CORE1_CENTRAL_SYS_PWR_REG, { 0x0, 0x0, 0x0} },
+   { EXYNOS3_ISP_ARM_SYS_PWR_REG,  { 0x1, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ISP_ARM_LOCAL_SYS_PWR_REG,{ 0x0, 0x0, 0x0} },
+   { EXYNOS3_DIS_IRQ_ISP_ARM_CENTRAL_SYS_PWR_REG,  { 0x0, 0x0, 0x0} },
+   { EXYNOS3_ARM_COMMON_SYS_PWR_REG,   { 0x0, 0x0, 0x2} },
+   { EXYNOS3_ARM_L2_SYS_PWR_REG,   { 0x0, 0x0, 0x3} },
+   { EXYNOS3_CMU_ACLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+   { EXYNOS3_CMU_SCLKSTOP_SYS_PWR_REG, { 0x1, 0x1, 0x0} },
+   { EXYNOS3_CMU_RESET_SYS_PWR_REG,{ 0x1, 0x1, 0x0} },
+   { EXYNOS3_DRAM_FREQ_DOWN_SYS_PWR_REG,   { 0x1, 0x1, 0x1} },
+   { EXYNOS3_DDRPHY_DLLOFF_SYS_PWR_REG,{ 0x1, 0x1, 0x1} },
+   { EXYNOS3_LPDDR_PHY_DLL_LOCK_SYS_PWR_REG,   { 0x1, 0x1, 0x1} },
+  

Re: [PATCH v6 0/9] samsung: pmu: split up SoC specific PMU data

2015-11-16 Thread Krzysztof Kozlowski
On 17.11.2015 15:05, Pankaj Dubey wrote:
> In this series I am splitting up SoC specific PMU configuration data into
> mach-exynos folder itself, before moving all of them under
> drivers/soc/samsung/. Also instead of making all changes in single patch it
> has been broken into SoC specific patches to avoid large size of patch.
> With this approach there will not be unwanted big churns just after
> adding exynos-pmu under drivers/soc/samsung.
> 
> All these patches are just refactoring to keep minimal changes while moving
> exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can
> be added on top of it, in such a manner that for ARM64 build, ARM related
> SoC's PMU will not get compiled and thus unnecessary increasing kernel image 
> size.
> 
> These patches have been prepared on top of Kukjin Kim's for-next merged with
> driver-samsung and on top of
> cherry-picked change from [1].
> 
> 1: ARM: EXYNOS: Constify local exynos_pmu_data structure
>https://lkml.org/lkml/2015/10/28/917
> 
> For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for boot
> and S2R functionality.
> 
> Tested-by: Pankaj Dubey 
> 
> For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff)
> and Odroid XU3 (Exynos5422, reboot, poweroff).
> 
> Tested-by: Krzysztof Kozlowski 

Don't add it here. It will get lost.

Tags given to a cover letter applies for all patches so this tested-by
should be added to each patch.

Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 3/9] ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"

2015-11-16 Thread Pankaj Dubey
Moving Exynos PMU specific header file into "include/linux/soc/samsung"
thus updated affected files under "mach-exynos" to use new location of
these header files.

Signed-off-by: Amit Daniel Kachhap 
Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/exynos.c   | 2 +-
 arch/arm/mach-exynos/mcpm-exynos.c  | 2 +-
 arch/arm/mach-exynos/platsmp.c  | 2 +-
 arch/arm/mach-exynos/pm.c   | 4 ++--
 arch/arm/mach-exynos/pmu.c  | 6 +++---
 arch/arm/mach-exynos/suspend.c  | 4 ++--
 {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h| 6 +++---
 .../regs-pmu.h => include/linux/soc/samsung/exynos-regs-pmu.h   | 6 +++---
 8 files changed, 16 insertions(+), 16 deletions(-)
 rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (81%)
 rename arch/arm/mach-exynos/regs-pmu.h => 
include/linux/soc/samsung/exynos-regs-pmu.h (99%)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 4ffb90e..5d68ce8 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,7 +32,6 @@
 
 #include "common.h"
 #include "mfc.h"
-#include "regs-pmu.h"
 
 void __iomem *pmu_base_addr;
 
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c 
b/arch/arm/mach-exynos/mcpm-exynos.c
index 5697819..f086bf6 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -16,13 +16,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 
-#include "regs-pmu.h"
 #include "common.h"
 
 #define EXYNOS5420_CPUS_PER_CLUSTER4
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 98a2c0c..d5caf30 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -30,7 +31,6 @@
 #include 
 
 #include "common.h"
-#include "regs-pmu.h"
 
 extern void exynos4_secondary_startup(void);
 
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 9c1506b..b9b9186 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -29,8 +31,6 @@
 #include 
 
 #include "common.h"
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
 
 static inline void __iomem *exynos_boot_vector_addr(void)
 {
diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index d40f7e9..3974f52 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -17,10 +17,10 @@
 #include 
 #include 
 
-#include 
+#include 
+#include 
 
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
+#include 
 
 #define PMU_TABLE_END  (-1U)
 
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 237653e..f216909 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -37,8 +39,6 @@
 #include 
 
 #include "common.h"
-#include "exynos-pmu.h"
-#include "regs-pmu.h"
 
 #define REG_TABLE_END (-1U)
 
diff --git a/arch/arm/mach-exynos/exynos-pmu.h 
b/include/linux/soc/samsung/exynos-pmu.h
similarity index 81%
rename from arch/arm/mach-exynos/exynos-pmu.h
rename to include/linux/soc/samsung/exynos-pmu.h
index a2ab0d5..e2e9de1 100644
--- a/arch/arm/mach-exynos/exynos-pmu.h
+++ b/include/linux/soc/samsung/exynos-pmu.h
@@ -9,8 +9,8 @@
  * published by the Free Software Foundation.
  */
 
-#ifndef __EXYNOS_PMU_H
-#define __EXYNOS_PMU_H
+#ifndef __LINUX_SOC_EXYNOS_PMU_H
+#define __LINUX_SOC_EXYNOS_PMU_H
 
 enum sys_powerdown {
SYS_AFTR,
@@ -21,4 +21,4 @@ enum sys_powerdown {
 
 extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
 
-#endif /* __EXYNOS_PMU_H */
+#endif /* __LINUX_SOC_EXYNOS_PMU_H */
diff --git a/arch/arm/mach-exynos/regs-pmu.h 
b/include/linux/soc/samsung/exynos-regs-pmu.h
similarity index 99%
rename from arch/arm/mach-exynos/regs-pmu.h
rename to include/linux/soc/samsung/exynos-regs-pmu.h
index 5e4f4c2..d30186e 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/include/linux/soc/samsung/exynos-regs-pmu.h
@@ -9,8 +9,8 @@
  * published by the Free Software Foundation.
 */
 
-#ifndef __ASM_ARCH_REGS_PMU_H
-#define __ASM_ARCH_REGS_PMU_H __FILE__
+#ifndef __LINUX_SOC_EXYNOS_REGS_PMU_H
+#define __LINUX_SOC_EXYNOS_REGS_PMU_H __FILE__
 
 #define S5P_CENTRAL_SEQ_CONFIGURATION  0x0200
 
@@ -690,4 +690,4 @@
 | EXYNOS5420_KFC_USE_STANDBY_WFI2  \
 | EXYNOS5420_KFC_USE_STANDBY_WFI3)
 
-#endif /* __ASM_ARCH_REGS_P

[PATCH v6 2/9] ARM: EXYNOS: Fix potential NULL pointer access in exynos_sys_powerdown_conf

2015-11-16 Thread Pankaj Dubey
If no platform devices binded to the driver but driver itself loaded and
exynos_sys_powerdown_conf is called from
arch/arm/mach-exynos/{suspend.c, pm.c} it will result in NULL pointer access,
to prevent this added check on pmu_context for NULL.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/pmu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 64ea7d6..d40f7e9 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -749,8 +749,12 @@ static void exynos5_powerdown_conf(enum sys_powerdown mode)
 void exynos_sys_powerdown_conf(enum sys_powerdown mode)
 {
unsigned int i;
+   const struct exynos_pmu_data *pmu_data;
+
+   if (!pmu_context)
+   return;
 
-   const struct exynos_pmu_data *pmu_data = pmu_context->pmu_data;
+   pmu_data = pmu_context->pmu_data;
 
if (pmu_data->powerdown_conf)
pmu_data->powerdown_conf(mode);
-- 
2.4.5

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


[PATCH v6 1/9] ARM: EXYNOS: removing redundant code from regs-pmu.h

2015-11-16 Thread Pankaj Dubey
commit 6ec4f8d0d91f ("ARM: EXYNOS: add generic function to calculate
cpu number") introduced exynos_pmu_cpunr to be used by multi-cluster SoC's
e.g Exynos5420, but it's no more used in the codebase and hence removing
this part of code.

Signed-off-by: Pankaj Dubey 
Reviewed-by: Krzysztof Kozlowski 
---
 arch/arm/mach-exynos/pmu.c  | 1 +
 arch/arm/mach-exynos/regs-pmu.h | 9 -
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index 5775154..64ea7d6 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 
+#include 
 
 #include "exynos-pmu.h"
 #include "regs-pmu.h"
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index fba9068..5e4f4c2 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -484,15 +484,6 @@
 
 #define EXYNOS5420_SWRESET_KFC_SEL 0x3
 
-#include 
-#define MAX_CPUS_IN_CLUSTER4
-
-static inline unsigned int exynos_pmu_cpunr(unsigned int mpidr)
-{
-   return ((MPIDR_AFFINITY_LEVEL(mpidr, 1) * MAX_CPUS_IN_CLUSTER)
-+ MPIDR_AFFINITY_LEVEL(mpidr, 0));
-}
-
 /* Only for EXYNOS5420 */
 #define EXYNOS5420_ISP_ARM_OPTION  0x2488
 #define EXYNOS5420_L2RSTDISABLE_VALUE  BIT(3)
-- 
2.4.5

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


[PATCH v6 0/9] samsung: pmu: split up SoC specific PMU data

2015-11-16 Thread Pankaj Dubey
In this series I am splitting up SoC specific PMU configuration data into
mach-exynos folder itself, before moving all of them under
drivers/soc/samsung/. Also instead of making all changes in single patch it
has been broken into SoC specific patches to avoid large size of patch.
With this approach there will not be unwanted big churns just after
adding exynos-pmu under drivers/soc/samsung.

All these patches are just refactoring to keep minimal changes while moving
exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can
be added on top of it, in such a manner that for ARM64 build, ARM related
SoC's PMU will not get compiled and thus unnecessary increasing kernel image 
size.

These patches have been prepared on top of Kukjin Kim's for-next merged with
driver-samsung and on top of
cherry-picked change from [1].

1: ARM: EXYNOS: Constify local exynos_pmu_data structure
   https://lkml.org/lkml/2015/10/28/917

For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for boot
and S2R functionality.

Tested-by: Pankaj Dubey 

For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff)
and Odroid XU3 (Exynos5422, reboot, poweroff).

Tested-by: Krzysztof Kozlowski 

Changes since v5:
 - Removed extra blank line from patch 5/9 and 6/9.
 - Modified soc/samsung/Kconfig for config EXNOS_PMU. Added depends on ARM.

Changes since v4:
 - In v3 I missed to give -M flag to detect rename, which made patches hard
   to review, so resubmitting patches with rename detector flag.
 - Addressed review comments from Krzysztof.

Changes since v3:
 - Keeping intact copyright dates in existing header files.
 - Addressed review comments from Krzysztof for v3.
 - Removing static inline function from exynos-pmu.h and
   keeping them in PMU driver.
 - Added new patch (2/9) for fixing potential null pointer reference in
   exynos_sys_powerdown_conf.
 - Added new patch (8/9) for rearranging static and non-static function for
   better readability.

Changes since v2:
 - Removed Amit's Samsung id as it's no more valid.
 - Rebased on latest kgene tree.
 - Removed redundant code from regs-pmu.h

Pankaj Dubey (9):
  ARM: EXYNOS: removing redundant code from regs-pmu.h
  ARM: EXYNOS: Fix potential NULL pointer access in
exynos_sys_powerdown_conf
  ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung"
  ARM: EXYNOS: split up exynos3250 SoC specific PMU data
  ARM: EXYNOS: split up exynos4 SoC specific PMU data
  ARM: EXYNOS: split up exynos5250 SoC specific PMU data
  ARM: EXYNOS: split up exynos5420 SoC specific PMU data
  ARM: EXYNOS: rearrange static and non-static functions of PMU driver
  drivers: soc: Add support for Exynos PMU driver

 arch/arm/mach-exynos/Kconfig   |1 +
 arch/arm/mach-exynos/Makefile  |2 +-
 arch/arm/mach-exynos/exynos.c  |4 +-
 arch/arm/mach-exynos/mcpm-exynos.c |2 +-
 arch/arm/mach-exynos/platsmp.c |2 +-
 arch/arm/mach-exynos/pm.c  |4 +-
 arch/arm/mach-exynos/pmu.c | 1004 
 arch/arm/mach-exynos/suspend.c |4 +-
 drivers/soc/samsung/Kconfig|4 +
 drivers/soc/samsung/Makefile   |2 +
 drivers/soc/samsung/exynos-pmu.c   |  183 
 drivers/soc/samsung/exynos-pmu.h   |   44 +
 drivers/soc/samsung/exynos3250-pmu.c   |  175 
 drivers/soc/samsung/exynos4-pmu.c  |  222 +
 drivers/soc/samsung/exynos5250-pmu.c   |  195 
 drivers/soc/samsung/exynos5420-pmu.c   |  280 ++
 .../linux/soc/samsung}/exynos-pmu.h|6 +-
 .../linux/soc/samsung/exynos-regs-pmu.h|   15 +-
 18 files changed, 1120 insertions(+), 1029 deletions(-)
 delete mode 100644 arch/arm/mach-exynos/pmu.c
 create mode 100644 drivers/soc/samsung/exynos-pmu.c
 create mode 100644 drivers/soc/samsung/exynos-pmu.h
 create mode 100644 drivers/soc/samsung/exynos3250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos4-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5250-pmu.c
 create mode 100644 drivers/soc/samsung/exynos5420-pmu.c
 rename {arch/arm/mach-exynos => include/linux/soc/samsung}/exynos-pmu.h (81%)
 rename arch/arm/mach-exynos/regs-pmu.h => 
include/linux/soc/samsung/exynos-regs-pmu.h (98%)

-- 
2.4.5

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


[PATCH] phy: phy-mt65xx-usb3: improve HS eye diagram

2015-11-16 Thread Chunfeng Yun
calibrate HS slew rate and switch 100uA current to SSUSB
to improve HS eye diagram of HQA test.

Change-Id: I6d392c7fffb32b3a710e3a8dda92710886806d90
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 99 +--
 1 file changed, 96 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index dc480d3..9069162 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,7 @@
  * relative to USB3_SIF2_BASE base address
  */
 #define SSUSB_SIFSLV_SPLLC 0x
+#define SSUSB_SIFSLV_U2FREQ0x0100
 
 /* offsets of sub-segment in each port registers */
 #define SSUSB_SIFSLV_U2PHY_COM_BASE0x
@@ -41,6 +43,7 @@
 #define PA2_RG_SIF_U2PLL_FORCE_EN  BIT(18)
 
 #define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
+#define PA5_RG_U2_HSTX_SRCAL_ENBIT(15)
 #define PA5_RG_U2_HSTX_SRCTRL  GENMASK(14, 12)
 #define PA5_RG_U2_HSTX_SRCTRL_VAL(x)   ((0x7 & (x)) << 12)
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
@@ -113,6 +116,24 @@
 #define XC3_RG_U3_XTAL_RX_PWD  BIT(9)
 #define XC3_RG_U3_FRC_XTAL_RX_PWD  BIT(8)
 
+#define U3P_U2FREQ_FMCR0   (SSUSB_SIFSLV_U2FREQ + 0x00)
+#define P2F_RG_MONCLK_SEL  GENMASK(27, 26)
+#define P2F_RG_MONCLK_SEL_VAL(x)   ((0x3 & (x)) << 26)
+#define P2F_RG_FREQDET_EN  BIT(24)
+#define P2F_RG_CYCLECNTGENMASK(23, 0)
+#define P2F_RG_CYCLECNT_VAL(x) ((P2F_RG_CYCLECNT) & (x))
+
+#define U3P_U2FREQ_VALUE   (SSUSB_SIFSLV_U2FREQ + 0x0c)
+
+#define U3P_U2FREQ_FMMONR1 (SSUSB_SIFSLV_U2FREQ + 0x10)
+#define P2F_USB_FM_VALID   BIT(0)
+#define P2F_RG_FRCK_EN BIT(8)
+
+#define U3P_REF_CLK26  /* MHZ */
+#define U3P_SLEW_RATE_COEF 28
+#define U3P_SR_COEF_DIVISOR1000
+#define U3P_FM_DET_CYCLE_CNT   1024
+
 struct mt65xx_phy_instance {
struct phy *phy;
void __iomem *port_base;
@@ -128,6 +149,77 @@ struct mt65xx_u3phy {
int nphys;
 };
 
+static void hs_slew_rate_calibrate(struct mt65xx_u3phy *u3phy,
+   struct mt65xx_phy_instance *instance)
+{
+   void __iomem *sif_base = u3phy->sif_base;
+   int calibration_val;
+   int fm_out;
+   u32 tmp;
+
+   /* enable USB ring oscillator */
+   tmp = readl(instance->port_base + U3P_USBPHYACR5);
+   tmp |= PA5_RG_U2_HSTX_SRCAL_EN;
+   writel(tmp, instance->port_base + U3P_USBPHYACR5);
+   udelay(1);
+
+   /*enable free run clock */
+   tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+   tmp |= P2F_RG_FRCK_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+   /* set cycle count as 1024, and select u2 channel */
+   tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+   tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
+   tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
+   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+   writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+   /* enable frequency meter */
+   tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+   tmp |= P2F_RG_FREQDET_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+   /* ignore return value */
+   readl_poll_timeout(sif_base + U3P_U2FREQ_FMMONR1, tmp,
+ (tmp & P2F_USB_FM_VALID), 10, 200);
+
+   fm_out = readl(sif_base + U3P_U2FREQ_VALUE);
+
+   /* disable frequency meter */
+   tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
+   tmp &= ~P2F_RG_FREQDET_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
+
+   /*disable free run clock */
+   tmp = readl(sif_base + U3P_U2FREQ_FMMONR1);
+   tmp &= ~P2F_RG_FRCK_EN;
+   writel(tmp, sif_base + U3P_U2FREQ_FMMONR1);
+
+   if (fm_out) {
+   /* ( 1024 / FM_OUT ) x reference clock frequency x 0.028 */
+   tmp = U3P_FM_DET_CYCLE_CNT * U3P_REF_CLK * U3P_SLEW_RATE_COEF;
+   tmp /= fm_out;
+   calibration_val = DIV_ROUND_CLOSEST(tmp, U3P_SR_COEF_DIVISOR);
+   } else {
+   /* if FM detection fail, set default value */
+   calibration_val = 4;
+   }
+   dev_dbg(u3phy->dev, "phy:%d, fm_out:%d, calib:%d\n",
+   instance->index, fm_out, calibration_val);
+
+   /* set HS slew rate */
+   tmp = readl(instance->port_base + U3P_USBPHYACR5);
+   tmp &= ~PA5_RG_U2_HSTX_SRCTRL;
+   tmp |= PA5_RG_U2_HSTX_SRCTRL_VAL(calibration_val);
+   writel(tmp, instance->port_base + U3P_USBPHYACR5);
+
+   /* disable USB ring oscillator */
+   tmp = readl(instance->port_base + U3P_USBPHYACR5);
+   tmp &= ~PA5_RG_U2_HSTX_SRCAL_EN;
+   writel(tmp, instance->port_base + U3P_USBPHYACR5);
+}
+
 static void phy_instance_init(struct mt65xx_u3phy *u3phy,
struct mt65xx_phy_instance *instance)
 {
@@ -226,9 +318,9 @@ static void phy_instance_power_on(s

Re: [RESEND] phy: core: Get a refcount to phy in devm_of_phy_get_by_index()

2015-11-16 Thread Jisheng Zhang
Hi,

On Tue, 17 Nov 2015 13:56:48 +0800
Chunfeng Yun  wrote:

> On driver detach, devm_phy_release() will put a refcount to
> the phy, so gets a refconut to it before return.
> 
> Change-Id: I56fe428bf945f19c38d56245978c8ca17340eb2c

This line need to be removed



> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/phy-core.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index fc48fac..8c7f27d 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -636,8 +636,9 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
>   * @np: node containing the phy
>   * @index: index of the phy
>   *
> - * Gets the phy using _of_phy_get(), and associates a device with it using
> - * devres. On driver detach, release function is invoked on the devres data,
> + * Gets the phy using _of_phy_get(), then gets a refcount to it,
> + * and associates a device with it using devres. On driver detach,
> + * release function is invoked on the devres data,
>   * then, devres data is freed.
>   *
>   */
> @@ -651,13 +652,21 @@ struct phy *devm_of_phy_get_by_index(struct device 
> *dev, struct device_node *np,
>   return ERR_PTR(-ENOMEM);
>  
>   phy = _of_phy_get(np, index);
> - if (!IS_ERR(phy)) {
> - *ptr = phy;
> - devres_add(dev, ptr);
> - } else {
> + if (IS_ERR(phy)) {
>   devres_free(ptr);
> + return phy;
>   }
>  
> + if (!try_module_get(phy->ops->owner)) {
> + devres_free(ptr);
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
> + get_device(&phy->dev);
> +
> + *ptr = phy;
> + devres_add(dev, ptr);
> +
>   return phy;
>  }
>  EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] phy: phy-mt65xx-usb3: fix test fail of HS receiver sensitivity

2015-11-16 Thread Chunfeng Yun
when use the default value 8 of RG_USB20_SQTH, the HS receiver
sensitivity test of HQA will fail, set it as 2 to fix up the
issue.

Change-Id: Ia5bdbbfc8ebb170d3ef26007e665b7350b6d28ab
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index f30b28b..dc480d3 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -49,6 +49,8 @@
 #define PA6_RG_U2_ISO_EN   BIT(31)
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
+#define PA6_RG_U2_SQTH GENMASK(3, 0)
+#define PA6_RG_U2_SQTH_VAL(x)  (0xf & (x))
 
 #define U3P_U2PHYACR4  (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
 #define P2C_RG_USB20_GPIO_CTL  BIT(9)
@@ -165,9 +167,10 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
writel(tmp, port_base + U3P_U2PHYDTM0);
}
 
-   /* DP/DM BC1.1 path Disable */
tmp = readl(port_base + U3P_USBPHYACR6);
-   tmp &= ~PA6_RG_U2_BC11_SW_EN;
+   tmp &= ~PA6_RG_U2_BC11_SW_EN;   /* DP/DM BC1.1 path Disable */
+   tmp &= ~PA6_RG_U2_SQTH;
+   tmp |= PA6_RG_U2_SQTH_VAL(2);
writel(tmp, port_base + U3P_USBPHYACR6);
 
tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
-- 
1.8.1.1.dirty

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


[RESEND] phy: core: Get a refcount to phy in devm_of_phy_get_by_index()

2015-11-16 Thread Chunfeng Yun
On driver detach, devm_phy_release() will put a refcount to
the phy, so gets a refconut to it before return.

Change-Id: I56fe428bf945f19c38d56245978c8ca17340eb2c
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-core.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index fc48fac..8c7f27d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -636,8 +636,9 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
  * @np: node containing the phy
  * @index: index of the phy
  *
- * Gets the phy using _of_phy_get(), and associates a device with it using
- * devres. On driver detach, release function is invoked on the devres data,
+ * Gets the phy using _of_phy_get(), then gets a refcount to it,
+ * and associates a device with it using devres. On driver detach,
+ * release function is invoked on the devres data,
  * then, devres data is freed.
  *
  */
@@ -651,13 +652,21 @@ struct phy *devm_of_phy_get_by_index(struct device *dev, 
struct device_node *np,
return ERR_PTR(-ENOMEM);
 
phy = _of_phy_get(np, index);
-   if (!IS_ERR(phy)) {
-   *ptr = phy;
-   devres_add(dev, ptr);
-   } else {
+   if (IS_ERR(phy)) {
devres_free(ptr);
+   return phy;
}
 
+   if (!try_module_get(phy->ops->owner)) {
+   devres_free(ptr);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
+   get_device(&phy->dev);
+
+   *ptr = phy;
+   devres_add(dev, ptr);
+
return phy;
 }
 EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
-- 
1.8.1.1.dirty

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


Re: [PATCH 6/7] mm/gfp: make gfp_zonelist return directly and bool

2015-11-16 Thread David Rientjes
On Tue, 17 Nov 2015, Yaowei Bai wrote:

> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 6523109..14a6249 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -378,9 +378,9 @@ static inline enum zone_type gfp_zone(gfp_t flags)
>  static inline int gfp_zonelist(gfp_t flags)
>  {
> if (IS_ENABLED(CONFIG_NUMA) && unlikely(flags & __GFP_THISNODE))
> -   return 1;
> +   return ZONELIST_NOFALLBACK;
>  
> -   return 0;
> +   return ZONELIST_FALLBACK;
>  }
>  
>  /*
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index e23a9e7..9664d6c 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -576,8 +576,6 @@ static inline bool zone_is_empty(struct zone *zone)
>  /* Maximum number of zones on a zonelist */
>  #define MAX_ZONES_PER_ZONELIST (MAX_NUMNODES * MAX_NR_ZONES)
>  
> -#ifdef CONFIG_NUMA
> -
>  /*
>   * The NUMA zonelists are doubled because we need zonelists that restrict the
>   * allocations to a single node for __GFP_THISNODE.
> @@ -585,10 +583,13 @@ static inline bool zone_is_empty(struct zone *zone)
>   * [0] : Zonelist with fallback
>   * [1] : No fallback (__GFP_THISNODE)
>   */
> -#define MAX_ZONELISTS 2
> -#else
> -#define MAX_ZONELISTS 1
> +enum {
> +   ZONELIST_FALLBACK,
> +#ifdef CONFIG_NUMA
> +   ZONELIST_NOFALLBACK,
>  #endif
> +   MAX_ZONELISTS
> +};
>  
>  /*
>   * This struct contains information about a zone in a zonelist. It is stored

This is a different change than the original.  I don't see a benefit from 
it, but I have no strong feelings on it.  If someone else finds value in 
this, please update the comment when defining the enum as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] vhost: relax log address alignment

2015-11-16 Thread Jason Wang


On 11/16/2015 11:00 PM, Michael S. Tsirkin wrote:
> commit 5d9a07b0de512b77bf28d2401e5fe3351f00a240 ("vhost: relax used
> address alignment") fixed the alignment for the used virtual address,
> but not for the physical address used for logging.
>
> That's a mistake: alignment should clearly be the same for virtual and
> physical addresses,
>
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/vhost/vhost.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index eec2f11..080422f 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -819,7 +819,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, 
> void __user *argp)
>   BUILD_BUG_ON(__alignof__ *vq->used > VRING_USED_ALIGN_SIZE);
>   if ((a.avail_user_addr & (VRING_AVAIL_ALIGN_SIZE - 1)) ||
>   (a.used_user_addr & (VRING_USED_ALIGN_SIZE - 1)) ||
> - (a.log_guest_addr & (sizeof(u64) - 1))) {
> + (a.log_guest_addr & (VRING_USED_ALIGN_SIZE - 1))) {
>   r = -EINVAL;
>   break;
>   }

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


Re: [PATCH v5 00/11] exynos-ufs: add support for Exynos

2015-11-16 Thread Kishon Vijay Abraham I
Hi Alim,

On Monday 16 November 2015 06:31 AM, Alim Akhtar wrote:
> Hi Kishon,
> 
> Any more concern on the PHY part of this series?

Sorry for the late reply. Yes, I still have concerns. I'll comment on your 
patch.

Thanks
Kishon
> 
> Thanks!
> 
> On Mon, Nov 9, 2015 at 10:56 AM, Alim Akhtar  wrote:
>> This patch-set introduces UFS (Universal Flash Storage) host support
>> for Samsung Exynos SoC. Mostly, it consists of UFS PHY and host specific 
>> driver.
>> And it also contains some quirks handling for Exynos.
>>
>> NOTE: ** This series has a dependency on [4]. **
>>
>> -Changes since v4:
>> * Removed platform specific PHY ops as suggested by Kishon
>> * Rebased on the top of Yaniv Gardi's work [4]
>> * make use of newly introduce ufshcd_{get,set}_variant
>> * other small changes and improvements.
>> * rebased on the top of linux next-20151109
>>
>> -Changes since v3:
>> * Fixed compilation warrings as reported by "Kbuild Test Robot"[5].
>> * Restructure the driver to make it as a platform driver, rebased on top of 
>> [4].
>> * Addressed review comments from Arnd Bergmann[5].
>> * Other misc changes and improvements.
>>
>> -Changes since v2:
>> * Addressed review comments from Kishon[1] and Rob Herring [2]
>> * Splited ufs dt binding documetation from ufs driver patch
>>
>> -Changes since v1:
>> * Addressed review comments from Alexey[3] and various review comments from 
>> Amit.
>> * Updated email id of Seungwon as his samsung id is void now.
>> * Added ufs platform data
>>
>> [1]-> https://lkml.org/lkml/2015/9/18/29
>> [2]-> https://lkml.org/lkml/2015/9/21/668
>> [3]-> https://lkml.org/lkml/2015/8/23/124
>> [4]-> https://lkml.org/lkml/2015/10/28/271
>> [5]-> https://lkml.org/lkml/2015/10/1/402
>>
>> This patch set is tested on exynos7-espresso board.
>>
>>
>> Alim Akhtar (1):
>>   Documentation: samsung-phy: Add dt bindings for UFS
>>
>> Seungwon Jeon (10):
>>   phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC
>>   scsi: ufs: add quirk to contain unconformable utrd field
>>   scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr
>>   scsi: ufs: add quirk not to allow reset of interrupt aggregation
>>   scsi: ufs: add quirk to enable host controller without hce
>>   scsi: ufs: add specific callback for nexus type
>>   scsi: ufs: add add specific callback for hibern8
>>   scsi: ufs: make ufshcd_config_pwr_mode of non-static func
>>   Documentation: devicetree: ufs: Add DT bindings for exynos UFS host
>> controller
>>   scsi: ufs-exynos: add UFS host support for Exynos SoCs
>>
>>  .../devicetree/bindings/phy/samsung-phy.txt|   22 +
>>  .../devicetree/bindings/ufs/ufs-exynos.txt |  104 ++
>>  drivers/phy/Kconfig|7 +
>>  drivers/phy/Makefile   |1 +
>>  drivers/phy/phy-exynos-ufs.c   |  241 
>>  drivers/phy/phy-exynos-ufs.h   |   85 ++
>>  drivers/phy/phy-exynos7-ufs.h  |   89 ++
>>  drivers/scsi/ufs/Kconfig   |   12 +
>>  drivers/scsi/ufs/Makefile  |1 +
>>  drivers/scsi/ufs/ufs-exynos-hw.c   |  131 ++
>>  drivers/scsi/ufs/ufs-exynos-hw.h   |   43 +
>>  drivers/scsi/ufs/ufs-exynos.c  | 1304 
>> 
>>  drivers/scsi/ufs/ufs-exynos.h  |  247 
>>  drivers/scsi/ufs/ufshcd.c  |  168 ++-
>>  drivers/scsi/ufs/ufshcd.h  |   54 +
>>  drivers/scsi/ufs/ufshci.h  |   26 +-
>>  drivers/scsi/ufs/unipro.h  |   47 +
>>  include/linux/phy/phy-exynos-ufs.h |   85 ++
>>  18 files changed, 2647 insertions(+), 20 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/ufs/ufs-exynos.txt
>>  create mode 100644 drivers/phy/phy-exynos-ufs.c
>>  create mode 100644 drivers/phy/phy-exynos-ufs.h
>>  create mode 100644 drivers/phy/phy-exynos7-ufs.h
>>  create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
>>  create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
>>  create mode 100644 drivers/scsi/ufs/ufs-exynos.c
>>  create mode 100644 drivers/scsi/ufs/ufs-exynos.h
>>  create mode 100644 include/linux/phy/phy-exynos-ufs.h
>>
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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: BUG: unable to handle kernel paging request at ffffe8ff7fc00001

2015-11-16 Thread Kyle Sanderson
Looks like massive corruption, so the oops above probably isn't
anywhere near the cause. NFS was bouncing a bit, dmesg below...

I've downgraded back to 3.14.56, will see if it continues.

[523529.636418] nfs: server ftpback-bhs1-9.ip-198-100-151.net OK
[532541.586437] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[532541.657558] REISERFS warning (device sda4): sh-2006
read_super_block: bread failed (dev sda4, block 8, size 1024)
[532541.657621] REISERFS warning (device sda4): sh-2006
read_super_block: bread failed (dev sda4, block 64, size 1024)
[532541.657682] REISERFS warning (device sda4): sh-2021
reiserfs_fill_super: can not find reiserfs on sda4
[532541.658379] EXT3-fs (sda4): error: unable to read superblock
[532541.659020] EXT2-fs (sda4): error: unable to read superblock
[532541.659664] EXT4-fs (sda4): unable to read superblock
[532541.660423] squashfs: SQUASHFS error: Can't find a SQUASHFS
superblock on sda4
[532541.661194] FAT-fs (sda4): bogus number of reserved sectors
[532541.661226] FAT-fs (sda4): Can't find a valid FAT filesystem
[532541.661901] isofs_fill_super: bread failed, dev=sda4,
iso_blknum=16, block=32
[532541.662588] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=256, location=256
[532541.662819] UDF-fs: error (device sda4): udf_read_tagged: tag
version 0x != 0x0002 || 0x0003, block 0
[532541.662879] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=512, location=512
[532541.662935] UDF-fs: error (device sda4): udf_read_tagged: tag
version 0x != 0x0002 || 0x0003, block 0
[532541.662994] UDF-fs: error (device sda4): udf_read_tagged: tag
version 0x != 0x0002 || 0x0003, block 0
[532541.663052] UDF-fs: warning (device sda4): udf_load_vrs: No anchor found
[532541.663086] UDF-fs: Rescanning with blocksize 2048
[532541.663124] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=256, location=256
[532541.663181] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=512, location=512
[532541.663238] UDF-fs: warning (device sda4): udf_load_vrs: No anchor found
[532541.663271] UDF-fs: warning (device sda4): udf_fill_super: No
partition found (1)
[532541.664182] XFS (sda4): Invalid superblock magic number
[532541.665014] (mount,17550,6):ocfs2_get_sector:1822 ERROR: status = -12
[532541.665048] (mount,17550,6):ocfs2_sb_probe:821 ERROR: status = -12
[532541.665081] (mount,17550,6):ocfs2_fill_super:1026 ERROR:
superblock probe failed!
[532541.665117] (mount,17550,6):ocfs2_fill_super:1217 ERROR: status = -12
[532541.665775] attempt to access beyond end of device
[532541.665806] sda4: rw=48, want=136, limit=2
[532541.665833] gfs2: error -5 reading superblock
[532541.666457] gfs2: gfs2 mount does not exist
[532541.667821] FAT-fs (sda4): bogus number of reserved sectors
[532541.667853] FAT-fs (sda4): Can't find a valid FAT filesystem
[532541.668621] ntfs: (device sda4): read_ntfs_boot_sector(): Primary
boot sector is invalid.
[532541.672594] ntfs: (device sda4): read_ntfs_boot_sector(): Mount
option errors=recover not used. Aborting without trying to recover.
[532541.672657] ntfs: (device sda4): ntfs_fill_super(): Not an NTFS volume.
[532603.588489] REISERFS warning (device sda4): sh-2006
read_super_block: bread failed (dev sda4, block 8, size 1024)
[532603.588552] REISERFS warning (device sda4): sh-2006
read_super_block: bread failed (dev sda4, block 64, size 1024)
[532603.588613] REISERFS warning (device sda4): sh-2021
reiserfs_fill_super: can not find reiserfs on sda4
[532603.589374] EXT3-fs (sda4): error: unable to read superblock
[532603.590054] EXT2-fs (sda4): error: unable to read superblock
[532603.590738] EXT4-fs (sda4): unable to read superblock
[532603.591524] squashfs: SQUASHFS error: Can't find a SQUASHFS
superblock on sda4
[532603.592590] FAT-fs (sda4): bogus number of reserved sectors
[532603.592622] FAT-fs (sda4): Can't find a valid FAT filesystem
[532603.593273] isofs_fill_super: bread failed, dev=sda4,
iso_blknum=16, block=32
[532603.593945] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=256, location=256
[532603.594247] UDF-fs: error (device sda4): udf_read_tagged: tag
version 0x != 0x0002 || 0x0003, block 0
[532603.594312] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=512, location=512
[532603.594371] UDF-fs: error (device sda4): udf_read_tagged: tag
version 0x != 0x0002 || 0x0003, block 0
[532603.594432] UDF-fs: error (device sda4): udf_read_tagged: tag
version 0x != 0x0002 || 0x0003, block 0
[532603.594492] UDF-fs: warning (device sda4): udf_load_vrs: No anchor found
[532603.594527] UDF-fs: Rescanning with blocksize 2048
[532603.594582] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=256, location=256
[532603.594642] UDF-fs: error (device sda4): udf_read_tagged: read
failed, block=512, location=512
[532603.594700] UDF-fs: warning (device sda4): udf_load_vrs: No anchor found
[532603.594746] UDF-fs: warning (device sda4): udf_fill_super: No
partition foun

Re: [PATCH 5/7] mm/lru: remove unused is_unevictable_lru function

2015-11-16 Thread Hillf Danton
> 
> Since commit a0b8cab3 ("mm: remove lru parameter from __pagevec_lru_add
> and remove parts of pagevec API") there's no user of this function anymore,
> so remove it.
> 
> Signed-off-by: Yaowei Bai 
> ---

Acked-by: Hillf Danton 

>  include/linux/mmzone.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index e23a9e7..9963846 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -195,11 +195,6 @@ static inline int is_active_lru(enum lru_list lru)
>   return (lru == LRU_ACTIVE_ANON || lru == LRU_ACTIVE_FILE);
>  }
> 
> -static inline int is_unevictable_lru(enum lru_list lru)
> -{
> - return (lru == LRU_UNEVICTABLE);
> -}
> -
>  struct zone_reclaim_stat {
>   /*
>* The pageout code in vmscan.c keeps track of how many of the
> --
> 1.9.1
> 


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


[PATCH V1] regulator: pv88060: new regulator driver

2015-11-16 Thread James Ban

From: James Ban 

This is the driver for the Powerventure PV88060 BUCKs and LDOs regulator.
It communicates via an I2C bus to the device.

Signed-off-by: James Ban 

---
This patch applies against linux-next and next-20151115 


 .../devicetree/bindings/regulator/pv88060.txt  |  124 +
 drivers/regulator/Kconfig  |8 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/pv88060-regulator.c  |  517 
 drivers/regulator/pv88060-regulator.h  |   69 +++
 include/linux/regulator/pv88060.h  |   28 ++
 6 files changed, 747 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/regulator/pv88060.txt
 create mode 100644 drivers/regulator/pv88060-regulator.c
 create mode 100644 drivers/regulator/pv88060-regulator.h
 create mode 100644 include/linux/regulator/pv88060.h

diff --git a/Documentation/devicetree/bindings/regulator/pv88060.txt 
b/Documentation/devicetree/bindings/regulator/pv88060.txt
new file mode 100644
index 000..10a6dad
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/pv88060.txt
@@ -0,0 +1,124 @@
+* Powerventure Semiconductor PV88060 Voltage Regulator
+
+Required properties:
+- compatible: "pvs,pv88060".
+- reg: I2C slave address, usually 0x49.
+- interrupts: the interrupt outputs of the controller
+- regulators: A node that houses a sub-node for each regulator within the
+  device. Each sub-node is identified using the node's name, with valid
+  values listed below. The content of each sub-node is defined by the
+  standard binding for regulators; see regulator.txt.
+  BUCK1, LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7, SW1, SW2, SW3, SW4,
+  SW5, and SW6.
+
+Optional properties:
+- Any optional property defined in regulator.txt
+
+Example
+
+   pmic: pv88060@49 {
+   compatible = "pvs,pv88060";
+   reg = <0x49>;
+   interrupt-parent = <&gpio>;
+   interrupts = <24 24>;
+
+   regulators {
+   BUCK1 {
+   regulator-name = "buck1";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <4387500>;
+   regulator-min-microamp  = <1496000>;
+   regulator-max-microamp  = <4189000>;
+   regulator-boot-on;
+   };
+
+   LDO1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <335>;
+   regulator-boot-on;
+   };
+
+   LDO2 {
+   regulator-name = "ldo2";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <335>;
+   regulator-boot-on;
+   };
+
+   LDO3 {
+   regulator-name = "ldo3";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <335>;
+   regulator-boot-on;
+   };
+
+   LDO4 {
+   regulator-name = "ldo4";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <335>;
+   regulator-boot-on;
+   };
+
+   LDO5 {
+   regulator-name = "ldo5";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <335>;
+   regulator-boot-on;
+   };
+
+   LDO6 {
+   regulator-name = "ldo6";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <335>;
+   regulator-boot-on;
+   };
+
+   LDO7 {
+   regulator-name = "ldo7";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <335>;
+   regulator-boot-on;
+   };
+
+   SW1 {
+   regulator-name = "sw1";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+
+   SW2 {
+   regulator-name = "sw2";
+  

RE: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

2015-11-16 Thread Bharat Kumar Gogada
> On Wed, 11 Nov 2015 12:03:39 +0530
> Bharat Kumar Gogada  wrote:
> 
> > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> >
> > Signed-off-by: Bharat Kumar Gogada 
> > Signed-off-by: Ravi Kiran Gummaluri 
> > ---
> > Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
> > Moved MSI functionality to separate functions.
> > Changed error return values.
> > ---
> >  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
> >  drivers/pci/host/Kconfig   |   16 +-
> >  drivers/pci/host/Makefile  |1 +
> >  drivers/pci/host/pcie-xilinx-nwl.c | 1062 
> > 
> >  4 files changed, 1144 insertions(+), 3 deletions(-)  create mode
> > 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> >  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> >
> > diff --git a/drivers/pci/host/pcie-xilinx-nwl.c
> > b/drivers/pci/host/pcie-xilinx-nwl.c
> > new file mode 100644
> > index 000..8bc509c
> > --- /dev/null
> > +++ b/drivers/pci/host/pcie-xilinx-nwl.c
> 
> [...]
> 
> > +static struct msi_domain_info nwl_msi_domain_info = {
> > +   .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> MSI_FLAG_USE_DEF_CHIP_OPS |
> > + MSI_FLAG_MULTI_PCI_MSI),
> 
> Given that you claim to support multi-MSI...
> 
> [...]
> 
> > +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> > +   unsigned int nr_irqs, void *args) {
> > +   struct nwl_pcie *pcie = domain->host_data;
> > +   struct nwl_msi *msi = &pcie->msi;
> > +   unsigned long bit;
> > +   int i;
> > +
> > +   mutex_lock(&msi->lock);
> > +   for (i = 0; i < nr_irqs; i++) {
> > +   bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> > +   if (bit < INT_PCI_MSI_NR)
> > +   set_bit(bit, msi->used);
> > +   else
> > +   bit = -ENOSPC;
> > +
> > +   if (bit < 0) {
> > +   mutex_unlock(&msi->lock);
> > +   return bit;
> > +   }
> > +
> > +   irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> > +   domain->host_data, handle_simple_irq,
> > +   NULL, NULL);
> > +   virq = virq + 1;
> > +   }
> 
> I really don't see how this allocator guarantees that all hwirqs are 
> contiguous.
> I already mentioned this when reviewing v7, and you still haven't got it 
> right.
> So either you allocate *contiguous* hwirqs in an atomic fashion, or you drop
> support for multi-MSI.
> 
Yes, I understood now there is no check for allocating contiguous hwirq, I will 
address this in the next patch.

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


Re: [RFC PATCH -v2.1] x86: Kill notsc

2015-11-16 Thread H. Peter Anvin
On 11/16/15 13:25, Thomas Gleixner wrote:
> On Mon, 16 Nov 2015, Borislav Petkov wrote:
>> -/*
>> - * disable flag for tsc. Takes effect by clearing the TSC cpu flag
>> - * in cpu/common.c
>> - */
>> -int __init notsc_setup(char *str)
>> +/* Disable the TSC feature flag to avoid further TSC use. */
>> +int __init notsc_setup(void)
>>  {
>> +#ifndef CONFIG_X86_TSC
>>  setup_clear_cpu_cap(X86_FEATURE_TSC);
> 
> This is silly, really.
> 
> If CONFIG_X86_TSC is disabled then we should just not compile tsc.c at
> all and map cpu_has_tsc and stuff depending on it to false.
> 

CONFIG_X86_TSC means TSC is obligatory, not that it is supported.

-hpa


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


Re: [PATCH 2/4] timer: relax tick stop in idle entry

2015-11-16 Thread Paul E. McKenney
On Mon, Nov 16, 2015 at 06:57:14PM -0800, Arjan van de Ven wrote:
> On 11/16/2015 6:53 PM, Paul E. McKenney wrote:
> >Fair point.  When in the five-jiffy throttling state, what can wake up
> >a CPU?  In an earlier version of this proposal, the answer was "nothing",
> >but maybe that has changed.
> 
> device interrupts are likely to wake the cpus.

OK, that I cannot help you with.  But presumably if the interrupt handler
does a wakeup (or similar), that is deferred to the end of the throttling
interval?  Timers are also deferred, including hrtimers?

Thanx, Paul

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


RE: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

2015-11-16 Thread Bharat Kumar Gogada
 
> On 11/10/2015 10:33 PM, Bharat Kumar Gogada wrote:
> > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> >
> > Signed-off-by: Bharat Kumar Gogada 
> > Signed-off-by: Ravi Kiran Gummaluri 
> > ---
> > Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc function.
> > Moved MSI functionality to separate functions.
> > Changed error return values.
> > +static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int
> virq,
> > +   unsigned int nr_irqs, void *args) {
> > +   struct nwl_pcie *pcie = domain->host_data;
> > +   struct nwl_msi *msi = &pcie->msi;
> > +   unsigned long bit;
> > +   int i;
> > +
> > +   mutex_lock(&msi->lock);
> > +   for (i = 0; i < nr_irqs; i++) {
> > +   bit = find_first_zero_bit(msi->used, INT_PCI_MSI_NR);
> > +   if (bit < INT_PCI_MSI_NR)
> > +   set_bit(bit, msi->used);
> > +   else
> > +   bit = -ENOSPC;
> 
> Don't you get a compiler warning with this? Note bit is unsigned long and you
> assign -ENOSPC to it.
> 
Ya that's a mistake, I will address these in next patch.
> > +
> > +   if (bit < 0) {
> 
> how can bit < 0 if it's unsigned long?
> 
> > +   mutex_unlock(&msi->lock);
> > +   return bit;
> > +   }
> > +
> > +   irq_domain_set_info(domain, virq, bit, &nwl_irq_chip,
> > +   domain->host_data, handle_simple_irq,
> > +   NULL, NULL);
> 
> nit, but if you do irq_domain_set_info(domain, virq + i, ...
> 
> then you can get rid of the code below.
> 
> > +   virq = virq + 1;
> > +   }
> > +   mutex_unlock(&msi->lock);
> > +   return 0;
> > +}
> > +

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


RE: [PATCH v8] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

2015-11-16 Thread Bharat Kumar Gogada
> On 11/16/2015 7:14 AM, Marc Zyngier wrote:
> > On 11/11/15 06:33, Bharat Kumar Gogada wrote:
> >> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> >>
> >> Signed-off-by: Bharat Kumar Gogada 
> >> Signed-off-by: Ravi Kiran Gummaluri 
> >> ---
> >> Added logic to allocate contiguous hwirq in nwl_irq_domain_alloc
> function.
> >> Moved MSI functionality to separate functions.
> >> Changed error return values.
> >> ---
> >>   .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
> >>   drivers/pci/host/Kconfig   |   16 +-
> >>   drivers/pci/host/Makefile  |1 +
> >>   drivers/pci/host/pcie-xilinx-nwl.c | 1062
> 
> >>   4 files changed, 1144 insertions(+), 3 deletions(-)
> >>   create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-
> pcie.txt
> >>   create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> >>
> >
> > [...]
> >
> >> +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus
> >> +*bus) {
> >> +  struct platform_device *pdev = to_platform_device(pcie->dev);
> >> +  struct nwl_msi *msi = &pcie->msi;
> >> +  unsigned long base;
> >> +  int ret;
> >> +
> >> +  mutex_init(&msi->lock);
> >> +
> >> +  /* Check for msii_present bit */
> >> +  ret = nwl_bridge_readl(pcie, I_MSII_CAPABILITIES) & MSII_PRESENT;
> >> +  if (!ret) {
> >> +  dev_err(pcie->dev, "MSI not present\n");
> >> +  ret = -EIO;
> >> +  goto err;
> >> +  }
> >> +
> >> +  /* Enable MSII */
> >> +  nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> >> +MSII_ENABLE, I_MSII_CONTROL);
> >> +
> >> +  /* Enable MSII status */
> >> +  nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, I_MSII_CONTROL) |
> >> +MSII_STATUS_ENABLE, I_MSII_CONTROL);
> >> +
> >> +  /* setup AFI/FPCI range */
> >> +  msi->pages = __get_free_pages(GFP_KERNEL, 0);
> >> +  base = virt_to_phys((void *)msi->pages);
> >> +  nwl_bridge_writel(pcie, lower_32_bits(base), I_MSII_BASE_LO);
> >> +  nwl_bridge_writel(pcie, upper_32_bits(base), I_MSII_BASE_HI);
> >
> > BTW, you still haven't answered my question as to why you need to
> > waste a page of memory here, and why putting a device address doesn't
> work.
> >
> > As this is (to the best of my knowledge) the only driver doing so, I'd
> > really like you to explain the rational behind this.
> 
> Might not be the only driver doing so after I start sending out patches for 
> the
> iProc MSI support (soon), :)
> 
> I'm not sure how it works for the Xilinx NWL controller, which Bharat should
> be able to help to explain. But for the iProc MSI controller, there's no 
> device
> I/O memory reserved for MSI posted writes in the ASIC.
> Therefore one needs to reserve host memory for these writes.
> >

Our SoC doesn't reserve any memory for MSI, hence we need to assign a memory 
space for it out of RAM.

Regards,
Bharat


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


Re: [PATCH v5 0/8] Add support for Exynos SROM Controller driver

2015-11-16 Thread pankaj.dubey
Hi Kukjin

On Friday 23 October 2015 11:48 PM, Kukjin Kim wrote:
> On 10/23/15 18:49, Pavel Fedin wrote:
>>  Hello!
>>
 This patchset, I have tested on Peach-Pi (Exynos5880) based chromebook for 
 boot
 and S2R functionality.

>>>
>>> Entire patchset tested on Trats2 (Exynos4412) board. Unless Kukjin picks
>>> it also, I plan to take it for v4.5.
>>
>>  Tested on SMDK5410. By the way, what is current status? If this is final 
>> revision, can i post my Ethernet support patchset on top
>> of it?
>>
>>  Tested-by: Pavel Fedin 
>>
> Applied, this whole series.
> 

I just pulled your tree, and I can't find these SROM patches in for-next
(earlier they were present). Also I can see samsung for-next is pointing
to linus/master branch. As this series not landed in linus tree due last
moment changes, So do I need to rebase SROM patches on top of latest
for-next, and send it once again?

Thanks,
Pankaj Dubey

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


Re: [PATCH v2] thermal: of-thermal: Reduce log level for message when can't find thermal zone

2015-11-16 Thread Jiada Wang

Hello

On 11/17/2015 12:37 PM, Eduardo Valentin wrote:

On Tue, Nov 17, 2015 at 11:43:34AM +0900, Jiada Wang wrote:

Some systems register thermal zone by themself and don't need to
have thermal zones node in DT. Therefore reduce the log level from
ERROR to DEBUG when thermal zone node can't be found in
of_thermal_destroy_zones().



This is already applied [1]. I applied V1 though.
What is the difference from v1?


fixed typo in commit subject
"fine" -> "find"

Thanks,
Jiada

[1] -
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixes&id=285249884ec19480f99c011d223760bb1fc865a2

BR,

Eduardo Valentin


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V4 2/2] arm64: bpf: make BPF prologue and epilogue align with ARM64 AAPCS

2015-11-16 Thread Shi, Yang

On 11/16/2015 8:41 PM, Alexei Starovoitov wrote:

On Mon, Nov 16, 2015 at 08:37:11PM -0800, Z Lim wrote:

On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi  wrote:

Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
in prologue in order to get the correct stack backtrace.

...

CC: Zi Shen Lim 
CC: Xi Wang 
Signed-off-by: Yang Shi 


Acked-by: Zi Shen Lim 


great that it's finalized.
Yang, please resubmit both patches to netdev as fresh submission so it
gets picked up by patchwork.


OK, btw the first one has been applied by David.

Yang





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 3/3] cpufreq: arm_big_little: Add support to register a cpufreq cooling device

2015-11-16 Thread Viresh Kumar
On Tue, Nov 17, 2015 at 1:00 AM, Punit Agrawal  wrote:
> Register passive cooling devices when initialising cpufreq on
> big.LITTLE systems. If the device tree provides a dynamic power
> coefficient for the CPUs then the bound cooling device will support
> the extensions that allow it to be used with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal 
> Acked-by: Viresh Kumar 

Remind me when did I Ack this version of your patch ..

> Cc: Sudeep Holla 
> Cc: Eduardo Valentin 
> ---
>  drivers/cpufreq/Kconfig.arm  |  2 ++
>  drivers/cpufreq/arm_big_little.c | 35 +++
>  2 files changed, 37 insertions(+)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 1582c1c..0e0052e 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -6,6 +6,8 @@
>  config ARM_BIG_LITTLE_CPUFREQ
> tristate "Generic ARM big LITTLE CPUfreq driver"
> depends on (ARM_CPU_TOPOLOGY || ARM64) && HAVE_CLK
> +   # if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot 
> be =y
> +   depends on !CPU_THERMAL || THERMAL
> select PM_OPP
> help
>   This enables the Generic CPUfreq driver for ARM big.LITTLE 
> platforms.
> diff --git a/drivers/cpufreq/arm_big_little.c 
> b/drivers/cpufreq/arm_big_little.c
> index c5d256c..60d09c0 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufreq/arm_big_little.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -55,6 +56,7 @@ static bool bL_switching_enabled;
>  #define ACTUAL_FREQ(cluster, freq)  ((cluster == A7_CLUSTER) ? freq << 1 : 
> freq)
>  #define VIRT_FREQ(cluster, freq)((cluster == A7_CLUSTER) ? freq >> 1 : 
> freq)
>
> +static struct thermal_cooling_device *cdev[MAX_CLUSTERS];
>  static struct cpufreq_arm_bL_ops *arm_bL_ops;
>  static struct clk *clk[MAX_CLUSTERS];
>  static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
> @@ -493,6 +495,7 @@ static int bL_cpufreq_init(struct cpufreq_policy *policy)
>  static int bL_cpufreq_exit(struct cpufreq_policy *policy)
>  {
> struct device *cpu_dev;
> +   int domain;
>
> cpu_dev = get_cpu_device(policy->cpu);
> if (!cpu_dev) {
> @@ -501,12 +504,43 @@ static int bL_cpufreq_exit(struct cpufreq_policy 
> *policy)
> return -ENODEV;
> }
>
> +   domain = topology_physical_package_id(cpu_dev->id);

And this is broken.

Have you tested this for IKS ? That's what the primary use-case of
this driver is.
And yeah, I would like to migrate the bL usecase to cpufreq-dt, now that it can
support multiple clusters.

This is broken, because exit() might get called for a CPU from big
cluster, while
read() was called for a CPU on little cluster.

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V4 2/2] arm64: bpf: make BPF prologue and epilogue align with ARM64 AAPCS

2015-11-16 Thread Alexei Starovoitov
On Mon, Nov 16, 2015 at 08:37:11PM -0800, Z Lim wrote:
> On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi  wrote:
> > Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> > in prologue in order to get the correct stack backtrace.
...
> > CC: Zi Shen Lim 
> > CC: Xi Wang 
> > Signed-off-by: Yang Shi 
> 
> Acked-by: Zi Shen Lim 

great that it's finalized.
Yang, please resubmit both patches to netdev as fresh submission so it
gets picked up by patchwork.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

2015-11-16 Thread Krzysztof Kozlowski
On 17.11.2015 13:31, pankaj.dubey wrote:
> 
> 
> On Monday 16 November 2015 07:06 AM, Krzysztof Kozlowski wrote:
>> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
>> so it is built also on ARMv7. This does not bring any kind of benefit.
>> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
>> multi_v7 for ARMv7).
>>
>> Instead build clock drivers only for respective SoC's architecture.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  drivers/clk/samsung/Kconfig  | 13 +
>>  drivers/clk/samsung/Makefile |  4 ++--
>>  2 files changed, 15 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
>> index 84196ecdaa12..5f138fc4d84d 100644
>> --- a/drivers/clk/samsung/Kconfig
>> +++ b/drivers/clk/samsung/Kconfig
>> @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
>>  bool
>>  select COMMON_CLK
>>  
>> +# ARMv7 SoCs:
>>  config S3C2410_COMMON_CLK
>>  bool
>>  select COMMON_CLK_SAMSUNG
>> @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
>>  bool
>>  select COMMON_CLK_SAMSUNG
>>  
>> +# ARMv8 SoCs:
>> +config EXYNOS5433_COMMON_CLK
>> +bool
>> +depends on ARM64 || COMPILE_TEST
>> +default ARCH_EXYNOS
>> +select COMMON_CLK_SAMSUNG
>> +
>> +config EXYNOS7_COMMON_CLK
>> +bool
>> +depends on ARM64 || COMPILE_TEST
>> +default ARCH_EXYNOS
>> +select COMMON_CLK_SAMSUNG
>> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
>> index 5f6833ea355d..a31332a24ef4 100644
>> --- a/drivers/clk/samsung/Makefile
>> +++ b/drivers/clk/samsung/Makefile
>> @@ -10,11 +10,11 @@ obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
>>  obj-$(CONFIG_SOC_EXYNOS5260)+= clk-exynos5260.o
>>  obj-$(CONFIG_SOC_EXYNOS5410)+= clk-exynos5410.o
>>  obj-$(CONFIG_SOC_EXYNOS5420)+= clk-exynos5420.o
>> -obj-$(CONFIG_ARCH_EXYNOS)   += clk-exynos5433.o
>> +obj-$(CONFIG_EXYNOS5433_COMMON_CLK) += clk-exynos5433.o
>>  obj-$(CONFIG_SOC_EXYNOS5440)+= clk-exynos5440.o
>>  obj-$(CONFIG_ARCH_EXYNOS)   += clk-exynos-audss.o
>>  obj-$(CONFIG_ARCH_EXYNOS)   += clk-exynos-clkout.o
>> -obj-$(CONFIG_ARCH_EXYNOS7)  += clk-exynos7.o
>> +obj-$(CONFIG_EXYNOS7_COMMON_CLK)+= clk-exynos7.o
>>  obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
>>  obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
>>  obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
>>
> 
> So in this approach we need to add separate config for clock support of
> each ARM64 Exynos64 SoC. Is this fine?
> 
> Can we club compilation of each ARM64 Exynos SoC clock file under
> EXYNOS7_COMMON_CLK? As for all ARM64 SoC there is single defconfig and
> binary.

Yes, it can be one config symbol for all clocks of ARMv8 Exynos SoCs.
>From my point of view both has some advantages and disadvantages (kernel
size, granularity, number of Kconfig symbols etc.) and I don't mind
choosing different than I selected before.

Any opinion from Samsung clock maintainers? Which do you prefer?

Best regards,
Krzysztof
it even looks

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/13] perf test: Test BPF prologue

2015-11-16 Thread Wangnan (F)



On 2015/11/17 9:29, Arnaldo Carvalho de Melo wrote:

Em Mon, Nov 16, 2015 at 12:10:14PM +, Wang Nan escreveu:

This patch introduces a new BPF script to test BPF prologue. The new
script probes at null_lseek, which is the function pointer when we try
to lseek on '/dev/null'.

null_lseek is chosen because it is a function pointer, so we don't need
to consider inlining and LTO.

By extracting file->f_mode, bpf-script-test-prologue.c should know whether
the file is writable or readonly. According to llseek_loop() and
bpf-script-test-prologue.c, one forth of total lseeks should be collected.

So I tentatively changed the section name key=val separator from '\n' to
';', applied all the patches up to this one (will review the last one
tomorrow), and tested it, reproducing your results, for some reason that
SEC() wasn't working, have to check again, using it expanded, as in my
previous tests, works, I updated the comments to reflect the tests I
did, please take a look.

I've pushed everything to my perf/ebpf branch, please let me know if
what is there is acceptable, then it will be up to Ingo to decide where
to put this, if in perf/urgent for this merge window, or in perf/core,
for the next one.

Ah, to extract the output for these BPF sub-tests I had to use -v, i.e.
just:

   # perf test BPF
   37: Test BPF filter  : Ok
   #

Ditto for the LLVM one.

Doesn't tell us too much about all those nice sub-tests...

How about:

   # perf test -v BPF
   37: Test BPF filter:
   37.1: test a: Ok
   37.2: test b: Ok
   37.3: Test BPF prologue generation  : Ok
   37.4: Another... : Ok
   37: Test BPF filter : Ok
   #

Thanks!


I think what you want is to report state of subtests *without* -v?

That would be nice but changing of perf testing infrastructure is required
because there's no "sub-test" before, and we both agree that testcase
should be silent without '-v', so we need a way to output them in
builtin-test.c.

Let me try it but I think it should not be a blocking problem.

Thank you.

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


Re: [PATCH V4 2/2] arm64: bpf: make BPF prologue and epilogue align with ARM64 AAPCS

2015-11-16 Thread Z Lim
On Mon, Nov 16, 2015 at 2:35 PM, Yang Shi  wrote:
> Save and restore FP/LR in BPF prog prologue and epilogue, save SP to FP
> in prologue in order to get the correct stack backtrace.
>
> However, ARM64 JIT used FP (x29) as eBPF fp register, FP is subjected to
> change during function call so it may cause the BPF prog stack base address
> change too.
>
> Use x25 to replace FP as BPF stack base register (fp). Since x25 is callee
> saved register, so it will keep intact during function call.
> It is initialized in BPF prog prologue when BPF prog is started to run
> everytime. Save and restore x25/x26 in BPF prologue and epilogue to keep
> them intact for the outside of BPF. Actually, x26 is unnecessary, but SP
> requires 16 bytes alignment.
>
> So, the BPF stack layout looks like:
>
>  high
>  original A64_SP =>   0:+-+ BPF prologue
> |FP/LR|
>  current A64_FP =>  -16:+-+
> | ... | callee saved registers
> +-+
> | | x25/x26
>  BPF fp register => -80:+-+
> | |
> | ... | BPF prog stack
> | |
> | |
>  current A64_SP =>  +-+
> | |
> | ... | Function call stack
> | |
> +-+
>   low
>
> CC: Zi Shen Lim 
> CC: Xi Wang 
> Signed-off-by: Yang Shi 

Acked-by: Zi Shen Lim 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 0/3] Dynamic power model from device tree

2015-11-16 Thread Viresh Kumar
On Tue, Nov 17, 2015 at 1:00 AM, Punit Agrawal  wrote:
> Hi,
>
> This patchset adds support to build a single-coefficient dynamic power
> model for a CPU. The model is used by the CPU cooling device to
> provide an estimate of power consumption and also translate allocated
> power to performance cap.
>
> Changes from previous posting -
>
> v3 -> v4:
> arm_big_little: Migrated to using static arrays
> arm_big_little: Updated Kconfig to support building thermal as module
>
> Patch 1 extends the CPU nodes binding to provide an optional dynamic
> power coefficient which can be used to create a dynamic power model
> for the CPUs. This model is used to constrain device power consumption
> (using power_allocator governor) when the system is thermally
> constrained.
>
> Patches 2-3 extends the cpufreq-dt and arm_big_little driver to
> register cpu cooling devices with the dynamic coefficient when
> provided.
>
> The patches were previously posted at [0][1][2]. Mediatek platform
> 8173 builds on these bindings to build the power model.
>
> If there are no objections, I'd appreciate Acks from device tree
> bindings maintainers.

You forgot to cc cpufreq maintainers for this and there are good chances
that I may completely miss the series some times..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v4 1/3] devicetree: bindings: Add optional dynamic-power-coefficient property

2015-11-16 Thread Viresh Kumar
On Tue, Nov 17, 2015 at 1:00 AM, Punit Agrawal  wrote:
> The dynamic power consumption of a device is proportional to the
> square of voltage (V) and the clock frequency (f). It can be expressed as
>
> Pdyn = dynamic-power-coefficient * V^2 * f.
>
> The coefficient represents the running time dynamic power consumption in
> units of mw/MHz/uVolt^2 and can be used in the above formula to
> calculate the dynamic power in mW.
>
> Signed-off-by: Punit Agrawal 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3a07a87..6aca64f 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -242,6 +242,23 @@ nodes to be present and contain the properties described 
> below.
> Definition: Specifies the syscon node controlling the cpu core
> power domains.
>
> +   - dynamic-power-coefficient
> +   Usage: optional
> +   Value type: 
> +   Definition: A u32 value that represents the running time 
> dynamic
> +   power coefficient in units of mW/MHz/uVolt^2. The
> +   coefficient can either be calculated from power
> +   measurements or derived by analysis.
> +
> +   The dynamic power consumption of the CPU  is
> +   proportional to the square of the Voltage (V) and
> +   the clock frequency (f). The coefficient is used 
> to
> +   calculate the dynamic power as below -
> +
> +   Pdyn = dynamic-power-coefficient * V^2 * f
> +
> +   where voltage is in uV, frequency is in MHz.
> +
>  Example 1 (dual-cluster big.LITTLE system 32-bit):
>
> cpus {

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


[PATCH v5 2/2] simplefb: Claim and enable regulators

2015-11-16 Thread Chen-Yu Tsai
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Mark Brown 
---
 drivers/video/fbdev/simplefb.c | 120 -
 1 file changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..48ccf6db62a2 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
 #endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+   u32 regulator_count;
+   struct regulator **regulators;
+#endif
 };
 
 #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
 static void simplefb_clocks_destroy(struct simplefb_par *par) { }
 #endif
 
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+   struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct property *prop;
+   struct regulator *regulator;
+   const char *p;
+   int count = 0, i = 0, ret;
+
+   if (dev_get_platdata(&pdev->dev) || !np)
+   return 0;
+
+   /* Count the number of regulator supplies */
+   for_each_property_of_node(np, prop) {
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (p && p != prop->name)
+   count++;
+   }
+
+   if (!count)
+   return 0;
+
+   par->regulators = devm_kcalloc(&pdev->dev, count,
+  sizeof(struct regulator *), GFP_KERNEL);
+   if (!par->regulators)
+   return -ENOMEM;
+
+   /* Get all the regulators */
+   for_each_property_of_node(np, prop) {
+   char name[32]; /* 32 is max size of property name */
+
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (!p || p == prop->name)
+   continue;
+
+   strlcpy(name, prop->name,
+   strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
+   regulator = devm_regulator_get_optional(&pdev->dev, name);
+   if (IS_ERR(regulator)) {
+   if (PTR_ERR(regulator) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(&pdev->dev, "regulator %s not found: %ld\n",
+   name, PTR_ERR(regulator));
+   continue;
+   }
+   par->regulators[i++] = regulator;
+   }
+   par->regulator_count = i;
+
+   /* Enable all the regulators */
+   for (i = 0; i < par->regulator_count; i++) {
+   ret = regulator_enable(par->regulators[i]);
+   if (ret) {
+   dev_err(&pdev->dev,
+   "failed to enable regulator %d: %d\n",
+   i, ret);
+   devm_regulator_put(par->regulators[i]);
+   par->regulators[i] = NULL;
+   }
+   }
+
+   return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+   int i;
+
+   if (!par->regulators)
+   return;
+
+   for (i = 0; i < par->regulator_count; i++)
+   if (par->regulators[i])
+   regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+   struct platform_device *pdev) { return 0; }
+static void s

[PATCH v5 1/2] dt-bindings: simplefb: Support regulator supply properties

2015-11-16 Thread Chen-Yu Tsai
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.

The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Hans de Goede 
Acked-by: Mark Brown 
---
 .../devicetree/bindings/display/simple-framebuffer.txt  | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.txt 
b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
   - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
 
 Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
-   are expected to already be configured correctly. The OS must
-   ensure these clocks are not modified or disabled while the
-   simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+be named according to the names in the device's design.
+
+  The above resources are expected to already be configured correctly.
+  The OS must ensure they are not modified or disabled while the simple
+  framebuffer remains active.
+
 - display : phandle pointing to the primary display hardware node
 
 Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>;
+   lcd-supply = <®_dc1sw>;
display = <&lcdc0>;
};
stdout-path = "display0";
-- 
2.6.2

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


Re: [PATCH 1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7

2015-11-16 Thread pankaj.dubey


On Monday 16 November 2015 07:06 AM, Krzysztof Kozlowski wrote:
> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS
> so it is built also on ARMv7. This does not bring any kind of benefit.
> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like
> multi_v7 for ARMv7).
> 
> Instead build clock drivers only for respective SoC's architecture.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/clk/samsung/Kconfig  | 13 +
>  drivers/clk/samsung/Makefile |  4 ++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig
> index 84196ecdaa12..5f138fc4d84d 100644
> --- a/drivers/clk/samsung/Kconfig
> +++ b/drivers/clk/samsung/Kconfig
> @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG
>   bool
>   select COMMON_CLK
>  
> +# ARMv7 SoCs:
>  config S3C2410_COMMON_CLK
>   bool
>   select COMMON_CLK_SAMSUNG
> @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK
>   bool
>   select COMMON_CLK_SAMSUNG
>  
> +# ARMv8 SoCs:
> +config EXYNOS5433_COMMON_CLK
> + bool
> + depends on ARM64 || COMPILE_TEST
> + default ARCH_EXYNOS
> + select COMMON_CLK_SAMSUNG
> +
> +config EXYNOS7_COMMON_CLK
> + bool
> + depends on ARM64 || COMPILE_TEST
> + default ARCH_EXYNOS
> + select COMMON_CLK_SAMSUNG
> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
> index 5f6833ea355d..a31332a24ef4 100644
> --- a/drivers/clk/samsung/Makefile
> +++ b/drivers/clk/samsung/Makefile
> @@ -10,11 +10,11 @@ obj-$(CONFIG_SOC_EXYNOS5250)  += clk-exynos5250.o
>  obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o
>  obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
>  obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
> -obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos5433.o
> +obj-$(CONFIG_EXYNOS5433_COMMON_CLK)  += clk-exynos5433.o
>  obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
>  obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-audss.o
>  obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-clkout.o
> -obj-$(CONFIG_ARCH_EXYNOS7)   += clk-exynos7.o
> +obj-$(CONFIG_EXYNOS7_COMMON_CLK) += clk-exynos7.o
>  obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
>  obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
>  obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
> 

So in this approach we need to add separate config for clock support of
each ARM64 Exynos64 SoC. Is this fine?

Can we club compilation of each ARM64 Exynos SoC clock file under
EXYNOS7_COMMON_CLK? As for all ARM64 SoC there is single defconfig and
binary.


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


[PATCH v5 0/2] simplefb: Add regulator handling support

2015-11-16 Thread Chen-Yu Tsai
Hi everyone,

This is v5 of the simplefb regulator support series. This series adds
regulator claiming and enabling support for simplefb.

Hans, I dropped your Reviewed-by tag from patch 2 since v4.

Changes since v5:
  - Rebased onto v4.4-rc1
  - Dropped dts patches (merged)

Changes since v4:
  - Fixed inverted logic when testing the property name.
  - Fixed regulator supply name string copy length off by 1.
  - Added real world user, MSI Primo 81 dts patches.

Changes since v3:
  - Dropped extra "if" which is always true, leftover from v1.
  - Updated commit message of patch 1

Sometimes the simplefb display output path consits of external conversion
chips and/or LCD drivers and backlights. These devices normally have
GPIOs to turn them on and/or bring them out of reset, and regulators
supplying power to them.

While the kernel does not touch unclaimed GPIOs, the regulator core
happily disables unused regulators. Thus we need simplefb to claim
and enable the regulators used throughout the display pipeline.

The binding supports any named regulator supplies under its device
node. The driver will look through its properties, and claim any
regulators by matching "*-supply", as Mark suggested.

I've not done a generic helper in the regulator core yet, instead doing
the regulator property handling in the simplefb code for now.


Patch 1 adds the regulator properties to the DT binding.

Patch 2 adds code to the simplefb driver to claim and enable regulators.

Regards
ChenYu


Chen-Yu Tsai (2):
  dt-bindings: simplefb: Support regulator supply properties
  simplefb: Claim and enable regulators

 .../bindings/display/simple-framebuffer.txt|  13 ++-
 drivers/video/fbdev/simplefb.c | 120 -
 2 files changed, 128 insertions(+), 5 deletions(-)

-- 
2.6.2

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


Re: [PATCH v5 9/9] drivers: soc: Add support for Exynos PMU driver

2015-11-16 Thread Krzysztof Kozlowski
On 17.11.2015 12:44, pankaj.dubey wrote:
> 
> 
> On Saturday 14 November 2015 05:00 PM, Krzysztof Kozlowski wrote:
>> W dniu 14.11.2015 o 00:36, Pankaj Dubey pisze:
>>> On 13 November 2015 at 15:58, Krzysztof Kozlowski
>>>  wrote:

 On 13.11.2015 18:29, Pankaj Dubey wrote:
> This patch moves Exynos PMU driver implementation from
> "arm/mach-exynos"
> to "drivers/soc/samsung". This driver is mainly used for setting misc
> bits of register from PMU IP of Exynos SoC which will be required to
> configure before Suspend/Resume. Currently all these settings are done
> in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
> support, there is a need of this PMU driver in driver/* folder.
>
> This driver uses existing DT binding information and there should
> be no functionality change in the supported platforms.
>
> Signed-off-by: Amit Daniel Kachhap 
> Signed-off-by: Pankaj Dubey 
> ---
>   arch/arm/mach-exynos/Kconfig   | 1 +
>   arch/arm/mach-exynos/Makefile  |
> 4 +---
>   drivers/soc/samsung/Kconfig|
> 4 
>   drivers/soc/samsung/Makefile   |
> 4 
>   arch/arm/mach-exynos/pmu.c => drivers/soc/samsung/exynos-pmu.c | 0
>   {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h | 0
>   {arch/arm/mach-exynos => drivers/soc/samsung}/exynos3250-pmu.c | 0
>   {arch/arm/mach-exynos => drivers/soc/samsung}/exynos4-pmu.c| 0
>   {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5250-pmu.c | 0
>   {arch/arm/mach-exynos => drivers/soc/samsung}/exynos5420-pmu.c | 0
>   10 files changed, 10 insertions(+), 3 deletions(-)
>   rename arch/arm/mach-exynos/pmu.c =>
> drivers/soc/samsung/exynos-pmu.c (100%)
>   rename {arch/arm/mach-exynos => drivers/soc/samsung}/exynos-pmu.h
> (100%)
>   rename {arch/arm/mach-exynos =>
> drivers/soc/samsung}/exynos3250-pmu.c (100%)
>   rename {arch/arm/mach-exynos =>
> drivers/soc/samsung}/exynos4-pmu.c (100%)
>   rename {arch/arm/mach-exynos =>
> drivers/soc/samsung}/exynos5250-pmu.c (100%)
>   rename {arch/arm/mach-exynos =>
> drivers/soc/samsung}/exynos5420-pmu.c (100%)
>
> diff --git a/arch/arm/mach-exynos/Kconfig
> b/arch/arm/mach-exynos/Kconfig
> index 83c85f5..874cb38 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -16,6 +16,7 @@ menuconfig ARCH_EXYNOS
>select ARM_GIC
>select COMMON_CLK_SAMSUNG
>select EXYNOS_THERMAL
> + select EXYNOS_PMU
>select EXYNOS_SROM if PM
>select HAVE_ARM_SCU if SMP
>select HAVE_S3C2410_I2C if I2C
> diff --git a/arch/arm/mach-exynos/Makefile
> b/arch/arm/mach-exynos/Makefile
> index 2d58063..34d29df 100644
> --- a/arch/arm/mach-exynos/Makefile
> +++ b/arch/arm/mach-exynos/Makefile
> @@ -9,9 +9,7 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) +=
> -I$(srctree)/$(src)/include -I$(srctree)
>
>   # Core
>
> -obj-$(CONFIG_ARCH_EXYNOS)+= exynos.o pmu.o exynos-smc.o
> firmware.o \
> - exynos3250-pmu.o exynos4-pmu.o \
> - exynos5250-pmu.o
> exynos5420-pmu.o
> +obj-$(CONFIG_ARCH_EXYNOS)+= exynos.o exynos-smc.o firmware.o
>
>   obj-$(CONFIG_EXYNOS_CPU_SUSPEND) += pm.o sleep.o
>   obj-$(CONFIG_PM_SLEEP)   += suspend.o
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 2833b5b..f545d6c 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -10,4 +10,8 @@ config EXYNOS_SROM
>bool
>depends on ARM && ARCH_EXYNOS && PM
>
> +config EXYNOS_PMU
> + bool
> + depends on ARCH_EXYNOS
> +
>   endmenu
> diff --git a/drivers/soc/samsung/Makefile
> b/drivers/soc/samsung/Makefile
> index 9c554d5..26fb489 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -1 +1,5 @@
>   obj-$(CONFIG_EXYNOS_SROM)+= exynos-srom.o
> +ifdef CONFIG_ARM
> +obj-$(CONFIG_EXYNOS_PMU) += exynos-pmu.o exynos3250-pmu.o
> exynos4-pmu.o \
> + exynos5250-pmu.o
> exynos5420-pmu.o
> +endif

 Why ifdef CONFIG_ARM? This already depends on ARCH_EXYNOS. If you want
 to limit to ARMv7 then add the dependency to Kconfig (just like
 EXYNOS_SROM).

>>>
>>> This is required, so that 32-bit based Exynos SoC's PMU should not get
>>> compiled when we are compiling for ARM64 and vice-versa.
>>>
>>> For example: In future, I have plan to add exynos7 PMU support as -
>>>
>>> ifdef CONFIG_ARM64
>>> obj-$(CONFIG_EXYNOS_PMU) += exy

Re: [PATCH 2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS

2015-11-16 Thread pankaj.dubey


On Monday 16 November 2015 07:06 AM, Krzysztof Kozlowski wrote:
> The ARMv8 Exynos family SoCs in Linux kernel are currently:
>  - Exynos5433 (controlled by ARCH_EXYNOS),
>  - Exynos7 (controlled by ARCH_EXYNOS7).
> 
> It duplicates Kconfig symbols unnecessarily, so consolidate them into
> one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS
> symbol.
> 
> The commit should not bring any visible functional change.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm64/Kconfig.platforms| 11 ++-
>  arch/arm64/boot/dts/exynos/Makefile |  2 +-
>  arch/arm64/configs/defconfig|  2 +-
>  3 files changed, 4 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 4043c35962cc..afa19baca94e 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -13,21 +13,14 @@ config ARCH_BERLIN
> This enables support for Marvell Berlin SoC Family
>  
>  config ARCH_EXYNOS
> - bool
> - help
> -   This enables support for Samsung Exynos SoC family
> -
> -config ARCH_EXYNOS7
> - bool "ARMv8 based Samsung Exynos7"
> - select ARCH_EXYNOS
> + bool "ARMv8 based Samsung Exynos SoC family"
>   select COMMON_CLK_SAMSUNG
>   select HAVE_S3C2410_WATCHDOG if WATCHDOG
>   select HAVE_S3C_RTC if RTC_CLASS
>   select PINCTRL
>   select PINCTRL_EXYNOS
> -
>   help
> -   This enables support for Samsung Exynos7 SoC family
> +   This enables support for Samsung Exynos ARMv8 SoC family
>  
>  config ARCH_LAYERSCAPE
>   bool "ARMv8 based Freescale Layerscape SoC family"
> diff --git a/arch/arm64/boot/dts/exynos/Makefile 
> b/arch/arm64/boot/dts/exynos/Makefile
> index 20310e5b6d6f..50c9b9383cfa 100644
> --- a/arch/arm64/boot/dts/exynos/Makefile
> +++ b/arch/arm64/boot/dts/exynos/Makefile
> @@ -1,4 +1,4 @@
> -dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb
> +dtb-$(CONFIG_ARCH_EXYNOS) += exynos7-espresso.dtb
>  
>  always   := $(dtb-y)
>  subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index bdd7aa358d2a..a396fa7c69a5 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -33,7 +33,7 @@ CONFIG_MODULE_UNLOAD=y
>  # CONFIG_IOSCHED_DEADLINE is not set
>  CONFIG_ARCH_BCM_IPROC=y
>  CONFIG_ARCH_BERLIN=y
> -CONFIG_ARCH_EXYNOS7=y
> +CONFIG_ARCH_EXYNOS=y
>  CONFIG_ARCH_LAYERSCAPE=y
>  CONFIG_ARCH_HISI=y
>  CONFIG_ARCH_MEDIATEK=y
> 

Reviewed-by: Pankaj Dubey 

Thanks,
Pankaj Dubey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: mediatek: fix a memleak when do dt maps.

2015-11-16 Thread Hongzhou Yang
configs will kmemdup to dup_configs in pictrl util function.
So configs need to be freed.

Signed-off-by: Hongzhou Yang 
---
 Fix a memleak issue.

 drivers/pinctrl/mediatek/pinctrl-mtk-common.c |   24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index bbf0230..0f9e416 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -520,21 +520,23 @@ static int mtk_pctrl_dt_subnode_to_map(struct pinctrl_dev 
*pctldev,
if (has_config && num_pins >= 1)
maps_per_pin++;
 
-   if (!num_pins || !maps_per_pin)
-   return -EINVAL;
+   if (!num_pins || !maps_per_pin) {
+   err = -EINVAL;
+   goto exit;
+   }
 
reserve = num_pins * maps_per_pin;
 
err = pinctrl_utils_reserve_map(pctldev, map,
reserved_maps, num_maps, reserve);
if (err < 0)
-   goto fail;
+   goto exit;
 
for (i = 0; i < num_pins; i++) {
err = of_property_read_u32_index(node, "pinmux",
i, &pinfunc);
if (err)
-   goto fail;
+   goto exit;
 
pin = MTK_GET_PIN_NO(pinfunc);
func = MTK_GET_PIN_FUNC(pinfunc);
@@ -543,20 +545,21 @@ static int mtk_pctrl_dt_subnode_to_map(struct pinctrl_dev 
*pctldev,
func >= ARRAY_SIZE(mtk_gpio_functions)) {
dev_err(pctl->dev, "invalid pins value.\n");
err = -EINVAL;
-   goto fail;
+   goto exit;
}
 
grp = mtk_pctrl_find_group_by_pin(pctl, pin);
if (!grp) {
dev_err(pctl->dev, "unable to match pin %d to group\n",
pin);
-   return -EINVAL;
+   err = -EINVAL;
+   goto exit;
}
 
err = mtk_pctrl_dt_node_to_map_func(pctl, pin, func, grp, map,
reserved_maps, num_maps);
if (err < 0)
-   goto fail;
+   goto exit;
 
if (has_config) {
err = pinctrl_utils_add_map_configs(pctldev, map,
@@ -564,13 +567,14 @@ static int mtk_pctrl_dt_subnode_to_map(struct pinctrl_dev 
*pctldev,
configs, num_configs,
PIN_MAP_TYPE_CONFIGS_GROUP);
if (err < 0)
-   goto fail;
+   goto exit;
}
}
 
-   return 0;
+   err = 0;
 
-fail:
+exit:
+   kfree(configs);
return err;
 }
 
-- 
1.7.9.5

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


[PATCH 1/7] misc: eeprom: 93xx46: Fix 16-bit read and write accesses.

2015-11-16 Thread Cory Tusar
Compatible at93xx46 devices from both Microchip and Atmel expect a
word-based address, regardless of whether the device is strapped for 8-
or 16-bit operation.  However, the offset parameter passed in when
reading or writing at a specific location is always specified in terms
of bytes.

This commit fixes 16-bit read and write accesses by shifting the offset
parameter to account for this difference between a byte offset and a
word-based address.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index ff63f05..e1bf0a5 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -54,7 +54,7 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject 
*kobj,
cmd_addr |= off & 0x7f;
bits = 10;
} else {
-   cmd_addr |= off & 0x3f;
+   cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
}
 
@@ -155,7 +155,7 @@ eeprom_93xx46_write_word(struct eeprom_93xx46_dev *edev,
bits = 10;
data_len = 1;
} else {
-   cmd_addr |= off & 0x3f;
+   cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
data_len = 2;
}
-- 
2.4.10

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


[PATCH 5/7] misc: eeprom: 93xx46: Add quirks to support Atmel AT93C46D device.

2015-11-16 Thread Cory Tusar
Atmel devices in this family have some quirks not found in other similar
chips - they do not support a sequential read of the entire EEPROM
contents, and the control word sent at the start of each operation
varies in bit length.

This commit adds quirk support to the driver and modifies the read
implementation to support non-sequential reads for consistency with
other misc/eeprom drivers.

Tested on a custom Freescale VF610-based platform, with an AT93C46D
device attached via dspi2.  The spi-gpio driver was used to allow the
necessary non-byte-sized transfers.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 128 ++--
 include/linux/eeprom_93xx46.h   |   6 ++
 2 files changed, 98 insertions(+), 36 deletions(-)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index 1f29d9a..0386b03 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -27,6 +27,15 @@
 #define ADDR_ERAL  0x20
 #define ADDR_EWEN  0x30
 
+struct eeprom_93xx46_devtype_data {
+   unsigned int quirks;
+};
+
+static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
+   .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
+ EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
+};
+
 struct eeprom_93xx46_dev {
struct spi_device *spi;
struct eeprom_93xx46_platform_data *pdata;
@@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
int addrlen;
 };
 
+static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
+{
+   return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ);
+}
+
+static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev *edev)
+{
+   return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH);
+}
+
 static ssize_t
 eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
   struct bin_attribute *bin_attr,
@@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject 
*kobj,
 {
struct eeprom_93xx46_dev *edev;
struct device *dev;
-   struct spi_message m;
-   struct spi_transfer t[2];
-   int bits, ret;
-   u16 cmd_addr;
+   ssize_t ret = 0;
 
dev = container_of(kobj, struct device, kobj);
edev = dev_get_drvdata(dev);
 
-   cmd_addr = OP_READ << edev->addrlen;
+   mutex_lock(&edev->lock);
 
-   if (edev->addrlen == 7) {
-   cmd_addr |= off & 0x7f;
-   bits = 10;
-   } else {
-   cmd_addr |= (off >> 1) & 0x3f;
-   bits = 9;
-   }
+   if (edev->pdata->prepare)
+   edev->pdata->prepare(edev);
 
-   dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
-   cmd_addr, edev->spi->max_speed_hz);
+   while (count) {
+   struct spi_message m;
+   struct spi_transfer t[2] = { { 0 } };
+   u16 cmd_addr = OP_READ << edev->addrlen;
+   size_t nbytes = count;
+   int bits;
+   int err;
+
+   if (edev->addrlen == 7) {
+   cmd_addr |= off & 0x7f;
+   bits = 10;
+   if (has_quirk_single_word_read(edev))
+   nbytes = 1;
+   } else {
+   cmd_addr |= (off >> 1) & 0x3f;
+   bits = 9;
+   if (has_quirk_single_word_read(edev))
+   nbytes = 2;
+   }
 
-   spi_message_init(&m);
-   memset(t, 0, sizeof(t));
+   dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
+   cmd_addr, edev->spi->max_speed_hz);
 
-   t[0].tx_buf = (char *)&cmd_addr;
-   t[0].len = 2;
-   t[0].bits_per_word = bits;
-   spi_message_add_tail(&t[0], &m);
+   spi_message_init(&m);
 
-   t[1].rx_buf = buf;
-   t[1].len = count;
-   t[1].bits_per_word = 8;
-   spi_message_add_tail(&t[1], &m);
+   t[0].tx_buf = (char *)&cmd_addr;
+   t[0].len = 2;
+   t[0].bits_per_word = bits;
+   spi_message_add_tail(&t[0], &m);
 
-   mutex_lock(&edev->lock);
+   t[1].rx_buf = buf;
+   t[1].len = count;
+   t[1].bits_per_word = 8;
+   spi_message_add_tail(&t[1], &m);
 
-   if (edev->pdata->prepare)
-   edev->pdata->prepare(edev);
+   err = spi_sync(edev->spi, &m);
+   /* have to wait at least Tcsl ns */
+   ndelay(250);
 
-   ret = spi_sync(edev->spi, &m);
-   /* have to wait at least Tcsl ns */
-   ndelay(250);
-   if (ret) {
-   dev_err(&edev->spi->dev, "read %zu bytes at %d: err. %d\n",
-   count, (int)off, ret);
+   if (err) {
+   dev_err(&edev->spi->dev, "read %zu bytes at %d: err. 
%d\

[PATCH 3/7] misc: eeprom: 93xx46: Implement eeprom_93xx46 DT bindings.

2015-11-16 Thread Cory Tusar
This commit implements bindings in the eeprom_93xx46 driver allowing
device word size and read-only attributes to be specified via
devicetree.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 62 +
 1 file changed, 62 insertions(+)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index e1bf0a5..1f29d9a 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -294,12 +296,71 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
*dev,
 }
 static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
 
+#ifdef CONFIG_OF
+static const struct of_device_id eeprom_93xx46_of_table[] = {
+   { .compatible = "eeprom-93xx46", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+
+static int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+   struct device_node *np = spi->dev.of_node;
+   struct eeprom_93xx46_platform_data *pd;
+   u32 tmp;
+   int ret;
+
+   if (!of_match_device(eeprom_93xx46_of_table, &spi->dev))
+   return 0;
+
+   pd = devm_kzalloc(&spi->dev, sizeof(*pd), GFP_KERNEL);
+   if (!pd)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "data-size", &tmp);
+   if (ret < 0) {
+   dev_err(&spi->dev, "data-size property not found\n");
+   goto error_free;
+   }
+
+   if (tmp == 8) {
+   pd->flags |= EE_ADDR8;
+   } else if (tmp == 16) {
+   pd->flags |= EE_ADDR16;
+   } else {
+   dev_err(&spi->dev, "invalid data-size (%d)\n", tmp);
+   goto error_free;
+   }
+
+   if (of_property_read_bool(np, "read-only"))
+   pd->flags |= EE_READONLY;
+
+   spi->dev.platform_data = pd;
+
+   return 1;
+
+error_free:
+   devm_kfree(&spi->dev, pd);
+   return ret;
+}
+
+#else
+static inline int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+   return 0;
+}
+#endif
+
 static int eeprom_93xx46_probe(struct spi_device *spi)
 {
struct eeprom_93xx46_platform_data *pd;
struct eeprom_93xx46_dev *edev;
int err;
 
+   err = eeprom_93xx46_probe_dt(spi);
+   if (err < 0)
+   return err;
+
pd = spi->dev.platform_data;
if (!pd) {
dev_err(&spi->dev, "missing platform data\n");
@@ -370,6 +431,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
 static struct spi_driver eeprom_93xx46_driver = {
.driver = {
.name   = "93xx46",
+   .of_match_table = eeprom_93xx46_of_table,
},
.probe  = eeprom_93xx46_probe,
.remove = eeprom_93xx46_remove,
-- 
2.4.10

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


[PATCH 6/7] misc: eeprom: 93xx46: Add DT binding for a GPIO 'select' line.

2015-11-16 Thread Cory Tusar
This commit documents an additional devicetree binding in the
eeprom_93x46 driver allowing a GPIO line to function as a 'select'
or 'enable' signal prior to accessing the EEPROM.

Signed-off-by: Cory Tusar 
---
 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt 
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
index 34a0cc2..75b16f4 100644
--- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -6,6 +6,8 @@ Required properties:
 
 Optional properties:
 - read-only : parameter-less property which disables writes to the EEPROM
+- select-gpio : if present, specifies the GPIO that will be asserted prior to
+  each access to the EEPROM (e.g. for SPI bus multiplexing)
 
 Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
 apply.  In particular, "reg" and "spi-max-frequency" properties must be given.
@@ -17,4 +19,5 @@ Example:
spi-max-frequency = <100>;
spi-cs-high;
data-size = <8>;
+   select-gpio = <&gpio4 4 GPIO_ACTIVE_HIGH>;
};
-- 
2.4.10

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


[PATCH 2/7] misc: eeprom: 93xx46: Add DT bindings to eeprom_93xx46 driver.

2015-11-16 Thread Cory Tusar
This commit documents bindings to be added to the eeprom_93xx46 driver
which allow device word size and read-only attributes to be specified
via devicetree.

Currently the only supported device is a generic "eeprom-93xx46", which
mirrors the configuration options previously available as a platform
device.

Signed-off-by: Cory Tusar 
---
 .../devicetree/bindings/misc/eeprom-93xx46.txt   | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt 
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
new file mode 100644
index 000..ba493a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -0,0 +1,20 @@
+EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
+
+Required properties:
+- compatible : "eeprom-93xx46"
+- data-size : number of data bits per word (either 8 or 16)
+
+Optional properties:
+- read-only : parameter-less property which disables writes to the EEPROM
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply.  In particular, "reg" and "spi-max-frequency" properties must be given.
+
+Example:
+   93c46c@0 {
+   compatible = "eeprom-93xx46";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   spi-cs-high;
+   data-size = <8>;
+   };
-- 
2.4.10

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


[PATCH 7/7] misc: eeprom: 93xx46: Add support for a GPIO 'select' line.

2015-11-16 Thread Cory Tusar
This commit adds support to the eeprom_93x46 driver allowing a GPIO line
to function as a 'select' or 'enable' signal prior to accessing the
EEPROM.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 26 ++
 include/linux/eeprom_93xx46.h   |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index 0386b03..3f41696 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -10,11 +10,14 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -344,6 +347,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
*dev,
 static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
 
 #ifdef CONFIG_OF
+static void select_assert(void *context)
+{
+   struct eeprom_93xx46_dev *edev = context;
+
+   gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 1);
+}
+
+static void select_deassert(void *context)
+{
+   struct eeprom_93xx46_dev *edev = context;
+
+   gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 0);
+}
+
 static const struct of_device_id eeprom_93xx46_of_table[] = {
{ .compatible = "eeprom-93xx46", },
{ .compatible = "atmel,at93c46d", .data = &atmel_at93c46d_data, },
@@ -385,6 +402,15 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
if (of_property_read_bool(np, "read-only"))
pd->flags |= EE_READONLY;
 
+   ret = of_get_named_gpio(np, "select-gpio", 0);
+   if (ret < 0) {
+   pd->select_gpio = -1;
+   } else {
+   pd->select_gpio = ret;
+   pd->prepare = select_assert;
+   pd->finish = select_deassert;
+   }
+
if (of_id->data) {
const struct eeprom_93xx46_devtype_data *data = of_id->data;
 
diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
index 92fa4c3..aa472c7 100644
--- a/include/linux/eeprom_93xx46.h
+++ b/include/linux/eeprom_93xx46.h
@@ -21,4 +21,5 @@ struct eeprom_93xx46_platform_data {
 */
void (*prepare)(void *);
void (*finish)(void *);
+   unsigned int select_gpio;
 };
-- 
2.4.10

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


[PATCH 4/7] misc: eeprom: 93xx46: Add DT binding for Atmel AT93C46D devices.

2015-11-16 Thread Cory Tusar
This commit adds a compatible string to the eeprom_93xx46 devicetree
bindings in support of Atmel AT93C46D devices.

Signed-off-by: Cory Tusar 
---
 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt 
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
index ba493a8..34a0cc2 100644
--- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -1,7 +1,7 @@
 EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
 
 Required properties:
-- compatible : "eeprom-93xx46"
+- compatible : "eeprom-93xx46", "atmel,at93c46d"
 - data-size : number of data bits per word (either 8 or 16)
 
 Optional properties:
-- 
2.4.10

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


[PATCH 0/7] Devicetree support for misc/eeprom/eeprom_93xx46.

2015-11-16 Thread Cory Tusar
This series of patches adds an initial set of devicetree bindings to the
eeprom_93xx46 driver which mirror the configuration options previously
available as a platform device.  These bindings are then extended to
include support for specific Atmel devices in this family and also to
support GPIO-based selection of the device (e.g. for use with an SPI bus
mux).

Additionally, an address aliasing issue with 16-bit read and write
accesses in the eeprom_93xx46 driver discovered during testing is fixed.

Cory Tusar (7):
  misc: eeprom: 93xx46: Fix 16-bit read and write accesses.
  misc: eeprom: 93xx46: Add DT bindings to eeprom_93xx46 driver.
  misc: eeprom: 93xx46: Implement eeprom_93xx46 DT bindings.
  misc: eeprom: 93xx46: Add DT binding for Atmel AT93C46D devices.
  misc: eeprom: 93xx46: Add quirks to support Atmel AT93C46D device.
  misc: eeprom: 93xx46: Add DT binding for a GPIO 'select' line.
  misc: eeprom: 93xx46: Add support for a GPIO 'select' line.

 .../devicetree/bindings/misc/eeprom-93xx46.txt |  23 +++
 drivers/misc/eeprom/eeprom_93xx46.c| 216 +
 include/linux/eeprom_93xx46.h  |   7 +
 3 files changed, 210 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt

-- 
2.4.10

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


Re: [PATCH] Revert "thermal: qcom_spmi: allow compile test"

2015-11-16 Thread Eduardo Valentin
On Mon, Nov 16, 2015 at 10:43:50PM +0100, Arnd Bergmann wrote:
> This just caused build errors:
> 
> warning: (QCOM_SPMI_TEMP_ALARM) selects REGMAP_SPMI which has unmet direct 
> dependencies (SPMI)
> drivers/built-in.o: In function `regmap_spmi_ext_gather_write':
> :(.text+0x609b0): undefined reference to `spmi_ext_register_write'
> :(.text+0x609f0): undefined reference to `spmi_ext_register_writel'
> 
> While it's generally a good idea to allow compile testing, in this
> case, it just doesn't work, so reverting the patch that
> introduced the compile-test variant seems the most appropriate
> solution.

Looking this closer, the original patch simply does not make sense. The
platform dependent code is already covered by the SPMI code.

> 
> Note that SPIMI also has a 'depends on ARCH_QCOM || COMPILE_TEST'
> statement, so we should be able to enable SPMI on all architectures
> for compile testing already.

So, applied. I just s/SPIMI/SPMI/g.

> 
> Signed-off-by: Arnd Bergmann 
> Fixes: cb7fb4d34202 ("thermal: qcom_spmi: allow compile test")
> 
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 2e7524f0f3f7..6045b17d0e00 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -381,7 +381,7 @@ endmenu
>  
>  config QCOM_SPMI_TEMP_ALARM
>   tristate "Qualcomm SPMI PMIC Temperature Alarm"
> - depends on OF && (SPMI || COMPILE_TEST) && IIO
> + depends on OF && SPMI && IIO
>   select REGMAP_SPMI
>   help
> This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] lib/kobject: fix memory leak in error path of kset_create_and_add()

2015-11-16 Thread Greg Kroah-Hartman
On Tue, Nov 17, 2015 at 01:04:19AM +0100, Nicolai Stange wrote:
> In kset_create_and_add(), the name duped into the kset's kobject by
> kset_create() gets leaked if the call to kset_register() fails.
> 
> Indeed, triggering failure by invoking kset_create_and_add() with a
> duplicate name makes kmemleak reporting
> 
>   unreferenced object 0x8800b4a1f428 (size 16):
> comm "insmod", pid 682, jiffies 4294745489 (age 50.477s)
> hex dump (first 16 bytes):
>   64 75 70 6c 69 63 61 74 65 00 6b 6b 6b 6b 6b a5  duplicate.k.
> backtrace:
>   [] kmemleak_alloc+0x4e/0xb0
>   [] __kmalloc_track_caller+0x2b1/0x390
>   [] kstrdup+0x31/0x60
>   [] kstrdup_const+0x23/0x30
>   [] kvasprintf_const+0x54/0x90
>   [] kobject_set_name_vargs+0x21/0xa0
>   [] kobject_set_name+0x4e/0x70
>   [] kset_create_and_add+0x45/0xa0
>   [...]
> 
> Similar problems exist at all call sites of kset_register(), that is
> in drivers/base, fs/ext4 and in fs/ocfs2.

Yes, but those calls all succeed, so this isn't a problem in the "real"
world :)

> The deeper cause behind this are the current semantics of the kset
> initialization, creation and registration functions which differ from the
> ones of their corresponding kobject counterparts.
> Namely,
> - there is no _exported_ kset initialization function,
> - the (not exported) kset_create() creates a halfway initialized kset
>   object,
> - and the kset_register() finishes a kset object's initialization but
>   expects its name to already have been set at its entry.
> 
> To fix this:
> - Export kset_init() and let it mimic the semantics of kobject_init().
>   Especially it takes and sets a kobj_type which makes the kset object
>   kset_put()able upon return.
> - Let the internal kset_create() do the complete initialization by means
>   of kset_init().
> - Remove any kset initialization from kset_register(): it expects a
>   readily initialized kset object now. Furthermore, let kset_register()
>   take and set the kset object's name. This resembles the behaviour of
>   kobject_add(). In analogy to the latter, require the caller to call
>   kset_put() or kset_unregister() unconditionally, even on failure.
> 
> At the call sites of kset_register():
> - Replace the open coded kset object initialization by a call to
>   kset_init().
> - Remove the explicit name setting and let the kset_register() call do
>   that work.
> - Replace any kfree()s by kset_put()s where appropriate.
> 
> Signed-off-by: Nicolai Stange 
> ---
> To the maintainers of ext4 and ocfs2: although several subsystems are
> touched, the changes come in one single patch in order to keep them 
> bisectable.
> 
> 
>  drivers/base/bus.c | 14 ++-
>  drivers/base/class.c   | 39 ++-
>  fs/ext4/sysfs.c| 13 +++
>  fs/ocfs2/cluster/masklog.c | 13 ---
>  include/linux/kobject.h|  6 ++-
>  lib/kobject.c  | 94 
> --
>  6 files changed, 110 insertions(+), 69 deletions(-)
> 
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 5005924..a81227c 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -900,15 +900,11 @@ int bus_register(struct bus_type *bus)
>  
>   BLOCKING_INIT_NOTIFIER_HEAD(&priv->bus_notifier);
>  
> - retval = kobject_set_name(&priv->subsys.kobj, "%s", bus->name);
> - if (retval)
> - goto out;
> -
> - priv->subsys.kobj.kset = bus_kset;
> - priv->subsys.kobj.ktype = &bus_ktype;
>   priv->drivers_autoprobe = 1;
>  
> - retval = kset_register(&priv->subsys);
> + kset_init(&priv->subsys, &bus_ktype, NULL);
> + priv->subsys.kobj.kset = bus_kset;
> + retval = kset_register(&priv->subsys, bus->name, NULL);
>   if (retval)
>   goto out;
>  
> @@ -955,10 +951,8 @@ bus_drivers_fail:
>  bus_devices_fail:
>   bus_remove_file(bus, &bus_attr_uevent);
>  bus_uevent_fail:
> - kset_unregister(&bus->p->subsys);
>  out:
> - kfree(bus->p);
> - bus->p = NULL;
> + kset_unregister(&bus->p->subsys);
>   return retval;
>  }
>  EXPORT_SYMBOL_GPL(bus_register);
> diff --git a/drivers/base/class.c b/drivers/base/class.c
> index 71059e3..94a5b040 100644
> --- a/drivers/base/class.c
> +++ b/drivers/base/class.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "base.h"
>  
>  #define to_class_attr(_attr) container_of(_attr, struct class_attribute, 
> attr)
> @@ -82,6 +83,24 @@ static struct kobj_type class_ktype = {
>   .child_ns_type  = class_child_ns_type,
>  };
>  
> +static void glue_dirs_release_dummy(struct kobject *kobj)
> +{
> + /*
> +  * The glue_dirs kset member of struct subsys_private is never
> +  * registered and thus, never unregistered.
> +  * This release function is a dummy to make kset_init() happy.
> +  */
> + pr_err(
> + "class (%p): unexpected kset_put() on glue_dirs, something is broken.",
> + 

Re: [RFC] block: change to use atomic_inc_return_release()

2015-11-16 Thread yalin wang

> On Nov 17, 2015, at 11:38, Jens Axboe  wrote:
> 
> On 11/16/2015 08:24 PM, yalin wang wrote:
>> Some arch define this atomic_inc_return_release() OP.
> 
> That is a very vague commit message, you'll need a whole lot more than 
> that... A commit message is supposed to describe the reason for the change. 
> You provide no reason for the change.
> 
>> diff --git a/block/bio.c b/block/bio.c
>> index fbc558b..b251857 100644
>> --- a/block/bio.c
>> +++ b/block/bio.c
>> @@ -310,8 +310,7 @@ static void bio_chain_endio(struct bio *bio, int error)
>>  static inline void bio_inc_remaining(struct bio *bio)
>>  {
>>  bio->bi_flags |= (1 << BIO_CHAIN);
>> -smp_mb__before_atomic();
>> -atomic_inc(&bio->__bi_remaining);
>> +atomic_inc_return_release(&bio->__bi_remaining);
> 
> Are these equivalent? Where's the documentation for this primitive? The 
> previous code ensured that we ordered the dec of the remaining count with the 
> update of the flags.
> 
i just have a look at ARM64 implementation for this new atomic OP ,
but i don’t find doc in memory-barrier.txt . so i make this RFC for some 
response,
atomic_inc_return_release()  should have store_release() class memory barriers .
in this example,  smp_store_release() memory barrier is not enough ?
just make sure bi_flags update can been seen by other cores before update 
atomic counter.
atomic_inc_return_{release,acquire,relax} OP seems newly add to kernel .
But i don’t see much users in code .
Can it be used to replace lots of smp_mb__before_atomic() ?

Thanks

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


[PATCH v4 0/4] crypto: add crypto accelerator support for rk3288

2015-11-16 Thread Zain Wang
This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc),
and the more algorithms and new hash drivers will be added later on.

Changed in v4:
- modify irq function
- add devm_add_action in probe
- fix some minor mistakes

Changed in v3:
- add OF depended in Kconfig
- rename some variate
- add reset property
- remove crypto_p variate

Changed in v2:
- remove some part about hash
- add weak key detection
- changed some variate's type

Changed in v1:
- modify some variate's name
- modify some variate's type
- modify some return value
- remove or modify some print info
- use more dev_xxx in probe
- modify the prio of cipher
- add Kconfig

Zain Wang (4):
  crypto: rockchip/crypto - add DT bindings documentation
  clk: rockchip: set an ID for crypto clk
  Crypto: rockchip/crypto - add crypto driver for rk3288
  ARM: dts: rockchip: Add Crypto node for rk3288

 .../devicetree/bindings/crypto/rockchip-crypto.txt |  29 ++
 arch/arm/boot/dts/rk3288.dtsi  |  12 +
 drivers/clk/rockchip/clk-rk3288.c  |   2 +-
 drivers/crypto/Kconfig |  11 +
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rockchip/Makefile   |   3 +
 drivers/crypto/rockchip/rk3288_crypto.c| 396 +
 drivers/crypto/rockchip/rk3288_crypto.h| 216 +
 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 489 +
 include/dt-bindings/clock/rk3288-cru.h |   1 +
 10 files changed, 1159 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
 create mode 100644 drivers/crypto/rockchip/Makefile
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c

-- 
1.9.1


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


[PATCH v4 2/4] clk: rockchip: set an ID for crypto clk

2015-11-16 Thread Zain Wang
Set an ID for crypto clk, so that it can be called in other part.

Signed-off-by: Zain Wang 
Acked-by: Michael Turquette 
Tested-by: Heiko Stuebner 
---
Changed in v4:
- None
Changed in v3:
- None
Changed in v2: 
- None
Changed in v1:
- define SCLK_CRYPTO in rk3288-cru.h
- use SCLK_CRYPTO instead of SRST_CRYPTO

 drivers/clk/rockchip/clk-rk3288.c  | 2 +-
 include/dt-bindings/clock/rk3288-cru.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..3fceda1 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
-   COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+   COMPOSITE_NOMUX(SCLK_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..30dcd60 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
 #define SCLK_USBPHY480M_SRC122
 #define SCLK_PVTM_CORE 123
 #define SCLK_PVTM_GPU  124
+#define SCLK_CRYPTO125
 
 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
1.9.1


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


[PATCH v4 3/4] Crypto: rockchip/crypto - add crypto driver for rk3288

2015-11-16 Thread Zain Wang
Crypto driver support:
 ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.

And other algorithms and platforms will be added later on.

Signed-off-by: Zain Wang 
Tested-by: Heiko Stuebner 
---
Changed in v4:
- modify irq function
- add devm_add_action in probe
- fix some minor mistakes

Changed in v3:
- add OF depended in Kconfig
- rename some variate
- add reset property
- remove crypto_p variate

Changed in v2:
- remove some part about hash
- add weak key detection
- changed some variate's type

Changed in v1:
- modify some variate's name
- modify some variate's type
- modify some return value
- remove or modify some print info
- use more dev_xxx in probe
- modify the prio of cipher
- add Kconfig

 drivers/crypto/Kconfig |  11 +
 drivers/crypto/Makefile|   1 +
 drivers/crypto/rockchip/Makefile   |   3 +
 drivers/crypto/rockchip/rk3288_crypto.c| 396 +
 drivers/crypto/rockchip/rk3288_crypto.h| 216 +
 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 489 +
 6 files changed, 1116 insertions(+)
 create mode 100644 drivers/crypto/rockchip/Makefile
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
 create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2569e04..e5451b6 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
  To compile this driver as a module, choose M here: the module
  will be called sun4i-ss.
 
+config CRYPTO_DEV_ROCKCHIP
+   tristate "Rockchip's Cryptographic Engine driver"
+   depends on OF && ARCH_ROCKCHIP
+   select CRYPTO_AES
+   select CRYPTO_DES
+   select CRYPTO_BLKCIPHER
+
+   help
+ This driver interfaces with the hardware crypto accelerator.
+ Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..713de9d 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
 obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
diff --git a/drivers/crypto/rockchip/Makefile b/drivers/crypto/rockchip/Makefile
new file mode 100644
index 000..7051c6c
--- /dev/null
+++ b/drivers/crypto/rockchip/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
+rk_crypto-objs := rk3288_crypto.o \
+ rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
b/drivers/crypto/rockchip/rk3288_crypto.c
new file mode 100644
index 000..3c79902
--- /dev/null
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -0,0 +1,396 @@
+/*
+ * Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int rk_crypto_enable_clk(struct rk_crypto_info *dev)
+{
+   int err;
+
+   err = clk_prepare_enable(dev->sclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock sclk\n",
+   __func__, __LINE__);
+   goto err_return;
+   }
+   err = clk_prepare_enable(dev->aclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock aclk\n",
+   __func__, __LINE__);
+   goto err_aclk;
+   }
+   err = clk_prepare_enable(dev->hclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock hclk\n",
+   __func__, __LINE__);
+   goto err_hclk;
+   }
+   err = clk_prepare_enable(dev->dmaclk);
+   if (err) {
+   dev_err(dev->dev, "[%s:%d], Couldn't enable clock dmaclk\n",
+   __func__, __LINE__);
+   goto err_dmaclk;
+   }
+   return err;
+err_dmaclk:
+   clk_disable_unprepare(dev->hclk);
+err_hclk:
+   clk_disable_unprepare(dev->aclk);
+err_aclk:
+   clk_disable_unprepare(dev->sclk);
+err_return:
+   return err;
+}
+
+static void rk_crypto_disable_clk(struct rk_crypto_info *dev)
+{
+   clk_disable_unprepare(dev->dmaclk);
+   clk_disable_unprepare(dev->hclk);
+   clk_disable_unprepare(dev->ac

[PATCH v4 4/4] ARM: dts: rockchip: Add Crypto node for rk3288

2015-11-16 Thread Zain Wang
Add Crypto node for rk3288 including crypto controller and dma clk.

Signed-off-by: Zain Wang 
Tested-by: Heiko Stuebner 
---
Changed in v4:
- None

Changed in v3:
- add reset property

Changed in v2:
- None

Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"

 arch/arm/boot/dts/rk3288.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..f0d1217 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -778,6 +778,18 @@
status = "disabled";
};
 
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,rk3288-crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
+   clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+   resets = <&cru SRST_CRYPTO>;
+   reset-names = "crypto-rst";
+   status = "okay";
+   };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
-- 
1.9.1


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


[PATCH v4 1/4] crypto: rockchip/crypto - add DT bindings documentation

2015-11-16 Thread Zain Wang
Add DT bindings documentation for the rk3288 crypto drivers.

Signed-off-by: Zain Wang 
Acked-by: Rob Herring 
Tested-by: Heiko Stuebner 

---
Changed in v4:
- None

Changed in v3:
- add reset property

Changed in v2:
- None

Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
- remove the description of status

 .../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt

diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt 
b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
new file mode 100644
index 000..096df34
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
@@ -0,0 +1,29 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: Should be "rockchip,rk3288-crypto"
+- reg: Base physical address of the engine and length of memory mapped
+   region
+- interrupts: Interrupt number
+- clocks: Reference to the clocks about crypto
+- clock-names: "aclk" used to clock data
+  "hclk" used to clock data
+  "sclk" used to clock crypto accelerator
+  "apb_pclk" used to clock dma
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names: Must include the name "crypto-rst".
+
+Examples:
+
+   crypto: cypto-controller@ff8a {
+   compatible = "rockchip,rk3288-crypto";
+   reg = <0xff8a 0x4000>;
+   interrupts = ;
+   clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>, <&cru ACLK_DMAC1>;
+   clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+   resets = <&cru SRST_CRYPTO>;
+   reset-names = "crypto-rst";
+   status = "okay";
+   };
-- 
1.9.1


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


  1   2   3   4   5   6   7   8   9   10   >