Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic

[David Hildenbrand]

> On Thu, 27 Nov 2014, David Hildenbrand wrote:
> > > OTOH, there is no reason why we need to disable preemption over that
> > > page_fault_disabled() region. There are code pathes which really do
> > > not require to disable preemption for that.
> > > 
> > > We have that seperated in preempt-rt for obvious reasons and IIRC
> > > Peter Zijlstra tried to distangle it in mainline some time ago. I
> > > forgot why that never got merged.
> > > 
> > 
> > Of course, we can completely separate that in our page fault code by doing
> > pagefault_disabled() checks instead of in_atomic() checks (even in add on
> > patches later).
> > 
> > > We tie way too much stuff on the preemption count already, which is a
> > > mightmare because we have no clear distinction of protection
> > > scopes. 
> > 
> > Although it might not be optimal, but keeping a separate counter for
> > pagefault_disable() as part of the preemption counter seems to be the only
> > doable thing right now.
> 
> It needs to be seperate, if it should be useful. Otherwise we just
> have a extra accounting in preempt_count() which does exactly the same
> thing as we have now: disabling preemption.
> 
> Now you might say, that we could mask out that part when checking
> preempt_count, but that wont work on x86 as x86 has the preempt
> counter as a per cpu variable and not as a per thread one.

Ah right, it's per cpu on x86. So it really belongs to a thread if we want to
demangle preemption and pagefault_disable.

Would work for now, but for x86 not on the long run.

> 
> But if you want to distangle pagefault disable from preempt disable
> then you must move it to the thread, because it is a property of the
> thread. preempt count is very much a per cpu counter as you can only
> go through schedule when it becomes 0.

Thinking about it, this makes perfect sense!

> 
> Btw, I find the x86 representation way more clear, because it
> documents that preempt count is a per cpu BKL and not a magic thread
> property. And sadly that is how preempt count is used ...
> 
> > I am not sure if a completely separated counter is even possible,
> > increasing the size of thread_info.
> 
> And adding a ulong to thread_info is going to create exactly which
> problem?

If we're allowed to increase the size of thread_info - absolutely fine with me!
(I am not sure if some archs have special constraints on the size)

Will see what I can come up with.

Thanks!

> 
> Thanks,
> 
>   tglx
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/8] mm/debug-pagealloc: prepare boottime configurable on/off

[Joonsoo Kim]

On Thu, Nov 27, 2014 at 01:35:39PM +0100, Paul Bolle wrote:
> Joonsoo,
> 
> On Mon, 2014-11-24 at 17:15 +0900, Joonsoo Kim wrote:
> > Until now, debug-pagealloc needs extra flags in struct page, so we need
> > to recompile whole source code when we decide to use it. This is really
> > painful, because it takes some time to recompile and sometimes rebuild is
> > not possible due to third party module depending on struct page.
> > So, we can't use this good feature in many cases.
> > 
> > Now, we have the page extension feature that allows us to insert
> > extra flags to outside of struct page. This gets rid of third party module
> > issue mentioned above. And, this allows us to determine if we need extra
> > memory for this page extension in boottime. With these property, we can
> > avoid using debug-pagealloc in boottime with low computational overhead
> > in the kernel built with CONFIG_DEBUG_PAGEALLOC. This will help our
> > development process greatly.
> > 
> > This patch is the preparation step to achive above goal. debug-pagealloc
> > originally uses extra field of struct page, but, after this patch, it
> > will use field of struct page_ext. Because memory for page_ext is
> > allocated later than initialization of page allocator in CONFIG_SPARSEMEM,
> > we should disable debug-pagealloc feature temporarily until initialization
> > of page_ext. This patch implements this.
> > 
> > v2: fix compile error on CONFIG_PAGE_POISONING
> > 
> > Signed-off-by: Joonsoo Kim 
> 
> This patch is included in today's linux-next (ie, next-2o0141127) as
> commit 1e491e9be4c9 ("mm/debug-pagealloc: prepare boottime configurable
> on/off").
> 
> > [...]
> > 
> > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> > index 33a8acf..c7b22e7 100644
> > --- a/include/linux/mm_types.h
> > +++ b/include/linux/mm_types.h
> > @@ -10,7 +10,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -186,9 +185,6 @@ struct page {
> > void *virtual;  /* Kernel virtual address (NULL if
> >not kmapped, ie. highmem) */
> >  #endif /* WANT_PAGE_VIRTUAL */
> > -#ifdef CONFIG_WANT_PAGE_DEBUG_FLAGS
> > -   unsigned long debug_flags;  /* Use atomic bitops on this */
> > -#endif
> >  
> >  #ifdef CONFIG_KMEMCHECK
> > /*
> > diff --git a/include/linux/page-debug-flags.h 
> > b/include/linux/page-debug-flags.h
> > deleted file mode 100644
> > index 22691f61..000
> > --- a/include/linux/page-debug-flags.h
> > +++ /dev/null
> > @@ -1,32 +0,0 @@
> > -#ifndef LINUX_PAGE_DEBUG_FLAGS_H
> > -#define  LINUX_PAGE_DEBUG_FLAGS_H
> > -
> > -/*
> > - * page->debug_flags bits:
> > - *
> > - * PAGE_DEBUG_FLAG_POISON is set for poisoned pages. This is used to
> > - * implement generic debug pagealloc feature. The pages are filled with
> > - * poison patterns and set this flag after free_pages(). The poisoned
> > - * pages are verified whether the patterns are not corrupted and clear
> > - * the flag before alloc_pages().
> > - */
> > -
> > -enum page_debug_flags {
> > -   PAGE_DEBUG_FLAG_POISON, /* Page is poisoned */
> > -   PAGE_DEBUG_FLAG_GUARD,
> > -};
> > -
> > -/*
> > - * Ensure that CONFIG_WANT_PAGE_DEBUG_FLAGS reliably
> > - * gets turned off when no debug features are enabling it!
> > - */
> > -
> > -#ifdef CONFIG_WANT_PAGE_DEBUG_FLAGS
> > -#if !defined(CONFIG_PAGE_POISONING) && \
> > -!defined(CONFIG_PAGE_GUARD) \
> > -/* && !defined(CONFIG_PAGE_DEBUG_SOMETHING_ELSE) && ... */
> > -#error WANT_PAGE_DEBUG_FLAGS is turned on with no debug features!
> > -#endif
> > -#endif /* CONFIG_WANT_PAGE_DEBUG_FLAGS */
> > -
> > -#endif /* LINUX_PAGE_DEBUG_FLAGS_H */
> 
> This remove all uses of CONFIG_WANT_PAGE_DEBUG_FLAGS and
> CONFIG_PAGE_GUARD. So the Kconfig symbols WANT_PAGE_DEBUG_FLAGS and
> PAGE_GUARD are now unused.
> 
> Should I submit the trivial patch to remove these symbols or is a patch
> that does that queued already?

Hello, Paul.

Thanks for spotting this.
I attach the patch. :)

Andrew,
Could you kindly fold this into the patch in your tree?

Thanks.

--->8---
>From a33c480160904cc9807a448960151ac4c534 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim 
Date: Fri, 28 Nov 2014 16:05:32 +0900
Subject: [PATCH] mm/debug_pagealloc: remove obsolete Kconfig options

These are obsolete since commit "mm/debug-pagealloc: prepare boottime
configurable" is merged. So, remove it.

[pebo...@tiscali.nl: find obsolete Kconfig options]
Signed-off-by: Joonsoo Kim 
---
 mm/Kconfig.debug |9 -
 1 file changed, 9 deletions(-)

diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 56badfc..957d3da 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -14,7 +14,6 @@ config DEBUG_PAGEALLOC
depends on !KMEMCHECK
select PAGE_EXTENSION
select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC
-   select PAGE_GUARD if ARCH_SUPPORTS_DEBUG_PAGEALLOC

Re: [Patch v2 2/2] gpio: Document GPIO hogging mechanism

[Alexandre Courbot]

On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot  wrote:
> Add GPIO hogging documentation to gpio.txt
>
> Signed-off-by: Benoit Parrot 
> ---
> Changes since v1:
>  * Split the devicetree bindings documentation in its own patch.
>
>  Documentation/devicetree/bindings/gpio/gpio.txt | 25 
> +
>  1 file changed, 25 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt 
> b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 3fb8f53..82755e2 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -103,6 +103,24 @@ Every GPIO controller node must contain both an empty 
> "gpio-controller"
>  property, and a #gpio-cells integer property, which indicates the number of
>  cells in a gpio-specifier.
>
> +The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
> +providing automatic GPIO request and configuration as part of the
> +gpio-controller's driver probe function.
> +
> +Each GPIO hog definition is represented as a child node of the GPIO 
> controller.
> +Required properties:
> +- gpio-hog: a property specifying that this child node represent a gpio-hog.
> +- gpios: store the gpio information (id, flags, ...). Shall contain the
> +  number of cells specified in its parent node (GPIO controller node).
> +- input: a property specifying to set the GPIO direction as input.
> +- output-high: a property specifying to set the GPIO direction to output with
> +  the value high.
> +- output-low: a property specifying to set the GPIO direction to output with
> +  the value low.
> +
> +Optional properties:
> +- line-name: the GPIO label name. If not present the node name is used.
> +
>  Example of two SOC GPIO banks defined as gpio-controller nodes:
>
> qe_pio_a: gpio-controller@1400 {
> @@ -110,6 +128,13 @@ Example of two SOC GPIO banks defined as gpio-controller 
> nodes:
> reg = <0x1400 0x18>;
> gpio-controller;
> #gpio-cells = <2>;
> +
> +   line_b: line_b {

Mmm what is the label used for? Can this node ever be referenced from
somewhere else?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v2 1/2] gpio: add GPIO hogging mechanism

[Alexandre Courbot]

On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot  wrote:
> Based on Boris Brezillion's work this is a reworked patch
> of his initial GPIO hogging mechanism.
> This patch provides a way to initally configure specific GPIO
> when the gpio controller is probed.
>
> The actual DT scanning to collect the GPIO specific data is performed
> as part of the gpiochip_add().
>
> The purpose of this is to allows specific GPIOs to be configured
> without any driver specific code.
> This particularly useful because board design are getting
> increasingly complex and given SoC pins can now have upward
> of 10 mux values a lot of connections are now dependent on
> external IO muxes to switch various modes and combination.
>
> Specific drivers should not necessarily need to be aware of
> what accounts to a specific board implementation. This board level
> "description" should be best kept as part of the dts file.
>
> Signed-off-by: Benoit Parrot 
> ---
> Changes since v1:
>  * Refactor the gpio-hog mechanism as private functions meant to
>be to invoked from of_gpiochip_add().
>
>  drivers/gpio/gpiolib-of.c | 188 
> ++
>  1 file changed, 188 insertions(+)
>
> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
> index 604dbe6..3caed76 100644
> --- a/drivers/gpio/gpiolib-of.c
> +++ b/drivers/gpio/gpiolib-of.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "gpiolib.h"
>
> @@ -111,6 +112,184 @@ int of_get_named_gpio_flags(struct device_node *np, 
> const char *list_name,
>  EXPORT_SYMBOL(of_get_named_gpio_flags);
>
>  /**
> + * of_get_gpio_hog() - Get a GPIO hog descriptor, names and flags for GPIO 
> API
> + * @np:device node to get GPIO from
> + * @name:  GPIO line name
> + * @flags: a flags pointer to fill in
> + *
> + * Returns GPIO descriptor to use with Linux GPIO API, or one of the errno
> + * value on the error condition.
> + */
> +
> +static struct gpio_desc *of_get_gpio_hog(struct device_node *np,
> + const char **name,
> + enum gpio_lookup_flags *lflags,
> + enum gpiod_flags *dflags)
> +{
> +   struct device_node *chip_np;
> +   enum of_gpio_flags xlate_flags;
> +   struct gpio_desc *desc;
> +   struct gg_data gg_data = {
> +   .flags = _flags,
> +   .out_gpio = NULL,
> +   };
> +   u32 tmp;
> +   int i, in, outlo, outhi;
> +   int ret;
> +
> +   if (!np)
> +   return ERR_PTR(-EINVAL);

This function is being called from a perfectly mastered context in
this file, so maybe we can avoid this check.

> +
> +   chip_np = np->parent;
> +   if (!chip_np) {
> +   desc = ERR_PTR(-EINVAL);
> +   goto out;
> +   }
> +
> +   if (!lflags || !dflags) {
> +   desc = ERR_PTR(-EINVAL);
> +   goto out;
> +   }

Same for this one.

> +
> +   *lflags = 0;
> +   *dflags = 0;
> +   in = 0;
> +   outlo = 0;
> +   outhi = 0;
> +
> +   ret = of_property_read_u32(chip_np, "#gpio-cells", );
> +   if (ret) {
> +   desc = ERR_PTR(ret);
> +   goto out;

Please use "return ERR_PTR(ret);" directly, since you do absolutely no
cleanup in out:. Same remark everywhere it applies.

> +   }
> +
> +   if (tmp > MAX_PHANDLE_ARGS) {
> +   desc = ERR_PTR(-EINVAL);
> +   goto out;
> +   }
> +
> +   gg_data.gpiospec.args_count = tmp;
> +   gg_data.gpiospec.np = chip_np;
> +   for (i = 0; i < tmp; i++) {
> +   ret = of_property_read_u32(np, "gpios",
> +  _data.gpiospec.args[i]);
> +   if (ret) {
> +   desc = ERR_PTR(ret);
> +   goto out;
> +   }
> +   }
> +
> +   gpiochip_find(_data, of_gpiochip_find_and_xlate);

This seems to work but only supports one GPIO per hog node. It would
be nice to be able to specify several GPIOs to which the same settings
need to be applied.

> +   if (!gg_data.out_gpio) {
> +   if (np->parent == np)
> +   desc = ERR_PTR(-ENXIO);
> +   else
> +   desc = ERR_PTR(-EPROBE_DEFER);
> +   goto out;
> +   }
> +
> +   if (xlate_flags & OF_GPIO_ACTIVE_LOW)
> +   *lflags |= GPIOF_ACTIVE_LOW;
> +
> +   if (of_property_read_bool(np, "input")) {
> +   *dflags |= GPIOD_IN;
> +   in = 1;
> +   }
> +   if (of_property_read_bool(np, "output-low")) {
> +   *dflags |= GPIOD_OUT_LOW;
> +   outlo = 1;
> +   }
> +   if (of_property_read_bool(np, "output-high")) {
> +   *dflags |= GPIOD_OUT_HIGH;
> +   outhi = 1;
> +   }

I thought we agreed that this should be a "direction =

Re: [PATCH] Drivers:Staging:rtl8188eu:hal:usb_halinit.c: Added blank line after declarations

[Sudip Mukherjee]

On Thu, Nov 27, 2014 at 08:13:03PM +0530, Anjana Sasindran wrote:
> This patch fixes the five checkpatch.pl warnings:
> 
> WARNING:Missing a blank line after declaration
> 
> Signed-off-by: Anjana Sasindran 
> ---
>  drivers/staging/rtl8188eu/hal/usb_halinit.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c 
> b/drivers/staging/rtl8188eu/hal/usb_halinit.c
> index 14650e9..439828c 100644
> --- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
> +++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
> @@ -1931,6 +1931,7 @@ GetHalDefVar8188EUsb(
>   case HW_DEF_RA_INFO_DUMP:
>   {
>   u8 entry_id = *((u8 *)pValue);
> +
>   if (check_fwstate(>mlmepriv, _FW_LINKED)) {
>   DBG_88E(" RA status check 
> ===\n");
>   DBG_88E("Mac_id:%d , RateID = %d, RAUseRate = 
> 0x%08x, RateSGI = %d, DecisionRate = 0x%02x ,PTStage = %d\n",
> @@ -1946,6 +1947,7 @@ GetHalDefVar8188EUsb(
>   case HW_DEF_ODM_DBG_FLAG:
>   {
>   struct odm_dm_struct *dm_ocm = &(haldata->odmpriv);
> +
>   pr_info("dm_ocm->DebugComponents = 0x%llx\n", 
> dm_ocm->DebugComponents);
>   }
>   break;
> @@ -1994,6 +1996,7 @@ static u8 SetHalDefVar8188EUsb(struct adapter *Adapter, 
> enum hal_def_variable eV
>   } else if (dm_func == 6) {/* turn on all dynamic func */
>   if (!(podmpriv->SupportAbility  & 
> DYNAMIC_BB_DIG)) {
>   struct rtw_dig *pDigTable = 
> >DM_DigTable;
> +
>   pDigTable->CurIGValue = 
> usb_read8(Adapter, 0xc50);
>   }
>   podmpriv->SupportAbility = 
> DYNAMIC_ALL_FUNC_ENABLE;
> @@ -2011,6 +2014,7 @@ static u8 SetHalDefVar8188EUsb(struct adapter *Adapter, 
> enum hal_def_variable eV
>   {
>   u8 bRSSIDump = *((u8 *)pValue);
>   struct odm_dm_struct *dm_ocm = &(haldata->odmpriv);
> +
>   if (bRSSIDump)
>   dm_ocm->DebugComponents =   
> ODM_COMP_DIG|ODM_COMP_FA_CNT;
>   else
> @@ -2021,7 +2025,9 @@ static u8 SetHalDefVar8188EUsb(struct adapter *Adapter, 
> enum hal_def_variable eV
>   {
>   u64 DebugComponents = *((u64 *)pValue);
>   struct odm_dm_struct *dm_ocm = &(haldata->odmpriv);
> +
>   dm_ocm->DebugComponents = DebugComponents;
> +
any reason to give this blank line here? This is not a declaration.

thanks
sudip
>   }
>   break;
>   default:
> -- 
> 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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: replace magic number with PAGE_SHIFT macro in fixup_pv code

[Nicolas Pitre]

On Fri, 28 Nov 2014, Masahiro Yamada wrote:

> This line converts PHYS_OFFSET into PHYS_PFN_OFFSET.
> It is better to use PAGE_SHIFT rather than the magic number 12.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Nicolas Pitre 


> ---
> 
>  arch/arm/kernel/head.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index 664eee8..ecb7be8 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -586,7 +586,7 @@ __fixup_pv_table:
>   add r5, r5, r3  @ adjust table end address
>   add r6, r6, r3  @ adjust __pv_phys_pfn_offset address
>   add r7, r7, r3  @ adjust __pv_offset address
> - mov r0, r8, lsr #12 @ convert to PFN
> + mov r0, r8, lsr #PAGE_SHIFT @ convert to PFN
>   str r0, [r6]@ save computed PHYS_OFFSET to 
> __pv_phys_pfn_offset
>   strcc   ip, [r7, #HIGH_OFFSET]  @ save to __pv_offset high bits
>   mov r6, r3, lsr #24 @ constant for add/sub instructions
> -- 
> 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 2/3] ARM: edma: Rename header file for dmaengine filter function definition

[Peter Ujfalusi]

On 11/27/2014 11:52 PM, Arnd Bergmann wrote:
> On Thursday 27 November 2014 20:46:12 Peter Ujfalusi wrote:
>>
>> I see. With this series I did not planed to fix all edma related issues, just
>> as a start clean up the related header files. I would rather not add fixes to
>> mmc, spi, etc drivers since while you have valid point it is not in the scope
>> of this series.
>> Can we do the changes you are suggesting in an incremental manner?
> 
> Sure, but I'd leave the existing filter function declaration alone then
> and not move it, since we wouldn't want to keep it in the long run.

but if you want to reference the filter function (which is in
drivers/dma/edma.c) in arch/arm/mach-davinci/ directory, we will need it.
Don't we?

If I leave the header as it is, then how would we clean up the edma headers? I
would not put the API definitions for the arch code into the same file as we
have the filter definition.


> 
>   Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


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

Re: [PATCH] ARM: decompressor: fix a wrong comment

[Nicolas Pitre]

On Fri, 28 Nov 2014, Masahiro Yamada wrote:

> This comment does not correspond to the actual code.
> 
> When zImage is loaded at a lower *OR* higher address of
> the destination of Image, it won't overwrite itself.
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Nicolas Pitre 


> ---
> 
>  arch/arm/boot/compressed/head.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 68be901..9dff614 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -178,7 +178,7 @@ not_angel:
>  
>   /*
>* Set up a page table only if it won't overwrite ourself.
> -  * That means r4 < pc && r4 - 16k page directory > &_end.
> +  * That means r4 < pc || r4 - 16k page directory > &_end.
>* Given that r4 > &_end is most unfrequent, we add a rough
>* additional 1MB of room for a possible appended DTB.
>*/
> -- 
> 1.9.1
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] perf record: Show precise number of samples

[Namhyung Kim]

After perf record finishes, it prints file size and number of samples
in the file but this info is wrong since it assumes typical sample
size of 24 bytes and divides file size by the value.

However as we post-process recorded samples for build-id, it can show
correct number like below.  If build-id post-processing is not requested
just omit the wrong number of samples.

  $ perf record noploop 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.159 MB perf.data (3989 samples) ]

  $ perf report --stdio -n
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  # Samples: 3K of event 'cycles'
  # Event count (approx.): 3771330663
  #
  # Overhead   Samples  Command  Shared Object Symbol
  #     ...    
..
  #
  99.90%  3982  noploop  noploop   [.] main
   0.09% 1  noploop  ld-2.17.so[.] 
_dl_check_map_versions
   0.01% 1  noploop  [kernel.vmlinux]  [k] setup_arg_pages
   0.00% 5  noploop  [kernel.vmlinux]  [k] intel_pmu_enable_all

Reported-by: Milian Wolff 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 53 ++---
 1 file changed, 40 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 1134de22979e..f88f5ccb96dc 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -190,6 +190,19 @@ static int record__open(struct record *rec)
return rc;
 }
 
+static int process_sample_event(struct perf_tool *tool,
+   union perf_event *event,
+   struct perf_sample *sample,
+   struct perf_evsel *evsel,
+   struct machine *machine)
+{
+   struct record *rec = container_of(tool, struct record, tool);
+
+   rec->samples++;
+
+   return build_id__mark_dso_hit(tool, event, sample, evsel, machine);
+}
+
 static int process_buildids(struct record *rec)
 {
struct perf_data_file *file  = >file;
@@ -200,6 +213,7 @@ static int process_buildids(struct record *rec)
return 0;
 
file->size = size;
+   rec->samples = 0;
 
/*
 * During this process, it'll load kernel map and replace the
@@ -212,7 +226,7 @@ static int process_buildids(struct record *rec)
 */
symbol_conf.ignore_vmlinux_buildid = true;
 
-   return perf_session__process_events(session, 
_id__mark_dso_hit_ops);
+   return perf_session__process_events(session, >tool);
 }
 
 static void perf_event__synthesize_guest_os(struct machine *machine, void 
*data)
@@ -503,19 +517,9 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
goto out_child;
}
 
-   if (!quiet) {
+   if (!quiet)
fprintf(stderr, "[ perf record: Woken up %ld times to write 
data ]\n", waking);
 
-   /*
-* Approximate RIP event size: 24 bytes.
-*/
-   fprintf(stderr,
-   "[ perf record: Captured and wrote %.3f MB %s (~%" 
PRIu64 " samples) ]\n",
-   (double)rec->bytes_written / 1024.0 / 1024.0,
-   file->path,
-   rec->bytes_written / 24);
-   }
-
 out_child:
if (forks) {
int exit_status;
@@ -535,10 +539,26 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
status = err;
 
if (!err && !file->is_pipe) {
+   bool print_nr_samples = false;
+
rec->session->header.data_size += rec->bytes_written;
 
-   if (!rec->no_buildid)
+   if (!rec->no_buildid) {
process_buildids(rec);
+   print_nr_samples = true;
+   }
+
+   if (!quiet) {
+   fprintf(stderr, "[ perf record: Captured and wrote %.3f 
MB %s",
+   (double)rec->bytes_written / 1024.0 / 1024.0,
+   file->path);
+
+   if (print_nr_samples)
+   fprintf(stderr, " (%"PRIu64" samples)", 
rec->samples);
+
+   fputs(" ]\n", stderr);
+   }
+
perf_session__write_header(rec->session, rec->evlist,
   file->fd, true);
}
@@ -719,6 +739,13 @@ static struct record record = {
.default_per_cpu = true,
},
},
+   .tool = {
+   .sample = process_sample_event,
+   .fork   = perf_event__process_fork,
+   .comm   = perf_event__process_comm,
+   .mmap   = perf_event__process_mmap,
+ 

[PATCH 2/2] perf record: Show precise number of samples

[Namhyung Kim]

After perf record finishes, it prints file size and number of samples
in the file but this info is wrong since it assumes typical sample
size of 24 bytes and divides file size by the value.

However as we post-process recorded samples for build-id, it can show
correct number like below.  If build-id post-processing is not requested
just omit the wrong number of samples.

  $ perf record noploop 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.159 MB perf.data (3989 samples) ]

  $ perf report --stdio -n
  # To display the perf.data header info, please use --header/--header-only 
options.
  #
  # Samples: 3K of event 'cycles'
  # Event count (approx.): 3771330663
  #
  # Overhead   Samples  Command  Shared Object Symbol
  #     ...    
..
  #
  99.90%  3982  noploop  noploop   [.] main
   0.09% 1  noploop  ld-2.17.so[.] 
_dl_check_map_versions
   0.01% 1  noploop  [kernel.vmlinux]  [k] setup_arg_pages
   0.00% 5  noploop  [kernel.vmlinux]  [k] intel_pmu_enable_all

Reported-by: Milian Wolff 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 50 +
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 1134de22979e..e4e2b5b583b3 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -190,6 +190,19 @@ static int record__open(struct record *rec)
return rc;
 }
 
+static int process_sample_event(struct perf_tool *tool,
+   union perf_event *event,
+   struct perf_sample *sample,
+   struct perf_evsel *evsel,
+   struct machine *machine)
+{
+   struct record *rec = container_of(tool, struct record, tool);
+
+   rec->samples++;
+
+   return build_id__mark_dso_hit(tool, event, sample, evsel, machine);
+}
+
 static int process_buildids(struct record *rec)
 {
struct perf_data_file *file  = >file;
@@ -200,6 +213,7 @@ static int process_buildids(struct record *rec)
return 0;
 
file->size = size;
+   rec->samples = 0;
 
/*
 * During this process, it'll load kernel map and replace the
@@ -212,7 +226,7 @@ static int process_buildids(struct record *rec)
 */
symbol_conf.ignore_vmlinux_buildid = true;
 
-   return perf_session__process_events(session, 
_id__mark_dso_hit_ops);
+   return perf_session__process_events(session, >tool);
 }
 
 static void perf_event__synthesize_guest_os(struct machine *machine, void 
*data)
@@ -503,19 +517,9 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
goto out_child;
}
 
-   if (!quiet) {
+   if (!quiet)
fprintf(stderr, "[ perf record: Woken up %ld times to write 
data ]\n", waking);
 
-   /*
-* Approximate RIP event size: 24 bytes.
-*/
-   fprintf(stderr,
-   "[ perf record: Captured and wrote %.3f MB %s (~%" 
PRIu64 " samples) ]\n",
-   (double)rec->bytes_written / 1024.0 / 1024.0,
-   file->path,
-   rec->bytes_written / 24);
-   }
-
 out_child:
if (forks) {
int exit_status;
@@ -537,8 +541,21 @@ static int __cmd_record(struct record *rec, int argc, 
const char **argv)
if (!err && !file->is_pipe) {
rec->session->header.data_size += rec->bytes_written;
 
-   if (!rec->no_buildid)
+   if (!rec->no_buildid) {
process_buildids(rec);
+
+   if (!quiet) {
+   fprintf(stderr, "[ perf record: Captured and 
wrote %.3f MB %s (%"PRIu64" samples) ]\n",
+   (double)rec->bytes_written / 1024.0 / 
1024.0,
+   file->path, rec->samples);
+   }
+   }
+   if (!quiet) {
+   fprintf(stderr, "[ perf record: Captured and wrote %.3f 
MB %s ]\n",
+   (double)rec->bytes_written / 1024.0 / 1024.0,
+   file->path);
+   }
+
perf_session__write_header(rec->session, rec->evlist,
   file->fd, true);
}
@@ -719,6 +736,13 @@ static struct record record = {
.default_per_cpu = true,
},
},
+   .tool = {
+   .sample = process_sample_event,
+   .fork   = perf_event__process_fork,
+   .comm   = perf_event__process_comm,
+   .mmap   = 

[PATCH 1/2] perf tools: Do not use __perf_session__process_events() directly

[Namhyung Kim]

It's only used for perf record to process build-id because its file
size it's not fixed at this time due to remaining header features.
However data offset and size is available so that we can use the
perf_session__process_events() once we set the file size as the
current offset like for now.

Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-record.c | 7 +++
 tools/perf/util/session.c   | 6 +++---
 tools/perf/util/session.h   | 3 ---
 3 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 8648c6d3003d..1134de22979e 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -194,12 +194,13 @@ static int process_buildids(struct record *rec)
 {
struct perf_data_file *file  = >file;
struct perf_session *session = rec->session;
-   u64 start = session->header.data_offset;
 
u64 size = lseek(file->fd, 0, SEEK_CUR);
if (size == 0)
return 0;
 
+   file->size = size;
+
/*
 * During this process, it'll load kernel map and replace the
 * dso->long_name to a real pathname it found.  In this case
@@ -211,9 +212,7 @@ static int process_buildids(struct record *rec)
 */
symbol_conf.ignore_vmlinux_buildid = true;
 
-   return __perf_session__process_events(session, start,
- size - start,
- size, 
_id__mark_dso_hit_ops);
+   return perf_session__process_events(session, 
_id__mark_dso_hit_ops);
 }
 
 static void perf_event__synthesize_guest_os(struct machine *machine, void 
*data)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 6ac62ae6b8fa..88aa2f09df93 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1252,9 +1252,9 @@ fetch_mmaped_event(struct perf_session *session,
 #define NUM_MMAPS 128
 #endif
 
-int __perf_session__process_events(struct perf_session *session,
-  u64 data_offset, u64 data_size,
-  u64 file_size, struct perf_tool *tool)
+static int __perf_session__process_events(struct perf_session *session,
+ u64 data_offset, u64 data_size,
+ u64 file_size, struct perf_tool *tool)
 {
int fd = perf_data_file__fd(session->file);
u64 head, page_offset, file_offset, file_pos, size;
diff --git a/tools/perf/util/session.h b/tools/perf/util/session.h
index dc26ebf60fe4..6d663dc76404 100644
--- a/tools/perf/util/session.h
+++ b/tools/perf/util/session.h
@@ -49,9 +49,6 @@ int perf_session__peek_event(struct perf_session *session, 
off_t file_offset,
 union perf_event **event_ptr,
 struct perf_sample *sample);
 
-int __perf_session__process_events(struct perf_session *session,
-  u64 data_offset, u64 data_size, u64 size,
-  struct perf_tool *tool);
 int perf_session__process_events(struct perf_session *session,
 struct perf_tool *tool);
 
-- 
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: [regression] Boot crash with: f7426b983a6a ("mm: cma: adjust address limit to avoid hitting low/high memory boundary")

[Joonsoo Kim]

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",

> 
> Thanks,
> 
>   Ingo
> 
> * Ingo Molnar  wrote:
> 
> > In x86 randconfig boot testing on a generic whitebox PC I started 
> > seeing the following new early boot crash, starting in this merge 
> > window:
> > 
> > ...
> > init_memory_mapping: [mem 0x37c0-0x37d33fff]
> >  [mem 0x37c0-0x37d33fff] page 4k
> > BRK [0x02a36000, 0x02a36fff] PGTABLE
> > 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
> > Stack:   (null) c1ed7f1c c1fccd26   (null)   (null)   (null)   (null) 
> > 00134000
> >  (null) 37c0 37d34000   (null)   (null) 3fff c2a09600 
> > 0665b000
> >  (null) c1ed7f3c c1fe9b6e   (null)   (null)   (null) c2a09600 
> > 0665b000
> > CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0+ #241217
> > Hardware name: System manufacturer System Product Name/A8N-E, BIOS ASUS 
> > A8N-E ACPI BIOS Revision 1008 08/22/2005
> >    c1ed7e88 c1902dfd 4000 c1ed7edc c1fad1f7 c2023431
> >  0006 00f06f53  0665b000 c1ed7edc 4000 c1ed7ed8 007b
> >  007b c2022c18 37d34000  0006  c102b62e 0060
> > 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
> > Press any key to enter the menu
> > 
> > and bisected it down to:
> > 
> >  f7426b983a6a353cf21e5733e84458219c4a817e is the first bad commit
> >  commit f7426b983a6a353cf21e5733e84458219c4a817e
> >  Author: Marek Szyprowski 
> >  Date:   Thu Oct 9 15:26:47 2014 -0700
> > 
> > mm: cma: adjust address limit to avoid hitting low/high memory boundary
> > 
> > Russell King recently noticed that limiting default CMA region only to 
> > low
> > memory on ARM architecture causes serious memory management issues with
> > machines having a lot of memory (which is mainly available as high
> > memory).  More information can be found the following thread:
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/348441/
> > 
> > Those two patches removes this limit letting kernel to put default CMA
> > region into high memory when this is possible (there is enough high 
> > memory
> > available and architecture specific DMA limit fits).
> > 
> > [...]
> > 
> > The offending commit does not revert cleanly.
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hv: hv_fcopy: drop the obsolete message on transfer failure

[Jason Wang]

On Thu, Nov 27, 2014 at 9:09 PM, Dexuan Cui  wrote:

In the case the user-space daemon crashes, hangs or is killed, we
need to down the semaphore, otherwise, after the daemon starts next
time, the obsolete data in fcopy_transaction.message or
fcopy_transaction.fcopy_msg will be used immediately.

Cc: Jason Wang 
Cc: Vitaly Kuznetsov 
Cc: K. Y. Srinivasan 
Signed-off-by: Dexuan Cui 
---

v2: I removed the "FCP" prefix as Greg asked.

I also updated the output message a little:
"FCP: failed to acquire the semaphore" --> 
"can not acquire the semaphore: it is benign"


v3: I added the code in fcopy_release() as Jason Wang suggested.
I removed the pr_debug (it isn't so meaningful)and added a 
comment instead.


 drivers/hv/hv_fcopy.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/hv/hv_fcopy.c b/drivers/hv/hv_fcopy.c
index 23b2ce2..faa6ba6 100644
--- a/drivers/hv/hv_fcopy.c
+++ b/drivers/hv/hv_fcopy.c
@@ -86,6 +86,18 @@ static void fcopy_work_func(struct work_struct 
*dummy)

 * process the pending transaction.
 */
fcopy_respond_to_host(HV_E_FAIL);
+
+   /* In the case the user-space daemon crashes, hangs or is killed, we
+	 * need to down the semaphore, otherwise, after the daemon starts 
next

+* time, the obsolete data in fcopy_transaction.message or
+* fcopy_transaction.fcopy_msg will be used immediately.
+*
+	 * NOTE: fcopy_read() happens to get the semaphore (very rare)? 
We're

+* still OK, because we've reported the failure to the host.
+*/
+   if (down_trylock(_transaction.read_sema))
+   ;


Sorry, I'm not quite understand how if () ; can help here.

Btw, a question not relate to this patch.

What happens if a daemon is resume from SIGSTOP and expires the check 
here?


+
 }
 
 static int fcopy_handle_handshake(u32 version)
@@ -351,6 +363,13 @@ static int fcopy_release(struct inode *inode, 
struct file *f)

 */
in_hand_shake = true;
opened = false;
+
+   if (cancel_delayed_work_sync(_work)) {
+   /* We haven't up()-ed the semaphore(very rare)? */
+   if (down_trylock(_transaction.read_sema))
+   ;


And this.


+   fcopy_respond_to_host(HV_E_FAIL);
+   }
return 0;
 }
 
--

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/


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

[PATCH v2 2/2] mmc: rtsx: add support for sdio card

[micky_ching]

From: Micky Ching 

Add support for sdio card by SD interface. The main change is data
transfer mode, When read data, host wait data transfer while command
start. When write data, host will start data transfer after command get
response. The transfer mode modify can be applied both for SD/MMC card
and sdio card.

Signed-off-by: Micky Ching 
---
 drivers/mmc/host/rtsx_pci_sdmmc.c | 523 +-
 1 file changed, 288 insertions(+), 235 deletions(-)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index c70b602..b780779 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -71,30 +72,79 @@ static inline void sd_clear_error(struct realtek_pci_sdmmc 
*host)
 }
 
 #ifdef DEBUG
-static void sd_print_debug_regs(struct realtek_pci_sdmmc *host)
+static void dump_reg_range(struct realtek_pci_sdmmc *host, u16 start, u16 end)
 {
-   struct rtsx_pcr *pcr = host->pcr;
-   u16 i;
-   u8 *ptr;
+   u16 len = end - start + 1;
+   int i;
+   u8 data[8];
 
-   /* Print SD host internal registers */
-   rtsx_pci_init_cmd(pcr);
-   for (i = 0xFDA0; i <= 0xFDAE; i++)
-   rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
-   for (i = 0xFD52; i <= 0xFD69; i++)
-   rtsx_pci_add_cmd(pcr, READ_REG_CMD, i, 0, 0);
-   rtsx_pci_send_cmd(pcr, 100);
-
-   ptr = rtsx_pci_get_cmd_data(pcr);
-   for (i = 0xFDA0; i <= 0xFDAE; i++)
-   dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
-   for (i = 0xFD52; i <= 0xFD69; i++)
-   dev_dbg(sdmmc_dev(host), "0x%04X: 0x%02x\n", i, *(ptr++));
+   if (!data)
+   return;
+
+   for (i = 0; i < len; i += 8) {
+   int j;
+   int n = min(8, len - i);
+
+   memset(, 0, sizeof(data));
+   for (j = 0; j < n; j++)
+   rtsx_pci_read_register(host->pcr, start + i + j,
+   data + j);
+   dev_dbg(sdmmc_dev(host), "0x%04X(%d): %8ph\n", start, n, data);
+   }
+}
+
+static void sd_print_debug_regs(struct realtek_pci_sdmmc *host)
+{
+   dump_reg_range(host, 0xFDA0, 0xFDB3);
+   dump_reg_range(host, 0xFD52, 0xFD69);
 }
 #else
 #define sd_print_debug_regs(host)
 #endif /* DEBUG */
 
+static void sd_cmd_set_sd_cmd(struct rtsx_pcr *pcr, struct mmc_command *cmd)
+{
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_CMD0, 0xFF, SD_CMD_START | 
cmd->opcode);
+   rtsx_pci_write_be32(pcr, SD_CMD1, cmd->arg);
+}
+
+static void sd_cmd_set_data_len(struct rtsx_pcr *pcr, u16 blocks, u16 blksz)
+{
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_BLOCK_CNT_L, 0xFF, blocks);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_BLOCK_CNT_H, 0xFF, blocks >> 8);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_BYTE_CNT_L, 0xFF, blksz);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_BYTE_CNT_H, 0xFF, blksz >> 8);
+}
+
+static int sd_response_type(struct mmc_command *cmd)
+{
+   switch (mmc_resp_type(cmd)) {
+   case MMC_RSP_NONE:
+   return SD_RSP_TYPE_R0;
+   case MMC_RSP_R1:
+   return SD_RSP_TYPE_R1;
+   case MMC_RSP_R1 & ~MMC_RSP_CRC:
+   return SD_RSP_TYPE_R1 | SD_NO_CHECK_CRC7;
+   case MMC_RSP_R1B:
+   return SD_RSP_TYPE_R1b;
+   case MMC_RSP_R2:
+   return SD_RSP_TYPE_R2;
+   case MMC_RSP_R3:
+   return SD_RSP_TYPE_R3;
+   default:
+   return -EINVAL;
+   }
+}
+
+static int sd_status_index(int resp_type)
+{
+   if (resp_type == SD_RSP_TYPE_R0)
+   return 0;
+   else if (resp_type == SD_RSP_TYPE_R2)
+   return 16;
+
+   return 5;
+}
 /*
  * sd_pre_dma_transfer - do dma_map_sg() or using cookie
  *
@@ -166,123 +216,6 @@ static void sdmmc_post_req(struct mmc_host *mmc, struct 
mmc_request *mrq,
data->host_cookie = 0;
 }
 
-static int sd_read_data(struct realtek_pci_sdmmc *host, u8 *cmd, u16 byte_cnt,
-   u8 *buf, int buf_len, int timeout)
-{
-   struct rtsx_pcr *pcr = host->pcr;
-   int err, i;
-   u8 trans_mode;
-
-   dev_dbg(sdmmc_dev(host), "%s: SD/MMC CMD%d\n", __func__, cmd[0] - 0x40);
-
-   if (!buf)
-   buf_len = 0;
-
-   if ((cmd[0] & 0x3F) == MMC_SEND_TUNING_BLOCK)
-   trans_mode = SD_TM_AUTO_TUNING;
-   else
-   trans_mode = SD_TM_NORMAL_READ;
-
-   rtsx_pci_init_cmd(pcr);
-
-   for (i = 0; i < 5; i++)
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_CMD0 + i, 0xFF, cmd[i]);
-
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_BYTE_CNT_L, 0xFF, (u8)byte_cnt);
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_BYTE_CNT_H,
-   0xFF, (u8)(byte_cnt >> 8));
-   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, SD_BLOCK_CNT_L, 0xFF, 1);
-  

[PATCH v2 0/2] mmc: rtsx: add support for sdio card

[micky_ching]

From: Micky Ching 

v2:
  rtsx_pci.h:
- remove unused rtsx_pci_write_le32
- add SD_CMD_START
  rtsx_pci_sdmmc.c:
- dump_reg_range
  - alloc data on stack
- remove forward declaration
- use SD_CMD_START replace magic number 0x40
- move initialize assignment to error handling

This patch is used to change transfer mode for sdio card support
by SD interface.

Micky Ching (2):
  mfd: rtsx: add func to split u32 into register
  mmc: rtsx: add support for sdio card

 drivers/mmc/host/rtsx_pci_sdmmc.c | 523 +-
 include/linux/mfd/rtsx_pci.h  |   9 +
 2 files changed, 297 insertions(+), 235 deletions(-)

-- 
1.9.1

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

[PATCH v2 1/2] mfd: rtsx: add func to split u32 into register

[micky_ching]

From: Micky Ching 

Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.

Signed-off-by: Micky Ching 
---
 include/linux/mfd/rtsx_pci.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..9234449 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -558,6 +558,7 @@
 #define SD_SAMPLE_POINT_CTL0xFDA7
 #define SD_PUSH_POINT_CTL  0xFDA8
 #define SD_CMD00xFDA9
+#define   SD_CMD_START 0x40
 #define SD_CMD10xFDAA
 #define SD_CMD20xFDAB
 #define SD_CMD30xFDAC
@@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr 
*pcr)
return (u8 *)(pcr->host_cmds_ptr);
 }
 
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32 val)
+{
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val >> 24);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val >> 16);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val >> 8);
+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
 #endif
-- 
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/

linux-next: manual merge of the usb tree with the driver-core tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the usb tree got a conflict in
drivers/usb/chipidea/core.c between commit 5bc879a6a271 ("usb:
chipidea: drop owner assignment from platform_drivers") from the
driver-core tree and commit 8076932ff2fc ("usb: chipidea: add system
power management support") from the usb tree.

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

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

diff --cc drivers/usb/chipidea/core.c
index 947ed6e78be2,e14eafb2a05e..
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@@ -751,6 -867,8 +867,7 @@@ static struct platform_driver ci_hdrc_d
.remove = ci_hdrc_remove,
.driver = {
.name   = "ci_hdrc",
+   .pm = _pm_ops,
 -  .owner  = THIS_MODULE,
},
  };
  


pgp4reomZkXuZ.pgp
Description: OpenPGP digital signature

[PATCH] nf_log_ipv6: correct typo in module description

[Steven Noonan]

It incorrectly identifies itself as "IPv4" packet logging.

Signed-off-by: Steven Noonan 
---
 net/ipv6/netfilter/nf_log_ipv6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/netfilter/nf_log_ipv6.c b/net/ipv6/netfilter/nf_log_ipv6.c
index 7b17a0b..41b9ade 100644
--- a/net/ipv6/netfilter/nf_log_ipv6.c
+++ b/net/ipv6/netfilter/nf_log_ipv6.c
@@ -412,6 +412,6 @@ module_init(nf_log_ipv6_init);
 module_exit(nf_log_ipv6_exit);
 
 MODULE_AUTHOR("Netfilter Core Team ");
-MODULE_DESCRIPTION("Netfilter IPv4 packet logging");
+MODULE_DESCRIPTION("Netfilter IPv6 packet logging");
 MODULE_LICENSE("GPL");
 MODULE_ALIAS_NF_LOGGER(AF_INET6, 0);
-- 
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/

linux-next: manual merge of the tty tree with the devicetree tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the tty tree got a conflict in
Documentation/devicetree/bindings/serial/pl011.txt between commit
a81a6c654bbe ("ARM: dt: fix up PL011 device tree bindings") from the
devicetree tree and commit 98267d33e2da ("serial: pl011: Add device
tree support for RX DMA polling") from the tty tree.

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

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

diff --cc Documentation/devicetree/bindings/serial/pl011.txt
index 52464918cfe2,0e05340055e1..
--- a/Documentation/devicetree/bindings/serial/pl011.txt
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@@ -6,34 -6,17 +6,39 @@@ Required properties
  - interrupts: exactly one interrupt specifier
  
  Optional properties:
 -- pinctrl:When present, must have one state named "sleep"
 -  and one state named "default"
 -- clocks: When present, must refer to exactly one clock named
 -  "apb_pclk"
 -- dmas:   When present, may have one or two dma channels.
 -  The first one must be named "rx", the second one
 -  must be named "tx".
 +- pinctrl: When present, must have one state named "default",
 + and may contain a second name named "sleep". The former
 + state sets up pins for ordinary operation whereas
 + the latter state will put the associated pins to sleep
 + when the UART is unused
 +- clocks:  When present, the first clock listed must correspond to
 + the clock named UARTCLK on the IP block, i.e. the clock
 + to the external serial line, whereas the second clock
 + must correspond to the PCLK clocking the internal logic
 + of the block. Just listing one clock (the first one) is
 + deprecated.
 +- clocks-names: When present, the first clock listed must be named
 + "uartclk" and the second clock listed must be named
 + "apb_pclk"
 +- dmas:  When present, may have one or two dma channels.
 + The first one must be named "rx", the second one
 + must be named "tx".
+ - auto-poll:  Enables polling when using RX DMA.
+ - poll-rate-ms:   Rate at which poll occurs when auto-poll is set,
+   default 100ms.
+ - poll-timeout-ms:Poll timeout when auto-poll is set, default
+   3000ms.
  
  See also bindings/arm/primecell.txt
 +
 +Example:
 +
 +uart@8012 {
 +  compatible = "arm,pl011", "arm,primecell";
 +  reg = <0x8012 0x1000>;
 +  interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
 +  dmas = < 13 0 0x2>, < 13 0 0x0>;
 +  dma-names = "rx", "tx";
 +  clocks = <_clk>, <_clk>;
 +  clock-names = "uartclk", "apb_pclk";
 +};


pgpjjhe_aaXA9.pgp
Description: OpenPGP digital signature

[PATCH] ARM: decompressor: fix a wrong comment

[Masahiro Yamada]

This comment does not correspond to the actual code.

When zImage is loaded at a lower *OR* higher address of
the destination of Image, it won't overwrite itself.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/compressed/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 68be901..9dff614 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -178,7 +178,7 @@ not_angel:
 
/*
 * Set up a page table only if it won't overwrite ourself.
-* That means r4 < pc && r4 - 16k page directory > &_end.
+* That means r4 < pc || r4 - 16k page directory > &_end.
 * Given that r4 > &_end is most unfrequent, we add a rough
 * additional 1MB of room for a possible appended DTB.
 */
-- 
1.9.1

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

[PATCH] ARM: replace magic number with PAGE_SHIFT macro in fixup_pv code

[Masahiro Yamada]

This line converts PHYS_OFFSET into PHYS_PFN_OFFSET.
It is better to use PAGE_SHIFT rather than the magic number 12.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/kernel/head.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 664eee8..ecb7be8 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -586,7 +586,7 @@ __fixup_pv_table:
add r5, r5, r3  @ adjust table end address
add r6, r6, r3  @ adjust __pv_phys_pfn_offset address
add r7, r7, r3  @ adjust __pv_offset address
-   mov r0, r8, lsr #12 @ convert to PFN
+   mov r0, r8, lsr #PAGE_SHIFT @ convert to PFN
str r0, [r6]@ save computed PHYS_OFFSET to 
__pv_phys_pfn_offset
strcc   ip, [r7, #HIGH_OFFSET]  @ save to __pv_offset high bits
mov r6, r3, lsr #24 @ constant for add/sub instructions
-- 
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 net] bpf: x86: fix epilogue generation for eBPF programs

[Alexei Starovoitov]

On Thu, Nov 27, 2014 at 1:52 AM, Daniel Borkmann  wrote:
> On 11/27/2014 06:02 AM, Alexei Starovoitov wrote:
>>
>> classic BPF has a restriction that last insn is always BPF_RET.
>> eBPF doesn't have BPF_RET instruction and this restriction.
>> It has BPF_EXIT insn which can appear anywhere in the program
>> one or more times and it doesn't have to be last insn.
>> Fix eBPF JIT to emit epilogue when first BPF_EXIT is seen
>> and all other BPF_EXIT instructions will be emitted as jump.
>>
>> Signed-off-by: Alexei Starovoitov 
>> ---
>> Note, this bug is applicable only to native eBPF programs
>> which first were introduced in 3.18, so no need to send it
>> to stable and therefore no 'Fixes' tag.
>
>
> Btw, even if it's not sent to -stable, a 'Fixes:' tag is useful
> information for backporting and regression tracking, preferably
> always mentioned where it can clearly be identified.

Well I didn't mention it, as I said, because I don't think it
needs backporting. Otherwise with the tag the tools might
pick it up automatically? Just a guess.
Anyway:
Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")

>> arm64 JIT has the same problem, but the fix is not as trivial,
>> so will be done as separate patch.
>>
>> Since 3.18 can only load eBPF programs and cannot execute them,
>> this patch can even be done in net-next only, but I think it's worth
>> to apply it to 3.18(net), so that JITed output for native eBPF
>> programs is correct when bpf syscall loads it with
>> net.core.bpf_jit_enable=2
>
>
> Yes, sounds good to me, the condition insn_cnt - 1 is still held
> with BPF to eBPF transformations.

Correct. That's what I meant that prior to 3.18 it's not needed.
and 'insn_cnt - 1' condition will still hold for classic in the future.

>>   arch/x86/net/bpf_jit_comp.c |6 --
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> index 3f62734..7e90244 100644
>> --- a/arch/x86/net/bpf_jit_comp.c
>> +++ b/arch/x86/net/bpf_jit_comp.c
>> @@ -178,7 +178,7 @@ static void jit_fill_hole(void *area, unsigned int
>> size)
>>   }
>>
>>   struct jit_context {
>> -   unsigned int cleanup_addr; /* epilogue code offset */
>> +   int cleanup_addr; /* epilogue code offset */
>
>
> Why this type change here? This seems a bit out of context (I would
> have expected a mention of this in the commit message, otherwise).

Ok. Will respin with updated commit msg.
The reason for signed is the following:
jmp offset to epilogue is computed as:
jmp_offset = ctx->cleanup_addr - addrs[i]
when cleanup_addr was always last insn it wasn't a problem,
since result of subtraction was positive.
Now, since epilogue will be in the middle of JITed
code the jmps to epilogue may be negative, so
signed int is need to do the math correctly.
In other words, it should be:
(long long) ((int)20 - (int)30)
instead of:
(long long) ((unsigned int)20 - (int)30)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v10 6/6] arm64: add seccomp support

[AKASHI Takahiro]

secure_computing() is called first in syscall_trace_enter() so that
a system call will be aborted quickly without doing succeeding syscall
tracing if seccomp rules want to deny that system call.

On compat task, syscall numbers for system calls allowed in seccomp mode 1
are different from those on normal tasks, and so _NR_seccomp_xxx_32's need
to be redefined.

Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/Kconfig   |   14 ++
 arch/arm64/include/asm/seccomp.h |   25 +
 arch/arm64/include/asm/unistd.h  |3 +++
 arch/arm64/kernel/ptrace.c   |5 +
 4 files changed, 47 insertions(+)
 create mode 100644 arch/arm64/include/asm/seccomp.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..f495d3c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -37,6 +37,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
+   select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_BPF_JIT
select HAVE_C_RECORDMCOUNT
@@ -345,6 +346,19 @@ config ARCH_HAS_CACHE_LINE_SIZE
 
 source "mm/Kconfig"
 
+config SECCOMP
+   bool "Enable seccomp to safely compute untrusted bytecode"
+   ---help---
+ This kernel feature is useful for number crunching applications
+ that may need to compute untrusted bytecode during their
+ execution. By using pipes or other transports made available to
+ the process as file descriptors supporting the read/write
+ syscalls, it's possible to isolate those applications in
+ their own address space using seccomp. Once seccomp is
+ enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
+ and the task is only allowed to execute a few safe syscalls
+ defined by each seccomp mode.
+
 config XEN_DOM0
def_bool y
depends on XEN
diff --git a/arch/arm64/include/asm/seccomp.h b/arch/arm64/include/asm/seccomp.h
new file mode 100644
index 000..c76fac9
--- /dev/null
+++ b/arch/arm64/include/asm/seccomp.h
@@ -0,0 +1,25 @@
+/*
+ * arch/arm64/include/asm/seccomp.h
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _ASM_SECCOMP_H
+#define _ASM_SECCOMP_H
+
+#include 
+
+#ifdef CONFIG_COMPAT
+#define __NR_seccomp_read_32   __NR_compat_read
+#define __NR_seccomp_write_32  __NR_compat_write
+#define __NR_seccomp_exit_32   __NR_compat_exit
+#define __NR_seccomp_sigreturn_32  __NR_compat_rt_sigreturn
+#endif /* CONFIG_COMPAT */
+
+#include 
+
+#endif /* _ASM_SECCOMP_H */
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 6d2bf41..49c9aef 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -31,6 +31,9 @@
  * Compat syscall numbers used by the AArch64 kernel.
  */
 #define __NR_compat_restart_syscall0
+#define __NR_compat_exit   1
+#define __NR_compat_read   3
+#define __NR_compat_write  4
 #define __NR_compat_sigreturn  119
 #define __NR_compat_rt_sigreturn   173
 
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index f576781..d882b83 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1149,6 +1150,10 @@ static void tracehook_report_syscall(struct pt_regs 
*regs,
 
 asmlinkage int syscall_trace_enter(struct pt_regs *regs)
 {
+   /* Do the secure computing check first; failures should be fast. */
+   if (secure_computing() == -1)
+   return -1;
+
if (test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
 
-- 
1.7.9.5

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

[PATCH v10 5/6] arm64: add SIGSYS siginfo for compat task

[AKASHI Takahiro]

SIGSYS is primarily used in secure computing to notify tracer of syscall
events. This patch allows signal handler on compat task to get correct
information with SA_SIGINFO specified when this signal is delivered.

Reviewed-by: Kees Cook 
Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/include/asm/compat.h |7 +++
 arch/arm64/kernel/signal32.c|6 ++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 56de5aa..3fb053f 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -205,6 +205,13 @@ typedef struct compat_siginfo {
compat_long_t _band;/* POLL_IN, POLL_OUT, POLL_MSG 
*/
int _fd;
} _sigpoll;
+
+   /* SIGSYS */
+   struct {
+   compat_uptr_t _call_addr; /* calling user insn */
+   int _syscall;   /* triggering system call number */
+   compat_uint_t _arch;/* AUDIT_ARCH_* of syscall */
+   } _sigsys;
} _sifields;
 } compat_siginfo_t;
 
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 1b9ad02..5a1ba6e 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -186,6 +186,12 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, 
const siginfo_t *from)
err |= __put_user(from->si_uid, >si_uid);
err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr, 
>si_ptr);
break;
+   case __SI_SYS:
+   err |= __put_user((compat_uptr_t)(unsigned long)
+   from->si_call_addr, >si_call_addr);
+   err |= __put_user(from->si_syscall, >si_syscall);
+   err |= __put_user(from->si_arch, >si_arch);
+   break;
default: /* this is just in case for now ... */
err |= __put_user(from->si_pid, >si_pid);
err |= __put_user(from->si_uid, >si_uid);
-- 
1.7.9.5

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

