Re: [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it

[Wei Yang]

On Mon, Dec 08, 2014 at 11:20:59PM -0800, Yinghai Lu wrote:
>On Mon, Dec 8, 2014 at 6:26 PM, Wei Yang  wrote:
>> On Tue, Dec 09, 2014 at 11:11:19AM +1100, Gavin Shan wrote:
>>>
>>>I'm going to give it a spin and Richard, could you please apply Yinghai's
>>>patch to see if your SRIOV code can work properly?
>>>
>>
>> I did a quick test on my machine. This patch doesn't affect the MMIO
>> allocation on out platform, so SRIOV works fine.
>>
>> I will spend more time to read the patch to get more understanding about the
>> problem.
>
>Hi Marek,
>
>Can you boot following branch with "debug ignore_loglevel pci=realloc"
>on your setup?
>
>git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>for-pci-allocate-fit-3.18
>
>it has
>8f74af9: PCI, x86: Allocate mmio near end of free range
>1ff91c1: PCI: Don't allocate small resource in big free space.
>108b43b: resources: Add allocate_resource_fit()
>b6a22f0: resources: Make find_resource could return just fit resource
>cf50e16: resources: Split out __allocate_resource()
>
>on top the v3.18, and it will allocate resource in fit way.

Hi, Yinghai

Just spent some time to understand the problem and your patch.

Two comments to this patch:
1. realloc_head is not necessary here
2. In case we have two MEM BAR under a bus, one is MEM64|PREF and one is PREF,
after this patch, the MEM64 flag will be cleared, right? If so, this may fall
back to the same situation in bug 74151.

I am looking at the bugzilla and try to understand the root cause for this
allocation failure. Currently I don't get the reason. In my mind, the resource
will be sized in the non-pref bridge window. But seems not. I have asked more
info in the bugzilla, so that I could understand the problem. (Yeah, maybe I
am not that smart, if one of you would help me understand the problem, I am
happy to offer you a cup of coffee :-) )

Bjorin,

As you mentioned in another thread, "5b28541552ef is taking the wrong
approach". (http://www.spinics.net/lists/linux-pci/msg37374.html) Maybe I
don't catch it clearly. Put a 32bit prefetchable resource in a 32bit
non-prefetchable bridge window is a bad idea? But in my mind, if the bridge
prefetchable window is 64bit, we can't put a 32bit prefetchable resource in
it.

I am trying to catch up with the updates of the bug, if I missed something
just let me know.

>
>Thanks
>
>Yinghai

-- 
Richard Yang
Help you, Help me

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

[PATCH 3/3] mm: page_alloc: remove redundant set_freepage_migratetype() calls

[Weijie Yang]

The freepage_migratetype is a temporary cached value which represents
the free page's pageblock migratetype. Now we use it in two scenarios:

1. Use it as a cached value in page freeing path. This cached value
is temporary and non-100% update, which help us decide which pcp
freelist and buddy freelist the page should go rather than using
get_pfnblock_migratetype() to save some instructions.
When there is race between page isolation and free path, we need use
additional method to get a accurate value to put the free pages to
the correct freelist and get a precise free pages statistics.

2. Use it in page alloc path to update NR_FREE_CMA_PAGES statistics.

This patch aims at the scenario 1 and removes two redundant
set_freepage_migratetype() calls, which will make sense in the hot path.

Signed-off-by: Weijie Yang 
---
 mm/page_alloc.c |2 --
 1 file changed, 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 616a2c9..99af01a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -775,7 +775,6 @@ static void __free_pages_ok(struct page *page, unsigned int 
order)
migratetype = get_pfnblock_migratetype(page, pfn);
local_irq_save(flags);
__count_vm_events(PGFREE, 1 << order);
-   set_freepage_migratetype(page, migratetype);
free_one_page(page_zone(page), page, pfn, order, migratetype);
local_irq_restore(flags);
 }
@@ -1024,7 +1023,6 @@ int move_freepages(struct zone *zone,
order = page_order(page);
list_move(>lru,
  >free_area[order].free_list[migratetype]);
-   set_freepage_migratetype(page, migratetype);
page += 1 << order;
pages_moved += 1 << order;
}
-- 
1.7.10.4


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

[PATCH 2/3] mm: page_isolation: remove unnecessary freepage_migratetype check for unused page

[Weijie Yang]

when we test the pages in a range is free or not, there is a little
chance we encounter some page which is not in buddy but page_count is 0.
That means that page could be in the page-freeing path but not in the
buddy freelist, such as in pcplist or wait for the zone->lock which the
tester is holding.

Back to the freepage_migratetype, we use it for a cached value for decide
which free-list the page go when freeing page. If the pageblock is isolated
the page will go to free-list[MIGRATE_ISOLATE] even if the cached type is
not MIGRATE_ISOLATE, the commit ad53f92e(fix incorrect isolation behavior
by rechecking migratetype) patch series have ensure this.

So the freepage_migratetype check for page_count==0 page in
__test_page_isolated_in_pageblock() is meaningless.
This patch removes the unnecessary freepage_migratetype check.

Signed-off-by: Weijie Yang 
---
 mm/page_isolation.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 6e5174d..f7c9183 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -223,8 +223,7 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
unsigned long end_pfn,
page = pfn_to_page(pfn);
if (PageBuddy(page))
pfn += 1 << page_order(page);
-   else if (page_count(page) == 0 &&
-   get_freepage_migratetype(page) == MIGRATE_ISOLATE)
+   else if (page_count(page) == 0)
pfn += 1;
else if (skip_hwpoisoned_pages && PageHWPoison(page)) {
/*
-- 
1.7.10.4


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

Re: [regression] Boot crash with: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")

[Joonsoo Kim]

On Mon, Dec 08, 2014 at 11:56:40AM +0100, Ingo Molnar wrote:
> 
> * Joonsoo Kim  wrote:
> 
> > On Thu, Nov 27, 2014 at 02:05:56PM +0100, Ingo Molnar wrote:
> > > 
> > > Any replies to this regression after 10 days, or should I send a 
> > > revert patch?
> > 
> > Hello, Ingo.
> > 
> > I can reproduce your problem and find root cause.
> > If CONFIG_DEBUG_VIRTUAL is enabled, __pa() checks whether virtual
> > address is valid or not. Because high_memory is not direct mapped
> > address, error occurs. IMO, physical address of high_memory is
> > useful to check phycal address of highmem boundary so do following
> > workaround to avoid validation is reasonable. But, if there is
> > a better solution, please let me know. I think that Marek will be
> > better than me in this area.
> > 
> > Please check following change to fix your problem.
> > If you agree following change, I will send it to Andrew with
> > proper description.
> > 
> > Thanks.
> > 
> > --->8-
> > diff --git a/mm/cma.c b/mm/cma.c
> > index ee3c3e0..45cd0a6 100644
> > --- a/mm/cma.c
> > +++ b/mm/cma.c
> > @@ -227,7 +227,7 @@ int __init cma_declare_contiguous(phys_addr_t base,
> > bool fixed, struct cma **res_cma)
> >  {
> > phys_addr_t memblock_end = memblock_end_of_DRAM();
> > -   phys_addr_t highmem_start = __pa(high_memory);
> > +   phys_addr_t highmem_start = __pa_nodebug(high_memory);
> > int ret = 0;
> >  
> > pr_debug("%s(size %pa, base %pa, limit %pa alignment %pa)\n",
> 
> Looks like this patch solves my boot crash problem:
> 
>   Tested-by: Ingo Molnar 
> 
> I'll let you know if there's any problem left as I test it some 
> more. Consider the bug fixed!
> 

Hello, Andrew.

Could you manage this fix for above boot regression in x86?
Patch itself is so dirty, because __pa_nodebug() is implemented only
in x86. If someone knows better idea, please let me know.

Thanks.

--->8
>From 8d5de7c1acd6373e333c86058462c6046db8ca7d Mon Sep 17 00:00:00 2001
From: Joonsoo Kim 
Date: Tue, 9 Dec 2014 16:03:47 +0900
Subject: [PATCH] mm/CMA: fix boot regression due to physical address of
 high_memory

high_memory isn't direct mapped memory so retrieving it's physical
address isn't appropriate. But, it would be useful to check physical
address of highmem boundary so it's justfiable to get physical address
from it. In x86, there is a validation check if CONFIG_DEBUG_VIRTUAL
and it triggers following boot failure reported by Ingo.

...
BUG: Int 6: CR2 00f06f53
 EDI   (null)  ESI 0665b000  EBP c1ed7edc  EBX 4000
 ESP c1ed7ed8   ES 007b   DS 007b
 EDX c2022c18  ECX 37d34000  EAX   (null)
 vec 0006  err   (null)  EIP c102b62e   CS 0060  flg 00210013
...
Call Trace:
 [] dump_stack+0x41/0x52
 [] early_idt_handler+0x6b/0x6b
 [] ? __phys_addr+0x16/0x68
 [] cma_declare_contiguous+0x33/0x212
 [] dma_contiguous_reserve_area+0x31/0x4e
 [] dma_contiguous_reserve+0x11d/0x125
 [] ? setup_real_mode+0x98/0xa3
 [] setup_arch+0x7b5/0xb63
 [] start_kernel+0xb8/0x3e6
 [] i386_start_kernel+0x79/0x7d

To fix boot regression, this patch implements workaround to avoid
validation check in x86 when retrieving physical address of high_memory.
__pa_nodebug() used by this patch is implemented only in x86 so
there is no choice but to use dirty #ifdef.

Reported-by: Ingo Molnar 
Tested-by: Ingo Molnar 
Signed-off-by: Joonsoo Kim 
---
 mm/cma.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mm/cma.c b/mm/cma.c
index ee3c3e0..35c4787 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -227,9 +227,22 @@ int __init cma_declare_contiguous(phys_addr_t base,
bool fixed, struct cma **res_cma)
 {
phys_addr_t memblock_end = memblock_end_of_DRAM();
-   phys_addr_t highmem_start = __pa(high_memory);
+   phys_addr_t highmem_start;
int ret = 0;
 
+#ifdef CONFIG_X86
+   /*
+* high_memory isn't direct mapped memory so retrieving it's
+* physical address isn't appropriate. But, it would be useful
+* to check physical address of highmem boundary so it's
+* justfiable to get physical address from it. In x86, there is
+* a validation check for this case, so following workaround is
+* needed to avoid it.
+*/
+   highmem_start = __pa_nodebug(high_memory);
+#else
+   highmem_start = __pa(high_memory);
+#endif
pr_debug("%s(size %pa, base %pa, limit %pa alignment %pa)\n",
__func__, , , , );
 
-- 
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] input: edt-ft5x06: fixed a macro coding style issue

[Asaf Vertz]

On 12/09/2014 08:44 AM, Joe Perches wrote:
> On Tue, 2014-12-09 at 08:34 +0200, Asaf Vertz wrote:
>> Fixed a coding style error, macros with complex values should be
>> enclosed in parentheses.
>>  
>> -#define EDT_ATTR_CHECKSET(name, reg) \
>> +#define EDT_ATTR_CHECKSET(name, reg) { \
>>  if (pdata->name >= edt_ft5x06_attr_##name.limit_low &&  \
>>  pdata->name <= edt_ft5x06_attr_##name.limit_high)   \
>> -edt_ft5x06_register_write(tsdata, reg, pdata->name)
>> +edt_ft5x06_register_write(tsdata, reg, pdata->name);\
>> +}
> 
> Any time you see a naked if (foo) bar in a macro
> prefer to use a do while (0) like;
> 
> #define EDT_ATTR_CHECKSET(name, reg)  \
> do {  \
>   if (pdata->name >= edt_ft5x06_attr_##name.limit_low &&  \
>   pdata->name <= edt_ft5x06_attr_##name.limit_high)   \
>   edt_ft5x06_register_write(tsdata, reg, pdata->name);\
> while (0)
> 

thanks for the input, I will update and resend it

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

[PATCH 1/3] mm: page_isolation: remove redundant moving for isolated buddy pages

[Weijie Yang]

The commit ad53f92e(fix incorrect isolation behavior by rechecking migratetype)
patch series describe the race between page isolation and alloc/free path, and
fix the race.

Now, after the pageblock has been isolated, free buddy pages are already in
the free_list[MIGRATE_ISOLATE] and will not be allocated for usage. So the
current freepage_migratetype check is unnecessary and it will cause redundant
page move. That is to say, even if the buddy page's migratetype is not
MIGRATE_ISOLATE, the page is in free_list[MIGRATE_ISOLATE], we just move it
from free_list[MIGRATE_ISOLATE] to free_list[MIGRATE_ISOLATE].

This patch removes the unnecessary freepage_migratetype check and the
redundant page moving.

Signed-off-by: Weijie Yang 
---
 mm/page_isolation.c |   17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index c8778f7..6e5174d 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -221,23 +221,8 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
unsigned long end_pfn,
continue;
}
page = pfn_to_page(pfn);
-   if (PageBuddy(page)) {
-   /*
-* If race between isolatation and allocation happens,
-* some free pages could be in MIGRATE_MOVABLE list
-* although pageblock's migratation type of the page
-* is MIGRATE_ISOLATE. Catch it and move the page into
-* MIGRATE_ISOLATE list.
-*/
-   if (get_freepage_migratetype(page) != MIGRATE_ISOLATE) {
-   struct page *end_page;
-
-   end_page = page + (1 << page_order(page)) - 1;
-   move_freepages(page_zone(page), page, end_page,
-   MIGRATE_ISOLATE);
-   }
+   if (PageBuddy(page))
pfn += 1 << page_order(page);
-   }
else if (page_count(page) == 0 &&
get_freepage_migratetype(page) == MIGRATE_ISOLATE)
pfn += 1;
-- 
1.7.10.4


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

Re: [PATCH 12/19] clk: samsung: exynos5433: Add clocks for CMU_GSCL domain

[Pankaj Dubey]

Hi Chanwoo,

On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:

This patch adds the divider/gate of CMU_GSCL domain which contains gscaler
clocks.

Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Acked-by: Inki Dae 
Acked-by: Geunsik Lim 
---
  .../devicetree/bindings/clock/exynos5433-clock.txt |   8 ++
  drivers/clk/samsung/clk-exynos5433.c   | 144 +
  include/dt-bindings/clock/exynos5433.h |  37 +-
  3 files changed, 188 insertions(+), 1 deletion(-)



[snip]


  }
  CLK_OF_DECLARE(exynos5433_cmu_g3d, "samsung,exynos5433-cmu-g3d",
exynos5433_cmu_g3d_init);
+
+/*
+ * Register offset definitions for CMU_GSCL
+ */
+#define MUX_SEL_GSCL   0x0200
+#define MUX_ENABLE_GSCL0x0300
+#defineMUX_STAT_GSCL   0x0400
+#defineENABLE_ACLK_GSCL0x0800
+#defineENABLE_ACLK_GSCL_SECURE_SMMU_GSCL0  0x0804
+#defineENABLE_ACLK_GSCL_SECURE_SMMU_GSCL1  0x0808
+#defineENABLE_ACLK_GSCL_SECURE_SMMU_GSCL2  0x080c
+#defineENABLE_PCLK_GSCL0x0900
+#defineENABLE_PCLK_GSCL_SECURE_SMMU_GSCL0  0x0904
+#defineENABLE_PCLK_GSCL_SECURE_SMMU_GSCL1  0x0908
+#defineENABLE_PCLK_GSCL_SECURE_SMMU_GSCL2  0x090c
+#defineENABLE_IP_GSCL0 0x0b00
+#defineENABLE_IP_GSCL1 0x0b04
+#defineENABLE_IP_GSCL_SECURE_SMMU_GSCL00x0b08
+#defineENABLE_IP_GSCL_SECURE_SMMU_GSCL10x0b0c
+#defineENABLE_IP_GSCL_SECURE_SMMU_GSCL20x0b10
+


nit: tabspace after #define should be changed to one whitespace.


+static unsigned long gscl_clk_regs[] __initdata = {
+   MUX_SEL_GSCL,
+   MUX_ENABLE_GSCL,
+   MUX_STAT_GSCL,
+   ENABLE_ACLK_GSCL,
+   ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL0,
+   ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL1,
+   ENABLE_ACLK_GSCL_SECURE_SMMU_GSCL2,
+   ENABLE_PCLK_GSCL,
+   ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL0,
+   ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL1,
+   ENABLE_PCLK_GSCL_SECURE_SMMU_GSCL2,
+   ENABLE_IP_GSCL0,
+   ENABLE_IP_GSCL1,
+   ENABLE_IP_GSCL_SECURE_SMMU_GSCL0,
+   ENABLE_IP_GSCL_SECURE_SMMU_GSCL1,
+   ENABLE_IP_GSCL_SECURE_SMMU_GSCL2,
+};
+
+/* list of all parent clock list */
+PNAME(aclk_gscl_111_user_p)= { "fin_pll", "aclk_gscl_111", };
+PNAME(aclk_gscl_333_user_p)= { "fin_pll", "aclk_gscl_333", };
+
+static struct samsung_mux_clock gscl_mux_clks[] __initdata = {
+   /* MUX_SEL_GSCL */
+   MUX(CLK_MOUT_ACLK_GSCL_111_USER, "mout_aclk_gscl_111_user",
+   aclk_gscl_111_user_p, MUX_SEL_GSCL, 4, 1),
+   MUX(CLK_MOUT_ACLK_GSCL_333_USER, "mout_aclk_gscl_333_user",
+   aclk_gscl_333_user_p, MUX_SEL_GSCL, 4, 1),


aclk_gscl_333_user mux clock has a shift of '0'.


+};
+


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] mm: page_alloc: place zone id check before VM_BUG_ON_PAGE check

[Weijie Yang]

If the free page and its buddy has different zone id, the current
zone->lock cann't prevent buddy page getting allocated, this could
trigger VM_BUG_ON_PAGE in a very tiny chance:

cpu 0:  cpu 1:
hold zone_1 lock
check page and it buddy
PageBuddy(buddy) is truehold zone_2 lock
page_order(buddy) == order is true  alloc buddy
trigger VM_BUG_ON_PAGE(page_count(buddy) != 0)

This patch fixes this issue by placing the zone id check before
the VM_BUG_ON_PAGE check.

Signed-off-by: Weijie Yang 
---
 mm/page_alloc.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 616a2c9..491d055 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -488,17 +488,15 @@ static inline int page_is_buddy(struct page *page, struct 
page *buddy,
return 0;
 
if (page_is_guard(buddy) && page_order(buddy) == order) {
-   VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
-
if (page_zone_id(page) != page_zone_id(buddy))
return 0;
 
+   VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
+
return 1;
}
 
if (PageBuddy(buddy) && page_order(buddy) == order) {
-   VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
-
/*
 * zone check is done late to avoid uselessly
 * calculating zone/node ids for pages that could
@@ -507,6 +505,8 @@ static inline int page_is_buddy(struct page *page, struct 
page *buddy,
if (page_zone_id(page) != page_zone_id(buddy))
return 0;
 
+   VM_BUG_ON_PAGE(page_count(buddy) != 0, buddy);
+
return 1;
}
return 0;
-- 
1.7.10.4


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

[PATCHv2] arm64:mm: free the useless initial page table

[zhichang . yuan]

From: "zhichang.yuan" 

For 64K page system, after mapping a PMD section, the corresponding initial
page table is not needed any more. That page can be freed.

Changes since v1:

* make consistent code between alloc_init_pmd and alloc_init_pud;
* flush the TLB before the unused page table is freed;

Signed-off-by: Zhichang Yuan 
---
 arch/arm64/include/asm/pgtable.h |3 +++
 arch/arm64/mm/mmu.c  |   15 ---
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 41a43bf..8a135b6 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -337,9 +337,12 @@ extern pgprot_t phys_mem_access_prot(struct file *file, 
unsigned long pfn,
 
 #ifdef CONFIG_ARM64_64K_PAGES
 #define pud_sect(pud)  (0)
+#define pud_table(pud) (1)
 #else
 #define pud_sect(pud)  ((pud_val(pud) & PUD_TYPE_MASK) == \
 PUD_TYPE_SECT)
+#define pud_table(pud) ((pud_val(pud) & PUD_TYPE_MASK) == \
+   PUD_TYPE_TABLE)
 #endif
 
 static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index f4f8b50..515f75b 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -191,8 +191,14 @@ static void __init alloc_init_pmd(pud_t *pud, unsigned 
long addr,
 * Check for previous table entries created during
 * boot (__create_page_tables) and flush them.
 */
-   if (!pmd_none(old_pmd))
+   if (!pmd_none(old_pmd)) {
flush_tlb_all();
+   if (pmd_table(old_pmd)) {
+   phys_addr_t table = 
__pa(pte_offset_map(_pmd, 0));
+
+   memblock_free(table, PAGE_SIZE);
+   }
+   }
} else {
alloc_init_pte(pmd, addr, next, __phys_to_pfn(phys),
   prot_pte);
@@ -234,9 +240,12 @@ static void __init alloc_init_pud(pgd_t *pgd, unsigned 
long addr,
 * Look up the old pmd table and free it.
 */
if (!pud_none(old_pud)) {
-   phys_addr_t table = __pa(pmd_offset(_pud, 
0));
-   memblock_free(table, PAGE_SIZE);
flush_tlb_all();
+   if (pud_table(old_pud)) {
+   phys_addr_t table = 
__pa(pmd_offset(_pud, 0));
+
+   memblock_free(table, PAGE_SIZE);
+   }
}
} else {
alloc_init_pmd(pud, addr, next, phys, map_io);
-- 
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] PCI: Clear bridge MEM_64 flag if one child does not support it

[Yinghai Lu]

On Mon, Dec 8, 2014 at 6:26 PM, Wei Yang  wrote:
> On Tue, Dec 09, 2014 at 11:11:19AM +1100, Gavin Shan wrote:
>>
>>I'm going to give it a spin and Richard, could you please apply Yinghai's
>>patch to see if your SRIOV code can work properly?
>>
>
> I did a quick test on my machine. This patch doesn't affect the MMIO
> allocation on out platform, so SRIOV works fine.
>
> I will spend more time to read the patch to get more understanding about the
> problem.

Hi Marek,

Can you boot following branch with "debug ignore_loglevel pci=realloc"
on your setup?

git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-pci-allocate-fit-3.18

it has
8f74af9: PCI, x86: Allocate mmio near end of free range
1ff91c1: PCI: Don't allocate small resource in big free space.
108b43b: resources: Add allocate_resource_fit()
b6a22f0: resources: Make find_resource could return just fit resource
cf50e16: resources: Split out __allocate_resource()

on top the v3.18, and it will allocate resource in fit way.

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND 2/3] PM / devfreq: Add watermark simple governor

[Alexandre Courbot]

On Fri, Dec 5, 2014 at 10:41 PM, Arto Merilainen  wrote:
> From: Shridhar Rasal 
>
> This patch adds a new devfreq governor, watermark simple. The
> governor decides next frequency naively by selecting the previous
> frequency in the frequency table if we received low watermark
> - or the next frequency in case we received high watermark.
>
> Signed-off-by: Shridhar Rasal 
> Signed-off-by: Arto Merilainen 
> ---
>  drivers/devfreq/Kconfig |   7 +
>  drivers/devfreq/Makefile|   1 +
>  drivers/devfreq/governor_wmark_simple.c | 245 
> 
>  3 files changed, 253 insertions(+)
>  create mode 100644 drivers/devfreq/governor_wmark_simple.c
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index faf4e70c42e0..37710d999ffe 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -63,6 +63,13 @@ config DEVFREQ_GOV_USERSPACE
>   Otherwise, the governor does not change the frequnecy
>   given at the initialization.
>
> +config DEVFREQ_GOV_WMARK_SIMPLE
> +   tristate "Simple Watermark"
> +   help
> + Sets the frequency based on monitor watermark events.
> + This governor returns the next frequency from frequency table
> + based on type watermark event.
> +
>  comment "DEVFREQ Drivers"
>
>  config ARM_EXYNOS4_BUS_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 16138c9e0d58..92024eeb73b6 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)   += 
> governor_simpleondemand.o
>  obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE)  += governor_performance.o
>  obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o
>  obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
> +obj-$(CONFIG_DEVFREQ_GOV_WMARK_SIMPLE) += governor_wmark_simple.o
>
>  # DEVFREQ Drivers
>  obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)  += exynos/
> diff --git a/drivers/devfreq/governor_wmark_simple.c 
> b/drivers/devfreq/governor_wmark_simple.c
> new file mode 100644
> index ..bd14adcc84cb
> --- /dev/null
> +++ b/drivers/devfreq/governor_wmark_simple.c
> @@ -0,0 +1,245 @@
> +/*
> + * Copyright (c) 2014, NVIDIA CORPORATION.  All rights reserved.
> + *
> + * 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.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "governor.h"
> +
> +struct wmark_gov_info {
> +   /* probed from the devfreq */
> +   unsigned int*freqlist;
> +   int freq_count;
> +
> +   /* algorithm parameters */
> +   unsigned intp_high_wmark;
> +   unsigned intp_low_wmark;
> +
> +   /* dynamically changing data */
> +   enum watermark_type event;

I would rename this to last_event for clarity.

> +   unsigned intlast_request;

last_freq might be a more appropriate name here.

> +
> +   /* common data */
> +   struct devfreq  *df;

Unless I missed something this member is only set once in
devfreq_watermark_start() and never touched afterwards.

> +   struct platform_device  *pdev;

Same with this one.

