Re: [PATCH 2/3] perf tools: Spare double comparison of callchain first entry

[Namhyung Kim]

Hi Arnaldo and Frederic,

On Thu, 16 Jan 2014 17:47:34 -0200, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 16, 2014 at 06:34:58PM +0100, Frederic Weisbecker escreveu:
>> On Thu, Jan 16, 2014 at 10:17:53AM +0900, Namhyung Kim wrote: 
>> > I think if the sort key doesn't contain "symbol", unmatch case would be
>> > increased as more various callchains would go into a same entry.
>> 
>> You mean -g fractal,0.5,callee,address ?
>> 
>> Hmm, actually I haven't seen much difference there.
>
> I guess he will, but will wait for Namhyung's final ack here, ok?

I meant sorting of hist entry like "-s cpu".   So as your number said
it's not an issue IMHO.  Arnaldo, I'm good with this change please merge
it. :)

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: davinci_nand: Remove unnecessary labels from error path

[Prabhakar Lad]

Hi Brain,

On Fri, Jan 17, 2014 at 10:46 AM, Prabhakar Lad
 wrote:
> Hi Brian,
>
> On Fri, Jan 17, 2014 at 3:02 AM, Brian Norris
>  wrote:
>> On Wed, Jan 15, 2014 at 01:38:26PM +0530, Prabhakar Lad wrote:
>>> From: "Lad, Prabhakar" 
>>>
>>> This patch removes the unnecessary labels from
>>> the error path in probe function which did nothing
>>> than just returning error values, Thus simplifying code
>>> path and improved readability.
>>>
>>> Signed-off-by: Lad, Prabhakar 
>>
>> This does not apply to my branch, since some OOM messages have been
>> dropped. Can you rebase on l2-mtd.git (or linux-next)?
>>
> OK I'll rebase it against linux-next and post a v2.
>
My Bad was too late, there is already a patch fixing the above issue
in linux-next
please ignore this patch.

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

Re: [PATCH] perf tools: Fix JIT profiling on heap

[Namhyung Kim]

Hi Gaurav,

On Thu, 16 Jan 2014 20:23:27 +, Gaurav Jain wrote:
> On 1/16/14, 9:37 AM, "Arnaldo Carvalho de Melo" 
> wrote:
>
>>Em Thu, Jan 16, 2014 at 10:49:31AM +0900, Namhyung Kim escreveu:
>>> Gaurav reported that perf cannot profile JIT program if it executes
>>> the code on heap.  This was because current map__new() only handle JIT
>>> on anon mappings - extends it to handle no_dso (heap, stack) case too.
>>> 
>>> This patch assumes JIT profiling only provides dynamic function
>>> symbols so check the mapping type to distinguish the case.  It'd
>>> provide no symbols for data mapping - if we need to support symbols on
>>> data mappings later it should be changed.
>>
>>But we do support symbols in data mappings, that is why we have
>>MAP__VARIABLE, etc, can you elaborate?
>
> Does perf support data mappings from perf map files? Could you please
> share an example of how I may be able to use this.

IIUC there's no difference between function and data mapping.  So you
can use same perf map file for both - in fact there's no way to use
different map file in a single task.  I guess perf will use it to find
only function symbols in function mappings and variables in data
mapping based on the address it accesses.

What I wasn't sure is whether JIT program also produces some dynamic data.
And I think only perf mem command cares about data mappings, no?

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI: Fix acpi_evaluate_object() return value check

[Jani Nikula]

On Fri, 17 Jan 2014, Yijing Wang  wrote:
> Fix acpi_evaluate_object() return value check,
> shoud acpi_status not int.

Please spellcheck.

>
> Signed-off-by: Yijing Wang 
> ---
> v2->v3: Fix compile error pointed out by Hanjun.
> v1->v2: Add CC to related subsystem MAINTAINERS
> ---
>  drivers/gpu/drm/i915/intel_acpi.c  |   24 
> ++--
>  drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |9 +
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |   23 +--
>  drivers/pci/pci-label.c|9 ++---
>  4 files changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index dfff090..87e8f74 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -35,7 +35,8 @@ static int intel_dsm(acpi_handle handle, int func)
>   union acpi_object params[4];
>   union acpi_object *obj;
>   u32 result;
> - int ret = 0;
> + acpi_status status;
> + int ret;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -50,10 +51,11 @@ static int intel_dsm(acpi_handle handle, int func)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", , );
> - if (ret) {
> - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> - return ret;
> + status = acpi_evaluate_object(handle, "_DSM", , );
> + if (ACPI_FAILURE(status)) {
> + DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
> + acpi_format_exception(status));
> + return -EINVAL;
>   }
>  
>   obj = (union acpi_object *)output.pointer;
> @@ -141,7 +143,8 @@ static void intel_dsm_platform_mux_info(void)
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *pkg;
> - int i, ret;
> + acpi_status status;
> + int i;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -156,10 +159,11 @@ static void intel_dsm_platform_mux_info(void)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", ,
> -);
> - if (ret) {
> - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> + acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle,
> + "_DSM", , );
> + if (ACPI_FAILURE(status)) {
> + DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
> + acpi_format_exception(status));
>   goto out;
>   }

In the two hunks above, one of the error paths calls
kfree(output.pointer), the other doesn't. Which one is wrong?

The fix for that should probably be a follow-up patch; this patch is

Reviewed-by: Jani Nikula 


>  
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> index 1291204..c5e7a2b 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> @@ -114,15 +114,16 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
>   struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
>   union acpi_object *obj;
>   acpi_handle handle;
> - int ret;
> + acpi_status status;
>  
>   handle = ACPI_HANDLE(>pdev->dev);
>   if (!handle)
>   return false;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", , );
> - if (ret) {
> - nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
> + status = acpi_evaluate_object(handle, "_DSM", , );
> + if (ACPI_FAILURE(status)) {
> + nv_debug(mxm, "DSM MXMS failed: %s\n",
> + acpi_format_exception(status));
>   return false;
>   }
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index ba0183f..de3068b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *obj;
> - int i, err;
> + acpi_status status;
> + int i;
>   char args_buff[4];
>  
>   input.count = 4;
> @@ -101,10 +102,11 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   args_buff[i] = (arg >> i * 8) & 0xFF;
>   params[3].buffer.pointer = args_buff;
>  
> - err = acpi_evaluate_object(handle, "_DSM", , );
> - if (err) {
> - printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
> - return err;
> + status = acpi_evaluate_object(handle, "_DSM", , );
> + if (ACPI_FAILURE(status)) {

Re: [PATCH v2 1/2] i2c: qup: Add device tree bindings information

[Ivan T. Ivanov]

Hi, 

On Thu, 2014-01-16 at 15:20 -0800, Bjorn Andersson wrote: 
> On Tue 14 Jan 00:57 PST 2014, Ivan T. Ivanov wrote:
> 
> > 
> > Thanks Bjorn, 
> > 
> > I have prepared second version, but never send it out :-).
> > One thing suggested by Mark was missed in this version.
> 
> Yeah, Mattew told me you we're assigned to other things and asked me to send
> out an update as I had gotten it to work on our boards.
> 
> I did modify the wording of most of these to match how it is written in the
> other Qualcomm definitions.
> 
> @Mark, would you rather have me change this to your suggested wording?
> 
> > 
> > 
> > On Mon, 2014-01-13 at 16:30 -0800, Bjorn Andersson wrote: 
> > > From: "Ivan T. Ivanov" 
> > > 
> [snip]
> > > + - clocks: Should contain the core clock and the AHB clock.
> > 
> > + - clocks: a list of phandle + clock-specifier pairs for each entry in
> > +   clock-names
> > 
> 
> This is in line with how it's written in other drivers, so if the DT
> maintainers doesn't disagree I would like to keep phandles out of the
> description. This specific line is a verbatime copy of the msm_serial
> documentation (same block, different mode)...
> 
> > > + - clock-names: Should be "core" for the core clock and "iface" for the
> > > +AHB clock.
> > > +
> > > + - #address-cells: Should be <1> Address cells for i2c device address
> > > + - #size-cells: Should be <0> as i2c addresses have no size component
> > > +
> > > +Optional properties:
> > > + - clock-frequency: Should specify the desired i2c bus clock frequency 
> > > in Hz,
> > > +default is 100kHz if omitted.
> > > +
> > > +Child nodes should conform to i2c bus binding.
> > > +
> > > +Example:
> > > +
> > > + i2c2: i2c@f9924000 {
> > > + compatible = "qcom,i2c-qup";
> > > + reg = <0xf9924000 0x1000>;
> > > + interrupts = <0 96 0>;
> > > +
> > > + clocks = <_blsp1_qup2_i2c_apps_clk>, <_blsp1_ahb_clk>;
> > 
> > In the light of the latest patches from Stephen, this could be 
> > 
> > +   clocks = < GCC_BLSP1_QUP2_I2C_APPS_CLK>, < GCC_BLSP1_AHB_CLK>;
> 
> Yes, that's exactly what I have in my dts. However as this is just an example
> I didn't feel it was worth tainting the documentation with all those capital
> letters ;)
> So unless DT maintainers disagree I would like to just keep it as an example.

Until, we get some meaningful board DTS files for Qualcomm platforms, it
is easy for people which will like to test or use drivers to just copy
and paste these definitions.

Regards,
Ivan

> 
> Regards,
> Bjorn
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

Re: [PATCH 3/4] fix module autoloading for ACPI enumerated devices

[Jarkko Nikula]

On 01/16/2014 09:46 PM, Mark Brown wrote:

On Thu, Jan 16, 2014 at 09:05:09PM +0800, Zhang Rui wrote:

On Thu, 2014-01-16 at 13:27 +0100, Wolfram Sang wrote:
This seems a gap to me but I'm not 100% sure.
I saw Grant Likely introduced the OF style MODALIAS to platform bus, and
OF style registration/binding to i2c bus, maybe he has an answer for
this.

This is needed for ACPI because we rewrite the device names to give us
stable names.  With OF for I2C and SPI nothing bus specific is done that
affects this stuff so the default behaviour works.
Sidenote: actually this modalias/module loading issue is different and 
not related to stable ACPI i2c/spi slave device names.


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

Kconfig errors

[Prabhakar Lad]

Hi,

On Linux-next branch I see following errors for davinci_all_defconfig
& da8xx_omapl_defconfig configs,

arch/arm/Kconfig:1966:error: recursive dependency detected!
arch/arm/Kconfig:1966:symbol ZBOOT_ROM depends on AUTO_ZRELADDR
arch/arm/Kconfig:2154:symbol AUTO_ZRELADDR is selected by ZBOOT_ROM
#
# configuration written to .config
#

Regards,
--Prabhakar Lad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/1] Drivers: hv: Implement the file copy service

[Dan Carpenter]

On Thu, Jan 16, 2014 at 10:42:01AM +0100, Olaf Hering wrote:
> On Tue, Jan 14, K. Y. Srinivasan wrote:
> 
> > +enum hv_fcopy_op {
> > +   START_FILE_COPY = 0,
> > +   WRITE_TO_FILE,
> > +   COMPLETE_FCOPY,
> > +   CANCEL_FCOPY,
> > +};
> > +
> > +struct hv_fcopy_hdr {
> > +   enum hv_fcopy_op operation;
> > +   uuid_le service_id0; /* currently unused */
> > +   uuid_le service_id1; /* currently unused */
> > +} __attribute__((packed));
> 
> Is enum a fixed size?

No, it's not.  The compiler has a lot of latitude in choosing the size
for enums.

regards,
dan carpenter

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

[PATCH] f2fs: avoid f2fs_balance_fs call during pageout

[Jaegeuk Kim]

This patch should resolve the following bug.

=
[ INFO: possible irq lock inversion dependency detected ]
3.13.0-rc5.f2fs+ #6 Not tainted
-
kswapd0/41 just changed the state of lock:
 (>gc_mutex){+.+.-.}, at: [] f2fs_balance_fs+0xae/0xd0 
[f2fs]
but this lock took another, RECLAIM_FS-READ-unsafe lock in the past:
 (>cp_rwsem){.?}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
Chain exists of:
  >gc_mutex --> >cp_mutex --> >cp_rwsem

 Possible interrupt unsafe locking scenario:

   CPU0CPU1
   
  lock(>cp_rwsem);
   local_irq_disable();
   lock(>gc_mutex);
   lock(>cp_mutex);
  
lock(>gc_mutex);

 *** DEADLOCK ***

This bug is due to the f2fs_balance_fs call in f2fs_write_data_page.
If f2fs_write_data_page is triggered by wbc->for_reclaim via kswapd, it should
not call f2fs_balance_fs which tries to get a mutex grabbed by original syscall
flow.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 19ad066..e57bde0 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -842,8 +842,10 @@ write:
else if (err)
goto redirty_out;
 
-   if (wbc->for_reclaim)
+   if (wbc->for_reclaim) {
f2fs_submit_merged_bio(sbi, DATA, WRITE);
+   need_balance_fs = false;
+   }
 
clear_cold_data(page);
 out:
-- 
1.8.4.474.g128a96c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv3 0/8] zram stats rework and code cleanup

[Minchan Kim]

On Thu, Jan 16, 2014 at 04:12:08PM +0300, Sergey Senozhatsky wrote:
> This patchset includes zram stats clean up and enhancements.
> 
> Sergey Senozhatsky (8):
>   zram: drop `init_done' struct zram member
>   zram: do not pass rw argument to __zram_make_request()
>   zram: remove good and bad compress stats
>   zram: use atomic64_t for all zram stats
>   zram: remove zram stats code duplication
>   zram: report failed read and write stats
>   zram: drop not used table `count' member
>   zram: move zram size warning to documentation
> 
>  Documentation/blockdev/zram.txt |   5 ++
>  drivers/block/zram/zram_drv.c   | 175 
> +---
>  drivers/block/zram/zram_drv.h   |  10 +--
>  3 files changed, 64 insertions(+), 126 deletions(-)

Great clean up.

Sergey, Thanks!
I am looking forward to your next step!

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

Re: [PATCHv3 8/8] zram: move zram size warning to documentation

[Minchan Kim]

On Thu, Jan 16, 2014 at 04:12:16PM +0300, Sergey Senozhatsky wrote:
> Move zram warning about disksize and size of memory correlation
> to zram documentation.
> 
> Signed-off-by: Sergey Senozhatsky 
Acked-by: Minchan Kim 

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

[PATCHv10 1/2] ARM: dts: vf610: Add eDMA node

[Jingchang Lu]

Signed-off-by: Jingchang Lu 
Acked-by: Arnd Bergmann 
---
no changes in v10.

changes in v9:
 remove include/dt-bindings/dma/vf610-edma.h, the request source ID
 is the same as SoC's reference manual.

changes in v8:
 describe dmamux info in edma node to avoid confusion.
 change eDMA requst source macro definitions.

 changes in v7:
 fix dmamux2 and dmamux3 register number.

 no changes in v2 ~ v6.

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

diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 48dbfe5..8febb29f 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -88,6 +88,21 @@
arm,tag-latency = <2 2 2>;
};
 
+   edma0: dma-controller@40018000 {
+   #dma-cells = <2>;
+   compatible = "fsl,vf610-edma";
+   reg = <0x40018000 0x2000>,
+   <0x40024000 0x1000>,
+   <0x40025000 0x1000>;
+   interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
+   <0 9 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "edma-tx", "edma-err";
+   dma-channels = <32>;
+   clock-names = "dmamux0", "dmamux1";
+   clocks = < VF610_CLK_DMAMUX0>,
+   < VF610_CLK_DMAMUX1>;
+   };
+
uart0: serial@40027000 {
compatible = "fsl,vf610-lpuart";
reg = <0x40027000 0x1000>;
@@ -263,6 +278,21 @@
reg = <0x4008 0x8>;
ranges;
 
+   edma1: dma-controller@40098000 {
+   #dma-cells = <2>;
+   compatible = "fsl,vf610-edma";
+   reg = <0x40098000 0x2000>,
+   <0x400a1000 0x1000>,
+   <0x400a2000 0x1000>;
+   interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>,
+   <0 11 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "edma-tx", "edma-err";
+   dma-channels = <32>;
+   clock-names = "dmamux0", "dmamux1";
+   clocks = < VF610_CLK_DMAMUX2>,
+   < VF610_CLK_DMAMUX3>;
+   };
+
uart4: serial@400a9000 {
compatible = "fsl,vf610-lpuart";
reg = <0x400a9000 0x1000>;
-- 
1.8.0


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

[PATCHv10 2/2] dma: Add Freescale eDMA engine driver support

[Jingchang Lu]

Add Freescale enhanced direct memory(eDMA) controller support.
This module can be found on Vybrid and LS-1 SoCs.

Signed-off-by: Alison Wang 
Signed-off-by: Jingchang Lu 
Acked-by: Arnd Bergmann 
---
changes in v10:
 define fsl_edma_mutex in fsl_edma_engine instead of global.
 minor changes of binding description.

changes in v9:
 define endian's operating functions instead of macro definition.
 remove the filter function, using dma_get_slave_channel instead.

changes in v8:
 change the edma driver according eDMA dts change.
 add big-endian and little-endian handling.

 no changes in v4 ~ v7.

 changes in v3:
  add vf610 edma dt-bindings namespace with prefix VF610_*.

 changes in v2:
  using generic dma-channels property instead of fsl,dma-channels.

 Documentation/devicetree/bindings/dma/fsl-edma.txt |  76 ++
 drivers/dma/Kconfig|  10 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/fsl-edma.c | 956 +
 4 files changed, 1043 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/fsl-edma.txt
 create mode 100644 drivers/dma/fsl-edma.c

diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt 
b/Documentation/devicetree/bindings/dma/fsl-edma.txt
new file mode 100644
index 000..191d7bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt
@@ -0,0 +1,76 @@
+* Freescale enhanced Direct Memory Access(eDMA) Controller
+
+  The eDMA channels have multiplex capability by programmble memory-mapped
+registers. channels are split into two groups, called DMAMUX0 and DMAMUX1,
+specific DMA request source can only be multiplexed by any channel of certain
+group, DMAMUX0 or DMAMUX1, but not both.
+
+* eDMA Controller
+Required properties:
+- compatible :
+   - "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC
+- reg : Specifies base physical address(s) and size of the eDMA registers.
+   The 1st region is eDMA control register's address and size.
+   The 2nd and the 3rd regions are programmable channel multiplexing
+   control register's address and size.
+- interrupts : A list of interrupt-specifiers, one for each entry in
+   interrupt-names.
+- interrupt-names : Should contain:
+   "edma-tx" - the transmission interrupt
+   "edma-err" - the error interrupt
+- #dma-cells : Must be <2>.
+   The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1).
+   Specific request source can only be multiplexed by specific channels
+   group called DMAMUX.
+   The 2nd cell specifies the request source(slot) ID.
+   See the SoC's reference manual for all the supported request sources.
+- dma-channels : Number of channels supported by the controller
+- clock-names : A list of channel group clock names. Should contain:
+   "dmamux0" - clock name of mux0 group
+   "dmamux1" - clock name of mux1 group
+- clocks : A list of phandle and clock-specifier pairs, one for each entry in
+   clock-names.
+
+Optional properties:
+- big-endian: If present registers and hardware scatter/gather descriptors
+   of the eDMA are implemented in big endian mode, otherwise in little
+   mode.
+
+
+Examples:
+
+edma0: dma-controller@40018000 {
+   #dma-cells = <2>;
+   compatible = "fsl,vf610-edma";
+   reg = <0x40018000 0x2000>,
+   <0x40024000 0x1000>,
+   <0x40025000 0x1000>;
+   interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
+   <0 9 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-names = "edma-tx", "edma-err";
+   dma-channels = <32>;
+   clock-names = "dmamux0", "dmamux1";
+   clocks = < VF610_CLK_DMAMUX0>,
+   < VF610_CLK_DMAMUX1>;
+};
+
+
+* DMA clients
+DMA client drivers that uses the DMA function must use the format described
+in the dma.txt file, using a two-cell specifier for each channel: the 1st
+specifies the channel group(DMAMUX) in which this request can be multiplexed,
+and the 2nd specifies the request source.
+
+Examples:
+
+sai2: sai@40031000 {
+   compatible = "fsl,vf610-sai";
+   reg = <0x40031000 0x1000>;
+   interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
+   clock-names = "sai";
+   clocks = < VF610_CLK_SAI2>;
+   dma-names = "tx", "rx";
+   dmas = < 0 21>,
+   < 0 20>;
+   status = "disabled";
+};
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9ae6f54..3d8a522 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -342,6 +342,16 @@ config K3_DMA
  Support the DMA engine for Hisilicon K3 platform
  devices.
 
+config FSL_EDMA
+   tristate "Freescale eDMA engine support"
+   depends on OF
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Support the Freescale eDMA engine with programmable channel
+ multiplexing capability for DMA request sources(slot).
+ This module can be found on Freescale Vybrid 

[PATCHv10 0/2] dma: Add Freescale eDMA engine driver support

[Jingchang Lu]

This series add Freescale eDMA engine support.

Jingchang Lu (2):
ARM: dts: vf610: Add eDMA node
dma: Add Freescale eDMA engine driver support

 Documentation/devicetree/bindings/dma/fsl-edma.txt |  76 
 arch/arm/boot/dts/vf610.dtsi   |  30 ++
 drivers/dma/Kconfig|  10 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/fsl-edma.c | 956 
+
 5 files changed, 1073 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/fsl-edma.txt
 create mode 100644 drivers/dma/fsl-edma.c


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

Re: [PATCHv3 7/8] zram: drop not used table `count' member

[Minchan Kim]

On Thu, Jan 16, 2014 at 04:12:15PM +0300, Sergey Senozhatsky wrote:
> struct table `count' member is not used.
> 
> Signed-off-by: Sergey Senozhatsky 

There is no gain with this patch in memory space ponit of view but it
might reveal the lurking bug.

Acked-by: Minchan Kim 

> ---
>  drivers/block/zram/zram_drv.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
> index 58d4ac5..1d5b1f5 100644
> --- a/drivers/block/zram/zram_drv.h
> +++ b/drivers/block/zram/zram_drv.h
> @@ -64,7 +64,6 @@ enum zram_pageflags {
>  struct table {
>   unsigned long handle;
>   u16 size;   /* object size (excluding header) */
> - u8 count;   /* object ref count (not yet used) */
>   u8 flags;
>  } __aligned(4);
>  
> -- 
> 1.8.5.3.493.gb139ac2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: [PATCHv3 5/8] zram: remove zram stats code duplication

[Minchan Kim]

On Thu, Jan 16, 2014 at 04:12:13PM +0300, Sergey Senozhatsky wrote:
> Introduce ZRAM_ATTR_RO macro that generates device_attribute
> and default ATTR show() function for existing atomic64_t zram
> stats.
> 
> Signed-off-by: Sergey Senozhatsky 
Acked-by: Minchan Kim 

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

Re: [PATCHv3 4/8] zram: use atomic64_t for all zram stats

[Minchan Kim]

On Thu, Jan 16, 2014 at 04:12:12PM +0300, Sergey Senozhatsky wrote:
> This is a preparation patch for stats code duplication removal.
> 
> 1) use atomic64_t for `pages_zero' and `pages_stored' zram stats.
> 2) `compr_size' and `pages_zero' struct zram_stats members did not
> follow the existing device attr naming scheme: zram_stats.ATTR has
> ATTR_show() function. rename them:
> -- compr_size -> compr_data_size
> -- pages_zero -> zero_pages
> 
> Minchan Kim's note:
>  If we really have trouble with atomic stat operation, we could
>  change it with percpu_counter so that it could solve atomic overhead and
>  unnecessary memory space by introducing unsigned long instead of 64bit
>  atomic_t.
> 
> Signed-off-by: Sergey Senozhatsky 
Acked-by: Minchan Kim 

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

[PATCH RFC 1/6] net: rfkill: gpio: fix gpio name buffer size off by 1

[Chen-Yu Tsai]

snprintf should be passed the complete size of the buffer, including
the space for '\0'. The previous code resulted in the *_reset and
*_shutdown strings being truncated.

Signed-off-by: Chen-Yu Tsai 
---
 net/rfkill/rfkill-gpio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index bd2a5b9..97ec12a 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -117,8 +117,8 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
if (!rfkill->shutdown_name)
return -ENOMEM;
 
-   snprintf(rfkill->reset_name, len + 6 , "%s_reset", rfkill->name);
-   snprintf(rfkill->shutdown_name, len + 9, "%s_shutdown", rfkill->name);
+   snprintf(rfkill->reset_name, len + 7 , "%s_reset", rfkill->name);
+   snprintf(rfkill->shutdown_name, len + 10, "%s_shutdown", rfkill->name);
 
rfkill->clk = devm_clk_get(>dev, clk_name);
 
-- 
1.8.5.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/

[PATCH RFC 2/6] net: rfkill: gpio: use clk_prepare_enable/clk_disable_unprepare

[Chen-Yu Tsai]

rfkill-gpio calls clk_enable() without first calling clk_prepare(),
resulting in a warning and no effect. Switch to clk_prepare_enable()
and clk_disable_unprepare.

Signed-off-by: Chen-Yu Tsai 
---
 net/rfkill/rfkill-gpio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 97ec12a..c7081b7 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -51,10 +51,10 @@ static int rfkill_gpio_set_power(void *data, bool blocked)