[PATCH v10 4/6] arm64: add seccomp syscall for compat task

[AKASHI Takahiro]

This patch allows compat task to issue seccomp() system call.

Reviewed-by: Kees Cook 
Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/include/asm/unistd32.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index 9dfdac4..8893ceb 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -787,7 +787,8 @@ __SYSCALL(__NR_sched_setattr, sys_sched_setattr)
 __SYSCALL(__NR_sched_getattr, sys_sched_getattr)
 #define __NR_renameat2 382
 __SYSCALL(__NR_renameat2, sys_renameat2)
-   /* 383 for seccomp */
+#define __NR_seccomp 383
+__SYSCALL(__NR_seccomp, sys_seccomp)
 #define __NR_getrandom 384
 __SYSCALL(__NR_getrandom, sys_getrandom)
 #define __NR_memfd_create 385
-- 
1.7.9.5

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

[PATCH v10 1/6] arm64: ptrace: add NT_ARM_SYSTEM_CALL regset

[AKASHI Takahiro]

This regeset is intended to be used to get and set a system call number
while tracing.
There was some discussion about possible approaches to do so:

(1) modify x8 register with ptrace(PTRACE_SETREGSET) indirectly,
and update regs->syscallno later on in syscall_trace_enter(), or
(2) define a dedicated regset for this purpose as on s390, or
(3) support ptrace(PTRACE_SET_SYSCALL) as on arch/arm

Thinking of the fact that user_pt_regs doesn't expose 'syscallno' to
tracer as well as that secure_computing() expects a changed syscall number,
especially case of -1, to be visible before this function returns in
syscall_trace_enter(), (1) doesn't work well.
We will take (2) since it looks much cleaner.

Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/kernel/ptrace.c |   35 +++
 include/uapi/linux/elf.h   |1 +
 2 files changed, 36 insertions(+)

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 8a4ae8e..f576781 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -551,6 +551,32 @@ static int tls_set(struct task_struct *target, const 
struct user_regset *regset,
return ret;
 }
 