> +   struct dentry   *debugdir;
> +};
> +
> +static unsigned long freqlist_up(struct wmark_gov_info *wmarkinfo,
> +unsigned long curr_freq)
> +{
> +   int i, pos;
> +
> +   for (i = 0; i < wmarkinfo->freq_count; i++)
> +   if (wmarkinfo->freqlist[i] > curr_freq)
> +   break;
> +
> +   pos = min(wmarkinfo->freq_count - 1, i);
> +
> +   return wmarkinfo->freqlist[pos];
> +}
> +
> +static unsigned int freqlist_down(struct wmark_gov_info *wmarkinfo,
> + unsigned long curr_freq)
> +{
> +   int i, pos;
> +
> +   for (i = wmarkinfo->freq_count - 1; i >= 0; i--)
> +   if (wmarkinfo->freqlist[i] < curr_freq)
> +   break;
> +
> +   pos = max(0, i);
> +   return wmarkinfo->freqlist[pos];
> +}
> +
> +static int devfreq_watermark_target_freq(struct devfreq *df,
> +unsigned long *freq)
> +{
> +   struct wmark_gov_info *wmarkinfo = df->data;
> +   struct devfreq_dev_status dev_stat;
> +   int err;
> +
> +   err = 

Re: [RFC RESEND 1/3] PM / devfreq: Add watermark events

[Alexandre Courbot]

On Fri, Dec 5, 2014 at 10:41 PM, Arto Merilainen  wrote:
> From: Shridhar Rasal 
>
> This patch adds support for watermark events. These events inform
> the governor that the device load has gone below (low watermark) or
> above (high watermark) certain load value.

This is definitely a useful feature to have, as it reflects what
efficient hardware does (raise an interrupt when load goes above/under
a certain threshold). In particular Tomeu's ACTMON driver would
probably greatly benefit from it.

A few comments below:

>
> Signed-off-by: Shridhar Rasal 
> Signed-off-by: Arto Merilainen 
> ---
>  drivers/devfreq/devfreq.c  | 19 +++
>  drivers/devfreq/governor.h |  1 +
>  include/linux/devfreq.h| 26 ++
>  3 files changed, 46 insertions(+)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 30b538d8cc90..8333d024132a 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -1050,6 +1050,25 @@ static struct attribute *devfreq_attrs[] = {
>  };
>  ATTRIBUTE_GROUPS(devfreq);
>
> +/**
> + * devfreq_watermark_event() - Handles watermark events
> + * @devfreq: the devfreq instance to be updated
> + * @type: type of watermark event
> + */
> +int devfreq_watermark_event(struct devfreq *devfreq, int type)

Here I suppose "type" is to be an enum watermark_type - therefore it
should probably be changed to that type instead of int.

> +{
> +   if (!devfreq)
> +   return -EINVAL;
> +
> +   if (!devfreq->governor)
> +   return -EINVAL;

Let's fold these two conditions into "if (!devfreq || !devfreq->governor)"

> +
> +   return devfreq->governor->event_handler(devfreq,
> +   DEVFREQ_GOV_WMARK, );
> +}
> +EXPORT_SYMBOL(devfreq_watermark_event);
> +
> +

Extra whiteline here.

>  static int __init devfreq_init(void)
>  {
> devfreq_class = class_create(THIS_MODULE, "devfreq");
> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
> index fad7d6321978..fb9875388f3f 100644
> --- a/drivers/devfreq/governor.h
> +++ b/drivers/devfreq/governor.h
> @@ -24,6 +24,7 @@
>  #define DEVFREQ_GOV_INTERVAL   0x3
>  #define DEVFREQ_GOV_SUSPEND0x4
>  #define DEVFREQ_GOV_RESUME 0x5
> +#define DEVFREQ_GOV_WMARK  0x6
>
>  /* Caution: devfreq->lock must be locked before calling update_devfreq */
>  extern int update_devfreq(struct devfreq *devfreq);
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index f1863dcd83ea..b5bf6c4fe286 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -21,6 +21,12 @@
>
>  struct devfreq;
>
> +enum watermark_type {

Change the name to devfreq_watermark_event maybe? We know it's a type
already from the context, and we should use the devfreq_ prefix to
avoid name collisions.

> +   NO_WATERMARK_EVENT = 0,
> +   HIGH_WATERMARK_EVENT = 1,
> +   LOW_WATERMARK_EVENT = 2

... and if the type is renamed to watermark_event, these could become
DEVFREQ_NO_WATERMARK, DEVFREQ_HIGH_WATERMARK, and
DEVFREQ_LOW_WATERMARK.

> +};
> +
>  /**
>   * struct devfreq_dev_status - Data given from devfreq user device to
>   *  governors. Represents the performance
> @@ -68,6 +74,16 @@ struct devfreq_dev_status {
>   * status to devfreq, which is used by governors.
>   * @get_cur_freq:  The device should provide the current frequency
>   * at which it is operating.
> + * @set_high_wmark:This is an optional callback to set high
> + * watermark for watermark event. The value is
> + * be scaled between 0 and 1000 where 1000 equals to
> + * 100% load. Setting this value to 1000 disables
> + * the event
> + * @set_low_wmark: This is an optional callback to set low
> + * watermark for watermark event. The value is
> + * be scaled between 0 and 1000 where 1000 equals to
> + * 100% load. Setting this value to 0 disables the
> + * event.

>From the comment it is not clear whether the 0..1000 range corresponds
to the load between two frequencies in the frequencies table, or
covers the whole frequency table. I understand it is the former, but
it would be nice to explicitly state it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: tegra: Define PLLD_DSI and remove dsia(b)_mux

[Mark Zhang]

PLLD is the only parent for DSIA & DSIB on Tegra124 and
Tegra132. Besides, BIT 30 in PLLD_MISC register controls
the output of DSI clock.

So this patch removes "dsia_mux" & "dsib_mux", and create
a new clock "plld_dsi" to represent the DSI clock enable
control.

Signed-off-by: Peter De Schrijver 
Signed-off-by: Mark Zhang 
---
 drivers/clk/tegra/clk-id.h   |  2 --
 drivers/clk/tegra/clk-tegra-periph.c |  2 --
 drivers/clk/tegra/clk-tegra114.c | 10 +++--
 drivers/clk/tegra/clk-tegra124.c | 36 ++--
 include/dt-bindings/clock/tegra124-car.h |  6 +++---
 5 files changed, 27 insertions(+), 29 deletions(-)

diff --git a/drivers/clk/tegra/clk-id.h b/drivers/clk/tegra/clk-id.h
index 0011d547a9f7..60738cc954cb 100644
--- a/drivers/clk/tegra/clk-id.h
+++ b/drivers/clk/tegra/clk-id.h
@@ -64,10 +64,8 @@ enum clk_id {
tegra_clk_disp2,
tegra_clk_dp2,
tegra_clk_dpaux,
-   tegra_clk_dsia,
tegra_clk_dsialp,
tegra_clk_dsia_mux,
-   tegra_clk_dsib,
tegra_clk_dsiblp,
tegra_clk_dsib_mux,
tegra_clk_dtv,
diff --git a/drivers/clk/tegra/clk-tegra-periph.c 
b/drivers/clk/tegra/clk-tegra-periph.c
index 37f32c49674e..1d0acbce6dc6 100644
--- a/drivers/clk/tegra/clk-tegra-periph.c
+++ b/drivers/clk/tegra/clk-tegra-periph.c
@@ -537,8 +537,6 @@ static struct tegra_periph_init_data gate_clks[] = {
GATE("xusb_host", "xusb_host_src", 89, 0, tegra_clk_xusb_host, 0),
GATE("xusb_ss", "xusb_ss_src", 156, 0, tegra_clk_xusb_ss, 0),
GATE("xusb_dev", "xusb_dev_src", 95, 0, tegra_clk_xusb_dev, 0),
-   GATE("dsia", "dsia_mux", 48, 0, tegra_clk_dsia, 0),
-   GATE("dsib", "dsib_mux", 82, 0, tegra_clk_dsib, 0),
GATE("emc", "emc_mux", 57, 0, tegra_clk_emc, CLK_IGNORE_UNUSED),
GATE("sata_cold", "clk_m", 129, TEGRA_PERIPH_ON_APB, 
tegra_clk_sata_cold, 0),
GATE("ispb", "clk_m", 3, 0, tegra_clk_ispb, 0),
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 0b03d2cf7264..d0766423a5d6 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -715,7 +715,6 @@ static struct tegra_clk tegra114_clks[tegra_clk_max] 
__initdata = {
[tegra_clk_sbc2_8] = { .dt_id = TEGRA114_CLK_SBC2, .present = true },
[tegra_clk_sbc3_8] = { .dt_id = TEGRA114_CLK_SBC3, .present = true },
[tegra_clk_i2c5] = { .dt_id = TEGRA114_CLK_I2C5, .present = true },
-   [tegra_clk_dsia] = { .dt_id = TEGRA114_CLK_DSIA, .present = true },
[tegra_clk_mipi] = { .dt_id = TEGRA114_CLK_MIPI, .present = true },
[tegra_clk_hdmi] = { .dt_id = TEGRA114_CLK_HDMI, .present = true },
[tegra_clk_csi] = { .dt_id = TEGRA114_CLK_CSI, .present = true },
@@ -739,7 +738,6 @@ static struct tegra_clk tegra114_clks[tegra_clk_max] 
__initdata = {
[tegra_clk_dtv] = { .dt_id = TEGRA114_CLK_DTV, .present = true },
[tegra_clk_ndspeed] = { .dt_id = TEGRA114_CLK_NDSPEED, .present = true 
},
[tegra_clk_i2cslow] = { .dt_id = TEGRA114_CLK_I2CSLOW, .present = true 
},
-   [tegra_clk_dsib] = { .dt_id = TEGRA114_CLK_DSIB, .present = true },
[tegra_clk_tsec] = { .dt_id = TEGRA114_CLK_TSEC, .present = true },
[tegra_clk_xusb_host] = { .dt_id = TEGRA114_CLK_XUSB_HOST, .present = 
true },
[tegra_clk_msenc] = { .dt_id = TEGRA114_CLK_MSENC, .present = true },
@@ -1224,6 +1222,14 @@ static __init void tegra114_periph_clk_init(void __iomem 
*clk_base,
   clk_base + PLLD2_BASE, 25, 1, 0, _d2_lock);
clks[TEGRA114_CLK_DSIB_MUX] = clk;
 
+   clk = tegra_clk_register_periph_gate("dsia", "dsia_mux", 0, clk_base,
+0, 48, periph_clk_enb_refcnt);
+   clks[TEGRA114_CLK_DSIA] = clk;
+
+   clk = tegra_clk_register_periph_gate("dsib", "dsib_mux", 0, clk_base,
+0, 82, periph_clk_enb_refcnt);
+   clks[TEGRA114_CLK_DSIB] = clk;
+
/* emc mux */
clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
   ARRAY_SIZE(mux_pllmcp_clkm),
diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index f5f9baca7bb6..482086326f6f 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -128,7 +128,6 @@ static unsigned long osc_freq;
 static unsigned long pll_ref_freq;
 
 static DEFINE_SPINLOCK(pll_d_lock);
-static DEFINE_SPINLOCK(pll_d2_lock);
 static DEFINE_SPINLOCK(pll_e_lock);
 static DEFINE_SPINLOCK(pll_re_lock);
 static DEFINE_SPINLOCK(pll_u_lock);
@@ -145,11 +144,6 @@ static unsigned long tegra124_input_freq[] = {
[12] = 26000,
 };
 
-static const char *mux_plld_out0_plld2_out0[] = {
-   "pll_d_out0", "pll_d2_out0",
-};
-#define mux_plld_out0_plld2_out0_idx NULL
-
 static const char *mux_pllmcp_clkm[] = {
"pll_m", "pll_c", "pll_p", "clk_m", 

Re: [RESEND][PATCH v15 7/7] ARM: kprobes: enable OPTPROBES for ARM 32

[Masami Hiramatsu]

(2014/12/08 23:09), Wang Nan wrote:
> This patch introduce kprobeopt for ARM 32.
> 
> Limitations:
>  - Currently only kernel compiled with ARM ISA is supported.
> 
>  - Offset between probe point and optinsn slot must not larger than
>32MiB. Masami Hiramatsu suggests replacing 2 words, it will make
>things complex. Futher patch can make such optimization.
> 
> Kprobe opt on ARM is relatively simpler than kprobe opt on x86 because
> ARM instruction is always 4 bytes aligned and 4 bytes long. This patch
> replace probed instruction by a 'b', branch to trampoline code and then
> calls optimized_callback(). optimized_callback() calls opt_pre_handler()
> to execute kprobe handler. It also emulate/simulate replaced instruction.
> 
> When unregistering kprobe, the deferred manner of unoptimizer may leave
> branch instruction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
> 
> Signed-off-by: Wang Nan 
> Acked-by: Masami Hiramatsu 
> Cc: Jon Medhurst (Tixy) 
> Cc: Russell King - ARM Linux 
> Cc: Will Deacon 
> ---
> v1 -> v2:
>  - Improvement: if replaced instruction is conditional, generate a
>conditional branch instruction for it;
>  - Introduces RELATIVEJUMP_OPCODES due to ARM kprobe_opcode_t is 4
>bytes;
>  - Removes size field in struct arch_optimized_insn;
>  - Use arm_gen_branch() to generate branch instruction;
>  - Remove all recover logic: ARM doesn't use tail buffer, no need
>recover replaced instructions like x86;
>  - Remove incorrect CONFIG_THUMB checking;
>  - can_optimize() always returns true if address is well aligned;
>  - Improve optimized_callback: using opt_pre_handler();
>  - Bugfix: correct range checking code and improve comments;
>  - Fix commit message.
> 
> v2 -> v3:
>  - Rename RELATIVEJUMP_OPCODES to MAX_COPIED_INSNS;
>  - Remove unneeded checking:
>   arch_check_optimized_kprobe(), can_optimize();
>  - Add missing flush_icache_range() in arch_prepare_optimized_kprobe();
>  - Remove unneeded 'return;'.
> 
> v3 -> v4:
>  - Use __mem_to_opcode_arm() to translate copied_insn to ensure it
>works in big endian kernel;
>  - Replace 'nop' placeholder in trampoline code template with
>'.long 0' to avoid confusion: reader may regard 'nop' as an
>instruction, but it is value in fact.
> 
> v4 -> v5:
>  - Don't optimize stack store operations.
>  - Introduce prepared field to arch_optimized_insn to indicate whether
>it is prepared. Similar to size field with x86. See v1 -> v2.
> 
> v5 -> v6:
>  - Dynamically reserve stack according to instruction.
>  - Rename: kprobes-opt.c -> kprobes-opt-arm.c.
>  - Set op->optinsn.insn after all works are done.
> 
> v6 -> v7:
>   - Using checker to check stack consumption.
> 
> v7 -> v8:
>   - Small code adjustments.
> 
> v8 -> v9:
>   - Utilize original kprobe passed to arch_prepare_optimized_kprobe()
> to avoid copy ainsn twice.
>   - A bug in arch_prepare_optimized_kprobe() is found and fixed.
> 
> v9 -> v10:
>   - Commit message improvements.
> 
> v10 -> v11:
>   - Move to arch/arm/probes/, insn.h is moved to arch/arm/include/asm.
>   - Code cleanup.
>   - Bugfix based on Tixy's test result:
> - Trampoline deal with ARM -> Thumb transision instructions and
>   AEABI stack alignment requirement correctly.
> - Trampoline code buffer should start at 4 byte aligned address.
>   We enforces it in this series by using macro to wrap 'code' var.
> 
> v11 -> v12:
>   - Remove trampoline code stack trick and use r4 to save original
> stack.
>   - Remove trampoline code buffer alignment trick.
>   - Names of files are changed.
> 
> v12 -> v13:
>   - Assume stack always aligned by 4-bytes in any case.
>   - Comments update.
> 
> v13 -> v14:
>   - Use stop_machine to wrap arch_optimize_kprobes to avoid a racing.
> 
> v14 -> v15:
>   - In v14, stop_machine() wraps a coarse-grained piece of code which
> makes things complex than it should be. In this version,
> kprobes_remove_breakpoint() is extracted, core.c and opt-arm.c use it
> to replace breakpoint to valid instruction. stop_machine() used inside
> in kprobes_remove_breakpoint().
> ---
>  arch/arm/Kconfig|   1 +
>  arch/arm/{kernel => include/asm}/insn.h |   0
>  arch/arm/include/asm/kprobes.h  |  29 +++
>  arch/arm/kernel/Makefile|   2 +-
>  arch/arm/kernel/ftrace.c|   3 +-
>  arch/arm/kernel/jump_label.c|   3 +-
>  arch/arm/probes/kprobes/Makefile|   1 +
>  arch/arm/probes/kprobes/core.c  |  26 ++-
>  arch/arm/probes/kprobes/core.h  |   2 +
>  arch/arm/probes/kprobes/opt-arm.c   | 317 
> 
>  10 files changed, 372 insertions(+), 12 deletions(-)
>  rename arch/arm/{kernel => include/asm}/insn.h (100%)
>  create 

Re: [PATCH] input: edt-ft5x06: fixed a macro coding style issue

[Joe Perches]

On Tue, 2014-12-09 at 08:34 +0200, Asaf Vertz wrote:
> Fixed a coding style error, macros with complex values should be
> enclosed in parentheses.
[]
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> b/drivers/input/touchscreen/edt-ft5x06.c
[]
> @@ -849,10 +849,11 @@ static int edt_ft5x06_ts_identify(struct i2c_client 
> *client,
>   return 0;
>  }
>  
> -#define EDT_ATTR_CHECKSET(name, reg) \
> +#define EDT_ATTR_CHECKSET(name, reg) { \
>   if (pdata->name >= edt_ft5x06_attr_##name.limit_low &&  \
>   pdata->name <= edt_ft5x06_attr_##name.limit_high)   \
> - edt_ft5x06_register_write(tsdata, reg, pdata->name)
> + edt_ft5x06_register_write(tsdata, reg, pdata->name);\
> +}

Any time you see a naked if (foo) bar in a macro
prefer to use a do while (0) like;

#define EDT_ATTR_CHECKSET(name, reg)\
do {\
if (pdata->name >= edt_ft5x06_attr_##name.limit_low &&  \
pdata->name <= edt_ft5x06_attr_##name.limit_high)   \
edt_ft5x06_register_write(tsdata, reg, pdata->name);\
while (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] dmaengine: rcar-dmac: Handle hardware descriptor allocation failure

[Vinod Koul]

On Mon, Dec 08, 2014 at 11:20:44PM +0530, Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> > > > [GIT PULL FOR v3.19] R-Car DMA engine driver
> > > > http://www.spinics.net/lists/linux-sh/msg37764.html
> > > 
> > > And I dont seem to have this request in my Inbox :(
> > > Yes I do see it in archieves, so not sure how this is not present, not 
> > > sure
> > > if the servers mangeled it!!
> > 
> > I haven't CC'ed you, I'll make sure to do so next time. The mail should 
> > still 
> > have reached you through the mailing list though (I assume you're 
> > subscribed 
> > to dmaeng...@vger.kernel.org ;-)).
> Yes I am, so should have reached me even though i wasnt cced
> I do see email reaching me from list without me being in CC, but then it
> wont hit my inbox and go to ML folder :)
> So generally its a good practice to CC relvant folks, lots of folks do ask
> that if ML is high volume

Hey Laurent,

I see that the oddity in commitlogs with change since artifacts after SOB,
can you please fix that up

commit 43dc9ba2b51ccb9124bf6fed614c5053500592a6
Author: Laurent Pinchart 
Date:   Sat Jul 19 00:05:14 2014 +0200

dmaengine: rcar-dmac: Cache hardware descriptors memory

Unlike DMA transfers descriptors that are preallocated and cached,
memory used to store hardware descriptors is allocated and freed 
with
the DMA coherent allocation API for every transfer. Besides 
degrading
performances, this creates a CMA stress test that seems to cause 
issues.
Running dmatest with the noverify option produces

[   50.066539] alloc_contig_range test_pages_isolated(6b845, 6b846) 
failed
[   50.235180] alloc_contig_range test_pages_isolated(6b848, 6b84e) 
failed
[   52.964584] alloc_contig_range test_pages_isolated(6b847, 6b848) 
failed
[   54.127113] alloc_contig_range test_pages_isolated(6b843, 6b844) 
failed
[   56.270253] alloc_contig_range test_pages_isolated(6b84c, 6b850) 
failed

The root cause needs to be fixed, but in the meantime, as a 
workaround
and a performance improvement, cache hardware descriptors.

Signed-off-by: Laurent Pinchart 

Tested-by: Wolfram Sang 

---

Changes since v2:

- Typo fixes
- Align allocated hwdesc size to page size
- Ignore allocated hwdesc memory when the transfer doesn't use 
hwdescs

commit feb2e9f12b1a4a871b1d3eb2e2f44255510a79d3
Author: Laurent Pinchart 
Date:   Wed Jul 16 23:15:48 2014 +0200

dmaengine: rcar-dmac: Implement support for hardware descriptor 
lists

The DMAC supports hardware-based auto-configuration from descriptor
lists. This reduces the number of interrupts required for 
processing a
DMA transfer. Support that mode in the driver.

Signed-off-by: Laurent Pinchart 

Tested-by: Wolfram Sang 

---

Changes since v2:

- Typo fixes
- Use GFP_NOWAIT to allocate hardware descriptors
- Clear descriptor stage end interrupt when halting the channel

and many more...

Thanks
-- 
~Vinod

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

[PATCH V3] fix build error for vm tools

[Wang, Yalin]

This patch fix the build error when make like this:
make O=/xx/x vm

use $(OUTPUT) to generate to the right place.

Signed-off-by: Yalin Wang 
---
 tools/lib/api/Makefile |  2 +-
 tools/vm/Makefile  | 14 +-
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/tools/lib/api/Makefile b/tools/lib/api/Makefile
index 36c08b1..a1c598d 100644
--- a/tools/lib/api/Makefile
+++ b/tools/lib/api/Makefile
@@ -44,6 +44,6 @@ $(OUTPUT)%.o: %.S libapi_dirs
$(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) $<
 
 clean:
-   $(call QUIET_CLEAN, libapi) $(RM) $(LIB_OBJS) $(LIBFILE)
+   $(call QUIET_CLEAN, libapi) $(RM) $(LIB_OBJS) $(OUTPUT)$(LIBFILE)
 
 .PHONY: clean
diff --git a/tools/vm/Makefile b/tools/vm/Makefile
index 3d907da..7e3fc9f 100644
--- a/tools/vm/Makefile
+++ b/tools/vm/Makefile
@@ -1,22 +1,26 @@
 # Makefile for vm tools
 #
+include ../scripts/Makefile.include
 TARGETS=page-types slabinfo
 
 LIB_DIR = ../lib/api
-LIBS = $(LIB_DIR)/libapikfs.a
+LIBS = $(OUTPUT)../lib/api/libapikfs.a
 
 CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall -Wextra -I../lib/
 LDFLAGS = $(LIBS)
 
+all: $(TARGETS)
 $(TARGETS): $(LIBS)
 
 $(LIBS):
-   make -C $(LIB_DIR)
+   $(call descend,../lib/api libapikfs.a)
 
 %: %.c
-   $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS)
+   $(CC) $(CFLAGS) -o $(OUTPUT)$@ $< $(LDFLAGS)
 
 clean:
-   $(RM) page-types slabinfo
-   make -C $(LIB_DIR) clean
+   $(RM) $(OUTPUT)page-types $(OUTPUT)slabinfo
+   $(call descend,../lib/api clean)
+
+.PHONY: all clean
-- 
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] input: edt-ft5x06: fixed a macro coding style issue

[Asaf Vertz]

Fixed a coding style error, macros with complex values should be
enclosed in parentheses.

Signed-off-by: Asaf Vertz 
---
 drivers/input/touchscreen/edt-ft5x06.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
b/drivers/input/touchscreen/edt-ft5x06.c
index ee3434f..6db9253 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -849,10 +849,11 @@ static int edt_ft5x06_ts_identify(struct i2c_client 
*client,
return 0;
 }
 
-#define EDT_ATTR_CHECKSET(name, reg) \
+#define EDT_ATTR_CHECKSET(name, reg) { \
if (pdata->name >= edt_ft5x06_attr_##name.limit_low &&  \
pdata->name <= edt_ft5x06_attr_##name.limit_high)   \
-   edt_ft5x06_register_write(tsdata, reg, pdata->name)
+   edt_ft5x06_register_write(tsdata, reg, pdata->name);\
+}
 
 #define EDT_GET_PROP(name, reg) {  \
u32 val;\
-- 
1.7.0.4

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

Re: [PATCH v5 5/6] Documentation: dt-bindings: Add binding info for X-Gene QMTM UIO driver

[Ankit Jindal]

On 8 December 2014 at 22:45, Rob Herring  wrote:
> On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal  wrote:
>> On 18 November 2014 at 18:40, Arnd Bergmann  wrote:
>>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
 On 17 November 2014 16:47, Arnd Bergmann  wrote:
 > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
 >> +
 >> +   qmtm1_uio: qmtm_uio@1f20 {
 >> +   compatible = "apm,xgene-qmtm";
 >> +   status = "disabled";
 >> +   reg = <0x0 0x1f20 0x0 0x1>,
 >> + <0x0 0x1b00 0x0 0x40>;
 >> +   reg-names = "csr", "fabric";
 >> +   qpool-memory = <_uio_qpool>;
 >> +   clocks = < 0>;
 >> +   num-queues = <0x400>;
 >> +   devid = <1>;
 >> +   };
 >> +
 >
 > To make my previous review comments clearer:
 >
 > NAK
 >
 > Do not create device nodes that are meant for a specific use case in
 > software and that are not usable for the common case. I don't think
 > it makes any sense to keep on submitting a UIO driver for this until
 > we have a proper network driver that uses this so we can make sure we
 > have a working binding.
>
> +1
>
 The dataplane frameworks like OpenDataPlane etc, need to have access
 to complete subsystem from the user space. Hence, we would like to
 have this driver and some other UIO drivers to be the part of kernel
 to have data plane frameworks working on our platform.
>>>
>>> Please work with the people that do the in-kernel QMTM driver to come
>>> up with a common binding then.
>> Thanks Arnd, I have synced with them, and in future our dt bindings
>> for this device is going to be inline with the one mentioned in the
>> patchset.
>
> What does "in the future" mean? Is there already a QMTM binding? If
> so, you need to figure out how to either align with it or deprecate
> it. This patch at a minimum needs to be fixed to not refer to UIO.

There is no QMTM dt binding as of now, and the kernel QMTM driver will
also use the same dt binding.
I will remove all references to the UIO from this patch, and move this
binding under the misc folder.

>
> Rob

Thanks,
Ankit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: arch_timer: Fix code to use physical timers when requested

[Yingjoe Chen]

On Mon, 2014-12-08 at 16:21 +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 10:41:04AM +, Yingjoe Chen wrote:
> > On Sun, 2014-11-23 at 23:02 -0800, Sonny Rao wrote: 
> > > This is a bug fix for using physical arch timers when
> > > the arch_timer_use_virtual boolean is false.  It restores the
> > > arch_counter_get_cntpct() function after removal in
> > > 
> > > 0d651e4e "clocksource: arch_timer: use virtual counters"
> > > 
> > > We need this on certain ARMv7 systems which are architected like this:
> > > diff --git a/arch/arm64/include/asm/arch_timer.h 
> > > b/arch/arm64/include/asm/arch_timer.h
> > > index f190971..b1fa4e6 100644
> > > --- a/arch/arm64/include/asm/arch_timer.h
> > > +++ b/arch/arm64/include/asm/arch_timer.h
> > > @@ -104,6 +104,15 @@ static inline void arch_timer_set_cntkctl(u32 
> > > cntkctl)
> > >   asm volatile("msr   cntkctl_el1, %0" : : "r" (cntkctl));
> > >  }
> > >  
> > > +static inline u64 arch_counter_get_cntpct(void)
> > > +{
> > > + /*
> > > +  * AArch64 kernel and user space mandate the use of CNTVCT.
> > > +  */
> > > + BUG();
> > > + return 0;
> > > +}
> > > +
> > >  static inline u64 arch_counter_get_cntvct(void)
> > >  {
> > >   u64 cval;
> > 
> > I tested this on an arm64 platform and system fail to boot when apply
> > this patch.
> > 
> > The boot loader start kernel at EL2, so is_hyp_mode_available() will be
> > true and we will use physical timer. Without this patch,
> > arch_timer_read_counter set to arch_counter_get_cntvct even when we use
> > physical timer which is incorrect but at least system will boot.
> 
> So on arm64 we want to use CNTVCT all the time, even if we start the
> kernel at EL2. This is the counter that gets exposed to user via vdso.
> When the kernel boots at EL2, we initialise CNTVOFF to 0, so we know
> that CNTVCT == CNTPCT. However, I would still prefer to use CNTVCT even
> in such case to spot possible firmware issues with not restoring CNTVOFF
> when coming out of suspend (one particular case of suspend which does
> not require a different kernel entry point).
> 
> > I think we still need this function on arm64. We should add BUG() to
> > arch_timer_init instead, maybe something like this:
> > 
> > @@ -708,9 +708,12 @@ static void __init arch_timer_init(struct device_node 
> > *np)
> >  * If we cannot rely on firmware initializing the timer registers then
> >  * we should use the physical timers instead.
> >  */
> > -   if (IS_ENABLED(CONFIG_ARM) &&
> > -   of_property_read_bool(np, "arm,cpu-registers-not-fw-configured"))
> > +   if (of_property_read_bool(np, "arm,cpu-registers-not-fw-configured")) {
> > +   if (IS_ENABLED(CONFIG_ARM64))
> > +   BUG();
> > +   else
> > arch_timer_use_virtual = false;
> > +   }
> 
> We could be more tolerant (give people a chance to check their DT):
> 
>   if (!WARN_ON(IS_ENABLED(CONFIG_ARM64)))
>   arch_timer_use_virtual = false;
> 
> In addition, we can define arch_counter_get_cntpct to always read CNTVCT
> (not that nice but maybe it looks better with a comment):
> 
> /*
>  * AArch64 kernel and user space mandate the use of CNTVCT.
>  */
> #define arch_counter_get_cntpct   arch_counter_get_cntvct
> 
> (or any better suggestion to avoid reading CNTPCT on arm64)
> 

I'm not sure about this. arch_timer_use_virtual is false, indicate we
are using physical timer, the function name suggest it will read
physical timer, but actually it is reading virtual timer. It sure will
create confusion when one need to debug.

We are using physical timer because arch_timer_init() will check
is_hyp_mode_available(), and use physical timer if it is avaliable. For
arm64, if we want to use virtual timer even in HYP mode, how about this
change:

@@ -720,7 +723,8 @@ static void __init arch_timer_init(struct device_node *np)
 * If no interrupt provided for virtual timer, we'll have to
 * stick to the physical timer. It'd better be accessible...
 */
-   if (is_hyp_mode_available() || !arch_timer_ppi[VIRT_PPI]) {
+   if ((IS_ENABLED(CONFIG_ARM) && is_hyp_mode_available()) ||
+   !arch_timer_ppi[VIRT_PPI]) {
arch_timer_use_virtual = false;

if (!arch_timer_ppi[PHYS_SECURE_PPI] ||

Maybe also add some WARN_ON for arm64 here to make sure we never set
arch_timer_use_virtual to false for ARM64.

Joe.C


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/19] clk: samsung: exynos5433: Add clocks for CMU_PERIC domain

[Chanwoo Choi]

On 12/09/2014 03:13 PM, Pankaj Dubey wrote:
> 
> 
> On Tuesday 09 December 2014 06:42 AM, Chanwoo Choi wrote:
>> Hi Pankaj,
>>
>> On 12/08/2014 08:31 PM, Pankaj Dubey wrote:
>>> Hi Chanwoo,
>>>
>>> On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:
 This patch adds missing divider/gate clocks of CMU_PERIC domain
 which includes I2S/PCM/SPDIF/PWM/SLIMBUS IPs. The SPI/I2S may use
 external input clock which has 'ioclk_*' prefix.

 Cc: Sylwester Nawrocki 
 Cc: Tomasz Figa 
 Signed-off-by: Chanwoo Choi 
 [ideal.song: Change clk flags of to pclk_gpio_* clk, pclk_gpio_* should be 
 always on.]
 Signed-off-by: Inha Song 
 Acked-by: Inki Dae 
 Acked-by: Geunsik Lim 
 ---
drivers/clk/samsung/clk-exynos5433.c   | 80 
 +-
include/dt-bindings/clock/exynos5433.h | 34 ++-
2 files changed, 112 insertions(+), 2 deletions(-)

 diff --git a/drivers/clk/samsung/clk-exynos5433.c 
 b/drivers/clk/samsung/clk-exynos5433.c
 index 88e8cac..a48b36c 100644
 --- a/drivers/clk/samsung/clk-exynos5433.c
 +++ b/drivers/clk/samsung/clk-exynos5433.c
 @@ -256,6 +256,14 @@ static struct samsung_fixed_rate_clock 
 top_fixed_clks[] __initdata = {
FRATE(0, "ioclk_audiocdclk0", NULL, CLK_IS_ROOT, 1),
/* Xi2s1SDI input clock for SPDIF */
FRATE(0, "ioclk_spdif_extclk", NULL, CLK_IS_ROOT, 1),
 +/* XspiCLK[4:0] input clock for SPI */
 +FRATE(0, "ioclk_spi4_clk_in", NULL, CLK_IS_ROOT, 5000),
 +FRATE(0, "ioclk_spi3_clk_in", NULL, CLK_IS_ROOT, 5000),
 +FRATE(0, "ioclk_spi2_clk_in", NULL, CLK_IS_ROOT, 5000),
 +FRATE(0, "ioclk_spi1_clk_in", NULL, CLK_IS_ROOT, 5000),
 +FRATE(0, "ioclk_spi0_clk_in", NULL, CLK_IS_ROOT, 5000),
 +/* Xi2s1SCLK input clock for I2S1_BCLK */
 +FRATE(0, "ioclk_i2s1_bclk_in", NULL, CLK_IS_ROOT, 12288000),
};

static struct samsung_mux_clock top_mux_clks[] __initdata = {
 @@ -760,6 +768,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif, 
 "samsung,exynos5433-cmu-mif",
 * Register offset definitions for CMU_PERIC
 */
#define DIV_PERIC0x0600
 +#define DIV_STAT_PERIC0x0700
#define ENABLE_ACLK_PERIC0x0800
#define ENABLE_PCLK_PERIC00x0900
#define ENABLE_PCLK_PERIC10x0904
 @@ -770,6 +779,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif, 
 "samsung,exynos5433-cmu-mif",

static unsigned long peric_clk_regs[] __initdata = {
DIV_PERIC,
 +DIV_STAT_PERIC,
>>>
>>> IMO, this line should have been added in first place itself when you added 
>>> peric_clk_regs.
>>
>> Why? I want to locate it according to address base.
> 
> Since DIV_PERIC and DIV_STAT_PERIC both has same address base, why not to add 
> DIV_STAT_PERIC at the same place when you added DIV_PERIC?

I mean the register offset instead of address base.
DIV_PERIC(0x0600) is less than DIV_STAT_PERIC(0x0700).
So, I want to locate DIV_STAT_PERIC on behind DIV_PERIC in ascending order.

But, It is just minor issue.

Best Regards,
Chanwoo Choi

> 
> Anyways, this was just my opinion as I don't see any dependency why we should 
> add it here? I left this up to you.
> 
>>
>>>
ENABLE_ACLK_PERIC,
ENABLE_PCLK_PERIC0,
ENABLE_PCLK_PERIC1,
 @@ -779,14 +789,57 @@ static unsigned long peric_clk_regs[] __initdata = {
ENABLE_IP_PERIC2,
};

 +static struct samsung_div_clock peric_div_clks[] __initdata = {
 +/* DIV_PERIC */
 +DIV(CLK_DIV_SCLK_SCI, "div_sclk_sci", "fin_pll", DIV_PERIC, 4, 8),
>>>
>>> As per UM I have DIV_SCLK_SCI has 4 bit wide as [7:4] please cross verify.
>>
>> You're right. It is my mistake. I'll fix it.
>>
>> Best Regards,
>> Chanwoo Choi
>>
> 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/

Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_G3D domain

[Pankaj Dubey]

Hi Chanwoo,

On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:

This patch adds the mux/divider/gate clocks for CMU_G3D domain which contains
the clocks for GPU(3D Graphics Engine).

Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Acked-by: Inki Dae 
Acked-by: Geunsik Lim 


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 v2] x86/tsc: Change Fast TSC calibration failed from error to warning

[Alexandre Demers]

Most users see this message when booting without knowning that it is of 
mostly no importance and that TSC calibration may have succeeded by another 
way.

As explained thoroufly by Paul Bolle in 2012 
(http://lkml.iu.edu//hypermail/linux/kernel/1209.3/00224.html), 
"Fast TSC calibration failed" should not be considered as an error since 
other calibration methods are being tried afterward. At most, those send a 
warning if they fail (not an error). So let's change the message from error 
to warning.

It should also fix bug 75971: fast tsc calibration failed on ubuntu 14.04 LTS

Tested on kernel 3.18.

v2: fixed comment.

Cc: sta...@vger.kernel.org
Signed-off-by: Alexandre Demers 

---
 arch/x86/kernel/tsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index b6025f9..5a22022 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -617,7 +617,7 @@ static unsigned long quick_pit_calibrate(void)
goto success;
}
}
-   pr_err("Fast TSC calibration failed\n");
+   pr_warn("Fast TSC calibration failed\n");
return 0;
 
 success:
-- 
2.1.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] softirq/preempt: add missing current->preempt_disable_ip update

[Heiko Carstens]

On Mon, Nov 24, 2014 at 03:16:19PM +0100, Heiko Carstens wrote:
> While debugging some "sleeping function called from invalid context" bug I
> realized that the debug message "Preemption disabled at:" pointed to an
> incorrect function.
> In particular if the function/action that disabled preemption was
> spin_lock_bh() then current->preempt_disable_ip won't be updated.
> 
> The reason for this is that __local_bh_disable_ip() will increase
> preempt_count manually instead of calling preempt_count_add(), which
> would handle the update correctly.
> It look like the manual handling was done to work around some lockdep issue.
> 
> So add the missing update of current->preempt_disable_ip to
> __local_bh_disable_ip() as well.
> 
> Signed-off-by: Heiko Carstens 
> ---
>  kernel/softirq.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index 501baa9ac1be..edd51027e3ab 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -114,8 +114,13 @@ void __local_bh_disable_ip(unsigned long ip, unsigned 
> int cnt)
>   trace_softirqs_off(ip);
>   raw_local_irq_restore(flags);
>  
> - if (preempt_count() == cnt)
> - trace_preempt_off(CALLER_ADDR0, get_parent_ip(CALLER_ADDR1));
> + if (preempt_count() == cnt) {
> + unsigned long ip = get_parent_ip(CALLER_ADDR1);
> +#ifdef CONFIG_DEBUG_PREEMPT
> + current->preempt_disable_ip = ip;
> +#endif
> + trace_preempt_off(CALLER_ADDR0, ip);
> + }
>  }
>  EXPORT_SYMBOL(__local_bh_disable_ip);
>  #endif /* CONFIG_TRACE_IRQFLAGS */

*ping*

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

[f2fs-dev][PATCH 3/4 v2] f2fs: readahead contiguous current summary blocks in checkpoint

[Chao Yu]

Let's add readahead code for reading contiguous compact/normal summary blocks
in checkpoint, then we will gain better performance in mount procedure.

Changes from v1
  o remove inappropriate 'unlikely' in npages_for_summary_flush.

Signed-off-by: Chao Yu 
---
 fs/f2fs/checkpoint.c |  2 +-
 fs/f2fs/f2fs.h   |  2 +-
 fs/f2fs/segment.c| 21 ++---
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index b2d5431..226f980 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -923,7 +923,7 @@ static void do_checkpoint(struct f2fs_sb_info *sbi, struct 
cp_control *cpc)
ckpt->next_free_nid = cpu_to_le32(last_nid);
 
/* 2 cp  + n data seg summary + orphan inode blocks */
-   data_sum_blocks = npages_for_summary_flush(sbi);
+   data_sum_blocks = npages_for_summary_flush(sbi, false);
if (data_sum_blocks < NR_CURSEG_DATA_TYPE)
set_ckpt_flags(ckpt, CP_COMPACT_SUM_FLAG);
else
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index f60b817..1d36ff5 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1401,7 +1401,7 @@ void refresh_sit_entry(struct f2fs_sb_info *, block_t, 
block_t);
 void clear_prefree_segments(struct f2fs_sb_info *);
 void release_discard_addrs(struct f2fs_sb_info *);
 void discard_next_dnode(struct f2fs_sb_info *, block_t);
-int npages_for_summary_flush(struct f2fs_sb_info *);
+int npages_for_summary_flush(struct f2fs_sb_info *, bool);
 void allocate_new_segments(struct f2fs_sb_info *);
 int f2fs_trim_fs(struct f2fs_sb_info *, struct fstrim_range *);
 struct page *get_sum_page(struct f2fs_sb_info *, unsigned int);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 42607a6..e287e45 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -735,7 +735,7 @@ static void __add_sum_entry(struct f2fs_sb_info *sbi, int 
type,
 /*
  * Calculate the number of current summary pages for writing
  */
-int npages_for_summary_flush(struct f2fs_sb_info *sbi)
+int npages_for_summary_flush(struct f2fs_sb_info *sbi, bool for_ra)
 {
int valid_sum_count = 0;
int i, sum_in_page;
@@ -743,8 +743,13 @@ int npages_for_summary_flush(struct f2fs_sb_info *sbi)
for (i = CURSEG_HOT_DATA; i <= CURSEG_COLD_DATA; i++) {
if (sbi->ckpt->alloc_type[i] == SSR)
valid_sum_count += sbi->blocks_per_seg;
-   else
-   valid_sum_count += curseg_blkoff(sbi, i);
+   else {
+   if (for_ra)
+   valid_sum_count += le16_to_cpu(
+   F2FS_CKPT(sbi)->cur_data_blkoff[i]);
+   else
+   valid_sum_count += curseg_blkoff(sbi, i);
+   }
}
 
sum_in_page = (PAGE_CACHE_SIZE - 2 * SUM_JOURNAL_SIZE -
@@ -1450,12 +1455,22 @@ static int restore_curseg_summaries(struct f2fs_sb_info 
*sbi)
int err;
 
if (is_set_ckpt_flags(F2FS_CKPT(sbi), CP_COMPACT_SUM_FLAG)) {
+   int npages = npages_for_summary_flush(sbi, true);
+
+   if (npages >= 2)
+   ra_meta_pages(sbi, start_sum_block(sbi), npages,
+   META_CP);
+
/* restore for compacted data summary */
if (read_compacted_summaries(sbi))
return -EINVAL;
type = CURSEG_HOT_NODE;
}
 
+   if (is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG))
+   ra_meta_pages(sbi, sum_blk_addr(sbi, NR_CURSEG_TYPE, type),
+   NR_CURSEG_TYPE - type, META_CP);
+
for (; type <= CURSEG_COLD_NODE; type++) {
err = read_normal_summaries(sbi, type);
if (err)
-- 
2.1.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] SCSI / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM

[Aaron Lu]

On 12/04/2014 09:22 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
> selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
> depending on CONFIG_PM_RUNTIME may now be changed to depend on
> CONFIG_PM.
> 
> Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
> drivers/scsi/ and in include/scsi/scsi_device.h.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
> 
> Note: This depends on commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if
> PM_SLEEP is selected) which is only in linux-next at the moment (via the
> linux-pm tree).
> 
> Please let me know if it is OK to take this one into linux-pm.
> 
> ---
>  drivers/scsi/scsi_pm.c   |4 ++--
>  drivers/scsi/scsi_priv.h |5 ++---
>  drivers/scsi/ufs/ufshcd-pci.c|   11 ---
>  drivers/scsi/ufs/ufshcd-pltfrm.c |   11 ---
>  include/scsi/scsi_device.h   |4 ++--
>  5 files changed, 14 insertions(+), 21 deletions(-)
> 
> Index: linux-pm/drivers/scsi/scsi_pm.c
> ===
> --- linux-pm.orig/drivers/scsi/scsi_pm.c
> +++ linux-pm/drivers/scsi/scsi_pm.c
> @@ -213,7 +213,7 @@ static int scsi_bus_restore(struct devic
>  
>  #endif /* CONFIG_PM_SLEEP */
>  
> -#ifdef CONFIG_PM_RUNTIME
> +#ifdef CONFIG_PM
>  
>  static int sdev_runtime_suspend(struct device *dev)
>  {
> @@ -338,7 +338,7 @@ void scsi_autopm_put_host(struct Scsi_Ho
>  #define scsi_runtime_resume  NULL
>  #define scsi_runtime_idleNULL
>  
> -#endif /* CONFIG_PM_RUNTIME */
> +#endif /* CONFIG_PM */
>  
>  const struct dev_pm_ops scsi_bus_pm_ops = {
>   .prepare =  scsi_bus_prepare,

Just one nitpeak: since scsi_pm.o is only compiled when CONFIG_PM is
set, I think we can skip the #ifdef CONFIG_PM ... #endif macro in this
file now. I mean something like this:

diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 7454498..9e43ae1 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -213,8 +213,6 @@ static int scsi_bus_restore(struct device *dev)
 
 #endif /* CONFIG_PM_SLEEP */
 
-#ifdef CONFIG_PM_RUNTIME
-
 static int sdev_runtime_suspend(struct device *dev)
 {
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
@@ -332,14 +330,6 @@ void scsi_autopm_put_host(struct Scsi_Host *shost)
pm_runtime_put_sync(>shost_gendev);
 }
 
-#else
-
-#define scsi_runtime_suspend   NULL
-#define scsi_runtime_resumeNULL
-#define scsi_runtime_idle  NULL
-
-#endif /* CONFIG_PM_RUNTIME */
-
 const struct dev_pm_ops scsi_bus_pm_ops = {
.prepare =  scsi_bus_prepare,
.suspend =  scsi_bus_suspend,

Thanks,
Aaron
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] s390: Include kvm_host.h header only if KVM is enabled

[Heiko Carstens]

On Mon, Dec 08, 2014 at 09:29:08PM -0500, Pranith Kumar wrote:
> On Mon, Dec 8, 2014 at 6:59 PM, Paul E. McKenney
>  wrote:
> > On Mon, Dec 08, 2014 at 03:24:35PM -0500, Pranith Kumar wrote:
> >> KVM uses srcu structures because of which CONFIG_KVM selects CONFIG_SRCU. 
> >> In
> >> asm-offsets.c, we are including kvm_host.h unconditionally even though
> >> CONFIG_KVM is not enabled because of which we get errors like follows:
> >>
> >> In file included from arch/s390/kernel/asm-offsets.c:10:0:
> >> >> include/linux/kvm_host.h:363:21: error: field 'srcu' has incomplete type
> >>   struct srcu_struct srcu;
> >>  ^
> >> >> include/linux/kvm_host.h:364:21: error: field 'irq_srcu' has incomplete 
> >> >> type
> >>   struct srcu_struct irq_srcu;
> >>  ^
> >> make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1
> >> make[2]: Target '__build' not remade because of errors.
> >> make[1]: *** [prepare0] Error 2
> >> make[1]: Target 'prepare' not remade because of errors.
> >> make: *** [sub-make] Error 2
> >>
> >> This patch fixes these by including kvm_host.h conditionally on CONFIG_KVM.
> >>
> >> Signed-off-by: Pranith Kumar 
> >
> > To make the commits bisectable, we need to combine these two patches,
> > correct?
> >
> 
> Yes, if the s390 maintainers raise no objections, I will combine this
> with the other patch and send it.

That's fine with me.

> >>  arch/s390/kernel/asm-offsets.c | 7 ++-
> >>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/s390/kernel/asm-offsets.c 
> >> b/arch/s390/kernel/asm-offsets.c
> >> index ef279a1..055334d 100644
> >> --- a/arch/s390/kernel/asm-offsets.c
> >> +++ b/arch/s390/kernel/asm-offsets.c
> >> @@ -7,12 +7,15 @@
> >>  #define ASM_OFFSETS_C
> >>
> >>  #include 
> >> -#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>  #include 
> >>
> >> +#ifdef CONFIG_KVM
> >> +#include 
> >> +#endif
> >> +

Even though I'm wondering why linux/kvm_host.h doesn't have such an #ifdef
included. Not that it would help in this case, but it would help to omit
the #ifdef around the #include statement here.

Looking a bit further.. so arch/s390/include/asm/kvm_host.h includes
include/linux/kvm_host.h and vice versa. Nice ;)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [f2fs-dev][PATCH 3/4] f2fs: readahead contiguous current summary blocks in checkpoint

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, December 09, 2014 3:09 AM
> To: Chao Yu
> Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net; 
> linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [f2fs-dev][PATCH 3/4] f2fs: readahead contiguous current summary 
> blocks in
> checkpoint
> 
> Hi Chao,
> 
> On Mon, Dec 08, 2014 at 03:01:16PM +0800, Chao Yu wrote:
> > Let's add readahead code for reading contiguous compact/normal summary 
> > blocks
> > in checkpoint, then we will gain better performance in mount procedure.
> >
> > Signed-off-by: Chao Yu 
> > ---
> >  fs/f2fs/checkpoint.c |  2 +-
> >  fs/f2fs/f2fs.h   |  2 +-
> >  fs/f2fs/segment.c| 21 ++---
> >  3 files changed, 20 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > index e0ff75e..aa2a21c 100644
> > --- a/fs/f2fs/checkpoint.c
> > +++ b/fs/f2fs/checkpoint.c
> > @@ -915,7 +915,7 @@ static void do_checkpoint(struct f2fs_sb_info *sbi, 
> > struct cp_control
> *cpc)
> > ckpt->next_free_nid = cpu_to_le32(last_nid);
> >
> > /* 2 cp  + n data seg summary + orphan inode blocks */
> > -   data_sum_blocks = npages_for_summary_flush(sbi);
> > +   data_sum_blocks = npages_for_summary_flush(sbi, false);
> > if (data_sum_blocks < NR_CURSEG_DATA_TYPE)
> > set_ckpt_flags(ckpt, CP_COMPACT_SUM_FLAG);
> > else
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index d042813..fc88e8a 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -1393,7 +1393,7 @@ void refresh_sit_entry(struct f2fs_sb_info *, 
> > block_t, block_t);
> >  void clear_prefree_segments(struct f2fs_sb_info *);
> >  void release_discard_addrs(struct f2fs_sb_info *);
> >  void discard_next_dnode(struct f2fs_sb_info *, block_t);
> > -int npages_for_summary_flush(struct f2fs_sb_info *);
> > +int npages_for_summary_flush(struct f2fs_sb_info *, bool);
> >  void allocate_new_segments(struct f2fs_sb_info *);
> >  int f2fs_trim_fs(struct f2fs_sb_info *, struct fstrim_range *);
> >  struct page *get_sum_page(struct f2fs_sb_info *, unsigned int);
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index 9a33e34..e3bec6e 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -731,7 +731,7 @@ static void __add_sum_entry(struct f2fs_sb_info *sbi, 
> > int type,
> >  /*
> >   * Calculate the number of current summary pages for writing
> >   */
> > -int npages_for_summary_flush(struct f2fs_sb_info *sbi)
> > +int npages_for_summary_flush(struct f2fs_sb_info *sbi, bool for_ra)
> >  {
> > int valid_sum_count = 0;
> > int i, sum_in_page;
> > @@ -739,8 +739,13 @@ int npages_for_summary_flush(struct f2fs_sb_info *sbi)
> > for (i = CURSEG_HOT_DATA; i <= CURSEG_COLD_DATA; i++) {
> > if (sbi->ckpt->alloc_type[i] == SSR)
> > valid_sum_count += sbi->blocks_per_seg;
> > -   else
> > -   valid_sum_count += curseg_blkoff(sbi, i);
> > +   else {
> > +   if (unlikely(for_ra))
> 
> IMO, unlikely is not appropriate for here.

I suppose that for readonly f2fs image, unlikely is not appropriate, as
we always execute the if part when mount.
Anyway, I will remove this and resend the patch.
Thanks for your review!

Regards,
Yu

> 
> 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 03/19] clk: samsung: exynos5433: Add clocks for CMU_PERIC domain

[Pankaj Dubey]

On Tuesday 09 December 2014 06:42 AM, Chanwoo Choi wrote:

Hi Pankaj,

On 12/08/2014 08:31 PM, Pankaj Dubey wrote:

Hi Chanwoo,

On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:

This patch adds missing divider/gate clocks of CMU_PERIC domain
which includes I2S/PCM/SPDIF/PWM/SLIMBUS IPs. The SPI/I2S may use
external input clock which has 'ioclk_*' prefix.

Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
[ideal.song: Change clk flags of to pclk_gpio_* clk, pclk_gpio_* should be 
always on.]
Signed-off-by: Inha Song 
Acked-by: Inki Dae 
Acked-by: Geunsik Lim 
---
   drivers/clk/samsung/clk-exynos5433.c   | 80 
+-
   include/dt-bindings/clock/exynos5433.h | 34 ++-
   2 files changed, 112 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index 88e8cac..a48b36c 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -256,6 +256,14 @@ static struct samsung_fixed_rate_clock top_fixed_clks[] 
__initdata = {
   FRATE(0, "ioclk_audiocdclk0", NULL, CLK_IS_ROOT, 1),
   /* Xi2s1SDI input clock for SPDIF */
   FRATE(0, "ioclk_spdif_extclk", NULL, CLK_IS_ROOT, 1),
+/* XspiCLK[4:0] input clock for SPI */
+FRATE(0, "ioclk_spi4_clk_in", NULL, CLK_IS_ROOT, 5000),
+FRATE(0, "ioclk_spi3_clk_in", NULL, CLK_IS_ROOT, 5000),
+FRATE(0, "ioclk_spi2_clk_in", NULL, CLK_IS_ROOT, 5000),
+FRATE(0, "ioclk_spi1_clk_in", NULL, CLK_IS_ROOT, 5000),
+FRATE(0, "ioclk_spi0_clk_in", NULL, CLK_IS_ROOT, 5000),
+/* Xi2s1SCLK input clock for I2S1_BCLK */
+FRATE(0, "ioclk_i2s1_bclk_in", NULL, CLK_IS_ROOT, 12288000),
   };

   static struct samsung_mux_clock top_mux_clks[] __initdata = {
@@ -760,6 +768,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif, 
"samsung,exynos5433-cmu-mif",
* Register offset definitions for CMU_PERIC
*/
   #define DIV_PERIC0x0600
+#define DIV_STAT_PERIC0x0700
   #define ENABLE_ACLK_PERIC0x0800
   #define ENABLE_PCLK_PERIC00x0900
   #define ENABLE_PCLK_PERIC10x0904
@@ -770,6 +779,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif, 
"samsung,exynos5433-cmu-mif",

   static unsigned long peric_clk_regs[] __initdata = {
   DIV_PERIC,
+DIV_STAT_PERIC,


IMO, this line should have been added in first place itself when you added 
peric_clk_regs.


Why? I want to locate it according to address base.


Since DIV_PERIC and DIV_STAT_PERIC both has same address base, why not 
to add DIV_STAT_PERIC at the same place when you added DIV_PERIC?


Anyways, this was just my opinion as I don't see any dependency why we 
should add it here? I left this up to you.







   ENABLE_ACLK_PERIC,
   ENABLE_PCLK_PERIC0,
   ENABLE_PCLK_PERIC1,
@@ -779,14 +789,57 @@ static unsigned long peric_clk_regs[] __initdata = {
   ENABLE_IP_PERIC2,
   };

+static struct samsung_div_clock peric_div_clks[] __initdata = {
+/* DIV_PERIC */
+DIV(CLK_DIV_SCLK_SCI, "div_sclk_sci", "fin_pll", DIV_PERIC, 4, 8),


As per UM I have DIV_SCLK_SCI has 4 bit wide as [7:4] please cross verify.


You're right. It is my mistake. I'll fix it.

Best Regards,
Chanwoo Choi


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/

Re: [PATCH] irqchip: mediatek: Fix error return code detection

[Yingjoe Chen]

On Mon, 2014-12-08 at 21:30 +0100, Thomas Gleixner wrote:
> On Mon, 8 Dec 2014, Yingjoe Chen wrote:
> 
> > This fix an error handling bug reported by Beniamino, this is based on
> > mtk intpol patches [1]
> >
> > Joe.C
> > 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305808.html
> > 
> > 
> > of_io_request_and_map() return ERR_PTR wrapped error code instead of
> > NULL when fail, fix code in mtk_sysirq_of_init() to correctly handle
> > this.
> > 
> > Signed-off-by: Yingjoe Chen 
> 
> This is not a proper changelog. Let me write up a proper one:
> 
> Subject: irqchip: mediatek: Use IS_ERR() instead of NULL pointer check
> 
> Beniamino reported a kernel oops caused by an invalid DT file for the
> mediatek interrupt polarity extension.
> 
> The reason is that the interrupt polarity support for mediatek chips
> merily checks for at NULL pointer instead of a casted error return
> value in mtk_sysirq_of_init() so any other casted error value passes
> the NULL pointer check and causes a kernel panic when dereferenced.
> 
> Use IS_ERR() and return the error value via PTR_ERR().
> 
> Reported-and-tested-by: Beniamino Galvani 
> Signed-off-by: Yingjoe Chen 
> 
> Can you see the difference?
> 
> Thanks,
> 
>   tglx

Thanks for the review.

This changelog describe issue and why we need this change more clearly.
I'll prepare a new patch with this changelog, Thanks.

Joe.C


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

Re: [PATCH 07/19] clk: samsung: exynos5433: Add clocks for CMU_DISP domain

[Pankaj Dubey]

Hi Chanwoo,

On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:

This patch adds the the mux/divider/gate clocks for CMU_DISP domain which
includes the clocks of Display IPs (DECON/HDMI/DSIM/MIXER). The CMU_DISP clocks
is used to need the source clock of CMU_MIF domain so, the CMU_MIF's clocks
related to CMU_DISP should be always on state.

Also, CMU_DISP must need the source clock of 'sclk_hdmi_spdif_disp'
from CMU_TOP domain. This patch adds the clocks of CMU_TOP related to HDMI.

Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Acked-by: Inki Dae 
Acked-by: Geunsik Lim 
---
  .../devicetree/bindings/clock/exynos5433-clock.txt |   9 +
  drivers/clk/samsung/clk-exynos5433.c   | 465 -
  include/dt-bindings/clock/exynos5433.h | 114 -
  3 files changed, 577 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 27dd77b..8d3dad4 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -21,6 +21,8 @@ Required Properties:
  which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
- "samsung,exynos5433-cmu-g2d"   - clock controller compatible for CMU_G2D
  which generates clocks for G2D/MDMA IPs.
+  - "samsung,exynos5433-cmu-disp"  - clock controller compatible for CMU_DISP
+which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.

  - reg: physical base address of the controller and length of memory mapped
region.
@@ -78,6 +80,13 @@ Example 1: Examples of clock controller nodes are listed 
below.
#clock-cells = <1>;
};

+   cmu_disp: clock-controller@0x13b9 {
+   compatible = "samsung,exynos5433-cmu-disp";
+   reg = <0x13b9 0x0c04>;
+   #clock-cells = <1>;
+   };
+
+
  Example 2: UART controller node that consumes the clock generated by the clock
   controller.

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index 10197a1..ec23e97 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -245,6 +245,8 @@ PNAME(mout_sclk_audio1_p)   = { "ioclk_audiocdclk1", 
"fin_pll",
  PNAME(mout_sclk_audio0_p) = { "ioclk_audiocdclk0", "fin_pll",
"mout_aud_pll_user_t",};

+PNAME(mout_sclk_hdmi_spdif_p)  = { "sclk_audio1", "ioclk_spdif_extclk", };
+
  static struct samsung_fixed_factor_clock top_fixed_factor_clks[] __initdata = 
{
FFACTOR(0, "sclk_bus_pll", "fout_bus_pll", 1, 1, 0),
FFACTOR(0, "sclk_mfc_pll", "fout_mfc_pll", 1, 1, 0),
@@ -397,6 +399,10 @@ static struct samsung_mux_clock top_mux_clks[] __initdata 
= {
MUX_SEL_TOP_PERIC1, 4, 2),
MUX(CLK_MOUT_SCLK_AUDIO0, "mout_sclk_audio0", mout_sclk_audio0_p,
MUX_SEL_TOP_PERIC1, 0, 2),
+
+   /* MUX_SEL_TOP_DISP */
+   MUX(CLK_MOUT_SCLK_HDMI_SPDIF, "mout_sclk_hdmi_spdif",
+   mout_sclk_hdmi_spdif_p, MUX_SEL_TOP_DISP, 0, 1),
  };

  static struct samsung_div_clock top_div_clks[] __initdata = {
@@ -1256,9 +1262,9 @@ static struct samsung_gate_clock mif_gate_clks[] 
__initdata = {

/* ENABLE_ACLK_MIF3 */
GATE(CLK_ACLK_BUS2_400, "aclk_bus2_400", "div_aclk_bus2_400",
-   ENABLE_ACLK_MIF3, 4, 0, 0),
+   ENABLE_ACLK_MIF3, 4, CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_DISP_333, "aclk_disp_333", "div_aclk_disp_333",
-   ENABLE_ACLK_MIF3, 1, 0, 0),
+   ENABLE_ACLK_MIF3, 1, CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_CPIF_200, "aclk_cpif_200", "div_aclk_cpif_200",
ENABLE_ACLK_MIF3, 0, CLK_IGNORE_UNUSED, 0),

@@ -1333,21 +1339,30 @@ static struct samsung_gate_clock mif_gate_clks[] 
__initdata = {

/* ENABLE_SCLK_MIF */
GATE(CLK_SCLK_DSIM1_DISP, "sclk_dsim1_disp", "div_sclk_dsim1",
-   ENABLE_SCLK_MIF, 15, 0, 0),
+   ENABLE_SCLK_MIF, 15, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_DECON_TV_VCLK_DISP, "sclk_decon_tv_vclk_disp",
-   "div_sclk_decon_tv_vclk", ENABLE_SCLK_MIF, 14, 0, 0),
+   "div_sclk_decon_tv_vclk", ENABLE_SCLK_MIF,
+   14, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_DSIM0_DISP, "sclk_dsim0_disp", "div_sclk_dsim0",
-   ENABLE_SCLK_MIF, 9, 0, 0),
+   ENABLE_SCLK_MIF, 9, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_DSD_DISP, "sclk_dsd_disp", "div_sclk_dsd",
-   ENABLE_SCLK_MIF, 8, 0, 0),
+   ENABLE_SCLK_MIF, 8, CLK_IGNORE_UNUSED, 0),
GATE(CLK_SCLK_DECON_TV_ECLK_DISP, "sclk_decon_tv_eclk_disp",
-   "div_sclk_decon_tv_eclk", 

Re: [PATCH 08/19] clk: samsung: exynos5433: Add clocks for CMU_AUD domain

[Pankaj Dubey]

Hi Chanwoo,

On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:

This patch adds the mux/divider/gate clocks for CMU_AUD domain which
includes the clocks of Cortex-A6/Bus/Audio clocks.


Cortex-A6? I think it should be Cortex-A5?



Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Acked-by: Inki Dae 
Acked-by: Geunsik Lim 
---
  .../devicetree/bindings/clock/exynos5433-clock.txt |   7 +
  drivers/clk/samsung/clk-exynos5433.c   | 173 +
  include/dt-bindings/clock/exynos5433.h |  53 +++
  3 files changed, 233 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 8d3dad4..9a6ae75 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -23,6 +23,8 @@ Required Properties:
  which generates clocks for G2D/MDMA IPs.
- "samsung,exynos5433-cmu-disp"  - clock controller compatible for CMU_DISP
  which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.
+  - "samsung,exynos5433-cmu-aud"   - clock controller compatible for CMU_AUD
+which generates clocks for Cortex-A5/BUS/AUDIO clocks.


Commit message says Cortex-A6?



  - reg: physical base address of the controller and length of memory mapped
region.
@@ -86,6 +88,11 @@ Example 1: Examples of clock controller nodes are listed 
below.
#clock-cells = <1>;
};

+   cmu_aud: clock-controller@0x114c {
+   compatible = "samsung,exynos5433-cmu-aud";
+   reg = <0x114c 0x0b04>;
+   #clock-cells = <1>;
+   };

  Example 2: UART controller node that consumes the clock generated by the clock
   controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index ec23e97..99262e0 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -2454,3 +2454,176 @@ static void __init exynos5433_cmu_disp_init(struct 
device_node *np)

  CLK_OF_DECLARE(exynos5433_cmu_disp, "samsung,exynos5433-cmu-disp",
exynos5433_cmu_disp_init);
+
+/*
+ * Register offset definitions for CMU_AUD
+ */
+#define MUX_SEL_AUD0   0x0200
+#define MUX_SEL_AUD1   0x0204
+#define MUX_ENABLE_AUD00x0300
+#define MUX_ENABLE_AUD10x0304
+#define MUX_STAT_AUD0  0x0400
+#define DIV_AUD0   0x0600
+#define DIV_AUD1   0x0604
+#define DIV_STAT_AUD0  0x0700
+#define DIV_STAT_AUD1  0x0704
+#define ENABLE_ACLK_AUD0x0800
+#define ENABLE_PCLK_AUD0x0900
+#define ENABLE_SCLK_AUD0   0x0a00
+#define ENABLE_SCLK_AUD1   0x0a04
+#define ENABLE_IP_AUD0 0x0b00
+#define ENABLE_IP_AUD1 0x0b04
+
+static unsigned long aud_clk_regs[] __initdata = {
+   MUX_SEL_AUD0,
+   MUX_SEL_AUD1,
+   MUX_ENABLE_AUD0,
+   MUX_ENABLE_AUD1,
+   MUX_STAT_AUD0,
+   DIV_AUD0,
+   DIV_AUD1,
+   DIV_STAT_AUD0,
+   DIV_STAT_AUD1,
+   ENABLE_ACLK_AUD,
+   ENABLE_PCLK_AUD,
+   ENABLE_SCLK_AUD0,
+   ENABLE_SCLK_AUD1,
+   ENABLE_IP_AUD0,
+   ENABLE_IP_AUD1,
+};
+
+/* list of all parent clock list */
+PNAME(mout_aud_pll_user_aud_p) = { "fin_pll", "fout_aud_pll", };
+PNAME(mout_sclk_aud_pcm_p) = { "mout_aud_pll_user", "ioclk_audiocdclk0",};
+PNAME(mout_sclk_aud_i2s_p) = { "mout_aud_pll_user", "ioclk_audiocdclk0",};


Above two lines can be clubbed with some common name as both has same 
parent clocks.



+
+static struct samsung_fixed_rate_clock aud_fixed_clks[] __initdata = {
+   FRATE(0, "ioclk_jtag_tclk", NULL, CLK_IS_ROOT, 18800),
+   FRATE(0, "ioclk_slimbus_clk", NULL, CLK_IS_ROOT, 18800),
+   FRATE(0, "ioclk_i2s_bclk", NULL, CLK_IS_ROOT, 18800),


Are you sure about these clock rates?
As per UM I have, these are having rates as 33 MHz, 25 MHz and 50 MHz 
respectively.



+};
+
+static struct samsung_mux_clock aud_mux_clks[] __initdata = {
+   /* MUX_SEL_AUD0 */
+   MUX(CLK_MOUT_AUD_PLL_USER, "mout_aud_pll_user",
+   mout_aud_pll_user_aud_p, MUX_SEL_AUD0, 0, 1),
+
+   /* MUX_SEL_AUD1 */
+   MUX(CLK_MOUT_SCLK_AUD_PCM, "mout_sclk_aud_pcm", mout_sclk_aud_pcm_p,
+   MUX_SEL_AUD1, 8, 1),
+   MUX(CLK_MOUT_SCLK_AUD_I2S, "mout_sclk_aud_i2s", mout_sclk_aud_i2s_p,
+   MUX_SEL_AUD1, 0, 1),
+};
+


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/

Re: [PATCH 09/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains

[Pankaj Dubey]

Hi Chanwoo,

On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:

This patch adds the mux/divider/gate clocks for CMU_BUS{0|1|2} domains
which contain global data buses clocked at up the 400MHz. These blocks
transfer data between DRAM and various sub-blocks. These clock domains
also contain global peripheral buses clocked at 67/111/200/222/266/333/400
MHz and used for regiser accesses.


typo: %s/regiser/register



Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Cc: Arnd Bergmann 
Signed-off-by: Chanwoo Choi 
Acked-by: Inki Dae 
Acked-by: Geunsik Lim 
---
  .../devicetree/bindings/clock/exynos5433-clock.txt |  21 +++
  drivers/clk/samsung/clk-exynos5433.c   | 185 -
  include/dt-bindings/clock/exynos5433.h |  29 +++-
  3 files changed, 232 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 9a6ae75..03ae40a 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -25,6 +25,9 @@ Required Properties:
  which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.
- "samsung,exynos5433-cmu-aud"   - clock controller compatible for CMU_AUD
  which generates clocks for Cortex-A5/BUS/AUDIO clocks.
+  - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
+and "samsung,exynos5433-cmu-bus2" - clock controller compatible for CMU_BUS
+which generates global data buses clock and global peripheral buses clock.

  - reg: physical base address of the controller and length of memory mapped
region.
@@ -94,6 +97,24 @@ Example 1: Examples of clock controller nodes are listed 
below.
#clock-cells = <1>;
};

+   cmu_bus0: clock-controller@0x1360 {
+   compatible = "samsung,exynos5433-cmu-bus0";
+   reg = <0x1360 0x0b04>;
+   #clock-cells = <1>;
+   };
+
+   cmu_bus1: clock-controller@0x1480 {
+   compatible = "samsung,exynos5433-cmu-bus1";
+   reg = <0x1480 0x0b04>;
+   #clock-cells = <1>;
+   };
+
+   cmu_bus2: clock-controller@0x1340 {
+   compatible = "samsung,exynos5433-cmu-bus2";
+   reg = <0x1340 0x0b04>;
+   #clock-cells = <1>;
+   };
+
  Example 2: UART controller node that consumes the clock generated by the clock
   controller.

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index 99262e0..5b4ec83 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -425,7 +425,7 @@ static struct samsung_div_clock top_div_clks[] __initdata = 
{
DIV_TOP2, 0, 3),

/* DIV_TOP3 */
-   DIV(CLK_DIV_ACLK_IMEM_SSSX, "div_aclk_imem_sssx",
+   DIV(CLK_DIV_ACLK_IMEM_SSSX_266, "div_aclk_imem_sssx_266",


This change can be moved to patch 1/19 itself.


"mout_bus_pll_user", DIV_TOP3, 24, 3),
DIV(CLK_DIV_ACLK_IMEM_200, "div_aclk_imem_200",
"mout_bus_pll_user", DIV_TOP3, 20, 3),
@@ -440,6 +440,14 @@ static struct samsung_div_clock top_div_clks[] __initdata 
= {
DIV(CLK_DIV_ACLK_PERIS_66_A, "div_aclk_peris_66_a",
"mout_bus_pll_user", DIV_TOP3, 0, 3),

+   /* DIV_TOP4 */
+   DIV(CLK_DIV_ACLK_G3D_400, "div_aclk_g3d_400", "mout_bus_pll_user",
+   DIV_TOP4, 8, 3),
+   DIV(CLK_DIV_ACLK_BUS0_400, "div_aclk_bus0_400", "mout_aclk_bus0_400",
+   DIV_TOP4, 4, 3),
+   DIV(CLK_DIV_ACLK_BUS1_400, "div_aclk_bus1_400", "mout_bus_pll_user",
+   DIV_TOP4, 0, 3),
+


With these changes you can have:

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/

Re: [PATCH 10/19] clk: samsung: exynos5433: Add missing clocks for CMU_FSYS domain

[Pankaj Dubey]

Hi Chanwoo,

On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:

This patch adds the mux/divider/gate clocks for CMU_FSYS domain which
contains the clocks of USB/UFS/SDMMC/TSI/PDMA IPs.

Cc: Sylwester Nawrocki 
Cc: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
Acked-by: Inki Dae 
Acked-by: Geunsik Lim 
---
  drivers/clk/samsung/clk-exynos5433.c   | 286 +
  include/dt-bindings/clock/exynos5433.h |  82 +-
  2 files changed, 365 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos5433.c 
b/drivers/clk/samsung/clk-exynos5433.c
index 5b4ec83..e2b7ea6 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -464,6 +464,16 @@ static struct samsung_div_clock top_div_clks[] __initdata 
= {
DIV(CLK_DIV_SCLK_MMC2_A, "div_sclk_mmc2_a", "mout_sclk_mmc2_b",
DIV_TOP_FSYS1, 0, 4),

+   /* DIV_TOP_FSYS2 */
+   DIV(CLK_DIV_SCLK_PCIE_100, "div_sclk_pcie_100", "mout_sclk_pcie_100",
+   DIV_TOP_FSYS2, 12, 3),
+   DIV(CLK_DIV_SCLK_USBHOST30, "div_sclk_usbhost30",
+   "mout_sclk_usbhost30", DIV_TOP_FSYS2, 8, 4),
+   DIV(CLK_DIV_SCLK_UFSUNIPRO, "div_sclk_ufsunipro",
+   "mout_sclk_ufsunipro", DIV_TOP_FSYS2, 4, 4),
+   DIV(CLK_DIV_SCLK_USBDRD30, "div_sclk_usbdrd30", "mout_sclk_usbdrd30",
+   DIV_TOP_FSYS2, 0, 4),
+
/* DIV_TOP_PERIC0 */
DIV(CLK_DIV_SCLK_SPI1_B, "div_sclk_spi1_b", "div_sclk_spi1_a",
DIV_TOP_PERIC0, 16, 8),
@@ -536,12 +546,20 @@ static struct samsung_gate_clock top_gate_clks[] 
__initdata = {
ENABLE_ACLK_TOP, 0, CLK_IGNORE_UNUSED, 0),

/* ENABLE_SCLK_TOP_FSYS */
+   GATE(CLK_SCLK_PCIE_100_FSYS, "sclk_pcie_100_fsys", "div_sclk_pcie_100",
+   ENABLE_SCLK_TOP_FSYS, 7, 0, 0),
GATE(CLK_SCLK_MMC2_FSYS, "sclk_mmc2_fsys", "div_sclk_mmc2_b",
ENABLE_SCLK_TOP_FSYS, 6, 0, 0),
GATE(CLK_SCLK_MMC1_FSYS, "sclk_mmc1_fsys", "div_sclk_mmc1_b",
ENABLE_SCLK_TOP_FSYS, 5, 0, 0),
GATE(CLK_SCLK_MMC0_FSYS, "sclk_mmc0_fsys", "div_sclk_mmc0_b",
ENABLE_SCLK_TOP_FSYS, 4, 0, 0),
+   GATE(CLK_SCLK_UFSUNIPRO_FSYS, "sclk_ufsunipro_fsys",
+   "div_sclk_ufsunipro", ENABLE_SCLK_TOP_FSYS, 7, 0, 0),


bit_index for sclk_ufsunipro_fsys is '3'.


+   GATE(CLK_SCLK_USBHOST30_FSYS, "sclk_usbhost30_fsys",
+   "div_sclk_usbhost30", ENABLE_SCLK_TOP_FSYS, 7, 0, 0),


bit_index for sclk_usbhost30_fsys is '1'.


+   GATE(CLK_SCLK_USBDRD30_FSYS, "sclk_usbdrd30_fsys",
+   "div_sclk_usbdrd30", ENABLE_SCLK_TOP_FSYS, 7, 0, 0),


bit_index for sclk_usbdrd30_fsys is '0'.



/* ENABLE_SCLK_TOP_PERIC */
GATE(CLK_SCLK_SPI4_PERIC, "sclk_spi4_peric", "div_sclk_spi4_b",
@@ -1819,10 +1837,45 @@ CLK_OF_DECLARE(exynos5433_cmu_peris, 
"samsung,exynos5433-cmu-peris",
  #define ENABLE_IP_FSYS1   0x0b04

  /* list of all parent clock list */
+PNAME(mout_sclk_ufs_mphy_user_p)   = { "fin_pll", "sclk_ufs_mphy", };
  PNAME(mout_aclk_fsys_200_user_p)  = { "fin_pll", "aclk_fsys_200", };
+PNAME(mout_sclk_pcie_100_user_p)   = { "fin_pll", "sclk_ufsunipro_fsys",};


This parent list looks wrong.
As per UM, it should be: { "fin_pll", "sclk_pcie_100_fsys",};


+PNAME(mout_sclk_ufsunipro_user_p)  = { "fin_pll", "sclk_ufsunipro_fsys",};
  PNAME(mout_sclk_mmc2_user_p)  = { "fin_pll", "sclk_mmc2_fsys", };
  PNAME(mout_sclk_mmc1_user_p)  = { "fin_pll", "sclk_mmc1_fsys", };
  PNAME(mout_sclk_mmc0_user_p)  = { "fin_pll", "sclk_mmc0_fsys", };
+PNAME(mout_sclk_usbhost30_user_p)  = { "fin_pll", "sclk_usbhost30_fsys",};
+PNAME(mout_sclk_usbdrd30_user_p)   = { "fin_pll", "sclk_usbdrd30_fsys", };
+
+PNAME(mout_phyclk_usbhost30_uhost30_pipe_pclk_user_p)
+   = { "fin_pll", "phyclk_usbhost30_uhost30_pipe_pclk_phy", };
+PNAME(mout_phyclk_usbhost30_uhost30_phyclock_user_p)
+   = { "fin_pll", "phyclk_usbhost30_uhost30_phyclock_phy", };
+PNAME(mout_phyclk_usbhost20_phy_hsic1_p)
+   = { "fin_pll", "phyclk_usbhost20_phy_hsic1_phy", };
+PNAME(mout_phyclk_usbhost20_phy_clk48mohci_user_p)
+   = { "fin_pll", "phyclk_usbhost20_phy_clk48mohci_phy", };
+PNAME(mout_phyclk_usbhost20_phy_phyclock_user_p)
+   = { "fin_pll", "phyclk_usbhost20_phy_phyclock_phy", };
+PNAME(mout_phyclk_usbhost20_phy_freeclk_user_p)
+   = { "fin_pll", "phyclk_usbhost20_phy_freeclk_phy", };
+PNAME(mout_phyclk_usbdrd30_udrd30_pipe_pclk_p)
+   = { "fin_pll", "phyclk_usbhost30_uhost30_pipe_pclk_phy", };


Here second parent should be 'phyclk_usbdrd30_udrd30_pipe_pclk_phy'.


+PNAME(mout_phyclk_usbdrd30_udrd30_phyclock_user_p)
+   = { "fin_pll", "phyclk_usbhost30_uhost30_phyclock_phy", 

[alsa-devel][PATCH v4] ASoC: wm8960: Let wm8960 codec driver manage its own MCLK

[Zidan Wang]

When we want to use wm8960 codec, we should enable its MCLK in machine
driver. It's reasonable for wm8960 codec driver to manage its own MCLK to
save power.

Enable runtime power management, and auto enable/disable MCLK in pm_runtime
resume and suspend. When wm8960 codec is being used, it will triger resume()
to enable MCLK. When codec is not being used, it will triger suspend() to
disable MCLK.

Signed-off-by: Zidan Wang 
---
 sound/soc/codecs/wm8960.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index 031a1ae..aff24a7 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -117,6 +119,7 @@ static bool wm8960_volatile(struct device *dev, unsigned 
int reg)
 }
 
 struct wm8960_priv {
+   struct clk *mclk;
struct regmap *regmap;
int (*set_bias_level)(struct snd_soc_codec *,
  enum snd_soc_bias_level level);
@@ -1002,6 +1005,13 @@ static int wm8960_i2c_probe(struct i2c_client *i2c,
if (wm8960 == NULL)
return -ENOMEM;
 
+   wm8960->mclk = devm_clk_get(>dev, "codec_mclk");
+
+   if (IS_ERR(wm8960->mclk)) {
+   if (PTR_ERR(wm8960->mclk) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   }
+
wm8960->regmap = devm_regmap_init_i2c(i2c, _regmap);
if (IS_ERR(wm8960->regmap))
return PTR_ERR(wm8960->regmap);
@@ -1041,6 +1051,9 @@ static int wm8960_i2c_probe(struct i2c_client *i2c,
 
i2c_set_clientdata(i2c, wm8960);
 
+   pm_runtime_enable(>dev);
+   pm_request_idle(>dev);
+
ret = snd_soc_register_codec(>dev,
_codec_dev_wm8960, _dai, 1);
 
@@ -1053,6 +1066,38 @@ static int wm8960_i2c_remove(struct i2c_client *client)
return 0;
 }
 
+#ifdef CONFIG_PM_RUNTIME
+static int wm8960_runtime_resume(struct device *dev)
+{
+   struct wm8960_priv *wm8960 = dev_get_drvdata(dev);
+   int ret;
+
+   if (!IS_ERR(wm8960->mclk)) {
+   ret = clk_prepare_enable(wm8960->mclk);
+   if (ret) {
+   dev_err(dev, "Failed to enable MCLK: %d\n", ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static int wm8960_runtime_suspend(struct device *dev)
+{
+   struct wm8960_priv *wm8960 = dev_get_drvdata(dev);
+
+   if (!IS_ERR(wm8960->mclk))
+   clk_disable_unprepare(wm8960->mclk);
+
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops wm8960_pm = {
+   SET_RUNTIME_PM_OPS(wm8960_runtime_suspend, wm8960_runtime_resume, NULL)
+};
+
 static const struct i2c_device_id wm8960_i2c_id[] = {
{ "wm8960", 0 },
{ }
@@ -1070,6 +1115,7 @@ static struct i2c_driver wm8960_i2c_driver = {
.name = "wm8960",
.owner = THIS_MODULE,
.of_match_table = wm8960_of_match,
+   .pm = _pm,
},
.probe =wm8960_i2c_probe,
.remove =   wm8960_i2c_remove,
-- 
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 v3 0/3] Add support for Tegra Activity Monitor

[Alexandre Courbot]

On Fri, Dec 5, 2014 at 1:14 AM, Tomeu Vizoso  wrote:
> Hello,
>
> this v3 addresses the comments that the devfreq implementation got, namely:
>
> * Address misc. style issues found by Thierry and Alexander
> * Added helpers for register i/o
> * Further documented the structs
> * Enable the ACTMON after the IRQ handler has been installed
> * Disable the ACTMON before removing the IRQ handler
> * Add governor in a subsys initcall
>
> There's an open question on whether some functionality currently in this
> devfreq driver should be moved into the devfreq framework, but without knowing
> of other SoC family that would benefit from it, I'm reticent. It would be
> great to hear from the devfreq maintainers if they have any plans regarding
> this, or if they have any suggestion.

I cannot make a thorough review because of the problem I mentioned in
patch 3/3, but I am guessing this series is converging towards what we
want. Now the main question will be how we can leverage Arto's
watermark series for this one. I am ready to bet that doing so can
reduce quite a lot of code.

Since you are likely to be the first user of the watermarking feature,
could you comment on its potential shortcomings and whatever needs to
be fixed to best implement ACTMON support using it? I will try to push
it myself, but you are obviously in a better position to understand
what is needed.

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 v3 3/3] ARM: tegra: Add Tegra124 ACTMON support

[Alexandre Courbot]

On Fri, Dec 5, 2014 at 1:14 AM, Tomeu Vizoso  wrote:
> Add device node for the ACTMON block to the Tegra124 device tree.
>
> Signed-off-by: Tomeu Vizoso 
>
> ---
>
> v3: * Address misc. style issues found by Thierry and Alexander
> * Added helpers for register i/o
> * Further documented the structs
> * Enable the ACTMON after the IRQ handler has been installed
> * Disable the ACTMON before removing the IRQ handler
> * Add governor in a subsys initcall
>
> v2: * Add operating-points property
> ---
>  arch/arm/boot/dts/tegra124.dtsi|  23 +
>  drivers/devfreq/Kconfig|   7 +-
>  drivers/devfreq/Makefile   |   2 +-
>  drivers/devfreq/tegra-actmon-devfreq.c | 777 
> +
>  drivers/devfreq/tegra-devfreq.c| 718 --

In patch 2/3 you create tegra-devfreq.c, to apparently move it to
tegra-actmon-devfreq.c and (seemingly) add somemore lines to it. This
makes things difficult to review, and I am almost sure this is a
naming mistake - could you fix this and resend?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] arch: powerpc: kernel: vio.c: Remove unused function

[Michael Ellerman]

On Sun, 2014-12-07 at 23:31 +0100, Rickard Strandqvist wrote:
> Remove the function cmo_high_show() that is not used anywhere.
> 
> This was partially found by using a static code analysis program called 
> cppcheck.
> 
> Signed-off-by: Rickard Strandqvist 
> ---
>  arch/powerpc/kernel/vio.c |5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index 5bfdab9..11657d2 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1032,11 +1032,6 @@ viobus_cmo_pool_rd_attr(reserve, size);
>  viobus_cmo_pool_rd_attr(excess, size);
>  viobus_cmo_pool_rd_attr(excess, free);
>  
> -static ssize_t cmo_high_show(struct bus_type *bt, char *buf)
> -{
> - return sprintf(buf, "%lu\n", vio_cmo.high);
> -}


from ../arch/powerpc/kernel/vio.c:17:
../arch/powerpc/kernel/vio.c:1046:20: error: 'cmo_high_show' undeclared here 
(not in a function)
static BUS_ATTR_RW(cmo_high);
^
../include/linux/sysfs.h:76:10: note: in definition of macro '__ATTR'
.show = _show,  \
^
../include/linux/device.h:53:42: note: in expansion of macro '__ATTR_RW'
struct bus_attribute bus_attr_##_name = __ATTR_RW(_name)
^
../arch/powerpc/kernel/vio.c:1046:8: note: in expansion of macro 'BUS_ATTR_RW'
static BUS_ATTR_RW(cmo_high);
^

cheers


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

Re: wl1251: NVS firmware data

[Marcel Holtmann]

Hi Pali,

>> Use your own custom usermode helper for stuff like this, not
>> the firmware interface.  But use a binary sysfs file if you
>> want, that seems to make sense for it...
>> 
>> greg k-h
> 
> Patch for telling permanent mac address from userspace via sysfs 
> file was rejected for inclusion into mainline kernel.
> 
> So I do not think that now maintainers of network subsystem allow 
> it for nvs data...
> 
> https://lkml.org/lkml/2013/12/8/35

this magic sysfs that has to be written to at the right time of the boot 
process to make this all work is something that will not work. I does not work 
for WiFi and it does not work for Bluetooth. Seems the discussion come full 
circle now and we are back to square one.

The problem is that either the driver does not register the device with 
mac80211 until it gets the MAC address provided by userspace or mac80211 should 
get an unconfigured state. The unconfigured state is something telling 
userspace that the device is present, but needs a few extra configuration 
information before it can become useful.

For Bluetooth, I went the later route. Mainly because the missing address is 
such a generic problem that solving it in the core makes a lot more sense. The 
driver just tells the core that it has no address for this device and provides 
a custom callback to configure the address when provided. After that everything 
resumes as normal.

However userspace gets informed when an unconfigured device gets added and at 
boot it can just query the list of unconfigured devices, or at runtime wait to 
be told there is a new unconfigured device that needs its attention. And then 
just provide the information. Once all information are present, the devices 
disappears as unconfigured and shows up as configured device ready for normal 
operation.

https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/mgmt-api.txt#n2006
http://permalink.gmane.org/gmane.linux.bluez.kernel/50716

Can something similar be added to cfg80211 + nl80211. It bet it can, but that 
is up to Johannes to decide and someone to actually do the work and implement 
it.

Regards

Marcel

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

[PATCH V2] fix build error for vm tools

[Wang, Yalin]

This patch fix the build error when make like this:
make O=/xx/x vm

use $(OUTPUT) to generate to the right place.

Signed-off-by: Yalin Wang 
---
 tools/vm/Makefile | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/vm/Makefile b/tools/vm/Makefile
index 3d907da..2847345 100644
--- a/tools/vm/Makefile
+++ b/tools/vm/Makefile
@@ -1,22 +1,24 @@
 # Makefile for vm tools
 #
+include ../scripts/Makefile.include
 TARGETS=page-types slabinfo
 
 LIB_DIR = ../lib/api
-LIBS = $(LIB_DIR)/libapikfs.a
+LIBS = $(OUTPUT)../lib/api/libapikfs.a
 
 CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall -Wextra -I../lib/
 LDFLAGS = $(LIBS)
 
+all: $(TARGETS)
 $(TARGETS): $(LIBS)
 
 $(LIBS):
-   make -C $(LIB_DIR)
+   $(call descend,../lib/api libapikfs.a)
 
 %: %.c
-   $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS)
+   $(CC) $(CFLAGS) -o $(OUTPUT)$@ $< $(LDFLAGS)
 
 clean:
-   $(RM) page-types slabinfo
+   $(RM) $(OUTPUT)page-types $(OUTPUT)slabinfo
make -C $(LIB_DIR) clean
-- 
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: wl1251: NVS firmware data

[Marcel Holtmann]

Hi Dan,

>>> a) change driver to prefer a new "wl1251-nvs-n900.bin" file, but fall
>>> back to "wl1251-nvs.bin" if the first one isn't present
>>> b) have a "wl1251-cal-nvs-update" service that, if wl1521-nvs-n900.bin
>>> is *not* present mounts the CAL MTD, reads the data, writes it out into
>>> wl1521-nvs-n900.bin, and the rmmod/modprobes the driver
>>> 
>>> and done?  Stuff that's not N900 just wouldn't ship the update service
>>> and would proceed like none of this happened.
>>> 
>>> Dan
>>> 
>>> 
>> 
>> That would mean that the driver should not be built-in, as afaik we 
>> cannot rmmod built-in drivers. Sure, it will work after a reboot, but 
>> this is a bit hacky, agree?
>> 
>> Also, new NVS file needs to be loaded when fcc regulation changes(flying 
>> abroad), so that would mean that the device would be outside of those 
>> until reboot (in case of built-in driver)
> 
> Regulatory stuff needs to be hooked into CRDA or the existing regulatory
> codepaths, not some other path.  So when cfg80211 sets the regulatory
> domain on the driver the driver needs to get the necessary NVS data.
> Either the NVS for every domain (which cannot be a lot of them) gets
> hardcoded into the driver, and then selected based on what cfg80211
> says, or the driver needs to ask userspace for the NVS data based on
> what cfg80211 says.  In all cases, cfg80211 drives the regulatory domain
> [1].
> 
> a) How many regulatory domains does the driver support, how much data is
> there for each domain, and can that be put into the driver instead of
> getting it from the CAL partition?
> 
> b) what do *other* (non-N900) wl1251 devices do for regulatory data?
> 
> Dan
> 
> [1] unless there's some *restriction* hardcoded into the EEPROM of the
> device, which in the case of the N900 there isn't, since the regulatory
> data changes based on the MCC/MNC of the cellular side.

and even these ones would all work just fine. The regulatory handling of 
cfg80211 is already multi-layer anyway. I will intersect from the driver 
provided information and userspace provided information.

I mean if userspace can just make up some NVS data to change the regulatory 
enforcement or let cfg80211 do it for you, there is no difference. So the real 
question is why bother with this at all in the first place. We already have a 
solution that does exactly what you want. Use CRDA and be done with it.

And calibration data should be rather static for each device. It might differ 
from device a to device b, but on device a it would stay the same. These 
calibration data are normally programmed at the factory line and then never 
changed again.

For me this sounds all a bit like that everybody is buying into this NVS file 
solution for everything and now trying to hack that into something workable. 
But nobody actually looks at the existing solutions out there and really tries 
to fix the mess that Nokia and TI left behind for this chipset.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] blk-mq: prevent unmapped hw queue from being scheduled

[Ming Lei]

On Tue, Dec 9, 2014 at 12:39 PM, Jens Axboe  wrote:
> On 12/08/2014 05:41 PM, Ming Lei wrote:
>
>
> Picked up for 3.19, sorry for the delay. I'm curious how this queue gets

Thanks!

> scheduled, though. My worry here would be that we are masking a bug that
> should be fixed separately.

That is because the schedule unit of following interfaces is
per request_queue, and they are easily used in drivers now:

   blk_mq_start_hw_queues()
   blk_mq_start_stopped_hw_queues()
   blk_mq_kick_requeue_list().

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

Re: [GIT PULL] hwmon updates for 3.19

[Guenter Roeck]

On 12/08/2014 08:32 PM, Linus Torvalds wrote:

On Mon, Dec 8, 2014 at 8:01 PM, Guenter Roeck  wrote:


Please pull hwmon updates for Linux 3.19 from signed tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-linus-v3.19


Yeah, no, that doesn't exist.

But this does:


   git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-linus-3.19


Notice the 'v' (or lack-there-of). It took me a while to notice that
your two tag-names weren't actually the same.



Oh well. Sorry for that. The tag _was_ supposed to have a 'v' in it.
I see you pulled anyway - thanks.

And I owe you a beer or two next time I see you.

Guenter

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

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

[Vinod Koul]

On Tue, Dec 09, 2014 at 02:48:17PM +1100, Stephen Rothwell wrote:
> Hi Vinod,
> 
> After merging the slave-dma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
I did merge the next-20141208 wth this new code and pushed. Found and
resolved the same merg conflict as you :) Feng'd bot didn't
find any issues, so am wondering why :)

Neverthless, I am dropping these changes from next.

Thanks for reporting them

> drivers/spi/spi-atmel.c: In function 'atmel_spi_stop_dma':
> drivers/spi/spi-atmel.c:485:26: error: 'struct dma_device' has no member 
> named 'device_control'
>as->dma.chan_rx->device->device_control(as->dma.chan_rx,
>   ^
> drivers/spi/spi-atmel.c:486:8: error: 'DMA_TERMINATE_ALL' undeclared (first 
> use in this function)
> DMA_TERMINATE_ALL, 0);
> ^
> drivers/spi/spi-atmel.c:486:8: note: each undeclared identifier is reported 
> only once for each function it appears in
> drivers/spi/spi-atmel.c:488:26: error: 'struct dma_device' has no member 
> named 'device_control'
>as->dma.chan_tx->device->device_control(as->dma.chan_tx,
>   ^
> drivers/usb/musb/ux500_dma.c: In function 'ux500_configure_channel':
> drivers/usb/musb/ux500_dma.c:124:18: error: 'struct dma_device' has no member 
> named 'device_control'
>   dma_chan->device->device_control(dma_chan, DMA_SLAVE_CONFIG,
>   ^
> drivers/usb/musb/ux500_dma.c:124:45: error: 'DMA_SLAVE_CONFIG' undeclared 
> (first use in this function)
>   dma_chan->device->device_control(dma_chan, DMA_SLAVE_CONFIG,
>  ^
> drivers/usb/musb/ux500_dma.c:124:45: note: each undeclared identifier is 
> reported only once for each function it appears in
> drivers/usb/musb/ux500_dma.c: In function 'ux500_dma_channel_abort':
> drivers/usb/musb/ux500_dma.c:249:34: error: 'struct dma_device' has no member 
> named 'device_control'
>ux500_channel->dma_chan->device->
>   ^
> drivers/usb/musb/ux500_dma.c:251:6: error: 'DMA_TERMINATE_ALL' undeclared 
> (first use in this function)
>   DMA_TERMINATE_ALL, 0);
>   ^
> 
> Caused by commit f86999789afe ("dmaengine: Remove device_control and
> device_slave_caps").
> 
> I have used the slave-dma tree from next-20141208 for today.

-- 
~Vinod


signature.asc
Description: Digital signature

Re: [PATCH v5 00/61] dmaengine: Implement generic slave capabilities retrieval

[Vinod Koul]

On Mon, Dec 08, 2014 at 07:38:53PM +0100, Maxime Ripard wrote:
> On Mon, Dec 08, 2014 at 09:58:43PM +0530, Vinod Koul wrote:
> I totally understand your point. And I actually am a bit uncomfortable
> merging this so late too, and I'd actually prefer to have it merged
> for 3.20. But this is a huge patchset, and I'd really like to avoid
> rebasing it forever.
> 
> I'll send a v6, with your patches, as soon as 3.19-rc1 is out. This
> will be my last rebase of this serie. If these patches are not merged
> then, then I will just give up on this cleanup, and probably any
> subsequent ones.
Since I have applied them to a topic branch, I don't think we you to rebase
and resend. Git does a pretty good job at rebasing so I will rebase
this branch on top of -rc1 and merge. Fixes can keep coming on top of this
one.

So these patches are applied, and will show up in -next after -rc1. Thank
you for the work you put in this.

Last night, I thought of giving it a try so temporarily merged this to my
next. SFR found bunch of issues with it (mostly due to dependencies in
users) so lets keep fixing those..

-- 
~Vinod



signature.asc
Description: Digital signature

Re: [PATCH] blk-mq: prevent unmapped hw queue from being scheduled

[Jens Axboe]

On 12/08/2014 05:41 PM, Ming Lei wrote:

On Wed, Dec 3, 2014 at 7:38 PM, Ming Lei  wrote:

When one hardware queue has no mapped software queues, it
shouldn't have been scheduled. Otherwise WARNING or OOPS
can triggered.

blk_mq_hw_queue_mapped() helper is introduce for fixing
the problem.

Signed-off-by: Ming Lei 
---
  block/blk-mq.c |8 ++--
  block/blk-mq.h |5 +
  2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index c95abc6..c916ad0 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -599,7 +599,7 @@ static void blk_mq_rq_timer(unsigned long priv)
  * If not software queues are currently mapped to this
  * hardware queue, there's nothing to check
  */
-   if (!hctx->nr_ctx || !hctx->tags)
+   if (!blk_mq_hw_queue_mapped(hctx))
 continue;

 blk_mq_tag_busy_iter(hctx, blk_mq_check_expired, );
@@ -819,7 +819,8 @@ static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx *hctx)

  void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async)
  {
-   if (unlikely(test_bit(BLK_MQ_S_STOPPED, >state)))
+   if (unlikely(test_bit(BLK_MQ_S_STOPPED, >state) ||
+   !blk_mq_hw_queue_mapped(hctx)))
 return;

 if (!async) {
@@ -926,6 +927,9 @@ static void blk_mq_delay_work_fn(struct work_struct *work)

  void blk_mq_delay_queue(struct blk_mq_hw_ctx *hctx, unsigned long msecs)
  {
+   if (unlikely(!blk_mq_hw_queue_mapped(hctx)))
+   return;
+
 kblockd_schedule_delayed_work_on(blk_mq_hctx_next_cpu(hctx),
 >delay_work, msecs_to_jiffies(msecs));
  }
diff --git a/block/blk-mq.h b/block/blk-mq.h
index d567d52..206230e 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -115,4 +115,9 @@ static inline void blk_mq_set_alloc_data(struct 
blk_mq_alloc_data *data,
 data->hctx = hctx;
  }

+static inline bool blk_mq_hw_queue_mapped(struct blk_mq_hw_ctx *hctx)
+{
+   return hctx->nr_ctx && hctx->tags;
+}
+
  #endif


Gentle ping...


Picked up for 3.19, sorry for the delay. I'm curious how this queue gets 
scheduled, though. My worry here would be that we are masking a bug that 
should be fixed separately.


--
Jens Axboe

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

Re: [GIT PULL] hwmon updates for 3.19

[Stephen Rothwell]

Hi Guenter,

On Mon,  8 Dec 2014 20:01:44 -0800 Guenter Roeck  wrote:
>
> Please pull hwmon updates for Linux 3.19 from signed tag:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> hwmon-for-linus-v3.19

This does not match

> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> tags/hwmon-for-linus-3.19

this ('v' difference - the latter exists) ...

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


pgpGrW34wIah4.pgp
Description: OpenPGP digital signature

Re: [GIT PULL] hwmon updates for 3.19

[Linus Torvalds]

On Mon, Dec 8, 2014 at 8:01 PM, Guenter Roeck  wrote:
>
> Please pull hwmon updates for Linux 3.19 from signed tag:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> hwmon-for-linus-v3.19

Yeah, no, that doesn't exist.

But this does:

>   git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> tags/hwmon-for-linus-3.19

Notice the 'v' (or lack-there-of). It took me a while to notice that
your two tag-names weren't actually the same.

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

[Resend PATCH v4 3/5] usb: dwc2: add generic PHY

[Yunzhi Li]

Get PHY parameters from devicetree and power off usb PHY during
system suspend.

Signed-off-by: Yunzhi Li 
Acked-by: Paul Zimmerman 

---
Hi Felipe,
Sorry for my mistake, I have fixed the commit log.

Changes in v4: None
Changes in v3:
- Fix coding style: both branches of the if() which only one
  branch of the conditional statement is a single statement
  should have braces.
- No need to test dwc2->phy for NULL before calling generic phy
  APIs.

 drivers/usb/dwc2/gadget.c   | 33 -
 drivers/usb/dwc2/platform.c | 36 ++--
 2 files changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..2601c61 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
 {
struct device *dev = hsotg->dev;
struct s3c_hsotg_plat *plat = dev->platform_data;
-   struct phy *phy;
-   struct usb_phy *uphy;
struct s3c_hsotg_ep *eps;
int epnum;
int ret;
@@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
hsotg->phyif = GUSBCFG_PHYIF16;
 
/*
-* Attempt to find a generic PHY, then look for an old style
-* USB PHY, finally fall back to pdata
+* If platform probe couldn't find a generic PHY or an old style
+* USB PHY, fall back to pdata
 */
-   phy = devm_phy_get(dev, "usb2-phy");
-   if (IS_ERR(phy)) {
-   uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(uphy)) {
-   /* Fallback for pdata */
-   plat = dev_get_platdata(dev);
-   if (!plat) {
-   dev_err(dev,
-   "no platform data or transceiver defined\n");
-   return -EPROBE_DEFER;
-   }
-   hsotg->plat = plat;
-   } else
-   hsotg->uphy = uphy;
-   } else {
-   hsotg->phy = phy;
+   if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
+   plat = dev_get_platdata(dev);
+   if (!plat) {
+   dev_err(dev,
+   "no platform data or transceiver defined\n");
+   return -EPROBE_DEFER;
+   }
+   hsotg->plat = plat;
+   } else if (hsotg->phy) {
/*
 * If using the generic PHY framework, check if the PHY bus
 * width is 8-bit and set the phyif appropriately.
 */
-   if (phy_get_bus_width(phy) == 8)
+   if (phy_get_bus_width(hsotg->phy) == 8)
hsotg->phyif = GUSBCFG_PHYIF8;
}
 
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa..ae095f0 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
struct dwc2_core_params defparams;
struct dwc2_hsotg *hsotg;
struct resource *res;
+   struct phy *phy;
+   struct usb_phy *uphy;
int retval;
int irq;
 
@@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
 
hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
 
+   /*
+* Attempt to find a generic PHY, then look for an old style
+* USB PHY
+*/
+   phy = devm_phy_get(>dev, "usb2-phy");
+   if (IS_ERR(phy)) {
+   hsotg->phy = NULL;
+   uphy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(uphy))
+   hsotg->uphy = NULL;
+   else
+   hsotg->uphy = uphy;
+   } else {
+   hsotg->phy = phy;
+   phy_power_on(hsotg->phy);
+   phy_init(hsotg->phy);
+   }
+
spin_lock_init(>lock);
mutex_init(>init_mutex);
retval = dwc2_gadget_init(hsotg, irq);
@@ -231,8 +251,15 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
 
-   if (dwc2_is_device_mode(dwc2))
+   if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_suspend(dwc2);
+   } else {
+   if (dwc2->lx_state == DWC2_L0)
+   return 0;
+   phy_exit(dwc2->phy);
+   phy_power_off(dwc2->phy);
+
+   }
return ret;
 }
 
@@ -241,8 +268,13 @@ static int __maybe_unused dwc2_resume(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
 
-   if (dwc2_is_device_mode(dwc2))
+   if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_resume(dwc2);
+   } else {
+  

Re: wl1251: NVS firmware data

[Greg Kroah-Hartman]

On Tue, Dec 09, 2014 at 08:48:28AM +0800, Ming Lei wrote:
> On Tue, Dec 9, 2014 at 4:57 AM, Greg Kroah-Hartman
>  wrote:
> > On Mon, Dec 08, 2014 at 05:47:30PM +0100, Pali Rohár wrote:
> >> On Monday 08 December 2014 17:37:14 Greg Kroah-Hartman wrote:
> >> > On Mon, Dec 08, 2014 at 11:18:18PM +0800, Ming Lei wrote:
> >> > > On Sat, Dec 6, 2014 at 9:02 PM, Pali Rohár
> >>  wrote:
> >> > > > On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
> >> > > >  /**
> >> > > >
> >> > > > + * request_firmware_prefer_user: - prefer usermode helper
> >> > > > for loading firmware + * @firmware_p: pointer to firmware
> >> > > > image
> >> > > > + * @name: name of firmware file
> >> > > > + * @device: device for which firmware is being loaded
> >> > > > + *
> >> > > > + * This function works pretty much like
> >> > > > request_firmware(), but it prefer + * usermode helper. If
> >> > > > usermode helper fails then it fallback to direct access.
> >> > > > + * Usefull for dynamic or model specific firmware data.
> >> > > > + **/
> >> > > > +int request_firmware_prefer_user(const struct firmware
> >> > > > **firmware_p, +   const char
> >> > > > *name, struct device *device) +{
> >> > > > +   int ret;
> >> > > > +   __module_get(THIS_MODULE);
> >> > > > +   ret = _request_firmware(firmware_p, name, device,
> >> > > > +   FW_OPT_UEVENT |
> >> > > > FW_OPT_PREFER_USER); +   module_put(THIS_MODULE);
> >> > > > +   return ret;
> >> > > > +}
> >> > > > +EXPORT_SYMBOL_GPL(request_firmware_prefer_user);
> >> > >
> >> > > I'd like to introduce request_firmware_user() which only
> >> > > requests firmware from user space, and this way is simpler
> >> > > and more flexible since we have request_firmware_direct()
> >> > > already.
> >> >
> >> > Why would a driver care about what program provides the
> >> > firmware?  It shouldn't at all, and we want to get rid of the
> >> > userspace firmware loader, not encourage drivers to use it
> >> > "exclusively" at all.
> >> >
> >>
> >> Do not remove it! Without userspace firmware loader it is
> >> impossible to load dynamic firmware files.
> >
> > You should not be loading "dynamic" firmware files with the firmware
> > interface, as that's not a "firmware" file anymore, it's a "special
> > binary file that my driver needs to be created and sent into the
> > kernel."
> 
> It is reasonable to put firmware somewhere instead of default
> search path, maybe in network.

That's why we allow you to change the firmware search path at build
time, and kernel boot time (or firmware class module load time.)  To do
this on a per-firmware-file basis is crazy.

thanks,

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

Re: [GIT PULL] MFD for v3.19

[Linus Torvalds]

On Mon, Dec 8, 2014 at 4:00 AM, Lee Jones  wrote:
>
> Johan Hovold (4):
>   mfd: Use mfd_add_hotplug_devices() helper

This clashed with the earlier fix "mfd: viperboard: Fix
platform-device id collision" also by Johan.

My merge resolution ends up taking the mfd_add_hotplug_devices() version.

See drivers/mfd/viperboard.c, and somebody should double-check and
test that this actually works. The "Fix platform-device id collision"
commit supposedly fixed a problem with multiple boards, I'm
hoping/assuming that the mfd_add_hotplug_devices() helper handles that
case correctly.

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

[GIT PULL] hwmon updates for 3.19

[Guenter Roeck]

Hi Linus,

Please pull hwmon updates for Linux 3.19 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hwmon-for-linus-v3.19

Thanks,
Guenter
--

The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a:

  Linux 3.18-rc7 (2014-11-30 16:42:27 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hwmon-for-linus-3.19

for you to fetch changes up to 907a6d5824599d09e986105a5a880d119a996c4b:

  hwmon: (tmp401) Detect TMP435 on all addresses it supports (2014-12-08 
06:48:37 -0800)


Notable changes:
New driver for NCT7802Y
Add support for TMP435, LM95233, LM95235, NCT6792D, and NXP LM75B
Add regulator support for PMBus chips, specifically LTX2978
Add support for humidity sensors to iio-hwmon bridge driver


Alan Tull (4):
  hwmon: (ltc2978) device tree bindings documentation
  hwmon: (pmbus) add helpers for byte write and read modify write
  hwmon: (pmbus) Add regulator support
  hwmon: (ltc2978) Add regulator support

Axel Lin (1):
  hwmon: (ibmpowernv) Convert to module_platform_driver

Bartosz Golaszewski (2):
  hwmon: (ina2xx) bail-out from ina2xx_probe() in case of configuration 
errors
  hwmon: (tmp401) Bail out from tmp401_probe() in case of write errors

Guenter Roeck (9):
  hwmon: (iio_hwmon) Add support for humidity sensors
  hwmon: Driver for Nuvoton NCT7802Y
  hwmon: (nct6775) Documentation updates
  hwmon: (nct6775) Add support for NCT6792D
  hwmon: (nct6775) Add blank lines after declarations
  hwmon: (lm95245) Add support for LM95235
  hwmon: (lm95234) Add support for LM95233
  hwmon: (lm75) Strengthen detect function
  hwmon: (tmp401) Detect TMP435 on all addresses it supports

Michael Thalmeier (1):
  hwmon: (lm75) Add support for the NXP LM75B

Neelesh Gupta (1):
  hwmon: (ibmpowernv) Use platform 'id_table' to probe the device

Nishanth Menon (2):
  hwmon: (gpio-fan) Allow usage of gpio operations that may sleep
  hwmon: (gpio-fan) Add a shutdown handler to poweroff the fans

Patrick Titiano (1):
  hwmon: (tmp401) Add support for TI TMP435

 .../devicetree/bindings/hwmon/ltc2978.txt  |  39 +
 Documentation/hwmon/lm75   |   5 +
 Documentation/hwmon/lm95234|  15 +-
 Documentation/hwmon/lm95245|  14 +-
 Documentation/hwmon/nct6775|  14 +-
 Documentation/hwmon/nct7802|  32 +
 Documentation/hwmon/tmp401 |   8 +-
 arch/powerpc/platforms/powernv/opal-sensor.c   |  20 +
 drivers/hwmon/Kconfig  |  28 +-
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/gpio-fan.c   |  18 +-
 drivers/hwmon/ibmpowernv.c |  78 +-
 drivers/hwmon/iio_hwmon.c  |   7 +-
 drivers/hwmon/ina2xx.c |  26 +-
 drivers/hwmon/lm75.c   |  12 +
 drivers/hwmon/lm95234.c|  91 ++-
 drivers/hwmon/lm95245.c|  41 +-
 drivers/hwmon/nct6775.c|  77 +-
 drivers/hwmon/nct7802.c| 860 +
 drivers/hwmon/pmbus/Kconfig|  11 +-
 drivers/hwmon/pmbus/ltc2978.c  |  39 +-
 drivers/hwmon/pmbus/pmbus.h|  30 +
 drivers/hwmon/pmbus/pmbus_core.c   | 118 +++
 drivers/hwmon/tmp401.c |  42 +-
 include/linux/i2c/pmbus.h  |   4 +
 25 files changed, 1465 insertions(+), 165 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwmon/ltc2978.txt
 create mode 100644 Documentation/hwmon/nct7802
 create mode 100644 drivers/hwmon/nct7802.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the slave-dma tree

[Stephen Rothwell]

Hi Vinod,

After merging the slave-dma tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/spi/spi-atmel.c: In function 'atmel_spi_stop_dma':
drivers/spi/spi-atmel.c:485:26: error: 'struct dma_device' has no member named 
'device_control'
   as->dma.chan_rx->device->device_control(as->dma.chan_rx,
  ^
drivers/spi/spi-atmel.c:486:8: error: 'DMA_TERMINATE_ALL' undeclared (first use 
in this function)
DMA_TERMINATE_ALL, 0);
^
drivers/spi/spi-atmel.c:486:8: note: each undeclared identifier is reported 
only once for each function it appears in
drivers/spi/spi-atmel.c:488:26: error: 'struct dma_device' has no member named 
'device_control'
   as->dma.chan_tx->device->device_control(as->dma.chan_tx,
  ^
drivers/usb/musb/ux500_dma.c: In function 'ux500_configure_channel':
drivers/usb/musb/ux500_dma.c:124:18: error: 'struct dma_device' has no member 
named 'device_control'
  dma_chan->device->device_control(dma_chan, DMA_SLAVE_CONFIG,
  ^
drivers/usb/musb/ux500_dma.c:124:45: error: 'DMA_SLAVE_CONFIG' undeclared 
(first use in this function)
  dma_chan->device->device_control(dma_chan, DMA_SLAVE_CONFIG,
 ^
drivers/usb/musb/ux500_dma.c:124:45: note: each undeclared identifier is 
reported only once for each function it appears in
drivers/usb/musb/ux500_dma.c: In function 'ux500_dma_channel_abort':
drivers/usb/musb/ux500_dma.c:249:34: error: 'struct dma_device' has no member 
named 'device_control'
   ux500_channel->dma_chan->device->
  ^
drivers/usb/musb/ux500_dma.c:251:6: error: 'DMA_TERMINATE_ALL' undeclared 
(first use in this function)
  DMA_TERMINATE_ALL, 0);
  ^

Caused by commit f86999789afe ("dmaengine: Remove device_control and
device_slave_caps").

I have used the slave-dma tree from next-20141208 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp2xy8IjgAZc.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.

[Felipe Balbi]

On Tue, Dec 09, 2014 at 10:50:27AM +0800, Yunzhi Li wrote:
> Get PHY parameters from devicetree and power off usb PHY during
> system suspend.
> 
> Signed-off-by: Yunzhi Li 
> 
> Acked-by: Paul Zimmerman 
> 
> Changes in v3:
> - Fix coding style: both branches of the if() which only one
>   branch of the conditional statement is a single statement
>   should have braces.
> - No need to test dwc2->phy for NULL before calling generic phy
>   APIs.

please fix your commit log. Hint: try saving the patch from mailing list
and applying it with git am to another branch.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] fix build error for vm tools

[Wang, Yalin]

This patch fix the build error when make like this:
make O=/xx/x vm

use $(OUTPUT) to generate to the right place.

Signed-off-by: Yalin Wang 
---
 tools/vm/Makefile | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/vm/Makefile b/tools/vm/Makefile
index 3d907da..28d4bd9 100644
--- a/tools/vm/Makefile
+++ b/tools/vm/Makefile
@@ -1,9 +1,10 @@
 # Makefile for vm tools
 #
+include ../scripts/Makefile.include
 TARGETS=page-types slabinfo
 
 LIB_DIR = ../lib/api
-LIBS = $(LIB_DIR)/libapikfs.a
+LIBS = $(OUTPUT)../lib/api/libapikfs.a
 
 CC = $(CROSS_COMPILE)gcc
 CFLAGS = -Wall -Wextra -I../lib/
@@ -12,11 +13,11 @@ LDFLAGS = $(LIBS)
 $(TARGETS): $(LIBS)
 
 $(LIBS):
-   make -C $(LIB_DIR)
+   $(call descend,../lib/api libapikfs.a)
 
 %: %.c
-   $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS)
+   $(CC) $(CFLAGS) -o $(OUTPUT)$@ $< $(LDFLAGS)
 
 clean:
-   $(RM) page-types slabinfo
+   $(RM) $(OUTPUT)page-types $(OUTPUT)slabinfo
make -C $(LIB_DIR) clean
-- 
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2] x86/mm: Fix zone ranges boot printout

[Xishi Qiu]

Changelog:
V2:
-fix building warnings of min(...).

This is the usual physical memory layout boot printout:
...
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x]
[0.00]   Normal   [mem 0x1-0xc3fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x00099fff]
[0.00]   node   0: [mem 0x0010-0xbf78]
[0.00]   node   0: [mem 0x1-0x63fff]
[0.00]   node   1: [mem 0x64000-0xc3fff]
...

This is the log when we set "mem=2G" on the boot cmdline:
...
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x]  // should be 0x7fff, 
right?
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x00099fff]
[0.00]   node   0: [mem 0x0010-0x7fff]
...

This patch fixes the printout, the following log shows the right ranges:
...
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   DMA32[mem 0x0100-0x7fff]
[0.00]   Normal   empty
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x00099fff]
[0.00]   node   0: [mem 0x0010-0x7fff]
...

Signed-off-by: Xishi Qiu 
---
 arch/x86/mm/init.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 66dba36..963945d 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -674,10 +674,12 @@ void __init zone_sizes_init(void)
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
 
 #ifdef CONFIG_ZONE_DMA
-   max_zone_pfns[ZONE_DMA] = MAX_DMA_PFN;
+   max_zone_pfns[ZONE_DMA] = min_t(unsigned long,
+   max_low_pfn, MAX_DMA_PFN);
 #endif
 #ifdef CONFIG_ZONE_DMA32
-   max_zone_pfns[ZONE_DMA32]   = MAX_DMA32_PFN;
+   max_zone_pfns[ZONE_DMA32]   = min_t(unsigned long,
+   max_low_pfn, MAX_DMA32_PFN);
 #endif
max_zone_pfns[ZONE_NORMAL]  = max_low_pfn;
 #ifdef CONFIG_HIGHMEM
-- 
2.0.0


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

[RFC V5] mm:add KPF_ZERO_PAGE flag for /proc/kpageflags

[Wang, Yalin]

This patch add KPF_ZERO_PAGE flag for zero_page,
so that userspace process can notice zero_page from
/proc/kpageflags, and then do memory analysis more accurately.

Signed-off-by: Yalin Wang 
---
 Documentation/vm/pagemap.txt   |  8 
 fs/proc/page.c | 16 +---
 include/linux/huge_mm.h| 12 
 include/uapi/linux/kernel-page-flags.h |  1 +
 mm/huge_memory.c   |  7 +--
 tools/vm/page-types.c  |  1 +
 6 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
index 5948e45..6fbd55e 100644
--- a/Documentation/vm/pagemap.txt
+++ b/Documentation/vm/pagemap.txt
@@ -62,6 +62,8 @@ There are three components to pagemap:
 20. NOPAGE
 21. KSM
 22. THP
+23. BALLOON
+24. ZERO_PAGE
 
 Short descriptions to the page flags:
 
@@ -102,6 +104,12 @@ Short descriptions to the page flags:
 22. THP
 contiguous pages which construct transparent hugepages
 
+23. BALLOON
+balloon compaction page
+
+24. ZERO_PAGE
+zero page for pfn_zero or huge_zero page
+
 [IO related page flags]
  1. ERROR IO error occurred
  3. UPTODATE  page has up-to-date data
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 1e3187d..7eee2d8 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -121,9 +122,18 @@ u64 stable_page_flags(struct page *page)
 * just checks PG_head/PG_tail, so we need to check PageLRU/PageAnon
 * to make sure a given page is a thp, not a non-huge compound page.
 */
-   else if (PageTransCompound(page) && (PageLRU(compound_head(page)) ||
-PageAnon(compound_head(page
-   u |= 1 << KPF_THP;
+   else if (PageTransCompound(page)) {
+   struct page *head = compound_head(page);
+
+   if (PageLRU(head) || PageAnon(head))
+   u |= 1 << KPF_THP;
+   else if (is_huge_zero_page(head)) {
+   u |= 1 << KPF_ZERO_PAGE;
+   u |= 1 << KPF_THP;
+   }
+   } else if (is_zero_pfn(page_to_pfn(page)))
+   u |= 1 << KPF_ZERO_PAGE;
+
 
/*
 * Caveats on high order pages: page->_count will only be set
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index ad9051b..f10b20f 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -157,6 +157,13 @@ static inline int hpage_nr_pages(struct page *page)
 extern int do_huge_pmd_numa_page(struct mm_struct *mm, struct vm_area_struct 
*vma,
unsigned long addr, pmd_t pmd, pmd_t *pmdp);
 
+extern struct page *huge_zero_page;
+
+static inline bool is_huge_zero_page(struct page *page)
+{
+   return ACCESS_ONCE(huge_zero_page) == page;
+}
+
 #else /* CONFIG_TRANSPARENT_HUGEPAGE */
 #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
 #define HPAGE_PMD_MASK ({ BUILD_BUG(); 0; })
@@ -206,6 +213,11 @@ static inline int do_huge_pmd_numa_page(struct mm_struct 
*mm, struct vm_area_str
return 0;
 }
 
+static inline bool is_huge_zero_page(struct page *page)
+{
+   return false;
+}
+
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 #endif /* _LINUX_HUGE_MM_H */
diff --git a/include/uapi/linux/kernel-page-flags.h 
b/include/uapi/linux/kernel-page-flags.h
index 2f96d23..a6c4962 100644
--- a/include/uapi/linux/kernel-page-flags.h
+++ b/include/uapi/linux/kernel-page-flags.h
@@ -32,6 +32,7 @@
 #define KPF_KSM21
 #define KPF_THP22
 #define KPF_BALLOON23
+#define KPF_ZERO_PAGE  24
 
 
 #endif /* _UAPILINUX_KERNEL_PAGE_FLAGS_H */
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index de98415..d7bc7a5 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -171,12 +171,7 @@ static int start_khugepaged(void)
 }
 
 static atomic_t huge_zero_refcount;
-static struct page *huge_zero_page __read_mostly;
-
-static inline bool is_huge_zero_page(struct page *page)
-{
-   return ACCESS_ONCE(huge_zero_page) == page;
-}
+struct page *huge_zero_page __read_mostly;
 
 static inline bool is_huge_zero_pmd(pmd_t pmd)
 {
diff --git a/tools/vm/page-types.c b/tools/vm/page-types.c
index 264fbc2..8bdf16b 100644
--- a/tools/vm/page-types.c
+++ b/tools/vm/page-types.c
@@ -133,6 +133,7 @@ static const char * const page_flag_names[] = {
[KPF_KSM]   = "x:ksm",
[KPF_THP]   = "t:thp",
[KPF_BALLOON]   = "o:balloon",
+   [KPF_ZERO_PAGE] = "z:zero_page",
 
[KPF_RESERVED]  = "r:reserved",
[KPF_MLOCKED]   = "m:mlocked",
-- 
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH V3] mm:add VM_BUG_ON_PAGE() for page_mapcount()

[Hillf Danton]

> 
> This patch add VM_BUG_ON_PAGE() for slab page,
> because _mapcount is an union with slab struct in struct page,
> avoid access _mapcount if this page is a slab page.
> Also remove the unneeded bracket.
> 
> Signed-off-by: Yalin Wang 
> ---
Acked-by: Hillf Danton 

>  include/linux/mm.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b464611..a117527 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -449,7 +449,8 @@ static inline void page_mapcount_reset(struct page *page)
> 
>  static inline int page_mapcount(struct page *page)
>  {
> - return atomic_read(&(page)->_mapcount) + 1;
> + VM_BUG_ON_PAGE(PageSlab(page), page);
> + return atomic_read(>_mapcount) + 1;
>  }
> 
>  static inline int page_count(struct page *page)
> --
> 2.1.3

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

Re: [RFC PATCH 3/3] mm: always steal split buddies in fallback allocations

[Minchan Kim]

On Thu, Dec 04, 2014 at 06:12:58PM +0100, Vlastimil Babka wrote:
> When allocation falls back to another migratetype, it will steal a page with
> highest available order, and (depending on this order and desired 
> migratetype),
> it might also steal the rest of free pages from the same pageblock.
> 
> Given the preference of highest available order, it is likely that it will be
> higher than the desired order, and result in the stolen buddy page being 
> split.
> The remaining pages after split are currently stolen only when the rest of the
> free pages are stolen. This can however lead to situations where for MOVABLE
> allocations we split e.g. order-4 fallback UNMOVABLE page, but steal only
> order-0 page. Then on the next MOVABLE allocation (which may be batched to
> fill the pcplists) we split another order-3 or higher page, etc. By stealing
> all pages that we have split, we can avoid further stealing.
> 
> This patch therefore adjust the page stealing so that buddy pages created by
> split are always stolen. This has effect only on MOVABLE allocations, as
> RECLAIMABLE and UNMOVABLE allocations already always do that in addition to
> stealing the rest of free pages from the pageblock.
> 
> Note that commit 7118af076f6 ("mm: mmzone: MIGRATE_CMA migration type added")
> has already performed this change (unintentinally), but was reverted by commit
> 0cbef29a7821 ("mm: __rmqueue_fallback() should respect pageblock type").
> Neither included evaluation. My evaluation with stress-highalloc from mmtests
> shows about 2.5x reduction of page stealing events for MOVABLE allocations,
> without affecting the page stealing events for other allocation migratetypes.
> 
> Signed-off-by: Vlastimil Babka 
Acked-by: Minchan Kim 

Nit:

>From this patch, try_to_steal_freepages always return start_type excpet CMA
case so we could factor CMA case out in try_to_steal_freepages and put the
check right before calling try_to_steal_freepages.

The benefit are we could make try_to_steal_freepages's return type as void
and we could remove fallback_type argument(ie, make the function simple).
Additionally, we could move set_freepage_migratetype into
try_to_steal_freepages so that we could remove new_type variable
in __rmqueue_fallback.

trace_mm_page_alloc_extfrag could work without new_type using
get_pageblock_migratetype.

Thanks.

> ---
>  mm/page_alloc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a14249c..82096a6 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1108,11 +1108,9 @@ static int try_to_steal_freepages(struct zone *zone, 
> struct page *page,
>   if (pages >= (1 << (pageblock_order-1)) ||
>   page_group_by_mobility_disabled)
>   set_pageblock_migratetype(page, start_type);
> -
> - return start_type;
>   }
>  
> - return fallback_type;
> + return start_type;
>  }
>  
>  /* Remove an element from the buddy allocator from the fallback list */
> -- 
> 2.1.2
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

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

linux-next: manual merge of the slave-dma tree with the arm tree

[Stephen Rothwell]

Hi Vinod,

Today's linux-next merge of the slave-dma tree got a conflict in
drivers/dma/pl330.c between commits ae43b3289186 ("ARM: 8202/1:
dmaengine: pl330: Add runtime Power Management support v12") and
b816ccc5c01f ("ARM: 8206/1: dmaengine: pl330: Add PM sleep support")
from the arm tree and commits 86e15941d3f5 ("dmaengine: pl330: Split
device_control") and c9a09dacf851 ("dmaengine: pl330: Declare slave
capabilities for the generic code") from the slave-dma tree.

I fixed it up (hopefully - see below) and can carry the fix as
necessary (no action is required).

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

diff --cc drivers/dma/pl330.c
index ca1566045ca4,b8470c11..
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@@ -2092,71 -2092,38 +2116,44 @@@ static int pl330_terminate_all(struct d
struct dma_pl330_desc *desc;
unsigned long flags;
struct pl330_dmac *pl330 = pch->dmac;
-   struct dma_slave_config *slave_config;
LIST_HEAD(list);
  
-   switch (cmd) {
-   case DMA_TERMINATE_ALL:
-   pm_runtime_get_sync(pl330->ddma.dev);
-   spin_lock_irqsave(>lock, flags);
++  pm_runtime_get_sync(pl330->ddma.dev);
+   spin_lock_irqsave(>lock, flags);
  
-   spin_lock(>lock);
-   _stop(pch->thread);
-   spin_unlock(>lock);
+   spin_lock(>lock);
+   _stop(pch->thread);
+   spin_unlock(>lock);
  
-   pch->thread->req[0].desc = NULL;
-   pch->thread->req[1].desc = NULL;
-   pch->thread->req_running = -1;
+   pch->thread->req[0].desc = NULL;
+   pch->thread->req[1].desc = NULL;
+   pch->thread->req_running = -1;
  
-   /* Mark all desc done */
-   list_for_each_entry(desc, >submitted_list, node) {
-   desc->status = FREE;
-   dma_cookie_complete(>txd);
-   }
+   /* Mark all desc done */
+   list_for_each_entry(desc, >submitted_list, node) {
+   desc->status = FREE;
+   dma_cookie_complete(>txd);
+   }
  
-   list_for_each_entry(desc, >work_list , node) {
-   desc->status = FREE;
-   dma_cookie_complete(>txd);
-   }
+   list_for_each_entry(desc, >work_list , node) {
+   desc->status = FREE;
+   dma_cookie_complete(>txd);
+   }
  
-   list_for_each_entry(desc, >completed_list , node) {
-   desc->status = FREE;
-   dma_cookie_complete(>txd);
-   }
+   list_for_each_entry(desc, >completed_list , node) {
+   desc->status = FREE;
+   dma_cookie_complete(>txd);
+   }
  
-   if (!list_empty(>work_list))
-   pm_runtime_put(pl330->ddma.dev);
++  if (!list_empty(>work_list))
++  pm_runtime_put(pl330->ddma.dev);
 +
-   list_splice_tail_init(>submitted_list, >desc_pool);
-   list_splice_tail_init(>work_list, >desc_pool);
-   list_splice_tail_init(>completed_list, >desc_pool);
-   spin_unlock_irqrestore(>lock, flags);
-   pm_runtime_mark_last_busy(pl330->ddma.dev);
-   pm_runtime_put_autosuspend(pl330->ddma.dev);
-   break;
-   case DMA_SLAVE_CONFIG:
-   slave_config = (struct dma_slave_config *)arg;
- 
-   if (slave_config->direction == DMA_MEM_TO_DEV) {
-   if (slave_config->dst_addr)
-   pch->fifo_addr = slave_config->dst_addr;
-   if (slave_config->dst_addr_width)
-   pch->burst_sz = 
__ffs(slave_config->dst_addr_width);
-   if (slave_config->dst_maxburst)
-   pch->burst_len = slave_config->dst_maxburst;
-   } else if (slave_config->direction == DMA_DEV_TO_MEM) {
-   if (slave_config->src_addr)
-   pch->fifo_addr = slave_config->src_addr;
-   if (slave_config->src_addr_width)
-   pch->burst_sz = 
__ffs(slave_config->src_addr_width);
-   if (slave_config->src_maxburst)
-   pch->burst_len = slave_config->src_maxburst;
-   }
-   break;
-   default:
-   dev_err(pch->dmac->ddma.dev, "Not supported command.\n");
-   return -ENXIO;
-   }
+   list_splice_tail_init(>submitted_list, >desc_pool);
+   list_splice_tail_init(>work_list, >desc_pool);
+   list_splice_tail_init(>completed_list, >desc_pool);
+   spin_unlock_irqrestore(>lock, flags);
++  pm_runtime_mark_last_busy(pl330->ddma.dev);
++  pm_runtime_put_autosuspend(pl330->ddma.dev);1
  
return 0;
  }
@@@ -2623,59 -2578,6 +2620,46 @@@ 

Re: [RFC PATCH 2/3] mm: more aggressive page stealing for UNMOVABLE allocations

[Minchan Kim]

On Thu, Dec 04, 2014 at 06:12:57PM +0100, Vlastimil Babka wrote:
> When allocation falls back to stealing free pages of another migratetype,
> it can decide to steal extra pages, or even the whole pageblock in order to
> reduce fragmentation, which could happen if further allocation fallbacks
> pick a different pageblock. In try_to_steal_freepages(), one of the situations
> where extra pages are stolen happens when we are trying to allocate a
> MIGRATE_RECLAIMABLE page.
> 
> However, MIGRATE_UNMOVABLE allocations are not treated the same way, although
> spreading such allocation over multiple fallback pageblocks is arguably even
> worse than it is for RECLAIMABLE allocations. To minimize fragmentation, we
> should minimize the number of such fallbacks, and thus steal as much as is
> possible from each fallback pageblock.

Fair enough.

> 
> This patch thus adds a check for MIGRATE_UNMOVABLE to the decision to steal
> extra free pages. When evaluating with stress-highalloc from mmtests, this has
> reduced the number of MIGRATE_UNMOVABLE fallbacks to roughly 1/6. The number
> of these fallbacks stealing from MIGRATE_MOVABLE block is reduced to 1/3.
> 
> Signed-off-by: Vlastimil Babka 
Acked-by: Minchan Kim 

Nit:

Please fix comment on try_to_steal_freepages.
We don't bias MIGRATE_RECLAIMABLE any more so remove it. Instead,
put some words about the policy and why.

Thanks.

> ---
>  mm/page_alloc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 548b072..a14249c 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1098,6 +1098,7 @@ static int try_to_steal_freepages(struct zone *zone, 
> struct page *page,
>  
>   if (current_order >= pageblock_order / 2 ||
>   start_type == MIGRATE_RECLAIMABLE ||
> + start_type == MIGRATE_UNMOVABLE ||
>   page_group_by_mobility_disabled) {
>   int pages;
>  
> -- 
> 2.1.2
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] gpio: bcm-kona: memory corruption fix

[Alexandre Courbot]

On Tue, Dec 9, 2014 at 6:34 AM, Olof Johansson  wrote:
> In one instance the base address of the internal controller state
> structure is passed into a function doing writel to an offset of
> the pointer passed in is used, instead of the register base.
>
> Once I found the bug, I also went back to check for other sparse
> warnings in the file, but found none. This one, however, triggered:
>
> drivers/gpio/gpio-bcm-kona.c:552:47: warning: incorrect type in argument 1 
> (different address spaces)
> drivers/gpio/gpio-bcm-kona.c:552:47:expected void [noderef] 
> *reg_base
> drivers/gpio/gpio-bcm-kona.c:552:47:got struct bcm_kona_gpio *kona_gpio
> drivers/gpio/gpio-bcm-kona.c:556:47: warning: incorrect type in argument 1 
> (different address spaces)
> drivers/gpio/gpio-bcm-kona.c:556:47:expected void [noderef] 
> *reg_base
> drivers/gpio/gpio-bcm-kona.c:556:47:got struct bcm_kona_gpio *kona_gpio
>
> As far as I can tell, this bug has been here for a long time and is
> not new, but I found it when hunting down another heisenbug on this
> platform.

Ouch. Thanks for fixing this.

Reviewed-by: Alexandre Courbot 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Thermal: introduce INT3406 thermal driver

[Aaron Lu]

INT3406 ACPI device object resembles an ACPI video output device, but its
_BCM is said to be deprecated and should not be used. So we will make
use of the raw interface to do the actual cooling. Due to this, the
backlight core has some modifications. Also, to re-use some of the ACPI
video module's code, one function has been exported.

Signed-off-by: Aaron Lu 
Signed-off-by: Zhang Rui 
---
 drivers/acpi/video.c  |  78 
 drivers/thermal/Kconfig   |  26 +--
 drivers/thermal/int340x_thermal/Kconfig   |  41 
 drivers/thermal/int340x_thermal/Makefile  |   1 +
 drivers/thermal/int340x_thermal/int3406_thermal.c | 230 ++
 drivers/video/backlight/backlight.c   |  44 +++--
 include/acpi/video.h  |  20 ++
 include/linux/backlight.h |   2 +
 8 files changed, 367 insertions(+), 75 deletions(-)
 create mode 100644 drivers/thermal/int340x_thermal/Kconfig
 create mode 100644 drivers/thermal/int340x_thermal/int3406_thermal.c

diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 9d75ead..12f5c5d 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -186,19 +186,6 @@ struct acpi_video_device_cap {
u8 _DDC:1;  /* Return the EDID for this device */
 };
 
-struct acpi_video_brightness_flags {
-   u8 _BCL_no_ac_battery_levels:1; /* no AC/Battery levels in _BCL */
-   u8 _BCL_reversed:1; /* _BCL package is in a reversed order 
*/
-   u8 _BQC_use_index:1;/* _BQC returns an index value */
-};
-
-struct acpi_video_device_brightness {
-   int curr;
-   int count;
-   int *levels;
-   struct acpi_video_brightness_flags flags;
-};
-
 struct acpi_video_device {
unsigned long device_id;
struct acpi_video_device_flags flags;
@@ -344,7 +331,7 @@ static const struct thermal_cooling_device_ops 
video_cooling_ops = {
  */
 
 static int
-acpi_video_device_lcd_query_levels(struct acpi_video_device *device,
+acpi_video_device_lcd_query_levels(acpi_handle handle,
   union acpi_object **levels)
 {
int status;
@@ -354,7 +341,7 @@ acpi_video_device_lcd_query_levels(struct acpi_video_device 
*device,
 
*levels = NULL;
 
-   status = acpi_evaluate_object(device->dev->handle, "_BCL", NULL, 
);
+   status = acpi_evaluate_object(handle, "_BCL", NULL, );
if (!ACPI_SUCCESS(status))
return status;
obj = (union acpi_object *)buffer.pointer;
@@ -727,29 +714,18 @@ static int acpi_video_bqc_quirk(struct acpi_video_device 
*device,
return 0;
 }
 
-
-/*
- *  Arg:
- * device  : video output device (LCD, CRT, ..)
- *
- *  Return Value:
- * Maximum brightness level
- *
- *  Allocate and initialize device->brightness.
- */
-
-static int
-acpi_video_init_brightness(struct acpi_video_device *device)
+int acpi_video_get_levels(struct acpi_device *device,
+ struct acpi_video_device_brightness **dev_br)
 {
union acpi_object *obj = NULL;
int i, max_level = 0, count = 0, level_ac_battery = 0;
-   unsigned long long level, level_old;
union acpi_object *o;
struct acpi_video_device_brightness *br = NULL;
-   int result = -EINVAL;
+   int result = 0;
u32 value;
 
-   if (!ACPI_SUCCESS(acpi_video_device_lcd_query_levels(device, ))) {
+   if (!ACPI_SUCCESS(acpi_video_device_lcd_query_levels(device->handle,
+   ))) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Could not query available "
"LCD brightness level\n"));
goto out;
@@ -822,6 +798,38 @@ acpi_video_init_brightness(struct acpi_video_device 
*device)
"Found unordered _BCL package"));
 
br->count = count;
+   *dev_br = br;
+
+out:
+   kfree(obj);
+   return result;
+out_free:
+   kfree(br);
+   goto out;
+}
+EXPORT_SYMBOL(acpi_video_get_levels);
+
+/*
+ *  Arg:
+ * device  : video output device (LCD, CRT, ..)
+ *
+ *  Return Value:
+ * Maximum brightness level
+ *
+ *  Allocate and initialize device->brightness.
+ */
+
+static int
+acpi_video_init_brightness(struct acpi_video_device *device)
+{
+   int i, max_level = 0;
+   unsigned long long level, level_old;
+   struct acpi_video_device_brightness *br = NULL;
+   int result = -EINVAL;
+
+   result = acpi_video_get_levels(device->dev, );
+   if (result)
+   return result;
device->brightness = br;
 
/* _BQC uses INDEX while _BCL uses VALUE in some laptops */
@@ -864,17 +872,13 @@ set_level:
goto out_free_levels;
 
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "found %d brightness levels\n", count - 2));
-   kfree(obj);
-   return result;
+  

[PATCH v3]PM/Sleep: Timer quiesce in freeze state

[Li, Aubrey]

The patch is based on v3.18.

Freeze is a general power saving state that processes are frozen, devices
are suspended and CPUs are in idle state. However, when the system enters
freeze state, there are a few timers keep ticking and hence consumes more
power unnecessarily. The observed timer events in freeze state are:
- tick_sched_timer
- watchdog lockup detector
- realtime scheduler period timer

The system power consumption in freeze state will be reduced significantly
if we quiesce these timers.

The patch is tested on:
- Sandybrdige-EP system, both RTC alarm and power button are able to wake
  the system up from freeze state.
- HP laptop EliteBook 8460p, both RTC alarm and power button are able to
  wake the system up from freeze state.
- Baytrail-T(ASUS_T100) platform, power button is able to wake the system
  up from freeze state.

Suggested-by: Thomas Gleixner 
Signed-off-by: Aubrey Li 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Len Brown 
Cc: Alan Cox 
---
 drivers/cpuidle/cpuidle.c   | 13 
 include/linux/clockchips.h  |  4 +++
 include/linux/suspend.h |  4 +++
 include/linux/timekeeping.h |  2 ++
 kernel/power/suspend.c  | 50 ++---
 kernel/sched/idle.c | 45 ++
 kernel/softirq.c|  5 +--
 kernel/time/clockevents.c   | 13 
 kernel/time/tick-common.c   | 53 +++
 kernel/time/tick-internal.h |  3 ++
 kernel/time/timekeeping.c   | 77 +
 11 files changed, 243 insertions(+), 26 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 125150d..b9a3ada 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cpuidle.h"
 
@@ -119,6 +120,18 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct 
cpuidle_driver *drv,
ktime_t time_start, time_end;
s64 diff;
 
+   /*
+* under the freeze scenario, the timekeeping is suspended
+* as well as the clock source device, so we bypass the idle
+* counter update in freeze idle
+*/
+   if (in_freeze()) {
+   entered_state = target_state->enter(dev, drv, index);
+   if (!cpuidle_state_is_coupled(dev, drv, entered_state))
+   local_irq_enable();
+   return entered_state;
+   }
+
trace_cpu_idle_rcuidle(index, dev->cpu);
time_start = ktime_get();
 
diff --git a/include/linux/clockchips.h b/include/linux/clockchips.h
index 2e4cb67..d118e0b 100644
--- a/include/linux/clockchips.h
+++ b/include/linux/clockchips.h
@@ -18,6 +18,9 @@ enum clock_event_nofitiers {
CLOCK_EVT_NOTIFY_BROADCAST_EXIT,
CLOCK_EVT_NOTIFY_SUSPEND,
CLOCK_EVT_NOTIFY_RESUME,
+   CLOCK_EVT_NOTIFY_FREEZE_PREPARE,
+   CLOCK_EVT_NOTIFY_FREEZE,
+   CLOCK_EVT_NOTIFY_UNFREEZE,
CLOCK_EVT_NOTIFY_CPU_DYING,
CLOCK_EVT_NOTIFY_CPU_DEAD,
 };
@@ -95,6 +98,7 @@ enum clock_event_mode {
  */
 struct clock_event_device {
void(*event_handler)(struct clock_event_device *);
+   void(*real_handler)(struct clock_event_device *);
int (*set_next_event)(unsigned long evt,
  struct clock_event_device *);
int (*set_next_ktime)(ktime_t expires,
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 3388c1b..86a651c 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -203,6 +203,8 @@ extern void suspend_set_ops(const struct 
platform_suspend_ops *ops);
 extern int suspend_valid_only_mem(suspend_state_t state);
 extern void freeze_set_ops(const struct platform_freeze_ops *ops);
 extern void freeze_wake(void);
+extern bool in_freeze(void);
+extern bool idle_should_freeze(void);
 
 /**
  * arch_suspend_disable_irqs - disable IRQs for suspend
@@ -230,6 +232,8 @@ static inline void suspend_set_ops(const struct 
platform_suspend_ops *ops) {}
 static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
 static inline void freeze_set_ops(const struct platform_freeze_ops *ops) {}
 static inline void freeze_wake(void) {}
+static inline bool in_freeze(void) { return false; }
+static inline bool idle_should_freeze(void) { return false; }
 #endif /* !CONFIG_SUSPEND */
 
 /* struct pbe is used for creating lists of pages that should be restored
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 1caa6b0..07957a9 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -5,6 +5,8 @@
 
 void timekeeping_init(void);
 extern int timekeeping_suspended;
+extern void timekeeping_freeze(void);
+extern void timekeeping_unfreeze(void);
 
 /*
  * Get and set timeofday
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index c347e3c..6467fb8 100644

Re: [RFC PATCH 1/3] mm: when stealing freepages, also take pages created by splitting buddy page

[Minchan Kim]

On Thu, Dec 04, 2014 at 06:12:56PM +0100, Vlastimil Babka wrote:
> When __rmqueue_fallback() is called to allocate a page of order X, it will
> find a page of order Y >= X of a fallback migratetype, which is different from
> the desired migratetype. With the help of try_to_steal_freepages(), it may
> change the migratetype (to the desired one) also of:
> 
> 1) all currently free pages in the pageblock containing the fallback page
> 2) the fallback pageblock itself
> 3) buddy pages created by splitting the fallback page (when Y > X)
> 
> These decisions take the order Y into account, as well as the desired
> migratetype, with the goal of preventing multiple fallback allocations that
> could e.g. distribute UNMOVABLE allocations among multiple pageblocks.
> 
> Originally, decision for 1) has implied the decision for 3). Commit
> 47118af076f6 ("mm: mmzone: MIGRATE_CMA migration type added") changed that
> (probably unintentionally) so that the buddy pages in case 3) are always
> changed to the desired migratetype, except for CMA pageblocks.
> 
> Commit fef903efcf0c ("mm/page_allo.c: restructure free-page stealing code and
> fix a bug") did some refactoring and added a comment that the case of 3) is
> intended. Commit 0cbef29a7821 ("mm: __rmqueue_fallback() should respect
> pageblock type") removed the comment and tried to restore the original 
> behavior
> where 1) implies 3), but due to the previous refactoring, the result is 
> instead
> that only 2) implies 3) - and the conditions for 2) are less frequently met
> than conditions for 1). This may increase fragmentation in situations where 
> the
> code decides to steal all free pages from the pageblock (case 1)), but then
> gives back the buddy pages produced by splitting.
> 
> This patch restores the original intended logic where 1) implies 3). During
> testing with stress-highalloc from mmtests, this has shown to decrease the
> number of events where UNMOVABLE and RECLAIMABLE allocations steal from 
> MOVABLE
> pageblocks, which can lead to permanent fragmentation. It has increased the
> number of events when MOVABLE allocations steal from UNMOVABLE or RECLAIMABLE
> pageblocks, but these are fixable by sync compaction and thus less harmful.
> 
> Signed-off-by: Vlastimil Babka 
Acked-by: Minchan Kim 

I expect you will Cc -stable when you respin with fixing pointed out
by Joonsoo.

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

Re: [PATCH] ARM: DMA: Fix kzalloc flags in __iommu_alloc_buffer()

[Alexandre Courbot]

On Mon, Dec 8, 2014 at 7:24 PM, Arnd Bergmann  wrote:
> On Monday 08 December 2014 17:39:27 Alexandre Courbot wrote:
>> There doesn't seem to be any valid reason to allocate the pages array
>> with the same flags as the buffer itself. Doing so can eventually lead
>> to the following safeguard in mm/slab.c to be hit:
>>
>> BUG_ON(flags & GFP_SLAB_BUG_MASK);
>>
>> This happens when buffers are allocated with __GFP_DMA32 or
>> __GFP_HIGHMEM.
>>
>> Fix this by allocating the pages array with GFP_KERNEL to follow what is
>> done elsewhere in this file. Using GFP_KERNEL in __iommu_alloc_buffer()
>> is safe because atomic allocations are handled by __iommu_alloc_atomic().
>>
>
> I think you need to carry over the GFP_ATOMIC flag if that is set by the
> caller, but not the GFP_HIGHMEM or GFP_DMA32. Not sure if it's better
> to mask out flags from the caller mask, or to start with GFP_KERNEL
> and adding in extra bits.

I thought the issue of atomicity is already handled by
__iommu_alloc_buffer's caller (arm_iommu_alloc_attrs):

if (!(gfp & __GFP_WAIT))
return __iommu_alloc_atomic(dev, size, handle);

pages = __iommu_alloc_buffer(dev, size, gfp, attrs);

Isn't the interesting property about GFP_ATOMIC that it does not
include __GFP_WAIT? I may very well misunderstand the issue, sorry if
that's the case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] ARM: dts: Enable usb PHY on rk3288-evb board

[Yunzhi Li]

Enable usb PHY for all usb ports on rk3288-evb.

Signed-off-by: Yunzhi Li 

---

Changes in v4: None
Changes in v3: None

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

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index cb83cea..992f323 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -174,6 +174,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
 _host0_ehci {
status = "okay";
 };
-- 
2.0.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/

[PATCH v4 4/5] ARM: dts: add rk3288 usb PHY

[Yunzhi Li]

This patch adds a device_node for RK3288 SoC usb phy. It also
defines the phy to be used by three usb controllers: usb_host0/1
and usb_otg.

Signed-off-by: Yunzhi Li 

---

Changes in v4:
- Add phy subnodes.

Changes in v3: None

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

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 874e66d..2db2d12 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -329,12 +329,35 @@
status = "disabled";
};
 
+   usbphy: phy {
+   #phy-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-usb-phy";
+   rockchip,grf = <>;
+   status = "disabled";
+
+   usb-phy@0 {
+   reg = <0>;
+   };
+
+   usb-phy@1 {
+   reg = <1>;
+   };
+
+   usb-phy@2 {
+   reg = <2>;
+   };
+   };
+
usb_host0_ehci: usb@ff50 {
compatible = "generic-ehci";
reg = <0xff50 0x100>;
interrupts = ;
clocks = < HCLK_USBHOST0>;
clock-names = "usbhost";
+   phys = < 1>;
+   phy-names = "usb";
status = "disabled";
};
 
@@ -347,6 +370,8 @@
interrupts = ;
clocks = < HCLK_USBHOST1>;
clock-names = "otg";
+   phys = < 2>;
+   phy-names = "usb2-phy";
status = "disabled";
};
 
@@ -357,6 +382,8 @@
interrupts = ;
clocks = < HCLK_OTG0>;
clock-names = "otg";
+   phys = < 0>;
+   phy-names = "usb2-phy";
status = "disabled";
};
 
-- 
2.0.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: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Tian, Kevin]

> From: Daniel Vetter
> Sent: Monday, December 08, 2014 6:21 PM
> 
> On Mon, Dec 08, 2014 at 10:55:01AM +0100, Gerd Hoffmann wrote:
> > On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
> > > I don't know that is exactly needed, we also need to have Windows
> > > driver considered.  However, I'm quite confident that, if things gonna
> > > work for IGD passthrough, it gonna work for GVT-g.
> >
> > I'd suggest to focus on q35 emulation.  q35 is new enough that a version
> > with integrated graphics exists, so the gap we have to close is *much*
> > smaller.
> >
> > In case guests expect a northbridge matching the chipset generation of
> > the graphics device (which I'd expect is the case, after digging a bit
> > in the igd and agpgart linux driver code) I think we should add proper
> > device emulation for them, i.e. comply q35-pcihost with
> > sandybridge-pcihost + ivybridge-pcihost + haswell-pcihost instead of
> > just copying over the pci ids from the host.  Most likely all those
> > variants can share most of the emulation code.
> 
> I don't think i915.ko should care about either northbridge nor pch on
> para-virtualized platforms. We do noodle around in there for the oddball
> memory controller setting and for some display stuff. But neither of that
> really applies to paravirtualized hw. And if there's any case like that we
> should  patch it out (like we do with some of the runtime pm code
> already).

Agree. Now Allen is working on how to avoid those tricky platform
stickiness in Windows gfx driver. We should do same thing in Linux
part too.

Thanks
Kevin

[PATCH v4 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.

[Yunzhi Li]

Get PHY parameters from devicetree and power off usb PHY during
system suspend.

Signed-off-by: Yunzhi Li 

Acked-by: Paul Zimmerman 

Changes in v3:
- Fix coding style: both branches of the if() which only one
  branch of the conditional statement is a single statement
  should have braces.
- No need to test dwc2->phy for NULL before calling generic phy
  APIs.

---

Changes in v4: None
Changes in v3: None

 drivers/usb/dwc2/gadget.c   | 33 -
 drivers/usb/dwc2/platform.c | 36 ++--
 2 files changed, 46 insertions(+), 23 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..2601c61 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3410,8 +3410,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
 {
struct device *dev = hsotg->dev;
struct s3c_hsotg_plat *plat = dev->platform_data;
-   struct phy *phy;
-   struct usb_phy *uphy;
struct s3c_hsotg_ep *eps;
int epnum;
int ret;
@@ -3421,30 +3419,23 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
hsotg->phyif = GUSBCFG_PHYIF16;
 
/*
-* Attempt to find a generic PHY, then look for an old style
-* USB PHY, finally fall back to pdata
+* If platform probe couldn't find a generic PHY or an old style
+* USB PHY, fall back to pdata
 */
-   phy = devm_phy_get(dev, "usb2-phy");
-   if (IS_ERR(phy)) {
-   uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
-   if (IS_ERR(uphy)) {
-   /* Fallback for pdata */
-   plat = dev_get_platdata(dev);
-   if (!plat) {
-   dev_err(dev,
-   "no platform data or transceiver defined\n");
-   return -EPROBE_DEFER;
-   }
-   hsotg->plat = plat;
-   } else
-   hsotg->uphy = uphy;
-   } else {
-   hsotg->phy = phy;
+   if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
+   plat = dev_get_platdata(dev);
+   if (!plat) {
+   dev_err(dev,
+   "no platform data or transceiver defined\n");
+   return -EPROBE_DEFER;
+   }
+   hsotg->plat = plat;
+   } else if (hsotg->phy) {
/*
 * If using the generic PHY framework, check if the PHY bus
 * width is 8-bit and set the phyif appropriately.
 */
-   if (phy_get_bus_width(phy) == 8)
+   if (phy_get_bus_width(hsotg->phy) == 8)
hsotg->phyif = GUSBCFG_PHYIF8;
}
 
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa..ae095f0 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -155,6 +155,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
struct dwc2_core_params defparams;
struct dwc2_hsotg *hsotg;
struct resource *res;
+   struct phy *phy;
+   struct usb_phy *uphy;
int retval;
int irq;
 
@@ -212,6 +214,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
 
hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
 
+   /*
+* Attempt to find a generic PHY, then look for an old style
+* USB PHY
+*/
+   phy = devm_phy_get(>dev, "usb2-phy");
+   if (IS_ERR(phy)) {
+   hsotg->phy = NULL;
+   uphy = devm_usb_get_phy(>dev, USB_PHY_TYPE_USB2);
+   if (IS_ERR(uphy))
+   hsotg->uphy = NULL;
+   else
+   hsotg->uphy = uphy;
+   } else {
+   hsotg->phy = phy;
+   phy_power_on(hsotg->phy);
+   phy_init(hsotg->phy);
+   }
+
spin_lock_init(>lock);
mutex_init(>init_mutex);
retval = dwc2_gadget_init(hsotg, irq);
@@ -231,8 +251,15 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
 
-   if (dwc2_is_device_mode(dwc2))
+   if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_suspend(dwc2);
+   } else {
+   if (dwc2->lx_state == DWC2_L0)
+   return 0;
+   phy_exit(dwc2->phy);
+   phy_power_off(dwc2->phy);
+
+   }
return ret;
 }
 
@@ -241,8 +268,13 @@ static int __maybe_unused dwc2_resume(struct device *dev)
struct dwc2_hsotg *dwc2 = dev_get_drvdata(dev);
int ret = 0;
 
-   if (dwc2_is_device_mode(dwc2))
+   if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_resume(dwc2);
+   } else {
+   phy_power_on(dwc2->phy);
+   

RE: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Tian, Kevin]

Here is some background of this KVMGT release:

- the major purpose is for early experiment of this technique in KVM, and 
throw out issues about adding in-kernel device model (or mediated pass-through 
framework) in KVM.

- KVMGT shares 90% code as XenGT, regarding to vGPU device model. The
only difference is the in-kernel dm interface. The vGPU device model will be
split and integrated in i915 driver. It will register to in-kernel dm framework
provided either by Xen or KVM at boot time. Upstreaming of vGPU device
model is already in progress, with valuable comments received from i915 
community. However the refactoring mostly happen in XenGT repo now 

- Now we have XenGT/KVMGT separately maintained, and KVMGT lags
behind XenGT regarding to features and qualities. Likely you'll continue
see stale code (like Xen inst decoder) for some time. In the future we
plan to maintain a single kernel repo for both, so KVMGT can share
same quality as XenGT once KVM in-kernel dm framework is stable.

- Regarding to Qemu hacks, KVMGT really doesn't have any different 
requirements as what have been discussed for GPU pass-through, e.g. 
about ISA bridge. Our implementation is based on an old Qemu repo, 
and honestly speaking not cleanly developed, because we know we
can leverage from GPU pass-through support once it's in Qemu. At 
that time we'll leverage the same logic with minimal changes to 
hook KVMGT mgmt. APIs (e.g. create/destroy a vGPU instance). So
we can ignore this area for now. :-)

Thanks
Kevin

> From: Paolo Bonzini
> Sent: Friday, December 05, 2014 9:04 PM
> 
> 
> 
> On 05/12/2014 09:50, Gerd Hoffmann wrote:
> > A few comments on the kernel stuff (brief look so far, also
> > compile-tested only, intel gfx on my test machine is too old).
> >
> >  * Noticed the kernel bits don't even compile when configured as
> >module.  Everything (vgt, i915, kvm) must be compiled into the
> >kernel.
> 
> I'll add that the patch is basically impossible to review with all the
> XenGT bits still in.  For example, the x86 emulator seems to be
> unnecessary for KVMGT, but I am not 100% sure.
> 
> I would like a clear understanding of why/how Andrew Barnes was able to
> do i915 passthrough (GVT-d) without hacking the ISA bridge, and why this
> does not apply to GVT-g.
> 
> Paolo
> 
> >  * Design approach still seems to be i915 on vgt not the other way
> >around.
> >
> > Qemu/SeaBIOS bits:
> >
> > I've seen the host bridge changes identity from i440fx to
> > copy-pci-ids-from-host.  Guess the reason for this is that seabios uses
> > this device to figure whenever it is running on i440fx or q35.  Correct?
> >
> > What are the exact requirements for the device?  Must it match the host
> > exactly, to not confuse the guest intel graphics driver?  Or would
> > something more recent -- such as the q35 emulation qemu has -- be good
> > enough to make things work (assuming we add support for the
> > graphic-related pci config space registers there)?
> >
> > The patch also adds a dummy isa bridge at 0x1f.  Simliar question here:
> > What exactly is needed here?  Would things work if we simply use the q35
> > lpc device here?
> >
> > more to come after I've read the paper linked above ...
> >
> > cheers,
> >   Gerd
> >
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v4 2/5] Documentation: bindings: add doc for the Rockchip usb PHY

[Yunzhi Li]

Document the bindings of the Rockchip usb PHY driver.

Signed-off-by: Yunzhi Li 

---

Changes in v4:
- Updata description for phy device tree subnode.

Changes in v3: None

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

diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
new file mode 100644
index 000..0b725e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
@@ -0,0 +1,32 @@
+ROCKCHIP USB2 PHY
+
+Required properties:
+ - compatible: rockchip,rk3288-usb-phy
+ - rockchip,grf : phandle to the syscon managing the "general
+   register files"
+ - #phy-cells: should be 1
+ - #address-cells: should be 1
+ - #size-cells: should be 0
+
+Sub-nodes:
+Each PHY should be represented as a sub-node.
+
+Sub-nodes
+required properties:
+- reg: the PHY number
+   "0" - PHY connect to OTG controller
+   "1" - PHY connect to HOST0 controller
+   "2" - PHY connect to HOST1 controller
+
+Optional Properties:
+- clocks : phandle + clock specifier for the phy clocks
+
+Example:
+
+usbphy: phy {
+   #phy-cells = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-usb-phy";
+   rockchip,grf = <>;
+};
-- 
2.0.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/

[PATCH v4 0/5] Patches to add support for Rockchip usb PHYs.

[Yunzhi Li]

Patches to add support for Rockchip usb phys.Add a new Rockchip
usb phy driver and modify dwc2 controller driver to make dwc2
platform devices support a generic PHY framework driver. This
patch set has been tested on my rk3288-evb and power off the usb
phys would reduce about 60mW power budget in total during sustem
suspend.

Changes in v4:
- Get number of PHYs from device tree.
- Model each PHY as subnode of the phy provider node.
- Updata description for phy device tree subnode.
- Add phy subnodes.

Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.

Yunzhi Li (5):
  phy: add a driver for the Rockchip SoC internal USB2.0 PHY
  Documentation: bindings: add doc for the Rockchip usb PHY
  usb: dwc2: add generic PHY framework support for dwc2 usb controler
platform driver.
  ARM: dts: add rk3288 usb PHY
  ARM: dts: Enable usb PHY on rk3288-evb board

 .../devicetree/bindings/phy/rockchip-usb-phy.txt   |  32 
 arch/arm/boot/dts/rk3288-evb.dtsi  |   4 +
 arch/arm/boot/dts/rk3288.dtsi  |  27 +++
 drivers/phy/Kconfig|   7 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-rockchip-usb.c | 211 +
 drivers/usb/dwc2/gadget.c  |  33 ++--
 drivers/usb/dwc2/platform.c|  36 +++-
 8 files changed, 328 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt
 create mode 100644 drivers/phy/phy-rockchip-usb.c

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

[PATCH v4 1/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY

[Yunzhi Li]

This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
currently this driver can support RK3288. The RK3288 SoC have
three independent USB PHY IPs which are all configured through a
set of registers located in the GRF (general register files)
module.

Signed-off-by: Yunzhi Li 

---

Changes in v4:
- Get number of PHYs from device tree.
- Model each PHY as subnode of the phy provider node.

Changes in v3:
- Use BIT macro instead of bit shift ops.
- Rename the config entry to PHY_ROCKCHIP_USB.

 drivers/phy/Kconfig|   7 ++
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-rockchip-usb.c | 211 +
 3 files changed, 219 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccad880..8a39d2a 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -239,6 +239,13 @@ config PHY_QCOM_IPQ806X_SATA
depends on OF
select GENERIC_PHY
 
+config PHY_ROCKCHIP_USB2
+   tristate "Rockchip USB2 PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip USB 2.0 PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index aa74f96..8a13f72 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -28,6 +28,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2) += 
phy-exynos5250-usb2.o
 phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
+obj-$(CONFIG_PHY_ROCKCHIP_USB2) += phy-rockchip-usb.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-usb.c b/drivers/phy/phy-rockchip-usb.c
new file mode 100644
index 000..0317c21
--- /dev/null
+++ b/drivers/phy/phy-rockchip-usb.c
@@ -0,0 +1,211 @@
+/*
+ * Rockchip usb PHY driver
+ *
+ * Copyright (C) 2014 Yunzhi Li 
+ * Copyright (C) 2014 ROCKCHIP, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ROCKCHIP_RK3288_UOC(n) (0x320 + n * 0x14)
+
+/*
+ * The higher 16-bit of this register is used for write protection
+ * only if BIT(13 + 16) set to 1 the BIT(13) can be written.
+ */
+#define SIDDQ_MSK  BIT(13 + 16)
+#define SIDDQ_ON   BIT(13)
+#define SIDDQ_OFF  (0 << 13)
+
+struct rockchip_usb_phy {
+   struct regmap   *reg_base;
+   unsigned intreg_offset;
+   struct clk  *clk;
+   struct phy  *phy;
+   unsignedindex;
+};
+
+struct rockchip_usb_phy_priv {
+   struct rockchip_usb_phy *phys;
+   unsignednphys;
+};
+
+static int rockchip_usb_phy_power(struct rockchip_usb_phy *phy,
+  bool siddq)
+{
+   return regmap_write(phy->reg_base, phy->reg_offset,
+   SIDDQ_MSK | (siddq ? SIDDQ_ON : SIDDQ_OFF));
+}
+
+static int rockchip_usb_phy_power_off(struct phy *_phy)
+{
+   struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+   int ret = 0;
+
+   /* Power down usb phy analog blocks by set siddq 1 */
+   ret = rockchip_usb_phy_power(phy, 1);
+   if (ret)
+   return ret;
+
+   clk_disable_unprepare(phy->clk);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static int rockchip_usb_phy_power_on(struct phy *_phy)
+{
+   struct rockchip_usb_phy *phy = phy_get_drvdata(_phy);
+   int ret = 0;
+
+   ret = clk_prepare_enable(phy->clk);
+   if (ret)
+   return ret;
+
+   /* Power up usb phy analog blocks by set siddq 0 */
+   ret = rockchip_usb_phy_power(phy, 0);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static struct phy *rockchip_usb_phy_xlate(struct device *dev,
+   struct of_phandle_args *args)
+{
+   struct rockchip_usb_phy_priv *priv = dev_get_drvdata(dev);
+   int i;
+
+   if (WARN_ON(args->args[0] >= priv->nphys))
+   return ERR_PTR(-ENODEV);
+
+   for (i = 0; i < priv->nphys; i++) {
+   

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

[Zhang Rui]

On Tue, 2014-12-09 at 10:31 +0800, Aaron Lu wrote:
> Sorry for the trouble.
> 
> Hi Rui,
> 
> Please let me know if you want an update to the original patch
> or an incremental one.
> 
updated one
> Thanks,
> Aaron
> 
> On 12/09/2014 10:17 AM, Stephen Rothwell wrote:
> > Hi Zhang,
> > 
> > After merging the thermal tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > drivers/thermal/Kconfig:265: can't open file 
> > "drivers/thermal/int340x_thermal/Kconfig"
> > 
> > Caused by commit 4152c8bc018d ("Thermal: introduce INT3406 thermal
> > driver").  Presumable a new file was missed.
> > 
> > I have used teh thermal tree from next-20141208 for today.
> > 
> 


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

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

[Aaron Lu]

Sorry for the trouble.

Hi Rui,

Please let me know if you want an update to the original patch
or an incremental one.

Thanks,
Aaron

On 12/09/2014 10:17 AM, Stephen Rothwell wrote:
> Hi Zhang,
> 
> After merging the thermal tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> drivers/thermal/Kconfig:265: can't open file 
> "drivers/thermal/int340x_thermal/Kconfig"
> 
> Caused by commit 4152c8bc018d ("Thermal: introduce INT3406 thermal
> driver").  Presumable a new file was missed.
> 
> I have used teh thermal tree from next-20141208 for today.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] s390: Include kvm_host.h header only if KVM is enabled

[Pranith Kumar]

On Mon, Dec 8, 2014 at 6:59 PM, Paul E. McKenney
 wrote:
> On Mon, Dec 08, 2014 at 03:24:35PM -0500, Pranith Kumar wrote:
>> KVM uses srcu structures because of which CONFIG_KVM selects CONFIG_SRCU. In
>> asm-offsets.c, we are including kvm_host.h unconditionally even though
>> CONFIG_KVM is not enabled because of which we get errors like follows:
>>
>> In file included from arch/s390/kernel/asm-offsets.c:10:0:
>> >> include/linux/kvm_host.h:363:21: error: field 'srcu' has incomplete type
>>   struct srcu_struct srcu;
>>  ^
>> >> include/linux/kvm_host.h:364:21: error: field 'irq_srcu' has incomplete 
>> >> type
>>   struct srcu_struct irq_srcu;
>>  ^
>> make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1
>> make[2]: Target '__build' not remade because of errors.
>> make[1]: *** [prepare0] Error 2
>> make[1]: Target 'prepare' not remade because of errors.
>> make: *** [sub-make] Error 2
>>
>> This patch fixes these by including kvm_host.h conditionally on CONFIG_KVM.
>>
>> Signed-off-by: Pranith Kumar 
>
> To make the commits bisectable, we need to combine these two patches,
> correct?
>

Yes, if the s390 maintainers raise no objections, I will combine this
with the other patch and send it.

Thanks!

>> ---
>>  arch/s390/kernel/asm-offsets.c | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
>> index ef279a1..055334d 100644
>> --- a/arch/s390/kernel/asm-offsets.c
>> +++ b/arch/s390/kernel/asm-offsets.c
>> @@ -7,12 +7,15 @@
>>  #define ASM_OFFSETS_C
>>
>>  #include 
>> -#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>
>> +#ifdef CONFIG_KVM
>> +#include 
>> +#endif
>> +
>>  /*
>>   * Make sure that the compiler is new enough. We want a compiler that
>>   * is known to work with the "Q" assembler constraint.
>> @@ -182,8 +185,10 @@ int main(void)
>>   DEFINE(__LC_PGM_TDB, offsetof(struct _lowcore, pgm_tdb));
>>   DEFINE(__THREAD_trap_tdb, offsetof(struct task_struct, 
>> thread.trap_tdb));
>>   DEFINE(__GMAP_ASCE, offsetof(struct gmap, asce));
>> +#ifdef CONFIG_KVM
>>   DEFINE(__SIE_PROG0C, offsetof(struct kvm_s390_sie_block, prog0c));
>>   DEFINE(__SIE_PROG20, offsetof(struct kvm_s390_sie_block, prog20));
>> +#endif /* CONFIG_KVM */
>>  #endif /* CONFIG_32BIT */
>>   return 0;
>>  }
>> --
>> 1.9.1
>>
>



-- 
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: Clear bridge MEM_64 flag if one child does not support it

[Wei Yang]

On Tue, Dec 09, 2014 at 11:11:19AM +1100, Gavin Shan wrote:
>On Mon, Dec 08, 2014 at 03:59:54PM -0800, Yinghai Lu wrote:
>>On Mon, Dec 8, 2014 at 2:56 PM, Benjamin Herrenschmidt
>> wrote:
>>> On Mon, 2014-12-08 at 13:52 -0800, Yinghai Lu wrote:
 2. or scan the children resource other than ROM to clear bridge MEM_64
for mmio pref.

 The patch is using second way so will keep child mmio pref into bridge
 mmio pref range.
>>>
>>> That means that having a single ROM BAR that is 32-bit and prefetchable
>>> will downgrade the entire window to 32-bit ? That's not going to work
>>> either.
>>
>>the ROM BAR get skipped during the checking.
>>
>>+   if (i != PCI_ROM_RESOURCE)
>>+   mem64_mask &= r->flags & IORESOURCE_MEM_64;
>>+   }
>>
>>>
>>> I have GPUs with 16G BARs for example... suddenly they don't fit
>>> anaymore because we downgraded the window to 32 bit because somewhere
>>> there's a 32-bit pref resource ?
>>>
>>> That will break more than it fixes...
>>
>>Please check if this patch break your platform. I tried on my setup on
>>x86. and it is still
>>working on 64 bit resource allocation.
>>
>
>I'm going to give it a spin and Richard, could you please apply Yinghai's
>patch to see if your SRIOV code can work properly?
>

Yinghai & Gavin,

I did a quick test on my machine. This patch doesn't affect the MMIO
allocation on out platform, so SRIOV works fine.

I will spend more time to read the patch to get more understanding about the
problem.

>Thanks,
>Gavin

-- 
Richard Yang
Help you, Help me

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

[Kirill A. Shutemov]

On Tue, Dec 09, 2014 at 01:56:51AM +, Al Viro wrote:
> On Mon, Dec 08, 2014 at 07:28:17PM +, Al Viro wrote:
> > On Mon, Dec 08, 2014 at 10:57:31AM -0800, Linus Torvalds wrote:
> > > So the whole "get_page()" thing is broken. Iterating over pages in a
> > > KVEC is simply wrong, wrong, wrong. It needs to fail.
> > 
> > Well, _that_ is easy to do, of course...  E.g. by replacing that thing in
> > iov_iter_get_pages()/iov_iter_get_pages_alloc() with ({ return -EFAULT; })
> > will do it.
> 
> OK, folded and pushed (i.e. in vfs.git#iov_iter and vfs.git#for-next).
> Matches earlier behaviour; oops reproducer is easy -
> 
> dd if=/dev/zero of=foo.ko bs=4096 count=1
> cat >a.c <<'EOF'
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> #include 
> main()
> {
> int fd = open("foo.ko", 0004);
> syscall(__NR_finit_module, fd, "", 0);
> }
> EOF
> gcc a.c
> strace ./a.out
> 
> Correct behaviour (both the mainline and this series with fixes folded):
> open("foo.ko", O_RDONLY|O_DIRECT)   = 3
> finit_module(3, "", 0)  = -1 EFAULT (Bad address)
> Incorrect one:
> open("foo.ko", O_RDONLY|O_DIRECT)   = 3
> finit_module(3, "", 0 
> +++ killed by SIGKILL +++
> Killed
> 
> with that oops reproduced.  Not sure if it's a proper LTP or xfstests fodder,
> but anyway, here it is.
> 
> Incremental from previous for-next is

Works for me.

-- 
 Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kthread: kthread_bind fails to enforce CPU affinity (fixes kernel BUG at kernel/smpboot.c:134!)

[Lai Jiangshan]

On 12/08/2014 09:54 PM, Steven Rostedt wrote:
> On Mon,  8 Dec 2014 14:27:01 +1100
> Anton Blanchard  wrote:
> 
>> I have a busy ppc64le KVM box where guests sometimes hit the infamous
>> "kernel BUG at kernel/smpboot.c:134!" issue during boot:
>>
>> BUG_ON(td->cpu != smp_processor_id());
>>
>> Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
>> output confirms it:
>>
>> CPU: 0
>> Comm: watchdog/130
>>
>> The issue is in kthread_bind where we set the cpus_allowed mask, but do
>> not touch task_thread_info(p)->cpu. The scheduler assumes the previously
>> scheduled CPU is in the cpus_allowed mask, but in this case we are
>> moving a thread to another CPU so it is not.
>>
> 
> Does this happen always on boot up, and always with the watchdog thread?
> 
> I followed the logic that starts the watchdog threads.
> 
> watchdog_enable_all_cpus()
>   smpboot_register_percpu-thread() {
> 
> for_each_online_cpu(cpu) { ... }
> 
> Where watchdog_enable_all_cpus() can be called by
> lockup_detector_init() before SMP is started, but also by
> proc_dowatchdog() which is called by the sysctl commands (after SMP is
> up and running).
> 
> I noticed there's no "get_online_cpus()" anywhere, although the
> unregister_percpu_thread() has it. Is it possible that we created a
> thread on a CPU that wasn't fully online yet?
> 
> Perhaps the following patch is needed? Even if this isn't the solution
> to this bug, it is probably needed as watchdog_enable_all_cpus() can be
> called after boot up too.
> 
> -- Steve


Hi, Steven, tglx

See this https://lkml.org/lkml/2014/7/30/804
"[PATCH] smpboot: add missing get_online_cpus() when register"


Thanks,
Lai

> 
> diff --git a/kernel/smpboot.c b/kernel/smpboot.c
> index eb89e1807408..60d35ac5d3f1 100644
> --- a/kernel/smpboot.c
> +++ b/kernel/smpboot.c
> @@ -279,6 +279,7 @@ int smpboot_register_percpu_thread(struct 
> smp_hotplug_thread *plug_thread)
>   unsigned int cpu;
>   int ret = 0;
>  
> + get_online_cpus();
>   mutex_lock(_threads_lock);
>   for_each_online_cpu(cpu) {
>   ret = __smpboot_create_thread(plug_thread, cpu);
> @@ -291,6 +292,7 @@ int smpboot_register_percpu_thread(struct 
> smp_hotplug_thread *plug_thread)
>   list_add(_thread->list, _threads);
>  out:
>   mutex_unlock(_threads_lock);
> + put_online_cpus();
>   return ret;
>  }
>  EXPORT_SYMBOL_GPL(smpboot_register_percpu_thread);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> .
> 

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

linux-next: build failure after merge of the thermal tree

[Stephen Rothwell]

Hi Zhang,

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

drivers/thermal/Kconfig:265: can't open file 
"drivers/thermal/int340x_thermal/Kconfig"

Caused by commit 4152c8bc018d ("Thermal: introduce INT3406 thermal
driver").  Presumable a new file was missed.

I have used teh thermal tree from next-20141208 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpxjPOyZYCAG.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 1/8] soc: mediatek: Add PMIC wrapper for MT8135 and MT6397 SoC

[Flora Fu]

Hi, Arnd,

On Fri, 2014-12-05 at 11:13 +0100, Arnd Bergmann wrote:
> On Friday 05 December 2014 12:07:52 Flora Fu wrote:
> > Add PMIC wrapper of MT8135 to access MT6397 MFD.
> > 
> > Signed-off-by: Flora Fu 
> > 
> 
> Please explain what a PMIC wrapper is and why you need one for MT8135.
> I don't understand the purpose of this code at all. Is this just another
> way of accessing the MT6397 when not using i2c or spi like other
> PMIC drivers do?
> 

Yes, MT8135 uses a proprietary hardware to communicate with MT6397. 
The hardware is called PMIC Wrapper or PWRAP.
Since it is not standard i2c or spi protocols, a soc related software
driver is implemented to handle access protocols in AP side.

+-+   +---+
| |   |   |
| Mediatek AP SoC |   |   |
| (ex. MT8135)|   |MT6397 |
| |   |   |
|  ++ | (SPI bus) | ++|
|  || |---| |||
|  |  PMIC  | |---| |  PMIC  ||
|  | Wrapper| |---| | Wrapper||
|  || |---| |||
|  ++ |   | ++|
| |   |   |
+-+   +---+

Thanks,
Flora


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

Re: [RESEND][PATCH v15 7/7] ARM: kprobes: enable OPTPROBES for ARM 32

[Wang Nan]

Hi all,

Looks like v15 patch solves the problems found in patch v13 and v14. I run 
Tixy's test
cases in a loop for a whole night on two real unpublished Hisilicon ARM A15 
SoCs (I
backported kprobes to 3.10 kernel), no problem arise, they are still running 
now.

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

Re: [PATCH 2/6] PCI/MSI: add hooks to populate the msi_domain field

[Yijing Wang]

On 2014/12/9 4:12, Marc Zyngier wrote:
> In order to be able to populate the device msi_domain field,
> add the necesary hooks to propagate the PHB msi_domain across
> secondary busses to devices.
> 
> So far, nobody populates the initial msi_domain.
> 
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/pci/probe.c | 24 
>  include/linux/pci.h |  1 +
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index c8ca98c..d1009a2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -670,6 +670,20 @@ static void pci_set_bus_speed(struct pci_bus *bus)
>   }
>  }
>  
> +void __weak pcibios_set_phb_msi_domain(struct pci_bus *bus)
> +{
> +}
> +
> +static void pci_set_bus_msi_domain(struct pci_bus *bus)
> +{
> + struct pci_dev *bridge = bus->self;
> +
> + if (!bridge)
> + pcibios_set_phb_msi_domain(bus);
> + else
> + dev_set_msi_domain(>dev, dev_get_msi_domain(>dev));
> +}


Hi Marc, we can not assume pci devices under same phb share the same msi irq 
domain,
now in x86, pci devices under the same phb may associate different msi irq 
domain.

> +
>  static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
>  struct pci_dev *bridge, int busnr)
>  {
> @@ -723,6 +737,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus 
> *parent,
>   bridge->subordinate = child;
>  
>  add_dev:
> + pci_set_bus_msi_domain(child);
>   ret = device_register(>dev);
>   WARN_ON(ret < 0);
>  
> @@ -1517,6 +1532,11 @@ static void pci_init_capabilities(struct pci_dev *dev)
>   pci_enable_acs(dev);
>  }
>  
> +static void pci_set_msi_domain(struct pci_dev *dev)
> +{
> + dev_set_msi_domain(>dev, dev_get_msi_domain(>bus->dev));
> +}
> +
>  void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>  {
>   int ret;
> @@ -1546,6 +1566,9 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus 
> *bus)
>   /* Initialize various capabilities */
>   pci_init_capabilities(dev);
>  
> + /* Setup MSI irq domain */
> + pci_set_msi_domain(dev);
> +
>   /*
>* Add the device to our list of discovered devices
>* and the bus list for fixup functions, etc.
> @@ -1947,6 +1970,7 @@ struct pci_bus *pci_create_root_bus(struct device 
> *parent, int bus,
>   b->bridge = get_device(>dev);
>   device_enable_async_suspend(b->bridge);
>   pci_set_bus_of_node(b);
> + pci_set_bus_msi_domain(b);
>  
>   if (!parent)
>   set_dev_node(b->bridge, pcibus_to_node(b));
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index a523cee..3266764 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1637,6 +1637,7 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
>  int pcibios_add_device(struct pci_dev *dev);
>  void pcibios_release_device(struct pci_dev *dev);
>  void pcibios_penalize_isa_irq(int irq, int active);
> +void pcibios_set_phb_msi_domain(struct pci_bus *bus);
>  
>  #ifdef CONFIG_HIBERNATE_CALLBACKS
>  extern struct dev_pm_ops pcibios_pm_ops;
> 


-- 
Thanks!
Yijing

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v6 6/9] thermal: cpu_cooling: implement the power cooling device API

[Viresh Kumar]

On 8 December 2014 at 19:52, Javi Merino  wrote:
> Ok, changed it into:
>
> cpu = cpumask_any(_device->allowed_cpus);
> dev = get_cpu_device(cpu);
> if (!dev) {
> dev_warn(_device->cool_dev->device,
> "No cpu device for cpu %d\n", cpu);
> ret = -EINVAL;
> goto unlock;
> }
>
> num_opps = dev_pm_opp_get_opp_count(dev);
> if (num_opps <= 0) {
> ret = (num_opps < 0)? num_opps : -EINVAL;
> goto unlock;
> }

And this might not work. This is what I said in the first reply.

So, a bit lengthy reply now :)

Every cpu has a device struct associated with it. When cpufreq
core initializes drivers, they ask for mapping (initializing) the opps.
At that point we pass policy->cpu to opp core. OPP core doesn't
know which cores share clock line (I am trying to solve that [1]) and
so it just initializes the OPPs for policy->cpu. Let us say it cpuX.

Now there will be few more CPUs which are going to share clock
line with it and hence will use the same OPPs. In thermal core,
you got clip_cpus which is exactly the masks of all these CPUs
sharing clock line.

If the OPP layer is good enough, then above code can work. But
because right now the OPPs are mapped to just cpuX, passing
any other cpu from clip_cpus will fail as it doesn't have any associated
OPPs.

Now what I asked you is to use the CPU for which
__cpufreq_cooling_register() is called. Normally we are calling
__cpufreq_cooling_register() for the CPU for which OPPs are
registered (but people might call it up for other CPUs as well)..

So, using that cpu *might* have worked here.

Now the earlier loop you used was good to get this information,
but it wasn't consistent and so I objected.

What you should do:

- Create another routine to find the cpu for which OPPs are bound
to
-  And save the cpu_dev for it in the global struct for cpu_cooling
- reuse it wherever required.

--
viresh

[1] https://www.marc.info/?t=14176917212=1=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: [RFC][PATCHES] iov_iter.c rewrite

[Al Viro]

On Mon, Dec 08, 2014 at 07:28:17PM +, Al Viro wrote:
> On Mon, Dec 08, 2014 at 10:57:31AM -0800, Linus Torvalds wrote:
> > So the whole "get_page()" thing is broken. Iterating over pages in a
> > KVEC is simply wrong, wrong, wrong. It needs to fail.
> 
> Well, _that_ is easy to do, of course...  E.g. by replacing that thing in
> iov_iter_get_pages()/iov_iter_get_pages_alloc() with ({ return -EFAULT; })
> will do it.

OK, folded and pushed (i.e. in vfs.git#iov_iter and vfs.git#for-next).
Matches earlier behaviour; oops reproducer is easy -

dd if=/dev/zero of=foo.ko bs=4096 count=1
cat >a.c <<'EOF'
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
main()
{
int fd = open("foo.ko", 0004);
syscall(__NR_finit_module, fd, "", 0);
}
EOF
gcc a.c
strace ./a.out

Correct behaviour (both the mainline and this series with fixes folded):
open("foo.ko", O_RDONLY|O_DIRECT)   = 3
finit_module(3, "", 0)  = -1 EFAULT (Bad address)
Incorrect one:
open("foo.ko", O_RDONLY|O_DIRECT)   = 3
finit_module(3, "", 0 
+++ killed by SIGKILL +++
Killed

with that oops reproduced.  Not sure if it's a proper LTP or xfstests fodder,
but anyway, here it is.

Incremental from previous for-next is
diff --git a/mm/iov_iter.c b/mm/iov_iter.c
index e0605c1..a1599ca 100644
--- a/mm/iov_iter.c
+++ b/mm/iov_iter.c
@@ -560,15 +560,7 @@ ssize_t iov_iter_get_pages(struct iov_iter *i,
get_page(*pages = v.bv_page);
return v.bv_len;
}),({
-   unsigned long addr = (unsigned long)v.iov_base, end;
-   size_t len = v.iov_len + (*start = addr & (PAGE_SIZE - 1));
-
-   if (len > maxpages * PAGE_SIZE)
-   len = maxpages * PAGE_SIZE;
-   addr &= ~(PAGE_SIZE - 1);
-   for (end = addr + len; addr < end; addr += PAGE_SIZE)
-   get_page(*pages++ = virt_to_page(addr));
-   return len - *start;
+   return -EFAULT;
})
)
return 0;
@@ -622,18 +614,7 @@ ssize_t iov_iter_get_pages_alloc(struct iov_iter *i,
get_page(*p = v.bv_page);
return v.bv_len;
}),({
-   unsigned long addr = (unsigned long)v.iov_base, end;
-   size_t len = v.iov_len + (*start = addr & (PAGE_SIZE - 1));
-   int n;
-
-   addr &= ~(PAGE_SIZE - 1);
-   n = DIV_ROUND_UP(len, PAGE_SIZE);
-   *pages = p = get_pages_array(n);
-   if (!p)
-   return -ENOMEM;
-   for (end = addr + len; addr < end; addr += PAGE_SIZE)
-   get_page(*p++ = virt_to_page(addr));
-   return len - *start;
+   return -EFAULT;
})
)
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 net-next 0/2] r8169:change hardware setting

[David Miller]

From: Chunhao Lin 
Date: Tue, 2 Dec 2014 16:48:29 +0800

> This patch series contains two hardware setting modification to prevent
> hardware become abnormal.

Series applied, 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 2/2 V9] intel_pstate: add kernel parameter to force loading.

[Ethan Zhao]

To force loading on Oracle Sun X86 servers, provide one kernel command line
parameter

  intel_pstate = force

For those who be aware of the risk of no power capping capabily working and
try to get better performance with this driver.

Signed-off-by: Ethan Zhao 
Tested-by: Alexey Kodanev 
Reviewed-by: Linda Knippers 
---
 v2: change to hardware vendor specific naming parameter.
 v4: refine code and doc.
 v5: fix a typo in doc.
 v7: change enum PCC to PPC.
 v8: change the name of kernel command line parameter to generic one.
 v9: refine doc

 Documentation/kernel-parameters.txt | 5 +
 drivers/cpufreq/intel_pstate.c  | 6 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 479f332..7d0983e 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1446,6 +1446,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
   disable
 Do not enable intel_pstate as the default
 scaling driver for the supported processors
+  force
+Enable intel_pstate on systems that prohibit it by 
default
+in favor of acpi-cpufreq. Forcing the intel_pstate 
driver
+instead of acpi-cpufreq may disable platform features, 
such
+as thermal controls and power capping, that rely on 
ACPI
+P-States information being indicated to OSPM and 
therefore
+should be used with caution. This option does not work 
with
+processors that aren't supported by the intel_pstate 
driver
+or on platforms that use pcc-cpufreq instead of 
acpi-cpufreq.
 
intremap=   [X86-64, Intel-IOMMU]
on  enable Interrupt Remapping (default)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 1bb62ca..2654e13 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -866,6 +866,7 @@ static struct cpufreq_driver intel_pstate_driver = {
 };
 
 static int __initdata no_load;
+static unsigned int  force_load;
 
 static int intel_pstate_msrs_not_valid(void)
 {
@@ -1003,7 +1004,8 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
case PSS:
return intel_pstate_no_acpi_pss();
case PPC:
-   return intel_pstate_has_acpi_ppc();
+   return intel_pstate_has_acpi_ppc() &&
+   (!force_load);
}
}
 
@@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
 
if (!strcmp(str, "disable"))
no_load = 1;
+   if (!strcmp(str, "force"))
+   force_load = 1;
return 0;
 }
 early_param("intel_pstate", intel_pstate_setup);
-- 
1.8.3.1

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

Re: [PATCH 2/2] Drivers: hv: balloon: Fix the deadlock issue in the memory hot-add code

[Yasuaki Ishimatsu]

(2014/12/09 0:04), Michal Hocko wrote:

On Fri 05-12-14 16:41:38, K. Y. Srinivasan wrote:

Andy Whitcroft  initially saw this deadlock. We
have seen this as well. Here is the original description of the
problem (and a potential solution) from Andy:

https://lkml.org/lkml/2014/3/14/451

Here is an excerpt from that mail:

"We are seeing machines lockup with what appears to be an ABBA
deadlock in the memory hotplug system.  These are from the 3.13.6 based Ubuntu 
kernels.
The hv_balloon driver is adding memory using add_memory() which takes
the hotplug lock


Do you mean mem_hotplug_begin?




and then emits a udev event, and then attempts to
lock the sysfs device.  In response to the udev event udev opens the
sysfs device and locks it, then attempts to grab the hotplug lock to online the 
memory.


Cannot we simply teach online_pages to fail with EBUSY when the memory
hotplug is on the way.  We shouldn't try to online something that is not
initialized yet, no?


Yes. Memory online shouldn't try before initializing it. Then memory online
should wait for initializing it, not easily fails. Generally, kernel sends
memory ONLINE event to userland by kobject_uevent() during initializing memory
and udev makes memory online after catching the event. Onlining memory by
udev almost run during initializing memory. So if memory online easily
fails, onlining memory by udev almost fails.


The memory hotplug log is global so we can get
false positives but that should be easier to deal with than exporting
lock_device_hotplug and adding yet another lock dependency.


This seems to be inverted nesting in the two cases, leading to the hangs below:

[  240.608612] INFO: task kworker/0:2:861 blocked for more than 120 seconds.
[  240.608705] INFO: task systemd-udevd:1906 blocked for more than 120 seconds.

I note that the device hotplug locking allows complete retries (via
ERESTARTSYS) and if we could detect this at the online stage it could
be used to get us out.


I am not sure I understand this but it suggests EBUSY above?


But before I go down this road I wanted to
make sure I am reading this right.  Or indeed if the hv_balloon driver
is just doing this wrong."

This patch is based on the suggestion from
Yasuaki Ishimatsu 


This changelog doesn't explain us much. And boy this whole thing is so
convoluted. E.g. I have hard time to see why ACPI hotplug is working
correctly. My trail got lost at acpi_memory_device_add level which is
a callback while acpi_device_hotplug is holding lock_device_hotplug but
then again the rest is hidden by callbacks.


Commit 0f1cfe9d0d06 (mm/hotplug: remove stop_machine() from try_offline_node()) 
said:

  ---
lock_device_hotplug() serializes hotplug & online/offline operations.  The
lock is held in common sysfs online/offline interfaces and ACPI hotplug
code paths.

And here are the code paths:

- CPU & Mem online/offline via sysfs online
store_online()->lock_device_hotplug()

- Mem online via sysfs state:
store_mem_state()->lock_device_hotplug()

- ACPI CPU & Mem hot-add:
acpi_scan_bus_device_check()->lock_device_hotplug()

- ACPI CPU & Mem hot-delete:
acpi_scan_hot_remove()->lock_device_hotplug()
  ---

CPU & Memory online/offline/hotplug are serialized by lock_device_hotplug().


I cannot seem to find any
documentation which would explain all the locking here.


Yes. I need the documentation.

Thanks,
Yasuaki Ishimatsu



So why other callers of add_memory don't need the same treatment and if
they do then why don't we use the lock at add_memory level?


Signed-off-by: K. Y. Srinivasan 


Nak to this without proper explanation and I really think that it should
be the onlining code which should deal with the parallel add_memory and
back off until the full initialization is done.


---
  drivers/hv/hv_balloon.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index afdb0d5..f525a62 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -649,8 +650,11 @@ static void hv_mem_hot_add(unsigned long start, unsigned 
long size,

release_region_mutex(false);
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
+
+   lock_device_hotplug();
ret = add_memory(nid, PFN_PHYS((start_pfn)),
(HA_CHUNK << PAGE_SHIFT));
+   unlock_device_hotplug();

if (ret) {
pr_info("hot_add memory failed error is %d\n", ret);
--
1.7.4.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [PATCH] PCI: Clear bridge MEM_64 flag if one child does not support it

[Yinghai Lu]

On Mon, Dec 8, 2014 at 5:08 PM, Gavin Shan  wrote:
> On Mon, Dec 08, 2014 at 03:59:54PM -0800, Yinghai Lu wrote:
>
> Yinghai, With the patch, the Power8 machine boots up and have resources
> assigned properly: 64-bits pref BARs are covered by 64-bits pref windows
> and left memory BARs are covered by 32-bits non-pref windows. Note that
> I didn't find an 32-bits-pref BAR on the system.
>
> For SRIOV case, Richard still need test.

Good, Thanks for the testing.

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 06/19] clk: samsung: exynos5433: Add clocks for CMU_MIF domain

[Chanwoo Choi]

Hi Pankaj,

On 12/08/2014 08:37 PM, Pankaj Dubey wrote:
> Hi Chanwoo,
> 
> On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:
>> This patch adds the mux/divider/gate clock fo CMU_MIF domain which includes
> 
> nit: %s/fo/of

I'll fix it.

> 
>> the clocks for DMC(DRAM memory controller) and CCI(Cache Coherent 
>> Interconnect).
>> The CMU_MIF domain provides the source clocks for CMU_DISP/CMU_BUS2.
>>
>> Cc: Sylwester Nawrocki 
>> Cc: Tomasz Figa 
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Inki Dae 
>> Acked-by: Geunsik Lim 
>> ---
>>   drivers/clk/samsung/clk-exynos5433.c   | 590 
>> +
>>   include/dt-bindings/clock/exynos5433.h | 190 ++-
>>   2 files changed, 779 insertions(+), 1 deletion(-)
>>
> 
> [snip]
> 
>>
>>   static struct samsung_pll_clock mif_pll_clks[] __initdata = {
>> @@ -768,9 +888,479 @@ static struct samsung_pll_clock mif_pll_clks[] 
>> __initdata = {
>>   MFC_PLL_LOCK, MFC_PLL_CON0, exynos5443_pll_rates),
>>   };
>>
>> +/* list of all parent clock list */
>> +PNAME(mout_mfc_pll_div2_p)= { "mout_mfc_pll", "dout_mfc_pll", };
>> +PNAME(mout_bus_pll_div2_p)= { "mout_bus_pll", "dout_bus_pll", };
>> +PNAME(mout_mem1_pll_div2_p)= { "mout_mem1_pll", "dout_mem1_pll", };
>> +PNAME(mout_mem0_pll_div2_p)= { "mout_mem0_pll", "dout_mem0_pll", };
>> +PNAME(mout_mfc_pll_p)= { "fin_pll", "fout_mfc_pll", };
>> +PNAME(mout_bus_pll_p)= { "fin_pll", "fout_bus_pll", };
>> +PNAME(mout_mem1_pll_p)= { "fin_pll", "fout_mem1_pll", };
>> +PNAME(mout_mem0_pll_p)= { "fin_pll", "fout_mem0_pll", };
>> +
>> +PNAME(mout_clk2x_phy_c_p)= { "mout_mem0_pll_div2", "mout_clkm_phy_b", };
>> +PNAME(mout_clk2x_phy_b_p)= { "mout_bus_pll_div2", "mout_clkm_phy_a", };
>> +PNAME(mout_clk2x_phy_a_p)= { "mout_bus_pll_div2", "mout_mfc_pll_div2", 
>> };
>> +PNAME(mout_clkm_phy_c_p)= { "mout_mem0_pll_div2", "mout_clkm_phy_b", };
> 
> As mout_clk2x_phy_c_p and mout_clkm_phy_c_p both has same parent list one of 
> them can be dropped.

OK, I'll use common parent to remove duplicat code.

> 
>> +PNAME(mout_clkm_phy_b_p)= { "mout_mem1_pll_div2", "mout_clkm_phy_a", };
>> +PNAME(mout_clkm_phy_a_p)= { "mout_bus_pll_div2", "mout_mfc_pll_div2", };
> 
> As mout_clk2x_phy_a_p and mout_clkm_phy_a_p both has same parent list one of 
> them can be dropped.

OK.

> 
>> +
>> +PNAME(mout_aclk_mifnm_200_p)= { "mout_mem0_pll_div2", "div_mif_pre", };
>> +PNAME(mout_aclk_mifnm_400_p)= { "mout_mem1_pll_div2", 
>> "mout_bus_pll_div2",};
>> +
>> +PNAME(mout_aclk_disp_333_b_p)= { "mout_aclk_disp_333_a",
>> +"mout_bus_pll_div2", };
>> +PNAME(mout_aclk_disp_333_a_p)= { "mout_mfc_pll_div2", "sclk_mphy_pll", 
>> };
>> +
>> +PNAME(mout_sclk_decon_vclk_c_p)= { "mout_sclk_decon_vclk_b",
>> +"sclk_mphy_pll", };
>> +PNAME(mout_sclk_decon_vclk_b_p)= { "mout_sclk_decon_vclk_a",
>> +"mout_mfc_pll_div2", };
>> +PNAME(mout_sclk_decon_vclk_a_p)= { "fin_pll", "mout_bus_pll_div2", };
>> +PNAME(mout_sclk_decon_eclk_c_p)= { "mout_sclk_decon_eclk_b",
>> +"sclk_mphy_pll", };
>> +PNAME(mout_sclk_decon_eclk_b_p)= { "mout_sclk_decon_eclk_a",
>> +"mout_mfc_pll_div2", };
>> +PNAME(mout_sclk_decon_eclk_a_p)= { "fin_pll", "mout_bus_pll_div2", };
>> +
>> +PNAME(mout_sclk_decon_tv_eclk_c_p) = { "mout_sclk_decon_tv_eclk_b",
>> +   "sclk_mphy_pll", };
>> +PNAME(mout_sclk_decon_tv_eclk_b_p) = { "mout_sclk_decon_tv_eclk_a",
>> +   "mout_mfc_pll_div2", };
>> +PNAME(mout_sclk_decon_tv_eclk_a_p) = { "fin_pll", "mout_bus_pll_div2", };
>> +PNAME(mout_sclk_dsd_c_p)= { "mout_sclk_dsd_b", "mout_bus_pll_div2", };
>> +PNAME(mout_sclk_dsd_b_p)= { "mout_sclk_dsd_a", "sclk_mphy_pll", };
>> +PNAME(mout_sclk_dsd_a_p)= { "fin_pll", "mout_mfc_pll_div2", };
>> +
>> +PNAME(mout_sclk_dsim0_c_p)= { "mout_sclk_dsim0_b", "sclk_mphy_pll", };
>> +PNAME(mout_sclk_dsim0_b_p)= { "mout_sclk_dsim0_a", "mout_mfc_pll_div2" 
>> };
>> +PNAME(mout_sclk_dsim0_a_p)= { "fin_pll", "mout_bus_pll_div2", };
>> +
>> +PNAME(mout_sclk_decon_tv_vclk_c_p) = { "mout_sclk_decon_tv_vclk_b",
>> +   "sclk_mphy_pll", };
>> +PNAME(mout_sclk_decon_tv_vclk_b_p) = { "mout_sclk_decon_tv_vclk_a",
>> +   "mout_mfc_pll_div2", };
>> +PNAME(mout_sclk_decon_tv_vclk_a_p) = { "fin_pll", "mout_bus_pll_div2", };
>> +PNAME(mout_sclk_dsim1_c_p)= { "mout_sclk_dsim1_b", "sclk_mphy_pll", };
>> +PNAME(mout_sclk_dsim1_b_p)= { "mout_sclk_dsim1_a", 
>> "mout_mfc_pll_div2",};
>> +PNAME(mout_sclk_dsim1_a_p)= { "fin_pll", "mout_bus_pll_div2", };
>> +
> 
> Same way I can see {"fin_pll", "mout_bus_pll_div2", } this combination of 
> parents is repeated six times above in different PNAME, which can be replaced 
> by one PNAME list with some common name, thus saving of 5 lines.

OK.

> 
>> +static 

Re: [PATCH v3 0/5] thermal: of: of-thermal.c API extensions

[Eduardo Valentin]

On Mon, Dec 08, 2014 at 06:04:16PM +0100, Lukasz Majewski wrote:
> Provided patch series extend of-thermal.c file API. It is necessary 
> for ongoing Exynos TMU rework.
> 
> First version of this code can be found at:
> http://www.spinics.net/lists/linux-samsung-soc/msg37719.html
> 
> Second version:
> http://www.spinics.net/lists/kernel/msg1872274.html
> 
> This code provides methods to access some of-thermal local data.
> Moreover it provides a read only access to of-thermal trip points.
> 
> Lukasz Majewski (5):
>   thermal: of: Extend of-thermal.c to provide number of trip points
>   thermal: of: Extend of-thermal.c to provide check if trip point is
> valid
>   thermal: of: Rename struct __thermal_trip to struct thermal_trip
>   thermal: of: Extend of-thermal to export table of trip points
>   thermal: of: Extend current of-thermal.c code to allow setting
> emulated temp

Applied the series in my -linus branch.

Cheers

> 
>  drivers/thermal/of-thermal.c   | 109 
> ++---
>  drivers/thermal/thermal_core.h |  18 +++
>  include/linux/thermal.h|  18 +++
>  3 files changed, 127 insertions(+), 18 deletions(-)
> 
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH] staging: ion: ion_cma_heap: remove ion_cma_get_sgtable

[Joe Perches]

On Tue, 2014-12-09 at 09:19 +0800, Zeng Tao wrote:
> Remove the temporary code ion_cma_get_sgtable,
> use dma_common_get_sgtable instead
[]
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
> b/drivers/staging/android/ion/ion_cma_heap.c
[]
> @@ -91,7 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
> ion_buffer *buffer,
>   if (!info->table)
>   goto free_mem;
>  
> - if (ion_cma_get_sgtable
> + if (dma_common_get_sgtable
>   (dev, info->table, info->cpu_addr, info->handle, len))
>   goto free_table;
>   /* keep this for memory release */

somewhat unrelated trivia:

It'd conform a bit more to kernel style to
write this with at least one argument on the
same line as the function like:

if (dma_common_get_sgtable(dev, info->table, info->cpu_addr,
   info->handle, len))
goto  free_table;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next] udp: Neaten and reduce size of compute_score functions

[David Miller]

From: Joe Perches 
Date: Mon, 01 Dec 2014 20:29:06 -0800

> The compute_score functions are a bit difficult to read.
> 
> Neaten them a bit to reduce object sizes and make them a
> bit more intelligible.
> 
> Return early to avoid indentation and avoid unnecessary
> initializations.
> 
> (allyesconfig, but w/ -O2 and no profiling)
> 
> $ size net/ipv[46]/udp.o.*
>textdata bss dec hex filename
>   286801184  25   2988974c1 net/ipv4/udp.o.new
>   287561184  25   29965750d net/ipv4/udp.o.old
>   176001010   2   1861248b4 net/ipv6/udp.o.new
>   176321010   2   1864448d4 net/ipv6/udp.o.old
> 
> Signed-off-by: Joe Perches 

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

Re: [PATCH net-next] hyperv: Add support for vNIC hot removal

[David Miller]

From: Haiyang Zhang 
Date: Mon,  1 Dec 2014 13:28:39 -0800

> This patch adds proper handling of the vNIC hot removal event, which includes
> a rescind-channel-offer message from the host side that triggers vNIC close 
> and
> removal. In this case, the notices to the host during close and removal is not
> necessary because the channel is rescinded. This patch blocks these 
> unnecessary 
> messages, and lets vNIC removal process complete normally.
> 
> Signed-off-by: Haiyang Zhang 
> Reviewed-by: K. Y. Srinivasan 

Applied, 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] staging: ion: ion_cma_heap: remove ion_cma_get_sgtable

[Zeng Tao]

Remove the temporary code ion_cma_get_sgtable,
use dma_common_get_sgtable instead

Signed-off-by: Zeng Tao 
---
 drivers/staging/android/ion/ion_cma_heap.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index f8cabcb..f4211f1 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,24 +39,6 @@ struct ion_cma_buffer_info {
struct sg_table *table;
 };
 
-/*
- * Create scatter-list for the already allocated DMA buffer.
- * This function could be replaced by dma_common_get_sgtable
- * as soon as it will avalaible.
- */
-static int ion_cma_get_sgtable(struct device *dev, struct sg_table *sgt,
-  void *cpu_addr, dma_addr_t handle, size_t size)
-{
-   struct page *page = virt_to_page(cpu_addr);
-   int ret;
-
-   ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
-   if (unlikely(ret))
-   return ret;
-
-   sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
-   return 0;
-}
 
 /* ION CMA heap operations functions */
 static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -91,7 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (!info->table)
goto free_mem;
 
-   if (ion_cma_get_sgtable
+   if (dma_common_get_sgtable
(dev, info->table, info->cpu_addr, info->handle, len))
goto free_table;
/* keep this for memory release */
-- 
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 05/19] clk: samsung: exynos5433: Add clocks for CMU_G2D domain

[Chanwoo Choi]

Hi Pankaj,

On 12/08/2014 08:36 PM, Pankaj Dubey wrote:
> Hi Chanwoo,
> 
> On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:
>> This patch adds ths mux/divider/gate clocksof CMU_G2D domain which includes
> 
> nit: %s/clocksof/clocks of

I'll fix it.

> 
>> G2D/MDMA IPs. The CMU_G2D must need the clocks related to G2D by providing
>> CMU_TOP domain. So, this patch add several clocks for G2D from CMU_TOP 
>> domain.
>>
>> Cc: Sylwester Nawrocki 
>> Cc: Tomasz Figa 
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Inki Dae 
>> Acked-by: Geunsik Lim 
>> ---
>>   .../devicetree/bindings/clock/exynos5433-clock.txt |   8 ++
>>   drivers/clk/samsung/clk-exynos5433.c   | 144 
>> +
>>   include/dt-bindings/clock/exynos5433.h |  42 +-
>>   3 files changed, 193 insertions(+), 1 deletion(-)
>>
> 
> Verified all changes in clock file against UM I have with me, all changes are 
> OK.
> 
> With small nit in commit message feel free to add:
> 
> Reviewed-by: Pankaj Dubey 

Thanks for your review.

Best Regards,
Chanwoo Choi


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

Re: [PATCH 04/19] clk: samsung: exynos5433: Add clocks for CMU_PERIS domain

[Chanwoo Choi]

Hi Pankaj,

On 12/08/2014 08:32 PM, Pankaj Dubey wrote:
> Hi Chanwoo,
> 
> On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:
>> This patch adds missing gate clocks of CMU_PERIS domain
>> which includes TMU/TZPC/SECKEY/CHIPID/TOPRTC/EFUSE IPs.
>> The special clocks of CMU_PERIS use fin_pll source clock directly.
>>
>> Cc: Sylwester Nawrocki 
>> Cc: Tomasz Figa 
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Inki Dae 
>> Acked-by: Geunsik Lim 
>> ---
>>   drivers/clk/samsung/clk-exynos5433.c   | 146 
>> -
>>   include/dt-bindings/clock/exynos5433.h |  33 +++-
>>   2 files changed, 176 insertions(+), 3 deletions(-)
>>
> 
> Verified all registers and clock relationship against UM I have, and changes 
> are OK.
> 
> Reviewed-by: Pankaj Dubey 

Thanks for your review.

Best Regards,
Chanwoo Choi

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

Re: [PATCH 03/19] clk: samsung: exynos5433: Add clocks for CMU_PERIC domain

[Chanwoo Choi]

Hi Pankaj,

On 12/08/2014 08:31 PM, Pankaj Dubey wrote:
> Hi Chanwoo,
> 
> On Tuesday 02 December 2014 02:19 PM, Chanwoo Choi wrote:
>> This patch adds missing divider/gate clocks of CMU_PERIC domain
>> which includes I2S/PCM/SPDIF/PWM/SLIMBUS IPs. The SPI/I2S may use
>> external input clock which has 'ioclk_*' prefix.
>>
>> Cc: Sylwester Nawrocki 
>> Cc: Tomasz Figa 
>> Signed-off-by: Chanwoo Choi 
>> [ideal.song: Change clk flags of to pclk_gpio_* clk, pclk_gpio_* should be 
>> always on.]
>> Signed-off-by: Inha Song 
>> Acked-by: Inki Dae 
>> Acked-by: Geunsik Lim 
>> ---
>>   drivers/clk/samsung/clk-exynos5433.c   | 80 
>> +-
>>   include/dt-bindings/clock/exynos5433.h | 34 ++-
>>   2 files changed, 112 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5433.c 
>> b/drivers/clk/samsung/clk-exynos5433.c
>> index 88e8cac..a48b36c 100644
>> --- a/drivers/clk/samsung/clk-exynos5433.c
>> +++ b/drivers/clk/samsung/clk-exynos5433.c
>> @@ -256,6 +256,14 @@ static struct samsung_fixed_rate_clock top_fixed_clks[] 
>> __initdata = {
>>   FRATE(0, "ioclk_audiocdclk0", NULL, CLK_IS_ROOT, 1),
>>   /* Xi2s1SDI input clock for SPDIF */
>>   FRATE(0, "ioclk_spdif_extclk", NULL, CLK_IS_ROOT, 1),
>> +/* XspiCLK[4:0] input clock for SPI */
>> +FRATE(0, "ioclk_spi4_clk_in", NULL, CLK_IS_ROOT, 5000),
>> +FRATE(0, "ioclk_spi3_clk_in", NULL, CLK_IS_ROOT, 5000),
>> +FRATE(0, "ioclk_spi2_clk_in", NULL, CLK_IS_ROOT, 5000),
>> +FRATE(0, "ioclk_spi1_clk_in", NULL, CLK_IS_ROOT, 5000),
>> +FRATE(0, "ioclk_spi0_clk_in", NULL, CLK_IS_ROOT, 5000),
>> +/* Xi2s1SCLK input clock for I2S1_BCLK */
>> +FRATE(0, "ioclk_i2s1_bclk_in", NULL, CLK_IS_ROOT, 12288000),
>>   };
>>
>>   static struct samsung_mux_clock top_mux_clks[] __initdata = {
>> @@ -760,6 +768,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif, 
>> "samsung,exynos5433-cmu-mif",
>>* Register offset definitions for CMU_PERIC
>>*/
>>   #define DIV_PERIC0x0600
>> +#define DIV_STAT_PERIC0x0700
>>   #define ENABLE_ACLK_PERIC0x0800
>>   #define ENABLE_PCLK_PERIC00x0900
>>   #define ENABLE_PCLK_PERIC10x0904
>> @@ -770,6 +779,7 @@ CLK_OF_DECLARE(exynos5433_cmu_mif, 
>> "samsung,exynos5433-cmu-mif",
>>
>>   static unsigned long peric_clk_regs[] __initdata = {
>>   DIV_PERIC,
>> +DIV_STAT_PERIC,
> 
> IMO, this line should have been added in first place itself when you added 
> peric_clk_regs.

Why? I want to locate it according to address base.

> 
>>   ENABLE_ACLK_PERIC,
>>   ENABLE_PCLK_PERIC0,
>>   ENABLE_PCLK_PERIC1,
>> @@ -779,14 +789,57 @@ static unsigned long peric_clk_regs[] __initdata = {
>>   ENABLE_IP_PERIC2,
>>   };
>>
>> +static struct samsung_div_clock peric_div_clks[] __initdata = {
>> +/* DIV_PERIC */
>> +DIV(CLK_DIV_SCLK_SCI, "div_sclk_sci", "fin_pll", DIV_PERIC, 4, 8),
> 
> As per UM I have DIV_SCLK_SCI has 4 bit wide as [7:4] please cross verify.

You're right. It is my mistake. I'll fix it.

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

[PATCH -next] ASoC: Intel: fix sparse non static symbol warnings

[weiyj_lk]

From: Wei Yongjun 

Fixes the following sparse warnings:

sound/soc/intel/sst/sst_acpi.c:248:5: warning:
 symbol 'sst_acpi_probe' was not declared. Should it be static?
sound/soc/intel/sst/sst_acpi.c:335:5: warning:
 symbol 'sst_acpi_remove' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 sound/soc/intel/sst/sst_acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/intel/sst/sst_acpi.c b/sound/soc/intel/sst/sst_acpi.c
index 31124aa..98a8f66 100644
--- a/sound/soc/intel/sst/sst_acpi.c
+++ b/sound/soc/intel/sst/sst_acpi.c
@@ -245,7 +245,7 @@ static struct sst_machines *sst_acpi_find_machine(
return NULL;
 }
 
-int sst_acpi_probe(struct platform_device *pdev)
+static int sst_acpi_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
int ret = 0;
@@ -332,7 +332,7 @@ do_sst_cleanup:
 * This function is called by OS when a device is unloaded
 * This frees the interrupt etc
 */
-int sst_acpi_remove(struct platform_device *pdev)
+static int sst_acpi_remove(struct platform_device *pdev)
 {
struct intel_sst_drv *ctx;
 

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