gpiod_set_value(rfkill->shutdown_gpio, 0);
gpiod_set_value(rfkill->reset_gpio, 0);
if (!IS_ERR(rfkill->clk) && rfkill->clk_enabled)
-   clk_disable(rfkill->clk);
+   clk_disable_unprepare(rfkill->clk);
} else {
if (!IS_ERR(rfkill->clk) && !rfkill->clk_enabled)
-   clk_enable(rfkill->clk);
+   clk_prepare_enable(rfkill->clk);
gpiod_set_value(rfkill->reset_gpio, 1);
gpiod_set_value(rfkill->shutdown_gpio, 1);
}
-- 
1.8.5.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: [PATCHv3 3/8] zram: remove good and bad compress stats

[Minchan Kim]

On Thu, Jan 16, 2014 at 04:12:11PM +0300, Sergey Senozhatsky wrote:
> Remove `good' and `bad' compressed sub-requests stats. RW request may
> cause a number of RW sub-requests. zram used to account `good' compressed
> sub-queries (with compressed size less than 50% of original size), `bad'
> compressed sub-queries (with compressed size greater that 75% of original
> size), leaving sub-requests with compression size between 50% and 75% of
> original size not accounted and not reported. zram already accounts each
> sub-request's compression size so we can calculate real device compression
> ratio.
> 

Most important thing is that we have accounted them but have not used
so it doesn't break anything and we could add them again if someone need them
later. :)

> Signed-off-by: Sergey Senozhatsky 

Acked-by: Minchan Kim 

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

[PATCH RFC 3/6] net: rfkill: gpio: fix reversed clock enable state

[Chen-Yu Tsai]

rfkill-gpio has clk_enabled = blocked, which is true when rfkill
blocks the device. This results in calling clock enable/disable at
the wrong time. Reversing the value fixes this.

Signed-off-by: Chen-Yu Tsai 
---
 net/rfkill/rfkill-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index c7081b7..3084fa3 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -59,7 +59,7 @@ static int rfkill_gpio_set_power(void *data, bool blocked)
gpiod_set_value(rfkill->shutdown_gpio, 1);
}
 
-   rfkill->clk_enabled = blocked;
+   rfkill->clk_enabled = !blocked;
 
return 0;
 }
-- 
1.8.5.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/

[PATCH RFC 4/6] net: rfkill: gpio: add device tree support

[Chen-Yu Tsai]

Signed-off-by: Chen-Yu Tsai 
---
 .../devicetree/bindings/rfkill/rfkill-gpio.txt | 26 ++
 net/rfkill/rfkill-gpio.c   | 23 +++
 2 files changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt

diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt 
b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
new file mode 100644
index 000..8a07ea4
--- /dev/null
+++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
@@ -0,0 +1,26 @@
+GPIO controlled RFKILL devices
+
+Required properties:
+- compatible   : Must be "rfkill-gpio".
+- rfkill-name  : Name of RFKILL device
+- rfkill-type  : Type of RFKILL device: 1 for WiFi, 2 for BlueTooth
+- NAME_shutdown-gpios  : GPIO phandle to shutdown control
+ (phandle must be the second)
+- NAME_reset-gpios : GPIO phandle to reset control
+
+NAME must match the rfkill-name property. NAME_shutdown-gpios or
+NAME_reset-gpios, or both, must be defined.
+
+Optional properties:
+- clocks   : phandle to clock to enable/disable
+
+Example:
+
+   rfkill_bt: rfkill@0 {
+   compatible = "rfkill-gpio";
+   rfkill-name = "bluetooth";
+   rfkill-type = <2>;
+   bluetooth_shutdown-gpios = <0>, < 7 18 0>;
+   bluetooth_reset-gpios = < 7 24 0>;
+   clocks = <_out_a>;
+   };
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 3084fa3..48381a8 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -83,6 +84,18 @@ static int rfkill_gpio_acpi_probe(struct device *dev,
return 0;
 }
 
+static int rfkill_gpio_dt_probe(struct device *dev,
+   struct rfkill_gpio_data *rfkill)
+{
+   struct device_node * np = dev->of_node;
+
+   rfkill->name = np->name;
+   of_property_read_string(np, "rfkill-name", >name);
+   of_property_read_u32(np, "rfkill-type", >type);
+
+   return 0;
+}
+
 static int rfkill_gpio_probe(struct platform_device *pdev)
 {
struct rfkill_gpio_platform_data *pdata = pdev->dev.platform_data;
@@ -100,6 +113,10 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
ret = rfkill_gpio_acpi_probe(>dev, rfkill);
if (ret)
return ret;
+   } else if (>dev.of_node) {
+   ret = rfkill_gpio_dt_probe(>dev, rfkill);
+   if (ret)
+   return ret;
} else if (pdata) {
clk_name = pdata->power_clk_name;
rfkill->name = pdata->name;
@@ -189,6 +206,11 @@ static const struct acpi_device_id rfkill_acpi_match[] = {
{ },
 };
 
+static const struct of_device_id rfkill_of_match[] = {
+   { .compatible = "rfkill-gpio", },
+   {},
+};
+
 static struct platform_driver rfkill_gpio_driver = {
.probe = rfkill_gpio_probe,
.remove = rfkill_gpio_remove,
@@ -196,6 +218,7 @@ static struct platform_driver rfkill_gpio_driver = {
.name = "rfkill_gpio",
.owner = THIS_MODULE,
.acpi_match_table = ACPI_PTR(rfkill_acpi_match),
+   .of_match_table = of_match_ptr(rfkill_of_match),
},
 };
 
-- 
1.8.5.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/

[PATCH RFC 6/6] ARM: sun7i: cubietruck: enable bluetooth module

[Chen-Yu Tsai]

The CubieTruck has an AMPAK AP6210 WiFi+Bluetooth module. The
Bluetooth part is a BCM20710 device connected to UART2 in the
A20 SoC.

The IC also requires a 32.768 KHz low power clock input for
proper auto-detection of the main clock, and power enable and
wake signals via GPIO.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts 
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index c8b3ea9..f172a8f 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -78,6 +78,20 @@
allwinner,drive = <0>;
allwinner,pull = <2>;
};
+
+   bt_pwr_pin: bt_pwr_pin@0 {
+   allwinner,pins = "PH18";
+   allwinner,function = "gpio_out";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   bt_wake_pin: bt_wake_pin@0 {
+   allwinner,pins = "PH24";
+   allwinner,function = "gpio_out";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
};
 
uart0: serial@01c28000 {
@@ -86,6 +100,12 @@
status = "okay";
};
 
+   uart2: serial@01c28800 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+
gmac: ethernet@01c5 {
pinctrl-names = "default";
pinctrl-0 = <_pins_rgmii>;
@@ -157,4 +177,21 @@
gpio = < 7 3 0>;
};
};
+
+   rfkill-switches {
+   compatible = "simple-bus";
+   pinctrl-names = "default";
+
+   rfkill_bt {
+   compatible = "rfkill-gpio";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwr_pin>, <_out_a_pins>;
+   rfkill-name = "bt";
+   rfkill-type = <2>;
+   bt_shutdown-gpios = <0>, < 7 18 0>; /* PH18 */
+   bt_reset-gpios = < 7 24 0>; /* PH24 */
+   clocks = <_out_a>;
+   clock-frequency = <32768>;
+   };
+   };
 };
-- 
1.8.5.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/

[PATCH RFC 0/6] net: rfkill: gpio: Add device tree support

[Chen-Yu Tsai]

Hi everyone,

This patch series adds device tree support to rfkill-gpio, and
fixes some issues I ran into. This is so we can define and control
RF devices through the device tree, such as the Broadcom BCM20710
UART-based Bluetooth device found on the CubieTruck,

The CubieTruck uses a non-default clock rate oscillator for the
BCM20710 device. As the datasheet states, a precise 32.768 KHz
low power clock must be provided at power on for the device to
detect the correct clock rate of the main oscillator. Hence the
need for the "clock-frequency" property.

The device tree bindings aren't pretty. They are the result of how
gpiod_find was implemented: of_gpiod_find includes con_id in the
DT property name; acpi_gpiod_find ignores it and only uses the index.
A more elegant DT binding would mean splitting the gpio lookup code
path in rfkill-gpio, which would be more like rfkill-gpio prior to
the descriptor-based GPIO patch.

I am aware there is a need for similar functionality for SDIO devices,
which the CubieTruck has as well. A mail thread [1] started yesterday
indicated that generic SDIO DT support was the way to go. I don't know
if that could be applied to UART-based devices though.

[1] http://www.spinics.net/lists/arm-kernel/msg301182.html

The series depends on

[PATCH v3 2/6] net: rfkill: gpio: convert to descriptor-based GPIO interface

which has been applied through the GPIO tree.

The last patch depends on

ARM: dts: sun7i: add pin muxing options for UART2

which I sent earlier this week.


Comments, please?


Cheers,
ChenYu


Chen-Yu Tsai (6):
  net: rfkill: gpio: fix gpio name buffer size off by 1
  net: rfkill: gpio: use clk_prepare_enable/clk_disable_unprepare
  net: rfkill: gpio: fix reversed clock enable state
  net: rfkill: gpio: add device tree support
  net: rfkill: gpio: add clock-frequency device tree property
  ARM: sun7i: cubietruck: enable bluetooth module

 .../devicetree/bindings/rfkill/rfkill-gpio.txt | 28 
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 37 ++
 net/rfkill/rfkill-gpio.c   | 37 +++---
 3 files changed, 97 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt

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

[PATCH RFC 5/6] net: rfkill: gpio: add clock-frequency device tree property

[Chen-Yu Tsai]

Some devices, such as Broadcom Bluetooth devices, require a specific
clock rate for the clock tied to the rfkill device. Add clock-frequency
property so we can specify this from the device tree.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt | 2 ++
 net/rfkill/rfkill-gpio.c | 4 
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt 
b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
index 8a07ea4..8b8db0a 100644
--- a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
+++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
@@ -13,6 +13,7 @@ NAME_reset-gpios, or both, must be defined.
 
 Optional properties:
 - clocks   : phandle to clock to enable/disable
+- clock-frequency  : clock rate to set for the given clock
 
 Example:
 
@@ -23,4 +24,5 @@ Example:
bluetooth_shutdown-gpios = <0>, < 7 18 0>;
bluetooth_reset-gpios = < 7 24 0>;
clocks = <_out_a>;
+   clock-frequency = <32678>;
};
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 48381a8..3092681 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -40,6 +40,7 @@ struct rfkill_gpio_data {
char*reset_name;
char*shutdown_name;
struct clk  *clk;
+   int clk_frequency;
 
boolclk_enabled;
 };
@@ -92,6 +93,7 @@ static int rfkill_gpio_dt_probe(struct device *dev,
rfkill->name = np->name;
of_property_read_string(np, "rfkill-name", >name);
of_property_read_u32(np, "rfkill-type", >type);
+   of_property_read_u32(np, "clock-frequency", >clk_frequency);
 
return 0;
 }
@@ -138,6 +140,8 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
snprintf(rfkill->shutdown_name, len + 10, "%s_shutdown", rfkill->name);
 
rfkill->clk = devm_clk_get(>dev, clk_name);
+   if (!IS_ERR(rfkill->clk) && rfkill->clk_frequency > 0)
+   clk_set_rate(rfkill->clk, rfkill->clk_frequency);
 
gpio = devm_gpiod_get_index(>dev, rfkill->reset_name, 0);
if (!IS_ERR(gpio)) {
-- 
1.8.5.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/

[GIT PULL] namespace fixes

[Eric W. Biederman]

Linus,

Please pull the for-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
for-linus

   HEAD: 41301ae78a99ead04ea42672a1ab72c6f44cc81d vfs: Fix a regression in 
mounting proc

This is a set of 3 regression fixes. 

This fixes /proc/mounts when using "ip netns add " to display the
actual mount point.

This fixes a regression in clone that broke lxc-attach.

This fixes a regression in the permission checks for mounting /proc that
made proc unmountable if binfmt_misc was in use. Oops.

My apologies for sending this pull request so late.  Al Viro gave
interesting review comments about the d_path fix that I wanted to
address in detail before I sent this pull request.  Unfortunately a
bad round of colds kept from addressing that in detail until today.
The executive summary of the review was:

Al: Is patching d_path really sufficient?
The prepend_path, d_path, d_absolute_path, and __d_path family of
functions is a really mess.

Me: Yes, patching d_path is really sufficient.  Yes, the code is mess.
No it is not appropriate to rewrite all of d_path for a regression
that has existed for entirely too long already, when a two line
change will do.

Eric W. Biederman (3):
  vfs: In d_path don't call d_dname on a mount point
  fork:  Allow CLONE_PARENT after setns(CLONE_NEWPID)
  vfs: Fix a regression in mounting proc

 fs/dcache.c|7 ++-
 fs/namespace.c |2 +-
 kernel/fork.c  |2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)


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

[PATCH 1/6] numa,sched,mm: remove p->numa_migrate_deferred

[riel]

From: Rik van Riel 

Excessive migration of pages can hurt the performance of workloads
that span multiple NUMA nodes.  However, it turns out that the
p->numa_migrate_deferred knob is a really big hammer, which does
reduce migration rates, but does not actually help performance.

Now that the second stage of the automatic numa balancing code
has stabilized, it is time to replace the simplistic migration
deferral code with something smarter.

Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Ingo Molnar 
Cc: Chegu Vinod 
Signed-off-by: Rik van Riel 
Signed-off-by: Rik van Riel 
---
 include/linux/sched.h |  1 -
 kernel/sched/fair.c   |  8 
 kernel/sysctl.c   |  7 ---
 mm/mempolicy.c| 45 -
 4 files changed, 61 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 68a0e84..97efba4 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1469,7 +1469,6 @@ struct task_struct {
unsigned int numa_scan_period;
unsigned int numa_scan_period_max;
int numa_preferred_nid;
-   int numa_migrate_deferred;
unsigned long numa_migrate_retry;
u64 node_stamp; /* migration stamp  */
struct callback_head numa_work;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 867b0a4..41e2176 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -819,14 +819,6 @@ unsigned int sysctl_numa_balancing_scan_size = 256;
 /* Scan @scan_size MB every @scan_period after an initial @scan_delay in ms */
 unsigned int sysctl_numa_balancing_scan_delay = 1000;
 
-/*
- * After skipping a page migration on a shared page, skip N more numa page
- * migrations unconditionally. This reduces the number of NUMA migrations
- * in shared memory workloads, and has the effect of pulling tasks towards
- * where their memory lives, over pulling the memory towards the task.
- */
-unsigned int sysctl_numa_balancing_migrate_deferred = 16;
-
 static unsigned int task_nr_scan_windows(struct task_struct *p)
 {
unsigned long rss = 0;
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 096db74..4d19492 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -384,13 +384,6 @@ static struct ctl_table kern_table[] = {
.proc_handler   = proc_dointvec,
},
{
-   .procname   = "numa_balancing_migrate_deferred",
-   .data   = _numa_balancing_migrate_deferred,
-   .maxlen = sizeof(unsigned int),
-   .mode   = 0644,
-   .proc_handler   = proc_dointvec,
-   },
-   {
.procname   = "numa_balancing",
.data   = NULL, /* filled in by handler */
.maxlen = sizeof(unsigned int),
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 36cb46c..052abac 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2301,35 +2301,6 @@ static void sp_free(struct sp_node *n)
kmem_cache_free(sn_cache, n);
 }
 
-#ifdef CONFIG_NUMA_BALANCING
-static bool numa_migrate_deferred(struct task_struct *p, int last_cpupid)
-{
-   /* Never defer a private fault */
-   if (cpupid_match_pid(p, last_cpupid))
-   return false;
-
-   if (p->numa_migrate_deferred) {
-   p->numa_migrate_deferred--;
-   return true;
-   }
-   return false;
-}
-
-static inline void defer_numa_migrate(struct task_struct *p)
-{
-   p->numa_migrate_deferred = sysctl_numa_balancing_migrate_deferred;
-}
-#else
-static inline bool numa_migrate_deferred(struct task_struct *p, int 
last_cpupid)
-{
-   return false;
-}
-
-static inline void defer_numa_migrate(struct task_struct *p)
-{
-}
-#endif /* CONFIG_NUMA_BALANCING */
-
 /**
  * mpol_misplaced - check whether current page node is valid in policy
  *
@@ -2432,24 +2403,8 @@ int mpol_misplaced(struct page *page, struct 
vm_area_struct *vma, unsigned long
 */
last_cpupid = page_cpupid_xchg_last(page, this_cpupid);
if (!cpupid_pid_unset(last_cpupid) && 
cpupid_to_nid(last_cpupid) != thisnid) {
-
-   /* See sysctl_numa_balancing_migrate_deferred comment */
-   if (!cpupid_match_pid(current, last_cpupid))
-   defer_numa_migrate(current);
-
goto out;
}
-
-   /*
-* The quadratic filter above reduces extraneous migration
-* of shared pages somewhat. This code reduces it even more,
-* reducing the overhead of page migrations of shared pages.
-* This makes workloads with shared pages rely more on
-* "move task near its memory", and less on "move memory
-* towards its task", which is exactly what we want.
-*/
-   if (numa_migrate_deferred(current, last_cpupid))
-   

[PATCH 2/6] numa,sched: track from which nodes NUMA faults are triggered

[riel]

From: Rik van Riel 

Track which nodes NUMA faults are triggered from, in other words
the CPUs on which the NUMA faults happened. This uses a similar
mechanism to what is used to track the memory involved in numa faults.

The next patches use this to build up a bitmap of which nodes a
workload is actively running on.

Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Ingo Molnar 
Cc: Chegu Vinod 
Signed-off-by: Rik van Riel 
Signed-off-by: Rik van Riel 
---
 include/linux/sched.h | 10 --
 kernel/sched/fair.c   | 30 +++---
 2 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 97efba4..a9f7f05 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1492,6 +1492,14 @@ struct task_struct {
unsigned long *numa_faults_buffer;
 
/*
+* Track the nodes where faults are incurred. This is not very
+* interesting on a per-task basis, but it help with smarter
+* numa memory placement for groups of processes.
+*/
+   unsigned long *numa_faults_from;
+   unsigned long *numa_faults_from_buffer;
+
+   /*
 * numa_faults_locality tracks if faults recorded during the last
 * scan window were remote/local. The task scan period is adapted
 * based on the locality of the faults with different weights
@@ -1594,8 +1602,6 @@ extern void task_numa_fault(int last_node, int node, int 
pages, int flags);
 extern pid_t task_numa_group_id(struct task_struct *p);
 extern void set_numabalancing_state(bool enabled);
 extern void task_numa_free(struct task_struct *p);
-
-extern unsigned int sysctl_numa_balancing_migrate_deferred;
 #else
 static inline void task_numa_fault(int last_node, int node, int pages,
   int flags)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 41e2176..1945ddc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -886,6 +886,7 @@ struct numa_group {
 
struct rcu_head rcu;
unsigned long total_faults;
+   unsigned long *faults_from;
unsigned long faults[0];
 };
 
@@ -1372,10 +1373,11 @@ static void task_numa_placement(struct task_struct *p)
int priv, i;
 
for (priv = 0; priv < 2; priv++) {
-   long diff;
+   long diff, f_diff;
 
i = task_faults_idx(nid, priv);
diff = -p->numa_faults[i];
+   f_diff = -p->numa_faults_from[i];
 
/* Decay existing window, copy faults since last scan */
p->numa_faults[i] >>= 1;
@@ -1383,12 +1385,18 @@ static void task_numa_placement(struct task_struct *p)
fault_types[priv] += p->numa_faults_buffer[i];
p->numa_faults_buffer[i] = 0;
 
+   p->numa_faults_from[i] >>= 1;
+   p->numa_faults_from[i] += p->numa_faults_from_buffer[i];
+   p->numa_faults_from_buffer[i] = 0;
+
faults += p->numa_faults[i];
diff += p->numa_faults[i];
+   f_diff += p->numa_faults_from[i];
p->total_numa_faults += diff;
if (p->numa_group) {
/* safe because we can only change our own 
group */
p->numa_group->faults[i] += diff;
+   p->numa_group->faults_from[i] += f_diff;
p->numa_group->total_faults += diff;
group_faults += p->numa_group->faults[i];
}
@@ -1457,7 +1465,7 @@ static void task_numa_group(struct task_struct *p, int 
cpupid, int flags,
 
if (unlikely(!p->numa_group)) {
unsigned int size = sizeof(struct numa_group) +
-   2*nr_node_ids*sizeof(unsigned long);
+   4*nr_node_ids*sizeof(unsigned long);
 
grp = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
if (!grp)
@@ -1467,8 +1475,10 @@ static void task_numa_group(struct task_struct *p, int 
cpupid, int flags,
spin_lock_init(>lock);
INIT_LIST_HEAD(>task_list);
grp->gid = p->pid;
+   /* Second half of the array tracks where faults come from */
+   grp->faults_from = grp->faults + 2 * nr_node_ids;
 
-   for (i = 0; i < 2*nr_node_ids; i++)
+   for (i = 0; i < 4*nr_node_ids; i++)
grp->faults[i] = p->numa_faults[i];
 
grp->total_faults = p->total_numa_faults;
@@ -1526,7 +1536,7 @@ static void task_numa_group(struct task_struct *p, int 
cpupid, int flags,
 
double_lock(_grp->lock, >lock);
 
-   for (i = 0; i < 2*nr_node_ids; i++) {
+   for (i = 0; i < 4*nr_node_ids; i++) {
  

[PATCH 0/6] pseudo-interleaving for automatic NUMA balancing

[riel]

The current automatic NUMA balancing code base has issues with
workloads that do not fit on one NUMA load. Page migration is
slowed down, but memory distribution between the nodes where
the workload runs is essentially random, often resulting in a
suboptimal amount of memory bandwidth being available to the
workload.

In order to maximize performance of workloads that do not fit in one NUMA
node, we want to satisfy the following criteria:
1) keep private memory local to each thread
2) avoid excessive NUMA migration of pages
3) distribute shared memory across the active nodes, to
   maximize memory bandwidth available to the workload

This patch series identifies the NUMA nodes on which the workload
is actively running, and balances (somewhat lazily) the memory
between those nodes, satisfying the criteria above.

As usual, the series has had some performance testing, but it
could always benefit from more testing, on other systems.


Some performance numbers, with two 40-warehouse specjbb instances
on an 8 node system with 10 CPU cores per node, using a pre-cleanup
version of these patches, courtesy of Chegu Vinod:

numactl manual pinning
spec1.txt:   throughput = 755900.20 SPECjbb2005 bops
spec2.txt:   throughput = 754914.40 SPECjbb2005 bops

NO-pinning results (Automatic NUMA balancing, with patches)
spec1.txt:   throughput = 706439.84 SPECjbb2005 bops
spec2.txt:   throughput = 729347.75 SPECjbb2005 bops

NO-pinning results (Automatic NUMA balancing, without patches)
spec1.txt:   throughput = 667988.47 SPECjbb2005 bops
spec2.txt:   throughput = 638220.45 SPECjbb2005 bops

No Automatic NUMA and NO-pinning results
spec1.txt:   throughput = 544120.97 SPECjbb2005 bops
spec2.txt:   throughput = 453553.41 SPECjbb2005 bops


My own performance numbers are not as relevant, since I have been
running with a more hostile workload on purpose, and I have run
into a scheduler issue that caused the workload to run on only
two of the four NUMA nodes on my test system...


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] numa,sched: tracepoints for NUMA balancing active nodemask changes

[riel]

From: Rik van Riel 

Being able to see how the active nodemask changes over time, and why,
can be quite useful.

Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Ingo Molnar 
Cc: Chegu Vinod 
Signed-off-by: Rik van Riel 
Signed-off-by: Rik van Riel 
---
 include/trace/events/sched.h | 34 ++
 kernel/sched/fair.c  |  8 ++--
 2 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 67e1bbf..91726b6 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -530,6 +530,40 @@ TRACE_EVENT(sched_swap_numa,
__entry->dst_pid, __entry->dst_tgid, __entry->dst_ngid,
__entry->dst_cpu, __entry->dst_nid)
 );
+
+TRACE_EVENT(update_numa_active_nodes_mask,
+
+   TP_PROTO(int pid, int gid, int nid, int set, long faults, long 
max_faults),
+
+   TP_ARGS(pid, gid, nid, set, faults, max_faults),
+
+   TP_STRUCT__entry(
+   __field(pid_t,  pid)
+   __field(pid_t,  gid)
+   __field(int,nid)
+   __field(int,set)
+   __field(long,   faults)
+   __field(long,   max_faults);
+   ),
+
+   TP_fast_assign(
+   __entry->pid = pid;
+   __entry->gid = gid;
+   __entry->nid = nid;
+   __entry->set = set;
+   __entry->faults = faults;
+   __entry->max_faults = max_faults;
+   ),
+
+   TP_printk("pid=%d gid=%d nid=%d set=%d faults=%ld max_faults=%ld",
+   __entry->pid,
+   __entry->gid,
+   __entry->nid,
+   __entry->set,
+   __entry->faults,
+   __entry->max_faults)
+
+);
 #endif /* _TRACE_SCHED_H */
 
 /* This part must be outside protection */
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index aa680e2..3551009 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1300,10 +1300,14 @@ static void update_numa_active_node_mask(struct 
task_struct *p)
faults = numa_group->faults_from[task_faults_idx(nid, 0)] +
 numa_group->faults_from[task_faults_idx(nid, 1)];
if (!node_isset(nid, numa_group->active_nodes)) {
-   if (faults > max_faults * 4 / 10)
+   if (faults > max_faults * 4 / 10) {
+   
trace_update_numa_active_nodes_mask(current->pid, numa_group->gid, nid, true, 
faults, max_faults);
node_set(nid, numa_group->active_nodes);
-   } else if (faults < max_faults * 2 / 10)
+   }
+   } else if (faults < max_faults * 2 / 10) {
+   trace_update_numa_active_nodes_mask(current->pid, 
numa_group->gid, nid, false, faults, max_faults);
node_clear(nid, numa_group->active_nodes);
+   }
}
 }
 
-- 
1.8.4.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/

[PATCH 3/6] numa,sched: build per numa_group active node mask from faults_from statistics

[riel]

From: Rik van Riel 

The faults_from statistics are used to maintain an active_nodes nodemask
per numa_group. This allows us to be smarter about when to do numa migrations.

Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Ingo Molnar 
Cc: Chegu Vinod 
Signed-off-by: Rik van Riel 
Signed-off-by: Rik van Riel 
---
 kernel/sched/fair.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1945ddc..aa680e2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -885,6 +885,7 @@ struct numa_group {
struct list_head task_list;
 
struct rcu_head rcu;
+   nodemask_t active_nodes;
unsigned long total_faults;
unsigned long *faults_from;
unsigned long faults[0];
@@ -1275,6 +1276,38 @@ static void numa_migrate_preferred(struct task_struct *p)
 }
 
 /*
+ * Iterate over the nodes from which NUMA hinting faults were triggered, in
+ * other words where the CPUs that incurred NUMA hinting faults are. The
+ * bitmask is used to limit NUMA page migrations, and spread out memory
+ * between the actively used nodes. To prevent flip-flopping, and excessive
+ * page migrations, nodes are added when they cause over 40% of the maximum
+ * number of faults, but only removed when they drop below 20%.
+ */
+static void update_numa_active_node_mask(struct task_struct *p)
+{
+   unsigned long faults, max_faults = 0;
+   struct numa_group *numa_group = p->numa_group;
+   int nid;
+
+   for_each_online_node(nid) {
+   faults = numa_group->faults_from[task_faults_idx(nid, 0)] +
+numa_group->faults_from[task_faults_idx(nid, 1)];
+   if (faults > max_faults)
+   max_faults = faults;
+   }
+
+   for_each_online_node(nid) {
+   faults = numa_group->faults_from[task_faults_idx(nid, 0)] +
+numa_group->faults_from[task_faults_idx(nid, 1)];
+   if (!node_isset(nid, numa_group->active_nodes)) {
+   if (faults > max_faults * 4 / 10)
+   node_set(nid, numa_group->active_nodes);
+   } else if (faults < max_faults * 2 / 10)
+   node_clear(nid, numa_group->active_nodes);
+   }
+}
+
+/*
  * When adapting the scan rate, the period is divided into NUMA_PERIOD_SLOTS
  * increments. The more local the fault statistics are, the higher the scan
  * period will be for the next scan window. If local/remote ratio is below
@@ -1416,6 +1449,7 @@ static void task_numa_placement(struct task_struct *p)
update_task_scan_period(p, fault_types[0], fault_types[1]);
 
if (p->numa_group) {
+   update_numa_active_node_mask(p);
/*
 * If the preferred task and group nids are different,
 * iterate over the nodes again to find the best place.
@@ -1478,6 +1512,8 @@ static void task_numa_group(struct task_struct *p, int 
cpupid, int flags,
/* Second half of the array tracks where faults come from */
grp->faults_from = grp->faults + 2 * nr_node_ids;
 
+   node_set(task_node(current), grp->active_nodes);
+
for (i = 0; i < 4*nr_node_ids; i++)
grp->faults[i] = p->numa_faults[i];
 
@@ -1547,6 +1583,8 @@ static void task_numa_group(struct task_struct *p, int 
cpupid, int flags,
my_grp->nr_tasks--;
grp->nr_tasks++;
 
+   update_numa_active_node_mask(p);
+
spin_unlock(_grp->lock);
spin_unlock(>lock);
 
-- 
1.8.4.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/

[PATCH 6/6] numa,sched: normalize faults_from stats and weigh by CPU use

[riel]

From: Rik van Riel 

The tracepoint has made it abundantly clear that the naive
implementation of the faults_from code has issues.

Specifically, the garbage collector in some workloads will
access orders of magnitudes more memory than the threads
that do all the active work. This resulted in the node with
the garbage collector being marked the only active node in
the group.

This issue is avoided if we weigh the statistics by CPU use
of each task in the numa group, instead of by how many faults
each thread has occurred.

To achieve this, we normalize the number of faults to the
fraction of faults that occurred on each node, and then
multiply that fraction by the fraction of CPU time the
task has used since the last time task_numa_placement was
invoked.

This way the nodes in the active node mask will be the ones
where the tasks from the numa group are most actively running,
and the influence of eg. the garbage collector and other
do-little threads is properly minimized.

Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Ingo Molnar 
Cc: Chegu Vinod 
Signed-off-by: Rik van Riel 
Signed-off-by: Rik van Riel 
---
 include/linux/sched.h |  2 ++
 kernel/sched/core.c   |  2 ++
 kernel/sched/fair.c   | 49 +++--
 3 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0af6c1a..52de567 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1471,6 +1471,8 @@ struct task_struct {
int numa_preferred_nid;
unsigned long numa_migrate_retry;
u64 node_stamp; /* migration stamp  */
+   u64 last_task_numa_placement;
+   u64 last_sum_exec_runtime;
struct callback_head numa_work;
 
struct list_head numa_entry;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7f45fd5..9a0908a 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1758,6 +1758,8 @@ static void __sched_fork(unsigned long clone_flags, 
struct task_struct *p)
p->numa_work.next = >numa_work;
p->numa_faults = NULL;
p->numa_faults_buffer = NULL;
+   p->last_task_numa_placement = 0;
+   p->last_sum_exec_runtime = 0;
 
INIT_LIST_HEAD(>numa_entry);
p->numa_group = NULL;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8e0a53a..1601c68 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1422,11 +1422,41 @@ static void update_task_scan_period(struct task_struct 
*p,
memset(p->numa_faults_locality, 0, sizeof(p->numa_faults_locality));
 }
 
+/*
+ * Get the fraction of time the task has been running since the last
+ * NUMA placement cycle. The scheduler keeps similar statistics, but
+ * decays those on a 32ms period, which is orders of magnitude off
+ * from the dozens-of-seconds NUMA balancing period. Use the scheduler
+ * stats only if the task is so new there are no NUMA statistics yet.
+ */
+static u64 numa_get_avg_runtime(struct task_struct *p, u64 *period)
+{
+   u64 runtime, delta, now;
+   /* Use the start of this time slice to avoid calculations. */
+   now = p->se.exec_start;
+   runtime = p->se.sum_exec_runtime;
+
+   if (p->last_task_numa_placement) {
+   delta = runtime - p->last_sum_exec_runtime;
+   *period = now - p->last_task_numa_placement;
+   } else {
+   delta = p->se.avg.runnable_avg_sum;
+   *period = p->se.avg.runnable_avg_period;
+   }
+
+   p->last_sum_exec_runtime = runtime;
+   p->last_task_numa_placement = now;
+
+   return delta;
+}
+
 static void task_numa_placement(struct task_struct *p)
 {
int seq, nid, max_nid = -1, max_group_nid = -1;
unsigned long max_faults = 0, max_group_faults = 0;
unsigned long fault_types[2] = { 0, 0 };
+   unsigned long total_faults;
+   u64 runtime, period;
spinlock_t *group_lock = NULL;
 
seq = ACCESS_ONCE(p->mm->numa_scan_seq);
@@ -1435,6 +1465,10 @@ static void task_numa_placement(struct task_struct *p)
p->numa_scan_seq = seq;
p->numa_scan_period_max = task_scan_max(p);
 
+   total_faults = p->numa_faults_locality[0] +
+  p->numa_faults_locality[1] + 1;
+   runtime = numa_get_avg_runtime(p, );
+
/* If the task is part of a group prevent parallel updates to group 
stats */
if (p->numa_group) {
group_lock = >numa_group->lock;
@@ -1447,7 +1481,7 @@ static void task_numa_placement(struct task_struct *p)
int priv, i;
 
for (priv = 0; priv < 2; priv++) {
-   long diff, f_diff;
+   long diff, f_diff, f_weight;
 
i = task_faults_idx(nid, priv);
diff = -p->numa_faults[i];
@@ -1459,8 +1493,19 @@ static void task_numa_placement(struct task_struct *p)
fault_types[priv] += p->numa_faults_buffer[i];
  

[PATCH 5/6] numa,sched,mm: use active_nodes nodemask to limit numa migrations

[riel]

From: Rik van Riel 

Use the active_nodes nodemask to make smarter decisions on NUMA migrations.

In order to maximize performance of workloads that do not fit in one NUMA
node, we want to satisfy the following criteria:
1) keep private memory local to each thread
2) avoid excessive NUMA migration of pages
3) distribute shared memory across the active nodes, to
   maximize memory bandwidth available to the workload

This patch accomplishes that by implementing the following policy for
NUMA migrations:
1) always migrate on a private fault
2) never migrate to a node that is not in the set of active nodes
   for the numa_group
3) always migrate from a node outside of the set of active nodes,
   to a node that is in that set