+static int system_call_get(struct task_struct *target,
+  const struct user_regset *regset,
+  unsigned int pos, unsigned int count,
+  void *kbuf, void __user *ubuf)
+{
+   int syscallno = task_pt_regs(target)->syscallno;
+
+   return user_regset_copyout(, , , ,
+  , 0, -1);
+}
+
+static int system_call_set(struct task_struct *target,
+  const struct user_regset *regset,
+  unsigned int pos, unsigned int count,
+  const void *kbuf, const void __user *ubuf)
+{
+   int syscallno, ret;
+
+   ret = user_regset_copyin(, , , , , 0, -1);
+   if (ret)
+   return ret;
+
+   task_pt_regs(target)->syscallno = syscallno;
+   return ret;
+}
+
 enum aarch64_regset {
REGSET_GPR,
REGSET_FPR,
@@ -559,6 +585,7 @@ enum aarch64_regset {
REGSET_HW_BREAK,
REGSET_HW_WATCH,
 #endif
+   REGSET_SYSTEM_CALL,
 };
 
 static const struct user_regset aarch64_regsets[] = {
@@ -608,6 +635,14 @@ static const struct user_regset aarch64_regsets[] = {
.set = hw_break_set,
},
 #endif
+   [REGSET_SYSTEM_CALL] = {
+   .core_note_type = NT_ARM_SYSTEM_CALL,
+   .n = 1,
+   .size = sizeof(int),
+   .align = sizeof(int),
+   .get = system_call_get,
+   .set = system_call_set,
+   },
 };
 
 static const struct user_regset_view user_aarch64_view = {
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index ea9bf25..71e1d0e 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -397,6 +397,7 @@ typedef struct elf64_shdr {
 #define NT_ARM_TLS 0x401   /* ARM TLS register */
 #define NT_ARM_HW_BREAK0x402   /* ARM hardware breakpoint 
registers */
 #define NT_ARM_HW_WATCH0x403   /* ARM hardware watchpoint 
registers */
+#define NT_ARM_SYSTEM_CALL 0x404   /* ARM system call number */
 #define NT_METAG_CBUF  0x500   /* Metag catch buffer registers */
 #define NT_METAG_RPIPE 0x501   /* Metag read pipeline state */
 #define NT_METAG_TLS   0x502   /* Metag TLS pointer */
-- 
1.7.9.5

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

[PATCH v10 3/6] asm-generic: add generic seccomp.h for secure computing mode 1

[AKASHI Takahiro]

Those values (__NR_seccomp_*) are used solely in secure_computing()
to identify mode 1 system calls. If compat system calls have different
syscall numbers, asm/seccomp.h may override them.

Acked-by: Arnd Bergmann 
Reviewed-by: Kees Cook 
Signed-off-by: AKASHI Takahiro 
---
 include/asm-generic/seccomp.h |   30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 include/asm-generic/seccomp.h

diff --git a/include/asm-generic/seccomp.h b/include/asm-generic/seccomp.h
new file mode 100644
index 000..9fa1f65
--- /dev/null
+++ b/include/asm-generic/seccomp.h
@@ -0,0 +1,30 @@
+/*
+ * include/asm-generic/seccomp.h
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _ASM_GENERIC_SECCOMP_H
+#define _ASM_GENERIC_SECCOMP_H
+
+#include 
+
+#if defined(CONFIG_COMPAT) && !defined(__NR_seccomp_read_32)
+#define __NR_seccomp_read_32   __NR_read
+#define __NR_seccomp_write_32  __NR_write
+#define __NR_seccomp_exit_32   __NR_exit
+#define __NR_seccomp_sigreturn_32  __NR_rt_sigreturn
+#endif /* CONFIG_COMPAT && ! already defined */
+
+#define __NR_seccomp_read  __NR_read
+#define __NR_seccomp_write __NR_write
+#define __NR_seccomp_exit  __NR_exit
+#ifndef __NR_seccomp_sigreturn
+#define __NR_seccomp_sigreturn __NR_rt_sigreturn
+#endif
+
+#endif /* _ASM_GENERIC_SECCOMP_H */
-- 
1.7.9.5

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

[PATCH v10 0/6] arm64: add seccomp support

[AKASHI Takahiro]

This patch series enables secure computing (system call filtering) on arm64,
and contains related enhancements and bug fixes.

  NOTE: This versions contain a workaround against possible BUG_ON() failure
  at audit_syscall_exit(), but doesn't contain an extra optimization, as I
  submitted for arm, of excluding syscall enter/exit tracing against invalid
  system calls due to an issue that I reported in:
   
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/292170.html

The code was tested on ARMv8 fast model with 64-bit/32-bit userspace using:
 * libseccomp v2.1.1 with modifications for arm64, especially its "live"
   tests: No.20, 21 and 24.
 * modified version of Kees' seccomp test for 'changing/skipping a syscall'
   and seccomp() system call
 * in-house tests for 'changing/skipping a system call' by tracing with
   ptrace(SETREGSET, NT_SYSTEM_CALL) (that is, not via seccomp filter)'
with and without audit tracing.


Changes v9 -> v10:
* modified system_call_get() for big-endian build [1/6]
* modified the way to check for syscall(-1) on syscall entry [2/6]

Changes v8 -> v9:
* removed a restriction on syscall(-1) by setting a default errno [2/6]

Changes v7 -> v8:
* changed an interface of changing a syscall number from ptrace(SET_SYSCALL)
  to ptrace(SETREGSET, NT_ARM_SYSTEM_CALL) [1/6]
* removed IS_SKILL_SYSCALL macro [2/6]
* clarified comments in syscall_trace_enter() [2/6]
* changed unsigned int to compat_uint_t in compat_siginfo._sigsys [5/6]
* moved to a new calling interface of secure_computing(void) [6/6]

Changes v6 -> v7:
* simplified the condition of checking for user-issued syscall(-1) at
  syscall_trace_enter() [2/6]
* defines __NR_seccomp_sigreturn only if arch-specific def doesn't exist.
  As Kees suggests, this is necessary for x86 and others. [3/6]
* removed "#ifdef __ARCH_SIGSYS" which is always true on arm64. [5/6]
* changed to call syscall_trace_exit() even if secure_computing fails. [6/6]
  In v6, syscall_trace_enter() returns RET_SYSCALL_SKIP_TRACE (== -2) and
  skips syscall_trace_exit() to minimize the overhead, but this case can be
  easily confused with user-issued (and invalid) syscall(-2).
  Anyway, this is now a consistent behavior with arm and other archs.

Changes v5 -> v6:
* rebased to v3.17-rc
* changed the interface of changing/skipping a system call from re-writing
  x8 register [v5 1/3] to using dedicated PTRACE_SET_SYSCALL command
  [1/6, 2/6]
  Patch [1/6] contains a checkpatch error around a switch statement, but it
  won't be fixed as in compat_arch_ptrace().
* added a new system call, seccomp(), for compat task [4/6]
* added SIGSYS siginfo for compat task [5/6]
* changed to always execute audit exit tracing to avoid OOPs [2/6, 6/6]

Changes v4 -> v5:
* rebased to v3.16-rc
* add patch [1/3] to allow ptrace to change a system call
  (please note that this patch should be applied even without seccomp.)

Changes v3 -> v4:
* removed the following patch and moved it to "arm64: prerequisites for
  audit and ftrace" patchset since it is required for audit and ftrace in
  case of !COMPAT, too.
  "arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h"

Changes v2 -> v3:
* removed unnecessary 'type cast' operations [2/3]
* check for a return value (-1) of secure_computing() explicitly [2/3]
* aligned with the patch, "arm64: split syscall_trace() into separate
  functions for enter/exit" [2/3]
* changed default of CONFIG_SECCOMP to n [2/3]

Changes v1 -> v2:
* added generic seccomp.h for arm64 to utilize it [1,2/3] 
* changed syscall_trace() to return more meaningful value (-EPERM)
  on seccomp failure case [2/3]
* aligned with the change in "arm64: make a single hook to syscall_trace()
  for all syscall features" v2 [2/3]
* removed is_compat_task() definition from compat.h [3/3]

AKASHI Takahiro (6):
  arm64: ptrace: add NT_ARM_SYSTEM_CALL regset
  arm64: ptrace: allow tracer to skip a system call
  asm-generic: add generic seccomp.h for secure computing mode 1
  arm64: add seccomp syscall for compat task
  arm64: add SIGSYS siginfo for compat task
  arm64: add seccomp support

 arch/arm64/Kconfig|   14 +
 arch/arm64/include/asm/compat.h   |7 +++
 arch/arm64/include/asm/seccomp.h  |   25 +++
 arch/arm64/include/asm/unistd.h   |3 +++
 arch/arm64/include/asm/unistd32.h |3 ++-
 arch/arm64/kernel/entry.S |   12 +--
 arch/arm64/kernel/ptrace.c|   40 +
 arch/arm64/kernel/signal32.c  |6 ++
 include/asm-generic/seccomp.h |   30 
 include/uapi/linux/elf.h  |1 +
 10 files changed, 138 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/include/asm/seccomp.h
 create mode 100644 include/asm-generic/seccomp.h

-- 
1.7.9.5

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

[PATCH v10 2/6] arm64: ptrace: allow tracer to skip a system call

[AKASHI Takahiro]

If tracer modifies a syscall number to -1, this traced system call should
be skipped with a return value specified in x0.
This patch implements this semantics.

Please note:
* syscall entry tracing and syscall exit tracing (ftrace tracepoint and
  audit) are always executed, if enabled, even when skipping a system call
  (that is, -1).
  In this way, we can avoid a potential bug where audit_syscall_entry()
  might be called without audit_syscall_exit() at the previous system call
  being called, that would cause OOPs in audit_syscall_entry().

Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/kernel/entry.S |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 726b910..5d6a399 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -668,8 +668,15 @@ ENDPROC(el0_svc)
 * switches, and waiting for our parent to respond.
 */
 __sys_trace:
-   mov x0, sp
+   mov w0, #-1 // set default errno for
+   cmp scno, x0// user-issued syscall(-1)
+   b.ne1f
+   mov x0, #-ENOSYS
+   str x0, [sp, #S_X0]
+1: mov x0, sp
bl  syscall_trace_enter
+   cmp w0, #-1 // skip the syscall?
+   b.eq__sys_trace_return_skipped
adr lr, __sys_trace_return  // return address
uxtwscno, w0// syscall number (possibly new)
mov x1, sp  // pointer to regs
@@ -683,7 +690,8 @@ __sys_trace:
br  x16 // call sys_* routine
 
 __sys_trace_return:
-   str x0, [sp]// save returned x0
+   str x0, [sp, #S_X0] // save returned x0
+__sys_trace_return_skipped:
mov x0, sp
bl  syscall_trace_exit
b   ret_to_user
-- 
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 v9 1/6] arm64: ptrace: add NT_ARM_SYSTEM_CALL regset

[AKASHI Takahiro]

On 11/27/2014 11:10 PM, Will Deacon wrote:

On Thu, Nov 27, 2014 at 05:53:36AM +, AKASHI Takahiro wrote:

On 11/26/2014 09:41 PM, Will Deacon wrote:

On Wed, Nov 26, 2014 at 04:49:46AM +, AKASHI Takahiro wrote:

This regeset is intended to be used to get and set a system call number
while tracing.
There was some discussion about possible approaches to do so:

(1) modify x8 register with ptrace(PTRACE_SETREGSET) indirectly,
  and update regs->syscallno later on in syscall_trace_enter(), or
(2) define a dedicated regset for this purpose as on s390, or
(3) support ptrace(PTRACE_SET_SYSCALL) as on arch/arm

Thinking of the fact that user_pt_regs doesn't expose 'syscallno' to
tracer as well as that secure_computing() expects a changed syscall number,
especially case of -1, to be visible before this function returns in
syscall_trace_enter(), (1) doesn't work well.
We will take (2) since it looks much cleaner.

Signed-off-by: AKASHI Takahiro 
---
   arch/arm64/kernel/ptrace.c |   35 +++
   include/uapi/linux/elf.h   |1 +
   2 files changed, 36 insertions(+)

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 8a4ae8e..8b98781 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -551,6 +551,32 @@ static int tls_set(struct task_struct *target, const 
struct user_regset *regset,
return ret;
   }

+static int system_call_get(struct task_struct *target,
+  const struct user_regset *regset,
+  unsigned int pos, unsigned int count,
+  void *kbuf, void __user *ubuf)
+{
+   struct pt_regs *regs = task_pt_regs(target);
+
+   return user_regset_copyout(, , , ,
+  >syscallno, 0, -1);


Does this work for big-endian machines? regs->syscallno is a u64, but the
regset defines it as an int. I think you need to copy to a temporary
register first.


Right. I will fix it.
Do you prefer to use s32, instead of int, like other regsets?


I don't have a preference either way.

It would be great to have a new revision of these patches ASAP if you're
targetting 3.19.


Yeah, definitely.

-Takahiro AKASHI


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

[CFT][PATCH v2] userns: Avoid problems with negative groups

[Eric W. Biederman]

Classic unix permission checks have an interesting feature.  The group
permissions for a file can be set to less than the other permissions
on a file.  Occassionally this is used deliberately to give a certain
group of users fewer permissions than the default.

Overlooking negative groups has resulted in the permission checks for
setting up a group mapping in a user namespace to be too lax.  Tighten
the permission checks in new_idmap_permitted to ensure that mapping
uids and gids into user namespaces without privilege will not result
in new combinations of credentials being available to the users.

When setting mappings without privilege only the creator of the user
namespace is interesting as all other users that have CAP_SETUID over
the user namespace will also have CAP_SETUID over the user namespaces
parent.  So the scope of the unprivileged check is reduced to just
the case where cred->euid is the namespace creator.

For setting a uid mapping without privilege only euid is considered as
setresuid can set uid, suid and fsuid from euid without privielege
making any combination of uids possible with user namespaces already
possible without them.

For setting a gid mapping without privilege only egid on a credential
without supplementary groups is condsidered, as setresgid can set gid,
sgid and fsgid from egid without privilege.  The requirement for no
supplementary groups is because CAP_SETUID in a user namespace allows
supplementary groups to be cleared, which unfortunately means allowing
a credential with supplementary groups would allow new combinations
of credentials to exist, and thus would allow defeating negative
groups without permission.

setgroups is modified to fail not only when the group ids do not
map but also when there are no gid mappings at all, preventing
setgroups(0, NULL) from succeeding when gid mappings have not been
established.

This change should break userspace by the minimal amount needed
to fix this issue.

This should fix CVE-2014-8989.

Cc: sta...@vger.kernel.org
Signed-off-by: "Eric W. Biederman" 
---
 include/linux/user_namespace.h | 10 ++
 kernel/groups.c|  7 ++-
 kernel/uid16.c |  5 -
 kernel/user_namespace.c| 16 
 4 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index e95372654f09..26d5e8f5db97 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -46,6 +46,11 @@ static inline struct user_namespace *get_user_ns(struct 
user_namespace *ns)
return ns;
 }
 
+static inline bool gid_mapping_possible(const struct user_namespace *ns)
+{
+   return ns->gid_map.nr_extents != 0;
+}
+
 extern int create_user_ns(struct cred *new);
 extern int unshare_userns(unsigned long unshare_flags, struct cred **new_cred);
 extern void free_user_ns(struct user_namespace *ns);
@@ -70,6 +75,11 @@ static inline struct user_namespace *get_user_ns(struct 
user_namespace *ns)
return _user_ns;
 }
 
+static inline bool gid_mapping_possible(const struct user_namespace *ns)
+{
+   return true;
+}
+
 static inline int create_user_ns(struct cred *new)
 {
return -EINVAL;
diff --git a/kernel/groups.c b/kernel/groups.c
index 451698f86cfa..302aa415158f 100644
--- a/kernel/groups.c
+++ b/kernel/groups.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* init to 2 - one for init_task, one to ensure it is never freed */
@@ -220,14 +221,18 @@ out:
 
 SYSCALL_DEFINE2(setgroups, int, gidsetsize, gid_t __user *, grouplist)
 {
+   struct user_namespace *user_ns = current_user_ns();
struct group_info *group_info;
int retval;
 
-   if (!ns_capable(current_user_ns(), CAP_SETGID))
+   if (!gid_mapping_possible(user_ns) ||
+   !ns_capable(user_ns, CAP_SETGID))
return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
 
+   /* How do I alloc a negative gidsetsize??? */
+
group_info = groups_alloc(gidsetsize);
if (!group_info)
return -ENOMEM;
diff --git a/kernel/uid16.c b/kernel/uid16.c
index 602e5bbbceff..602c7de2aa11 100644
--- a/kernel/uid16.c
+++ b/kernel/uid16.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -173,10 +174,12 @@ out:
 
 SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t __user *, grouplist)
 {
+   struct user_namespace *user_ns = current_user_ns();
struct group_info *group_info;
int retval;
 
-   if (!ns_capable(current_user_ns(), CAP_SETGID))
+   if (!gid_mapping_possible(user_ns) ||
+   !ns_capable(user_ns, CAP_SETGID))
return -EPERM;
if ((unsigned)gidsetsize > NGROUPS_MAX)
return -EINVAL;
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index aa312b0dc3ec..b338c42d04fd 100644
--- a/kernel/user_namespace.c
+++ 

Re: [PATCH 1/2 V4] intel_pstate: skip this driver if Sun server has _PPC method

[Yasuaki Ishimatsu]

(2014/11/28 12:36), Ethan Zhao wrote:
> Oracle Sun X86 servers have dynamic power capping capability that works via
> ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
> enabled.
> 
> Signed-off-by: Ethan Zhao 
> Signed-off-by: Dirk Brandewie 
> Tested-by: Linda Knippers 
> ---
>v2: fix break HP Proliant issue.
>v3: expand the hardware vendor list.
>v4: refine code.
> 
>   drivers/cpufreq/intel_pstate.c | 45 
> ++
>   1 file changed, 41 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 27bb6d3..1bb62ca 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -943,15 +943,46 @@ static bool intel_pstate_no_acpi_pss(void)
>   return true;
>   }
>   
> +static bool intel_pstate_has_acpi_ppc(void)
> +{
> + int i;
> +
> + for_each_possible_cpu(i) {
> + struct acpi_processor *pr = per_cpu(processors, i);
> +
> + if (!pr)
> + continue;
> + if (acpi_has_method(pr->handle, "_PPC"))
> + return true;
> + }
> + return false;
> +}
> +

> +enum {
> + PSS,
> + PCC,
> +};

What does PCC stand for? Is it PPC?

Thanks,
Yasuaki Ishimatsu

> +
>   struct hw_vendor_info {
>   u16  valid;
>   char oem_id[ACPI_OEM_ID_SIZE];
>   char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
> + int  oem_pwr_table;
>   };
>   
>   /* Hardware vendor-specific info that has its own power management modes */
>   static struct hw_vendor_info vendor_info[] = {
> - {1, "HP", "ProLiant"},
> + {1, "HP", "ProLiant", PSS},
> + {1, "ORACLE", "X4-2", PCC},
> + {1, "ORACLE", "X4-2L   ", PCC},
> + {1, "ORACLE", "X4-2B   ", PCC},
> + {1, "ORACLE", "X3-2", PCC},
> + {1, "ORACLE", "X3-2L   ", PCC},
> + {1, "ORACLE", "X3-2B   ", PCC},
> + {1, "ORACLE", "X4470M2 ", PCC},
> + {1, "ORACLE", "X4270M3 ", PCC},
> + {1, "ORACLE", "X4270M2 ", PCC},
> + {1, "ORACLE", "X4170M2 ", PCC},
>   {0, "", ""},
>   };
>   
> @@ -966,15 +997,21 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
>   
>   for (v_info = vendor_info; v_info->valid; v_info++) {
>   if (!strncmp(hdr.oem_id, v_info->oem_id, ACPI_OEM_ID_SIZE) &&
> - !strncmp(hdr.oem_table_id, v_info->oem_table_id, 
> ACPI_OEM_TABLE_ID_SIZE) &&
> - intel_pstate_no_acpi_pss())
> - return true;
> + !strncmp(hdr.oem_table_id, v_info->oem_table_id,
> + ACPI_OEM_TABLE_ID_SIZE))
> + switch (v_info->oem_pwr_table) {
> + case PSS:
> + return intel_pstate_no_acpi_pss();
> + case PCC:
> + return intel_pstate_has_acpi_ppc();
> + }
>   }
>   
>   return false;
>   }
>   #else /* CONFIG_ACPI not enabled */
>   static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { return 
> false; }
> +static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
>   #endif /* CONFIG_ACPI */
>   
>   static int __init intel_pstate_init(void)
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [CFT][PATCH] userns: Avoid problems with negative groups

[Eric W. Biederman]

Andy Lutomirski  writes:

>> This change should break userspace by the minimal amount needed
>> to fix this issue.
>>
>> This should fix CVE-2014-8989.
>
> I think this is both unnecessarily restrictive and that it doesn't fix
> the bug.  

You are going to have to work very hard to convince me this is
unnecessarily restrictive.  

>For example, I can exploit CVE-2014-8989 without ever
> writing a uid map or a gid map.

Yes.  I realized just after I sent the patch that setgroups(0, NULL)
would still work without a mapping set.  That is a first glass grade a
oversight that resulted in a bug.  None of the other uid or gid changing
syscalls without a mapping set, and setgroups was just overlooked
because it was different.  Oops.

I will send an updated patch that stops setgroups from working without
a mapping set shortly.

> IIUC, the only real issue is that user namespaces allow groups to be
> dropped using setgroups that wouldn't otherwise be dropped.  Can we
> get away with adding a per-user-ns flag that determines whether
> setgroups can be used?

Being able to call setgroups is fundamental to login programs, and login
programs are one of the things user namespaces need to support.  So
adding an extra flag and an extra place where privilege is required
is just noise, and will wind up breaking every user of user namespaces.

Further being able to setup uid and gid mappings without privilege is
primarily a nice to have.  The original design did not have unprivileged
setting of uid and gid maps and if it proves insecure I goofed and the
feature isn't safe so it needs to be removed.

This does mean that running a system with negative groups and users
delegated subordinate gids in /etc/subuid is a bad idea and system
administrators shouldn't do that as those negative groups won't prove
effective in stopping their users.  But this is all under system
administrator control so shrug.  There isn't a way to avoid that
fundamental conflict.

> setgroups would be unusable until the gid_map has been written and
> then it would become usable if and only if the parent userns could use
> setgroups and the opener of gid_map was privileged.

That proposal sounds a lot more restrictive and a lot more of a pain
to use than what I have implemented in my patch.

> If we wanted to allow finer-grained control, we could allow writing
> control lines like:
>
> options +setgroups
>
> or
>
> options -setgroups
>
> in gid_map, or we could add user_ns_flags that can only be written
> once and only before either uid_map or gid_map is written.

Definitely more complicated and I can't imagine a case where I need
a gid map without needing to call setgroups.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: ipv4: Use standard iovec primitive in raw_probe_proto_opt

[Al Viro]

On Thu, Nov 06, 2014 at 10:16:08PM +, Al Viro wrote:
> On Thu, Nov 06, 2014 at 09:55:31AM +, Jon Maloy wrote:
> > > Point, but that might very well be a pattern to watch for - there's at 
> > > least one
> > > more instance in TIPC (also not exploitable, according to TIPC folks) and 
> > > such
> > 
> > I don't recall this, and I can't see where it would be either. Can you 
> > please
> > point to where it is?
> 
> The same dest_name_check() thing.  This
> if (copy_from_user(, m->msg_iov[0].iov_base, sizeof(hdr)))
> return -EFAULT;
> if ((ntohs(hdr.tcm_type) & 0xC000) && (!capable(CAP_NET_ADMIN)))
> return -EACCES;
> is easily bypassed.  Suppose you want to send a packet with these two
> bits in ->tcm_type not being 00, and you don't have CAP_NET_ADMIN.
> Not a problem - spawn two threads sharing memory, have one trying to
> call sendmsg() while another keeps flipping these two bits.  Sooner
> of later you'll get the timing right and have these bits observed as 00
> in dest_name_check() and 11 when it comes to memcpy_fromiovecend() actually
> copying the whole thing.  And considering that the interval between those
> two is much longer than the loop in the second thread would take on
> each iteration, I'd expect the odds around 25% per attempted sendmsg().
> 
> IOW, this test is either pointless and can be removed completely, or there's
> an exploitable race.  As far as I understand from your replies both back then
> and in another branch of this thread, it's the former and the proper fix is
> to remove at least that part of dest_name_check().  So this case is also
> not something exploitable, but it certainly matches the same pattern.
> 
> My point was simply that this pattern is worth watching for - recurrent bug
> classes like that have a good chance to spawn an instance that will be
> exploitable.

Ping?  Can we simply remove dest_name_check() completely?  That's one of the
few remaining obstacles to making ->sendmsg() iov_iter-clean.  For now I'm
simply commenting its call out in tipc_sendmsg(); if it _is_ needed for
anything, we'll need to get rid of that double copying from userland.  I can
do that, but my impression from your comments back in April is that you
planned to removed the damn check anyway.

Another question: in tipc_send_stream() we have
mtu = tsk->max_pkt;
send = min_t(uint, dsz - sent, TIPC_MAX_USER_MSG_SIZE);
__skb_queue_head_init();
rc = tipc_msg_build(mhdr, m, sent, send, mtu, );
if (unlikely(rc < 0))
goto exit;
do {   
if (likely(!tsk_conn_cong(tsk))) {
rc = tipc_link_xmit(, dnode, ref);
if (likely(!rc)) {
tsk->sent_unacked++;
sent += send;
if (sent == dsz)
break;
goto next;
}
if (rc == -EMSGSIZE) {
tsk->max_pkt = tipc_node_get_mtu(dnode, ref);
goto next;
}

How can it hit that EMSGSIZE?  AFAICS, it can come only from
int __tipc_link_xmit(struct tipc_link *link, struct sk_buff_head *list)
{
struct tipc_msg *msg = buf_msg(skb_peek(list));
uint psz = msg_size(msg);
...
uint mtu = link->max_pkt;
...
/* Has valid packet limit been used ? */   
if (unlikely(psz > mtu)) {
__skb_queue_purge(list);
return -EMSGSIZE;
}

and msg_size() is basically the bits copied into skb by tipc_msg_build() and
set by msg_set_size() in there.  And unless I'm seriously misreading that
function, it can't be more than pktmax argument, i.e. mtu.  So unless something
manages to crap into our skb or change mtu right under us, it shouldn't be
possible.  And mtu (i.e. ->max_pkt) ought to be protected by lock_sock() there.

What's going on there?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Xen-devel] [PATCH] xen: privcmd: schedule() after private hypercall when non CONFIG_PREEMPT

[Juergen Gross]

On 11/27/2014 07:50 PM, Andrew Cooper wrote:

On 27/11/14 18:36, Luis R. Rodriguez wrote:

On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:

On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:

From: "Luis R. Rodriguez" 

Some folks had reported that some xen hypercalls take a long time
to complete when issued from the userspace private ioctl mechanism,
this can happen for instance with some hypercalls that have many
sub-operations, this can happen for instance on hypercalls that use
multi-call feature whereby Xen lets one hypercall batch out a series
of other hypercalls on the hypervisor. At times such hypercalls can
even end up triggering the TASK_UNINTERRUPTIBLE hanger check (default
120 seconds), this a non-issue issue on preemptible kernels though as
the kernel may deschedule such long running tasks. Xen for instance
supports multicalls to be preempted as well, this is what Xen calls
continuation (see xen commit 42217cbc5b which introduced this [0]).
On systems without CONFIG_PREEMPT though -- a kernel with voluntary
or no preemption -- a long running hypercall will not be descheduled
until the hypercall is complete and the ioctl returns to user space.

To help with this David had originally implemented support for use
of preempt_schedule_irq() [1] for non CONFIG_PREEMPT kernels. This
solution never went upstream though and upon review to help refactor
this I've concluded that usage of preempt_schedule_irq() would be
a bit abussive of existing APIs -- for a few reasons:

0) we want to avoid spreading its use on non CONFIG_PREEMPT kernels

1) we want try to consider solutions that might work for other
 hypervisors for this same problem, and identify it its an issue
 even present on other hypervisors or if this is a self
 inflicted architectural issue caused by use of multicalls

2) there is no documentation or profiling of the exact hypercalls
 that were causing these issues, nor do we have any context
 to help evaluate this any further

I at least checked with kvm folks and it seems hypercall preemption
is not needed there. We can survey other hypervisors...

If 'something like preemption' is needed then CONFIG_PREEMPT
should just be enabled and encouraged, it seems we want to
encourage CONFIG_PREEMPT on xen, specially when multicalls are
used. In the meantime this tries to address a solution to help
xen on non CONFIG_PREEMPT kernels.

One option tested and evaluated was to put private hypercalls in
process context, however this would introduce complexities such
originating hypercalls from different contexts. Current xen
hypercall callback handlers would need to be changed per architecture,
for instance, we'd also incur the cost of switching states from
user / kernel (this cost is also present if preempt_schedule_irq()
is used). There may be other issues which could be introduced with
this strategy as well. The simplest *shared* alternative is instead
to just explicitly schedule() at the end of a private hypercall on non
preempt kernels. This forces our private hypercall call mechanism
to try to be fair only on non CONFIG_PREEMPT kernels at the cost of
more context switch but keeps the private hypercall context intact.

[0] 
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=42217cbc5b3e84b8c145d8cfb62dd5de0134b9e8;hp=3a0b9c57d5c9e82c55dd967c84dd06cb43c49ee9
[1] 
http://ftp.suse.com/pub/people/mcgrof/xen-preempt-hypercalls/0001-x86-xen-allow-privcmd-hypercalls-to-be-preempted.patch

Cc: Davidlohr Bueso 
Cc: Joerg Roedel 
Cc: Borislav Petkov 
Cc: Konrad Rzeszutek Wilk 
Cc: Jan Beulich 
Cc: Juergen Gross 
Cc: Olaf Hering 
Cc: David Vrabel 
Signed-off-by: Luis R. Rodriguez 
---
   drivers/xen/privcmd.c | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 569a13b..e29edba 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -60,6 +60,9 @@ static long privcmd_ioctl_hypercall(void __user *udata)
   hypercall.arg[0], hypercall.arg[1],
   hypercall.arg[2], hypercall.arg[3],
   hypercall.arg[4]);
+#ifndef CONFIG_PREEMPT
+   schedule();
+#endif

return ret;
   }


Sorry, I don't think this will solve anything. You're calling schedule()
right after the long running hypercall just nanoseconds before returning
to the user.

Yeah, well that is what [1] tried as well only it tried using
preempt_schedule_irq() on the hypercall callback...


I suppose you were mislead by the "int 0x82" in [0]. This is the
hypercall from the kernel into the hypervisor, e.g. inside of
privcmd_call().

Nope, you have to consider what was done in [1], I was trying to
do something similar but less complex that didn't involve mucking
with the callbacks but also not abusing APIs.

I'm afraid we don't have much leg room.


XenServer uses

[PATCH] irqchip: gic: Remove warning by including linux/irqdomain.h

[Jason Cooper]

Commit

  853a33ce6932 irqchip: gic-v2m: Add support for ARM GICv2m MSI(-X) doorbell

Introduced a series of warnings when building ARM multi_v7_defconfig:

  include/linux/irqchip/arm-gic.h:109:53: warning: its scope is only this 
definition or declaration, which is probably not what you want
  In file included from arch/arm/mach-ux500/pm.c:13:0:
  include/linux/irqchip/arm-gic.h:109:53: warning: 'struct irq_domain' declared 
inside parameter list
   int gicv2m_of_init(struct device_node *node, struct irq_domain *parent);
   ^

Fix this by adding the proper include.

Signed-off-by: Jason Cooper 
---
I've added this to irqchip/irqdomain-arm locally and pushed it to next.  If
there are no objections, I'll push it to irqchip/irqdomain-arm.

thx,

Jason.

 include/linux/irqchip/arm-gic.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 60b09ed58cae..d1b2263a4db3 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -10,6 +10,8 @@
 #ifndef __LINUX_IRQCHIP_ARM_GIC_H
 #define __LINUX_IRQCHIP_ARM_GIC_H
 
+#include 
+
 #define GIC_CPU_CTRL   0x00
 #define GIC_CPU_PRIMASK0x04
 #define GIC_CPU_BINPOINT   0x08
-- 
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 V4 01/16] irqchip: Update docs regarding irq_domain_add_tree()

[Kevin Cernekee]

Several drivers now use this API, including the ARM GIC driver, so remove
the outdated comment.

Signed-off-by: Kevin Cernekee 
---
 Documentation/IRQ-domain.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index 8a8b82c9ca53..0ccd7b7f6043 100644
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -95,8 +95,7 @@ since it doesn't need to allocate a table as large as the 
largest
 hwirq number.  The disadvantage is that hwirq to IRQ number lookup is
 dependent on how many entries are in the table.
 
-Very few drivers should need this mapping.  At the moment, powerpc
-iseries is the only user.
+Very few drivers should need this mapping.
 
  No Map ===-
 irq_domain_add_nomap()
-- 
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/

[PATCH V4 07/16] irqchip: bcm7120-l2: Add support for BCM3380-style controllers

[Kevin Cernekee]

These controllers support multiple enable/status pairs (64+ IRQs),
can put the enable/status words at different offsets, and do not
support multiple parent IRQs.

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm3380-l2-intc.txt  | 41 
 drivers/irqchip/irq-bcm7120-l2.c   | 57 --
 2 files changed, 93 insertions(+), 5 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt
new file mode 100644
index ..8f48aad50868
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt
@@ -0,0 +1,41 @@
+Broadcom BCM3380-style Level 1 / Level 2 interrupt controller
+
+This interrupt controller shows up in various forms on many BCM338x/BCM63xx
+chipsets.  It has the following properties:
+
+- outputs a single interrupt signal to its interrupt controller parent
+
+- contains one or more enable/status word pairs, which often appear at
+  different offsets in different blocks
+
+- no atomic set/clear operations
+
+Required properties:
+
+- compatible: should be "brcm,bcm3380-l2-intc"
+- reg: specifies one or more enable/status pairs, in the following format:
+  ...
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+  source, should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller
+  this one is cascaded from
+- interrupts: specifies the interrupt line in the interrupt-parent controller
+  node, valid values depend on the type of parent interrupt controller
+
+Optional properties:
+
+- brcm,irq-can-wake: if present, this means the L2 controller can be used as a
+  wakeup source for system suspend/resume.
+
+Example:
+
+irq0_intc: interrupt-controller@1020 {
+   compatible = "brcm,bcm3380-l2-intc";
+   reg = <0x1024 0x4 0x102c 0x4>,
+ <0x1020 0x4 0x1028 0x4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   interrupt-parent = <_intc>;
+   interrupts = <2>;
+};
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 36014b27844a..561670cfb6d8 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,7 @@
 #define IRQSTAT0x04
 
 #define MAX_WORDS  4