4) within the set of active nodes in the numa_group, only migrate
   from a node with more NUMA page faults, to a node with fewer
   NUMA page faults, with a 25% margin to avoid ping-ponging

This results in most pages of a workload ending up on the actively
used nodes, with reduced ping-ponging of pages between those nodes.

Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Ingo Molnar 
Cc: Chegu Vinod 
Signed-off-by: Rik van Riel 
Signed-off-by: Rik van Riel 
---
 include/linux/sched.h |  7 +++
 kernel/sched/fair.c   | 37 +
 mm/mempolicy.c|  3 +++
 3 files changed, 47 insertions(+)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index a9f7f05..0af6c1a 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1602,6 +1602,8 @@ extern void task_numa_fault(int last_node, int node, int 
pages, int flags);
 extern pid_t task_numa_group_id(struct task_struct *p);
 extern void set_numabalancing_state(bool enabled);
 extern void task_numa_free(struct task_struct *p);
+extern bool should_numa_migrate(struct task_struct *p, int last_cpupid,
+   int src_nid, int dst_nid);
 #else
 static inline void task_numa_fault(int last_node, int node, int pages,
   int flags)
@@ -1617,6 +1619,11 @@ static inline void set_numabalancing_state(bool enabled)
 static inline void task_numa_free(struct task_struct *p)
 {
 }
+static inline bool should_numa_migrate(struct task_struct *p, int last_cpupid,
+  int src_nid, int dst_nid)
+{
+   return true;
+}
 #endif
 
 static inline struct pid *task_pid(struct task_struct *task)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3551009..8e0a53a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -948,6 +948,43 @@ static inline unsigned long group_weight(struct 
task_struct *p, int nid)
return 1000 * group_faults(p, nid) / p->numa_group->total_faults;
 }
 
+bool should_numa_migrate(struct task_struct *p, int last_cpupid,
+int src_nid, int dst_nid)
+{
+   struct numa_group *ng = p->numa_group;
+
+   /* Always allow migrate on private faults */
+   if (cpupid_match_pid(p, last_cpupid))
+   return true;
+
+   /* A shared fault, but p->numa_group has not been set up yet. */
+   if (!ng)
+   return true;
+
+   /*
+* Do not migrate if the destination is not a node that
+* is actively used by this numa group.
+*/
+   if (!node_isset(dst_nid, ng->active_nodes))
+   return false;
+
+   /*
+* Source is a node that is not actively used by this
+* numa group, while the destination is. Migrate.
+*/
+   if (!node_isset(src_nid, ng->active_nodes))
+   return true;
+
+   /*
+* Both source and destination are nodes in active
+* use by this numa group. Maximize memory bandwidth
+* by migrating from more heavily used groups, to less
+* heavily used ones, spreading the load around.
+* Use a 1/4 hysteresis to avoid spurious page movement.
+*/
+   return group_faults(p, dst_nid) < (group_faults(p, src_nid) * 3 / 4);
+}
+
 static unsigned long weighted_cpuload(const int cpu);
 static unsigned long source_load(int cpu, int type);
 static unsigned long target_load(int cpu, int type);
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 052abac..050962b 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -2405,6 +2405,9 @@ int mpol_misplaced(struct page *page, struct 
vm_area_struct *vma, unsigned long
if (!cpupid_pid_unset(last_cpupid) && 
cpupid_to_nid(last_cpupid) != thisnid) {
goto out;
}
+
+   if (!should_numa_migrate(current, last_cpupid, curnid, polnid))
+   goto out;
}
 
if (curnid != polnid)
-- 
1.8.4.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/

linux-next: Tree for Jan 17

[Stephen Rothwell]

Hi all,

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140116:

Dropped tree: sh (complex merge conflicts against very old commits)

The powerpc tree still had its build failure.

The net-next tree gained a conflict against the net tree.

The devicetree tree gained conflicts against the arm-soc tree.

The dt-rh tree gained a conflict against the arm-soc tree.

The tip tree lost its build failure with a supplied merge fix patch and
gained a conflict against Linus' tree.

The kvm tree still had its build failure so I used the version from
next-20140109.

The pinctrl tree gained a conflict against the watchdog tree.

Non-merge commits (relative to Linus' tree): 9316
 8699 files changed, 446302 insertions(+), 232089 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (85ce70fdf48a Merge branches 'sched-urgent-for-linus' and 
'timers-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" 
not depend on vmlinux)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (b25f3e1c3584 ARM: 7938/1: OMAP4/highbank: Flush L2 
cache before disabling)
Merging m68k-current/for-linus (77a42796786c m68k: Remove deprecated 
IRQF_DISABLED)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap)
Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4)
Merging net/master (aee636c4809f bpf: do not use reciprocal divide)
Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in 
dccp_probe init)
Merging sound-current/for-linus (315fba80a664 Merge tag 'asoc-v3.13-rc8-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, 
Armada, R-Car PCI host maintainers)
Merging wireless/master (2eff7c791a18 Merge tag 'nfc-fixes-3.13-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes)
Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5)
Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5)
Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5)
Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5)
Merging char-misc.current/char-misc-linus (802eee95bde7 Linux 3.13-rc6)
Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for 
Logitech F310 and F710)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile 
error)
Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary 
pci_set_drvdata())
Merging dwmw2/master (5950f0803ca9 pcmcia: remov

I want to invest this fund.

[Ms.Sarah Angus]

Hi,
 
Can you assist me to invest funds in your Country? if yes, then get back to 
me, so I can give you details and areas you can 

participate by being my partner.
 
Ms. Sarah
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Q] Why does kexec use device_shutdown rather than ubind them

[Benjamin Herrenschmidt]

On Thu, 2014-01-16 at 20:52 -0800, Eric W. Biederman wrote:
> 
> I think we have largely survied until now because kdump is so popular
> and kdump winds up having to reinitialize devices from any random
> state.

kdump also doesn't care too much if the device is still DMA'ing to the
old kernel memory :-)

> But like I said I am all for reducing the burden on device driver
> developers.

Right. I'm experimenting with a variant of device_shutdown() that tries
remove() first and if it doesn't exist and shutdown() does, call that
(is that ever the case ?). I'm keeping this kexec-specific for now.

I'll try to hammer that on some of our machines see if it breaks
anything, I think it's a much better approach for kexec.

As for actual machine shutdown, we *might* have some corner cases where
shutdown is actually different from remove for good reasons, so that
will have to be investigated a bit more in depth.

I'll post my results when I have them.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] MODSIGN: Fix including certificate twice when the signing_key.x509

[joeyli]

於 四，2014-01-16 於 12:31 +，David Howells 提到：
> 
> Are you asking for this to go upstream or into my devel-pekey branch?
> 
> If upstream you want it to go upstream, I presume commit
> d7ec435fdd03cfee70dba934ee384acc87bd6d00 doesn't fix the problem?
> 
> David 

You are right. I tried the d7ec435 patch fixed issue. Please ignore my
patch.


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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][v4] powerpc/config: Enable memory driver

[Prabhakar Kushwaha]

As Freescale IFC controller has been moved to driver to driver/memory.

So enable memory driver in powerpc config

Signed-off-by: Prabhakar Kushwaha 
---
 Changes for v2: Sending as it is
 Changes for v3: Sending as it is
 Changes for v4: Rebased to 
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git


 arch/powerpc/configs/corenet32_smp_defconfig |1 +
 arch/powerpc/configs/corenet64_smp_defconfig |1 +
 arch/powerpc/configs/mpc85xx_defconfig   |1 +
 arch/powerpc/configs/mpc85xx_smp_defconfig   |1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/powerpc/configs/corenet32_smp_defconfig 
b/arch/powerpc/configs/corenet32_smp_defconfig
index 60027c2..b717e5d 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -144,6 +144,7 @@ CONFIG_RTC_DRV_DS3232=y
 CONFIG_RTC_DRV_CMOS=y
 CONFIG_UIO=y
 CONFIG_STAGING=y
+CONFIG_MEMORY=y
 CONFIG_VIRT_DRIVERS=y
 CONFIG_FSL_HV_MANAGER=y
 CONFIG_EXT2_FS=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig 
b/arch/powerpc/configs/corenet64_smp_defconfig
index 6c8b020..efbe5a3 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -129,6 +129,7 @@ CONFIG_EDAC=y
 CONFIG_EDAC_MM_EDAC=y
 CONFIG_DMADEVICES=y
 CONFIG_FSL_DMA=y
+CONFIG_MEMORY=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 CONFIG_ISO9660_FS=m
diff --git a/arch/powerpc/configs/mpc85xx_defconfig 
b/arch/powerpc/configs/mpc85xx_defconfig
index 5a58882..e215d4d 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -210,6 +210,7 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_CMOS=y
 CONFIG_DMADEVICES=y
 CONFIG_FSL_DMA=y
+CONFIG_MEMORY=y
 # CONFIG_NET_DMA is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig 
b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 165e6b3..7bc167c 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -210,6 +210,7 @@ CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_CMOS=y
 CONFIG_DMADEVICES=y
 CONFIG_FSL_DMA=y
+CONFIG_MEMORY=y
 # CONFIG_NET_DMA is not set
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
-- 
1.7.9.5



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

[PATCH 1/2][4] driver/memory:Move Freescale IFC driver to a common driver

[Prabhakar Kushwaha]

 Freescale IFC controller has been used for mpc8xxx. It will be used
 for ARM-based SoC as well. This patch moves the driver to driver/memory
 and fix the header file includes.

  Also remove module_platform_driver() and  instead call
  platform_driver_register() from subsys_initcall() to make sure this module
  has been loaded before MTD partition parsing starts.

Signed-off-by: Prabhakar Kushwaha 
Acked-by: Arnd Bergmann 
---
Changes for v2:
- Move fsl_ifc in driver/memory

Changes for v3:
- move device tree bindings to memory

Changes for v4: Rebased to 
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git

 .../{powerpc => memory-controllers}/fsl/ifc.txt|0
 arch/powerpc/sysdev/Makefile   |1 -
 drivers/memory/Makefile|1 +
 {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c  |8 ++--
 drivers/mtd/nand/fsl_ifc_nand.c|2 +-
 .../include/asm => include/linux}/fsl_ifc.h|0
 6 files changed, 8 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/{powerpc => 
memory-controllers}/fsl/ifc.txt (100%)
 rename {arch/powerpc/sysdev => drivers/memory}/fsl_ifc.c (98%)
 rename {arch/powerpc/include/asm => include/linux}/fsl_ifc.h (100%)

diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt 
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
rename to Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 99464a7..ec69532 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -19,7 +19,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o fsl_mpic_err.o
 obj-$(CONFIG_FSL_PCI)  += fsl_pci.o $(fsl-msi-obj-y)
 obj-$(CONFIG_FSL_PMC)  += fsl_pmc.o
 obj-$(CONFIG_FSL_LBC)  += fsl_lbc.o
-obj-$(CONFIG_FSL_IFC)  += fsl_ifc.o
 obj-$(CONFIG_FSL_GTM)  += fsl_gtm.o
 obj-$(CONFIG_FSL_85XX_CACHE_SRAM)  += fsl_85xx_l2ctlr.o 
fsl_85xx_cache_sram.o
 obj-$(CONFIG_SIMPLE_GPIO)  += simple_gpio.o
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 9cce5d7..b494e5b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,5 +6,6 @@ ifeq ($(CONFIG_DDR),y)
 obj-$(CONFIG_OF)   += of_memory.o
 endif
 obj-$(CONFIG_TI_EMIF)  += emif.o
+obj-$(CONFIG_FSL_IFC)  += fsl_ifc.o
 obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 obj-$(CONFIG_TEGRA30_MC)   += tegra30-mc.o
diff --git a/arch/powerpc/sysdev/fsl_ifc.c b/drivers/memory/fsl_ifc.c
similarity index 98%
rename from arch/powerpc/sysdev/fsl_ifc.c
rename to drivers/memory/fsl_ifc.c
index d7fc722..135a950 100644
--- a/arch/powerpc/sysdev/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -30,8 +30,8 @@
 #include 
 #include 
 #include 
+#include 
 #include 
-#include 
 
 struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
 EXPORT_SYMBOL(fsl_ifc_ctrl_dev);
@@ -299,7 +299,11 @@ static struct platform_driver fsl_ifc_ctrl_driver = {
.remove  = fsl_ifc_ctrl_remove,
 };
 
-module_platform_driver(fsl_ifc_ctrl_driver);
+static int __init fsl_ifc_init(void)
+{
+   return platform_driver_register(_ifc_ctrl_driver);
+}
+subsys_initcall(fsl_ifc_init);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Freescale Semiconductor");
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index f1f7f12..43d1a92 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -29,7 +29,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define FSL_IFC_V1_1_0 0x0101
 #define ERR_BYTE   0xFF /* Value returned for read
diff --git a/arch/powerpc/include/asm/fsl_ifc.h b/include/linux/fsl_ifc.h
similarity index 100%
rename from arch/powerpc/include/asm/fsl_ifc.h
rename to include/linux/fsl_ifc.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] of: fix of_update_property()

[Xiubo Li]

The of_update_property() is intent to update a property in a node
and if the property does not exist, will add it to the node.

The second search of the property is possibly won't be found, that
maybe removed by other thread just before the second search begain,
if so just retry it.

Signed-off-by: Xiubo Li 
---
 drivers/of/base.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index f807d0e..d0c53bc 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1572,6 +1572,7 @@ int of_update_property(struct device_node *np, struct 
property *newprop)
if (!newprop->name)
return -EINVAL;
 
+retry:
oldprop = of_find_property(np, newprop->name, NULL);
if (!oldprop)
return of_add_property(np, newprop);
@@ -1593,7 +1594,7 @@ int of_update_property(struct device_node *np, struct 
property *newprop)
raw_spin_unlock_irqrestore(_lock, flags);
 
if (!found)
-   return -ENODEV;
+   goto retry;
 
 #ifdef CONFIG_PROC_DEVICETREE
/* try to add to proc as well if it was initialized */
-- 
1.8.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: [RFC PATCH] sched: select_idle_sibling macro optimize

[Alex Shi]

On 01/17/2014 11:36 AM, Mike Galbraith wrote:
> +
> > >>> +   /* skip single group domain */
> > >>> +   if (sg == sg->next)
> > >>> +   continue;
>>> > > 
>>> > > When is that gonna happen?
>> > 
>> > I had seen this in a Intel platform, you may have both CPU domain and MC
>> > domain layer, because the domain flag is different, then they can not be
>> > merged. and then the CPU domain just has one group.
> But sd starts at MC.

That's true. Sorry for noise.

-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/rfc] perf on raspberry-pi without overflow interrupt

[Vince Weaver]

On Thu, 16 Jan 2014, Peter Zijlstra wrote:

> Yeah I suppose we could do something like that. Maybe something like:
> 
> # cat /sys/bus/event_source/devices/cpu/flags
> int precise filter

wouldn't that violate the "one value per file" rule?

I guess we could also stick it in the mmap page somewhere, as tools like 
PAPI already have to check there for things like rdpmc support.


Anyway, here's a first pass at a generic fix for this issue.  I'm sure the 
code is pretty horrible, I don't usually mess with the perf code at this 
level.  I haven't tested yet as it touched enough files that the rasp-pi 
is going to take a few hours to finish compiling.

Am I on the right track, or totally off here?

diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index bc3f2ef..6782379 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -397,7 +397,7 @@ __hw_perf_event_init(struct perf_event *event)
 */
hwc->config_base|= (unsigned long)mapping;
 
-   if (!hwc->sample_period) {
+   if (!is_sampling_event(event)) {
/*
 * For non-sampling runs, limit the sample_period to half
 * of the counter width. That way, the new counter value
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 20d553c..afb3fc8 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -97,8 +97,8 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, 
irq_handler_t handler)
 
irqs = min(pmu_device->num_resources, num_possible_cpus());
if (irqs < 1) {
-   pr_err("no irqs for PMUs defined\n");
-   return -ENODEV;
+   printk_once("no irqs for PMUs defined, sampled events not 
supported\n");
+   return 0;
}
 
for (i = 0; i < irqs; ++i) {
@@ -150,6 +150,10 @@ static void cpu_pmu_init(struct arm_pmu *cpu_pmu)
/* Ensure the PMU has sane values out of reset. */
if (cpu_pmu->reset)
on_each_cpu(cpu_pmu->reset, cpu_pmu, 1);
+
+   if (platform_get_irq(cpu_pmu->plat_device, 0) <= 0)
+   cpu_pmu->pmu.capabilities |= PERF_PMU_NO_INTERRUPT;
+
 }
 
 /*
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 2e069d1..f5e7f0c 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -251,9 +251,19 @@ struct pmu {
 * flush branch stack on context-switches (needed in cpu-wide mode)
 */
void (*flush_branch_stack)  (void);
+
+   /*
+* various common per-pmu feature flags
+*/
+   int capabilities;
 };
 
 /**
+ * struct pmu->capabilites flags
+ */
+#define PERF_PMU_NO_INTERRUPT  1
+
+/**
  * enum perf_event_active_state - the states of a event
  */
 enum perf_event_active_state {
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f574401..f65c6c6 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7056,6 +7056,14 @@ SYSCALL_DEFINE5(perf_event_open,
 */
pmu = event->pmu;
 
+   if (is_sampling_event(event)) {
+   if (pmu->capabilities & PERF_PMU_NO_INTERRUPT)
+   err = -ENOTSUPP;
+   goto err_alloc;
+   }
+
+
+
if (group_leader &&
(is_software_event(event) != is_software_event(group_leader))) {
if (is_software_event(event)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next v2 3/3] reciprocal_divide: correction/update of the algorithm

[Eric Dumazet]

On Fri, 2014-01-17 at 05:29 +0100, Hannes Frederic Sowa wrote:

> Also I doubt the performance drop for SLAB will be that massive. Also it was
> already replaced by SLUB as the default SLAB allocator, which doesn't use
> reciprocal_divide.

Google servers use SLAB, not SLUB, for various reasons, and performance
is one of them.


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

Re: [PATCH] mm/zswap: add writethrough option

[Dan Streetman]

On Wed, Jan 15, 2014 at 12:42 AM, Minchan Kim  wrote:
> Hello,
>
> On Tue, Jan 14, 2014 at 10:10:44AM -0500, Dan Streetman wrote:
>> On Mon, Jan 13, 2014 at 7:11 PM, Minchan Kim  wrote:
>> > Hello Dan,
>> >
>> > Sorry for the late response and I didn't look at the code yet
>> > because I am not convinced. :(
>> >
>> > On Thu, Dec 19, 2013 at 08:23:27AM -0500, Dan Streetman wrote:
>> >> Currently, zswap is writeback cache; stored pages are not sent
>> >> to swap disk, and when zswap wants to evict old pages it must
>> >> first write them back to swap cache/disk manually.  This avoids
>> >> swap out disk I/O up front, but only moves that disk I/O to
>> >> the writeback case (for pages that are evicted), and adds the
>> >> overhead of having to uncompress the evicted pages and the
>> >> need for an additional free page (to store the uncompressed page).
>> >>
>> >> This optionally changes zswap to writethrough cache by enabling
>> >> frontswap_writethrough() before registering, so that any
>> >> successful page store will also be written to swap disk.  The
>> >> default remains writeback.  To enable writethrough, the param
>> >> zswap.writethrough=1 must be used at boot.
>> >>
>> >> Whether writeback or writethrough will provide better performance
>> >> depends on many factors including disk I/O speed/throughput,
>> >> CPU speed(s), system load, etc.  In most cases it is likely
>> >> that writeback has better performance than writethrough before
>> >> zswap is full, but after zswap fills up writethrough has
>> >> better performance than writeback.
>> >
>> > So you claims we should use writeback default but writethrough
>> > after memory limit is full?
>> > But it would break LRU ordering and I think better idea is to
>> > handle it more generic way rather than chaning entire policy.
>>
>> This patch only adds the option of using writethrough.  That's all.
>
> The point is that please explain that what's the your problem now
> and prove that adding new option for solve the problem is best.
> Just "Optionally, having is better" is not good approach to merge/maintain.

You may have missed the earlier emails discussing all that, so to
recap it appears that writeback is (usually) faster before zswap is
full, while writethrough appears (usually) slightly faster after zswap
has filled up.  It's highly dependent on the actual system details
(cpu speed, IO speed, load, etc) though.

>
>>
>> > Now, zswap evict out just *a* page rather than a bunch of pages
>> > so it stucks every store if many swap write happens continuously.
>> > It's not efficient so how about adding kswapd's threshold concept
>> > like min/low/high? So, it could evict early before reaching zswap
>> > memory pool and stop it reaches high watermark.
>> > I guess it could be better than now.
>>
>> Well, I don't think that's related to this patch, but certainly a good idea 
>> to
>> investigate.
>
> Why I suggested it that I feel from your description that wb is just
> slower than wt since zswap memory is pool.

evicting pages early doesn't avoid the overhead of having to
decompress the pages nor does it avoid having to write them to disk,
so I don't think it has a direct relation to this patch to add the
writethrough option.

>
>>
>> >
>> > Other point: As I read device-mapper/cache.txt, cache operating mode
>> > already supports writethrough. It means zram zRAM can support
>> > writeback/writethough with dm-cache.
>> > Have you tried it? Is there any problem?
>>
>> zswap isn't a block device though, so that doesn't apply (unless I'm
>> missing something).
>
> zram is block device so freely you can make it to swap block device
> and binding it with dm-cache will make what you want.
> The whole point is we could do what you want without adding new
> so I hope you prove what's the problem in existing solution so that
> we could judge and try to solve the pain point with more ideal
> approach.

Sorry, it seems like you're saying "you can drop zswap and start using
zram, so this patch isn't needed", which really doesn't actually
address this patch I don't think.  zswap vs. zram isn't an argument
I'm trying to get into right now.

>
>>
>> >
>> > Acutally, I really don't know how much benefit we have that in-memory
>> > swap overcomming to the real storage but if you want, zRAM with dm-cache
>> > is another option rather than invent new wheel by "just having is better".
>>
>> I'm not sure if this patch is related to the zswap vs. zram discussions.  
>> This
>> only adds the option of using writethrough to zswap.  It's a first
>> step to possibly
>> making zswap work more efficiently using writeback and/or writethrough
>> depending on
>> the system and conditions.
>
> The patch size is small. Okay I don't want to be a party-pooper
> but at least, I should say my thought for Andrew to help judging.

Sure, I'm glad to have your suggestions.

>
>>
>> >
>> > Thanks.
>> >
>> >>
>> >> Signed-off-by: Dan Streetman 
>> >>
>> >> ---
>> >>
>> >> Based on specjbb 

Re: gcc tickets for sparse attributes

[H. Peter Anvin]

On 01/16/2014 09:27 PM, H. Peter Anvin wrote:
> Hi,
> 
> I have filed gcc tickets asking for direct support in gcc for some
> sparse extensions that we use heavily in the kernel:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59851
> 

Add:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852

-hpa


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

[PATCH] MAINTAINERS: remove unnecessary EXYNOS DP DRIVER F: pattern

[Jingoo Han]

Remove unnecessary pattern for Exynos DP header from MAINTAINERS
file. After the commit f9b1e01 "video: exynos_dp: remove non-DT
support for Exynos Display Port", 'exynos_dp.h' has not been used.

Signed-off-by: Jingoo Han 
---
 MAINTAINERS |1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 070800c..0563a43 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3376,7 +3376,6 @@ M:Jingoo Han 
 L: linux-fb...@vger.kernel.org
 S: Maintained
 F: drivers/video/exynos/exynos_dp*
-F: include/video/exynos_dp*
 
 EXYNOS MIPI DISPLAY DRIVERS
 M: Inki Dae 
-- 
1.7.10.4


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

gcc tickets for sparse attributes

[H. Peter Anvin]

Hi,

I have filed gcc tickets asking for direct support in gcc for some
sparse extensions that we use heavily in the kernel:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59851

However, I would also like support for the context extensions, but I'm
not knowledgeable enough to describe the semantics accurately.  Would
anyone be willing to file a ticket describing how the context extension
works well enough that it could be implemented?

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

Re: bio_integrity_verify() bug causing READ verify to be silently skipped

[Nicholas A. Bellinger]

On Fri, 2014-01-03 at 15:09 -0500, Martin K. Petersen wrote:
> > "nab" == Nicholas A Bellinger  writes:
> 
> nab> Given that bio_integrity_verify() is using bio_for_each_segment(),
> nab> the loop starts from the updated bio->bi_idx, and not a zero value,
> nab> which ends up skipping individual bio segment calls to
> nab> bi->verify_fn().
> 
> That's botched. Verify is meant to be called with the completed bytes
> before the index is tampered with.
> 
> 
> nab> The following patch changes bio_integrity_verify() to use
> nab> bio_for_each_segment_all() instead of bio_for_each_segment() to
> nab> ensure that the segment walk always starts from zero, regardless of
> nab> the current bio->bi_idx value after bio_advance().
> 
> That breaks partial completion, though. I'll take a look at Kent's
> changes...
> 

Ping..?  Any updates on a proper bugfix for this..?

--nab

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

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the pinctrl tree got a conflict in
arch/arm/configs/bcm_defconfig between commit bd90ccd42c5d ("watchdog:
bcm281xx: Watchdog Driver") from the watchdog tree and commit
54b1aa5a5b16 ("ARM: pinctrl: Add Broadcom Capri pinctrl driver") from the
pinctrl 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 arch/arm/configs/bcm_defconfig
index 176e842308a8,bede51171d98..
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@@ -125,6 -126,4 +125,7 @@@ CONFIG_CRC_ITU_T=
  CONFIG_CRC7=y
  CONFIG_XZ_DEC=y
  CONFIG_AVERAGE=y
 +CONFIG_WATCHDOG=y
 +CONFIG_BCM_KONA_WDT=y
 +CONFIG_BCM_KONA_WDT_DEBUG=y
+ CONFIG_PINCTRL_CAPRI=y


pgpgVltwMOxSS.pgp
Description: PGP signature

Re: [PATCH RT 4/8] rtmutex: use a trylock for waiter lock in trylock

[Mike Galbraith]

On Thu, 2014-01-16 at 23:22 -0500, Steven Rostedt wrote: 
> On Thu, 16 Jan 2014 04:08:57 +0100
> Mike Galbraith  wrote:
> 
> > On Wed, 2014-01-15 at 20:58 -0500, Steven Rostedt wrote:
> > 
> > 
> > > 3.2.53-rt76-rc1 stable review patch.
> > > If anyone has any objections, please let me know.
> > 
> > Not sure this is needed without the tglx don't unconditionally raise
> > timer softirq patch, and with that patch applied in the form it exists
> > in 3.12-rt9, as well as this one, you'll still eventually deadlock.
> 
> Hmm, I'll have to take a look. This sounds to be missing from all the
> stable -rt kernels. I'll be pulling in the latest updates from 3.12-rt
> soon.

Below are the two deadlocks I encountered with 3.12-rt9, which has both
$subject and timers-do-not-raise-softirq-unconditionally.patch applied.

With bandaids applied, no others appeared.

nohz_full_all:
PID: 508TASK: 8802739ba340  CPU: 16  COMMAND: "ksoftirqd/16"
 #0 [880276806a40] machine_kexec at 8103bc07
 #1 [880276806aa0] crash_kexec at 810d56b3
 #2 [880276806b70] panic at 815bf8b0
 #3 [880276806bf0] watchdog_overflow_callback at 810fed3d
 #4 [880276806c10] __perf_event_overflow at 81131928
 #5 [880276806ca0] perf_event_overflow at 81132254
 #6 [880276806cb0] intel_pmu_handle_irq at 8102078f
 #7 [880276806de0] perf_event_nmi_handler at 815c5825
 #8 [880276806e10] nmi_handle at 815c4ed3
 #9 [880276806ea0] default_do_nmi at 815c5063
#10 [880276806ed0] do_nmi at 815c5388
#11 [880276806ef0] end_repeat_nmi at 815c4371
[exception RIP: _raw_spin_trylock+48]
RIP: 815c3790  RSP: 880276803e28  RFLAGS: 0002
RAX: 0010  RBX: 0010  RCX: 0002
RDX: 880276803e28  RSI: 0018  RDI: 0001
RBP: 815c3790   R8: 815c3790   R9: 0018
R10: 880276803e28  R11: 0002  R12: 
R13: 880273a0c000  R14: 8802739ba340  R15: 880273a03fd8
ORIG_RAX: 880273a03fd8  CS: 0010  SS: 0018
---  ---
#12 [880276803e28] _raw_spin_trylock at 815c3790
#13 [880276803e30] rt_spin_lock_slowunlock_hirq at 815c2cc8
#14 [880276803e50] rt_spin_unlock_after_trylock_in_irq at 815c3425
#15 [880276803e60] get_next_timer_interrupt at 810684a7
#16 [880276803ed0] tick_nohz_stop_sched_tick at 810c5f2e
#17 [880276803f50] tick_nohz_irq_exit at 810c6333
#18 [880276803f70] irq_exit at 81060065
#19 [880276803f90] smp_apic_timer_interrupt at 810358f5
#20 [880276803fb0] apic_timer_interrupt at 815cbf9d
---  ---
#21 [880273a03b28] apic_timer_interrupt at 815cbf9d
[exception RIP: _raw_spin_lock+50]
RIP: 815c3642  RSP: 880273a03bd8  RFLAGS: 0202
RAX: 8b49  RBX: 880272157290  RCX: 8802739ba340
RDX: 8b4a  RSI: 0010  RDI: 880273a0c000
RBP: 880273a03bd8   R8: 0001   R9: 
R10:   R11: 0001  R12: 810927b5
R13: 880273a03b68  R14: 0010  R15: 0010
ORIG_RAX: ff10  CS: 0010  SS: 0018
#22 [880273a03be0] rt_spin_lock_slowlock at 815c2591
#23 [880273a03cc0] rt_spin_lock at 815c3362
#24 [880273a03cd0] run_timer_softirq at 81069002
#25 [880273a03d70] handle_softirq at 81060d0f
#26 [880273a03db0] do_current_softirqs at 81060f3c
#27 [880273a03e20] run_ksoftirqd at 81061045
#28 [880273a03e40] smpboot_thread_fn at 81089c31
#29 [880273a03ec0] kthread at 810807fe
#30 [880273a03f50] ret_from_fork at 815cb28c

nohz_tick:
PID: 6948   TASK: 880272d1f1c0  CPU: 29  COMMAND: "tbench"
 #0 [8802769a6a40] machine_kexec at 8103bc07
 #1 [8802769a6aa0] crash_kexec at 810d3e93
 #2 [8802769a6b70] panic at 815bce70
 #3 [8802769a6bf0] watchdog_overflow_callback at 810fd51d
 #4 [8802769a6c10] __perf_event_overflow at 8112f1f8
 #5 [8802769a6ca0] perf_event_overflow at 8112fb14
 #6 [8802769a6cb0] intel_pmu_handle_irq at 8102078f
 #7 [8802769a6de0] perf_event_nmi_handler at 815c2de5
 #8 [8802769a6e10] nmi_handle at 815c2493
 #9 [8802769a6ea0] default_do_nmi at 815c2623
#10 [8802769a6ed0] do_nmi at 815c2948
#11 [8802769a6ef0] end_repeat_nmi at 815c1931
[exception RIP: preempt_schedule+36]
RIP: 815be944  RSP: 8802769a3d98  RFLAGS: 0002
RAX: 0010  RBX: 0010  RCX: 0002
RDX: 8802769a3d98  RSI: 0018  RDI: 0001
RBP: 815be944   R8: 815be944   R9: 

Re: [PATCH] mtd: davinci_nand: Remove unnecessary labels from error path

[Prabhakar Lad]

Hi Brian,

On Fri, Jan 17, 2014 at 3:02 AM, Brian Norris
 wrote:
> On Wed, Jan 15, 2014 at 01:38:26PM +0530, Prabhakar Lad wrote:
>> From: "Lad, Prabhakar" 
>>
>> This patch removes the unnecessary labels from
>> the error path in probe function which did nothing
>> than just returning error values, Thus simplifying code
>> path and improved readability.
>>
>> Signed-off-by: Lad, Prabhakar 
>
> This does not apply to my branch, since some OOM messages have been
> dropped. Can you rebase on l2-mtd.git (or linux-next)?
>
OK I'll rebase it against linux-next and post a v2.

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

Re: [RFC][PATCH] preempt: Debug for possible missed preemption checks

[Andrew Morton]

On Thu, 16 Jan 2014 23:57:51 -0500 Steven Rostedt  wrote:

> When PROVE_LOCKING and PREEMPT is configured, the preempt state
> tracking is active. Testing this out, I added a module that did the
> following:

So I assume your kernel at least has no instances of this bug, so we
don't need the patch ;) It *is* a fairly daft thing to do.

Maybe stick it in -next for a few months, see if anyone hits it?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH] preempt: Debug for possible missed preemption checks

[Steven Rostedt]

Peter Zijlstra mentioned that he wanted to catch the following problem:

 local_irq_disable();
 preempt_disable();
 local_irq_enable();

 local_irq_disable();
 preempt_enable();
 local_irq_enable();

Now what's wrong with the above? What happens if an interrupt comes in
the middle of that (between the local_irq_enable() and
local_irq_disable()) and sets the NEED_RESCHED flag? Because preemption
is disabled, it wont schedule there. It expects the schedule will
happen when preemption is enabled.

But the problem is that the preempt_enable() happens when a schedule
can not take place (interrupts are disabled), so it is ignored. Now
when interrupts are enabled, there's no NEED_RESCHED check, and we miss
our schedule.

Note, the first preempt_disable() did not need to even be within
the irq_disabled section. You can get the same problem with:

 preempt_disable();

  

 local_irq_disable();
 preempt_enable();
 local_irq_enable();

Basically anytime you go from preemption disabled and interrupts
enabled, to preemption enabled and interrupts disabled without ever
going back to preemption enabled and interrupts disabled state.

This can be solved by keeping track of the preemption and interrupt
states for the CPU. Here's the state diagram:

 State 0:  Preempt Enabled, Interrupts Enabled  (PEIE)
 State 1:  Preempt Enabled, Interrupts Disabled (PEID)
 State 2:  Preempt Disabled, Interrupts Enabled (PDIEX) *
 State 3:  Preempt Disabled, Interrupts Enabled (PDIE) **
 State 4:  Preempt Disabled, Interrupts Disabled (PDID)
 State 5:  Preempt Disabled, Interrupts Disabled (PDIDX)
 State 6:  Preempt Enabled, Interrupts Disabled (PEIDX)
 State 7:  Preempt Enabled, Interrupts Enabled (PEIEX) ***

(*) State 2 is the state where problems can occur (an interrupt
setting NEED_RESCHED while preemption is disabled).

Notice that some of the states have the same preemption and interrupts
disabled state. The difference between them is that those that went
through state 2 (denoted with an "X"), can lead us to state 6 which is
the state that can miss a preemption point.

(**) The difference between state 2 and state 3, is that state 3 is
 state 2 when it is in an interrupt. Ideally we would just switch
 state 7 to state 0 if we are in an interrupt, but this code can
 be called outside the setting of the "in_interrupt()" counter, and
 we can not detect it. To work around this, state 3 is created to
 keep from going into states 5, 6 and 7 while in an interrupt.

(***) If we hit state 7, we know that there's a path that exists that
  can lead us to miss a required schedule.

The state transactions are:

[preemption state changes] [interrupt state changes]
 State 0: (PEIE)   State 2   State 1
 State 1: (PEID)   State 4   State 0
 State 2: (PDIEX)  State 0   State 5
 State 3: (PDIE)   State 0   State 4
 State 4: (PDID)   State 1   State 2
 State 5: (PDIDX)  State 6   State 2
 State 6: (PEIDX)  State 5   State 7
 State 7: (PEIEX)   [End] [End]


When PROVE_LOCKING and PREEMPT is configured, the preempt state
tracking is active. Testing this out, I added a module that did the
following:

  preempt_disable();
  local_irq_disable();
  preempt_enable();
  local_irq_enable();

I also tested against:

  local_irq_disable();
  preempt_disable();
  local_irq_enable();
  local_irq_disable();
  preempt_enable();
  local_irq_enable();

And here's what the output looks like:

 ===
 [INFO: preempt check hit problem state]
 irq event stamp: 12
 hardirqs last  enabled at (11): [] 
_raw_spin_unlock_irq+0x30/0x60
 hardirqs last disabled at (12): [] dumb_thread+0x1e/0x80 
[preempt_bug]
 softirqs last  enabled at (0): [] copy_process+0x788/0x1a50
 softirqs last disabled at (0): [<  (null)>]   (null)
 Entered dangerous state at: 
[] preempt_count_add+0xab/0x110
[] dumb_thread+0x18/0x80 [preempt_bug]
[] kthread+0xf3/0x110
[] ret_from_fork+0x7c/0xb0
[] 0x
 stack backtrace:
 CPU: 4 PID: 3405 Comm: task1 Tainted: G   O 3.13.0-rc8-test+ #60
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 
05/07/2012
  0006 8800d47e5da8 8165d459 0002
  a050d028 8800d47e5de8 81099fc8 8800d47e5df8
  a050d028  a050d000 
 Call Trace:
  [] dump_stack+0x4f/0x7c
  [] ? dumb_thread+0x28/0x80 [preempt_bug]
  [] update_pied_state+0x398/0x3b0
  [] ? dumb_thread+0x28/0x80 [preempt_bug]
  [] ? 0xa050cfff
  [] trace_preempt_on+0x20/0x30
  [] preempt_count_sub+0xb9/0x100
  [] dumb_thread+0x28/0x80 [preempt_bug]
  [] kthread+0xf3/0x110
  [] ? flush_kthread_worker+0x150/0x150
  [] 

Re: [Q] Why does kexec use device_shutdown rather than ubind them

[Eric W. Biederman]

Benjamin Herrenschmidt  writes:

> Hi Folks !
>
> Sorry for the semi-random CC list, not sure who owns kexec nowadays. So
> we are working on a new crop of power servers for which the bootloader
> is going to be using kexec.
>
> As expected, we've been chasing a number of reliability issues mostly
> due to drivers not behaving properly, such as leaving devices DMA'ing or
> in a state that upsets the new kernel etc...
>
> So far our approach has been to fix the drivers one by one, adding the
> shutdown() method when it's missing, etc...
>
> But that lead me to wonder ... why shutdown() in the first place ? The
> semantic of shutdown() is that we are going to power the machine off. In
> some cases, that method will actively participate in the shutdown,
> powering things off, spinning disk down, etc
>
> It doesn't have the semantic of "put the device into a clean state for a
> new driver to pick up". It's also rarely implemented.
>
> On the other hand, the remove() routine is almost everywhere, and is
> already well understood as needing to leave the device in a clean state,
> as it's often used for rmmod (often by the driver developer
> him/herself), more likely to be tested in a condition that doesn't
> involve having the machine off immediately afterward but on the contrare
> in a condition where a new driver can come and try to pick the device
> up.
>
> Additionally, remove() is also what KVM does when assigning devices to
> guest, ie, the original driver is unbound from the host, and VFIO is
> bound in its place.
>
> So we have common purpose with kexec (somewhat) and possibly common (and
> better) testing coverage with remove() than with shutdown().
>
> I plan to experiment a bit in our bootloader see if that makes a
> difference, maybe doing a first pass of unbind for anything that can be
> unbound, and shutdown for the rest.
>
> (I'll probably also sneak it a PCIe hot reset at the end but that's more
> platform specific).
>
> Any opinion ?

When I was young and kexec was a new idea and the device model was just
getting methods.  An argument was made that using remove in the reboot
path was a bad idea because it does more than is necessary so we needed
shutdown.

I wanted to use remove at the time.

There is a lot of silliness now, but my inclination is to remove
shutdown entirely and replace it with remove.  I certainly would not
have heart burn with doing so just for kexec but getting the whole
reboot path at this point would make me very happy and then we could
kill a little used rarely implemented method from the kernel.

Given that we have found emperically that flipping the bus master enable
bit to off helps enormously for stability, but doing so generically
occassionally has unfortunate consequences why not.

I think we have largely survied until now because kdump is so popular
and kdump winds up having to reinitialize devices from any random state.

But like I said I am all for reducing the burden on device driver developers.

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/

[PATCH] ACPI / processor: Return specific error value when mapping lapic id

[Hanjun Guo]

we usually return 0 for success in int returned function, and negative
value when failed, but in processor_core.c, some function return 1
for success and 0 for failure which leads confusion sometimes,
replace with specific error values to fix that.

Signed-off-by: Hanjun Guo 
---
 drivers/acpi/processor_core.c |   26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index b3171f3..24c87ef 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -45,13 +45,13 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
(struct acpi_madt_local_apic *)entry;
 
if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
-   return 0;
+   return -ENODEV;
 
if (lapic->processor_id != acpi_id)
-   return 0;
+   return -EINVAL;
 
*apic_id = lapic->id;
-   return 1;
+   return 0;
 }
 
 static int map_x2apic_id(struct acpi_subtable_header *entry,
@@ -61,14 +61,14 @@ static int map_x2apic_id(struct acpi_subtable_header *entry,
(struct acpi_madt_local_x2apic *)entry;
 
if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
-   return 0;
+   return -ENODEV;
 
if (device_declaration && (apic->uid == acpi_id)) {
*apic_id = apic->local_apic_id;
-   return 1;
+   return 0;
}
 
-   return 0;
+   return -EINVAL;
 }
 
 static int map_lsapic_id(struct acpi_subtable_header *entry,
@@ -78,16 +78,16 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
(struct acpi_madt_local_sapic *)entry;
 
if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
-   return 0;
+   return -ENODEV;
 
if (device_declaration) {
if ((entry->length < 16) || (lsapic->uid != acpi_id))
-   return 0;
+   return -EINVAL;
} else if (lsapic->processor_id != acpi_id)
-   return 0;
+   return -EINVAL;
 
*apic_id = (lsapic->id << 8) | lsapic->eid;
-   return 1;
+   return 0;
 }
 
 static int map_madt_entry(int type, u32 acpi_id)
@@ -117,13 +117,13 @@ static int map_madt_entry(int type, u32 acpi_id)
struct acpi_subtable_header *header =
(struct acpi_subtable_header *)entry;
if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
-   if (map_lapic_id(header, acpi_id, _id))
+   if (!map_lapic_id(header, acpi_id, _id))
break;
} else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
-   if (map_x2apic_id(header, type, acpi_id, _id))
+   if (!map_x2apic_id(header, type, acpi_id, _id))
break;
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
-   if (map_lsapic_id(header, type, acpi_id, _id))
+   if (!map_lsapic_id(header, type, acpi_id, _id))
break;
}
entry += header->length;
-- 
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 V2] cpuidle/governors: Fix logic in selection of idle states