-#define MAX_MAPPINGS   MAX_WORDS
+#define MAX_MAPPINGS   (MAX_WORDS * 2)
 #define IRQS_PER_WORD  32
 
 struct bcm7120_l2_intc_data {
@@ -120,10 +121,15 @@ static int bcm7120_l2_intc_init_one(struct device_node 
*dn,
/* For multiple parent IRQs with multiple words, this looks like:
 * 
 */
-   for (idx = 0; idx < data->n_words; idx++)
-   data->irq_map_mask[idx] |=
-   be32_to_cpup(data->map_mask_prop +
-irq * data->n_words + idx);
+   for (idx = 0; idx < data->n_words; idx++) {
+   if (data->map_mask_prop) {
+   data->irq_map_mask[idx] |=
+   be32_to_cpup(data->map_mask_prop +
+irq * data->n_words + idx);
+   } else {
+   data->irq_map_mask[idx] = 0x;
+   }
+   }
 
irq_set_handler_data(parent_irq, data);
irq_set_chained_handler(parent_irq, bcm7120_l2_intc_irq_handle);
@@ -165,6 +171,37 @@ static int __init bcm7120_l2_intc_iomap_7120(struct 
device_node *dn,
return 0;
 }
 
+static int __init bcm7120_l2_intc_iomap_3380(struct device_node *dn,
+struct bcm7120_l2_intc_data *data)
+{
+   unsigned int gc_idx;
+
+   for (gc_idx = 0; gc_idx < MAX_WORDS; gc_idx++) {
+   unsigned int map_idx = gc_idx * 2;
+   void __iomem *en = of_iomap(dn, map_idx + 0);
+   void __iomem *stat = of_iomap(dn, map_idx + 1);
+   void __iomem *base = min(en, stat);
+
+   data->map_base[map_idx + 0] = en;
+   data->map_base[map_idx + 1] = stat;
+
+   if (!base)
+   break;
+
+   data->pair_base[gc_idx] = base;
+   data->en_offset[gc_idx] = en - base;
+   data->stat_offset[gc_idx] = stat - base;
+   }
+
+   if (!gc_idx) {
+   pr_err("unable to map registers\n");
+   return -EINVAL;
+   }
+
+   data->n_words = gc_idx;
+   return 0;
+}
+
 int __init bcm7120_l2_intc_probe(struct device_node *dn,
 struct device_node *parent,
  

[PATCH V4 04/16] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

[Kevin Cernekee]

From: Dmitry Torokhov 

Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.

Signed-off-by: Dmitry Torokhov 
Acked-by: Florian Fainelli 
Tested-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index e7c6155b23b8..8eec8e1201d9 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -102,9 +102,9 @@ static int bcm7120_l2_intc_init_one(struct device_node *dn,
unsigned int idx;
 
parent_irq = irq_of_parse_and_map(dn, irq);
-   if (parent_irq < 0) {
+   if (!parent_irq) {
pr_err("failed to map interrupt %d\n", irq);
-   return parent_irq;
+   return -EINVAL;
}
 
/* For multiple parent IRQs with multiple words, this looks like:
-- 
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/

[PATCH V4 03/16] irqchip: brcmstb-l2: fix error handling of irq_of_parse_and_map

[Kevin Cernekee]

From: Dmitry Torokhov 

Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.

Signed-off-by: Dmitry Torokhov 
Acked-by: Florian Fainelli 
Tested-by: Kevin Cernekee 
---
 drivers/irqchip/irq-brcmstb-l2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 4edd27c486c4..d6bcc6be0777 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -143,9 +143,9 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
writel(0x, data->base + CPU_CLEAR);
 
data->parent_irq = irq_of_parse_and_map(np, 0);
-   if (data->parent_irq < 0) {
+   if (!data->parent_irq) {
pr_err("failed to find parent interrupt\n");
-   ret = data->parent_irq;
+   ret = -EINVAL;
goto out_unmap;
}
 
-- 
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/

[PATCH V4 06/16] irqchip: bcm7120-l2: Split STB-specific logic into its own function

[Kevin Cernekee]

The BCM7xxx instances of this block (listed in the register manual as
simply "IRQ0") all have the following items in common:

 - brcm,int-map-mask: for routing different bits in the L2 to different
   parent IRQs

 - brcm,int-fwd-mask: for hardwiring certain IRQs to bypass the L2 and
   use dedicated L1 lines

 - one enable/status pair (32 bits only)

Much of the driver code can be shared with BCM3380-style controllers, but
in order to do this cleanly, let's split out the BCM7xxx-specific logic
first.

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm7120-l2-intc.txt  |  12 +-
 drivers/irqchip/irq-bcm7120-l2.c   | 121 -
 2 files changed, 70 insertions(+), 63 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
index bae1f2187226..44a9bb15dd56 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt
@@ -13,8 +13,7 @@ Such an interrupt controller has the following hardware 
design:
   or if they will output an interrupt signal at this 2nd level interrupt
   controller, in particular for UARTs
 
-- typically has one 32-bit enable word and one 32-bit status word, but on
-  some hardware may have more than one enable/status pair
+- has one 32-bit enable word and one 32-bit status word
 
 - no atomic set/clear operations
 
@@ -53,9 +52,7 @@ The typical hardware layout for this controller is 
represented below:
 Required properties:
 
 - compatible: should be "brcm,bcm7120-l2-intc"
-- reg: specifies the base physical address and size of the registers;
-  multiple pairs may be specified, with the first pair handling IRQ offsets
-  0..31 and the second pair handling 32..63
+- reg: specifies the base physical address and size of the registers
 - interrupt-controller: identifies the node as an interrupt controller
 - #interrupt-cells: specifies the number of cells needed to encode an interrupt
   source, should be 1.
@@ -66,10 +63,7 @@ Required properties:
 - brcm,int-map-mask: 32-bits bit mask describing how many and which interrupts
   are wired to this 2nd level interrupt controller, and how they match their
   respective interrupt parents. Should match exactly the number of interrupts
-  specified in the 'interrupts' property, multiplied by the number of
-  enable/status register pairs implemented by this controller.  For
-  multiple parent IRQs with multiple enable/status words, this looks like:
-  
+  specified in the 'interrupts' property.
 
 Optional properties:
 
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index da5b5745003c..36014b27844a 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -47,6 +47,8 @@ struct bcm7120_l2_intc_data {
bool can_wake;
u32 irq_fwd_mask[MAX_WORDS];
u32 irq_map_mask[MAX_WORDS];
+   int num_parent_irqs;
+   const __be32 *map_mask_prop;
 };
 
 static void bcm7120_l2_intc_irq_handle(unsigned int irq, struct irq_desc *desc)
@@ -104,7 +106,7 @@ static void bcm7120_l2_intc_resume(struct irq_data *d)
 
 static int bcm7120_l2_intc_init_one(struct device_node *dn,
struct bcm7120_l2_intc_data *data,
-   int irq, const __be32 *map_mask)
+   int irq)
 {
int parent_irq;
unsigned int idx;
@@ -120,7 +122,8 @@ static int bcm7120_l2_intc_init_one(struct device_node *dn,
 */
for (idx = 0; idx < data->n_words; idx++)
data->irq_map_mask[idx] |=
-   be32_to_cpup(map_mask + irq * data->n_words + idx);
+   be32_to_cpup(data->map_mask_prop +
+irq * data->n_words + idx);
 
irq_set_handler_data(parent_irq, data);
irq_set_chained_handler(parent_irq, bcm7120_l2_intc_irq_handle);
@@ -128,74 +131,76 @@ static int bcm7120_l2_intc_init_one(struct device_node 
*dn,
return 0;
 }
 
-int __init bcm7120_l2_intc_of_init(struct device_node *dn,
-   struct device_node *parent)
+static int __init bcm7120_l2_intc_iomap_7120(struct device_node *dn,
+struct bcm7120_l2_intc_data *data)
+{
+   int ret;
+
+   data->map_base[0] = of_iomap(dn, 0);
+   if (!data->map_base[0]) {
+   pr_err("unable to map registers\n");
+   return -ENOMEM;
+   }
+
+   data->pair_base[0] = data->map_base[0];
+   data->en_offset[0] = IRQEN;
+   data->stat_offset[0] = IRQSTAT;
+   data->n_words = 1;
+
+   ret = of_property_read_u32_array(dn, "brcm,int-fwd-mask",
+data->irq_fwd_mask, data->n_words);
+

[PATCH V4 08/16] irqchip: Add new driver for BCM7038-style level 1 interrupt controllers

[Kevin Cernekee]

This is the main peripheral IRQ controller on the BCM7xxx MIPS chips;
it has the following characteristics:

 - 64 to 160+ level IRQs
 - Atomic set/clear registers
 - Reasonably predictable register layout (N status words, then N
   mask status words, then N mask set words, then N mask clear words)
 - SMP affinity supported on most systems
 - Typically connected to MIPS IRQ 2,3,2,3 on CPUs 0,1,2,3

This driver registers one IRQ domain and one IRQ chip to cover all
instances of the block.  Up to 4 instances of the block may appear, as
it supports 4-way IRQ affinity on BCM7435.

The same block exists on the ARM BCM7xxx chips, but typically the ARM GIC
is used instead.  So this driver is primarily intended for MIPS STB chips.

Signed-off-by: Kevin Cernekee 
---
 .../interrupt-controller/brcm,bcm7038-l1-intc.txt  |  52 
 drivers/irqchip/Kconfig|   5 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-bcm7038-l1.c   | 335 +
 4 files changed, 393 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
 create mode 100644 drivers/irqchip/irq-bcm7038-l1.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
new file mode 100644
index ..cc217b22dccd
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
@@ -0,0 +1,52 @@
+Broadcom BCM7038-style Level 1 interrupt controller
+
+This block is a first level interrupt controller that is typically connected
+directly to one of the HW INT lines on each CPU.  Every BCM7xxx set-top chip
+since BCM7038 has contained this hardware.
+
+Key elements of the hardware design include:
+
+- 64, 96, 128, or 160 incoming level IRQ lines
+
+- Most onchip peripherals are wired directly to an L1 input
+
+- A separate instance of the register set for each CPU, allowing individual
+  peripheral IRQs to be routed to any CPU
+
+- Atomic mask/unmask operations
+
+- No polarity/level/edge settings
+
+- No FIFO or priority encoder logic; software is expected to read all
+  2-5 status words to determine which IRQs are pending
+
+Required properties:
+
+- compatible: should be "brcm,bcm7038-l1-intc"
+- reg: specifies the base physical address and size of the registers;
+  the number of supported IRQs is inferred from the size argument
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+  source, should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller(s)
+  this one is cascaded from
+- interrupts: specifies the interrupt line(s) in the interrupt-parent 
controller
+  node; valid values depend on the type of parent interrupt controller
+
+If multiple reg ranges and interrupt-parent entries are present on an SMP
+system, the driver will allow IRQ SMP affinity to be set up through the
+/proc/irq/ interface.  In the simplest possible configuration, only one
+reg range and one interrupt-parent is needed.
+
+Example:
+
+periph_intc: periph_intc@1041a400 {
+compatible = "brcm,bcm7038-l1-intc";
+reg = <0x1041a400 0x30 0x1041a600 0x30>;
+
+interrupt-controller;
+#interrupt-cells = <1>;
+
+interrupt-parent = <_intc>;
+interrupts = <2>, <3>;
+};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 018f884aa3b0..89ee92b8b94c 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -48,6 +48,11 @@ config ATMEL_AIC5_IRQ
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
 
+config BCM7038_L1_IRQ
+   bool
+   select GENERIC_IRQ_CHIP
+   select IRQ_DOMAIN
+
 config BCM7120_L2_IRQ
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 4954a314c31e..446ae7a98f7a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_TB10X_IRQC)  += irq-tb10x.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_BCM7038_L1_IRQ)   += irq-bcm7038-l1.o
 obj-$(CONFIG_BCM7120_L2_IRQ)   += irq-bcm7120-l2.o
 obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
 obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
new file mode 100644
index ..d3b8c8be15f6
--- /dev/null
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -0,0 +1,335 @@
+/*
+ * Broadcom BCM7038 style Level 1 interrupt controller driver
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ * Author: Kevin Cernekee
+ *
+ * This program is free 

[PATCH V4 09/16] MIPS: Let __dt_register_buses accept a single bus type

[Kevin Cernekee]

Some machines only have one bus type to register (e.g. "simple-bus").

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/prom.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 452d4350ce42..e303cb1ef2f4 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -64,7 +64,10 @@ int __init __dt_register_buses(const char *bus0, const char 
*bus1)
panic("device tree not present");
 
strlcpy(of_ids[0].compatible, bus0, sizeof(of_ids[0].compatible));
-   strlcpy(of_ids[1].compatible, bus1, sizeof(of_ids[1].compatible));
+   if (bus1) {
+   strlcpy(of_ids[1].compatible, bus1,
+   sizeof(of_ids[1].compatible));
+   }
 
if (of_platform_populate(NULL, of_ids, NULL, NULL))
panic("failed to populate DT");
-- 
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/

[PATCH V4 10/16] MIPS: Fall back to the generic restart notifier

[Kevin Cernekee]

If the machine doesn't set its own _machine_restart callback, call the
common do_kernel_restart() instead.  This allows arch-independent reset
drivers from drivers/power/reset/ to be used to reboot the machine.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/kernel/reset.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc5244aed4..cf23ab520701 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -29,6 +29,8 @@ void machine_restart(char *command)
 {
if (_machine_restart)
_machine_restart(command);
+   else
+   do_kernel_restart(command);
 }
 
 void machine_halt(void)
-- 
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/

[PATCH V4 11/16] MIPS: Reorder MIPS_L1_CACHE_SHIFT priorities

[Kevin Cernekee]

Enabling support for more than one BMIPS CPU in the same build may
result in different L1_CACHE_SHIFT values, e.g.

CPU_BMIPS5000 selects MIPS_L1_CACHE_SHIFT_7
CPU_BMIPS4380 selects MIPS_L1_CACHE_SHIFT_6
anything else defaults to MIPS_L1_CACHE_SHIFT_5

Ensure that if more than one MIPS_L1_CACHE_SHIFT_x option is selected,
Kconfig sets CONFIG_MIPS_L1_CACHE_SHIFT to the highest value.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 601b991dcdce..b4cdf722aeee 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1167,10 +1167,10 @@ config MIPS_L1_CACHE_SHIFT_7
 
 config MIPS_L1_CACHE_SHIFT
int
-   default "4" if MIPS_L1_CACHE_SHIFT_4
-   default "5" if MIPS_L1_CACHE_SHIFT_5
-   default "6" if MIPS_L1_CACHE_SHIFT_6
default "7" if MIPS_L1_CACHE_SHIFT_7
+   default "6" if MIPS_L1_CACHE_SHIFT_6
+   default "5" if MIPS_L1_CACHE_SHIFT_5
+   default "4" if MIPS_L1_CACHE_SHIFT_4
default "5"
 
 config HAVE_STD_PC_SERIAL_PORT
-- 
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/

[PATCH V4 13/16] MIPS: BMIPS: Flush the readahead cache after DMA

[Kevin Cernekee]

BMIPS 3300/435x/438x CPUs have a readahead cache that is separate from
the L1/L2.  During a DMA operation, accesses adjacent to a DMA buffer
may cause parts of the DMA buffer to be prefetched into the RAC.  To
avoid possible coherency problems, flush the RAC upon DMA completion.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/mm/dma-default.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index af5f046e627e..ee6d12cb7588 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -69,6 +70,18 @@ static inline struct page *dma_addr_to_page(struct device 
*dev,
  */
 static inline int cpu_needs_post_dma_flush(struct device *dev)
 {
+   if (boot_cpu_type() == CPU_BMIPS3300 ||
+   boot_cpu_type() == CPU_BMIPS4350 ||
+   boot_cpu_type() == CPU_BMIPS4380) {
+   void __iomem *cbr = BMIPS_GET_CBR();
+
+   /* Flush stale data out of the readahead cache */
+   __raw_writel(0x100, cbr + BMIPS_RAC_CONFIG);
+   __raw_readl(cbr + BMIPS_RAC_CONFIG);
+
+   return 0;
+   }
+
return !plat_device_is_coherent(dev) &&
   (boot_cpu_type() == CPU_R1 ||
boot_cpu_type() == CPU_R12000 ||
-- 
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/

[PATCH V4 12/16] MIPS: Create a common

[Kevin Cernekee]

11 platforms require at least one of these workarounds to be enabled; 22
platforms do not.  In the latter case we can fall back to a generic version.

Note that this also deletes an orphaned reference to RM9000_CDEX_SMP_WAR.

Suggested-by: Arnd Bergmann 
Signed-off-by: Kevin Cernekee 
---
 arch/mips/include/asm/mach-ar7/war.h   | 24 
 arch/mips/include/asm/mach-ath25/war.h | 25 -
 arch/mips/include/asm/mach-ath79/war.h | 24 
 arch/mips/include/asm/mach-au1x00/war.h| 24 
 arch/mips/include/asm/mach-bcm47xx/war.h   | 24 
 arch/mips/include/asm/mach-bcm63xx/war.h   | 24 
 arch/mips/include/asm/mach-cavium-octeon/war.h | 25 -
 arch/mips/include/asm/mach-cobalt/war.h| 24 
 arch/mips/include/asm/mach-dec/war.h   | 24 
 arch/mips/include/asm/mach-emma2rh/war.h   | 24 
 arch/mips/include/asm/mach-generic/war.h   | 24 
 arch/mips/include/asm/mach-jazz/war.h  | 24 
 arch/mips/include/asm/mach-jz4740/war.h| 24 
 arch/mips/include/asm/mach-lantiq/war.h| 23 ---
 arch/mips/include/asm/mach-lasat/war.h | 24 
 arch/mips/include/asm/mach-loongson/war.h  | 24 
 arch/mips/include/asm/mach-loongson1/war.h | 24 
 arch/mips/include/asm/mach-netlogic/war.h  | 25 -
 arch/mips/include/asm/mach-paravirt/war.h  | 25 -
 arch/mips/include/asm/mach-pnx833x/war.h   | 24 
 arch/mips/include/asm/mach-ralink/war.h| 24 
 arch/mips/include/asm/mach-tx39xx/war.h| 24 
 arch/mips/include/asm/mach-vr41xx/war.h| 24 
 23 files changed, 24 insertions(+), 531 deletions(-)
 delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
 delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-cavium-octeon/war.h
 delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
 delete mode 100644 arch/mips/include/asm/mach-dec/war.h
 delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
 create mode 100644 arch/mips/include/asm/mach-generic/war.h
 delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
 delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
 delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
 delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
 delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
 delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
 delete mode 100644 arch/mips/include/asm/mach-pnx833x/war.h
 delete mode 100644 arch/mips/include/asm/mach-ralink/war.h
 delete mode 100644 arch/mips/include/asm/mach-tx39xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-vr41xx/war.h

diff --git a/arch/mips/include/asm/mach-ar7/war.h 
b/arch/mips/include/asm/mach-ar7/war.h
deleted file mode 100644
index 99071e50faab..
diff --git a/arch/mips/include/asm/mach-ath25/war.h 
b/arch/mips/include/asm/mach-ath25/war.h
deleted file mode 100644
index e3a5250ebd67..
diff --git a/arch/mips/include/asm/mach-ath79/war.h 
b/arch/mips/include/asm/mach-ath79/war.h
deleted file mode 100644
index 0bb30905fd5b..
diff --git a/arch/mips/include/asm/mach-au1x00/war.h 
b/arch/mips/include/asm/mach-au1x00/war.h
deleted file mode 100644
index 72e260d24e59..
diff --git a/arch/mips/include/asm/mach-bcm47xx/war.h 
b/arch/mips/include/asm/mach-bcm47xx/war.h
deleted file mode 100644
index a3d2f448b10e..
diff --git a/arch/mips/include/asm/mach-bcm63xx/war.h 
b/arch/mips/include/asm/mach-bcm63xx/war.h
deleted file mode 100644
index 05ee8671bef1..
diff --git a/arch/mips/include/asm/mach-cavium-octeon/war.h 
b/arch/mips/include/asm/mach-cavium-octeon/war.h
deleted file mode 100644
index eb72b35cf04b..
diff --git a/arch/mips/include/asm/mach-cobalt/war.h 
b/arch/mips/include/asm/mach-cobalt/war.h
deleted file mode 100644
index 34ae4046541e..
diff --git a/arch/mips/include/asm/mach-dec/war.h 
b/arch/mips/include/asm/mach-dec/war.h
deleted file mode 100644
index d29996feb3e7..
diff --git a/arch/mips/include/asm/mach-emma2rh/war.h 

[PATCH V4 15/16] MIPS: Add Generic BMIPS target

[Kevin Cernekee]

bmips_be_defconfig supports Linux running on the following CM and DSL
SoCs:

 - BCM3384 (BMIPS5000) cable modem application processor, BE, SMP
 - BCM3384 (BMIPS4355) cable modem "spare CPU"*, BE
 - BCM6328 (BMIPS4355) ADSL chip, BE
 - BCM6368 (BMIPS4350) ADSL chip, BE, SMP

*experimental; most configurations will require changing CONFIG_PHYSICAL_START

bmips_stb_defconfig supports Linux running on the (nominally LE) STB
chipsets:

 - BCM7125 (BMIPS4380) set-top box chip, LE, SMP
 - BCM7346 (BMIPS5000) set-top box chip, LE, SMP
 - BCM7360 (BMIPS3300) set-top box chip, LE
 - BCM7420 (BMIPS5000) set-top box chip, LE, SMP
 - BCM7425 (BMIPS5000) set-top box chip, LE, SMP

serial8250 and bcm63xx_uart do not currently coexist.  If/when this is
fixed, it will be also possible to boot the BE image on any supported STB
board configured for BE.  For now, each defconfig can only pick one UART
driver, and the BE defconfig enables bcm63xx_uart.

On these MIPS systems, endianness cannot be reconfigured at runtime.  On
STB it is sometimes offered as a board jumper or 0-ohm resistor, and
sometimes hardwired to LE only.  The CM and DSL systems always run BE.

Device Tree is used to configure the following items:

 - UART, USB, GENET peripherals
 - IRQ controllers
 - Early console base address (bcm63xx_uart only)
 - SMP or UP mode
 - MIPS counter frequency
 - Memory size / regions
 - DMA remappings
 - Reboot sequences
 - GISB bus error catcher
 - Kernel command line

The DT-enabled bootloader and build instructions for 3384 are posted at
https://github.com/Broadcom/aeolus .

Signed-off-by: Kevin Cernekee 
---
 .../devicetree/bindings/mips/brcm/bmips.txt|   8 +
 .../devicetree/bindings/mips/brcm/soc.txt  |  12 ++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  34 
 arch/mips/bmips/Makefile   |   1 +
 arch/mips/bmips/Platform   |   7 +
 arch/mips/bmips/dma.c  | 121 +
 arch/mips/bmips/irq.c  |  38 
 arch/mips/bmips/setup.c| 191 +
 arch/mips/configs/bmips_be_defconfig   |  88 ++
 arch/mips/configs/bmips_stb_defconfig  |  88 ++
 arch/mips/include/asm/mach-bmips/dma-coherence.h   |  48 ++
 arch/mips/include/asm/mach-bmips/spaces.h  |  18 ++
 13 files changed, 655 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/bmips.txt
 create mode 100644 Documentation/devicetree/bindings/mips/brcm/soc.txt
 create mode 100644 arch/mips/bmips/Makefile
 create mode 100644 arch/mips/bmips/Platform
 create mode 100644 arch/mips/bmips/dma.c
 create mode 100644 arch/mips/bmips/irq.c
 create mode 100644 arch/mips/bmips/setup.c
 create mode 100644 arch/mips/configs/bmips_be_defconfig
 create mode 100644 arch/mips/configs/bmips_stb_defconfig
 create mode 100644 arch/mips/include/asm/mach-bmips/dma-coherence.h
 create mode 100644 arch/mips/include/asm/mach-bmips/spaces.h

diff --git a/Documentation/devicetree/bindings/mips/brcm/bmips.txt 
b/Documentation/devicetree/bindings/mips/brcm/bmips.txt
new file mode 100644
index ..4a8cd8f4d41a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/brcm/bmips.txt
@@ -0,0 +1,8 @@
+* Broadcom MIPS (BMIPS) CPUs
+
+Required properties:
+- compatible: "brcm,bmips3300", "brcm,bmips4350", "brcm,bmips4380"
+  "brcm,bmips5000"
+
+- mips-hpt-frequency: This is common to all CPUs in the system so it lives
+  under the "cpus" node.
diff --git a/Documentation/devicetree/bindings/mips/brcm/soc.txt 
b/Documentation/devicetree/bindings/mips/brcm/soc.txt
new file mode 100644
index ..f011443eb9d3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/brcm/soc.txt
@@ -0,0 +1,12 @@
+* Broadcom cable/DSL/settop platforms
+
+Required properties:
+
+- compatible: "brcm,bcm3384", "brcm,bcm33843"
+  "brcm,bcm3384-viper", "brcm,bcm33843-viper"
+  "brcm,bcm6328", "brcm,bcm6368",
+  "brcm,bcm7125", "brcm,bcm7346", "brcm,bcm7360",
+  "brcm,bcm7420", "brcm,bcm7425"
+
+The experimental -viper variants are for running Linux on the 3384's
+BMIPS4355 cable modem CPU instead of the BMIPS5000 application processor.
diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index 1780c74ed0da..a4d1e4f2ebb6 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -6,6 +6,7 @@ platforms += ath25
 platforms += ath79
 platforms += bcm47xx
 platforms += bcm63xx
+platforms += bmips
 platforms += cavium-octeon
 platforms += cobalt
 platforms += dec
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b4cdf722aeee..b10d5aaa6eb2 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -130,6 +130,40 @@ config ATH79
help
  Support for the Atheros AR71XX/AR724X/AR913X SoCs.
 
+config 

[PATCH V4 14/16] MIPS: BMIPS: Document the firmware->kernel DTB interface

[Kevin Cernekee]

Add a new section covering the Generic BMIPS machine type.

Signed-off-by: Kevin Cernekee 
---
 Documentation/devicetree/booting-without-of.txt | 28 +
 1 file changed, 28 insertions(+)

diff --git a/Documentation/devicetree/booting-without-of.txt 
b/Documentation/devicetree/booting-without-of.txt
index 77685185cf3b..e49e423268c0 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -15,6 +15,7 @@ Table of Contents
 1) Entry point for arch/arm
 2) Entry point for arch/powerpc
 3) Entry point for arch/x86
+4) Entry point for arch/mips/bmips
 
   II - The DT block format
 1) Header
@@ -288,6 +289,33 @@ it with special cases.
   or initrd address. It simply holds information which can not be retrieved
   otherwise like interrupt routing or a list of devices behind an I2C bus.
 
+4) Entry point for arch/mips/bmips
+--
+
+  Some bootloaders only support a single entry point, at the start of the
+  kernel image.  Other bootloaders will jump to the ELF start address.
+  Both schemes are supported; CONFIG_BOOT_RAW=y and CONFIG_NO_EXCEPT_FILL=y,
+  so the first instruction immediately jumps to kernel_entry().
+
+  Similar to the arch/arm case (b), a DT-aware bootloader is expected to
+  set up the following registers:
+
+ a0 : 0
+
+ a1 : 0x
+
+ a2 : Physical pointer to the device tree block (defined in chapter
+ II) in RAM.  The device tree can be located anywhere in the first
+ 512MB of the physical address space (0x - 0x1fff),
+ aligned on a 64 bit boundary.
+
+  Legacy bootloaders do not use this convention, and they do not pass in a
+  DT block.  In this case, Linux will look for a builtin DTB, selected via
+  CONFIG_DT_*.
+
+  This convention is defined for 32-bit systems only, as there are not
+  currently any 64-bit BMIPS implementations.
+
 II - The DT block format
 
 
-- 
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/

[PATCH V4 16/16] MIPS: BMIPS: Add DTS files for several platforms

[Kevin Cernekee]

Most of the supported chips use legacy (non-DT) bootloaders, so they will
need to select an appropriate builtin DTB at compile time until the
bootloader is updated.  Provide suitable DTS files, and a means to compile
one of them into the kernel image.

Signed-off-by: Kevin Cernekee 
---
 arch/mips/Kconfig|   1 +
 arch/mips/bmips/Kconfig  |  50 +++
 arch/mips/boot/dts/Makefile  |   9 ++
 arch/mips/boot/dts/bcm3384_viper.dtsi| 108 +++
 arch/mips/boot/dts/bcm3384_zephyr.dtsi   | 126 +
 arch/mips/boot/dts/bcm6328.dtsi  |  86 
 arch/mips/boot/dts/bcm6368.dtsi  |  93 +
 arch/mips/boot/dts/bcm7125.dtsi  | 139 +++
 arch/mips/boot/dts/bcm7346.dtsi  | 224 ++
 arch/mips/boot/dts/bcm7360.dtsi  | 161 ++
 arch/mips/boot/dts/bcm7420.dtsi  | 184 +
 arch/mips/boot/dts/bcm7425.dtsi  | 225 +++
 arch/mips/boot/dts/bcm93384wvg.dts   |  25 
 arch/mips/boot/dts/bcm93384wvg_viper.dts |  25 
 arch/mips/boot/dts/bcm96368mvwg.dts  |  31 +
 arch/mips/boot/dts/bcm97125cbmb.dts  |  31 +
 arch/mips/boot/dts/bcm97346dbsmb.dts |  58 
 arch/mips/boot/dts/bcm97360svmb.dts  |  34 +
 arch/mips/boot/dts/bcm97420c.dts |  45 +++
 arch/mips/boot/dts/bcm97425svmb.dts  |  60 +
 arch/mips/boot/dts/bcm9ejtagprb.dts  |  22 +++
 21 files changed, 1737 insertions(+)
 create mode 100644 arch/mips/bmips/Kconfig
 create mode 100644 arch/mips/boot/dts/bcm3384_viper.dtsi
 create mode 100644 arch/mips/boot/dts/bcm3384_zephyr.dtsi
 create mode 100644 arch/mips/boot/dts/bcm6328.dtsi
 create mode 100644 arch/mips/boot/dts/bcm6368.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7125.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7346.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7360.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7420.dtsi
 create mode 100644 arch/mips/boot/dts/bcm7425.dtsi
 create mode 100644 arch/mips/boot/dts/bcm93384wvg.dts
 create mode 100644 arch/mips/boot/dts/bcm93384wvg_viper.dts
 create mode 100644 arch/mips/boot/dts/bcm96368mvwg.dts
 create mode 100644 arch/mips/boot/dts/bcm97125cbmb.dts
 create mode 100644 arch/mips/boot/dts/bcm97346dbsmb.dts
 create mode 100644 arch/mips/boot/dts/bcm97360svmb.dts
 create mode 100644 arch/mips/boot/dts/bcm97420c.dts
 create mode 100644 arch/mips/boot/dts/bcm97425svmb.dts
 create mode 100644 arch/mips/boot/dts/bcm9ejtagprb.dts

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index b10d5aaa6eb2..9260ca6dc73c 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -892,6 +892,7 @@ source "arch/mips/ath25/Kconfig"
 source "arch/mips/ath79/Kconfig"
 source "arch/mips/bcm47xx/Kconfig"
 source "arch/mips/bcm63xx/Kconfig"
+source "arch/mips/bmips/Kconfig"
 source "arch/mips/jazz/Kconfig"
 source "arch/mips/jz4740/Kconfig"
 source "arch/mips/lantiq/Kconfig"
diff --git a/arch/mips/bmips/Kconfig b/arch/mips/bmips/Kconfig
new file mode 100644
index ..dced2cdc3d85
--- /dev/null
+++ b/arch/mips/bmips/Kconfig
@@ -0,0 +1,50 @@
+choice
+   prompt "Built-in device tree"
+   help
+ Legacy bootloaders do not pass a DTB pointer to the kernel, so
+ if a "wrapper" is not being used, the kernel will need to include
+ a device tree that matches the target board.
+
+ The builtin DTB will only be used if the firmware does not supply
+ a valid DTB.
+
+config DT_NONE
+   bool "None"
+
+config DT_BCM93384WVG
+   bool "BCM93384WVG Zephyr CPU"
+   select BUILTIN_DTB
+
+config DT_BCM93384WVG_VIPER
+   bool "BCM93384WVG Viper CPU (EXPERIMENTAL)"
+   select BUILTIN_DTB
+
+config DT_BCM96368MVWG
+   bool "BCM96368MVWG"
+   select BUILTIN_DTB
+
+config DT_BCM9EJTAGPRB
+   bool "BCM9EJTAGPRB"
+   select BUILTIN_DTB
+
+config DT_BCM97125CBMB
+   bool "BCM97125CBMB"
+   select BUILTIN_DTB
+
+config DT_BCM97346DBSMB
+   bool "BCM97346DBSMB"
+   select BUILTIN_DTB
+
+config DT_BCM97360SVMB
+   bool "BCM97360SVMB"
+   select BUILTIN_DTB
+
+config DT_BCM97420C
+   bool "BCM97420C"
+   select BUILTIN_DTB
+
+config DT_BCM97425SVMB
+   bool "BCM97425SVMB"
+   select BUILTIN_DTB
+
+endchoice
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index ca9c90e2cabf..153d04489c46 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,4 +1,13 @@
 dtb-$(CONFIG_CAVIUM_OCTEON_SOC)+= octeon_3xxx.dtb 