[Preeti U Murthy]

The cpuidle governors today are not handling scenarios where no idle state
can be chosen. Such scenarios coud arise if the user has disabled all the
idle states at runtime or the latency requirement from the cpus is very strict.

The menu governor returns 0th index of the idle state table when no other
idle state is suitable. This is even when the idle state corresponding to this
index is disabled or the latency requirement is strict and the exit_latency
of the lowest idle state is also not acceptable. Hence this patch
fixes this logic in the menu governor by defaulting to an idle state index
of -1 unless any other state is suitable.

The ladder governor needs a few more fixes in addition to that required in the
menu governor. When the ladder governor decides to demote the idle state of a
CPU, it does not check if the lower idle states are enabled. Add this logic
in addition to the logic where it chooses an index of -1 if it can neither
promote or demote the idle state of a cpu nor can it choose the current idle
state.

The cpuidle_idle_call() will return back if the governor decides upon not
entering any idle state. However it cannot return an error code because all
archs have the logic today that if the call to cpuidle_idle_call() fails, it
means that the cpuidle driver failed to *function*; for instance due to
errors during registration. As a result they end up deciding upon a
default idle state on their own, which could very well be a deep idle state.
This is incorrect in cases where no idle state is suitable.

Besides for the scenario that this patch is addressing, the call actually
succeeds. Its just that no idle state is thought to be suitable by the 
governors.
Under such a circumstance return success code without entering any idle
state.

Signed-off-by: Preeti U Murthy 

Changes from V1:https://lkml.org/lkml/2014/1/14/26

1. Change the return code to success from -EINVAL due to the reason mentioned
in the changelog.
2. Add logic that the patch is addressing in the ladder governor as well.
3. Added relevant comments and removed redundant logic as suggested in the
above thread.
---

 drivers/cpuidle/cpuidle.c  |   15 +-
 drivers/cpuidle/governors/ladder.c |   98 ++--
 drivers/cpuidle/governors/menu.c   |7 +--
 3 files changed, 89 insertions(+), 31 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index a55e68f..831b664 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -131,8 +131,9 @@ int cpuidle_idle_call(void)
 
/* ask the governor for the next state */
next_state = cpuidle_curr_governor->select(drv, dev);
+
+   dev->last_residency = 0;
if (need_resched()) {
-   dev->last_residency = 0;
/* give the governor an opportunity to reflect on the outcome */
if (cpuidle_curr_governor->reflect)
cpuidle_curr_governor->reflect(dev, next_state);
@@ -140,6 +141,18 @@ int cpuidle_idle_call(void)
return 0;
}
 
+   /* Unlike in the need_resched() case, we return here because the
+* governor did not find a suitable idle state. However idle is still
+* in progress as we are not asked to reschedule. Hence we return
+* without enabling interrupts.
+*
+* NOTE: The return code should still be success, since the verdict of 
this
+* call is "do not enter any idle state" and not a failed call due to
+* errors.
+*/
+   if (next_state < 0)
+   return 0;
+
trace_cpu_idle_rcuidle(next_state, dev->cpu);
 
broadcast = !!(drv->states[next_state].flags & CPUIDLE_FLAG_TIMER_STOP);
diff --git a/drivers/cpuidle/governors/ladder.c 
b/drivers/cpuidle/governors/ladder.c
index 9f08e8c..f495f57 100644
--- a/drivers/cpuidle/governors/ladder.c
+++ b/drivers/cpuidle/governors/ladder.c
@@ -58,6 +58,36 @@ static inline void ladder_do_selection(struct ladder_device 
*ldev,
ldev->last_state_idx = new_idx;
 }
 