octeon_68xx.dtb
+dtb-$(CONFIG_DT_BCM93384WVG)   += bcm93384wvg.dtb
+dtb-$(CONFIG_DT_BCM93384WVG_VIPER) += bcm93384wvg_viper.dtb
+dtb-$(CONFIG_DT_BCM96368MVWG)  += bcm96368mvwg.dtb
+dtb-$(CONFIG_DT_BCM9EJTAGPRB)  += bcm9ejtagprb.dtb
+dtb-$(CONFIG_DT_BCM97125CBMB)  += 

[PATCH V4 05/16] irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT offsets

[Kevin Cernekee]

Currently the driver assumes that REG_BASE+0x00 is the IRQ enable mask,
and REG_BASE+0x04 is the IRQ status mask.  This is true on BCM3384 and
BCM7xxx, but it is not true for some of the controllers found on BCM63xx
chips.  So we will change a couple of key assumptions:

 - Don't assume that both the IRQEN and IRQSTAT registers will be
   covered by a single ioremap() operation.

 - Don't assume any particular ordering (IRQSTAT might show up before
   IRQEN on some chips).

 - For an L2 controller with >=64 IRQs, don't assume that every
   IRQEN/IRQSTAT pair will use the same register spacing.

This patch changes the "plumbing" but doesn't yet provide a way for users
to instantiate a controller with arbitrary IRQEN/IRQSTAT offsets.

Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-bcm7120-l2.c | 41 +++-
 1 file changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 8eec8e1201d9..da5b5745003c 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -34,11 +34,15 @@
 #define IRQSTAT0x04
 
 #define MAX_WORDS  4
+#define MAX_MAPPINGS   MAX_WORDS
 #define IRQS_PER_WORD  32
 
 struct bcm7120_l2_intc_data {
unsigned int n_words;
-   void __iomem *base[MAX_WORDS];
+   void __iomem *map_base[MAX_MAPPINGS];
+   void __iomem *pair_base[MAX_WORDS];
+   int en_offset[MAX_WORDS];
+   int stat_offset[MAX_WORDS];
struct irq_domain *domain;
bool can_wake;
u32 irq_fwd_mask[MAX_WORDS];
@@ -61,7 +65,8 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
int hwirq;
 
irq_gc_lock(gc);
-   pending = irq_reg_readl(gc, IRQSTAT) & gc->mask_cache;
+   pending = irq_reg_readl(gc, b->stat_offset[idx]) &
+ gc->mask_cache;
irq_gc_unlock(gc);
 
for_each_set_bit(hwirq, , IRQS_PER_WORD) {
@@ -76,21 +81,24 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq, 
struct irq_desc *desc)
 static void bcm7120_l2_intc_suspend(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct bcm7120_l2_intc_data *b = gc->private;
 
irq_gc_lock(gc);
if (b->can_wake)
-   irq_reg_writel(gc, gc->mask_cache | gc->wake_active, IRQEN);
+   irq_reg_writel(gc, gc->mask_cache | gc->wake_active,
+  ct->regs.mask);
irq_gc_unlock(gc);
 }
 
 static void bcm7120_l2_intc_resume(struct irq_data *d)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
 
/* Restore the saved mask */
irq_gc_lock(gc);
-   irq_reg_writel(gc, gc->mask_cache, IRQEN);
+   irq_reg_writel(gc, gc->mask_cache, ct->regs.mask);
irq_gc_unlock(gc);
 }
 
@@ -137,9 +145,14 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
return -ENOMEM;
 
for (idx = 0; idx < MAX_WORDS; idx++) {
-   data->base[idx] = of_iomap(dn, idx);
-   if (!data->base[idx])
+   data->map_base[idx] = of_iomap(dn, idx);
+   if (!data->map_base[idx])
break;
+
+   data->pair_base[idx] = data->map_base[idx];
+   data->en_offset[idx] = IRQEN;
+   data->stat_offset[idx] = IRQSTAT;
+
data->n_words = idx + 1;
}
if (!data->n_words) {
@@ -157,7 +170,8 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
if (ret == 0 || ret == -EINVAL) {
for (idx = 0; idx < data->n_words; idx++)
__raw_writel(data->irq_fwd_mask[idx],
-data->base[idx] + IRQEN);
+data->pair_base[idx] +
+data->en_offset[idx]);
} else {
/* property exists but has the wrong number of words */
pr_err("invalid int-fwd-mask property\n");
@@ -215,11 +229,12 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
gc = irq_get_domain_generic_chip(data->domain, irq);
 
gc->unused = 0x & ~data->irq_map_mask[idx];
-   gc->reg_base = data->base[idx];
gc->private = data;
ct = gc->chip_types;
 
-   ct->regs.mask = IRQEN;
+   gc->reg_base = data->pair_base[idx];
+   ct->regs.mask = data->en_offset[idx];
+
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_ack = irq_gc_noop;
@@ -237,16 +252,16 @@ int __init bcm7120_l2_intc_of_init(struct device_node 

[PATCH V4 00/16] Generic BMIPS kernel

[Kevin Cernekee]

This patch series REPLACES the following commits in Ralf's
mips-for-linux-next branch:

846deacebfe1 Documentation: DT: Add entries for BCM3384 and its peripherals
d666cd0246f7 MIPS: bcm3384: Initial commit of bcm3384 platform support
a2f6734c5f68 MAINTAINERS: Add entry for BCM33xx cable chips

(if you just want to drop the above commits and target this for 3.20+,
that's fine.)


V3->V4:

 - Rename "Multiplatform BMIPS kernel" to "Generic BMIPS kernel".

 - Split the "Generic BMIPS kernel" work into two separate commits: one
   for code and one for DTS.

 - Drop set_io_port_base stuff; this can be added later when PCI(e)
   support is done.

 - Document the boot interface (entry points, register contents).

 - Document the special FIXMAP requirement.

 - Create a mach-generic/war.h to reduce copy/paste.

 - Change "compatible" strings to distinguish bcm7120-style
   "IRQEN/IRQSTAT" controllers from bcm3380-style "free form"
   controllers.

 - Add DT nodes for brcmstb-reboot.c and brcmstb_gisb.c.

 - Rebase on Ralf's latest tree.


This series is based on mips-for-linux-next, minus the three 3384 patches
listed above, plus these non-MIPS patches:

http://patchwork.linux-mips.org/bundle/cernekee/bmips-multi-v4-deps/?state=%2a
http://marc.info/?l=linux-usb=141305106215886=2 (all 3/3)
http://marc.info/?l=linux-usb=141696309127730=2 (all 9/9)

I believe the irq-b*-l2.c patches are the only compile-time dependencies;
you may want to take 01-08 through the irqchip tree since they build on
top of other pending commits there.

My branch can be viewed here:

https://github.com/Broadcom/stblinux/commits/bmips-generic-v4


Brian Norris (1):
  irqchip: brcmstb-l2: don't clear wakeable interrupts at init time

Dmitry Torokhov (2):
  irqchip: brcmstb-l2: fix error handling of irq_of_parse_and_map
  irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

Kevin Cernekee (13):
  irqchip: Update docs regarding irq_domain_add_tree()
  irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT
offsets
  irqchip: bcm7120-l2: Split STB-specific logic into its own function
  irqchip: bcm7120-l2: Add support for BCM3380-style controllers
  irqchip: Add new driver for BCM7038-style level 1 interrupt
controllers
  MIPS: Let __dt_register_buses accept a single bus type
  MIPS: Fall back to the generic restart notifier
  MIPS: Reorder MIPS_L1_CACHE_SHIFT priorities
  MIPS: Create a common 
  MIPS: BMIPS: Flush the readahead cache after DMA
  MIPS: BMIPS: Document the firmware->kernel DTB interface
  MIPS: Add Generic BMIPS target
  MIPS: BMIPS: Add DTS files for several platforms

 Documentation/IRQ-domain.txt   |   3 +-
 .../interrupt-controller/brcm,bcm3380-l2-intc.txt  |  41 +++
 .../interrupt-controller/brcm,bcm7038-l1-intc.txt  |  52 
 .../interrupt-controller/brcm,bcm7120-l2-intc.txt  |  12 +-
 .../devicetree/bindings/mips/brcm/bmips.txt|   8 +
 .../devicetree/bindings/mips/brcm/soc.txt  |  12 +
 Documentation/devicetree/booting-without-of.txt|  28 ++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  41 ++-
 arch/mips/bmips/Kconfig|  50 +++
 arch/mips/bmips/Makefile   |   1 +
 arch/mips/bmips/Platform   |   7 +
 arch/mips/bmips/dma.c  | 121 
 arch/mips/bmips/irq.c  |  38 +++
 arch/mips/bmips/setup.c| 191 
 arch/mips/boot/dts/Makefile|   9 +
 arch/mips/boot/dts/bcm3384_viper.dtsi  | 108 +++
 arch/mips/boot/dts/bcm3384_zephyr.dtsi | 126 
 arch/mips/boot/dts/bcm6328.dtsi|  86 ++
 arch/mips/boot/dts/bcm6368.dtsi|  93 ++
 arch/mips/boot/dts/bcm7125.dtsi| 139 +
 arch/mips/boot/dts/bcm7346.dtsi| 224 ++
 arch/mips/boot/dts/bcm7360.dtsi| 161 ++
 arch/mips/boot/dts/bcm7420.dtsi| 184 +++
 arch/mips/boot/dts/bcm7425.dtsi| 225 ++
 arch/mips/boot/dts/bcm93384wvg.dts |  25 ++
 arch/mips/boot/dts/bcm93384wvg_viper.dts   |  25 ++
 arch/mips/boot/dts/bcm96368mvwg.dts|  31 ++
 arch/mips/boot/dts/bcm97125cbmb.dts|  31 ++
 arch/mips/boot/dts/bcm97346dbsmb.dts   |  58 
 arch/mips/boot/dts/bcm97360svmb.dts|  34 +++
 arch/mips/boot/dts/bcm97420c.dts   |  45 +++
 arch/mips/boot/dts/bcm97425svmb.dts|  60 
 arch/mips/boot/dts/bcm9ejtagprb.dts|  22 ++
 arch/mips/configs/bmips_be_defconfig   |  88 ++
 arch/mips/configs/bmips_stb_defconfig  |  88 ++
 arch/mips/include/asm/mach-ar7/war.h   |  24 --
 

[PATCH V4 02/16] irqchip: brcmstb-l2: don't clear wakeable interrupts at init time

[Kevin Cernekee]

From: Brian Norris 

Wakeable interrupts might be pending at boot/init time, because wakeup
interrupts might have triggered a resume from S5. So don't clear such
wakeups.

This means that any driver which requests a wakeable interrupt bit
should be prepared to handle an interrupt as soon as they call
request_irq(). (This is technically already the correct development
practice, but some drivers probably expect not to receive interrupts
until they have performed some I/O.)

Signed-off-by: Brian Norris 
Signed-off-by: Kevin Cernekee 
---
 drivers/irqchip/irq-brcmstb-l2.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 4aa653a0ac72..4edd27c486c4 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -136,7 +136,11 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
 
/* Disable all interrupts by default */
writel(0x, data->base + CPU_MASK_SET);
-   writel(0x, data->base + CPU_CLEAR);
+
+   /* Wakeup interrupts may be retained from S5 (cold boot) */
+   data->can_wake = of_property_read_bool(np, "brcm,irq-can-wake");
+   if (!data->can_wake)
+   writel(0x, data->base + CPU_CLEAR);
 
data->parent_irq = irq_of_parse_and_map(np, 0);
if (data->parent_irq < 0) {
@@ -188,8 +192,7 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
ct->chip.irq_suspend = brcmstb_l2_intc_suspend;
ct->chip.irq_resume = brcmstb_l2_intc_resume;
 
-   if (of_property_read_bool(np, "brcm,irq-can-wake")) {
-   data->can_wake = true;
+   if (data->can_wake) {
/* This IRQ chip can wake the system, set all child interrupts
 * in wake_enabled mask
 */
-- 
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: [[PATCHv2] 3/3] drivers/rtc/rtc-snvs: Add clock support

[Sanchayan Maity]

On Wednesday 19 November 2014 10:19 AM, Sanchayan Maity wrote:
> On Wednesday 19 November 2014 06:47 AM, Shawn Guo wrote:
>> On Thu, Nov 13, 2014 at 11:03:09AM +0530, Sanchayan Maity wrote:
>>> On Wednesday 12 November 2014 04:17 PM, Shawn Guo wrote:
 On Wed, Nov 12, 2014 at 02:26:51PM +0530, Sanchayan Maity wrote:
> On Wednesday 12 November 2014 02:57 AM, Stefan Agner wrote:
>> On 2014-11-07 14:04, Sanchayan Maity wrote:
>>> This patch adds clock enable and disable support for
>>> the SNVS peripheral, which is required for using the
>>> RTC within the SNVS block.
>>
>> What happens if the device tree node is there while this patch is not
>> applied? I guess the driver would load, but since the clocks of the
>> peripheral are not enabled the first register access would lead to bus
>> error or similar. If this is the case, this would break bisectability.
>> You should move the device tree patch to the end.
>>
>
> If the DT node was present with this patch not applied, the driver would 
> still crash with a bus error, since the clocks for SNVS are not 
> explicitly 
> enabled anywhere else. I had not thought about any problems which might 
> occur later with git bisect. Will move this to the end with v3.

 Since changes on rtc-snvs.c will need to go through RTC subsystem tree,
 that means I cannot apply DTS changes until the driver patch gets
 mainlined and appears on my tree.

 Shawn
>>>
>>> Shawn
>>>
>>> So the approach in this patch is OK and acceptable? 
>>
>> Yes, I'm fine with it.
>>
>> Shawn
> 
> 
> Hello Alessandro, 
> 
> Sorry I missed adding you while sending this patch set.
> 
> Can you take this third patch, in this series through your RTC subsytem
> tree? Or should I resend this third patch separately?

Ping? Any inputs? Should I resend or is this Ok?
> 
> Regards,
> Sanchayan.
> 
>>
>>>
>>> Since the DT changes cannot be applied by you, till this goes through the 
>>> RTC subsystem tree, gets mainlined and appears on your tree, I will send 
>>> out 
>>> this patch by itself then and send the DT changes later once this gets
>>> mainlined?
>>>
>>> I did not CC Alessandro Zummo, the maintainer of RTC subsystem by mistake.
>>> Once you ACK/OK this i will send out this patch in isolation then or just 
>>> CC Alessandro Zummo.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] arcmsr: Notify has sense data report

[Ching Huang]

From: Ching Huang 

This patch is relative to 
http://git.infradead.org/users/hch/scsi-queue.git/tree/refs/heads/drivers-for-3.18:/drivers/scsi/arcmsr

Setting command status with 'DRIVER_SENSE' except 'CHECK_CONDITION' if we have 
sense data.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2014-09-19 11:04:41.84510 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2014-11-28 10:54:30.0 +0800
@@ -52,7 +52,7 @@ struct device_attribute;
#define ARCMSR_MAX_FREECCB_NUM  320
 #define ARCMSR_MAX_OUTSTANDING_CMD 255
 #endif
-#define ARCMSR_DRIVER_VERSION  "v1.30.00.04-20140919"
+#define ARCMSR_DRIVER_VERSION  "v1.30.00.05-20141128"
 #define ARCMSR_SCSI_INITIATOR_ID   
255
 #define ARCMSR_MAX_XFER_SECTORS
512
 #define ARCMSR_MAX_XFER_SECTORS_B  
4096
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-09-19 11:01:26.99009 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-11-28 10:55:54.0 +0800
@@ -989,7 +989,8 @@ static void arcmsr_report_sense_info(str
 
struct scsi_cmnd *pcmd = ccb->pcmd;
struct SENSE_DATA *sensebuffer = (struct SENSE_DATA 
*)pcmd->sense_buffer;
-   pcmd->result = DID_OK << 16;
+
+   pcmd->result = (DID_OK << 16) | (CHECK_CONDITION << 1);
if (sensebuffer) {
int sense_data_length =
sizeof(struct SENSE_DATA) < SCSI_SENSE_BUFFERSIZE
@@ -998,6 +999,7 @@ static void arcmsr_report_sense_info(str
memcpy(sensebuffer, ccb->arcmsr_cdb.SenseData, 
sense_data_length);
sensebuffer->ErrorCode = SCSI_SENSE_CURRENT_ERRORS;
sensebuffer->Valid = 1;
+   pcmd->result |= (DRIVER_SENSE << 24);
}
 }
 


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

[Yao Dongdong]

security_ops is not used in this file.

Signed-off-by: Yao Dongdong 
---
 security/selinux/hooks.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index c603b20..6da7532 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -95,8 +95,6 @@
 #include "audit.h"
 #include "avc_ss.h"
 
-extern struct security_operations *security_ops;
-
 /* SECMARK reference count */
 static atomic_t selinux_secmark_refcount = ATOMIC_INIT(0);
 
-- 
1.8.3.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 4/4] (CMA_AGGRESSIVE) Update page alloc function

[Hui Zhu]

On Fri, Oct 24, 2014 at 1:28 PM, Joonsoo Kim  wrote:
> On Thu, Oct 16, 2014 at 11:35:51AM +0800, Hui Zhu wrote:
>> If page alloc function __rmqueue try to get pages from MIGRATE_MOVABLE and
>> conditions (cma_alloc_counter, cma_aggressive_free_min, cma_alloc_counter)
>> allow, MIGRATE_CMA will be allocated as MIGRATE_MOVABLE first.
>>
>> Signed-off-by: Hui Zhu 
>> ---
>>  mm/page_alloc.c | 42 +++---
>>  1 file changed, 31 insertions(+), 11 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 736d8e1..87bc326 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -65,6 +65,10 @@
>>  #include 
>>  #include "internal.h"
>>
>> +#ifdef CONFIG_CMA_AGGRESSIVE
>> +#include 
>> +#endif
>> +
>>  /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
>>  static DEFINE_MUTEX(pcp_batch_high_lock);
>>  #define MIN_PERCPU_PAGELIST_FRACTION (8)
>> @@ -1189,20 +1193,36 @@ static struct page *__rmqueue(struct zone *zone, 
>> unsigned int order,
>>  {
>>   struct page *page;
>>
>> -retry_reserve:
>> +#ifdef CONFIG_CMA_AGGRESSIVE
>> + if (cma_aggressive_switch
>> + && migratetype == MIGRATE_MOVABLE
>> + && atomic_read(_alloc_counter) == 0
>> + && global_page_state(NR_FREE_CMA_PAGES) > cma_aggressive_free_min
>> + + (1 << order))
>> + migratetype = MIGRATE_CMA;
>> +#endif
>> +retry:
>
> I don't get it why cma_alloc_counter should be tested.
> When cma alloc is progress, pageblock is isolated so that pages on that
> pageblock cannot be allocated. Why should we prevent aggressive
> allocation in this case?
>

Hi Joonsoo,

Even if the pageblock is isolated in the begin of function
alloc_contig_range, it will unisolate if alloc_contig_range get some
error for example "PFNs busy".  And the cma_alloc will keep call
alloc_contig_range with another address if need.

So it will decrease the contradiction between CMA allocation in
cma_alloc and __rmqueue with  cma_alloc_counter.

Thanks,
Hui

> Thanks.
>
> --
> 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
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/2] arm64: exynos: Add bus1 pinctrl node on exynos7

[Vivek Gautam]

Hi Kukjin,


On Wed, Nov 26, 2014 at 6:59 PM, Alim Akhtar  wrote:
> Hi Vivek,
>
> On Mon, Nov 24, 2014 at 6:36 PM, Vivek Gautam  
> wrote:
>> BUS1 pinctrl provides gpios for usb and power regulator
>> available on exynos7-espresso board. So add relevant device
>> node for pinctrl-bus1.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> Signed-off-by: Vivek Gautam 
>> ---

We can pick this up for 3.19 rc1 ?

>>
> Looks good to me.
> Reviewed-by: Alim Akhtar 
>
>> This patch was part of series:
>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>  https://lkml.org/lkml/2014/11/21/247
>>
>> Changes since V1:
>>  - Added support for all pin banks which are part of BUS1 pin controller.
>>
>>  arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi |   82 
>> +++
>>  arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
>>  2 files changed, 89 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> index 2eef4a2..c367f0a 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> @@ -335,6 +335,88 @@
>> };
>>  };
>>
>> +_bus1 {
>> +   gpf0: gpf0 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf1: gpf1 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf2: gpf2 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf3: gpf3 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf4: gpf4 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpf5: gpf5 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpg1: gpg1 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpg2: gpg2 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gph1: gph1 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +
>> +   gpv6: gpv6 {
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> +};
>> +
>>  _nfc {
>> gpj0: gpj0 {
>> gpio-controller;
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
>> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index 1d9e4c9..e633b02 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -26,6 +26,7 @@
>> pinctrl5 = _ese;
>> pinctrl6 = _fsys0;
>> pinctrl7 = _fsys1;
>> +   pinctrl8 = _bus1;
>> };
>>
>> cpus {
>> @@ -242,6 +243,12 @@
>> interrupts = <0 383 0>;
>> };
>>
>> +   pinctrl_bus1: pinctrl@1487 {
>> +   compatible = "samsung,exynos7-pinctrl";
>> +   reg = <0x1487 0x1000>;
>> +   interrupts = <0 384 0>;
>> +   };
>> +
>> pinctrl_nfc: pinctrl@14cd {
>> compatible = "samsung,exynos7-pinctrl";
>> reg = <0x14cd 0x1000>;
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Regards,
> Alim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe 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 V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

[Vivek Gautam]

Hi Linus,


On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam  wrote:
> Hi Alim,
>
>
> On Wed, Nov 26, 2014 at 7:03 PM, Alim Akhtar  wrote:
>> Hi Vivek,
>>
>> On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam  
>> wrote:
>>> USB and Power regulator on Exynos7 require gpios available
>>> in BUS1 pin controller block.
>>> So adding the BUS1 pinctrl support.
>>>
>>> Signed-off-by: Naveen Krishna Ch 
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Linus Walleij 

If the change looks good, will it be possible to pick it fo 3.19-rc1 ?
That will really help enabling USB IP on exynos7.

>>> ---
>> Looks good to me.
>> Thanks!
>>
>> Reviewed-by: Alim Akhtar 
>
> Thanks for the review.
>
>>
>>>
>>> This patch was part of series:
>>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>>  https://lkml.org/lkml/2014/11/21/247
>>>
>>> Changes since V1:
>>>  - Added support for all pin banks which are part of BUS1 pin controller.
>>>
>>>  drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
>>>  1 file changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
>>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> index d5d4cfc..44e60dc 100644
>>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> @@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data 
>>> exynos7_pin_banks7[] __initconst = {
>>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>>>  };
>>>
>>> +/* pin banks of exynos7 pin-controller - BUS1 */
>>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst 
>>> = {
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
>>> +   EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
>>> +   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
>>> +   EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
>>> +   EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
>>> +   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>>> +   EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
>>> +};
>>> +
>>>  const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
>>> {
>>> /* pin-controller instance 0 Alive data */
>>> @@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
>>> __initconst = {
>>> .pin_banks  = exynos7_pin_banks7,
>>> .nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
>>> .eint_gpio_init = exynos_eint_gpio_init,
>>> +   }, {
>>> +   /* pin-controller instance 8 BUS1 data */
>>> +   .pin_banks  = exynos7_pin_banks8,
>>> +   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
>>> +   .eint_gpio_init = exynos_eint_gpio_init,
>>> },
>>>  };
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe 
>>> linux-samsung-soc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Regards,
>> Alim
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R Institute, Bangalore
> India



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V6] intel_pstate: add kernel parameter to force loading on Sun X86 servers.

[Ethan Zhao]

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

  intel_pstate = ora_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 
---
 v2: change to hardware vendor specific naming parameter.
 v4: refine code and doc.
 v5: fix a typo in 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
+  ora_force
+Force loading intel_pstate on Oracle Sun Servers(X86).
+only for those who be aware of the risk of no power 
capping
+capability working and try to get better performance 
with this
+driver.
 
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  ora_force;
 
 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 PCC:
-   return intel_pstate_has_acpi_ppc();
+   return intel_pstate_has_acpi_ppc() &&
+   (!ora_force);
}
}
 
@@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
 
if (!strcmp(str, "disable"))
no_load = 1;
+   if (!strcmp(str, "ora_force"))
+   ora_force = 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/

[PATCH 2/2 V6] intel_pstate: add kernel parameter to force loading on Sun X86 servers.

[Ethan Zhao]

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

  intel_pstate = ora_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 
---
 v2: change to hardware vendor specific naming parameter.
 v4: refine code and doc.
 v5: fix a typo in 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
+  ora_force
+Force loading intel_pstate on Oracle Sun Servers(X86).
+only for those who be aware of the risk of no power 
capping
+capability working and try to get better performance 
with this
+driver.
 
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  ora_force;
 
 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 PCC:
-   return intel_pstate_has_acpi_ppc();
+   return intel_pstate_has_acpi_ppc() &&
+   (!ora_force);
}
}
 
@@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
 
if (!strcmp(str, "disable"))
no_load = 1;
+   if (!strcmp(str, "ora_force"))
+   ora_force = 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/

[PATCH 1/2 V4] intel_pstate: skip this driver if Sun server has _PPC method

[Ethan Zhao]

Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.

Signed-off-by: Ethan Zhao 
Signed-off-by: Dirk Brandewie 
Tested-by: Linda Knippers 
---
  v2: fix break HP Proliant issue.
  v3: expand the hardware vendor list.
  v4: refine code.

 drivers/cpufreq/intel_pstate.c | 45 ++
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 27bb6d3..1bb62ca 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -943,15 +943,46 @@ static bool intel_pstate_no_acpi_pss(void)
return true;
 }
 
+static bool intel_pstate_has_acpi_ppc(void)
+{
+   int i;
+
+   for_each_possible_cpu(i) {
+   struct acpi_processor *pr = per_cpu(processors, i);
+
+   if (!pr)
+   continue;
+   if (acpi_has_method(pr->handle, "_PPC"))
+   return true;
+   }
+   return false;
+}
+
+enum {
+   PSS,
+   PCC,
+};
+
 struct hw_vendor_info {
u16  valid;
char oem_id[ACPI_OEM_ID_SIZE];
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+   int  oem_pwr_table;
 };
 
 /* Hardware vendor-specific info that has its own power management modes */
 static struct hw_vendor_info vendor_info[] = {
-   {1, "HP", "ProLiant"},
+   {1, "HP", "ProLiant", PSS},
+   {1, "ORACLE", "X4-2", PCC},
+   {1, "ORACLE", "X4-2L   ", PCC},
+   {1, "ORACLE", "X4-2B   ", PCC},
+   {1, "ORACLE", "X3-2", PCC},
+   {1, "ORACLE", "X3-2L   ", PCC},
+   {1, "ORACLE", "X3-2B   ", PCC},
+   {1, "ORACLE", "X4470M2 ", PCC},
+   {1, "ORACLE", "X4270M3 ", PCC},
+   {1, "ORACLE", "X4270M2 ", PCC},
+   {1, "ORACLE", "X4170M2 ", PCC},
{0, "", ""},
 };
 
@@ -966,15 +997,21 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
 
for (v_info = vendor_info; v_info->valid; v_info++) {
if (!strncmp(hdr.oem_id, v_info->oem_id, ACPI_OEM_ID_SIZE) &&
-   !strncmp(hdr.oem_table_id, v_info->oem_table_id, 
ACPI_OEM_TABLE_ID_SIZE) &&
-   intel_pstate_no_acpi_pss())
-   return true;
+   !strncmp(hdr.oem_table_id, v_info->oem_table_id,
+   ACPI_OEM_TABLE_ID_SIZE))
+   switch (v_info->oem_pwr_table) {
+   case PSS:
+   return intel_pstate_no_acpi_pss();
+   case PCC:
+   return intel_pstate_has_acpi_ppc();
+   }
}
 
return false;
 }
 #else /* CONFIG_ACPI not enabled */
 static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { return false; 
}
+static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
 #endif /* CONFIG_ACPI */
 
 static int __init intel_pstate_init(void)
-- 
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/

[PATCH 0/2 V4] intel_pstate: skip this driver if hit Sun X86 servers

[Ethan Zhao]

Oracle Sun servers(X86) have power capping features that work via ACPI _PPC 
method,
patch No.1 is used to skip this driver if Oracle Sun server and _PPC detected.
Patch No.2 introduces a kernel command line parameter for those who would like
to enable intel_pstate on Sun X86 servers and be aware of the risk of no power
capping capability working and try to get better performance.

Compiled and tested with stable-3.18-rc5 on Oracle Sun server X4-2 series.

Thanks test and review by Linda Knippers 
and the suggestion,review from Dirk Brandewie .
--
v2: fix break HP Proliant issue.
v3: expand the hardware vendor list.
v4: refine code and doc

Ethan Zhao (2):
  intel_pstate: skip this driver if Sun server has _PPC method
  intel_pstate: add kernel parameter to force loading on Sun X86
servers.

 Documentation/kernel-parameters.txt |  5 
 drivers/cpufreq/intel_pstate.c  | 49 ++---
 2 files changed, 50 insertions(+), 4 deletions(-)

-- 
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 V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7

[Vivek Gautam]

Hi Alim,


On Wed, Nov 26, 2014 at 7:03 PM, Alim Akhtar  wrote:
> Hi Vivek,
>
> On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam  
> wrote:
>> USB and Power regulator on Exynos7 require gpios available
>> in BUS1 pin controller block.
>> So adding the BUS1 pinctrl support.
>>
>> Signed-off-by: Naveen Krishna Ch 
>> Signed-off-by: Vivek Gautam 
>> Cc: Linus Walleij 
>> ---
> Looks good to me.
> Thanks!
>
> Reviewed-by: Alim Akhtar 

Thanks for the review.

>
>>
>> This patch was part of series:
>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>  https://lkml.org/lkml/2014/11/21/247
>>
>> Changes since V1:
>>  - Added support for all pin banks which are part of BUS1 pin controller.
>>
>>  drivers/pinctrl/samsung/pinctrl-exynos.c |   19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index d5d4cfc..44e60dc 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data 
>> exynos7_pin_banks7[] __initconst = {
>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>>  };
>>
>> +/* pin banks of exynos7 pin-controller - BUS1 */
>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst 
>> = {
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
>> +   EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
>> +   EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>> +   EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
>> +   EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
>> +   EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
>> +   EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>> +   EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
>> +};
>> +
>>  const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
>> {
>> /* pin-controller instance 0 Alive data */
>> @@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[] 
>> __initconst = {
>> .pin_banks  = exynos7_pin_banks7,
>> .nr_banks   = ARRAY_SIZE(exynos7_pin_banks7),
>> .eint_gpio_init = exynos_eint_gpio_init,
>> +   }, {
>> +   /* pin-controller instance 8 BUS1 data */
>> +   .pin_banks  = exynos7_pin_banks8,
>> +   .nr_banks   = ARRAY_SIZE(exynos7_pin_banks8),
>> +   .eint_gpio_init = exynos_eint_gpio_init,
>> },
>>  };
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Regards,
> Alim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V5] intel_pstate: add kernel parameter to force loading on Sun X86 servers.

[Ethan Zhao]

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

  intel_pstate = ora_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 
---
 v2: change to hardware vendor specific naming parameter.
 v4: refine code and doc.
 v5: fix a type in 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
+  ora_force
+Force loading intel_pstate on Oracle Sun Servers(X86).
+only for those who be aware of the risk of no power 
capping
+capability working and try to get better performance 
with this
+driver.
 
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  ora_force;
 
 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 PCC:
-   return intel_pstate_has_acpi_ppc();
+   return intel_pstate_has_acpi_ppc() &&
+   (!ora_force);
}
}
 
@@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
 
if (!strcmp(str, "disable"))
no_load = 1;
+   if (!strcmp(str, "ora_force"))
+   ora_force = 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/

[PATCH 1/2 V4] intel_pstate: skip this driver if Sun server has _PPC method

[Ethan Zhao]

Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.