+static int can_promote(struct ladder_device *ldev, int last_idx,
+   int last_residency)
+{
+   struct ladder_device_state *last_state;
+
+   last_state = >states[last_idx];
+   if (last_residency > last_state->threshold.promotion_time) {
+   last_state->stats.promotion_count++;
+   last_state->stats.demotion_count = 0;
+   if (last_state->stats.promotion_count >= 
last_state->threshold.promotion_count)
+   return 1;
+   }
+   return 0;
+}
+
+static int can_demote(struct ladder_device *ldev, int last_idx,
+   int last_residency)
+{
+   struct ladder_device_state *last_state;
+
+   last_state = >states[last_idx];
+   if (last_residency < last_state->threshold.demotion_time) {
+   last_state->stats.demotion_count++;
+   last_state->stats.promotion_count = 

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

[Jason Cooper]

Stephen,

On Fri, Jan 17, 2014 at 02:08:53PM +1100, Stephen Rothwell wrote:
> Hi Grant,
> 
> Today's linux-next merge of the devicetree tree got a conflict in
> arch/arm/boot/dts/dove.dtsi between commits 40aad3c1a9b6 ("dt/bindings:
> Remove all references to device_type "ethernet-phy"") and b31b32119abe
> ("ARM: dove: sort DT nodes by address") from the devicetree tree and
> commit 351291754df3 ("dt/bindings: remove device_type "network"
> references") from the devicetree tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks.

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

Re: [PATCH net-next v2 3/3] reciprocal_divide: correction/update of the algorithm

[Hannes Frederic Sowa]

On Thu, Jan 16, 2014 at 06:33:37PM -0800, Eric Dumazet wrote:
> On Fri, 2014-01-17 at 01:28 +0100, Hannes Frederic Sowa wrote:
> > Jakub Zawadzki noticed that some divisions by reciprocal_divide()
> > were not correct [1][2], which he could also show with BPF code after
> > divisions are transformed into reciprocal_value() for runtime invariant
> > which can be passed to reciprocal_divide() later on; reverse in BPF dump
> > ended up with a different, off-by-one K.
> > 
> > This has been fixed by Eric Dumazet in commit aee636c4809fa5 ("bpf: do not
> > use reciprocal divide"). This follow-up patch improves reciprocal_value()
> > and reciprocal_divide() to work in all cases, so future use is safe.
> > 
> > Known problems with the old implementation were that division by 1 always
> > returned 0 and some off-by-ones when the dividend and divisor where
> > very large.  This seemed to not be problematic with its current users
> > in networking, mm/slab.c and lib/flex_array.c, but future users would
> > need to check for this specifically and it might not be obvious at first.
> > 
> > In order to fix that, we propose an extension from the original
> > implementation from commit 6a2d7a955d8d resp. [3][4], by using
> > the algorithm proposed in "Division by Invariant Integers Using
> > Multiplication" [5], Torbjörn Granlund and Peter L. Montgomery, that is,
> > pseudocode for q = n/d where q,n,d is in u32 universe:
> > 
> > 1) Initialization:
> > 
> >   int l = ceil(log_2 d)
> >   uword m' = floor((1<<32)*((1< >   int sh_1 = min(l,1)
> >   int sh_2 = max(l-1,0)
> > 
> > 2) For q = n/d, all uword:
> > 
> >   uword t = (n*m')>>32
> >   q = (t+((n-t)>>sh_1))>>sh_2
> > 
> > The assembler implementation from Agner Fog [6] also helped a lot
> > while implementing. We have tested the implementation on x86_64,
> > ppc64, i686, s390x; on x86_64/haswell we're still half the latency
> > compared to normal divide.
> > 
> > Joint work with Daniel Borkmann.
> > 
> >   [1] http://www.wireshark.org/~darkjames/reciprocal-buggy.c
> >   [2] http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c
> >   [3] https://gmplib.org/~tege/division-paper.pdf
> >   [4] http://homepage.cs.uiowa.edu/~jones/bcd/divide.html
> >   [5] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.2556
> >   [6] http://www.agner.org/optimize/asmlib.zip
> > 
> > Fixes: 6a2d7a955d8d ("SLAB: use a multiply instead of a divide in 
> > obj_to_index()")
> 
> 
> I already demonstrated this slab patch was fine.
> 
> The current algo works well (no off-by-one error) when the dividend is
> a multiple of the divisor.

Sure, so did we state in the commit message.

> You are adding extra overhead, while we know its not necessary.
> 
> By using "Fixes: ... " you are asking a backport to stable branches,
> which seems really silly in this case, especially with this monolithic
> patch changing 12 files in different subsystems.

We can drop the the Fixes tags, no problem.

> If you believe flex_array has a problem, please fix flex_array only,
> by a small patch (Maybe a revert ?)

I really doubt it is helpful to have an implementation of reciprocal_divide
which has some known (and maybe unkown) problems in the long term.

This implementation still has an performance benefit compared to regular
division while calculating correct results in any case.

We clearly didn't intend stable inclusion, in fact this patch has been posted
for net-next inclusion as an improvment and not as a bugfix. The Fixes tags
where just lingering on this patch from my first attempt where the situation
was not that clear (at least for me).

Also I doubt the performance drop for SLAB will be that massive. Also it was
already replaced by SLUB as the default SLAB allocator, which doesn't use
reciprocal_divide.

Greetings,

  Hannes

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

Re: [PATCH RT 4/8] rtmutex: use a trylock for waiter lock in trylock

[Steven Rostedt]

On Thu, 16 Jan 2014 04:08:57 +0100
Mike Galbraith  wrote:

> On Wed, 2014-01-15 at 20:58 -0500, Steven Rostedt wrote:
> 
> 
> > 3.2.53-rt76-rc1 stable review patch.
> > If anyone has any objections, please let me know.
> 
> Not sure this is needed without the tglx don't unconditionally raise
> timer softirq patch, and with that patch applied in the form it exists
> in 3.12-rt9, as well as this one, you'll still eventually deadlock.

Hmm, I'll have to take a look. This sounds to be missing from all the
stable -rt kernels. I'll be pulling in the latest updates from 3.12-rt
soon.

Thanks,

-- Steve

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

[PATCH v3] ACPI: Fix acpi_evaluate_object() return value check

[Yijing Wang]

Fix acpi_evaluate_object() return value check,
shoud acpi_status not int.

Signed-off-by: Yijing Wang 
---
v2->v3: Fix compile error pointed out by Hanjun.
v1->v2: Add CC to related subsystem MAINTAINERS
---
 drivers/gpu/drm/i915/intel_acpi.c  |   24 ++--
 drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |9 +
 drivers/gpu/drm/nouveau/nouveau_acpi.c |   23 +--
 drivers/pci/pci-label.c|9 ++---
 4 files changed, 38 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index dfff090..87e8f74 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -35,7 +35,8 @@ static int intel_dsm(acpi_handle handle, int func)
union acpi_object params[4];
union acpi_object *obj;
u32 result;
-   int ret = 0;
+   acpi_status status;
+   int ret;
 
input.count = 4;
input.pointer = params;
@@ -50,10 +51,11 @@ static int intel_dsm(acpi_handle handle, int func)
params[3].package.count = 0;
params[3].package.elements = NULL;
 
-   ret = acpi_evaluate_object(handle, "_DSM", , );
-   if (ret) {
-   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
-   return ret;
+   status = acpi_evaluate_object(handle, "_DSM", , );
+   if (ACPI_FAILURE(status)) {
+   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
+   acpi_format_exception(status));
+   return -EINVAL;
}
 
obj = (union acpi_object *)output.pointer;
@@ -141,7 +143,8 @@ static void intel_dsm_platform_mux_info(void)
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *pkg;
-   int i, ret;
+   acpi_status status;
+   int i;
 
input.count = 4;
input.pointer = params;
@@ -156,10 +159,11 @@ static void intel_dsm_platform_mux_info(void)
params[3].package.count = 0;
params[3].package.elements = NULL;
 
-   ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", ,
-  );
-   if (ret) {
-   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
+   acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle,
+   "_DSM", , );
+   if (ACPI_FAILURE(status)) {
+   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
+   acpi_format_exception(status));
goto out;
}
 
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
index 1291204..c5e7a2b 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
@@ -114,15 +114,16 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_handle handle;
-   int ret;
+   acpi_status status;
 
handle = ACPI_HANDLE(>pdev->dev);
if (!handle)
return false;
 
-   ret = acpi_evaluate_object(handle, "_DSM", , );
-   if (ret) {
-   nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
+   status = acpi_evaluate_object(handle, "_DSM", , );
+   if (ACPI_FAILURE(status)) {
+   nv_debug(mxm, "DSM MXMS failed: %s\n",
+   acpi_format_exception(status));
return false;
}
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index ba0183f..de3068b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, 
int arg, uint32_t *
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
-   int i, err;
+   acpi_status status;
+   int i;
char args_buff[4];
 
input.count = 4;
@@ -101,10 +102,11 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
func, int arg, uint32_t *
args_buff[i] = (arg >> i * 8) & 0xFF;
params[3].buffer.pointer = args_buff;
 
-   err = acpi_evaluate_object(handle, "_DSM", , );
-   if (err) {
-   printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
-   return err;
+   status = acpi_evaluate_object(handle, "_DSM", , );
+   if (ACPI_FAILURE(status)) {
+   pr_info("failed to evaluate _DSM: %s\n",
+   acpi_format_exception(status));
+   return -EINVAL;
}
 
obj = (union acpi_object *)output.pointer;
@@ -134,7 +136,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
arg, uint32_t *result)
struct acpi_object_list input;
union 

Re: [PATCH REGRESSION FIX] x86 idle: restore mwait_idle()

[Mike Galbraith]

On Thu, 2014-01-16 at 14:00 -0800, Andy Lutomirski wrote:
> On 01/14/2014 09:37 PM, Len Brown wrote:
> > From: Len Brown 
> > 
> > In Linux-3.9 we removed the mwait_idle() loop:
> > 'x86 idle: remove mwait_idle() and "idle=mwait" cmdline param'
> > (69fb3676df3329a7142803bb3502fa59dc0db2e3)
> > 
> > The reasoning was that modern machines should be sufficiently
> > happy during the boot process using the default_idle() HALT loop,
> > until cpuidle loads and either acpi_idle or intel_idle
> > invoke the newer MWAIT-with-hints idle loop.
> > 
> > But two machines reported problems:
> > 1. Certain Core2-era machines support MWAIT-C1 and HALT only.
> >MWAIT-C1 is preferred for optimal power and performance.
> >But if they support just C1, cpuidle never loads and
> >so they use the boot-time default idle loop forever.
> > 
> > 2. Some laptops will boot-hang if HALT is used,
> >but will boot successfully if MWAIT is used.
> >This appears to be a hidden assumption in BIOS SMI,
> >that is presumably valid on the proprietary OS
> >where the BIOS was validated.
> > 
> >https://bugzilla.kernel.org/show_bug.cgi?id=60770
> > 
> > So here we effectively revert the patch above, restoring
> > the mwait_idle() loop.  However, we don't bother restoring
> > the idle=mwait cmdline parameter, since it appears to add
> > no value.
> > 
> > Maintainer notes:
> > For 3.9, simply revert 69fb3676df
> > for 3.10, patch -F3 applies, fuzz needed due to __cpuinit use in context
> > For 3.11, 3.12, 3.13, this patch applies cleanly
> > 
> > Cc: Mike Galbraith 
> > Cc: Ian Malone 
> > Cc: Josh Boyer 
> > Cc:  # 3.9, 3.10, 3.11, 3.12, 3.13
> > Signed-off-by: Len Brown 
> > ---
> >  arch/x86/kernel/process.c | 46 
> > ++
> >  1 file changed, 46 insertions(+)
> > 
> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > index 3fb8d95..db471a8 100644
> > --- a/arch/x86/kernel/process.c
> > +++ b/arch/x86/kernel/process.c
> > @@ -398,6 +398,49 @@ static void amd_e400_idle(void)
> > default_idle();
> >  }
> >  
> > +/*
> > + * Intel Core2 and older machines prefer MWAIT over HALT for C1.
> > + * We can't rely on cpuidle installing MWAIT, because it will not load
> > + * on systems that support only C1 -- so the boot default must be MWAIT.
> > + *  
> > + * Some AMD machines are the opposite, they depend on using HALT.
> > + *
> > + * So for default C1, which is used during boot until cpuidle loads,
> > + * use MWAIT-C1 on Intel HW that has it, else use HALT.
> > + */
> > +static int prefer_mwait_c1_over_halt(const struct cpuinfo_x86 *c)
> > +{
> > +   if (c->x86_vendor != X86_VENDOR_INTEL)
> > +   return 0;
> > +
> > +   if (!cpu_has(c, X86_FEATURE_MWAIT))
> > +   return 0;
> > +
> > +   return 1;
> > +}
> > +
> > +/*
> > + * MONITOR/MWAIT with no hints, used for default default C1 state.
> > + * This invokes MWAIT with interrutps enabled and no flags,
> > + * which is backwards compatible with the original MWAIT implementation.
> > + */
> > +
> > +static void mwait_idle(void)
> > +{
> > +   if (!need_resched()) {
> > +   if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
> > +   clflush((void *)_thread_info()->flags);
> > +
> > +   __monitor((void *)_thread_info()->flags, 0, 0);
> > +   smp_mb();
> > +   if (!need_resched())
> > +   __sti_mwait(0, 0);
> > +   else
> > +   local_irq_enable();
> > +   } else
> > +   local_irq_enable();
> > +}
> 
> Admittedly, there may be relatively few users left, but SMP users on
> C1-only Core 2 machines can, in principle, benefit from the monitor
^hugely
> functionality of mwait to avoid rescheduling IPIs.  This stuff changed
> recently so it now works with the cpuidle drivers (it used to be
> terminally broken).  Should something be twiddling TS_POLLING
> differently so that HLT gets the IPIs but mwait doesn't?

Urk, definitely.  The IPI is the primary cause of the size large cross
core scheduling performance regression for my aging, but lovely Q6600.

taskset 0xc pipe-test 1

3.8.13 3.397977 usecs/loop -- avg 3.400336 588.2 KHz
master+4.798547 usecs/loop -- avg 4.791692 417.4 KHz

-Mike

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

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

[Stephen Rothwell]

Hi all,

On Fri, 10 Jan 2014 14:00:43 +1100 Stephen Rothwell  
wrote:
>
> After merging the kvm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function 'kvm_vcpu_on_spin':
> arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1807:4: error: implicit 
> declaration of function 'kvm_vcpu_eligible_for_directed_yield' 
> [-Werror=implicit-function-declaration]
> if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
> ^
> 
> Caused by commit 7940876e1330 ("kvm: make local functions static").
> 
> I have used the kvm tree from next-20140109 for today.

I am still getting this build failure.

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


pgp3ZjmG4pD2t.pgp
Description: PGP signature

Re: [PATCH v2] ACPI: Fix acpi_evaluate_object() return value check

[Yijing Wang]

>> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
>> b/drivers/gpu/drm/i915/intel_acpi.c
>> index dfff090..7ea00e5 100644
>> --- a/drivers/gpu/drm/i915/intel_acpi.c
>> +++ b/drivers/gpu/drm/i915/intel_acpi.c
>> @@ -35,7 +35,7 @@ static int intel_dsm(acpi_handle handle, int func)
>>  union acpi_object params[4];
>>  union acpi_object *obj;
>>  u32 result;
>> -int ret = 0;
> 
> The 'ret' is removed, but

Ah, it's my mistake, will updata it right now, thanks!

> 
>> +acpi_status status;
>>  
>>  input.count = 4;
>>  input.pointer = params;
>> @@ -50,8 +50,8 @@ static int intel_dsm(acpi_handle handle, int func)
>>  params[3].package.count = 0;
>>  params[3].package.elements = NULL;
>>  
>> -ret = acpi_evaluate_object(handle, "_DSM", , );
>> -if (ret) {
>> +status = acpi_evaluate_object(handle, "_DSM", , );
>> +if (ACPI_FAILURE(status)) {
>>  DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>>  return ret;
> 
> you still use it here, so you should -EINVAL or something else here.

OK

> 
>>  }
>> @@ -141,7 +141,8 @@ static void intel_dsm_platform_mux_info(void)
>>  struct acpi_object_list input;
>>  union acpi_object params[4];
>>  union acpi_object *pkg;
>> -int i, ret;
>> +acpi_status status;
>>  
>> -err = acpi_evaluate_object(handle, "_DSM", , );
>> -if (err) {
>> +status = acpi_evaluate_object(handle, "_DSM", , );
>> +if (ACPI_FAILURE(status)) {
>>  printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
>>  return err;
> 
> here too.

OK, thanks.

> 
>>  }
>> @@ -134,7 +135,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
>> arg, uint32_t *result)
>>  struct acpi_object_list input;
>>  union acpi_object params[4];
>>  union acpi_object *obj;
>> -int err;
>> +acpi_status status;
>>  
>>  input.count = 4;
>>  input.pointer = params;
>> @@ -148,8 +149,8 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
>> arg, uint32_t *result)
>>  params[3].type = ACPI_TYPE_INTEGER;
>>  params[3].integer.value = arg;
>>  
>> -err = acpi_evaluate_object(handle, "_DSM", , );
>> -if (err) {
>> +status = acpi_evaluate_object(handle, "_DSM", , );
>> +if (ACPI_FAILURE(status)) {
>>  printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
>>  return err;
> 
> and here.

thanks.

> 
>>  }
>> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
>> index d51f45a..3c21f1b 100644
>> --- a/drivers/pci/pci-label.c
>> +++ b/drivers/pci/pci-label.c
>> @@ -213,7 +213,7 @@ dsm_get_label(acpi_handle handle, int func,
>>  union acpi_object *obj;
>>  int len = 0;
>>  
>> -int err;
>> +acpi_status status;
>>  
>>  input.count = 4;
>>  input.pointer = params;
>> @@ -228,8 +228,8 @@ dsm_get_label(acpi_handle handle, int func,
>>  params[3].package.count = 0;
>>  params[3].package.elements = NULL;
>>  
>> -err = acpi_evaluate_object(handle, "_DSM", , output);
>> -if (err)
>> +status = acpi_evaluate_object(handle, "_DSM", , output);
>> +if (ACPI_FAILURE(status))
>>  return -1;
> 
> can we return specific error such as -EINVAL instead of hard code?

I will try to add some more useful debug info here. thanks!

> 
> Thanks
> Hanjun
> 
> .
> 


-- 
Thanks!
Yijing

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

Re: [PATCH v2 01/16] reset: add non CONFIG_RESET_CONTROLLER routines

[Chen-Yu Tsai]

Hi,

On Fri, Jan 10, 2014 at 9:30 PM, Philipp Zabel  wrote:
> Hi,
>
> [Added Ivan, Stephen and Barry to Cc:]
>
> Am Freitag, den 10.01.2014, 15:00 +0800 schrieb Chen-Yu Tsai:
>> Some drivers are shared between platforms that may or may not
>> have RESET_CONTROLLER selected for them.
>
> I expected that drivers compiled for platforms without reset controllers
> but use the reset API should select or depend on RESET_CONTROLLER.
> Stubbing out device_reset and reset_control_get will turn a compile time
> error into a runtime error for everyone forgetting to do this when
> writing a new driver that needs the reset.

Since this was the intended behavior, I'll drop this patch and select
RESET_CONTROLLER for the stmmac driver for now.


Thanks
ChenYu

>
>>  Add dummy functions
>> when RESET_CONTROLLER is not selected, thereby eliminating the
>> need for drivers to enclose reset_control_*() calls within
>> #ifdef CONFIG_RESET_CONTROLLER, #endif
>>
>> Signed-off-by: Chen-Yu Tsai 
>
> This was already proposed by Ivan and Barry earlier, and so far we
> didn't get to a proper conclusion:
>
> https://lkml.org/lkml/2013/10/10/179
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/174758.html
>
> If included, the stubs should at least return an error to indicate a
> reset couldn't be performed, but then I lose the compile time error for
> drivers which should select RESET_CONTROLLER but don't.
>
> Also this alone won't help you if you build multi-arch kernels where one
> platform enables RESET_CONTROLLER and the other expects it to be
> disabled.
>
> regards
> Philipp
>
>> ---
>>  include/linux/reset.h | 39 +++
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/include/linux/reset.h b/include/linux/reset.h
>> index 6082247..38aa616 100644
>> --- a/include/linux/reset.h
>> +++ b/include/linux/reset.h
>> @@ -4,6 +4,8 @@
>>  struct device;
>>  struct reset_control;
>>
>> +#ifdef CONFIG_RESET_CONTROLLER
>> +
>>  int reset_control_reset(struct reset_control *rstc);
>>  int reset_control_assert(struct reset_control *rstc);
>>  int reset_control_deassert(struct reset_control *rstc);
>> @@ -14,4 +16,41 @@ struct reset_control *devm_reset_control_get(struct 
>> device *dev, const char *id)
>>
>>  int device_reset(struct device *dev);
>>
>> +#else /* !CONFIG_RESET_CONTROLLER */
>> +
>> +static inline int reset_control_reset(struct reset_control *rstc)
>> +{
>> + return 0;
>> +}
>> +
>> +static inline int reset_control_assert(struct reset_control *rstc)
>> +{
>> + return 0;
>> +}
>> +
>> +static inline int reset_control_deassert(struct reset_control *rstc)
>> +{
>> + return 0;
>> +}
>
> Those should probably have a WARN_ON(1) like the GPIO API stubs.
>
>> +
>> +static inline struct reset_control *reset_control_get(struct device *dev,
>> + const char *id)
>> +{
>> + return NULL;
>> +}
> [...]
>> +static inline struct reset_control *devm_reset_control_get(struct device 
>> *dev,
>> + const char *id)
>> +{
>> + return NULL;
>> +}
>
> These should return ERR_PTR(-ENOSYS).
>
>> +
>> +static inline int device_reset(struct device *dev)
>> +{
>> + return 0;
>> +}
>
> And this should return -ENOSYS.
>
> Drivers that also need to run on platforms with CONFIG_RESET_CONTROLLER
> disabled (and that don't need the reset) should ignore -ENOSYS and
> -ENOENT return values from device_reset/(devm_)reset_control_get.
>
> I wonder if it might be a good idea to add a RESET_CONTROLLER_OPTIONAL
> that drivers need to select to enable the API stubs? That way we could
> keep the compile time error for new drivers that need resets but forget
> to select RESET_CONTROLLER.
> Or add a
> #warning If this driver can work without reset, please select 
> CONFIG_RESET_CONTROLLER_OPTIONAL
>
> Another possibility would be to add device_reset_optional and
> (devm_)reset_control_get_optional variants and only provide stubs for
> those, but not for device_reset/(devm_)reset_control_get. Then drivers
> that need to work on platforms without the reset controller API enabled
> could explicitly use the _optional variants, and all other drivers would
> still be checked at compile time.
>
> regards
> Philipp
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi all,

On Thu, 16 Jan 2014 14:51:08 -0800 "H. Peter Anvin"  wrote:
>
> On 01/16/2014 02:34 PM, Stephen Rothwell wrote:
> > 
> > On Thu, 16 Jan 2014 23:25:36 +0100 Peter Zijlstra
> >  wrote:
> >> 
> >> On Fri, Jan 17, 2014 at 07:46:28AM +1100, Stephen Rothwell
> >> wrote:
> >>> 
> >>> On Thu, 16 Jan 2014 13:19:55 +0100 Peter Zijlstra
> >>>  wrote:
>  
>  I think the below ought to work
> >>> 
> >>> To be clear, all you did was replace the body of mwait_idle()
> >>> with
> >>> 
> >>> mwait_idle_with_hints(0, 0);
> >> 
> >> Pretty much, and add the asm/mwait.h include, otherwise you'll
> >> end up with a compile fail.
> >> 
> >>> (and the comment above it)?  I need to apply in incremental
> >>> patch in the merge commit.
> >> 
> >> I don't think I touched the comment at all.
> > 
> 
> In retrospect this bit probably should have gone through the idle
> tree.  That was my bad, I need to coordinate with Len better.

So this is what I added as a merge fix patch.  Someone just needs to make
sure Linus gets this when the latter of the tow trees gets merged.

From: Stephen Rothwell 
Date: Fri, 17 Jan 2014 14:42:06 +1100
Subject: [PATCH] x86 idle: mwait_idle merge update

Signed-off-by: Stephen Rothwell 
---
 arch/x86/kernel/process.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index db471a87fdd8..4da840f01561 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -427,18 +428,7 @@ static int prefer_mwait_c1_over_halt(const struct 
cpuinfo_x86 *c)
 
 static void mwait_idle(void)
 {
-   if (!need_resched()) {
-   if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
-   clflush((void *)_thread_info()->flags);
-
-   __monitor((void *)_thread_info()->flags, 0, 0);
-   smp_mb();
-   if (!need_resched())
-   __sti_mwait(0, 0);
-   else
-   local_irq_enable();
-   } else
-   local_irq_enable();
+   mwait_idle_with_hints(0, 0);
 }
 
 void select_idle_routine(const struct cpuinfo_x86 *c)
-- 
1.8.5.2


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


pgp6ncdy1I8lt.pgp
Description: PGP signature

Re: [PATCH v2] ACPI: Fix acpi_evaluate_object() return value check

[Hanjun Guo]

On 2014-1-17 9:29, Yijing Wang wrote:
> Fix acpi_evaluate_object() return value check,
> shoud acpi_status not int.
> 
> Signed-off-by: Yijing Wang 
> ---
> 
> v1->v2: Add CC to the related subsystem MAINTAINERS.
> 
> ---
>  drivers/gpu/drm/i915/intel_acpi.c  |   13 +++--
>  drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |6 +++---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |   13 +++--
>  drivers/pci/pci-label.c|6 +++---
>  4 files changed, 20 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index dfff090..7ea00e5 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -35,7 +35,7 @@ static int intel_dsm(acpi_handle handle, int func)
>   union acpi_object params[4];
>   union acpi_object *obj;
>   u32 result;
> - int ret = 0;

The 'ret' is removed, but

> + acpi_status status;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -50,8 +50,8 @@ static int intel_dsm(acpi_handle handle, int func)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", , );
> - if (ret) {
> + status = acpi_evaluate_object(handle, "_DSM", , );
> + if (ACPI_FAILURE(status)) {
>   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>   return ret;

you still use it here, so you should -EINVAL or something else here.

>   }
> @@ -141,7 +141,8 @@ static void intel_dsm_platform_mux_info(void)
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *pkg;
> - int i, ret;
> + acpi_status status;
> + int i;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -156,9 +157,9 @@ static void intel_dsm_platform_mux_info(void)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", ,
> + acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", 
> ,
>  );
> - if (ret) {
> + if (ACPI_FAILURE(status)) {
>   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>   goto out;
>   }
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> index 1291204..3920943 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> @@ -114,14 +114,14 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
>   struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
>   union acpi_object *obj;
>   acpi_handle handle;
> - int ret;
> + acpi_status status;
>  
>   handle = ACPI_HANDLE(>pdev->dev);
>   if (!handle)
>   return false;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", , );
> - if (ret) {
> + status = acpi_evaluate_object(handle, "_DSM", , );
> + if (ACPI_FAILURE(status)) {
>   nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
>   return false;
>   }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index ba0183f..6f810f2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *obj;
> - int i, err;
> + acpi_status status;
> + int i;
>   char args_buff[4];
>  
>   input.count = 4;
> @@ -101,8 +102,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   args_buff[i] = (arg >> i * 8) & 0xFF;
>   params[3].buffer.pointer = args_buff;
>  
> - err = acpi_evaluate_object(handle, "_DSM", , );
> - if (err) {
> + status = acpi_evaluate_object(handle, "_DSM", , );
> + if (ACPI_FAILURE(status)) {
>   printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
>   return err;

here too.

>   }
> @@ -134,7 +135,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
> arg, uint32_t *result)
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *obj;
> - int err;
> + acpi_status status;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -148,8 +149,8 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
> arg, uint32_t *result)
>   params[3].type = ACPI_TYPE_INTEGER;
>   params[3].integer.value = arg;
>  
> - err = acpi_evaluate_object(handle, "_DSM", , );
> - if (err) {
> + status = acpi_evaluate_object(handle, "_DSM", , );
> + if (ACPI_FAILURE(status)) {
>   

[Q] Why does kexec use device_shutdown rather than ubind them

[Benjamin Herrenschmidt]

Hi Folks !

Sorry for the semi-random CC list, not sure who owns kexec nowadays. So
we are working on a new crop of power servers for which the bootloader
is going to be using kexec.

As expected, we've been chasing a number of reliability issues mostly
due to drivers not behaving properly, such as leaving devices DMA'ing or
in a state that upsets the new kernel etc...

So far our approach has been to fix the drivers one by one, adding the
shutdown() method when it's missing, etc...

But that lead me to wonder ... why shutdown() in the first place ? The
semantic of shutdown() is that we are going to power the machine off. In
some cases, that method will actively participate in the shutdown,
powering things off, spinning disk down, etc

It doesn't have the semantic of "put the device into a clean state for a
new driver to pick up". It's also rarely implemented.

On the other hand, the remove() routine is almost everywhere, and is
already well understood as needing to leave the device in a clean state,
as it's often used for rmmod (often by the driver developer
him/herself), more likely to be tested in a condition that doesn't
involve having the machine off immediately afterward but on the contrare
in a condition where a new driver can come and try to pick the device
up.

Additionally, remove() is also what KVM does when assigning devices to
guest, ie, the original driver is unbound from the host, and VFIO is
bound in its place.

So we have common purpose with kexec (somewhat) and possibly common (and
better) testing coverage with remove() than with shutdown().

I plan to experiment a bit in our bootloader see if that makes a
difference, maybe doing a first pass of unbind for anything that can be
unbound, and shutdown for the rest.

(I'll probably also sneak it a PCIe hot reset at the end but that's more
platform specific).

Any opinion ?

Cheers,
Ben.
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] oprofile: check whether oprofile perf enabled in op_overflow_handler()

[Weng Meiling]

On 2014/1/17 3:36, Will Deacon wrote:
> On Thu, Jan 16, 2014 at 11:52:45AM +, Robert Richter wrote:
>> (cc'ing Will)
> 
> Thanks Robert,
> 
>> The problem of too low sample periods could be solved on ARM by using
>> perf's interrupt throttling, you might play around with:
>>
>>  /proc/sys/kernel/perf_event_max_sample_rate:10
>>
>> I am not quite sure whether this works esp. for kernel counters and

Try to lower the value of perf_event_max_sample_rate, it works. Testing
the following values:
100 500 1000 5000 1 5

for the last value, the command start to stall.
Just a simple test. :)


>> how userland can be notified about throttling. Throttling could be
>> worth for operf too, not only for the oprofile kernel driver.
>>

>> From a quick look it seems there is also code in x86 that dynamically
>> adjusts the rate which might be worth being implemented for ARM too.
> 
> Are you referring to the perf_sample_event_took callback? If so, that
> certainly looks worth persuing. I'll stick it on my list, thanks!
> 

Thanks Will for doing this.

Thanks
Weng Meiling

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

Re: [RFC PATCH] sched: select_idle_sibling macro optimize

[Mike Galbraith]

On Fri, 2014-01-17 at 10:14 +0800, Alex Shi wrote: 
> On 01/16/2014 09:52 PM, Mike Galbraith wrote:
> > On Thu, 2014-01-16 at 21:13 +0800, Alex Shi wrote: 
> >> Add Mike Galbraith.
> >>
> >> Any one like to give some comments?
> >>
> >> On 01/15/2014 10:23 PM, Alex Shi wrote:
> >>> If the sd domain just has one group, then we must be caught the
> >>>   i == target later, and then goes to deeper level domain.
> >>> So just skip this domain checking to save some instructions.
> >>>
> >>> Signed-off-by: Alex Shi 
> >>> ---
> >>>  kernel/sched/fair.c | 5 +
> >>>  1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >>> index c7395d9..3265fbc 100644
> >>> --- a/kernel/sched/fair.c
> >>> +++ b/kernel/sched/fair.c
> >>> @@ -4196,6 +4196,11 @@ static int select_idle_sibling(struct task_struct 
> >>> *p, int target)
> >>>   sd = rcu_dereference(per_cpu(sd_llc, target));
> >>>   for_each_lower_domain(sd) {
> >>>   sg = sd->groups;
> >>> +
> >>> + /* skip single group domain */
> >>> + if (sg == sg->next)
> >>> + continue;
> > 
> > When is that gonna happen?
> 
> I had seen this in a Intel platform, you may have both CPU domain and MC
> domain layer, because the domain flag is different, then they can not be
> merged. and then the CPU domain just has one group.

But sd starts at MC.

-Mike

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in
drivers/clocksource/cadence_ttc_timer.c between commit c1dcc927dae0
("clocksource: cadence_ttc: Fix mutex taken inside interrupt context")
from Linus' tree and commit dfded00902d7 ("clocksource:
cadence_ttc_timer: Switch to sched_clock_register()") from the tip tree.

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

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

diff --cc drivers/clocksource/cadence_ttc_timer.c
index a92350b55d32,8c7382bf260c..
--- a/drivers/clocksource/cadence_ttc_timer.c
+++ b/drivers/clocksource/cadence_ttc_timer.c
@@@ -308,7 -306,8 +308,8 @@@ static void __init ttc_setup_clocksourc
}
  
ttc_sched_clock_val_reg = base + TTC_COUNT_VAL_OFFSET;
-   setup_sched_clock(ttc_sched_clock_read, 16, ttccs->ttc.freq / PRESCALE);
+   sched_clock_register(ttc_sched_clock_read, 16,
 -  clk_get_rate(ttccs->ttc.clk) / PRESCALE);
++   ttccs->ttc.freq / PRESCALE);
  }
  
  static int ttc_rate_change_clockevent_cb(struct notifier_block *nb,


pgpehNCpOYmWJ.pgp
Description: PGP signature

Re: Kernel stack overflows due to "powerpc: Remove ksp_limit on ppc64" with v3.13-rc8 on ppc32 (P2020)

[Kevin Hao]

On Fri, Jan 17, 2014 at 01:58:10PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-01-17 at 10:20 +0800, Kevin Hao wrote:
> > On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:
> > > Hi all,
> > > 
> > > I am getting kernel stack overflows with v3.13-rc8 on a system with P2020 
> > > CPU.
> > > The kernel is patched for the target, but I don't think that is related.
> > > Stack overflows are in different areas, but always in calls from 
> > > __do_softirq.
> > > 
> > > Crashes happen reliably either during boot or if I put any kind of load
> > > onto the system.
> > 
> > How about the following fix:
> 
> Wow. I've been staring at that code for 15mn this morning and didn't
> spot it ! Nice catch :-)
> 
> Any chance you can send a version of that patch that adds the C
> prototype of the function in a comment right before the assembly ?

Will do. The patch is coming soon.

Thanks,
Kevin


pgpS225TwyTMg.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Rob,

Today's linux-next merge of the dt-rh tree got a conflict in
Documentation/devicetree/bindings/vendor-prefixes.txt between commits
70e123373c05 ("rtc: Add support for Intersil ISL12057 I2C RTC chip") from
the arm-soc tree and 53d6b36020c7 ("of: Add vendor prefix for LG
Corporation") from Linus' tree and commit 7e73700ce785 ("of: add vendor
prefix for Ka-Ro electronics GmbH") from the dt-rh 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/vendor-prefixes.txt
index d92c88f551f9,d98fa9a6279c..
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@@ -42,8 -38,7 +42,9 @@@ ibm   International Business Machines (IB
  idt   Integrated Device Technologies, Inc.
  img   Imagination Technologies Ltd.
  intercontrol  Inter Control Group
 +isl   Intersil
+ karo  Ka-Ro electronics GmbH
 +lgLG Corporation
  linux Linux-specific binding
  lsi   LSI Corp. (LSI Logic)
  marvell   Marvell Technology Group Ltd.


pgpnqqLGWPoDs.pgp
Description: PGP signature

Re: Kernel stack overflows due to "powerpc: Remove ksp_limit on ppc64" with v3.13-rc8 on ppc32 (P2020)

[Guenter Roeck]

On 01/16/2014 06:58 PM, Benjamin Herrenschmidt wrote:

On Fri, 2014-01-17 at 10:20 +0800, Kevin Hao wrote:

On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:

Hi all,

I am getting kernel stack overflows with v3.13-rc8 on a system with P2020 CPU.
The kernel is patched for the target, but I don't think that is related.
Stack overflows are in different areas, but always in calls from __do_softirq.

Crashes happen reliably either during boot or if I put any kind of load
onto the system.


How about the following fix:


Wow. I've been staring at that code for 15mn this morning and didn't
spot it ! Nice catch :-)


Yes, great catch! That fixes the problem.

Tested-by: Guenter Roeck 

I assume you or Kevin will take it from there ?

Thanks,
Guenter

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

Re: [RFC PATCH] sched: select_idle_sibling macro optimize

[Michael wang]

On 01/17/2014 10:14 AM, Alex Shi wrote:
[snip]
>>
>> When is that gonna happen?
> 
> I had seen this in a Intel platform, you may have both CPU domain and MC
> domain layer, because the domain flag is different, then they can not be
> merged. and then the CPU domain just has one group.

CPU and MC are different domains, isn't it?

General should like:

CPU cpu0cpu1
MC  core0   core1   core0   core1
SMT cpu 0   cpu 1   cpu 2   cpu 3   cpu 4   cpu 5   cpu 6   cpu 7

So for cpu0:

CPU sg0:cpu0,1,2,3  sg1:cpu4,5,6,7
MC  sg0:cpu0,1  sg1:cpu2,3
SMT sg0:cpu0sg1:cpu1

If one domain only have one group, that's sounds really a weird topology...

Regards,
Michael Wang

>>
>> -Mike
>>
>>
> 
> 

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

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the devicetree tree got a conflict in
arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts between commit
6b6430e82331 ("ARM: orion5x: Fix typo in device_type property of phy
node") from the arm-soc tree and commit 40aad3c1a9b6 ("dt/bindings:
Remove all references to device_type "ethernet-phy"") from the devicetree
tree.

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

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


pgpcRG_IgnDgL.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the devicetree tree got a conflict in
arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts between commit
261e7735d0ed ("ARM: kirkwood: NETGEAR ReadyNAS Duo v2 .dts cleanup") from
the arm-soc tree and commit 40aad3c1a9b6 ("dt/bindings: Remove all
references to device_type "ethernet-phy"") from the devicetree 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 arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
index 4d2a8db9ab77,00c0669b1b8c..
--- a/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
+++ b/arch/arm/boot/dts/kirkwood-netgear_readynas_duo_v2.dts
@@@ -241,8 -210,7 +241,7 @@@
   {
status = "okay";
  
 -  ethphy0: ethernet-phy@0 {
 +  ethphy0: ethernet-phy@0 { /* Marvell 88E1318 */
-   device_type = "ethernet-phy";
reg = <0>;
};
  };


pgp3vSJ5wLaDI.pgp
Description: PGP signature

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

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the devicetree tree got a conflict in
arch/arm/boot/dts/dove.dtsi between commits 40aad3c1a9b6 ("dt/bindings:
Remove all references to device_type "ethernet-phy"") and b31b32119abe
("ARM: dove: sort DT nodes by address") from the devicetree tree and
commit 351291754df3 ("dt/bindings: remove device_type "network"
references") from the devicetree 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 arch/arm/boot/dts/dove.dtsi
index 8de1031233ae,39ffabe04cc5..
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@@ -170,224 -192,34 +170,222 @@@
status = "disabled";
};
  
 -  gpio0: gpio-ctrl@d0400 {
 -  compatible = "marvell,orion-gpio";
 -  #gpio-cells = <2>;
 -  gpio-controller;
 -  reg = <0xd0400 0x20>;
 -  ngpios = <32>;
 +  spi1: spi-ctrl@14600 {
 +  compatible = "marvell,orion-spi";
 +  #address-cells = <1>;
 +  #size-cells = <0>;
 +  cell-index = <1>;
 +  interrupts = <5>;
 +  reg = <0x14600 0x28>;
 +  clocks = <_clk 0>;
 +  status = "disabled";
 +  };
 +
 +  mbusc: mbus-ctrl@2 {
 +  compatible = "marvell,mbus-controller";
 +  reg = <0x2 0x80>, <0x800100 0x8>;
 +  };
 +
 +  bridge_intc: bridge-interrupt-ctrl@20110 {
 +  compatible = "marvell,orion-bridge-intc";
interrupt-controller;
 -  #interrupt-cells = <2>;
 -  interrupts = <12>, <13>, <14>, <60>;
 +  #interrupt-cells = <1>;
 +  reg = <0x20110 0x8>;
 +  interrupts = <0>;
 +  marvell,#interrupts = <5>;
};
  
 -  gpio1: gpio-ctrl@d0420 {
 -  compatible = "marvell,orion-gpio";
 -  #gpio-cells = <2>;
 -  gpio-controller;
 -  reg = <0xd0420 0x20>;
 -  ngpios = <32>;
 +  intc: main-interrupt-ctrl@20200 {
 +  compatible = "marvell,orion-intc";
interrupt-controller;
 -  #interrupt-cells = <2>;
 -  interrupts = <61>;
 +  #interrupt-cells = <1>;
 +  reg = <0x20200 0x10>, <0x20210 0x10>;
};
  
 -  gpio2: gpio-ctrl@e8400 {
 -  compatible = "marvell,orion-gpio";
 -  #gpio-cells = <2>;
 -  gpio-controller;
 -  reg = <0xe8400 0x0c>;
 -  ngpios = <8>;
 +  timer: timer@20300 {
 +  compatible = "marvell,orion-timer";
 +  reg = <0x20300 0x20>;
 +  interrupt-parent = <_intc>;
 +  interrupts = <1>, <2>;
 +  clocks = <_clk 0>;
 +  };
 +
 +  crypto: crypto-engine@3 {
 +  compatible = "marvell,orion-crypto";
 +  reg = <0x3 0x1>,
 +<0xe000 0x800>;
 +  reg-names = "regs", "sram";
 +  interrupts = <31>;
 +  clocks = <_clk 15>;
 +  status = "okay";
 +  };
 +
 +  ehci0: usb-host@5 {
 +  compatible = "marvell,orion-ehci";
 +  reg = <0x5 0x1000>;
 +  interrupts = <24>;
 +  clocks = <_clk 0>;
 +  status = "okay";
 +  };
 +
 +  ehci1: usb-host@51000 {
 +  compatible = "marvell,orion-ehci";
 +  reg = <0x51000 0x1000>;
 +  interrupts = <25>;
 +  clocks = <_clk 1>;
 +  

[PATCH 1/2] USB: at91: fix the number of endpoint parameter

[Bo Shen]

In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
is only 7. So, fix it for sama5d3 SoC using the udc->num_ep.

Signed-off-by: Bo Shen 
---

 drivers/usb/gadget/atmel_usba_udc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/atmel_usba_udc.c 
b/drivers/usb/gadget/atmel_usba_udc.c
index 2cb52e0..7e67a81 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (ep_status) {
int i;
 
-   for (i = 0; i < USBA_NR_ENDPOINTS; i++)
+   for (i = 0; i < udc->num_ep; i++)
if (ep_status & (1 << i)) {
if (ep_is_control(>usba_ep[i]))
usba_control_irq(udc, >usba_ep[i]);
-- 
1.8.5.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/

[PATCH 2/2] USB: at91: using USBA_NR_DMAS for DMA channels

[Bo Shen]

When the SoC is earlier than sama5d3 SoC, which have the same number
endpoints and DMAs. However for sama5d3 SoC, it has different number
for endpoints and DMAs. So, define USBA_NR_DMAs for DMA channels

Signed-off-by: Bo Shen 
---

 drivers/usb/gadget/atmel_usba_udc.c | 2 +-
 drivers/usb/gadget/atmel_usba_udc.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/atmel_usba_udc.c 
b/drivers/usb/gadget/atmel_usba_udc.c
index 7e67a81..5cded1c 100644
--- a/drivers/usb/gadget/atmel_usba_udc.c
+++ b/drivers/usb/gadget/atmel_usba_udc.c
@@ -1661,7 +1661,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (dma_status) {
int i;
 
-   for (i = 1; i < USBA_NR_ENDPOINTS; i++)
+   for (i = 1; i < USBA_NR_DMAS; i++)
if (dma_status & (1 << i))
usba_dma_irq(udc, >usba_ep[i]);
}
diff --git a/drivers/usb/gadget/atmel_usba_udc.h 
b/drivers/usb/gadget/atmel_usba_udc.h
index 2922db5..a70706e 100644
--- a/drivers/usb/gadget/atmel_usba_udc.h
+++ b/drivers/usb/gadget/atmel_usba_udc.h
@@ -210,7 +210,7 @@
 #define USBA_FIFO_BASE(x)  ((x) << 16)
 
 /* Synth parameters */
-#define USBA_NR_ENDPOINTS  7
+#define USBA_NR_DMAS   7
 
 #define EP0_FIFO_SIZE  64
 #define EP0_EPT_SIZE   USBA_EPT_SIZE_64
-- 
1.8.5.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: Kernel stack overflows due to "powerpc: Remove ksp_limit on ppc64" with v3.13-rc8 on ppc32 (P2020)

[Benjamin Herrenschmidt]

On Fri, 2014-01-17 at 10:20 +0800, Kevin Hao wrote:
> On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:
> > Hi all,
> > 
> > I am getting kernel stack overflows with v3.13-rc8 on a system with P2020 
> > CPU.
> > The kernel is patched for the target, but I don't think that is related.
> > Stack overflows are in different areas, but always in calls from 
> > __do_softirq.
> > 
> > Crashes happen reliably either during boot or if I put any kind of load
> > onto the system.
> 
> How about the following fix:

Wow. I've been staring at that code for 15mn this morning and didn't
spot it ! Nice catch :-)

Any chance you can send a version of that patch that adds the C
prototype of the function in a comment right before the assembly ?

We should generalize that practice...

Cheers,
Ben.
 
> diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
> index e47d268727a4..52fffe5616b4 100644
> --- a/arch/powerpc/kernel/misc_32.S
> +++ b/arch/powerpc/kernel/misc_32.S
> @@ -61,7 +61,7 @@ _GLOBAL(call_do_irq)
>   mflrr0
>   stw r0,4(r1)
>   lwz r10,THREAD+KSP_LIMIT(r2)
> - addir11,r3,THREAD_INFO_GAP
> + addir11,r4,THREAD_INFO_GAP
>   stwur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
>   mr  r1,r4
>   stw r10,8(r1)
> 
> Thanks,
> Kevin
> > 
> > Example:
> > 
> > Kernel stack overflow in process eb3e5a00, r1=eb79df90
> > CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> > task: eb3e5a00 ti: c0616000 task.ti: ef44
> > NIP: c003a420 LR: c003a410 CTR: c0017518
> > REGS: eb79dee0 TRAP: 0901   Not tainted (3.13.0-rc8-juniper-00146-g19eca00)
> > MSR: 00029000   CR: 24008444  XER: 
> > GPR00: c003a410 eb79df90 eb3e5a00  eb05d900 0001 65d87646 
> > 
> > GPR08:  020b8000   44008442
> > NIP [c003a420] __do_softirq+0x94/0x1ec
> > LR [c003a410] __do_softirq+0x84/0x1ec
> > Call Trace:
> > [eb79df90] [c003a410] __do_softirq+0x84/0x1ec (unreliable)
> > [eb79dfe0] [c003a970] irq_exit+0xbc/0xc8
> > [eb79dff0] [c000cc1c] call_do_irq+0x24/0x3c
> > [ef441f20] [c00046a8] do_IRQ+0x8c/0xf8
> > [ef441f40] [c000e7f4] ret_from_except+0x0/0x18
> > --- Exception: 501 at 0xfcda524
> > LR = 0x10024900
> > Instruction dump:
> > 7c781b78 3b4a 3a73b040 543c0024 3a80 3b3913a0 7ef5bb78 48201bf9
> > 5463103a 7d3b182e 7e89b92e 7c008146 <3ba0> 7e7e9b78 4814 57fff87f
> > Kernel panic - not syncing: kernel stack overflow
> > CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> > Call Trace:
> > Rebooting in 180 seconds..
> > 
> > Reverting the following commit fixes the problem.
> > 
> > cbc9565ee8 "powerpc: Remove ksp_limit on ppc64"
> > 
> > Should I submit a patch reverting this commit, or is there a better way to 
> > fix
> > the problem on short notice (given that 3.13 is close) ?
> > 
> > Thanks,
> > Guenter
> > ___
> > Linuxppc-dev mailing list
> > linuxppc-...@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support

[Jingchang Lu]

> -Original Message-
> From: Mark Rutland [mailto:mark.rutl...@arm.com]
> Sent: Thursday, January 16, 2014 7:12 PM
> To: Lu Jingchang-B35083
> Cc: vinod.k...@intel.com; dan.j.willi...@intel.com; a...@arndb.de;
> shawn@linaro.org; Pawel Moll; swar...@wwwdotorg.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; Wang Huan-B18965
> Subject: Re: [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support
> 
> On Thu, Jan 16, 2014 at 02:30:00AM +, Jingchang Lu wrote:
> > Add Freescale enhanced direct memory(eDMA) controller support.
> > This module can be found on Vybrid and LS-1 SoCs.
> >
> > Signed-off-by: Alison Wang 
> > Signed-off-by: Jingchang Lu 
> > ---
> > changes in v9:
> >  define endian's operating functions instead of macro definition.
> >  remove the filter function, using dma_get_slave_channel instead.
> >
> > changes in v8:
> >  change the edma driver according eDMA dts change.
> >  add big-endian and little-endian handling.
> >
> >  no changes in v4 ~ v7.
> >
> >  changes in v3:
> >   add vf610 edma dt-bindings namespace with prefix VF610_*.
> >
> >  changes in v2:
> >   using generic dma-channels property instead of fsl,dma-channels.
> >
> >
> >  Documentation/devicetree/bindings/dma/fsl-edma.txt |  66 ++
> >  drivers/dma/Kconfig|  10 +
> >  drivers/dma/Makefile   |   1 +
> >  drivers/dma/fsl-edma.c | 957
> +
> >  4 files changed, 1034 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/dma/fsl-edma.txt
> >  create mode 100644 drivers/dma/fsl-edma.c
> >
> > diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt
> b/Documentation/devicetree/bindings/dma/fsl-edma.txt
> > new file mode 100644
> > index 000..5a5fb61
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt
> > @@ -0,0 +1,66 @@
> > +* Freescale enhanced Direct Memory Access(eDMA) Controller
> > +
> > +  The eDMA channels have multiplex capability by programmble memory-
> mapped
> > +registers. channels are split into two groups, called DMAMUX0 and
> DMAMUX1,
> > +specific DMA request source can only be multiplexed by any channel of
> certain
> > +group, DMAMUX0 or DMAMUX1, but not both.
> > +
> > +* eDMA Controller
> > +Required properties:
> > +- compatible :
> > +   - "fsl,vf610-edma" for eDMA used similar to that on Vybrid
> vf610 SoC
> > +- reg : Specifies base physical address(s) and size of the eDMA
> registers.
> > +   The 1st region is eDMA control register's address and size.
> > +   The 2nd and the 3rd regions are programmable channel
> multiplexing
> > +   control register's address and size.
> > +- interrupts : Should contain eDMA interrupt
> > +- interrupt-names : Should be "edma-tx" for transmission interrupt and
> > +   "edma-err" for error interrupt
> 
> The description of interrupts and interrupt-names is a bit odd. How
> about:
> 
> - interrupts: a list of interrupt-specifiers, one for each entry in
>   interrupt-names.
> 
> - interrupt names: should contain:
>   * "edma-tx" - the transmission interrupt.
>   * "edma-err" - the error interrupt.
> 
> > +- #dma-cells : Must be <2>.
> > +   The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for
> DMAMUX1).
> > +   Specific request source can only be multiplexed by specific
> channels
> > +   group called DMAMUX.
> > +   The 2nd cell specifies the request source(slot) ID.
> > +   See the SoC's reference manual for all the supported request
> sources.
> > +- dma-channels : Number of channels supported by the controller
> > +- clock-names : The channel group block clock names
> > +- clocks : eDMA module clock
> 
> The set of expected clock-names should be well defined, and the example
> has more than one clock..
> 
> This should be something like:
> 
> - clocks: a list of phandle + clock-specifier pairs, one for each entry
>   in clock-names.
> 
> - clock-names: a list of clock names. Should contain:
>   * "dmamux0" - 
>   * "dmamux1" - 
Your suggestion for the interrupt and clock binding is much clearer, I will 
take this, thanks.
> 
> > +
> > +
> > +Examples:
> > +
> > +edma0: dma-controller@40018000 {
> > +   #dma-cells = <2>;
> > +   compatible = "fsl,vf610-edma";
> > +   reg = <0x40018000 0x2000>,
> > +   <0x40024000 0x1000>,
> > +   <0x40025000 0x1000>;
> > +   interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
> > +   <0 9 IRQ_TYPE_LEVEL_HIGH>;
> > +   interrupt-names = "edma-tx", "edma-err";
> > +   dma-channels = <32>;
> > +   clock-names = "dmamux0", "dmamux1";
> > +   clocks = < VF610_CLK_DMAMUX0>,
> > +   < VF610_CLK_DMAMUX1>;
> > +};
> 
> [...]
> 
> > +   for (i = 0; i < DMAMUX_NR; i++) {
> > +   char clkname[32];
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 1 +
> i);
> > 

Re: [RFC PATCH] sched: find the latest idle cpu

[Nicolas Pitre]

On Thu, 16 Jan 2014, Daniel Lezcano wrote:

> The question raised when I looked closely how to fully integrate cpuidle with
> the scheduler; in particular, the idle time.
> The scheduler idle time is not the same than the cpuidle idle time.
> A cpu can be idle for the scheduler 1s but it could be interrupted several
> times by an interrupt thus the idle time for cpuidle is different. But anyway
> ...

The idle task would run each time an interrupt has been serviced, either 
to yield to a newly awaken task or to put the CPU back to sleep.  In the 
later case the idle task may simply do extra idleness accounting 
locally.  If the former case happens most of the time then the scheduler 
idle time would be most representative already.

And if threaded IRQs are used then the the scheduler idle time would be 
the same as cpuidle's.

> > We need the idle task, since we need to DO something to go idle, the
> > scheduler needs to pick a task to go do that something. This is the idle
> > task.
> > 
> > You cannot get rid of that.
> > 
> > In fact, the 'doing' of that task is running much of the cpuidle code,
> > so by getting rid of it, there's nobody left to execute that code.
> > 
> > Also, since its already running that cpuidle stuff, integrating it more
> > closely with the scheduler will not in fact change much, it will still
> > run it.
> > 
> > Could of course be I'm not reading what you meant to write, if so, do
> > try again ;-)
> 
> Well, I wanted to have a clarification of what was your feeling about how to
> integrate cpuidle in the scheduler. If removing the idle task (in the future)
> does not make sense for you, I will not insist. Let's see how the code evolves
> by integrating cpuidle and we will figure out what will be the impact on the
> idle task.

I think we should be able to get rid of architecture specific idle 
loops.  The idle loop could be moved close to the scheduler and 
architectures would only need to provide a default CPU halt method for 
when there is nothing else registered with the cpuidle subsystem.


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

Questionnaire: Valuation of contributions to FLOSS

[Marcel Kühn]

Hello everybody,

I just wanna send out a quick reminder: I'm doing a study on the 
valuation of contributions to FLOSS projects and I'd really appreciate 
your participation. You can find it here:


srv.bplaced.net

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

Re: [PATCH net-next v2 3/3] reciprocal_divide: correction/update of the algorithm

[Eric Dumazet]

On Fri, 2014-01-17 at 01:28 +0100, Hannes Frederic Sowa wrote:
> Jakub Zawadzki noticed that some divisions by reciprocal_divide()
> were not correct [1][2], which he could also show with BPF code after
> divisions are transformed into reciprocal_value() for runtime invariant
> which can be passed to reciprocal_divide() later on; reverse in BPF dump
> ended up with a different, off-by-one K.
> 
> This has been fixed by Eric Dumazet in commit aee636c4809fa5 ("bpf: do not
> use reciprocal divide"). This follow-up patch improves reciprocal_value()
> and reciprocal_divide() to work in all cases, so future use is safe.
> 
> Known problems with the old implementation were that division by 1 always
> returned 0 and some off-by-ones when the dividend and divisor where
> very large.  This seemed to not be problematic with its current users
> in networking, mm/slab.c and lib/flex_array.c, but future users would
> need to check for this specifically and it might not be obvious at first.
> 
> In order to fix that, we propose an extension from the original
> implementation from commit 6a2d7a955d8d resp. [3][4], by using
> the algorithm proposed in "Division by Invariant Integers Using
> Multiplication" [5], Torbjörn Granlund and Peter L. Montgomery, that is,
> pseudocode for q = n/d where q,n,d is in u32 universe:
> 
> 1) Initialization:
> 
>   int l = ceil(log_2 d)
>   uword m' = floor((1<<32)*((1<   int sh_1 = min(l,1)
>   int sh_2 = max(l-1,0)
> 
> 2) For q = n/d, all uword:
> 
>   uword t = (n*m')>>32
>   q = (t+((n-t)>>sh_1))>>sh_2
> 
> The assembler implementation from Agner Fog [6] also helped a lot
> while implementing. We have tested the implementation on x86_64,
> ppc64, i686, s390x; on x86_64/haswell we're still half the latency
> compared to normal divide.
> 
> Joint work with Daniel Borkmann.
> 
>   [1] http://www.wireshark.org/~darkjames/reciprocal-buggy.c
>   [2] http://www.wireshark.org/~darkjames/set-and-dump-filter-k-bug.c
>   [3] https://gmplib.org/~tege/division-paper.pdf
>   [4] http://homepage.cs.uiowa.edu/~jones/bcd/divide.html
>   [5] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.1.2556
>   [6] http://www.agner.org/optimize/asmlib.zip
> 
> Fixes: 6a2d7a955d8d ("SLAB: use a multiply instead of a divide in 
> obj_to_index()")


I already demonstrated this slab patch was fine.

The current algo works well (no off-by-one error) when the dividend is
a multiple of the divisor.

You are adding extra overhead, while we know its not necessary.

By using "Fixes: ... " you are asking a backport to stable branches,
which seems really silly in this case, especially with this monolithic
patch changing 12 files in different subsystems.

If you believe flex_array has a problem, please fix flex_array only,
by a small patch (Maybe a revert ?)

Then, introduce your new helpers if we really think they are needed.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support

[Jingchang Lu]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, January 16, 2014 7:03 PM
> To: Lu Jingchang-B35083
> Cc: vinod.k...@intel.com; dan.j.willi...@intel.com; shawn@linaro.org;
> pawel.m...@arm.com; mark.rutl...@arm.com; swar...@wwwdotorg.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; Wang Huan-B18965
> Subject: Re: [PATCHv9 2/2] dma: Add Freescale eDMA engine driver support
> 
> On Thursday 16 January 2014, Jingchang Lu wrote:
> > Add Freescale enhanced direct memory(eDMA) controller support.
> > This module can be found on Vybrid and LS-1 SoCs.
> >
> > Signed-off-by: Alison Wang 
> > Signed-off-by: Jingchang Lu 
> 
> Very nice! All my previous comments have been addressed, so
> 
> Acked-by: Arnd Bergmann 
> 
> One small comment still:
> 
> > +
> > +static DEFINE_MUTEX(fsl_edma_mutex);
> > +
> 
> I think this mutex should be part of struct fsl_edma_engine, not global.
Yes, it should be for each edma controller, I will define it in struct 
fsl_edma_engine. Thanks.


Best Regards,
Jingchang

Re: Kernel stack overflows due to "powerpc: Remove ksp_limit on ppc64" with v3.13-rc8 on ppc32 (P2020)

[Kevin Hao]

On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:
> Hi all,
> 
> I am getting kernel stack overflows with v3.13-rc8 on a system with P2020 CPU.
> The kernel is patched for the target, but I don't think that is related.
> Stack overflows are in different areas, but always in calls from __do_softirq.
> 
> Crashes happen reliably either during boot or if I put any kind of load
> onto the system.

How about the following fix:

diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index e47d268727a4..52fffe5616b4 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -61,7 +61,7 @@ _GLOBAL(call_do_irq)
mflrr0
stw r0,4(r1)
lwz r10,THREAD+KSP_LIMIT(r2)
-   addir11,r3,THREAD_INFO_GAP
+   addir11,r4,THREAD_INFO_GAP
stwur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
mr  r1,r4
stw r10,8(r1)

Thanks,
Kevin
> 
> Example:
> 
> Kernel stack overflow in process eb3e5a00, r1=eb79df90
> CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> task: eb3e5a00 ti: c0616000 task.ti: ef44
> NIP: c003a420 LR: c003a410 CTR: c0017518
> REGS: eb79dee0 TRAP: 0901   Not tainted (3.13.0-rc8-juniper-00146-g19eca00)
> MSR: 00029000   CR: 24008444  XER: 
> GPR00: c003a410 eb79df90 eb3e5a00  eb05d900 0001 65d87646 
> GPR08:  020b8000   44008442
> NIP [c003a420] __do_softirq+0x94/0x1ec
> LR [c003a410] __do_softirq+0x84/0x1ec
> Call Trace:
> [eb79df90] [c003a410] __do_softirq+0x84/0x1ec (unreliable)
> [eb79dfe0] [c003a970] irq_exit+0xbc/0xc8
> [eb79dff0] [c000cc1c] call_do_irq+0x24/0x3c
> [ef441f20] [c00046a8] do_IRQ+0x8c/0xf8
> [ef441f40] [c000e7f4] ret_from_except+0x0/0x18
> --- Exception: 501 at 0xfcda524
> LR = 0x10024900
> Instruction dump:
> 7c781b78 3b4a 3a73b040 543c0024 3a80 3b3913a0 7ef5bb78 48201bf9
> 5463103a 7d3b182e 7e89b92e 7c008146 <3ba0> 7e7e9b78 4814 57fff87f
> Kernel panic - not syncing: kernel stack overflow
> CPU: 0 PID: 2838 Comm: ssh Not tainted 3.13.0-rc8-juniper-00146-g19eca00 #4
> Call Trace:
> Rebooting in 180 seconds..
> 
> Reverting the following commit fixes the problem.
> 
> cbc9565ee8 "powerpc: Remove ksp_limit on ppc64"
> 
> Should I submit a patch reverting this commit, or is there a better way to fix
> the problem on short notice (given that 3.13 is close) ?
> 
> Thanks,
> Guenter
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


pgpehVQKEomJO.pgp
Description: PGP signature

Re: [RFC PATCH] sched: select_idle_sibling macro optimize

[Alex Shi]

On 01/16/2014 09:52 PM, Mike Galbraith wrote:
> On Thu, 2014-01-16 at 21:13 +0800, Alex Shi wrote: 
>> Add Mike Galbraith.
>>
>> Any one like to give some comments?
>>
>> On 01/15/2014 10:23 PM, Alex Shi wrote:
>>> If the sd domain just has one group, then we must be caught the
>>> i == target later, and then goes to deeper level domain.
>>> So just skip this domain checking to save some instructions.
>>>
>>> Signed-off-by: Alex Shi 
>>> ---
>>>  kernel/sched/fair.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index c7395d9..3265fbc 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -4196,6 +4196,11 @@ static int select_idle_sibling(struct task_struct 
>>> *p, int target)
>>> sd = rcu_dereference(per_cpu(sd_llc, target));
>>> for_each_lower_domain(sd) {
>>> sg = sd->groups;
>>> +
>>> +   /* skip single group domain */
>>> +   if (sg == sg->next)
>>> +   continue;
> 
> When is that gonna happen?

I had seen this in a Intel platform, you may have both CPU domain and MC
domain layer, because the domain flag is different, then they can not be
merged. and then the CPU domain just has one group.
> 
> -Mike
> 
> 


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

[PATCH 3/3] ACPI: Introduce map_gic_id() to get apic id from MADT or _MAT method

[Hanjun Guo]

Get apic id from MADT or _MAT method is not implemented on arm/arm64,
and ACPI 5.0 introduces GIC Structure for it, so this patch introduces
map_gic_id() to get apic id followed the ACPI 5.0 spec.

Signed-off-by: Hanjun Guo 
---
 drivers/acpi/processor_core.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index cd7b5fe..165eac7 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -90,6 +90,27 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
return 1;
 }
 
+static int map_gic_id(struct acpi_subtable_header *entry,
+   int device_declaration, u32 acpi_id, int *apic_id)
+{
+   struct acpi_madt_generic_interrupt *gic =
+   (struct acpi_madt_generic_interrupt *)entry;
+
+   if (!(gic->flags & ACPI_MADT_ENABLED))
+   return 0;
+
+   /* In the GIC interrupt model, logical processors are
+* required to have a Processor Device object in the DSDT,
+* so we should check device_declaration here
+*/
+   if (device_declaration && (gic->uid == acpi_id)) {
+   *apic_id = gic->gic_id;
+   return 1;
+   }
+
+   return 0;
+}
+
 static int map_madt_entry(int type, u32 acpi_id)
 {
unsigned long madt_end, entry;
@@ -125,6 +146,9 @@ static int map_madt_entry(int type, u32 acpi_id)
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
if (map_lsapic_id(header, type, acpi_id, _id))
break;
+   } else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+   if (map_gic_id(header, type, acpi_id, _id))
+   break;
}
entry += header->length;
}
@@ -155,6 +179,8 @@ static int map_mat_entry(acpi_handle handle, int type, u32 
acpi_id)
map_lapic_id(header, acpi_id, _id);
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
map_lsapic_id(header, type, acpi_id, _id);
+   } else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+   map_gic_id(header, type, acpi_id, _id);
}
 
 exit:
-- 
1.8.2.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/

[PATCH 2/3] ACPI / processor_core: Rework _PDC related stuff to make it more arch-independent

[Hanjun Guo]

_PDC related stuff in processor_core.c is little bit X86/IA64 dependent,
rework the code to make it more arch-independent, no functional change
in this patch.

The return value of acpi_processor_eval_pdc() should be 'acpi_status' but
defined as 'int', fix it too.

Signed-off-by: Hanjun Guo 
Signed-off-by: Graeme Gregory 
---
 arch/ia64/include/asm/acpi.h  |  5 +
 arch/ia64/kernel/acpi.c   | 17 +
 arch/x86/include/asm/acpi.h   | 19 +--
 arch/x86/kernel/acpi/cstate.c | 31 +++
 drivers/acpi/processor_core.c | 21 ++---
 5 files changed, 52 insertions(+), 41 deletions(-)

diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
index faa1bf0..3348d07 100644
--- a/arch/ia64/include/asm/acpi.h
+++ b/arch/ia64/include/asm/acpi.h
@@ -154,10 +154,7 @@ extern int __initdata nid_to_pxm_map[MAX_NUMNODES];
 #endif
 
 static inline bool arch_has_acpi_pdc(void) { return true; }
-static inline void arch_acpi_set_pdc_bits(u32 *buf)
-{
-   buf[2] |= ACPI_PDC_EST_CAPABILITY_SMP;
-}
+extern void arch_acpi_set_pdc_bits(u32 *buf);
 
 #define acpi_unlazy_tlb(x)
 
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index 59d52e3..d126f15 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -1018,3 +1018,20 @@ EXPORT_SYMBOL(acpi_unregister_ioapic);
  * TBD when when IA64 starts to support suspend...
  */
 int acpi_suspend_lowlevel(void) { return 0; }
+
+void arch_acpi_set_pdc_bits(u32 *buf)
+{
+   /* Enable coordination with firmware's _TSD info */
+   buf[2] |= ACPI_PDC_SMP_T_SWCOORD;
+   if (boot_option_idle_override == IDLE_NOMWAIT) {
+   /*
+* If mwait is disabled for CPU C-states, the C2C3_FFH access
+* mode will be disabled in the parameter of _PDC object.
+* Of course C1_FFH access mode will also be disabled.
+*/
+   buf[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
+
+   }
+
+   buf[2] |= ACPI_PDC_EST_CAPABILITY_SMP;
+}
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index c8c1e70..e9f71bc 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -147,24 +147,7 @@ static inline bool arch_has_acpi_pdc(void)
c->x86_vendor == X86_VENDOR_CENTAUR);
 }
 
-static inline void arch_acpi_set_pdc_bits(u32 *buf)
-{
-   struct cpuinfo_x86 *c = _data(0);
-
-   buf[2] |= ACPI_PDC_C_CAPABILITY_SMP;
-
-   if (cpu_has(c, X86_FEATURE_EST))
-   buf[2] |= ACPI_PDC_EST_CAPABILITY_SWSMP;
-
-   if (cpu_has(c, X86_FEATURE_ACPI))
-   buf[2] |= ACPI_PDC_T_FFH;
-
-   /*
-* If mwait/monitor is unsupported, C2/C3_FFH will be disabled
-*/
-   if (!cpu_has(c, X86_FEATURE_MWAIT))
-   buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
-}
+extern void arch_acpi_set_pdc_bits(u32 *buf);
 
 #else /* !CONFIG_ACPI */
 
diff --git a/arch/x86/kernel/acpi/cstate.c b/arch/x86/kernel/acpi/cstate.c
index d2b7f27..b132748 100644
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -16,6 +16,37 @@
 #include 
 #include 
 
+void arch_acpi_set_pdc_bits(u32 *buf)
+{
+   struct cpuinfo_x86 *c = _data(0);
+
+   /* Enable coordination with firmware's _TSD info */
+   buf[2] |= ACPI_PDC_SMP_T_SWCOORD;
+   if (boot_option_idle_override == IDLE_NOMWAIT) {
+   /*
+* If mwait is disabled for CPU C-states, the C2C3_FFH access
+* mode will be disabled in the parameter of _PDC object.
+* Of course C1_FFH access mode will also be disabled.
+*/
+   buf[2] &= ~(ACPI_PDC_C_C2C3_FFH | ACPI_PDC_C_C1_FFH);
+
+   }
+
+   buf[2] |= ACPI_PDC_C_CAPABILITY_SMP;
+
+   if (cpu_has(c, X86_FEATURE_EST))
+   buf[2] |= ACPI_PDC_EST_CAPABILITY_SWSMP;
+
+   if (cpu_has(c, X86_FEATURE_ACPI))
+   buf[2] |= ACPI_PDC_T_FFH;
+
+   /*
+* If mwait/monitor is unsupported, C2/C3_FFH will be disabled
+*/
+   if (!cpu_has(c, X86_FEATURE_MWAIT))
+   buf[2] &= ~(ACPI_PDC_C_C2C3_FFH);
+}
+
 /*
  * Initialize bm_flags based on the CPU cache properties
  * On SMP it depends on cache configuration
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index b3171f3..cd7b5fe 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -274,9 +274,6 @@ static void acpi_set_pdc_bits(u32 *buf)
buf[0] = ACPI_PDC_REVISION_ID;
buf[1] = 1;
 
-   /* Enable coordination with firmware's _TSD info */
-   buf[2] = ACPI_PDC_SMP_T_SWCOORD;
-
/* Twiddle arch-specific bits needed for _PDC */
arch_acpi_set_pdc_bits(buf);
 }
@@ -301,7 +298,7 @@ static struct acpi_object_list 
*acpi_processor_alloc_pdc(void)
return NULL;
}
 
-   buf = kmalloc(12, GFP_KERNEL);
+   buf = 

[PATCH 1/3] ACPI / idle: Move idle_boot_override out of the arch directory

[Hanjun Guo]

Move idle_boot_override out of the arch directory to be a single enum
including both platforms values, this will make it rather easier to
avoid ifdefs around which definitions are for which processor in
generally used ACPI code.

IDLE_FORCE_MWAIT for IA64 is not used anywhere, so romove it.

No functional change in this patch.

Suggested-by: Alan 
Signed-off-by: Hanjun Guo 
---
 arch/ia64/include/asm/processor.h| 3 ---
 arch/powerpc/include/asm/processor.h | 1 -
 arch/x86/include/asm/processor.h | 3 ---
 arch/x86/kernel/process.c| 1 +
 include/linux/cpu.h  | 8 
 5 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/ia64/include/asm/processor.h 
b/arch/ia64/include/asm/processor.h
index 5a84b3a..ccd63a0 100644
--- a/arch/ia64/include/asm/processor.h
+++ b/arch/ia64/include/asm/processor.h
@@ -698,9 +698,6 @@ prefetchw (const void *x)
 
 extern unsigned long boot_option_idle_override;
 
-enum idle_boot_override {IDLE_NO_OVERRIDE=0, IDLE_HALT, IDLE_FORCE_MWAIT,
-IDLE_NOMWAIT, IDLE_POLL};
-
 void default_idle(void);
 
 #define ia64_platform_is(x) (strcmp(x, ia64_platform_name) == 0)
diff --git a/arch/powerpc/include/asm/processor.h 
b/arch/powerpc/include/asm/processor.h
index fc14a38..06689c0 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -440,7 +440,6 @@ static inline unsigned long get_clean_sp(unsigned long sp, 
int is_32)
 #endif
 
 extern unsigned long cpuidle_disable;
-enum idle_boot_override {IDLE_NO_OVERRIDE = 0, IDLE_POWERSAVE_OFF};
 
 extern int powersave_nap;  /* set if nap mode can be used in idle loop */
 extern void power7_nap(void);
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 7b034a4..4bee51a 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -729,9 +729,6 @@ extern void init_amd_e400_c1e_mask(void);
 extern unsigned long   boot_option_idle_override;
 extern boolamd_e400_c1e_detected;
 
-enum idle_boot_override {IDLE_NO_OVERRIDE=0, IDLE_HALT, IDLE_NOMWAIT,
-IDLE_POLL};
-
 extern void enable_sep_cpu(void);
 extern int sysenter_setup(void);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95..62764ff 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 03e235ad..e324561 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -220,6 +220,14 @@ void cpu_idle(void);
 
 void cpu_idle_poll_ctrl(bool enable);
 
+enum idle_boot_override {
+   IDLE_NO_OVERRIDE = 0,
+   IDLE_HALT,
+   IDLE_NOMWAIT,
+   IDLE_POLL,
+   IDLE_POWERSAVE_OFF
+};
+
 void arch_cpu_idle(void);
 void arch_cpu_idle_prepare(void);
 void arch_cpu_idle_enter(void);
-- 
1.8.2.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/

[PATCH 0/3] ACPI: Some patches to prepare for running ACPI on !x86 and !ia64

[Hanjun Guo]

Some of the ACPI code is arch-dependent and make the code can't be
compiled on !x86 and !ia64, the first two patches just do some rework
on the idle_boot_override and _PDC related stuff to make the ACPI
code more arch-independent.

The third patch just introduce map_gic_id() for ACPI processor core
followed by the ACPI 5.0 spec.

These three patches are just ACPI related so I send them out as
a separate patch set.

I have compiled the kernel successful after appling this patch set
on x86, ia64 and powerpc(with cross compile tool).

Changes since last RFC version:
a) Remove the RFC tag;
b) Move idle_boot_override out of the arch directory suggested
   by Alan;
c) Make these 3 patches as a separate patch set since there are
   not not related to the ARM/ARM64 platform.

Hanjun Guo (3):
  ACPI / idle: Move idle_boot_override out of the arch directory
  ACPI / processor_core: Rework _PDC related stuff to make it more
arch-independent
  ACPI: Introduce map_gic_id() to get apic id from MADT or _MAT method

 arch/ia64/include/asm/acpi.h |  5 +---
 arch/ia64/include/asm/processor.h|  3 ---
 arch/ia64/kernel/acpi.c  | 17 +
 arch/powerpc/include/asm/processor.h |  1 -
 arch/x86/include/asm/acpi.h  | 19 +--
 arch/x86/include/asm/processor.h |  3 ---
 arch/x86/kernel/acpi/cstate.c| 31 
 arch/x86/kernel/process.c|  1 +
 drivers/acpi/processor_core.c| 47 +---
 include/linux/cpu.h  |  8 ++
 10 files changed, 87 insertions(+), 48 deletions(-)

-- 
1.8.2.2

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

Re: [PATCH -next] sched/numa: document CLONE_VM behavior

[Rik van Riel]

On 01/15/2014 02:01 PM, Davidlohr Bueso wrote:
> From: Davidlohr Bueso 
> 
> The changelog for Rik's "sched/numa: Stay on the same node if CLONE_VM" patch
> serves well documented in the code.
> 
> Signed-off-by: Davidlohr Bueso 

Reviewed-by: Rik van Riel 

-- 
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] percpu_counter: unbreak __percpu_counter_add()

[Ming Lei]

On Fri, Jan 17, 2014 at 7:26 AM, Hugh Dickins  wrote:
> Commit 74e72f894d56 ("lib/percpu_counter.c: fix __percpu_counter_add()")
> looked very plausible, but its arithmetic was badly wrong: obvious once
> you see the fix, but maddening to get there from the weird tmpfs ENOSPCs
>
> Signed-off-by: Hugh Dickins 
> ---
>
>  lib/percpu_counter.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 3.13-rc8+/lib/percpu_counter.c  2014-01-15 09:53:27.768111792 -0800
> +++ linux/lib/percpu_counter.c  2014-01-16 14:58:54.156555308 -0800
> @@ -82,7 +82,7 @@ void __percpu_counter_add(struct percpu_
> unsigned long flags;
> raw_spin_lock_irqsave(>lock, flags);
> fbc->count += count;
> -__this_cpu_sub(*fbc->counters, count);
> +   __this_cpu_sub(*fbc->counters, count - amount);

Ha, you are right, thanks for the fix, and I really tested the patch
with reinserting module of 'null_blk' after lots of IOs, now I know the
reason:  the scale of my test is still too small to cover the slow path
in case of the batch of 100, and only the part in fast path is verified
to be OK.


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

Re: [PATCH 3/4] fix module autoloading for ACPI enumerated devices

[Zhang Rui]

On Fri, 2014-01-17 at 02:28 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 16, 2014 04:04:35 PM Zhang Rui wrote:
> > On Wed, 2014-01-15 at 17:08 +0200, Mika Westerberg wrote:
> > > On Tue, Jan 14, 2014 at 04:46:37PM +0800, Zhang Rui wrote:
> > > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > > index 3a94b79..2f4aea2 100644
> > > > --- a/drivers/base/platform.c
> > > > +++ b/drivers/base/platform.c
> > > > @@ -677,7 +677,13 @@ static ssize_t modalias_show(struct device *dev, 
> > > > struct device_attribute *a,
> > > >  char *buf)
> > > >  {
> > > > struct platform_device  *pdev = to_platform_device(dev);
> > > > -   int len = snprintf(buf, PAGE_SIZE, "platform:%s\n", pdev->name);
> > > > +   int len;
> > > > +
> > > > +   len = acpi_device_modalias(dev, buf, PAGE_SIZE -1);
> > > 
> > > Here you have PAGE_SIZE -1...
> > > 
> > > > +   if (len != -ENODEV)
> > > > +   return len;
> > > > +
> > > > +   len = snprintf(buf, PAGE_SIZE, "platform:%s\n", pdev->name);
> > > >  
> > > > return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
> > > >  }
> > > > @@ -699,6 +705,10 @@ static int platform_uevent(struct device *dev, 
> > > > struct kobj_uevent_env *env)
> > > > if (rc != -ENODEV)
> > > > return rc;
> > > >  
> > > > +   rc = acpi_device_uevent_modalias(dev, env);
> > > > +   if (rc != -ENODEV)
> > > > +   return rc;
> > > > +
> > > > add_uevent_var(env, "MODALIAS=%s%s", PLATFORM_MODULE_PREFIX,
> > > > pdev->name);
> > > > return 0;
> > > > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > > > index d74c0b3..c4c5588 100644
> > > > --- a/drivers/i2c/i2c-core.c
> > > > +++ b/drivers/i2c/i2c-core.c
> > > > @@ -104,6 +104,11 @@ static int i2c_device_match(struct device *dev, 
> > > > struct device_driver *drv)
> > > >  static int i2c_device_uevent(struct device *dev, struct 
> > > > kobj_uevent_env *env)
> > > >  {
> > > > struct i2c_client   *client = to_i2c_client(dev);
> > > > +   int rc;
> > > > +
> > > > +   rc = acpi_device_uevent_modalias(dev, env);
> > > > +   if (rc != -ENODEV)
> > > > +   return rc;
> > > >  
> > > > if (add_uevent_var(env, "MODALIAS=%s%s",
> > > >I2C_MODULE_PREFIX, client->name))
> > > > @@ -409,6 +414,12 @@ static ssize_t
> > > >  show_modalias(struct device *dev, struct device_attribute *attr, char 
> > > > *buf)
> > > >  {
> > > > struct i2c_client *client = to_i2c_client(dev);
> > > > +   int len;
> > > > +
> > > > +   len = acpi_device_modalias(dev, buf, PAGE_SIZE -1);
> > > 
> > > and here
> > > 
> > > > +   if (len != -ENODEV)
> > > > +   return len;
> > > > +
> > > > return sprintf(buf, "%s%s\n", I2C_MODULE_PREFIX, client->name);
> > > >  }
> > > >  
> > > > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> > > > index 349ebba..ab70eda 100644
> > > > --- a/drivers/spi/spi.c
> > > > +++ b/drivers/spi/spi.c
> > > > @@ -58,6 +58,11 @@ static ssize_t
> > > >  modalias_show(struct device *dev, struct device_attribute *a, char 
> > > > *buf)
> > > >  {
> > > > const struct spi_device *spi = to_spi_device(dev);
> > > > +   int len;
> > > > +
> > > > +   len = acpi_device_modalias(dev, buf, PAGE_SIZE);
> > > 
> > > but here it is PAGE_SIZE.
> > > 
> > good catch.
> > 
> > > Perhaps it should be PAGE_SIZE in all sites?
> > 
> > dev_attr_show() will give a warning message if modalias_show() returns
> > PAGE_SIZE, thus I'd prefer to use PAGE_SIZE - 1 for all sites.
> 
> So I changed the PAGE_SIZE to PAGE_SIZE - 1 in the last instance and queued
> up the whole series for 3.14 in linux-pm.git/linux-next.  Please have a look
> at that and let me know if there's anything wrong with it.
> 
the change looks okay to me.

thanks,
rui
> Thanks!
> 


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

Re: [PATCH 2/2] Input: edt-ft5x06: Add DT support

[Simon Budig]

On 16/01/14 08:49, Lothar Waßmann wrote:
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
>>> @@ -0,0 +1,31 @@
>>> +* EDT FT5x06 Multiple Touch Controller
>>> +
> [...]
>>> +- threshold: allows setting the "click"-threshold in the range from 20 to 
>>> 80.
>>> +- gain: sensitivity (0..31) (lower value -> higher sensitivity)
>>> +- offset: edge compensation (0..31)
>>> +- report_rate: report rate (3..14)
>>
>> s/_/-/ on property names please. Also, it may make sense to prefix these
>> as they're rather generic sounding names.
>>
>> Could you elaborate on these a litle please? What units are each of
>> these in? Why does it make sense to have them in the dt?
>>
> I just converted them from being passed via platform_data. I have no
> idea what they actually control and what units they use. I could not
> even find a manual where they are documented.
> Maybe Simon Budig can help out here as the original driver author.

The units are not specified in the datasheets available to me. I suspect
that these are some sort of counter values related to the cap sensing.

The defaults differ for the different size glasses, so I really suspect
these are basically just numbers.

The only somewhat reasonable unit is available for the report-rate: it
is specified as about  * 10 touch reports per second.

Bye,
Simon

-- 
   Simon Budigkernel concepts GmbH
   simon.bu...@kernelconcepts.de  Sieghuetter Hauptweg 48
   +49-271-771091-17  D-57072 Siegen




signature.asc
Description: OpenPGP digital signature

Re: [PATCHv2 3/3] Input: edt-ft5x06: Add DT support

[Simon Budig]

Hi Dmitry

On 17/01/14 01:26, Dmitry Torokhov wrote:
>> +  The following properties provide default values for the
>> +  corresponding parameters (see Documentation/input/edt-ft5x06.txt)
>> +- edt,threshold: allows setting the "click"-threshold in the range from 20 
>> to 80.
>> +- edt,gain: sensitivity (0..31) (lower value -> higher sensitivity)
>> +- edt,offset: edge compensation (0..31)
>> +- edt,report-rate: report rate (3..14)
> 
> I wonder if we really need to have it in device tree? Can users needing
> top tweak the settings do it via udev rules?

IMO it makes sense to have these in the device tree. These values need
to be adjusted if you have glass or acrylics in front of the touch
glass. The defaults are tailored to the touchscreen without any
(additional) material in front of it.

So manufacturers need to provide different defaults depending on the way
a specific device is built. So these properties can be viewed in the
same way you specify display resolution or display type in the device tree.

Bye,
 Simon


-- 
   Simon Budigkernel concepts GmbH
   simon.bu...@kernelconcepts.de  Sieghuetter Hauptweg 48
   +49-271-771091-17  D-57072 Siegen




signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH 3/4] virtio_balloon: add pressure notification via a new virtqueue

[Luiz Capitulino]

On Thu, 16 Jan 2014 20:38:19 -0500
Luiz Capitulino  wrote:

> > What does qemu do with this information?
> 
> There are two possible scenarios:
> 
>  1. The balloon driver is currently inflating when it gets under
> pressure
> 
> QEMU resets "num_pages" to the current balloon size. This
> cancels the on-going inflate
> 
>  2. The balloon driver is not inflating, eg. it's possibly sleeping
> 
>QEMU issues a deflate
> 
> But note that those scenarios are not supposed to be used with the
> current device, they are part of the automatic ballooning feature.
> I CC'ed you on the QEMU patch, you can find it here case you didn't
> see it:
> 
>  http://marc.info/?l=kvm=138988966315690=2

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

Re: [PATCH v4 02/15] clk: Allow drivers to pass in a regmap

[Saravana Kannan]

On 01/15/2014 01:36 AM, Mike Turquette wrote:

Quoting Saravana Kannan (2014-01-13 19:54:42)

On 01/08/2014 05:51 PM, Mike Turquette wrote:

Quoting Stephen Boyd (2013-12-23 17:12:26)

Add support to the clock core so that drivers can pass in a
regmap. If no regmap is specified try to query the device that's
registering the clock for its regmap. This should allow drivers
to use the core regmap helpers. This is based on a similar design
in the regulator framework.

Cc: Mark Brown 
Signed-off-by: Stephen Boyd 
---
   drivers/clk/clk.c| 8 
   include/linux/clk-provider.h | 7 +++
   2 files changed, 15 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 9ad7b71..5e71f5c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -20,6 +20,7 @@
   #include 
   #include 
   #include 
+#include 

   static DEFINE_SPINLOCK(enable_lock);
   static DEFINE_MUTEX(prepare_lock);
@@ -1834,6 +1835,13 @@ static int _clk_register(struct device *dev, struct 
clk_hw *hw, struct clk *clk)
  clk->num_parents = hw->init->num_parents;
  hw->clk = clk;

+   if (hw->init->regmap)
+   hw->regmap = hw->init->regmap;


Hi Stephen,

The whole series looks good to me except for the placement of the regmap
details inside struct clk_hw. That structure exists only to hide struct
clk from the hardware-specific clock structure and I'd not like to set
the precedent of shoving per-clock data into it.

As an alternative, how about finding a way to put these per-clock regmap
details into the hardware-specific clock structure? I understand that
you want to make these ops available to others, which is why they are in
the public struct clk_hw. I'm just wondering if that is the right way to
do it...

Patch #3 illustrates the sort of struct-member-creep that worries me.
What is to stop someone from putting "unsigned int divider_reg" or
"unsigned int mux_reg", and then the thing just keeps growing.


I agree with Mike here. This definitely encourages struct field creep if
more people want to use it.

I talked to Stephen is person and my recommendation is to not have any
new fields other than struct regmap in clk_hw and remove the above 2
lines of code.


+   else if (dev && dev_get_regmap(dev, NULL))
+   hw->regmap = dev_get_regmap(dev, NULL);


Move "struct regmap *regmap" into struct clk_hw (since it's truly
reusable across clock types and is technically purely HW related) and
update it from the device's regmap like above.


Hi Saravana,

Thanks for your comments. In the paragraph above you mean "struct
clk_hw" or do you mean the hardware-specific structure(s) defined in a
clock driver?



We can then provide __clk_regmap_enable(regmap, offset, enable_mask)
helper functions. Then clock specific functions can use the helper. We
can even a simple macro to generate these wrappers.

#define DEFINE_REGMAP_EN_DIS(clktype) \

int clk_type##_enable(clktype *c, ) { }
int clk_type##_disable(clktype *c, ) { }


That to me seems like a reasonable compromise.


Providing common functions for the basic case (e.g. read-modify-write on
a register using a known mask) is reasonable. But that is exactly what
the existing basic clock types do (sans regmap) and they have all become
pretty ugly over time. And the clk-composite implementation just makes
me a sad panda.

I'm not opposed to providing public implementations of clk_ops callbacks
that use regmap, but I will be very mindful of any feature creep in the
future.

I am still unconvinced that adding struct regmap to struct clk_hw is a
good idea. The regmap data is a function of hardware-specific details
and those details always have and always will belong in the clock
driver


The details of the bits inside the register and how it's used would be 
clock type specific. Meaning, a Vendor X clock gate might have a busy 
bit and Vendor Y clock gate might not have a busy bit.


Regmap doesn't try to consolidate that. I'm not saying those clock gates 
should not be consolidated, but that's not what regmap is trying to do.


Regmap is helpful to consolidate clocks that behave exactly the same 
way, but differ in how the clock registers are accessed. Eg: mem-mapped 
IO, I2C, CP15 read/writes. So, even with a MSM based board, just because 
the way to access the registers are different, we could have to 
implement 3 different clock gate types. Which I think would be the wrong 
thing to do. Regmap cleanly consolidates this because the clock types 
just need to store the offsets and operate on them as usual using regmap 
APIs.


Since the regmap for the clock is assigned based on the device that's 
registering the enable/disable code for a clock gate can be agnostic of 
how the registers are accesses. Yes, regmap does provide helpers for 
read/modify writes, but that's not the main reason for using it.


Btw, this is a very real case on MSMs. The CPU clocks are accesses thru 
CP15 instructions, and the other clock trees are 

[PATCH] clocksource: timer-sun5i: Switch to sched_clock_register()

[Stephen Boyd]

The 32 bit sched_clock interface supports 64 bits since 3.13-rc1.
Upgrade to the 64 bit function to allow us to remove the 32 bit
registration interface.

Cc: Maxime Ripard 
Signed-off-by: Stephen Boyd 
---

Cc'in Ingo because this is simple enough to probably just apply to timers/core

 drivers/clocksource/timer-sun5i.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-sun5i.c 
b/drivers/clocksource/timer-sun5i.c
index bddc52233d2a..deebcd6469fc 100644
--- a/drivers/clocksource/timer-sun5i.c
+++ b/drivers/clocksource/timer-sun5i.c
@@ -136,7 +136,7 @@ static struct irqaction sun5i_timer_irq = {
.dev_id = _clockevent,
 };
 
-static u32 sun5i_timer_sched_read(void)
+static u64 sun5i_timer_sched_read(void)
 {
return ~readl(timer_base + TIMER_CNTVAL_LO_REG(1));
 }
@@ -166,7 +166,7 @@ static void __init sun5i_timer_init(struct device_node 
*node)
writel(TIMER_CTL_ENABLE | TIMER_CTL_RELOAD,
   timer_base + TIMER_CTL_REG(1));
 
-   setup_sched_clock(sun5i_timer_sched_read, 32, rate);
+   sched_clock_register(sun5i_timer_sched_read, 32, rate);
clocksource_mmio_init(timer_base + TIMER_CNTVAL_LO_REG(1), node->name,
  rate, 340, 32, clocksource_mmio_readl_down);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [RFC PATCH 3/4] virtio_balloon: add pressure notification via a new virtqueue

[Luiz Capitulino]

On Fri, 17 Jan 2014 09:10:47 +1030
Rusty Russell  wrote:

> Luiz Capitulino  writes:
> > From: Luiz capitulino 
> >
> > This commit adds support to a new virtqueue called message virtqueue.
> 
> OK, this needs a lot of thought (especially since reworking the virtio
> balloon is on the TODO list for the OASIS virtio technical committee...)
> 
> But AFAICT this is a way of explicitly saying "no" to the host's target
> (vs the implicit method of just not meeting the target).  I'm not sure
> that gives enough information to the host.  On the other hand, I'm not
> sure what information we *can* give.
> 
> Should we instead be counter-proposing a target?

The problem is how to estimate a target value. I found it simpler
to just try to obey what the host is asking for (and fail if not
possible) than trying to make the guest negotiate with the host.

> What does qemu do with this information?

There are two possible scenarios:

 1. The balloon driver is currently inflating when it gets under
pressure

QEMU resets "num_pages" to the current balloon size. This
cancels the on-going inflate

 2. The balloon driver is not inflating, eg. it's possibly sleeping

   QEMU issues a deflate

But note that those scenarios are not supposed to be used with the
current device, they are part of the automatic ballooning feature.
I CC'ed you on the QEMU patch, you can find it here case you didn't
see it:

 http://marc.info/?l=kvm=138988966315690=2

> 
> Thanks,
> Rusty.
> 
> > The message virtqueue can be used by guests to notify the host about
> > important memory-related state changes in the guest. Currently, the
> > only implemented notification is the "guest is under pressure" one,
> > which informs the host that the guest is under memory pressure.
> >
> > This notification can be used to implement automatic memory ballooning
> > in the host. For example, once learning that the guest is under pressure,
> > the host could cancel an on-going inflate and/or start a deflate
> > operation.
> >
> > Doing this through a virtqueue might seem like overkill, as all
> > we're doing is to transfer an integer between guest and host. However,
> > using a virtqueue offers the following advantages:
> >
> >  1. We can realibly synchronize host and guest. That is, the guest
> > will only continue once the host acknowledges the notification.
> > This is important, because if the guest gets under pressure while
> > inflating the balloon, it has to stop to give the host a chance
> > to reset "num_pages" (see next commit)
> >
> >  2. It's extensible. We may (or may not) want to tell the host
> > which pressure level the guest finds itself in (ie. low,
> > medium or critical)
> >
> > The lightweight alternative is to use a configuration space parameter.
> > For this to work though, the guest would have to wait the for host
> > to acknowloedge the receipt of a configuration change update. I could
> > try this if the virtqueue is too overkill.
> >
> > Finally, the guest learns it's under pressure by registering a
> > callback with the in-kernel vmpressure API.
> >
> > FIXMEs:
> >
> >  - vmpressure API is missing an de-registration routine
> >  - not completely sure my changes in virtballoon_probe() are correct
> >
> > Signed-off-by: Luiz capitulino 
> > ---
> >  drivers/virtio/virtio_balloon.c | 93 
> > +
> >  include/uapi/linux/virtio_balloon.h |  1 +
> >  2 files changed, 84 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_balloon.c 
> > b/drivers/virtio/virtio_balloon.c
> > index 5c4a95b..1c3ee71 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -29,6 +29,9 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> > +#include 
> > +
> >  /*
> >   * Balloon device works in 4K page units.  So each page is pointed to by
> >   * multiple balloon pages.  All memory counters in this driver are in 
> > balloon
> > @@ -37,10 +40,12 @@
> >  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> 
> > VIRTIO_BALLOON_PFN_SHIFT)
> >  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> >  
> > +#define VIRTIO_BALLOON_MSG_PRESSURE 1
> > +
> >  struct virtio_balloon
> >  {
> > struct virtio_device *vdev;
> > -   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq;
> > +   struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *message_vq;
> >  
> > /* Where the ballooning thread waits for config to change. */
> > wait_queue_head_t config_change;
> > @@ -51,6 +56,8 @@ struct virtio_balloon
> > /* Waiting for host to ack the pages we released. */
> > wait_queue_head_t acked;
> >  
> > +   wait_queue_head_t message_acked;
> > +
> > /* Number of balloon pages we've told the Host we're not using. */
> > unsigned int num_pages;
> > /*
> > @@ -71,6 +78,9 @@ struct virtio_balloon
> > /* Memory statistics */
> > int need_stats_update;
> > struct virtio_balloon_stat