Signed-off-by: Ethan Zhao 
Signed-off-by: Dirk Brandewie 
Tested-by: Linda Knippers 
---
  v2: fix break HP Proliant issue.
  v3: expand the hardware vendor list.
  v4: refine code.

 drivers/cpufreq/intel_pstate.c | 45 ++
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 27bb6d3..1bb62ca 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -943,15 +943,46 @@ static bool intel_pstate_no_acpi_pss(void)
return true;
 }
 
+static bool intel_pstate_has_acpi_ppc(void)
+{
+   int i;
+
+   for_each_possible_cpu(i) {
+   struct acpi_processor *pr = per_cpu(processors, i);
+
+   if (!pr)
+   continue;
+   if (acpi_has_method(pr->handle, "_PPC"))
+   return true;
+   }
+   return false;
+}
+
+enum {
+   PSS,
+   PCC,
+};
+
 struct hw_vendor_info {
u16  valid;
char oem_id[ACPI_OEM_ID_SIZE];
char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+   int  oem_pwr_table;
 };
 
 /* Hardware vendor-specific info that has its own power management modes */
 static struct hw_vendor_info vendor_info[] = {
-   {1, "HP", "ProLiant"},
+   {1, "HP", "ProLiant", PSS},
+   {1, "ORACLE", "X4-2", PCC},
+   {1, "ORACLE", "X4-2L   ", PCC},
+   {1, "ORACLE", "X4-2B   ", PCC},
+   {1, "ORACLE", "X3-2", PCC},
+   {1, "ORACLE", "X3-2L   ", PCC},
+   {1, "ORACLE", "X3-2B   ", PCC},
+   {1, "ORACLE", "X4470M2 ", PCC},
+   {1, "ORACLE", "X4270M3 ", PCC},
+   {1, "ORACLE", "X4270M2 ", PCC},
+   {1, "ORACLE", "X4170M2 ", PCC},
{0, "", ""},
 };
 
@@ -966,15 +997,21 @@ static bool intel_pstate_platform_pwr_mgmt_exists(void)
 
for (v_info = vendor_info; v_info->valid; v_info++) {
if (!strncmp(hdr.oem_id, v_info->oem_id, ACPI_OEM_ID_SIZE) &&
-   !strncmp(hdr.oem_table_id, v_info->oem_table_id, 
ACPI_OEM_TABLE_ID_SIZE) &&
-   intel_pstate_no_acpi_pss())
-   return true;
+   !strncmp(hdr.oem_table_id, v_info->oem_table_id,
+   ACPI_OEM_TABLE_ID_SIZE))
+   switch (v_info->oem_pwr_table) {
+   case PSS:
+   return intel_pstate_no_acpi_pss();
+   case PCC:
+   return intel_pstate_has_acpi_ppc();
+   }
}
 
return false;
 }
 #else /* CONFIG_ACPI not enabled */
 static inline bool intel_pstate_platform_pwr_mgmt_exists(void) { return false; 
}
+static inline bool intel_pstate_has_acpi_ppc(void) { return false; }
 #endif /* CONFIG_ACPI */
 
 static int __init intel_pstate_init(void)
-- 
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/

[PATCH 0/2 V4] intel_pstate: skip this driver if hit Sun X86 servers

[Ethan Zhao]

Oracle Sun servers(X86) have power capping features that work via ACPI _PPC 
method,
patch No.1 is used to skip this driver if Oracle Sun server and _PPC detected.
Patch No.2 introduces a kernel command line parameter for those who would like
to enable intel_pstate on Sun X86 servers and be aware of the risk of no power
capping capability working and try to get better performance.

Compiled and tested with stable-3.18-rc5 on Oracle Sun server X4-2 series.

Thanks test and review by Linda Knippers 
and the suggestion,review from Dirk Brandewie .
--
v2: fix break HP Proliant issue.
v3: expand the hardware vendor list.
v4: refine code and doc

Ethan Zhao (2):
  intel_pstate: skip this driver if Sun server has _PPC method
  intel_pstate: add kernel parameter to force loading on Sun X86
servers.

 Documentation/kernel-parameters.txt |  5 
 drivers/cpufreq/intel_pstate.c  | 49 ++---
 2 files changed, 50 insertions(+), 4 deletions(-)

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

[PATCH 2/2 V5] intel_pstate: add kernel parameter to force loading on Sun X86 servers.

[Ethan Zhao]

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

  intel_pstate = ora_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 
---
 v2: change to hardware vendor specific naming parameter.
 v4: refine code and doc.
 v5: fix a type in 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
+  ora_force
+Force loading intel_pstate on Oracle Sun Servers(X86).
+only for those who be aware of the risk of no power 
capping
+capability working and try to get better performance 
with this
+driver.
 
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  ora_force;
 
 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 PCC:
-   return intel_pstate_has_acpi_ppc();
+   return intel_pstate_has_acpi_ppc() &&
+   (!ora_force);
}
}
 
@@ -1078,6 +1080,8 @@ static int __init intel_pstate_setup(char *str)
 
if (!strcmp(str, "disable"))
no_load = 1;
+   if (!strcmp(str, "ora_force"))
+   ora_force = 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 v2] arm64: ARM: Fix the Generic Timers interrupt active level description

[Jisheng Zhang]

Dear Marc and Liviu,

On Thu, 27 Nov 2014 10:39:28 -0800
Marc Zyngier  wrote:

> On 27/11/14 16:21, Liviu Dudau wrote:
> > The Cortex-A5x TRM states in paragraph "9.2 Generic Timer functional
> > description" that generic timers provide a level not edge interrupt
> > output. Fix the device trees to correctly describe this.
> > 
> > While doing this update the CPU mask to match the number of described
> > CPUs as well as the DT bindings documentation for Generic Timers.
> > 
> > Signed-off-by: Liviu Dudau 
> 
> Acked-by: Marc Zyngier 
> 
>   M.
> 
> > ---
> > 
> > Arnd, Olof: This is on top of linux-next/master as it patches Juno's
> > as well as all the other ARM DTs.
> > 
> > --
> > 
> >  Documentation/devicetree/bindings/arm/arch_timer.txt | 8 
> >  arch/arm64/boot/dts/arm/foundation-v8.dts| 8 
> >  arch/arm64/boot/dts/arm/juno.dts | 8 
> >  arch/arm64/boot/dts/arm/rtsm_ve-aemv8a.dts   | 8 
> >  4 files changed, 16 insertions(+), 16 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt
> > b/Documentation/devicetree/bindings/arm/arch_timer.txt index
> > 37b2caf..6d2aa87 100644 ---
> > a/Documentation/devicetree/bindings/arm/arch_timer.txt +++
> > b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -27,10 +27,10
> > @@ Example: timer {
> > compatible = "arm,cortex-a15-timer",
> >  "arm,armv7-timer";
> > -   interrupts = <1 13 0xf08>,
> > -<1 14 0xf08>,
> > -<1 11 0xf08>,
> > -<1 10 0xf08>;
> > +   interrupts = <1 13 0xf04>,
> > +<1 14 0xf04>,
> > +<1 11 0xf04>,
> > +<1 10 0xf04>;
> > clock-frequency = <1>;
> > };
> >  

Does it mean we also need to fix the interrupt level description under
arch/arm/boot/dts? I found they are also wrong or I misunderstand something?

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

Re: Re: [PATCH v10 2/2] ARM: kprobes: enable OPTPROBES for ARM 32

[Masami Hiramatsu]

(2014/11/27 23:36), Jon Medhurst (Tixy) wrote:
> On Fri, 2014-11-21 at 14:35 +0800, Wang Nan wrote:
>> This patch introduce kprobeopt for ARM 32.
> 
> If I've understood things correctly, this is a feature which inserts
> probes by using a branch instruction to some trampoline code rather than
> using an undefined instruction as a breakpoint. That way we avoid the
> overhead of processing the exception and it is this performance
> improvement which is the main/only reason for implementing it?
> 
> If so, I though it good to see what kind of improvement we get by
> running the micro benchmarks in the kprobes test code. On an A7/A15
> big.LITTLE vexpress board the approximate figures I get are 0.3us for
> optimised probe, 1us for un-optimised, so a three times performance
> improvement. This is with an empty probe pre-handler and no post
> handler, so with a more realistic usecase, the relative improvement we
> get from optimisation would be less.

Indeed, I think we'd better use ftrace to measure performance, since
it is the most realistic usecase. On x86, we have similar number,
and ftrace itself has 0.3-0.4us to record an event. So I guess
it can get 2 times faster. (Of course it depends on the SoC because
memory bandwidth is the key for performance of event recording)


> I thought it good to see what sort of benefits this code achieves,
> especially as it could grow quite complex over time, and the cost of
> that versus the benefit should be considered.

I don't think it's so complex. It's actually cleanly separated.
However, ARM tree should have arch/arm/kernel/kprobe/ dir,
since there are too many kprobe related files under arch/arm/kernel/ ...


>>
>> Limitations:
>>  - Currently only kernel compiled with ARM ISA is supported.
> 
> Supporting Thumb will be very difficult because I don't believe that
> putting a branch into an IT block could be made to work, and you can't
> feasibly know if an instruction is in an IT block other than by first
> using something like the breakpoint probe method and then when that is
> hit examine the IT flags to see if they're set. If they aren't you could
> then change the probe to an optimised probe. Is transforming the probe
> type like that currently supported by the generic kprobes code?

Optprobe framework optimizes probes transparently. If it can not be
optimized, it just do nothing on it.


> Also, the Thumb branch instruction can only jump half as far as the ARM
> mode one. And being 32-bits when a lot of instructions people will want
> to probe are 16-bits will be an additional problem, similar as
> identified below for ARM instructions...
> 
> 
>>
>>  - Offset between probe point and optinsn slot must not larger than
>>32MiB.
> 
> 
> I see that elsewhere [1] people are working on supporting loading kernel
> modules at locations that are out of the range of a branch instruction,
> I guess because with multi-platform kernels and general code bloat
> kernels are getting too big. The same reasons would impact the usability
> of optimized kprobes as well if they're restricted to the range of a
> single branch instruction.
> 
> [1] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/305539.html
> 
> 
>>  Masami Hiramatsu suggests replacing 2 words, it will make
>>things complex. Futher patch can make such optimization.
> 
> I'm wondering how can we replace 2 words if we can't determine if the
> second word is the target of a branch instruction?

on X86, we already have an instruction decoder for finding the
branch target :). But yes, it can be impossible in other arch if
it intensively uses indirect branch.

> E.g. if we had
> 
>   b   after_probe
>   ...
> probe_me: mov r2, #0
> after_probe:  ldr r0, [r1]
> 
> and we inserted a two word probe at probe_me, then the branch to
> after_probe would be to the second half of that 2 word probe. Guess that
> could be worked around by ensuring the 2nd word is an invalid
> instruction and trapping that case then emulating after_probe like we do
> unoptimised probes. This assumes that we can come up with an
> encoding for a 2 word 'long branch' that was suitable. (For Thumb, I
> suspect that we would need at least 3 16-bit instructions to achieve
> that).
> 
> As the commit message says "will make things complex" and I begin to
> wonder if the extra complexity would be worth the benefits. (Considering
> that the resulting optimised probe would only be around twice as fast.)
> 
> 
>>
>> 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 

[PATCH 2/2] cpufreq: show the real avail freqs with the freq_table

[Wang Weidong]

Some time, the policy's max_freq and min_freq will change, so
the avail freqs is not from the cpuinfo_min to cpuinfo_max.
Just add the check for the freq_table.

Signed-off-by: Wang Weidong 
---
 drivers/cpufreq/freq_table.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index df14766..4f86010 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -237,7 +237,9 @@ static ssize_t show_available_freqs(struct cpufreq_policy 
*policy, char *buf,
 * show_boost = false and driver_data != BOOST freq
 * display NON BOOST freqs
 */
-   if (show_boost ^ (pos->flags & CPUFREQ_BOOST_FREQ))
+   if (pos->frequency < policy->min ||
+   pos->frequency > policy->max ||
+   show_boost ^ (pos->flags & CPUFREQ_BOOST_FREQ))
continue;
 
count += sprintf([count], "%d ", pos->frequency);
-- 
1.7.12


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

[PATCH 0/2] fix some problems for cpufreq

[Wang Weidong]

Hi Rafael and Viresh

Sorry to trouble you again. As for:
"acpi-cpufreq: get the cur_freq from acpi_processor_performance states"
I do it again, and add the other patch.

patch #1: acpi-cpufreq: make the freq_table store the same freq value

I think it can work. The set of available states which come
from acpi won't change. Just like the power would be remove,
the acpi driver will do that:
call
 ->acpi_processor_ppc_has_changed
 ->cpufreq_update_policy
 ->acpi_ppc_notifier_block.notifier_call
   ->acpi_processor_ppc_notifier
   ->cpufreq_verify_within_limits
The progress will change the policy's min_freq and max_freq
while it won't change the set of states(freq_tables).

patch #2: cpufreq: show the real avail freqs with the freq_table

when the min_freq and max_freq change, we should sync the availble
freqs.

Regards,
Wang

Wang Weidong (2):
  acpi-cpufreq: make the freq_table store the same freq value
  cpufreq: show the real avail freqs with the freq_table

 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 drivers/cpufreq/freq_table.c   | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
1.7.12


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

[PATCH 1/2] acpi-cpufreq: make the freq_table store the same freq value

[Wang Weidong]

As the initialized freq_tables maybe different from the p-states
values, so the array index is different as well.

Although in this case:
p-states value: [2400 2400 2000 ...], while the freq_tables:
[2400 2000 ... CPUFREQ_TABLE_END]. After setted the freqs 2000,
the perf->state is 3 while the freqs_table's index should be 2.
So when call the get_cur_freq_on_cpu, the freqs value we get
is 2400.

So, make the freq_table store the same value as well.

Signed-off-by: Wang Weidong 
---
 drivers/cpufreq/acpi-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b0c18ed..93634a4 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -779,7 +779,7 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
 
/* table init */
for (i = 0; i < perf->state_count; i++) {
-   if (i > 0 && perf->states[i].core_frequency >=
+   if (i > 0 && perf->states[i].core_frequency >
data->freq_table[valid_states-1].frequency / 1000)
continue;
 
-- 
1.7.12


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [tip:x86/apic] x86, irq: Use cached IOAPIC entry instead of reading from hardware

[Jiang Liu]

On 2014/11/28 3:32, Borislav Petkov wrote:
> On Wed, Nov 26, 2014 at 03:20:08PM -0800, tip-bot for Jiang Liu wrote:
>> Commit-ID:  fda7c08b1349cc4c65f8a5240b10f7e9938604b8
>> Gitweb: 
>> http://git.kernel.org/tip/fda7c08b1349cc4c65f8a5240b10f7e9938604b8
>> Author: Jiang Liu 
>> AuthorDate: Tue, 25 Nov 2014 15:49:53 +0800
>> Committer:  Thomas Gleixner 
>> CommitDate: Wed, 26 Nov 2014 23:52:49 +0100
>>
>> x86, irq: Use cached IOAPIC entry instead of reading from hardware
>>
>> Use cached IOAPIC entry instead of reading data from IOAPIC hardware
>> registers to improve performance.
>>
>> Signed-off-by: Jiang Liu 

>> @@ -1729,28 +1712,6 @@ static unsigned int startup_ioapic_irq(struct 
>> irq_data *data)
>>  return was_pending;
>>  }
>>  
>> -static void __target_IO_APIC_irq(unsigned int irq, struct irq_cfg *cfg,
>> - struct mp_chip_data *data)
>> -{
>> -int apic, pin;
>> -struct irq_pin_list *entry;
>> -u8 vector = cfg->vector;
>> -unsigned int dest = SET_APIC_LOGICAL_ID(cfg->dest_apicid);
>> -
>> -for_each_irq_pin(entry, data->irq_2_pin) {
>> -unsigned int reg;
>> -
>> -apic = entry->apic;
>> -pin = entry->pin;
>> -
>> -io_apic_write(apic, 0x11 + pin*2, dest);
>> -reg = io_apic_read(apic, 0x10 + pin*2);
>> -reg &= ~IO_APIC_REDIR_VECTOR_MASK;
>> -reg |= vector;
>> -io_apic_modify(apic, 0x10 + pin*2, reg);
>> -}
>> -}
>> -
>>  atomic_t irq_mis_count;
>>  
>>  #ifdef CONFIG_GENERIC_PENDING_IRQ
>> @@ -1916,6 +1877,7 @@ static int ioapic_set_affinity(struct irq_data 
>> *irq_data,
>>  {
>>  struct irq_data *parent = irq_data->parent_data;
>>  struct mp_chip_data *data = irq_data->chip_data;
>> +struct irq_pin_list *entry;
>>  struct irq_cfg *cfg;
>>  unsigned long flags;
>>  int ret;
>> @@ -1926,7 +1888,9 @@ static int ioapic_set_affinity(struct irq_data 
>> *irq_data,
>>  cfg = irqd_cfg(irq_data);
>>  data->entry.dest = SET_APIC_LOGICAL_ID(cfg->dest_apicid);
>>  data->entry.vector = cfg->vector;
>> -__target_IO_APIC_irq(irq_data->irq, cfg, irq_data->chip_data);
>> +for_each_irq_pin(entry, data->irq_2_pin)
>> +__ioapic_write_entry(entry->apic, entry->pin,
>> + data->entry);
>>  }
> 
> So let me hold down what tglx and I have been staring at a whole day
> today. This commit breaks booting my AMD laptop with the error messages
> below. The machine ends up in the emergency shell, completely unusable.
> 
> When I revert the commit, x86/apic boots fine again. Btw, I was able to
> reproduce the same issue in a kvm guest so something's definitely wrong.
> 
> If I revert only the last hunk and do
> 
>   __target_IO_APIC_irq(irq_data->irq, cfg, irq_data->chip_data);
> 
> instead and leave the loop over the irq pins in that function as the old
> icode did t, the problem disappears.
Hi Borislav,
Thanks for tracking down to this line of change. I have no
platform to reproduce this bug, so could you please help to revert this
commit and apply following patch to get some data about IOAPIC entry?
Thanks!
Gerry
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a915ee005148..cfada57140bd 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1736,7 +1736,9 @@ static void __target_IO_APIC_irq(unsigned int irq,
struct irq_cfg *cfg,
struct irq_pin_list *entry;
u8 vector = cfg->vector;
unsigned int dest = SET_APIC_LOGICAL_ID(cfg->dest_apicid);
+   union entry_union eu;

+   eu.entry = data->entry;
for_each_irq_pin(entry, data->irq_2_pin) {
unsigned int reg;

@@ -1748,6 +1750,7 @@ static void __target_IO_APIC_irq(unsigned int irq,
struct irq_cfg *cfg,
reg &= ~IO_APIC_REDIR_VECTOR_MASK;
reg |= vector;
io_apic_modify(apic, 0x10 + pin*2, reg);
+   pr_warn("ioapic%d pin%d, hardware reg %x, cached data
%x\n", apic, pin, reg, eu.w1);
}
 }


> 
> I've been trying different things but nothing helped so far as to
> pinpoint where the problem lies. Thus this mail to hold down the current
> situation. More staring later, on a clear head.
> 
> [3.465391] PM: Checking hibernation image partition /dev/sda2
> [3.497559] PM: Hibernation image partition 8:2 present
> [3.501859] PM: Looking for hibernation image.
> [6.600378] usb 1-1: New USB device found, idVendor=0627, idProduct=0001
> [6.608098] usb 1-1: New USB device strings: Mfr=1, Product=3, 
> SerialNumber=5
> [6.614747] usb 1-1: Product: QEMU USB Tablet
> [6.617966] usb 1-1: Manufacturer: QEMU
> [6.632779] usb 1-1: SerialNumber: 42
> [7.648783] ata2.00: qc timeout (cmd 0xa0)
> [7.655222] ata2.00: TEST_UNIT_READY failed (err_mask=0x5)
> [7.818934] 

Re: [PATCH 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer

[Viresh Kumar]

On 27 November 2014 at 19:38, Eduardo Valentin  wrote:
>> Acked-by: Viresh Kumar 
>
> Ok.
>
> though.. "normal practice" says  ack's are oftern used by the maintainer
> of the affected code (quoting Documentation/SubmittingPatches) :-)

Hehe :)

Another paragraph from the same file:

Acked-by: does not necessarily indicate acknowledgement of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
one subsystem maintainer then this usually indicates acknowledgement of just
the part which affects that maintainer's code.  Judgement should be used here.
When in doubt people should refer to the original discussion in the mailing
list archives.

So my Acked-by was as cpufreq subsystem Maintainer :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/7] ARM: hisi: add a common smp_prepares_cpus function

[Wang Long]

As hix5hd2 and hip01 has the same .smp_prepare_cpus
in struct smp_operations, so rename hix5hd2_smp_prepare_cpus
to hisi_common_smp_prepare_cpus.

the hip01 will use hisi_common_smp_prepare_cpus in its
struct smp_operations.

Signed-off-by: Wang Long 
---
 arch/arm/mach-hisi/platsmp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
index 575dd82..b3c3a58 100644
--- a/arch/arm/mach-hisi/platsmp.c
+++ b/arch/arm/mach-hisi/platsmp.c
@@ -96,7 +96,7 @@ struct smp_operations hi3xxx_smp_ops __initdata = {
 #endif
 };
 
-static void __init hix5hd2_smp_prepare_cpus(unsigned int max_cpus)
+static void __init hisi_common_smp_prepare_cpus(unsigned int max_cpus)
 {
hisi_enable_scu_a9();
 }
@@ -125,7 +125,7 @@ static int hix5hd2_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 
 
 struct smp_operations hix5hd2_smp_ops __initdata = {
-   .smp_prepare_cpus   = hix5hd2_smp_prepare_cpus,
+   .smp_prepare_cpus   = hisi_common_smp_prepare_cpus,
.smp_boot_secondary = hix5hd2_boot_secondary,
 #ifdef CONFIG_HOTPLUG_CPU
.cpu_die= hix5hd2_cpu_die,
-- 
1.8.3.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 4/7] ARM: config: enable ARCH_HIP01

[Wang Long]

Make hip01 share the hisi_defconfig.
And add it into multi_v7_defconfig too.

Signed-off-by: Wang Long 
---
 arch/arm/configs/hisi_defconfig | 1 +
 arch/arm/configs/multi_v7_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig
index 1772505..33b0b76 100644
--- a/arch/arm/configs/hisi_defconfig
+++ b/arch/arm/configs/hisi_defconfig
@@ -6,6 +6,7 @@ CONFIG_RD_LZMA=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_HI3xxx=y
 CONFIG_ARCH_HIX5HD2=y
+CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=16
diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 9d7a32f..df335a2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -28,6 +28,7 @@ CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_HI3xxx=y
 CONFIG_ARCH_HIX5HD2=y
+CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
 CONFIG_ARCH_KEYSTONE=y
 CONFIG_ARCH_MESON=y
-- 
1.8.3.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 0/7] ARM: hisi: enable HiP01 SoC

[Wang Long]

This series patch enable Hisilicon HiP01 SoC. The HiP01 SoC series
chip is designed for networking product, it integrates a rich peripheral
interfaces to support network applications and supports both one 
core or dual cores and quad cores. The core is Cortex A9. 

Wang Long (7):
  ARM: debug: add HiP01 debug uart
  ARM: hisi: enable HiP01 SoC
  ARM: dts: Add hip01-ca9x2 dts file
  ARM: config: enable ARCH_HIP01
  ARM: hisi: add a common smp_prepares_cpus function
  ARM: hisi: rename secondary_startup function
  ARM: hisi: enable smp for HiP01

 .../bindings/arm/hisilicon/hisilicon.txt   |  25 +
 arch/arm/Kconfig.debug |  10 ++
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/hip01-ca9x2.dts  |  52 ++
 arch/arm/boot/dts/hip01.dtsi   | 110 +
 arch/arm/configs/hisi_defconfig|   1 +
 arch/arm/configs/multi_v7_defconfig|   1 +
 arch/arm/mach-hisi/Kconfig |   8 ++
 arch/arm/mach-hisi/core.h  |   5 +-
 arch/arm/mach-hisi/headsmp.S   |   2 +-
 arch/arm/mach-hisi/hisilicon.c |  10 ++
 arch/arm/mach-hisi/hotplug.c   |  31 ++
 arch/arm/mach-hisi/platsmp.c   |  56 ++-
 13 files changed, 307 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/boot/dts/hip01-ca9x2.dts
 create mode 100644 arch/arm/boot/dts/hip01.dtsi

-- 
1.8.3.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: Re: [PATCHv4 0/3] Kernel Live Patching

[Masami Hiramatsu]

(2014/11/27 19:52), Petr Mladek wrote:
> On Thu 2014-11-27 19:06:37, Masami Hiramatsu wrote:
>> (2014/11/27 0:27), Josh Poimboeuf wrote:
>>> On Wed, Nov 26, 2014 at 10:18:24AM +0100, Jiri Kosina wrote:
 On Wed, 26 Nov 2014, Masami Hiramatsu wrote:

>> Note to Steve:
>> Masami's IPMODIFY patch is heading for -next via your tree.  Once it 
>> arrives,
>> I'll rebase and make the change to set IPMODIFY.  Do not pull this for 
>> -next
>> yet.  This version (v4) is for review and gathering acks.
>
> BTW, as we discussed IPMODIFY is an exclusive flag. So if we allocate 
> ftrace_ops for each function in each patch, it could be conflict each 
> other.

 Yup, this corresponds to what Petr brought up yesterday. There are cases 
 where all solutions (kpatch, kgraft, klp) would allocate multiple 
 ftrace_ops for a single function entry (think of patching one function 
 multiple times in a row).

 So it's not as easy as just setting the flag.

> Maybe we need to have another ops hashtable to find such conflict and 
> new handler to handle it.

 If I understand your proposal correctly, that would sound like a hackish 
 workaround, trying to basically trick the IPMODIFY flag semantics you just 
 implemented :)
>>>
>>> I think Masami may be proposing something similar to what we do in
>>> kpatch today.  We have a single ftrace_ops and handler which is used for
>>> all functions.  The handler accesses a global hash of kpatch_func
>>> structs which is indexed by the original function's IP address.
>>
>> Hmm, I think both is OK. kpatch method is less memory consuming and
>> will have a bigger overhead. However, as Steven talked at Plumbers Conf.,
>> he will introduce a direct code modifying interface for ftrace. After
>> that is introduced, we don't need to care about performance degradation
>> by patching :)
> 
> Yup, I would prefer to have ftrace_ops per (original) function entry. I mean
> that new patches will reuse the existing ftrace_ops for already
> patched functions. They will just create new ftrace_ops from the
> not-yet-patched symbols.

However, too many ftrace_ops will get bigger overhead if conflicts
happened on any entry, since on such entry ftrace walks through
all registered ftrace_ops and checks its filter. It's a downside.
Perhaps, ftrace needs to have 2 different ftrace_ops lists, one
is for managing, and one is for walk through. And the latter list
drops the ftrace_ops which has trampoline and whose all filtered ip
is exclusively used (iow, such ftrace_ops never be hit in the walk
through).

> Using a single ftrace_ops everywhere would kill the win from
> Steven's direct ftrace optimization.

It depends on the implementation and interface. E.g. an explicit
path-change optimization interface for each address with ftrace_ops,
like as
  ftrace_change_path_ip(ftrace_ops *ops, unsigned long old_addr,
unsigned long new_addr);

This checks ftrace_ops is already registered and has given old_addr
in filter, ensures no other ftrace_ops are registered on given address,
and then optimizes the fentry call to jump to the new_addr.

Anyway, at this point it is not a major discussion point, it's a
kind of minor implementation issue for performance and memory consuming.
We can switch it without changing API.

Thank you,

>>> It actually works out pretty well because it nicely encapsulates the
>>> knowledge about which functions are patched in a single place.  And it
>>> makes it easy to track function versions (for incremental patching and
>>> rollback).
>>>
 What I'd propose instead is to make sure that we always have 
 just a ftrace_ops per function entry, and only update the pointers there 
 as necessary. Fortunately we can do the switch atomically, by making use 
 of ->private.
>>>
>>> But how would you update multiple functions atomically, to enforce
>>> per-thread consistency?
>>
>> At this point, both can do it atomically. We just need an atomic flag
>> for applying patches.
> 
> By other words, we would need something like the "kgr_immutable" flag from
> kGraft. It will make sure that everybody stays with the current code until
> all function entries are updated.
> 
> Best Regards,
> Petr


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

[PATCH 6/7] ARM: hisi: rename secondary_startup function

[Wang Long]

As hix5hd2 and hip01 has the same secondary_startup
so rename hix5hd2_secondary_startup to
to hisi_secondary_startup.

the hip01 will use hisi_secondary_startup for the
secondary core boot.

Signed-off-by: Wang Long 
---
 arch/arm/mach-hisi/core.h| 2 +-
 arch/arm/mach-hisi/headsmp.S | 2 +-
 arch/arm/mach-hisi/platsmp.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-hisi/core.h b/arch/arm/mach-hisi/core.h
index 88b1f48..75520b0 100644
--- a/arch/arm/mach-hisi/core.h
+++ b/arch/arm/mach-hisi/core.h
@@ -12,7 +12,7 @@ extern void hi3xxx_cpu_die(unsigned int cpu);
 extern int hi3xxx_cpu_kill(unsigned int cpu);
 extern void hi3xxx_set_cpu(int cpu, bool enable);
 
-extern void hix5hd2_secondary_startup(void);
+extern void hisi_secondary_startup(void);
 extern struct smp_operations hix5hd2_smp_ops;
 extern void hix5hd2_set_cpu(int cpu, bool enable);
 extern void hix5hd2_cpu_die(unsigned int cpu);
diff --git a/arch/arm/mach-hisi/headsmp.S b/arch/arm/mach-hisi/headsmp.S
index 278889c..81e35b1 100644
--- a/arch/arm/mach-hisi/headsmp.S
+++ b/arch/arm/mach-hisi/headsmp.S
@@ -11,6 +11,6 @@
 
__CPUINIT
 
-ENTRY(hix5hd2_secondary_startup)
+ENTRY(hisi_secondary_startup)
bl  v7_invalidate_l1
b   secondary_startup
diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
index b3c3a58..4a70f56 100644
--- a/arch/arm/mach-hisi/platsmp.c
+++ b/arch/arm/mach-hisi/platsmp.c
@@ -116,7 +116,7 @@ static int hix5hd2_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 {
phys_addr_t jumpaddr;
 
-   jumpaddr = virt_to_phys(hix5hd2_secondary_startup);
+   jumpaddr = virt_to_phys(hisi_secondary_startup);
hix5hd2_set_scu_boot_addr(HIX5HD2_BOOT_ADDRESS, jumpaddr);
hix5hd2_set_cpu(cpu, true);
arch_send_wakeup_ipi_mask(cpumask_of(cpu));
-- 
1.8.3.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 7/7] ARM: hisi: enable smp for HiP01

[Wang Long]

enable smp for HiP01 board.

Signed-off-by: Wang Long 
---
 arch/arm/boot/dts/hip01-ca9x2.dts |  1 +
 arch/arm/mach-hisi/core.h |  3 +++
 arch/arm/mach-hisi/hotplug.c  | 31 
 arch/arm/mach-hisi/platsmp.c  | 50 +++
 4 files changed, 85 insertions(+)

diff --git a/arch/arm/boot/dts/hip01-ca9x2.dts 
b/arch/arm/boot/dts/hip01-ca9x2.dts
index 619d024..605d6b3 100644
--- a/arch/arm/boot/dts/hip01-ca9x2.dts
+++ b/arch/arm/boot/dts/hip01-ca9x2.dts
@@ -25,6 +25,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "hisilicon,hip01-smp";
 
cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/mach-hisi/core.h b/arch/arm/mach-hisi/core.h
index 75520b0..92a682d 100644
--- a/arch/arm/mach-hisi/core.h
+++ b/arch/arm/mach-hisi/core.h
@@ -17,4 +17,7 @@ extern struct smp_operations hix5hd2_smp_ops;
 extern void hix5hd2_set_cpu(int cpu, bool enable);
 extern void hix5hd2_cpu_die(unsigned int cpu);
 
+extern struct smp_operations hip01_smp_ops;
+extern void hip01_set_cpu(int cpu, bool enable);
+extern void hip01_cpu_die(unsigned int cpu);
 #endif
diff --git a/arch/arm/mach-hisi/hotplug.c b/arch/arm/mach-hisi/hotplug.c
index 84e6919..a129aae 100644
--- a/arch/arm/mach-hisi/hotplug.c
+++ b/arch/arm/mach-hisi/hotplug.c
@@ -65,6 +65,9 @@
 #define PMC0_CPU1_PMC_ENABLE   (1 << 7)
 #define PMC0_CPU1_POWERDOWN(1 << 3)
 
+#define HIP01_PERI90x50
+#define PERI9_CPU1_RESET   (1 << 1)
+
 enum {
HI3620_CTRL,
ERROR_CTRL,
@@ -209,6 +212,34 @@ void hix5hd2_set_cpu(int cpu, bool enable)
}
 }
 
+void hip01_set_cpu(int cpu, bool enable)
+{
+   unsigned int temp;
+   struct device_node *np;
+
+   if (!ctrl_base) {
+   np = of_find_compatible_node(NULL, NULL, 
"hisilicon,hip01-sysctrl");
+   if (np)
+   ctrl_base = of_iomap(np, 0);
+   else
+   BUG();
+   }
+
+   if (enable) {
+   /* reset on CPU1  */
+   temp = readl_relaxed(ctrl_base + HIP01_PERI9);
+   temp |= PERI9_CPU1_RESET;
+   writel_relaxed(temp, ctrl_base + HIP01_PERI9);
+
+   udelay(50);
+
+   /* unreset on CPU1 */
+   temp = readl_relaxed(ctrl_base + HIP01_PERI9);
+   temp &= ~PERI9_CPU1_RESET;
+   writel_relaxed(temp, ctrl_base + HIP01_PERI9);
+   }
+}
+
 static inline void cpu_enter_lowpower(void)
 {
unsigned int v;
diff --git a/arch/arm/mach-hisi/platsmp.c b/arch/arm/mach-hisi/platsmp.c
index 4a70f56..8880c8e 100644
--- a/arch/arm/mach-hisi/platsmp.c
+++ b/arch/arm/mach-hisi/platsmp.c
@@ -10,10 +10,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
+#include 
 
 #include "core.h"
 
@@ -132,5 +134,53 @@ struct smp_operations hix5hd2_smp_ops __initdata = {
 #endif
 };
 
+
+#define SC_SCTL_REMAP_CLR  0x0100
+#define HIP01_BOOT_ADDRESS 0x8000
+#define REG_SC_CTRL0x000
+
+void hip01_set_boot_addr(phys_addr_t start_addr, phys_addr_t jump_addr)
+{
+   void __iomem *virt;
+
+   virt = phys_to_virt(start_addr);
+
+   writel_relaxed(0xe51ff004, virt);
+   writel_relaxed(jump_addr, virt + 4);
+}
+
+static int hip01_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+   phys_addr_t jumpaddr;
+   unsigned int remap_reg_value = 0;
+   struct device_node *node;
+
+
+   jumpaddr = virt_to_phys(hisi_secondary_startup);
+   hip01_set_boot_addr(HIP01_BOOT_ADDRESS, jumpaddr);
+
+   node = of_find_compatible_node(NULL, NULL, "hisilicon,hip01-sysctrl");
+   if (WARN_ON(!node))
+   return -1;
+   ctrl_base = of_iomap(node, 0);
+
+   /* set the secondary core boot from DDR */
+   remap_reg_value = readl_relaxed(ctrl_base + REG_SC_CTRL);
+   barrier();
+   remap_reg_value |= SC_SCTL_REMAP_CLR;
+   barrier();
+   writel_relaxed(remap_reg_value, ctrl_base + REG_SC_CTRL);
+
+   hip01_set_cpu(cpu, true);
+
+   return 0;
+}
+
+struct smp_operations hip01_smp_ops __initdata = {
+   .smp_prepare_cpus   = hisi_common_smp_prepare_cpus,
+   .smp_boot_secondary = hip01_boot_secondary,
+};
+
 CPU_METHOD_OF_DECLARE(hi3xxx_smp, "hisilicon,hi3620-smp", _smp_ops);
 CPU_METHOD_OF_DECLARE(hix5hd2_smp, "hisilicon,hix5hd2-smp", _smp_ops);
+CPU_METHOD_OF_DECLARE(hip01_smp, "hisilicon,hip01-smp", _smp_ops);
-- 
1.8.3.4

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

[PATCH 3/7] ARM: dts: Add hip01-ca9x2 dts file

[Wang Long]

Add dts file for Hisilicon hip01 ca9x2 board

Signed-off-by: Wang Long 
---
 .../bindings/arm/hisilicon/hisilicon.txt   |  25 +
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/hip01-ca9x2.dts  |  51 ++
 arch/arm/boot/dts/hip01.dtsi   | 110 +
 4 files changed, 187 insertions(+)
 create mode 100644 arch/arm/boot/dts/hip01-ca9x2.dts
 create mode 100644 arch/arm/boot/dts/hip01.dtsi

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index f717c7b..35b1bd4 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -9,6 +9,10 @@ HiP04 D01 Board
 Required root node properties:
- compatible = "hisilicon,hip04-d01";
 
+HiP01 ca9x2 Board
+Required root node properties:
+   - compatible = "hisilicon,hip01-ca9x2";
+
 
 Hisilicon system controller
 
@@ -37,6 +41,27 @@ Example:
};
 
 ---
+Hisilicon HiP01 system controller
+
+Required properties:
+- compatible : "hisilicon,hip01-sysctrl"
+- reg : Register address and size
+
+The HiP01 system controller is mostly compatible with hisilicon
+system controller,but it has some specific control registers for
+HIP01 SoC family, such as slave core boot, and also some same
+registers located at different offset.
+
+Example:
+
+   /* for hip01-ca9x2 */
+   sysctrl: system-controller@1000 {
+   compatible = "hisilicon,hip01-sysctrl", "hisilicon,sysctrl";
+   reg = <0x1000 0x1000>;
+   reboot-offset = <0x4>;
+   };
+
+---
 Hisilicon CPU controller
 
 Required properties:
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 38c89ca..0e472e32 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_HI3xxx) += hi3620-hi4511.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += hisi-x5hd2-dkb.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
ecx-2000.dtb
+dtb-$(CONFIG_ARCH_HIP01) += hip01-ca9x2.dtb
 dtb-$(CONFIG_ARCH_HIP04) += hip04-d01.dtb
 dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
integratorcp.dtb
diff --git a/arch/arm/boot/dts/hip01-ca9x2.dts 
b/arch/arm/boot/dts/hip01-ca9x2.dts
new file mode 100644
index 000..619d024
--- /dev/null
+++ b/arch/arm/boot/dts/hip01-ca9x2.dts
@@ -0,0 +1,51 @@
+/*
+ * Hisilicon Ltd. HiP01 SoC
+ *
+ * Copyright (C) 2014 Hisilicon Ltd.
+ * Copyright (C) 2014 Huawei Ltd.
+ *
+ * Author: Wang Long 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+/* First 8KB reserved for secondary core boot */
+/memreserve/ 0x8000 0x2000;
+
+#include "hip01.dtsi"
+
+/ {
+   model = "Hisilicon HIP01 Development Board";
+   compatible = "hisilicon,hip01-ca9x2", "hisilicon,hip01";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   reg = <1>;
+   };
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x8000>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
diff --git a/arch/arm/boot/dts/hip01.dtsi b/arch/arm/boot/dts/hip01.dtsi
new file mode 100644
index 000..33130f8
--- /dev/null
+++ b/arch/arm/boot/dts/hip01.dtsi
@@ -0,0 +1,110 @@
+/*
+ * Hisilicon Ltd. HiP01 SoC
+ *
+ * Copyright (c) 2014 Hisilicon Ltd.
+ * Copyright (c) 2014 Huawei Ltd.
+ *
+ * Author: Wang Long 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "skeleton.dtsi"
+
+/ {
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   gic: interrupt-controller@1e001000 {
+   compatible = "arm,cortex-a9-gic";
+   #interrupt-cells = <3>;
+   #address-cells = <0>;
+   interrupt-controller;
+   reg = <0x1a001000 0x1000>, <0x1a000100 0x1000>;
+   };
+
+   hisi_refclk144mhz: refclk144mkhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14400>;
+   clock-output-names = "hisi:refclk144khz";
+ 

[PATCH 2/7] ARM: hisi: enable HiP01 SoC

[Wang Long]

Enable Hisilicon HiP01 SoC. This HiP01 SoC series support both
one core or dual cores and quad cores. The core is Cortex A9.

Signed-off-by: Wang Long 
---
 arch/arm/mach-hisi/Kconfig |  8 
 arch/arm/mach-hisi/hisilicon.c | 10 ++
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-hisi/Kconfig b/arch/arm/mach-hisi/Kconfig
index cd19433..83061ad 100644
--- a/arch/arm/mach-hisi/Kconfig
+++ b/arch/arm/mach-hisi/Kconfig
@@ -22,6 +22,14 @@ config ARCH_HI3xxx
help
  Support for Hisilicon Hi36xx SoC family
 
+config ARCH_HIP01
+   bool "Hisilicon HIP01 family" if ARCH_MULTI_V7
+   select HAVE_ARM_SCU if SMP
+   select HAVE_ARM_TWD if SMP
+   select ARM_GLOBAL_TIMER
+   help
+ Support for Hisilicon HIP01 SoC family
+
 config ARCH_HIP04
bool "Hisilicon HiP04 Cortex A15 family" if ARCH_MULTI_V7
select ARM_ERRATA_798181 if SMP
diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 7744c35..76b9070 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -72,3 +72,13 @@ static const char *hip04_compat[] __initconst = {
 DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
.dt_compat  = hip04_compat,
 MACHINE_END
+
+static const char *hip01_compat[] __initconst = {
+   "hisilicon,hip01",
+   "hisilicon,hip01-ca9x2",
+   NULL,
+};
+
+DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
+   .dt_compat  = hip01_compat,
+MACHINE_END
-- 
1.8.3.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 1/7] ARM: debug: add HiP01 debug uart

[Wang Long]

Add the support of Hisilicon HiP01 debug uart.
The uart of hip01 is 8250 compatible.

Signed-off-by: Wang Long 
---
 arch/arm/Kconfig.debug | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index d8f6a2e..ab65e58 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -240,6 +240,14 @@ choice
  Say Y here if you want the debug print routines to direct
  their output to the UART on Highbank based devices.
 
+   config DEBUG_HIP01_UART
+   bool "Hisilicon Hip01 Debug UART"
+   depends on ARCH_HIP01
+   select DEBUG_UART_8250
+   help
+ Say Y here if you want kernel low-level debugging support
+ on HIP01 UART.
+
config DEBUG_HIP04_UART
bool "Hisilicon HiP04 Debug UART"
depends on ARCH_HIP04
@@ -1117,6 +1125,7 @@ config DEBUG_UART_PHYS
default 0x1600 if ARCH_INTEGRATOR
default 0x18000300 if DEBUG_BCM_5301X
default 0x1c09 if DEBUG_VEXPRESS_UART0_RS1
+   default 0x20001000 if DEBUG_HIP01_UART
default 0x2006 if DEBUG_RK29_UART0
default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2
default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3
@@ -1240,6 +1249,7 @@ config DEBUG_UART_VIRT
default 0xfef36000 if DEBUG_HIGHBANK_UART
default 0xfefff700 if ARCH_IOP33X
default 0xff003000 if DEBUG_U300_UART
+   default 0xffd01000 if DEBUG_HIP01_UART
default DEBUG_UART_PHYS if !MMU
depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \
DEBUG_UART_8250 || DEBUG_UART_PL01X || DEBUG_MESON_UARTAO || \
-- 
1.8.3.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 1/3] kcmp: Move kcmp.h into uapi

[Michael Ellerman]

On Thu, 2014-10-23 at 16:07 +1100, Michael Ellerman wrote:
> kcmp.h appears to be part of the API, it's documented in kcmp(2), and
> the selftests/kcmp code uses it. So move it to uapi so it's actually
> exported.

Looks like this series fell through the cracks?

It still applies on rc6. Should I resend?

cheers

> Signed-off-by: Michael Ellerman 
> ---
>  include/linux/kcmp.h  | 13 +
>  include/uapi/linux/Kbuild |  1 +
>  include/uapi/linux/kcmp.h | 17 +
>  3 files changed, 19 insertions(+), 12 deletions(-)
>  create mode 100644 include/uapi/linux/kcmp.h
> 
> diff --git a/include/linux/kcmp.h b/include/linux/kcmp.h
> index 2dcd1b3aafc8..9dfb23e1771b 100644
> --- a/include/linux/kcmp.h
> +++ b/include/linux/kcmp.h
> @@ -1,17 +1,6 @@
>  #ifndef _LINUX_KCMP_H
>  #define _LINUX_KCMP_H
>  
> -/* Comparison type */
> -enum kcmp_type {
> - KCMP_FILE,
> - KCMP_VM,
> - KCMP_FILES,
> - KCMP_FS,
> - KCMP_SIGHAND,
> - KCMP_IO,
> - KCMP_SYSVSEM,
> -
> - KCMP_TYPES,
> -};
> +#include 
>  
>  #endif /* _LINUX_KCMP_H */
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index b70237e8bc37..1cf50d682dbf 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -209,6 +209,7 @@ header-y += ivtvfb.h
>  header-y += ixjuser.h
>  header-y += jffs2.h
>  header-y += joystick.h
> +header-y += kcmp.h
>  header-y += kd.h
>  header-y += kdev_t.h
>  header-y += kernel-page-flags.h
> diff --git a/include/uapi/linux/kcmp.h b/include/uapi/linux/kcmp.h
> new file mode 100644
> index ..84df14b37360
> --- /dev/null
> +++ b/include/uapi/linux/kcmp.h
> @@ -0,0 +1,17 @@
> +#ifndef _UAPI_LINUX_KCMP_H
> +#define _UAPI_LINUX_KCMP_H
> +
> +/* Comparison type */
> +enum kcmp_type {
> + KCMP_FILE,
> + KCMP_VM,
> + KCMP_FILES,
> + KCMP_FS,
> + KCMP_SIGHAND,
> + KCMP_IO,
> + KCMP_SYSVSEM,
> +
> + KCMP_TYPES,
> +};
> +
> +#endif /* _UAPI_LINUX_KCMP_H */




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

[PATCH v2] thermal: Intel SoC DTS: Don't do thermal zone update inside spin_lock

[Maurice Petallo]

The driver calls spin_lock_irqsave during DTS interrupt. The interrupt
handle then calls thermal_zone_device_update which implicitly calls
a sleep function and produce the following bug:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
in_atomic(): 1, irqs_disabled(): 1, pid: 920, name: irq/86-soc_dts
CPU: 0 PID: 920 Comm: irq/86-soc_dts Tainted: GE  3.17.0-rc2+ #1
Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS 
BYTICRB1.86C.0092.R31.1408290850 08/29/2014
   c25dbe74 c1818cfd f3cc488c c25dbe9c c1059305 c1b4063b
 0001 0001 0398 f3cc488c f6817644 f6817644 f3ecc6c0 c25dbea8
 c18208f2 f6817400 c25dbebc c159b0bb c25dbedc f6817400 f32a2300 c25dbee8
Call Trace:
 [] dump_stack+0x48/0x60
 [] __might_sleep+0xec/0xf4
 [] mutex_lock+0x1c/0x34
 [] thermal_zone_get_temp+0x34/0x59
 [] thermal_zone_device_update+0x2d/0xcb
 [] ? iosf_mbi_write+0x6c/0x74 [iosf_mbi]
 [] soc_irq_thread_fn+0x10c/0x163 [intel_soc_dts_thermal]
 [] irq_thread_fn+0x18/0x2a
 [] irq_thread+0x81/0x11f
 [] ? irq_finalize_oneshot+0x7c/0x7c
 [] ? irq_thread+0x11f/0x11f
 [] ? wake_threads_waitq+0x31/0x31
 [] kthread+0x87/0x8c
 [] ret_from_kernel_thread+0x21/0x30
 [] ? __kthread_parkme+0x55/0x55

Signed-off-by: Maurice Petallo 
Acked-by: Srinivas Pandruvada 
Acked-by: Eduardo Valentin 
CC: Kweh, Hock Leong 
---
Changelog v2:
* Change subject to emphasize that this patch affects only Intel SoC DTS
  (intel_soc_dts_thermal.c)

 drivers/thermal/intel_soc_dts_thermal.c |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/thermal/intel_soc_dts_thermal.c 
b/drivers/thermal/intel_soc_dts_thermal.c
index a6a0a18..5580f5b 100644
--- a/drivers/thermal/intel_soc_dts_thermal.c
+++ b/drivers/thermal/intel_soc_dts_thermal.c
@@ -360,6 +360,9 @@ static void proc_thermal_interrupt(void)
u32 sticky_out;
int status;
u32 ptmc_out;
+   unsigned long flags;
+
+   spin_lock_irqsave(_notify_lock, flags);
 
/* Clear APIC interrupt */
status = iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_READ,
@@ -378,21 +381,20 @@ static void proc_thermal_interrupt(void)
/* reset sticky bit */
status = iosf_mbi_write(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_WRITE,
SOC_DTS_OFFSET_PTTSS, sticky_out);
+   spin_unlock_irqrestore(_notify_lock, flags);
+
for (i = 0; i < SOC_MAX_DTS_SENSORS; ++i) {
pr_debug("TZD update for zone %d\n", i);
thermal_zone_device_update(soc_dts[i]->tzone);
}
-   }
+   } else
+   spin_unlock_irqrestore(_notify_lock, flags);
 
 }
 
 static irqreturn_t soc_irq_thread_fn(int irq, void *dev_data)
 {
-   unsigned long flags;
-
-   spin_lock_irqsave(_notify_lock, flags);
proc_thermal_interrupt();
-   spin_unlock_irqrestore(_notify_lock, flags);
pr_debug("proc_thermal_interrupt\n");
 
return IRQ_HANDLED;
-- 
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 1/2] mfd: rtsx: add func to split u32 into register

[敬锐]

On 11/27/2014 11:23 PM, Dan Carpenter wrote:
>> +static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32 
>> val)
>> >+{
>> >+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val >> 24);
>> >+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val >> 16);
>> >+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val >> 8);
>> >+   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
> This assumes the cpu is little endian.  First convert to big endian
> using cpu_to_be32() and then write it out.
>
>   __be32 be_val = cpu_to_be32()
>
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, be_val);
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, be_val >> 8);
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, be_val >> 16);
>   rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, be_val >> 24);
>
> (Written hurredly in my mail client.  May be wrong).
>
I think we better not use cpu_to_be32() here, leave the work to caller
may be better.

eg, in sd_ops.c the cmd.arg is constructed bit by bit, we can put the right
byte to the right register by shift, so the endian check is not 
need.N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z��wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i

RE: [PATCH] thermal: Don't call thermal_zone_device_update inside spinlock

[Petallo, MauriceX R]

Hi,
Ok. I will update the title.
Thanks for the feedbacks and Ack.

Regards,
-Maurice

-Original Message-
From: Srinivas Pandruvada [mailto:srinivas.pandruv...@linux.intel.com] 
Sent: Wednesday, November 26, 2014 1:57 AM
To: Eduardo Valentin
Cc: Petallo, MauriceX R; Zhang, Rui; linux...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] thermal: Don't call thermal_zone_device_update inside 
spinlock

On Tue, 2014-11-25 at 01:23 -0400, Eduardo Valentin wrote:
Hi, 
> Hi,
> 
> A minor thing. Your patch title makes us think this fix affects the 
> thermal subsystem completely, whereas it affects a specific driver.
> 
Good point. I overlooked this.

Maurice,
Change the title to something like
"thermal: Intel SoC DTS: Don't call thermal_zone_device_update inside spinlock"

Thanks,
Srinivas 
> 
> On Thu, Nov 13, 2014 at 06:47:04PM +0800, Maurice Petallo wrote:
> > The driver calls spin_lock_irqsave during DTS interrupt. The 
> > interrupt handle then calls thermal_zone_device_update which 
> > implicitly calls a sleep function and produce the following bug:
> >
>  
> > BUG: sleeping function called from invalid context at 
> > kernel/locking/mutex.c:97
> > in_atomic(): 1, irqs_disabled(): 1, pid: 920, name: irq/86-soc_dts
> > CPU: 0 PID: 920 Comm: irq/86-soc_dts Tainted: GE  3.17.0-rc2+ #1
> > Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS 
> > BYTICRB1.86C.0092.R31.1408290850 08/29/2014
> >    c25dbe74 c1818cfd f3cc488c c25dbe9c c1059305 
> > c1b4063b
> >  0001 0001 0398 f3cc488c f6817644 f6817644 f3ecc6c0 
> > c25dbea8
> >  c18208f2 f6817400 c25dbebc c159b0bb c25dbedc f6817400 f32a2300 
> > c25dbee8 Call Trace:
> >  [] dump_stack+0x48/0x60
> >  [] __might_sleep+0xec/0xf4  [] 
> > mutex_lock+0x1c/0x34  [] thermal_zone_get_temp+0x34/0x59  
> > [] thermal_zone_device_update+0x2d/0xcb
> >  [] ? iosf_mbi_write+0x6c/0x74 [iosf_mbi]  [] 
> > soc_irq_thread_fn+0x10c/0x163 [intel_soc_dts_thermal]  [] 
> > irq_thread_fn+0x18/0x2a  [] irq_thread+0x81/0x11f  
> > [] ? irq_finalize_oneshot+0x7c/0x7c  [] ? 
> > irq_thread+0x11f/0x11f  [] ? wake_threads_waitq+0x31/0x31  
> > [] kthread+0x87/0x8c  [] 
> > ret_from_kernel_thread+0x21/0x30  [] ? 
> > __kthread_parkme+0x55/0x55
> > 
> > Signed-off-by: Maurice Petallo 
> > Acked-by: Srinivas Pandruvada 
> > ---
> >  drivers/thermal/intel_soc_dts_thermal.c |   12 +++-
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/thermal/intel_soc_dts_thermal.c 
> > b/drivers/thermal/intel_soc_dts_thermal.c
> > index a6a0a18..5580f5b 100644
> > --- a/drivers/thermal/intel_soc_dts_thermal.c
> > +++ b/drivers/thermal/intel_soc_dts_thermal.c
> > @@ -360,6 +360,9 @@ static void proc_thermal_interrupt(void)
> > u32 sticky_out;
> > int status;
> > u32 ptmc_out;
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(_notify_lock, flags);
> >  
> > /* Clear APIC interrupt */
> > status = iosf_mbi_read(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_READ, @@ 
> > -378,21 +381,20 @@ static void proc_thermal_interrupt(void)
> > /* reset sticky bit */
> > status = iosf_mbi_write(BT_MBI_UNIT_PMC, BT_MBI_BUNIT_WRITE,
> > SOC_DTS_OFFSET_PTTSS, sticky_out);
> > +   spin_unlock_irqrestore(_notify_lock, flags);
> > +
> > for (i = 0; i < SOC_MAX_DTS_SENSORS; ++i) {
> > pr_debug("TZD update for zone %d\n", i);
> > thermal_zone_device_update(soc_dts[i]->tzone);
> > }
> > -   }
> > +   } else
> > +   spin_unlock_irqrestore(_notify_lock, flags);
> >  
> >  }
> >  
> >  static irqreturn_t soc_irq_thread_fn(int irq, void *dev_data)  {
> > -   unsigned long flags;
> > -
> > -   spin_lock_irqsave(_notify_lock, flags);
> > proc_thermal_interrupt();
> > -   spin_unlock_irqrestore(_notify_lock, flags);
> > pr_debug("proc_thermal_interrupt\n");
> >  
> > return IRQ_HANDLED;
> 
> A part from the minor thing I mentioned before, you can add my:
> 
> Acked-by: Eduardo Valentin 
> 
> > --
> > 1.7.9.5
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pm" 
> > in the body of a message to majord...@vger.kernel.org More majordomo 
> > info at  http://vger.kernel.org/majordomo-info.html

linux-next: manual merge of the kbuild tree with the arm-soc tree

[Stephen Rothwell]

Hi Michal,

Today's linux-next merge of the kbuild tree got a conflict in
scripts/Kbuild.include between commit 9fb5e5372208 ("dts, kbuild:
Factor out dtbs install rules to Makefile.dtbinst") from the arm-soc
tree and commit 371fdc77af44 ("kbuild: collect shorthands into
scripts/Kbuild.include") from the kbuild tree.

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

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

diff --cc scripts/Kbuild.include
index 5374b1bdf02f,0f909814edfc..
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@@ -180,11 -180,17 +180,23 @@@ build := -f $(srctree)/scripts/Makefile
  modbuiltin := -f $(srctree)/scripts/Makefile.modbuiltin obj
  
  ###
 +# Shorthand for $(Q)$(MAKE) -f scripts/Makefile.dtbinst obj=
 +# Usage:
 +# $(Q)$(MAKE) $(dtbinst)=dir
 +dtbinst := -f $(if $(KBUILD_SRC),$(srctree)/)scripts/Makefile.dtbinst obj
 +
++###
+ # Shorthand for $(Q)$(MAKE) -f scripts/Makefile.clean obj=
+ # Usage:
+ # $(Q)$(MAKE) $(clean)=dir
+ clean := -f $(srctree)/scripts/Makefile.clean obj
+ 
+ ###
+ # Shorthand for $(Q)$(MAKE) -rR -f scripts/Makefile.headersinst obj=
+ # Usage:
+ # $(Q)$(MAKE) $(hdr-inst)=dir
+ hdr-inst := -rR -f $(srctree)/scripts/Makefile.headersinst obj
+ 
  # Prefix -I with $(srctree) if it is not an absolute path.
  # skip if -I has no parameter
  addtree = $(if $(patsubst -I%,%,$(1)), \


pgpvQC8lJGOru.pgp
Description: OpenPGP digital signature

Re: [PATCH 2/2] mmc: rtsx: add support for sdio card

[敬锐]

On 11/27/2014 11:43 PM, Dan Carpenter wrote:
>> +int stat_idx = sd_status_index(rsp_type);
> I have always hated this terrible pointer math.  5 is relative to
> pcr->host_cmds_ptr + 1.  It's a mess...
5 mean CRC7 offset of Response R1, see SD spec V3.01 Page 82.
4.9.1 R1 (normal response command).

And we have to +1 to skip unused/undefined data.

Re: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.

[Ken Xue]

On Thu, 2014-11-27 at 13:46 +0200, Mika Westerberg wrote:
> On Wed, Nov 26, 2014 at 06:31:38PM +0800, Ken Xue wrote:
> > On Monday, 2014-11-24 at 02:47 +0100, Rafael J. Wysocki wrote:
> > > On Monday, November 24, 2014 01:02:30 AM Xue, Ken wrote:
> > > > 
> > > > On Tuesday, November 18, 2014 01:58:11 PM Ken Xue wrote:
> > > > > This new feature is to interpret AMD specific ACPI device to platform 
> > > > > device such as I2C, UART found on AMD CZ and later chipsets. It is 
> > > > > based on example INTEL LPSS. Now, it can support AMD I2C & UART.
> > > > > 
> > > > > Signed-off-by: Ken Xue 
> > > > > Signed-off-by: Jeff Wu 
> > > > 
> > > > Generally speaking, this seems to duplicate much code from acpi_lpss 
> > > > which should be re-used instead.  What about moving the code that will 
> > > > be common between acpi_lpss and the new driver into a new file (say 
> > > > acpi_soc.c)?
> > > > 
> > > > Also, you need to avoid automatic creation of platform devices when 
> > > > !X86_AMD_PLATFORM_DEVICE in analogy with what acpi_lpss does, or bad 
> > > > things will happen.
> > > > 
> > > > [ken] sounds fair enough.  Let me take action to merge drivers to 
> > > > acpi_soc.c ? or you have other plan?
> > > 
> > > I'd prefer the common code to reside in one file (or one .c file and one 
> > > header
> > > file), and the driver-specific code to stay in separate per-driver files.
> > > 
> > [Ken] I wrote a proto type for acpi_soc.c. please help to confirm if it
> > can match your ideal. if yes, i will submit a new patch after do more
> > test and refine codes. I think it will impact lpss driver greatly, even
> > i have taken it into account. below codes is for acpi_soc.c.
> 
> In general looks good. I have few comments though.
[Ken] thanks for your comments.

> > 
> > >From fc323fb7b3b4cbb79bda05ce3b1d6d8dfe5e883b Mon Sep 17 00:00:00 2001
> > From: Ken Xue 
> > Date: Wed, 26 Nov 2014 17:15:30 +0800
> > Subject: [PATCH] This is proto type for acpi_soc.
> > 
> > Signed-off-by: Ken Xue 
> > ---
> >  arch/x86/Kconfig|  11 +++
> >  drivers/acpi/Makefile   |   2 +-
> >  drivers/acpi/acpi_apd.c | 123 
> >  drivers/acpi/acpi_soc.c | 213
> > 
> 
> This is line-wrapped, please make sure when you submit the actual patch
> that it is formatted properly. Also you need proper changelog etc.
[Ken] sure. 

> > +#include "internal.h"
> > +#include "acpi_soc.h"
> > +
> > +struct acpi_soc asoc;
> 
> static?
> 
> Also Is "asoc" good name? That might get confused with Alsa SoC (ASoC).
[Ken] I will use "static", and change name to be a_soc.


> > +
> > +static struct acpi_soc_dev_desc cz_i2c_desc = {
> > +   .setup = acpi_apd_setup;
> > +   .fixed_clk_rate = 13300,
> 
> Oh, good so now we can get rid the hack we did for
> i2c-designware-platdrv.c with this commit:
> 
> a445900c906092f i2c: designware: Add support for AMD I2C controller
> 
> Since now you have means to pass clock to the driver.
> 
> Are you going to handle that driver as well?
[Ken]sure, thanks. this was one of reasons to create AMD APD.

> > +};
> > +
> > +static struct acpi_soc_dev_desc cz_uart_desc = {
> > +   .setup = acpi_apd_setup;
> > +   .fixed_clk_rate = 4800,
> > +};
> > +
> > +#else
> > +
> > +#define APD_ADDR(desc) (0UL)
> > +
> > +#endif /* CONFIG_X86_INTEL_LPSS */
> > +
> > +static struct acpi_device_id acpi_apd_device_ids[] = {
> 
> const?
[ken]No. "acpi_soc_dev_desc" may be modified later.

> > +   /* Generic apd devices */
> > +   { "AMD0010", APD_ADDR(cz_i2c_desc) },
> > +   { "AMD0020", APD_ADDR(cz_uart_desc) },
> > +   { }
> > +};
> > +
> > +#ifdef X86_AMD_PLATFORM_DEVICE
> > +
> > +static ssize_t apd_device_desc_show(struct device *dev,
> > +   struct device_attribute *attr, char *buf)
> > +{
> > +   int ret;
> > +   struct acpi_device *adev;
> > +   struct acpi_soc_dev_private_data *pdata;
> > +   struct acpi_soc_dev_desc *dev_desc;
> > +
> > +   ret = acpi_bus_get_device(ACPI_HANDLE(dev), );
> > +   if (WARN_ON(ret))
> > +   return ret;
> > +
> > +   pdata = acpi_driver_data(adev);
> > +   if (WARN_ON(!pdata || !pdata->dev_desc))
> > +   return -ENODEV;
> > +   
> > +   dev_desc = pdata->dev_desc;
> > +   if (dev_desc->fixed_clk_rate)
> > +   return sprintf(buf, "Required fix rate clk %s: %ld\n",
> > +   dev_desc->clk->name,
> > +   dev_desc->fixed_clk_rate);
> > +   else
> > +   return sprintf(buf, "No need clk\n");
> > +}
> > +
> > +static DEVICE_ATTR(device_desc, S_IRUSR, apd_device_desc_show, NULL);
> > +
> > +static struct attribute *apd_attrs[] = {
> > +   _attr_device_desc.attr,
> > +   NULL,
> > +};
> > +
> > +static struct attribute_group apd_attr_group = {
> > +   .attrs = apd_attrs,
> > +   .name = "apd",
> > +};
> 
> This requires updating sysfs ABI but then again, do you really need the
> above? And does it belong to sysfs in the first place?
[Ken] 

Re: [03/19] clk: samsung: exynos5433: Add clocks using common clock framework

[Chanwoo Choi]

Hi Pankaj,

On 11/27/2014 08:48 PM, Pankaj Dubey wrote:
> Hi Chanwoo,
> 
> On Thursday 27 November 2014 01:05 PM, Chanwoo Choi wrote:
>> This patch adds the support for CMU (Clock Management Units) of Exynos5433
>> which is 64bit SoC and has Octa-cores. This patch supports necessary clocks
>> for kernel boot as following:
>> - PLL/MMC/UART/MCT/I2C/SPI
>>
>> Cc: Sylwester Nawrocki 
>> Cc: Tomasz Figa 
>> Signed-off-by: Chanwoo Choi 
>> Acked-by: Inki Dae 
>> Acked-by: Geunsik Lim 
>>
>> ---
>> drivers/clk/samsung/Makefile   |   1 +
>>   drivers/clk/samsung/clk-exynos5433.c   | 971 
>> +
>>   include/dt-bindings/clock/exynos5433.h | 200 +++
>>   3 files changed, 1172 insertions(+)
>>   create mode 100644 drivers/clk/samsung/clk-exynos5433.c
>>   create mode 100644 include/dt-bindings/clock/exynos5433.h
>>

(snip)

>> +
>> +static struct samsung_div_clock top_div_clks[] __initdata = {
>> +/* DIV_TOP2 */
>> +DIV(CLK_DIV_ACLK_FSYS_200, "div_aclk_fsys_200", "mout_bus_pll_user",
>> +DIV_TOP2, 0, 3),
>> +
>> +/* DIV_TOP3 */
>> +DIV(CLK_DIV_ACLK_IMEM_SSSX, "div_aclk_imem_sssx",
>> +"mout_bus_pll_user", DIV_TOP3, 24, 3),
> 
> Isn't this clock name should be div_aclk_imem_sssx_266 as per UM?

You're right. So, I fxied clock name on patch11[1] for CMU_BUSx domains.
- [1] [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} 
domains

/* DIV_TOP3 */
-   DIV(CLK_DIV_ACLK_IMEM_SSSX, "div_aclk_imem_sssx",
+   DIV(CLK_DIV_ACLK_IMEM_SSSX_266, "div_aclk_imem_sssx_266",
"mout_bus_pll_user", DIV_TOP3, 24, 3),

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 v3] can: Convert to runtime_pm

[Appana Durga Kedareswara Rao]

Hi Soren,

-Original Message-
From: Sören Brinkmann [mailto:soren.brinkm...@xilinx.com]
Sent: Thursday, November 27, 2014 11:54 PM
To: Appana Durga Kedareswara Rao
Cc: w...@grandegger.com; m...@pengutronix.de; Michal Simek; 
grant.lik...@linaro.org; robh...@kernel.org; devicet...@vger.kernel.org; 
net...@vger.kernel.org; linux-kernel@vger.kernel.org; 
linux-...@vger.kernel.org; Appana Durga Kedareswara Rao; 
linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH v3] can: Convert to runtime_pm

Hi Kedar,

On Thu, 2014-11-27 at 06:38PM +0530, Kedareswara rao Appana wrote:
> Instead of enabling/disabling clocks at several locations in the
> driver, use the runtime_pm framework. This consolidates the actions
> for runtime PM in the appropriate callbacks and makes the driver more
> readable and mantainable.
>
> Signed-off-by: Soren Brinkmann 
> Signed-off-by: Kedareswara rao Appana 
> ---
> Changes for v3:
>   - Converted the driver to use runtime_pm.
> Changes for v2:
>   - Removed the struct platform_device* from suspend/resume
> as suggest by Lothar.
>
>  drivers/net/can/xilinx_can.c |  119
> +
>  1 files changed, 72 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/net/can/xilinx_can.c
> b/drivers/net/can/xilinx_can.c index 8a998e3..1be28ed 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define DRIVER_NAME  "xilinx_can"
>
> @@ -138,7 +139,7 @@ struct xcan_priv {
>   u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
>   void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
>   u32 val);
> - struct net_device *dev;
> + struct device *dev;
>   void __iomem *reg_base;
>   unsigned long irq_flags;
>   struct clk *bus_clk;
> @@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
>   struct xcan_priv *priv = netdev_priv(ndev);
>   int ret;
>
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime CAN resume failed(%d)\n\r",

There might be other issues than the resume that make this fail. It should 
probably just say 'pm_runtime_get failed'.
The CAN in the string should not be needed, the netdev_err macro makes sure the 
device name is printed.
Can we have a space between 'failed' and the error code?
There should not be a '\r'

K sure will modify the error message as you explained above.

> + __func__, ret);
> + return ret;
> + }
> +
>   ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
>   ndev->name, ndev);
>   if (ret < 0) {
> @@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
>   goto err;
>   }
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable device clock\n");
> - goto err_irq;
> - }
> -
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable bus clock\n");
> - goto err_can_clk;
> - }
> -
>   /* Set chip into reset mode */
>   ret = set_reset_mode(ndev);
>   if (ret < 0) {
>   netdev_err(ndev, "mode resetting failed!\n");
> - goto err_bus_clk;
> + goto err_irq;
>   }
>
>   /* Common open */
>   ret = open_candev(ndev);
>   if (ret)
> - goto err_bus_clk;
> + goto err_irq;
>
>   ret = xcan_chip_start(ndev);
>   if (ret < 0) {
> @@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
>
>  err_candev:
>   close_candev(ndev);
> -err_bus_clk:
> - clk_disable_unprepare(priv->bus_clk);
> -err_can_clk:
> - clk_disable_unprepare(priv->can_clk);
>  err_irq:
>   free_irq(ndev->irq, ndev);
>  err:
> + pm_runtime_put(priv->dev);
> +
>   return ret;
>  }
>
> @@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
>   netif_stop_queue(ndev);
>   napi_disable(>napi);
>   xcan_chip_stop(ndev);
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
>   free_irq(ndev->irq, ndev);
>   close_candev(ndev);
>
>   can_led_event(ndev, CAN_LED_EVENT_STOP);
> + pm_runtime_put(priv->dev);
>
>   return 0;
>  }
> @@ -934,27 +927,21 @@ static int xcan_get_berr_counter(const struct 
> net_device *ndev,
>   struct xcan_priv *priv = netdev_priv(ndev);
>   int ret;
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret)
> - goto err;
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime resume failed(%d)\n\r",
> + __func__, ret);

As above.

K will modify this too.

Regards,
Kedar.
Sören


This email and any 

RE: [PATCH v3] can: Convert to runtime_pm

[Appana Durga Kedareswara Rao]

Hi Michal,

-Original Message-
From: Michal Simek [mailto:michal.si...@xilinx.com]
Sent: Thursday, November 27, 2014 8:17 PM
To: Appana Durga Kedareswara Rao; w...@grandegger.com; m...@pengutronix.de; 
Michal Simek; Soren Brinkmann; grant.lik...@linaro.org; robh...@kernel.org
Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; 
devicet...@vger.kernel.org; Appana Durga Kedareswara Rao
Subject: Re: [PATCH v3] can: Convert to runtime_pm

On 11/27/2014 02:08 PM, Kedareswara rao Appana wrote:
> Instead of enabling/disabling clocks at several locations in the
> driver, use the runtime_pm framework. This consolidates the actions
> for runtime PM in the appropriate callbacks and makes the driver more
> readable and mantainable.
>
> Signed-off-by: Soren Brinkmann 
> Signed-off-by: Kedareswara rao Appana 
> ---
> Changes for v3:
>   - Converted the driver to use runtime_pm.
> Changes for v2:
>   - Removed the struct platform_device* from suspend/resume
> as suggest by Lothar.
>
>  drivers/net/can/xilinx_can.c |  119
> +
>  1 files changed, 72 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/net/can/xilinx_can.c
> b/drivers/net/can/xilinx_can.c index 8a998e3..1be28ed 100644
> --- a/drivers/net/can/xilinx_can.c
> +++ b/drivers/net/can/xilinx_can.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #define DRIVER_NAME  "xilinx_can"
>
> @@ -138,7 +139,7 @@ struct xcan_priv {
>   u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
>   void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
>   u32 val);
> - struct net_device *dev;
> + struct device *dev;
>   void __iomem *reg_base;
>   unsigned long irq_flags;
>   struct clk *bus_clk;
> @@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
>   struct xcan_priv *priv = netdev_priv(ndev);
>   int ret;
>
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime CAN resume failed(%d)\n\r",
> + __func__, ret);
> + return ret;
> + }
> +
>   ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
>   ndev->name, ndev);
>   if (ret < 0) {
> @@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
>   goto err;
>   }
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable device clock\n");
> - goto err_irq;
> - }
> -
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret) {
> - netdev_err(ndev, "unable to enable bus clock\n");
> - goto err_can_clk;
> - }
> -
>   /* Set chip into reset mode */
>   ret = set_reset_mode(ndev);
>   if (ret < 0) {
>   netdev_err(ndev, "mode resetting failed!\n");
> - goto err_bus_clk;
> + goto err_irq;
>   }
>
>   /* Common open */
>   ret = open_candev(ndev);
>   if (ret)
> - goto err_bus_clk;
> + goto err_irq;
>
>   ret = xcan_chip_start(ndev);
>   if (ret < 0) {
> @@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
>
>  err_candev:
>   close_candev(ndev);
> -err_bus_clk:
> - clk_disable_unprepare(priv->bus_clk);
> -err_can_clk:
> - clk_disable_unprepare(priv->can_clk);
>  err_irq:
>   free_irq(ndev->irq, ndev);
>  err:
> + pm_runtime_put(priv->dev);
> +
>   return ret;
>  }
>
> @@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
>   netif_stop_queue(ndev);
>   napi_disable(>napi);
>   xcan_chip_stop(ndev);
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
>   free_irq(ndev->irq, ndev);
>   close_candev(ndev);
>
>   can_led_event(ndev, CAN_LED_EVENT_STOP);
> + pm_runtime_put(priv->dev);
>
>   return 0;
>  }
> @@ -934,27 +927,21 @@ static int xcan_get_berr_counter(const struct 
> net_device *ndev,
>   struct xcan_priv *priv = netdev_priv(ndev);
>   int ret;
>
> - ret = clk_prepare_enable(priv->can_clk);
> - if (ret)
> - goto err;
> + ret = pm_runtime_get_sync(priv->dev);
> + if (ret < 0) {
> + netdev_err(ndev, "%s: runtime resume failed(%d)\n\r",
> + __func__, ret);
> + return ret;
> + }
>
> - ret = clk_prepare_enable(priv->bus_clk);
> - if (ret)
> - goto err_clk;
>
>   bec->txerr = priv->read_reg(priv, XCAN_ECR_OFFSET) & XCAN_ECR_TEC_MASK;
>   bec->rxerr = ((priv->read_reg(priv, XCAN_ECR_OFFSET) &
>   XCAN_ECR_REC_MASK) >> XCAN_ESR_REC_SHIFT);
>
> - clk_disable_unprepare(priv->bus_clk);
> - clk_disable_unprepare(priv->can_clk);
> + 

[PATCH v2 3/7] pinctrl: zynq: Document DT binding

[Soren Brinkmann]

Add documentation for the devicetree binding for the Zynq pincontroller.

Signed-off-by: Soren Brinkmann 
Tested-by: Andreas Färber 
---
Changes since v1:
 - fix typo
 - add USB related documentation
 - remove 'pinctrl-' prefix for pinctrl sub-nodes
 - update documentation to enforce strict separation of pinmux
   and pinconf nodes
   - update example accordingly
---
 .../bindings/pinctrl/xlnx,zynq-pinctrl.txt | 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt
new file mode 100644
index ..b7b55a964f65
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.txt
@@ -0,0 +1,104 @@
+   Binding for Xilinx Zynq Pinctrl
+
+Required properties:
+- compatible: "xlnx,zynq-pinctrl"
+- syscon: phandle to SLCR
+- reg: Offset and length of pinctrl space in SLCR
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Zynq's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, slew rate, etc.
+
+Each configuration node can consist of multiple nodes describing the pinmux and
+pinconf options. Those nodes can be pinmux nodes or pinconf nodes.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Required properties for pinmux nodes are:
+ - groups: A list of pinmux groups.
+ - function: The name of a pinmux function to activate for the specified set
+   of groups.
+
+Required properties for configuration nodes:
+One of:
+ - pins: a list of pin names
+ - groups: A list of pinmux groups.
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinmux subnode:
+ groups, function
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pinconf subnode:
+ groups, pins, bias-disable, bias-high-impedance, bias-pull-up, slew-rate,
+ low-power-disable, low-power-enable
+
+ Valid arguments for 'slew-rate' are '0' and '1' to select between slow and 
fast
+ respectively.
+
+ Valid values for groups are:
+   ethernet0_0_grp, ethernet1_0_grp, mdio0_0_grp, mdio1_0_grp,
+   qspi0_0_grp, qspi1_0_grp, qspi_fbclk, qspi_cs1_grp, spi0_0_grp,
+   spi0_1_grp - spi0_2_grp, spi1_0_grp - spi1_3_grp, sdio0_0_grp - sdio0_2_grp,
+   sdio1_0_grp - sdio1_3_grp, sdio0_emio_wp, sdio0_emio_cd, sdio1_emio_wp,
+   sdio1_emio_cd, smc0_nor, smc0_nor_cs1_grp, smc0_nor_addr25_grp, smc0_nand,
+   can0_0_grp - can0_10_grp, can1_0_grp - can1_11_grp, uart0_0_grp - 
uart0_10_grp,
+   uart1_0_grp - uart1_11_grp, i2c0_0_grp - i2c0_10_grp, i2c1_0_grp - 
i2c1_10_grp,
+   ttc0_0_grp - ttc0_2_grp, ttc1_0_grp - ttc1_2_grp, swdt0_0_grp - swdt0_4_grp,
+   gpio0_0_grp - gpio0_53_grp, usb0_0_grp, usb1_0_grp
+
+ Valid values for pins are:
+   MIO0 - MIO53
+
+ Valid values for function are:
+   ethernet0, ethernet1, mdio0, mdio1, qspi0, qspi1, qspi_fbclk, qspi_cs1,
+   spi0, spi1, sdio0, sdio0_pc, sdio0_cd, sdio0_wp,
+   sdio1, sdio1_pc, sdio1_cd, sdio1_wp,
+   smc0_nor, smc0_nor_cs1, smc0_nor_addr25, smc0_nand, can0, can1, uart0, 
uart1,
+   i2c0, i2c1, ttc0, ttc1, swdt0, gpio0, usb0, usb1
+
+The following driver-specific properties as defined here are valid to specify 
in
+a pin configuration subnode:
+ - io-standard: Configure the pin to use the selected IO standard according to
+   this mapping:
+1: LVCMOS18
+2: LVCMOS25
+3: LVCMOS33
+4: HSTL
+
+Example:
+   pinctrl0: pinctrl@700 {
+   compatible = "xlnx,pinctrl-zynq";
+   reg = <0x700 0x200>;
+   syscon = <>;
+
+   pinctrl_uart1_default: uart1-default {
+   mux {
+   groups = "uart1_10_grp";
+   function = "uart1";
+   };
+
+   conf {
+   groups = "uart1_10_grp";
+   slew-rate = <0>;
+   io-standard = <1>;
+   };
+
+   conf-rx {
+   pins = "MIO49";
+   bias-high-impedance;
+   };
+
+   conf-tx {
+   pins = "MIO48";
+   bias-disable;
+   };
+   };
+   };
-- 
2.1.3.1.ge241007

--
To 

[PATCH v2 4/7] pinctrl: Add driver for Zynq

[Soren Brinkmann]

This adds a pin-control driver for Zynq.

Signed-off-by: Soren Brinkmann 
Tested-by: Andreas Färber 
---
Changes since v1:
 - fix EMIO_SD1_CD pin name
 - add USB to pinmux options

changes since RFCv2:
 - let Zynq select PINCTRL_ZYNQ. Boot hangs when pinctrl information is
   present in DT but no driver available.
 - add #defines to get rid of magical constants
 - add commas at end of initializers
 - separate changes in mach-zynq in separate patch
 - add driver specific io-standard DT property
 - refactored pinconf set function to not require arguments for
   argument-less properties
 - squash other patches in
   - support for IO-standard property
   - support for low-power mode property
   - migration to pinconf_generic_dt_node_to_map_all()
 - use newly created infrastructure to add pass driver-specific DT
   params to pinconf-generic

changes since RFC:
 - use syscon/regmap to access registers in SLCR space
 - rebase to 3.18: rename enable -> set_mux
 - add kernel-doc
 - support pinconf
   - supported attributes
 - pin-bias: pull up, tristate, disable
 - slew-rate: 0 == slow, 1 == fast; generic pinconf does not display
   argument
---
 drivers/pinctrl/Kconfig|8 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-zynq.c | 1176 
 3 files changed, 1185 insertions(+)
 create mode 100644 drivers/pinctrl/pinctrl-zynq.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index d014f22f387a..67c8db927454 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -191,6 +191,14 @@ config PINCTRL_PALMAS
  open drain configuration for the Palmas series devices like
  TPS65913, TPS80036 etc.
 
+config PINCTRL_ZYNQ
+   bool "Pinctrl driver for Xilinx Zynq"
+   depends on ARCH_ZYNQ
+   select PINMUX
+   select GENERIC_PINCONF
+   help
+ This selectes the pinctrl driver for Xilinx Zynq.
+
 source "drivers/pinctrl/berlin/Kconfig"
 source "drivers/pinctrl/freescale/Kconfig"
 source "drivers/pinctrl/intel/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index c030b3db8034..886357556e87 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_PINCTRL_XWAY)+= pinctrl-xway.o
 obj-$(CONFIG_PINCTRL_LANTIQ)   += pinctrl-lantiq.o
 obj-$(CONFIG_PINCTRL_TB10X)+= pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST)   += pinctrl-st.o
+obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
 
 obj-$(CONFIG_ARCH_BERLIN)  += berlin/
 obj-y  += freescale/
diff --git a/drivers/pinctrl/pinctrl-zynq.c b/drivers/pinctrl/pinctrl-zynq.c
new file mode 100644
index ..29b75134771f
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-zynq.c
@@ -0,0 +1,1176 @@
+/*
+ * Zynq pin controller
+ *
+ *  Copyright (C) 2014 Xilinx
+ *
+ *  Sören Brinkmann 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * 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 
+#include 
+#include 
+#include "pinctrl-utils.h"
+#include "core.h"
+
+#define ZYNQ_NUM_MIOS  54
+
+#define ZYNQ_PCTRL_MIO_MST_TRI00x10c
+#define ZYNQ_PCTRL_MIO_MST_TRI10x110
+
+#define ZYNQ_PINMUX_MUX_SHIFT  1
+#define ZYNQ_PINMUX_MUX_MASK   (0x7f << ZYNQ_PINMUX_MUX_SHIFT)
+
+/**
+ * struct zynq_pinctrl - driver data
+ * @pctrl: Pinctrl device
+ * @syscon:Syscon regmap
+ * @pctrl_offset:  Offset for pinctrl into the @syscon space
+ * @groups:Pingroups
+ * @ngroupos:  Number of @groups
+ * @funcs: Pinmux functions
+ * @nfuncs:Number of @funcs
+ */
+struct zynq_pinctrl {
+   struct pinctrl_dev *pctrl;
+   struct regmap *syscon;
+   u32 pctrl_offset;
+   const struct zynq_pctrl_group *groups;
+   unsigned int ngroups;
+   const struct zynq_pinmux_function *funcs;
+   unsigned int nfuncs;
+};
+
+struct zynq_pctrl_group {
+   const char *name;
+   const unsigned int *pins;
+   const unsigned npins;
+};
+
+/**
+ * struct zynq_pinmux_function - a pinmux function
+ * @name:  Name of the pinmux function.
+ * @groups:List of pingroups for this function.
+ * @ngroups:   Number of entries in @groups.
+ * @mux_val:   Selector for this function
+ * @mux:   Offset of function specific mux
+ * @mux_mask: 

[ANNOUNCE] lsscsi version 0.28 released

[Douglas Gilbert]

lsscsi is a command line utility that probes sysfs in Linux
2.6 and 3 series kernels in order to list information about
SCSI devices and SCSI hosts. The default format is one device
(e.g. disk) per line. Other storage devices that use the SCSI
subsystem such as SATA and USB keys are also listed.

Version 0.28 is available at:
http://sg.danny.cz/scsi/lsscsi.html
More information can be found on that page including examples
plus a Download and Build information section containing
tarballs, rpm and deb packages.

ChangeLog:
Version 0.28 2014/09/30 [svn: r120]
  - fix handling of scsi_level 0 (no compliance)
  - add SRP transport identifier
  - add --unit option for LU identifier (>= lk 3.15)
  - add (S)ATA transport identifier (>= lk 3.15)
  - make USB transport ids more consistent
  - fix FC transport id missing comma
  - add pdt strings for security manager and zbc
  - upgrade automake to version 1.14.1

Version 0.27 2013/05/08 [svn: r111]
...


Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/7] ARM: zynq: Enable pinctrl

[Soren Brinkmann]

Select pinctrl and the Zynq pinctrl driver.

Signed-off-by: Soren Brinkmann 
Tested-by: Andreas Färber 
---
Changes since RFC v2:
 - separate mach-zynq changes in their own patch
---
 arch/arm/mach-zynq/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
index aaa5162c1509..78e5e007f52d 100644
--- a/arch/arm/mach-zynq/Kconfig
+++ b/arch/arm/mach-zynq/Kconfig
@@ -9,6 +9,8 @@ config ARCH_ZYNQ
select HAVE_ARM_TWD if SMP
select ICST
select MFD_SYSCON
+   select PINCTRL
+   select PINCTRL_ZYNQ
select SOC_BUS
help
  Support for Xilinx Zynq ARM Cortex A9 Platform
-- 
2.1.3.1.ge241007

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 6/7] ARM: zynq: DT: Add pinctrl information

[Soren Brinkmann]

Add pinctrl descriptions to the zc702 and zc706 device trees.

Signed-off-by: Soren Brinkmann 
Tested-by: Andreas Färber 
---
Changes since v1:
 - remove 'pinctrl-' prefix for pinctrl sub-nodes
 - separate config and mux nodes

Changes since RFC v2:
 - add pinconf properties to zc702 mdio node
 - remove arguments from bias-related props

Changes since RFC v1:
 - separate DT changes into their own patch
---
 arch/arm/boot/dts/zynq-7000.dtsi |   8 +-
 arch/arm/boot/dts/zynq-zc702.dts | 181 +++
 arch/arm/boot/dts/zynq-zc706.dts | 152 
 3 files changed, 340 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 24036c440440..37d7fe36a129 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -238,7 +238,7 @@
slcr: slcr@f800 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "xlnx,zynq-slcr", "syscon";
+   compatible = "xlnx,zynq-slcr", "syscon", "simple-bus";
reg = <0xF800 0x1000>;
ranges;
clkc: clkc@100 {
@@ -259,6 +259,12 @@
"dbg_trc", "dbg_apb";
reg = <0x100 0x100>;
};
+
+   pinctrl0: pinctrl@700 {
+   compatible = "xlnx,pinctrl-zynq";
+   reg = <0x700 0x200>;
+   syscon = <>;
+   };
};
 
dmac_s: dmac@f8003000 {
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index 94e2cda6f9b6..1e3d800e5b2e 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -40,21 +40,32 @@
 
  {
status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_can0_default>;
 };
 
  {
status = "okay";
phy-mode = "rgmii-id";
phy-handle = <_phy>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gem0_default>;
 
ethernet_phy: ethernet-phy@7 {
reg = <7>;
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio0_default>;
+};
+
  {
status = "okay";
clock-frequency = <40>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0_default>;
 
i2cswitch@74 {
compatible = "nxp,pca9548";
@@ -128,10 +139,180 @@
};
 };
 
+ {
+   pinctrl_can0_default: can0-default {
+   mux {
+   function = "can0";
+   groups = "can0_9_grp";
+   };
+
+   conf {
+   groups = "can0_9_grp";
+   slew-rate = <0>;
+   io-standard = <1>;
+   };
+
+   conf-rx {
+   pins = "MIO46";
+   bias-high-impedance;
+   };
+
+   conf-tx {
+   pins = "MIO47";
+   bias-disable;
+   };
+   };
+
+   pinctrl_gem0_default: gem0-default {
+   mux {
+   function = "ethernet0";
+   groups = "ethernet0_0_grp";
+   };
+
+   conf {
+   groups = "ethernet0_0_grp";
+   slew-rate = <0>;
+   io-standard = <4>;
+   };
+
+   conf-rx {
+   pins = "MIO22", "MIO23", "MIO24", "MIO25", "MIO26", 
"MIO27";
+   bias-high-impedance;
+   low-power-disable;
+   };
+
+   conf-tx {
+   pins = "MIO16", "MIO17", "MIO18", "MIO19", "MIO20", 
"MIO21";
+   bias-disable;
+   low-power-enable;
+   };
+
+   mux-mdio {
+   function = "mdio0";
+   groups = "mdio0_0_grp";
+   };
+
+   conf-mdio {
+   groups = "mdio0_0_grp";
+   slew-rate = <0>;
+   io-standard = <1>;
+   bias-disable;
+   };
+   };
+
+   pinctrl_gpio0_default: gpio0-default {
+   mux {
+   function = "gpio0";
+   groups = "gpio0_7_grp", "gpio0_8_grp", "gpio0_9_grp",
+"gpio0_10_grp", "gpio0_11_grp", "gpio0_12_grp",
+"gpio0_13_grp", "gpio0_14_grp";
+   };
+
+   conf {
+   groups = "gpio0_7_grp", "gpio0_8_grp", "gpio0_9_grp",
+"gpio0_10_grp", "gpio0_11_grp", "gpio0_12_grp",
+ 

[PATCH v2 2/7] pinctrl: pinconf-generic: Allow driver to specify DT params

[Soren Brinkmann]

Additionally to the generic DT parameters, allow drivers to provide
driver-specific DT parameters to be used with the generic parser
infrastructure.

To achieve this 'struct pinctrl_desc' is extended to pass custom pinconf
option to the core. In order to pass this kind of information, the
related data structures - 'struct pinconf_generic_dt_params',
'pin_config_item' - are moved from pinconf internals to the
pinconf-generic header.

Additionally pinconfg-generic is refactored to not only iterate over the
generic pinconf parameters but also take the parameters into account
that are provided through the driver's 'struct pinctrl_desc'.
In particular 'pinconf_generic_parse_dt_config()' and
'pinconf_generic_dump' helpers are split into two parts each. In order
to have a more generic helper that can be used to process the generic
parameters as well as the driver-specific ones.

Signed-off-by: Soren Brinkmann 
Tested-by: Andreas Färber 
---
v2:
 - fix typo
 - add missing documentation for @conf_items member in struct
 - rebase to pinctrl/devel: conflict in abx500
 - rename _pinconf_generic_dump() to pinconf_generic_dump_one()
 - removed '_' from _parse_dt_cfg()
 - removed BUG_ONs, error condition is handled in if statements
 - removed pinconf_generic_dump_group() & pinconf_generic_dump_pin
   helpers
   - fixed up corresponding call sites
   - renamed pinconf_generic_dump() to pinconf_generic_dump_pins()
   - added kernel-doc to pinconf_generic_dump_pins()
 - add kernel-doc
 - more verbose commit message
---
 drivers/pinctrl/nomadik/pinctrl-abx500.c |   2 +-
 drivers/pinctrl/pinconf-generic.c| 182 +--
 drivers/pinctrl/pinconf.c|   4 +-
 drivers/pinctrl/pinconf.h|  22 ++--
 drivers/pinctrl/pinctrl-rockchip.c   |   2 +-
 drivers/pinctrl/pinctrl-tz1090-pdc.c |   2 +-
 drivers/pinctrl/pinctrl-tz1090.c |   2 +-
 drivers/pinctrl/sh-pfc/pinctrl.c |   2 +-
 include/linux/pinctrl/pinconf-generic.h  |  18 +++
 include/linux/pinctrl/pinctrl.h  |   9 ++
 10 files changed, 141 insertions(+), 104 deletions(-)

diff --git a/drivers/pinctrl/nomadik/pinctrl-abx500.c 
b/drivers/pinctrl/nomadik/pinctrl-abx500.c
index e1087c75e4f4..de68c1f8477b 100644
--- a/drivers/pinctrl/nomadik/pinctrl-abx500.c
+++ b/drivers/pinctrl/nomadik/pinctrl-abx500.c
@@ -914,7 +914,7 @@ static int abx500_dt_subnode_to_map(struct pinctrl_dev 
*pctldev,
}
}
 
-   ret = pinconf_generic_parse_dt_config(np, , );
+   ret = pinconf_generic_parse_dt_config(np, pctldev, , );
if (nconfigs) {
const char *gpio_name;
const char *pin;
diff --git a/drivers/pinctrl/pinconf-generic.c 
b/drivers/pinctrl/pinconf-generic.c
index 1e782a0d6e48..ac1dcf1925ba 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -27,17 +27,6 @@
 #include "pinctrl-utils.h"
 
 #ifdef CONFIG_DEBUG_FS
-
-struct pin_config_item {
-   const enum pin_config_param param;
-   const char * const display;
-   const char * const format;
-   bool has_arg;
-};
-
-#define PCONFDUMP(a, b, c, d) { .param = a, .display = b, .format = c, \
-   .has_arg = d }
-
 static const struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_BIAS_DISABLE, "input bias disabled", NULL, false),
PCONFDUMP(PIN_CONFIG_BIAS_HIGH_IMPEDANCE, "input bias high impedance", 
NULL, false),
@@ -60,22 +49,25 @@ static const struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_OUTPUT, "pin output", "level", true),
 };
 
-void pinconf_generic_dump_pin(struct pinctrl_dev *pctldev,
- struct seq_file *s, unsigned pin)
+static void pinconf_generic_dump_one(struct pinctrl_dev *pctldev,
+struct seq_file *s, const char *gname,
+unsigned pin,
+const struct pin_config_item *items,
+int nitems)
 {
-   const struct pinconf_ops *ops = pctldev->desc->confops;
int i;
 
-   if (!ops->is_generic)
-   return;
-
-   for (i = 0; i < ARRAY_SIZE(conf_items); i++) {
+   for (i = 0; i < nitems; i++) {
unsigned long config;
int ret;
 
/* We want to check out this parameter */
-   config = pinconf_to_config_packed(conf_items[i].param, 0);
-   ret = pin_config_get_for_pin(pctldev, pin, );
+   config = pinconf_to_config_packed(items[i].param, 0);
+   if (gname)
+   ret = pin_config_group_get(dev_name(pctldev->dev),
+  gname, );
+   else
+   ret = pin_config_get_for_pin(pctldev, pin, );
/* These are legal errors */
if (ret == -EINVAL || ret == -ENOTSUPP)