[PATCH] staging: comedi: addi_apci_1564: move boilerplate text to addi_apci_1564.c

[Chase Southwood]

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 23 --
 drivers/staging/comedi/drivers/addi_apci_1564.c| 23 ++
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 198c627..d73db42 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -1,26 +1,3 @@
-/*
- * Copyright (C) 2004,2005  ADDI-DATA GmbH for the source code of this module.
- *
- * ADDI-DATA GmbH
- * Dieselstrasse 3
- * D-77833 Ottersweier
- * Tel: +19(0)7223/9493-0
- * Fax: +49(0)7223/9493-92
- * http://www.addi-data.com
- * i...@addi-data.com
- *
- * This program is free software; you can redistribute it and/or modify it 
under
- * the terms of the GNU General Public License as published by the Free 
Software
- * Foundation; either version 2 of the License, or (at your option) any later
- * version.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
FITNESS
- * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
- * details.
- *
- */
-
 /* Digital Input IRQ Function Selection */
 #define APCI1564_DI_INT_OR (0 << 1)
 #define APCI1564_DI_INT_AND(1 << 1)
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c 
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 16c02c8..6df3603 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -1,3 +1,26 @@
+/*
+ * addi_apci_1564.c
+ * Copyright (C) 2004,2005  ADDI-DATA GmbH for the source code of this module.
+ *
+ * ADDI-DATA GmbH
+ * Dieselstrasse 3
+ * D-77833 Ottersweier
+ * Tel: +19(0)7223/9493-0
+ * Fax: +49(0)7223/9493-92
+ * http://www.addi-data.com
+ * i...@addi-data.com
+ *
+ * This program is free software; you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License as published by the Free 
Software
+ * Foundation; either version 2 of the License, or (at your option) any later
+ * version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
FITNESS
+ * FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
+ * details.
+ */
+
 #include 
 #include 
 #include 
-- 
2.1.0

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

Re: [PATCH v3 4/4] pinctrl: qcom: Add support for reset for apq8064

[Pramod Gurav]

Bjorn,
Thanks for review. :)

On 30-08-2014 12:12 AM, Bjorn Andersson wrote:
> On Fri 29 Aug 07:30 PDT 2014, Pramod Gurav wrote:
> 
>> This patch adds support for reset functions to reboot the boards
>> with soc apq8064.
>>
>> CC: Linus Walleij 
>> CC: Bjorn Andersson 
>> CC: "Ivan T. Ivanov" 
>> CC: Stephen Boyd 
>> CC: Andy Gross 
>> Signed-off-by: Pramod Gurav 
> 
> Thanks for the rework, that was fast :)
> 
> Acked-by: Bjorn Andersson 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl: qcom: remove gpiochip in failure cases

[Pramod Gurav]

Hi Bjorn,

On 30-08-2014 12:27 AM, Bjorn Andersson wrote:
> On Fri 29 Aug 01:11 PDT 2014, Pramod Gurav wrote:
> 
>> This patch releases gpiochip related resources by calling
>> gpiochip_remove when either of gpiochip_add_pin_range and
>> gpiochip_irqchip_add fails.
>>
>> CC: Linus Walleij 
>> CC: Bjorn Andersson 
>> CC: "Ivan T. Ivanov" 
>> Signed-off-by: Pramod Gurav 
> 
> Acked-by: Bjorn Andersson 
> 

<..>

> 
> It seems like pinctrl-st.c and pinctrl-sirf.c is suffering the same problem,
> would you mind spinning patches for those too?
Sure. Was browsing files but I was caught by this thing called sleep
before I catch anything. :) Thanks for pointing them out. Will do it.

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

Re: [PATCH v2] pinctrl: qcom: remove gpiochip in failure cases

[Pramod Gurav]

Hi Bjorn,


On 30-08-2014 12:27 AM, Bjorn Andersson wrote:
> On Fri 29 Aug 01:11 PDT 2014, Pramod Gurav wrote:
> 
>> This patch releases gpiochip related resources by calling
>> gpiochip_remove when either of gpiochip_add_pin_range and
>> gpiochip_irqchip_add fails.
>>
>> CC: Linus Walleij 
>> CC: Bjorn Andersson 
>> CC: "Ivan T. Ivanov" 
>> Signed-off-by: Pramod Gurav 
> 
> Acked-by: Bjorn Andersson 
> 
>> ---
>>
>> Changes since v1:
>> - In v1 of this patch gpiochip_remove was called only in failure case of
>>   gpiochip_irqchip_add. This patchs adds a call to gpiochip_remove in failure
>>   case of gpiochip_add_pin_range as well.
>>
>>  drivers/pinctrl/qcom/pinctrl-msm.c |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
>> b/drivers/pinctrl/qcom/pinctrl-msm.c
>> index 2738108..9175bbc 100644
>> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
>> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
>> @@ -829,6 +829,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
>>  ret = gpiochip_add_pin_range(>chip, dev_name(pctrl->dev), 0, 0, 
>> chip->ngpio);
>>  if (ret) {
>>  dev_err(pctrl->dev, "Failed to add pin range\n");
>> +gpiochip_remove(>chip);
>>  return ret;
>>  }
>>  
>> @@ -839,6 +840,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
>> IRQ_TYPE_NONE);
>>  if (ret) {
>>  dev_err(pctrl->dev, "Failed to add irqchip to gpiochip\n");
>> +gpiochip_remove(>chip);
>>  return -ENOSYS;
>>  }
>>  
> 
> It seems like pinctrl-st.c and pinctrl-sirf.c is suffering the same problem,
> would you mind spinning patches for those too?
Sure. Was browsing files but I was caught by this thing called sleep
before I catch anything. :) Thanks for pointing them out. Will do it.

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

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

Santosh,

On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
 wrote:
> On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>> These two patches add support for automatically configuring the IO
>> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>> new notification types to the regulator code.  It's used by the second
>> patch which actually implements the IO voltage domain driver.
>>
>> These two patches were co-developed by Heiko Stübner and Doug Anderson
>> (proof of concept patches were written by Heiko).  They were tested in
>> a private branch on an rk3288 board using rk808 instead of mainline
>> since rk808 support isn't finalized in mainline yet.
>>
>> (sorry if you got this series twice; my mailer seems unhappy with me)
>>
>> Heiko Stübner (2):
>>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>>   soc/rockchip: io-domain: add driver handling io domains
>>
> Sorry to shot down but your IO domains are nothing but voltage domains
> and you should really build something in the drivers/power/*

If everyone agrees that this belongs in drivers/power that's totally
OK.  Neither Heiko nor I was confident that it should be in
drivers/soc.  I had even though that the code wouldn't be totally out
of place in the Rockchip pinctrl driver (adding Linus W since I think
some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).


> Please have a look at the RFC [1]. You should really go on those
> lines and collaborate to make a generic voltage domain layer instead of 
> throwing
> the driver under drivers/soc.

Trying to base things on a 7-month old RFC that hasn't been touched is
not something I'm going to do.  Maybe that makes me a bad person...

I would also say that I'm not convinced that we really need a
complicated framework here.  Maybe when we're talking about things
like ABB and DevFreq and the like then having a nice framework is a
good idea.  Really here we're just setting properties associated with
IO pins.  There's no decisions about latency, power tradeoffs, etc.
If the pin is connected to 1.8V we need to set the 1.8V bit.  If it's
connected to 3.3V we need to set the 3.3V bit.  The end.

The only remotely complicated thing (and why this isn't just a pinctrl
property) is what happens with dynamic voltages.  SD Card IO lines can
change voltage depending on UHS negotiation.  In that case the SD Card
Driver will request that its regulator change from 3.3V to 1.8V.  The
bit in the IO domain register needs to update in tandem.


The driver is really quite tiny (333 lines).  If we find that lots of
people copy it and they have code that's nearly the same then we
should try to abstract things out then.


I'd be interested in hearing other opinions, though.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/2] rockchip-i2s: add power setting for I2S controller and fix some critical bugs

[Doug Anderson]

Jianqun,

On Fri, Aug 29, 2014 at 3:07 PM, Jianqun  wrote:
> Add optional power setting for i2s controller found on rk3066, rk3168 and 
> rk3288
> processors from rockchip, should according to hardware design.
>
> Default setting for I2S controller is powered by 3.3V, there needs this patch 
> if
> it's powered by 1.8V by hardware design.
>
> Jianqun (2):
>   rockchip-i2s: dt: add grf requested properties to set power of I2S 
> controller
>   rockchip-i2s: add power setting for I2S controller, also fix some bugs
>
>  .../devicetree/bindings/sound/rockchip-i2s.txt |  6 +-
>  sound/soc/rockchip/rockchip_i2s.c  | 93 
> +-
>  sound/soc/rockchip/rockchip_i2s.h  | 13 +--
>  3 files changed, 68 insertions(+), 44 deletions(-)

Did the general solution I posted at
 not work for you?  ...or
did you not see that?

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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) v3] net: stmmac: fix warning from Sparse for socfpga

[David Miller]

From: Ley Foon Tan 
Date: Thu, 28 Aug 2014 12:59:46 +0800

> Warning:
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:41:
> sparse: cast removes address space of expression
> drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c:122:38:
> sparse: incorrect type in assignment (different address spaces)
> 
> Signed-off-by: Ley Foon Tan 

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

RE: [PATCH 1/4] net: stmmac: enhance to support multiple device instances

[Kweh, Hock Leong]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Saturday, August 30, 2014 11:06 AM
> To: Kweh, Hock Leong
> Cc: peppe.cavall...@st.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ong, Boon Leong
> Subject: Re: [PATCH 1/4] net: stmmac: enhance to support multiple device
> instances
> 
> From: Kweh Hock Leong 
> Date: Wed, 27 Aug 2014 18:32:26 +0800
> 
> > +static int instance_id = 1;
> 
> Don't do this instance stuff.  Instead pull in some identifier that
> can come from elsewhere.

Regarding this, I would like to open up a discussion here. This "instance_id" 
actually
is used for registering the mdio bus as a bus id. The original code use "1" for 
the bus
id. If the system plug in more than one stmmac pci cards, I believe there is 
conflict on
the mdio bus registration. So introduce this static global variable is to 
increase the
bus id starting from "1" base on how many stmmac pci cards being plugged in.

So, to change the "instance_id" by using some identifier, the only thing come 
to my
mind is pci_dev->devfn number. Is anyone have concern about using devfn number
as an mdio bus id ?


> > +   plat_dat->mdio_bus_data = devm_kzalloc(>dev,
> > +   sizeof(*plat_dat->mdio_bus_data),
> > +   GFP_KERNEL);
> 
> This is not indented properly.
> 
> On the second and subsequent lines of a multi-line function call,
> the lines should start exactly at the first column after the openning
> parenthesis of the first line.
> 
> You must use the correct number of TAB and SPACE characters necessary
> to do so.  Generally speaking, if you are indenting using only TAB
> characters, odds are you are doing it wrong.
> 
> Please audit for, and fix this, in your entire patch series.

Noted. Will fix the indentation on version 2 patch. Thanks.

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

[PATCH v2] mmc:sdhci: handle busy-end interrupt during command

[Chanho Min]

It is fully legal for a controller to start handling busy-end interrupt
before it has signaled that the command has completed. So make sure
we do things in the proper order, Or it results that command interrupt
is ignored so it can cause unexpected operations. This is founded at some
toshiba emmc with the bellow warning.

"mmc0: Got command interrupt 0x0001 even though
no command operation was in progress."

This issue has been also reported by Youssef TRIKI:
It is not specific to Toshiba devices, and happens with eMMC devices
as well as SD card which support Auto-CMD12 rather than CMD23.

Also, similar patch is submitted by:
Gwendal Grignou 

Changes since v1:
 Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git
 and Tested if issue is fixed again. 

Signed-off-by: Hankyung Yu 
Signed-off-by: Chanho Min 
Tested-by: Youssef TRIKI 
---
 drivers/mmc/host/sdhci.c  |   17 +++--
 include/linux/mmc/sdhci.h |1 +
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f6a683b..8428148 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1016,6 +1016,7 @@ void sdhci_send_command(struct sdhci_host *host, struct 
mmc_command *cmd)
mod_timer(>timer, timeout);
 
host->cmd = cmd;
+   host->busy_handle = 0;
 
sdhci_prepare_data(host, cmd);
 
@@ -2261,8 +2262,12 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 
intmask)
if (host->cmd->data)
DBG("Cannot wait for busy signal when also "
"doing a data transfer");
-   else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ))
+   else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ)
+   && !host->busy_handle) {
+   /* Mark that command complete before busy is ended */
+   host->busy_handle = 1;
return;
+   }
 
/* The controller does not support the end-of-busy IRQ,
 * fall through and take the SDHCI_INT_RESPONSE */
@@ -2330,7 +2335,15 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 
intmask)
return;
}
if (intmask & SDHCI_INT_DATA_END) {
-   sdhci_finish_command(host);
+   /*
+* Some cards handle busy-end interrupt
+* before the command completed, so make
+* sure we do things in the proper order.
+*/
+   if (host->busy_handle)
+   sdhci_finish_command(host);
+   else
+   host->busy_handle = 1;
return;
}
}
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 09ebe57..0aa85ca 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -146,6 +146,7 @@ struct sdhci_host {
struct mmc_command *cmd;/* Current command */
struct mmc_data *data;  /* Current data request */
unsigned int data_early:1;  /* Data finished before cmd */
+   unsigned int busy_handle:1; /* Handling the order of Busy-end */
 
struct sg_mapping_iter sg_miter;/* SG state for PIO */
unsigned int blocks;/* remaining PIO blocks */
-- 
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/

[RFC PATCH] powerpc: Wire up three syscalls

[Pranith Kumar]

I see that the three syscalls seccomp, getrandom and memfd_create are not wired
because of which we get a warning while compilation.

So I wired them up in this patch. What else needs to be done? I tried the
memfd_test after compiling this kernel, but it is failing. What am I missing for
this to work? Any advice is really appreciated! :)

Signed-off-by: Pranith Kumar 
---
 arch/powerpc/include/asm/systbl.h  | 3 +++
 arch/powerpc/include/asm/unistd.h  | 2 +-
 arch/powerpc/include/uapi/asm/unistd.h | 3 +++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/systbl.h 
b/arch/powerpc/include/asm/systbl.h
index 542bc0f..7d8a600 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -362,3 +362,6 @@ SYSCALL(ni_syscall) /* sys_kcmp */
 SYSCALL_SPU(sched_setattr)
 SYSCALL_SPU(sched_getattr)
 SYSCALL_SPU(renameat2)
+SYSCALL_SPU(seccomp)
+SYSCALL_SPU(getrandom)
+SYSCALL_SPU(memfd_create)
diff --git a/arch/powerpc/include/asm/unistd.h 
b/arch/powerpc/include/asm/unistd.h
index 5ce5552..4e9af3f 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h
@@ -12,7 +12,7 @@
 #include 
 
 
-#define __NR_syscalls  358
+#define __NR_syscalls  361
 
 #define __NR__exit __NR_exit
 #define NR_syscalls__NR_syscalls
diff --git a/arch/powerpc/include/uapi/asm/unistd.h 
b/arch/powerpc/include/uapi/asm/unistd.h
index 2d526f7..0688fc0 100644
--- a/arch/powerpc/include/uapi/asm/unistd.h
+++ b/arch/powerpc/include/uapi/asm/unistd.h
@@ -380,5 +380,8 @@
 #define __NR_sched_setattr 355
 #define __NR_sched_getattr 356
 #define __NR_renameat2 357
+#define __NR_seccomp   358
+#define __NR_getrandom 359
+#define __NR_memfd_create  360
 
 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */
-- 
2.1.0

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

Re: [PATCH] drivers/xen/evtchn.c: Check failure for evtchn_make_refcounted()

[Chen Gang]

On 8/29/14 21:43, David Vrabel wrote:
> On 29/08/14 14:34, Chen Gang wrote:
>>
>>
>> On 8/28/14 23:49, David Vrabel wrote:
>>> On 28/08/14 16:13, Chen Gang wrote:
 evtchn_make_refcounted() may return failure, so need process the failure
 case. In failure case, it need call unbind_from_irqhandler() just like
 evtchn_unbind_from_user() has done.

 irq_from_evtchn() must be OK when bind_evtchn_to_irqhandler() succeed,
 so need not check it again.

 Also still need remain the closing port code, because when the failure
 occurs, unbind_from_irqhandler() will not close port internally.
>>>
>>> None of the evtchn_make_refcounted() failures can occur since we know we
>>> have a valid irq and info at the single call site.
>>>
>>
>> OK, thanks. I guess what you said is correct.
>>
>> But only according to the code, for me, I am not quite sure about 'info'
>> must be always valid. If bind_evtchn_to_irqhandler() succeeds, I can not
>> find any related code to prove 'info' must be valid.
>>
>>  - for a new irq, it will allocate 'info' for it.
>>
>>  - but for an existing irq, the code assumes it may has no 'info'.
>>(so several areas check 'info' whether valid, although irq is OK).
>>
>> So could you give some additional related proofs for it? And if 'info'
>> must be always OK, can we remove all the related check about 'info'?
> 
> I'm not sure what you mean by an existing irq.  If it's an irq for an
> event channel it will have had info set when it was allocated.  the
> irq_mapping_update_lock protects against seeing partially setup irqs.
> 

After check the code details again. I guess, really no "existing irq",
just like you said.

But in honest, only based on the code, for me, it is not quite clear (
I guess it is OK, but I am not sure it must be OK -- still worry about
it).


> So, the checks for !info can be removed, yes.
> 

So for me, for safety (also easy understanding) reason, I still prefer
my original patch, although it is not the best one.

If you are sure about it (I guess you are sure), please help send patch
for it (skip checking "!info"). If necessary, may mark Cc or Reported-by
to me.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] Remove various orphaned header files

[David Miller]

From: Rasmus Villemoes 
Date: Thu, 28 Aug 2014 13:44:30 +0200

> These four files are not included anywhere, and seem to be accidental
> leftovers from past cleanups (see the individual commit messages).

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

Re: [PATCH net-next v2] r8152: reduce the number of Tx

[David Miller]

From: Hayes Wang 
Date: Thu, 28 Aug 2014 10:24:18 +0800

> Because the Tx has the features of stopping queue and aggregation,
> We don't need many tx buffers. Change the tx number from 10 to 4
> to reduce the usage of the memory. This could save 16K * 6 bytes
> memory.
> 
> Signed-off-by: Hayes Wang 
> ---
>  drivers/net/usb/r8152.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 33dcc97..cc64dc0 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -424,7 +424,7 @@ enum rtl_register_content {
>   FULL_DUP= 0x01,
>  };
>  
> -#define RTL8152_MAX_TX   10
> +#define RTL8152_MAX_TX   4
>  #define RTL8152_MAX_RX   10

This driver has a loop that iterates MAX_TX times to initialize both
the RX and TX buffers.

So if they are not equal, it can't possibly work.

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

Re: [PATCH 1/1] USB: Add device quirk for ASUS T100 Base Station keyboard

[Lu, Baolu]

On 8/29/2014 7:59 PM, Sergei Shtylyov wrote:

Hello.

On 8/29/2014 8:26 AM, Lu Baolu wrote:


This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.



This patch tries to introduce USB_QUIRK_IGNOR_REMOTE_WAKEUP quirk.


   Why not IGNORE? This doesn't look like a big save...


Sure, will change it.




With this quirk set, wakeup capability will be ignored during
device configure.



This patch could be back-ported to kernels as old as 2.6.39.



Signed-off-by: Lu Baolu 


WBR, Sergei



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

Re: [PATCH 1/4] net: stmmac: enhance to support multiple device instances

[David Miller]

From: Kweh Hock Leong 
Date: Wed, 27 Aug 2014 18:32:26 +0800

> @@ -26,27 +26,22 @@
>  #include 
>  #include "stmmac.h"
>  
> -static struct plat_stmmacenet_data plat_dat;
> -static struct stmmac_mdio_bus_data mdio_data;
> -static struct stmmac_dma_cfg dma_cfg;
> +static int instance_id = 1;

Don't do this instance stuff.  Instead pull in some identifier that
can come from elsewhere.

> + plat_dat->mdio_bus_data = devm_kzalloc(>dev,
> + sizeof(*plat_dat->mdio_bus_data),
> + GFP_KERNEL);

This is not indented properly.

On the second and subsequent lines of a multi-line function call,
the lines should start exactly at the first column after the openning
parenthesis of the first line.

You must use the correct number of TAB and SPACE characters necessary
to do so.  Generally speaking, if you are indenting using only TAB
characters, odds are you are doing it wrong.

Please audit for, and fix this, in your entire patch series.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: net_ns cleanup / RCU overhead

[Paul E. McKenney]

On Sat, Aug 30, 2014 at 01:52:06AM +0200, Florian Westphal wrote:
> Eric W. Biederman  wrote:
> > Julian Anastasov  writes:
> > 
> > >   Hello,
> > >
> > > On Thu, 28 Aug 2014, Simon Kirby wrote:
> > >
> > >> I noticed that [kworker/u16:0]'s stack is often:
> > >> 
> > >> [] wait_rcu_gp+0x46/0x50
> > >> [] synchronize_sched+0x2e/0x50
> > >> [] nf_nat_net_exit+0x2c/0x50 [nf_nat]
> > >
> > >   I guess the problem is in nf_nat_net_exit,
> > > may be other nf exit handlers too. pernet-exit handlers
> > > should avoid synchronize_rcu and rcu_barrier.
> > > A RCU callback and rcu_barrier in module-exit is the way
> > > to go. cleanup_net includes rcu_barrier, so pernet-exit
> > > does not need such calls.
> > 
> > In principle I agree, however in this particular case it looks a bit
> > tricky because a separate hash table to track nat state per network
> > namespace.
> > 
> > At the same time all of the packets should be drained before
> > we get to nf_nat_net_exit so it doesn't look the synchronize_rcu
> > in nf_nat_exit is actually protecting anything.
> 
> Hmm, the problem is with the conntrack entries living in the netns being
> destroyed.
> 
> I don't think they are guaranteed to be removed by the time
> the nat netns exit function runs.
> 
> > Further calling a rcu delay function in net_exit methods largely
> > destroys the batched cleanup of network namespaces, so it is very
> > unpleasant.
> > 
> > Could someone who knows nf_nat_core.c better than I do look and
> > see if we can just remove the synchronize_rcu in nf_nat_exit?
> 
> If I remember correctly its needed to ensure that
> all conntracks with nat extensions that might still be referenced
> on other cpu have finished (i.e., nf_conntrack_destroy() has been
> called, which calls nf_nat_cleanup_conntrack() which deletes
> the extension from the hash table).
> 
> As we remove the ct from that table ourselves EXCEPT in the
> case where we cannot steal the timers' reference we should
> be able to avoid that call virtually every time.
> 
> Perhaps this is worth a shot (not even compile tested):
> 
> diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
> index 4e0b478..80cfe10 100644
> --- a/net/netfilter/nf_nat_core.c
> +++ b/net/netfilter/nf_nat_core.c
> @@ -508,6 +508,7 @@ EXPORT_SYMBOL_GPL(nf_nat_packet);
>  struct nf_nat_proto_clean {
>   u8  l3proto;
>   u8  l4proto;
> + boolneed_sync_rcu;
>  };
> 
>  /* kill conntracks with affected NAT section */
> @@ -528,23 +529,32 @@ static int nf_nat_proto_remove(struct nf_conn *i, void 
> *data)
> 
>  static int nf_nat_proto_clean(struct nf_conn *ct, void *data)
>  {
> + struct nf_nat_proto_clean *clean = data;
>   struct nf_conn_nat *nat = nfct_nat(ct);
> 
> - if (nf_nat_proto_remove(ct, data))
> - return 1;
> -
>   if (!nat || !nat->ct)
>   return 0;
> 
> - /* This netns is being destroyed, and conntrack has nat null binding.
> + /* This netns is being destroyed, and conntrack has nat binding.
>* Remove it from bysource hash, as the table will be freed soon.
>*
> -  * Else, when the conntrack is destoyed, nf_nat_cleanup_conntrack()
> +  * Else, when the conntrack is destroyed, nf_nat_cleanup_conntrack()
>* will delete entry from already-freed table.
>*/
> - if (!del_timer(>timeout))
> + if (!del_timer(>timeout)) {
> + /* We have nat binding, but destruction
> +  * might already be in progress.
> +  *
> +  * nat entry is removed only after last
> +  * nf_ct_put().
> +  */
> + clean->need_sync_rcu = true;

So this happens only if we race with the timer handler?  If so, this
patch might give good speedups.  (Can't comment on any other correctness
issues due to unfamiliarity with the code and what it is trying to do.)

Thanx, Paul

>   return 1;
> + }
> 
> + /* We stole refcount owned by timer;
> +  * conntrack cannot go away.
> +  */
>   spin_lock_bh(_nat_lock);
>   hlist_del_rcu(>bysource);
>   ct->status &= ~IPS_NAT_DONE_MASK;
> @@ -553,6 +563,9 @@ static int nf_nat_proto_clean(struct nf_conn *ct, void 
> *data)
> 
>   add_timer(>timeout);
> 
> + if (nf_nat_proto_remove(ct, data))
> + return 1;
> +
>   /* don't delete conntrack.  Although that would make things a lot
>* simpler, we'd end up flushing all conntracks on nat rmmod.
>*/
> @@ -830,7 +843,8 @@ static void __net_exit nf_nat_net_exit(struct net *net)
>   struct nf_nat_proto_clean clean = {};
> 
>   nf_ct_iterate_cleanup(net, nf_nat_proto_clean, , 0, 0);
> - synchronize_rcu();
> + if (clean.need_sync_rcu)
> + synchronize_rcu();
>   nf_ct_free_hashtable(net->ct.nat_bysource, net->ct.nat_htable_size);
>  }
> 
> 

--
To unsubscribe from this list: send the line 

Re: [kselftest] kselftest wiki (was RE: [Ksummit-discuss] Fwd: Rough notes from testing unconference)

[Shuah Khan]

On Fri, Aug 29, 2014 at 7:09 PM, Bird, Tim  wrote:
> On Saturday, August 23, 2014 6:35 AM, Bird, Tim wrote:
>> Also, I've requested a 'test' wiki on kernel.org, where we can place
>> notes, ideas, and lists of things to work on, or things in progress
>> (like possible output format guidelines).
>>
>> I'll let everyone know when the wiki is set up.
>
> There is now a kselftest wiki on kernel.org at:
> https://kselftest.wiki.kernel.org/
>
> I believe anyone with a Linux Foundation account can edit it.
> I have put together a main page, along with a few sub-pages for
> some of the sub-projects (as I call them) that were discussed at
> the kernel summit.
>
> Please feel free to directly edit the wiki, or to let me know if
> there's any content you'd like to see placed on the wiki.
>

Thanks for doing this.

>
> P.S.  I have copied lkml and linux-api on this.  I believe this is the first
> use of linux-api for discussions about kselftest.  If the linux-api 
> maintainers
> would prefer we get our own list, please let me know.

I spoke to a few folks and gave a heads up to Michael Kerrisk about using
linux-api for kselftest - so far no objections to using it. I sent in
a patch adding
entry for Kselftest framework to MAINTAINERS file with linux-api as the
mailing list. I have a git for this:

git git://git.kernel.org/pub/scm/shuah/linux-kselftest

I couldn't edit the wiki to add this detail even after logging into my
LF account.
Might have to request for access perhaps.

thanks,
-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: net_ns cleanup / RCU overhead

[Paul E. McKenney]

On Thu, Aug 28, 2014 at 05:40:29PM -0700, Simon Kirby wrote:
> On Thu, Aug 28, 2014 at 01:46:58PM -0700, Paul E. McKenney wrote:
> 
> > On Thu, Aug 28, 2014 at 03:33:42PM -0500, Eric W. Biederman wrote:
> > 
> > > I just want to add a little bit more analysis to this.
> > > 
> > > What we desire to be fast is the copy_net_ns, cleanup_net is batched and
> > > asynchronous which nothing really cares how long it takes except that
> > > cleanup_net holds the net_mutex and thus blocks copy_net_ns.
> > > 
> > > The puzzle is why and which rcu delays Simon is seeing in the network
> > > namespace cleanup path, as it seems like the synchronize_rcu is not
> > > the only one, and in the case of vsftp with trivail network namespaces
> > > where nothing has been done we should not need to delay.
> > 
> > Indeed, given the version and .config, I can't see why any individual
> > RCU grace-period operation would be particularly slow.
> > 
> > I suggest using ftrace on synchronize_rcu() and friends.
> 
> I made a parallel net namespace create/destroy benchmark that prints the
> progress and time to create and cleanup 32 unshare()d child processes:
> 
> http://0x.ca/sim/ref/tools/netnsbench.c
> 
> I noticed that if I haven't run it for a while, the first batch often is
> fast, followed by slowness from then on:
> 
>  0.039478s
> -++-++-- 4.463837s
> +--+++-- 3.011882s
> +++---+- 2.283993s
> 
> Fiddling around on a stock kernel, "echo 1 > /sys/kernel/rcu_expedited"
> makes behaviour change as it did with my patch:
> 
> ++-++-+++-+-+-+-++-+-++--++-+--+-+-++--++-+-+-+-++-+--++ 0.801406s
> +-+-+-++-+-+-+-+-++--+-+-++-+--++-+-+-+-+-+-+-+-+-+-+-+--++-+--- 0.872011s
> ++--+-++--+-++--+-++--+-+-+-+-++-+--++--+-++-+-+-+-+--++-+-+-+-- 0.946745s
> 
> How would I use ftrace on synchronize_rcu() here?

http://lwn.net/Articles/370423/ is your friend here.  If your kernel
is built with the needed configuration, you give the command
"echo synchronize_rcu > set_ftrace_filter"

http://lwn.net/Articles/365835/ and http://lwn.net/Articles/366796/
have background info.

> As Eric said, cleanup_net() is batched, but while it is cleaning up,
> net_mutex is held. Isn't the issue just that net_mutex is held while
> some other things are going on that are meant to be lazy / batched?
> 
> What is net_mutex protecting in cleanup_net()?
> 
> I noticed that [kworker/u16:0]'s stack is often:
> 
> [] wait_rcu_gp+0x46/0x50
> [] synchronize_sched+0x2e/0x50
> [] nf_nat_net_exit+0x2c/0x50 [nf_nat]
> [] ops_exit_list.isra.4+0x39/0x60
> [] cleanup_net+0xf0/0x1a0
> [] process_one_work+0x157/0x440
> [] worker_thread+0x63/0x520
> [] kthread+0xd6/0xf0
> [] ret_from_fork+0x7c/0xb0
> [] 0x
> 
> and
> 
> [] _rcu_barrier+0x154/0x1f0
> [] rcu_barrier+0x10/0x20
> [] kmem_cache_destroy+0x6c/0xb0
> [] nf_conntrack_cleanup_net_list+0x167/0x1c0 [nf_conntrack]
> [] nf_conntrack_pernet_exit+0x65/0x70 [nf_conntrack]
> [] ops_exit_list.isra.4+0x53/0x60
> [] cleanup_net+0xf0/0x1a0
> [] process_one_work+0x157/0x440
> [] worker_thread+0x63/0x520
> [] kthread+0xd6/0xf0
> [] ret_from_fork+0x7c/0xb0
> [] 0x
> 
> So I tried flushing iptables rules and rmmoding netfilter bits:
> 
> -++++--- 0.179940s
> ++--+-+- 0.151988s
> ---+--+++--- 0.159967s
> ++--++-- 0.175964s
> 
> Expedited:
> 
> ++-+--++-+-+-+-+-+-+--++-+-+-++-+-+-+--++-+-+-+-+-+-+-+-+-+-+--- 0.079988s
> ++-+-+-+-+-+-+-+-+-+-+-+--++-+--++-+--+-++-+-+--++-+-+-+-+-+-+-- 0.089347s
> --+++--++--+-+++-+--++-+-+--++-+-+--++-- 0.081566s
> +-+++---++-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+--- 0.089026s
> 
> So, much faster. It seems that just loading nf_conntrack_ipv4 (like by
> running iptables -t nat -nvL) is enough to slow it way down. But it is
> still capable of being fast, as above.

My first guess is that this code sequence is calling synchronize_rcu()
quite often.  Would it be possible to consolidate these?

Thanx, Paul

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

Re: [Patch v4] x86, irq, PCI: Keep IRQ assignment for runtime power management

[Jiang Liu]

On 2014/8/30 7:24, Rafael J. Wysocki wrote:
> On Friday, August 29, 2014 04:42:34 PM Rafael J. Wysocki wrote:
>> On Fri, Aug 29, 2014 at 11:26 AM, Jiang Liu  
>> wrote:
>>> Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
>>> We need to keep IRQ assignment for PCI devices during runtime power
>>> management, otherwise it may cause failure of device wakeups.
>>>
>>> Commit 3eec595235c17a7 "x86, irq, PCI: Keep IRQ assignment for PCI
>>> devices during suspend/hibernation" has fixed the issue for suspend/
>>> hibernation, we also need the same fix for runtime device sleep too.
>>>
>>> Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271
>>> Reported-and-Tested-by: EmanueL Czirai 
>>> Signed-off-by: Jiang Liu 
>>> ---
>>>  arch/x86/include/asm/io_apic.h |2 ++
>>>  arch/x86/kernel/apic/io_apic.c |   12 
>>>  arch/x86/pci/intel_mid_pci.c   |2 +-
>>>  arch/x86/pci/irq.c |2 +-
>>>  drivers/acpi/pci_irq.c |4 
>>>  5 files changed, 20 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
>>> index 0aeed5ca356e..478c490f3654 100644
>>> --- a/arch/x86/include/asm/io_apic.h
>>> +++ b/arch/x86/include/asm/io_apic.h
>>> @@ -227,6 +227,8 @@ static inline void io_apic_modify(unsigned int apic, 
>>> unsigned int reg, unsigned
>>>
>>>  extern void io_apic_eoi(unsigned int apic, unsigned int vector);
>>>
>>> +extern bool mp_should_keep_irq(struct device *dev);
>>> +
>>>  #else  /* !CONFIG_X86_IO_APIC */
>>>
>>>  #define io_apic_assign_pci_irqs 0
>>> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
>>> index 29290f554e79..1e9a921d9701 100644
>>> --- a/arch/x86/kernel/apic/io_apic.c
>>> +++ b/arch/x86/kernel/apic/io_apic.c
>>> @@ -3946,6 +3946,18 @@ int mp_set_gsi_attr(u32 gsi, int trigger, int 
>>> polarity, int node)
>>> return ret;
>>>  }
>>>
>>> +bool mp_should_keep_irq(struct device *dev)
>>> +{
>>> +   if (dev->power.is_prepared)
>>> +   return true;
>>> +#ifdef CONFIG_PM_RUNTIME
>>> +   if (dev->power.runtime_status == RPM_SUSPENDING)
>>> +   return true;
>>> +#endif
>>
>> No, you can't do that.  It is racy and incorrect.
> 
> Well, maybe not.
> 
>> Please give me some time for looking into this.
> 
> So I guess the intended check is "Am I running in a suspend callback"?
Hi Rafael,
Yes, we are trying to check whether it's called for suspend.
Function pci_disable_device() may be called when:
1) unbinding PCI driver
2) destroying PCI device
3) suspending for runtime power management or sleep
For case 1 and 2, we should release IRQ assigned. But we need to
keep assigned IRQ for case 3.

So is it safe to check runtime_status and is_prepared flags to detect
case 3? Any better ways?

Regards!
Gerry


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

[alsa-devel] [PATCH v5 0/2] mfd: arizona: add support for INn_MODE register control

[Inha Song]

This patch series add support for INn_MODE register control using platform data.
Each input signal path can be configurated either as a Analogue or Digital using
the INn_MODE registers.

Changes for v5
- Change to use of_property_for_each_u32

Changes for v4
- Update document content for more clarity

Changes for v3
- Change to use of_property_read_u32_array
- Fix a few typos
- Update commit message

Changes for v2
- Change to support
- Update commit message
- Update document content for more clarity

Inha Song (2):
  mfd: arizona: Add support for INn_Mode register control
  mfd: arizona: Update DT binding to support INn_MODE init_data

 Documentation/devicetree/bindings/mfd/arizona.txt |  7 +++
 drivers/mfd/arizona-core.c| 13 +
 2 files changed, 20 insertions(+)

-- 
2.0.0.390.gcb682f8

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

[alsa-devel] [PATCH v5 2/2] mfd: arizona: Update DT binding to support INn_MODE init_data

[Inha Song]

This patch update DT binding to support INn_MODE init_data. Each
input signal path can be configurated either as a Analogue or
Digital using the INn_MODE registers.

Signed-off-by: Inha Song 
Reviewed-by: Charles Keepax 
---
 Documentation/devicetree/bindings/mfd/arizona.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index 5c7e723..7bd1273 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -42,6 +42,13 @@ Optional properties:
 the chip default will be used.  If present exactly five values must
 be specified.
 
+  - wlf,inmode : A list of INn_MODE register values, where n is the number
+of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
+2 (Digital Microphone). If absent, INn_MODE registers set to 0 by default.
+If present, values must be specified less than or equal to the number of
+input singals. If values less than the number of input signals, elements
+that has not been specifed are set to 0 by default.
+
   - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
 they are being externally supplied. As covered in
 Documentation/devicetree/bindings/regulator/regulator.txt
-- 
2.0.0.390.gcb682f8

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

[alsa-devel] [PATCH v5 1/2] mfd: arizona: Add support for INn_Mode register control

[Inha Song]

Some boards need to set the INn_MODE[1:0] register to change
the input signal patch. This wlf,inmode property is optional.
If present, values must be specified less than or equal to
the number of input singals. If values less than the number
of input signals, elements that has not been specifed are set
to 0 by default.

Example:
   - wlf,inmode = <2 0 2>;  /* IN1, IN3 use DMIC */

Signed-off-by: Inha Song 
Reviewed-by: Charles Keepax 
---
 drivers/mfd/arizona-core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 10a0cb9..31757f7 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -534,7 +534,11 @@ EXPORT_SYMBOL_GPL(arizona_of_get_named_gpio);
 static int arizona_of_get_core_pdata(struct arizona *arizona)
 {
struct arizona_pdata *pdata = >pdata;
+   struct property *prop;
+   const __be32 *cur;
+   u32 val;
int ret, i;
+   int count = 0;
 
pdata->reset = arizona_of_get_named_gpio(arizona, "wlf,reset", true);
 
@@ -560,6 +564,15 @@ static int arizona_of_get_core_pdata(struct arizona 
*arizona)
ret);
}
 
+   of_property_for_each_u32(arizona->dev->of_node, "wlf,inmode", prop,
+cur, val) {
+   if (count == ARRAY_SIZE(arizona->pdata.inmode))
+   break;
+
+   arizona->pdata.inmode[count] = val;
+   count++;
+   }
+
return 0;
 }
 
-- 
2.0.0.390.gcb682f8

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

[f2fs-dev][PATCH v2] f2fs: reposition unlock_new_inode to prevent accessing invalid inode

[Chao Yu]

As the race condition on the inode cache, following scenario can appear:
[Thread a]  [Thread b]
->f2fs_mkdir
  ->f2fs_add_link
->__f2fs_add_link
  ->init_inode_metadata failed here
->gc_thread_func
  ->f2fs_gc
->do_garbage_collect
  ->gc_data_segment
->f2fs_iget
  ->iget_locked
->wait_on_inode
  ->unlock_new_inode
->move_data_page
  ->make_bad_inode
  ->iput

When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode
should be set as bad to avoid being accessed by other thread. But in above
scenario, it allows f2fs to access the invalid inode before this inode was set
as bad.
This patch fix the potential problem, and this issue was found by code review.

change log from v1:
 o Add condition judgment in gc_data_segment() suggested by Changman Lee.
 o use iget_failed to simplify code.

Signed-off-by: Chao Yu 
---
 fs/f2fs/gc.c|  2 +-
 fs/f2fs/namei.c | 20 +---
 2 files changed, 6 insertions(+), 16 deletions(-)

diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index e8507b1..943a31d 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -593,7 +593,7 @@ next_step:
 
if (phase == 2) {
inode = f2fs_iget(sb, dni.ino);
-   if (IS_ERR(inode))
+   if (IS_ERR(inode) || is_bad_inode(inode))
continue;
 
start_bidx = start_bidx_of_node(nofs, F2FS_I(inode));
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 6b53ce9..ee103fd 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -134,9 +134,7 @@ static int f2fs_create(struct inode *dir, struct dentry 
*dentry, umode_t mode,
return 0;
 out:
clear_nlink(inode);
-   unlock_new_inode(inode);
-   make_bad_inode(inode);
-   iput(inode);
+   iget_failed(inode);
alloc_nid_failed(sbi, ino);
return err;
 }
@@ -267,9 +265,7 @@ static int f2fs_symlink(struct inode *dir, struct dentry 
*dentry,
return err;
 out:
clear_nlink(inode);
-   unlock_new_inode(inode);
-   make_bad_inode(inode);
-   iput(inode);
+   iget_failed(inode);
alloc_nid_failed(sbi, inode->i_ino);
return err;
 }
@@ -308,9 +304,7 @@ static int f2fs_mkdir(struct inode *dir, struct dentry 
*dentry, umode_t mode)
 out_fail:
clear_inode_flag(F2FS_I(inode), FI_INC_LINK);
clear_nlink(inode);
-   unlock_new_inode(inode);
-   make_bad_inode(inode);
-   iput(inode);
+   iget_failed(inode);
alloc_nid_failed(sbi, inode->i_ino);
return err;
 }
@@ -354,9 +348,7 @@ static int f2fs_mknod(struct inode *dir, struct dentry 
*dentry,
return 0;
 out:
clear_nlink(inode);
-   unlock_new_inode(inode);
-   make_bad_inode(inode);
-   iput(inode);
+   iget_failed(inode);
alloc_nid_failed(sbi, inode->i_ino);
return err;
 }
@@ -688,9 +680,7 @@ release_out:
 out:
f2fs_unlock_op(sbi);
clear_nlink(inode);
-   unlock_new_inode(inode);
-   make_bad_inode(inode);
-   iput(inode);
+   iget_failed(inode);
alloc_nid_failed(sbi, inode->i_ino);
return err;
 }
-- 
2.0.1.474.g72c7794


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

[Hannes Frederic Sowa]

Hi Sabrina,

On Fr, 2014-08-29 at 21:53 +0200, Sabrina Dubroca wrote:
> 2014-08-29, 11:14:48 -0700, Cong Wang wrote:
> > On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala  wrote:
> > > [   77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
> > > [   77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 
> > > 3.17.0-rc2+ #30
> > > [   77.299039] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > > [   77.299789]  88003d76a618 880026133c50 8238ba79
> > > 880037c84520
> > > [   77.300829]  880026133c90 820bd52b 
> > > 82d86c40
> > > [   77.301869]   f76fd1e1 8800382d8000
> > > 8800382d8220
> > > [   77.302906] Call Trace:
> > > [   77.303246]  [] dump_stack+0x4d/0x66
> > > [   77.303928]  [] addrconf_join_solict+0x4b/0xb0
> > > [   77.304731]  [] ipv6_dev_ac_inc+0x2bb/0x330
> > > [   77.305498]  [] ? ac6_seq_start+0x260/0x260
> > > [   77.306257]  [] ipv6_sock_ac_join+0x26e/0x360
> > > [   77.307046]  [] ? ipv6_sock_ac_join+0x99/0x360
> > > [   77.307798]  [] do_ipv6_setsockopt.isra.5+0xa70/0xf20
> > 
> > 
> > I think we should just use rtnl_lock() instead of rcu_read_lock() there,
> > it is not a hot path worth optimization.
> > 
> > Please try the attached patch.
> 
> note: it doesn't build as it is now, it needs:
> 
> -EXPORT_SYMBOL(dev_get_by_flags_rcu);
> +EXPORT_SYMBOL(dev_get_by_flags);
> 
> 
> I just tried your patch with a basic test program (open
> socket/join/leave/close and open socket/join/close).
> 
> I think you need to modify ipv6_sock_ac_close as well, or you can still
> trigger the assertion when closing the socket without leaving first.
> 
> Modified patch attached.

Sorry, just had time to look at this.

The reason is not to have list corruption but that the calls down to
ndo_set_rx_mode expect rtnl to be locked by the drivers. Filter lists
are locked by addr_list_lock and that's why I think we never saw any
problems with that, but drivers expect rtnl locked for those calls.

But this problem also affects multicast join, so patch seems incomplete
to me (and for that matter ssm multicast join, too).

Also rtnl_lock and rcu_read_lock compose in that order, so we don't need
to change dev_get_by_flags, but as this is the only user it sure is
possible. RCU locked version is just easier composeable, so I wouldn't
touch that if needed in future, just also take rcu lock as before.

So just adding rtnl_lock add appropriate places seems to be ok to me,
but still need to review parts of the ssm code.

Also we should move ASSERT_RTNL checks from addrconf_join_solict to
ipv6_dev_mc_inc/dec.

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

[PATCH -mmotm] mm: fix kmemcheck.c build errors

[Randy Dunlap]

From: Randy Dunlap 

Add header file to fix kmemcheck.c build errors:

../mm/kmemcheck.c:70:7: error: dereferencing pointer to incomplete type
../mm/kmemcheck.c:83:15: error: dereferencing pointer to incomplete type
../mm/kmemcheck.c:95:8: error: dereferencing pointer to incomplete type
../mm/kmemcheck.c:95:21: error: dereferencing pointer to incomplete type

Signed-off-by: Randy Dunlap 
---
 mm/kmemcheck.c |1 +
 1 file changed, 1 insertion(+)

Index: mmotm-2014-0829-1515/mm/kmemcheck.c
===
--- mmotm-2014-0829-1515.orig/mm/kmemcheck.c
+++ mmotm-2014-0829-1515/mm/kmemcheck.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void kmemcheck_alloc_shadow(struct page *page, int order, gfp_t flags, int 
node)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: comedi: usbdux: fix sparse endianness warnings

[Chase Southwood]

Sparse has many warnings like:

drivers/staging/comedi/drivers/usbdux.c:366:32: warning: cast to
restricted __le16

on lines on which devpriv->in_buf or devpriv->insn_buf are passed to
le16_to_cpu().  This suggests that both of these variables should actually
be of type __le16.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
This is, as usual, compile tested only.  I tried to verify as best as I
could that this is a sane change, but I am unable to test on the hardware.

 drivers/staging/comedi/drivers/usbdux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/usbdux.c 
b/drivers/staging/comedi/drivers/usbdux.c
index 053bc50..e1a19222 100644
--- a/drivers/staging/comedi/drivers/usbdux.c
+++ b/drivers/staging/comedi/drivers/usbdux.c
@@ -198,9 +198,9 @@ struct usbdux_private {
/* size of the PWM buffer which holds the bit pattern */
int pwm_buf_sz;
/* input buffer for the ISO-transfer */
-   uint16_t *in_buf;
+   __le16 *in_buf;
/* input buffer for single insn */
-   uint16_t *insn_buf;
+   __le16 *insn_buf;
 
unsigned int ao_readback[USBDUX_NUM_AO_CHAN];
 
-- 
2.1.0

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

[PATCH] staging: comedi: usbduxsigma: fix sparse endianness warnings

[Chase Southwood]

Sparse has many warnings like:

drivers/staging/comedi/drivers/usbduxsigma.c:293:21: warning: cast to
restricted __be32

on lines on which devpriv->in_buf is passed to be32_to_cpu().  This
suggests that this variable should actually be of type __be32.

Signed-off-by: Chase Southwood 
Cc: Ian Abbott 
Cc: H Hartley Sweeten 
---
This is, as usual, compile tested only.  I tried to verify as best as I
could that this is a sane change, but I am unable to test on the hardware.

 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/usbduxsigma.c 
b/drivers/staging/comedi/drivers/usbduxsigma.c
index 94a09c1..e9b11e8 100644
--- a/drivers/staging/comedi/drivers/usbduxsigma.c
+++ b/drivers/staging/comedi/drivers/usbduxsigma.c
@@ -157,7 +157,7 @@ struct usbduxsigma_private {
/* size of the PWM buffer which holds the bit pattern */
int pwm_buf_sz;
/* input buffer for the ISO-transfer */
-   uint32_t *in_buf;
+   __be32 *in_buf;
/* input buffer for single insn */
uint8_t *insn_buf;
 
-- 
2.1.0

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

Re: [PATCH v5 1/3] ARM: probes: check stack operation when decoding

[Wang Nan]

On 2014/8/29 16:47, Jon Medhurst (Tixy) wrote:
> On Thu, 2014-08-28 at 11:24 +0100, Will Deacon wrote:
>> On Thu, Aug 28, 2014 at 11:20:21AM +0100, Russell King - ARM Linux wrote:
>>> On Thu, Aug 28, 2014 at 06:51:15PM +0900, Masami Hiramatsu wrote:
 (2014/08/27 22:02), Wang Nan wrote:
> This patch improves arm instruction decoder, allows it check whether an
> instruction is a stack store operation. This information is important
> for kprobe optimization.
>
> For normal str instruction, this patch add a series of _SP_STACK
> register indicator in the decoder to test the base and offset register
> in ldr , [, ] against sp.
>
> For stm instruction, it check sp register in instruction specific
> decoder.

 OK, reviewed. but since I'm not so sure about arm32 ISA,
 I need help from ARM32 maintainer to ack this.
>>>
>>> What you actually need is an ack from the ARM kprobes people who
>>> understand this code.  That would be much more meaningful than my
>>> ack.  They're already on the Cc list.
>>
>> Tixy, can you take a look please?
> 
> I'll take an in depth look on Monday as I'm currently on holiday, so for
> now just some brief and possibly not well thought out comments...
> 
> - If the intent is to not optimise stack push operations, then this
> actually excludes the main use of kprobes which I believe is to insert
> probes at the start of functions (there's even a specific jprobes API
> for that) this is because functions usually start by saving registers on
> the stack.

Agree. If the decoder can bring up more information, kprobeopt can dynamically
compute the range of stack an instruction require, then adjust stack protection 
range.
This need ARM decoder bring up more information. For example: for a "push {r4, 
r5}"
instruction, decoder should report it is a stack store operation, require 8 
bytes
of stack, then when composing trampoline code, we can put registers at
[sp, #-8]. Only instructions such as "str r0, [sp, r1]" should be prevented.

However, this need more improvement on decoder: all store operations should use
a special decorer then. What do you think?

> 
> - Crowbarring in special case testing for stack operations looks a bit
> inelegant and not a sustainable way of doing this, what about the next
> special case we need? However, stack push operations _are_ a general
> special cases for instruction emulation so perhaps that's OK, and leads
> me to...
> 
> - The current 'unoptimised' kprobes implementation allows for pushing on
> the stack (see __und_svc and the unused (?) jprobe_return) but this is
> just aimed at stm instructions, not things like "str r0, [sp, -imm]!"
> that might be used to simultaneously save a register and reserve an
> arbitrary amount of stack space. Probing such instructions could lead to
> the kprobes code trashing the kernel stack.

By a quick search I just find tow instructions matching "str.*\[sp,[^\]]*-[^4]",
one in Ldiv0_64, another in Ldiv0, both are "str lr, [sp, #-8]!". So I think
such instructions are very special.

Furthermore, I thought "unoptimised" kprobe use another stack, could you please
explain how such probing trashing normal kernel stack?

Thank you.


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

Re: mm: BUG in unmap_page_range

[Sasha Levin]

On 08/27/2014 11:26 AM, Mel Gorman wrote:
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 281870f..ffea570 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -723,6 +723,9 @@ static inline pte_t pte_mknuma(pte_t pte)
>  
>   VM_BUG_ON(!(val & _PAGE_PRESENT));
>  
> + /* debugging only, specific to x86 */
> + VM_BUG_ON(val & _PAGE_PROTNONE);
> +
>   val &= ~_PAGE_PRESENT;
>   val |= _PAGE_NUMA;

Triggered again, the first VM_BUG_ON got hit, the second one never did.


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

[kselftest] kselftest wiki (was RE: [Ksummit-discuss] Fwd: Rough notes from testing unconference)

[Bird, Tim]

On Saturday, August 23, 2014 6:35 AM, Bird, Tim wrote:
> Also, I've requested a 'test' wiki on kernel.org, where we can place
> notes, ideas, and lists of things to work on, or things in progress
> (like possible output format guidelines).
> 
> I'll let everyone know when the wiki is set up.

There is now a kselftest wiki on kernel.org at:
https://kselftest.wiki.kernel.org/

I believe anyone with a Linux Foundation account can edit it.
I have put together a main page, along with a few sub-pages for
some of the sub-projects (as I call them) that were discussed at
the kernel summit.

Please feel free to directly edit the wiki, or to let me know if
there's any content you'd like to see placed on the wiki.

 -- Tim

P.S.  I have copied lkml and linux-api on this.  I believe this is the first 
use of linux-api for discussions about kselftest.  If the linux-api maintainers
would prefer we get our own list, please let me know.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support

[Scott Wood]

On Fri, 2014-08-29 at 02:17 -0500, Lu Jingchang-B35083 wrote:
> >-Original Message-
> >From: Wood Scott-B07421
> >Sent: Friday, August 29, 2014 12:26 AM
> >To: Lu Jingchang-B35083
> >Cc: mturque...@linaro.org; linuxppc-...@lists.ozlabs.org; linux-
> >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms
> >CLK_OF_DECLARE support
> >
> >On Thu, 2014-08-28 at 05:05 -0500, Lu Jingchang-B35083 wrote:
> >> >-Original Message-
> >> >From: Wood Scott-B07421
> >> >Sent: Thursday, August 28, 2014 7:34 AM
> >> >To: Lu Jingchang-B35083
> >> >Cc: mturque...@linaro.org; linuxppc-...@lists.ozlabs.org; linux-
> >> >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> >> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based
> >> >platforms CLK_OF_DECLARE support
> >> >
> >> >On Tue, 2014-08-26 at 21:19 -0500, Lu Jingchang-B35083 wrote:
> >> >> >-Original Message-
> >> >> >From: Wood Scott-B07421
> >> >> >Sent: Wednesday, August 27, 2014 6:51 AM
> >> >> >To: Lu Jingchang-B35083
> >> >> >Cc: mturque...@linaro.org; linuxppc-...@lists.ozlabs.org; linux-
> >> >> >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> >> >> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based
> >> >> >platforms CLK_OF_DECLARE support
> >> >> >
> >> >> >On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote:
> >> >> >> +CLK_OF_DECLARE(ppc_core_pll_v1, "fsl,qoriq-core-pll-1.0",
> >> >> >core_pll_init);
> >> >> >> +CLK_OF_DECLARE(ppc_core_pll_v2, "fsl,qoriq-core-pll-2.0",
> >> >> >core_pll_init);
> >> >> >> +CLK_OF_DECLARE(ppc_core_mux_v1, "fsl,qoriq-core-mux-1.0",
> >> >> >core_mux_init);
> >> >> >> +CLK_OF_DECLARE(ppc_core_mux_v2, "fsl,qoriq-core-mux-2.0",
> >> >> >core_mux_init);
> >> >> >
> >> >> >What does this do that the existing platform driver and match
> >> >> >table don't?  Why is it needed for ARM when PPC didn't need it?
> >> >> >
> >> >> >-Scott
> >> >> >
> >> >> Common clk init on ARM platform is initialized earlier via
> >> >> of_clk_init() instead of driver probe method, the of_clk_init will
> >> >> walk a __clk_of_table to init each clk provider in the table, the
> >> >> CLK_OF_DECLARE() macro puts a supported clk in the __clk_of_table
> >> >> for it
> >> >initializing on starup, and the clk system has added some common clk
> >> >such as "fixed-clk"
> >> >> to this table already.
> >> >> So here I add our specific clk init declaration to consist this
> >> >> framework, and the driver probe function will not be needed on ARM.
> >> >
> >> >OK... Is there any reason why the new method won't work on PPC?
> >> >
> >> PPC has little dependence on the clock tree but frequency, it will
> >> work well if adopted I think.
> >
> >I'm just saying it seems redundant to have both.  Even on ARM, won't this
> >result in the clock getting registered twice (albeit with one of those
> >times being too late)?
> >
> >Regardless of what dependence PPC has on the clock tree, what stops this
> >method of enumeration from working on PPC?  Is there anything required
> >other than inserting a call to of_clk_init(NULL) in the arch init code?
> >
> >-Scott
> >
> The of_clk_init is an alternative way to the legacy driver. 
> Latest ARM standard support a default call to of_clk_init(NULL) in its 
> time_init().
> So this is the general way for ARM-based platform.

Why are such things dependent on CPU architecture?

> The clk register layer can detect the twice registration of a same clk and
> avoid the duplicate registration. The dtb should select the compatible for 
> either,
> but not both.

Either but not both of what?

> On LS1021A the driver probe method will not be triggered.
> And for support of of_clk_init on PPC, I think just add a call to it as ARM do
> in time_init()[arch/arm/kernel/time.c] would be ok.

I'd rather see this happen than have the driver have to register itself
differently on different architectures.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: debug_dma_assert_idle - ahci - cpu touching an active dma mapped cacheline

[poma]

On 11.05.2014 12:02, poma wrote:
> 
> [ cut here ]
> WARNING: CPU: 2 PID: 628 at lib/dma-debug.c:593 
> debug_dma_assert_idle+0x159/0x1d0()
> snd_hda_intel :00:07.0: DMA-API: cpu touching an active dma mapped 
> cacheline [cln=0x03074000]
> CPU: 2 PID: 628 Comm: lightdm Not tainted 3.15.0-0.rc5.git0.1.fc21.i686+debug 
> #1
> Call Trace:
>  [] dump_stack+0x48/0x60
>  [] warn_slowpath_common+0x82/0xa0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] ? debug_dma_assert_idle+0x159/0x1d0
>  [] warn_slowpath_fmt+0x3e/0x60
>  [] debug_dma_assert_idle+0x159/0x1d0
>  [] ? anon_vma_prepare+0x29/0x140
>  [] do_wp_page+0xce/0x890
>  [] handle_mm_fault+0x662/0xb70
>  [] __do_page_fault+0x1a7/0x5d0
>  [] ? SyS_futex+0x97/0x180
>  [] ? trace_hardirqs_on_caller+0x1c0/0x1e0
>  [] ? trace_hardirqs_on_caller+0x13c/0x1e0
>  [] ? __do_page_fault+0x5d0/0x5d0
>  [] do_page_fault+0x1a/0x20
>  [] error_code+0x6c/0x74
> ---[ end trace b400a64c04aed387 ]---
> Mapped at:
>  [] debug_dma_alloc_coherent+0x22/0x70
>  [] snd_dma_alloc_pages+0x170/0x260 [snd_pcm]
>  [] snd_dma_alloc_pages_fallback+0x62/0x90 [snd_pcm]
>  [] snd_malloc_sgbuf_pages+0xf0/0x211 [snd_pcm]
>  [] snd_dma_alloc_pages+0x203/0x260 [snd_pcm]
> 

[ cut here ]
WARNING: CPU: 1 PID: 1180 at lib/dma-debug.c:593 
debug_dma_assert_idle+0x159/0x1d0()
ahci :00:09.0: DMA-API: cpu touching an active dma mapped cacheline 
[cln=0x03001000]
Modules linked in: ip6t_rpfilter ip6t_REJECT xt_conntrack cfg80211 rfkill 
ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw mt7601Usta(OE) nouveau kvm_amd ata_generic kvm uas pata_acpi ppdev 
mxm_wmi parport_serial video usb_storage k10temp r8169 i2c_algo_bit ttm 
drm_kms_helper serio_raw microcode parport_pc skge parport mii drm wmi 
i2c_nforce2 i2ccore pata_amd acpi_cpufreq sunrpc
CPU: 1 PID: 1180 Comm: gmain Tainted: G   OE  
3.17.0-0.rc2.git3.1.fc22.i686 #1
...
Call Trace:
 [] dump_stack+0x48/0x60
 [] warn_slowpath_common+0x82/0xa0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] ? debug_dma_assert_idle+0x159/0x1d0
 [] warn_slowpath_fmt+0x3e/0x60
 [] debug_dma_assert_idle+0x159/0x1d0
 [] ? anon_vma_prepare+0x29/0x140
 [] do_wp_page+0xe4/0x8c0
 [] handle_mm_fault+0x662/0xba0
 [] ? __do_page_fault+0x1a7/0x5d0
 [] __do_page_fault+0x208/0x5d0
 [] ? might_fault+0x51/0xb0
 [] ? might_fault+0xa7/0xb0
 [] ? _copy_to_user+0x40/0x60
 [] ? __do_page_fault+0x5d0/0x5d0
 [] do_page_fault+0x1a/0x20
 [] error_code+0x6c/0x74
---[ end trace d1e2e0e42481c1e4 ]---
Mapped at:
 [] debug_dma_alloc_coherent+0x22/0x70
 [] dmam_alloc_coherent+0xdb/0x130
 [] ahci_port_start+0xed/0x230
 [] ata_host_start.part.24+0xcb/0x1b0
 [] ata_host_activate+0x45/0x100

ahci:
00:09.0 SATA controller: NVIDIA Corporation MCP78S [GeForce 8200] AHCI 
Controller (rev a2)
and
snd_hda_intel:
00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High 
Definition Audio (rev a1)
swapped the roles. :)
mt7601Usta is irrelevant as tainter, here.


poma



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block

[Courtney Cavin]

On Sat, Aug 30, 2014 at 02:14:07AM +0200, Stephen Boyd wrote:
> On 08/29/14 16:41, Courtney Cavin wrote:
> > On Sat, Aug 30, 2014 at 01:14:23AM +0200, Bjorn Andersson wrote:
> >> From: Kumar Gala 
> >>
> >> Add driver for Qualcomm MSM Hardware Mutex block that exists on
> >> newer Qualcomm SoCs.
> >>
> >> Cc: Jeffrey Hugo 
> >> Cc: Eric Holmberg 
> >> Cc: Courtney Cavin 
> >> Signed-off-by: Kumar Gala 
> >> [bjorn: added pm_runtime calls, from Courtney,
> >>added sfpb-mutex compatible,
> >>updated DT binding documentation formatting]
> >> Signed-off-by: Bjorn Andersson 
> >> ---
> > [...]
> >> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> >> index 3612cb5..2cd39e2 100644
> >> --- a/drivers/hwspinlock/Kconfig
> >> +++ b/drivers/hwspinlock/Kconfig
> >> @@ -8,6 +8,17 @@ config HWSPINLOCK
> >>  
> >>  menu "Hardware Spinlock drivers"
> >>  
> >> +config HWSPINLOCK_MSM
> >> +  tristate "MSM Hardware Spinlock device"
> >> +  depends on ARCH_QCOM
> > This should also depend on OF, as it won't compile or work without it.
> 
> Doesn't ARCH_QCOM imply OF? ARCH_MULTIPLATFORM has a select USE_OF.

Hrm.  Apparently.

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

Re: [PATCH 3/3] ARM: zynq: DT: Add Ethernet phys

[Florian Fainelli]

On 08/29/2014 04:22 PM, Jason Gunthorpe wrote:
> On Fri, Aug 29, 2014 at 11:23:57AM -0700, Florian Fainelli wrote:
>> On 08/29/2014 10:31 AM, Jason Gunthorpe wrote:
>>> On Fri, Aug 29, 2014 at 08:35:36AM -0700, Sören Brinkmann wrote:
>>>
 The compatible string is listed as optional property for PHYs. So, not
 having one is an option, I guess. But, I'd also prefer to at least keep
 the -c22 one, since I saw problems when I tried using -c45 (the Zed phy
 should support it...).
>>>
>>> -c45 and -c22 use a completely different MDIO protocol, Zed doesn't
>>> have a 10GE port, so it certainly doesn't use -c45.
>>
>> Most recent 1GbE PHYs should also implement clause 45. It is a nice
>> improvement if you are using lot of transactions, otherwise clause 45
>> over clause 22 is suitable and supported by the PHY library (for EEE in
>> particular).
> 
> Oh, that is interesting, I haven't actually seen one of those yet..
> 
> Hum. So that is messy, even if the Zed phy supports the C45 format,
> the macb driver (and by my reading, the Zynq hardware) lacks the
> capability to generate C45 frames.

We should restrict ourselves to clause 45 over clause 22 compatibility
mode, which requires no MDIO bus driver changes.

> 
> It could be supported, but you'd have to use the GPIO bitbang MDIO
> driver to talk to the phy.
> 
> So... that makes the compatible string for the phy even more
> confusing. 'Describe The HW' says it should have both c22 and c45
> listed - however we don't have software support in Linux to negotiate
> c22 and c45 support between the phy bus driver and attached phy :(

Right now, if you set the c45 compatible string, the MDIO bus driver and
the PHY must support native c45 transactions to set phydev->is_c45, if
one or the other, or neither of those work, we will fallback to c22.

The part that is not figured out properly yet is how do we want to
handle functions (e.g: EEE) that are only accessible using c45 (native
or in compatible mode), since the PHY library uses two pairs of
accessors, with the native accessors not falling back to the indirect
accessor...
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Q] threading and scope_process

[Ian Kumlien]

Hi,

I have to admit that this is perhaps not the best time to write this,
late in the evening after work but... =)

A friend of mine recently started to develop things on Linux and got a
bit confused since Linux lacks PTHREAD_SCOPE_PROCESS which just about
all other OS:es seems to implement.

(Ok, so I have only googled a bit but it seems like all BSD:s has it
since quite some time and the
same goes for OS X and Windows)

At first i thought that this should be somewhat simple to simulate
using cgroups but there seems to be
quite a overhead and a learning curve, while implementing this should
be simpler because cgroups exist =)

Using this, and thus only compete with your own processes, should make
some multimedia applications
easier to do and could be usable for other things as well, I did talk
to some realtime people a while back
and they were quite surprised that it was lacking...

So, in conclusion is there a reason for this being missing or is it
just a question of "show me the code"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH V2] PM/CPU: Parallel enalbing nonboot cpus with resume devices

[Rafael J. Wysocki]

On 8/29/2014 5:40 AM, Lan Tianyu wrote:

On 2014年08月22日 16:33, Lan Tianyu wrote:

In the current world, all nonboot cpus are enabled serially during system
resume. System resume sequence is that boot cpu enables nonboot cpu one by
one and then resume devices. Before resuming devices, there are few tasks
assigned to nonboot cpus after they are brought up. This waste cpu usage.

To accelerate S3, this patches allows boot cpu to go forward to resume
devices after bringing up one nonboot cpu. The nonboot cpu will be in
charge of bringing up other cpus. This makes enabling cpu2~x parallel
with resuming devices.

Signed-off-by: Lan Tianyu 
---
Change since V1:
Remove PM_PARALLEL_CPU_UP_FOR_SUSPEND kernel config and make
paralleling cpu as default behaviour. Add error handling for
failure of the first frozen cpu online.

So far, I just tested the patch on the Intel machines. It's better
to test it on the others Arch platforms. Appreciate a lot if some
one can help test it.


Hi All:
Any comments on this patch?  Thanks.


You need to ensure that the async thing completes before 
cpufreq_resume() or bad things will happen I think.



  kernel/cpu.c | 70 +---
  1 file changed, 58 insertions(+), 12 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index a343bde..9bc8497 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -551,8 +551,42 @@ void __weak arch_enable_nonboot_cpus_end(void)
  {
  }
  
+static int _cpu_up_with_trace(int cpu)


Better name?


+{
+   int error;
+
+   trace_suspend_resume(TPS("CPU_ON"), cpu, true);
+   error = _cpu_up(cpu, 1);
+   trace_suspend_resume(TPS("CPU_ON"), cpu, false);
+   if (error) {
+   pr_warn("Error taking CPU%d up: %d\n", cpu, error);
+   return error;
+   }
+
+   pr_info("CPU%d is up\n", cpu);
+   return 0;
+}
+
+static int async_enable_nonboot_cpus(void *data)
+{
+   int cpu;
+
+   cpu_maps_update_begin();
+   arch_enable_nonboot_cpus_begin();


Shouldn't you call this before trying to bring up the first one?


+
+   for_each_cpu(cpu, frozen_cpus) {
+   _cpu_up_with_trace(cpu);
+   }
+
+   arch_enable_nonboot_cpus_end();
+   cpumask_clear(frozen_cpus);
+   cpu_maps_update_done();
+   return 0;
+}
+
  void __ref enable_nonboot_cpus(void)
  {
+   struct task_struct *tsk;
int cpu, error;
  
  	/* Allow everyone to use the CPU hotplug again */

@@ -563,22 +597,34 @@ void __ref enable_nonboot_cpus(void)
  
  	pr_info("Enabling non-boot CPUs ...\n");
  
-	arch_enable_nonboot_cpus_begin();

+   cpu = cpumask_first(frozen_cpus);
+   cpumask_clear_cpu(cpu, frozen_cpus);
  
-	for_each_cpu(cpu, frozen_cpus) {

-   trace_suspend_resume(TPS("CPU_ON"), cpu, true);
-   error = _cpu_up(cpu, 1);
-   trace_suspend_resume(TPS("CPU_ON"), cpu, false);
-   if (!error) {
-   pr_info("CPU%d is up\n", cpu);
-   continue;
+   error = _cpu_up_with_trace(cpu);
+   if (cpumask_empty(frozen_cpus))
+   goto out;
+
+   if (error) {
+   /*
+* If fail to bring up the first frozen cpus,
+* enable the rest frozen cpus on the boot cpu.
+*/
+   arch_enable_nonboot_cpus_begin();
+   for_each_cpu(cpu, frozen_cpus) {
+   _cpu_up_with_trace(cpu);
}
-   pr_warn("Error taking CPU%d up: %d\n", cpu, error);
-   }
+   arch_enable_nonboot_cpus_end();
  
-	arch_enable_nonboot_cpus_end();

+   } else {
+   tsk = kthread_create_on_cpu(async_enable_nonboot_cpus,
+   NULL, cpu, "async-enable-nonboot-cpus");


Does it really need to run on the other CPU?  If the idea is to avoid 
waiting mostly, the async thread can start running on the boot CPU just 
fine I suppose.



+   if (IS_ERR(tsk)) {
+   pr_err("Failed to create async enable nonboot cpus 
thread.\n");
+   goto out;
+   }
  
-	cpumask_clear(frozen_cpus);

+   kthread_unpark(tsk);
+   }
  out:
cpu_maps_update_done();
  }





Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block

[Stephen Boyd]

On 08/29/14 16:41, Courtney Cavin wrote:
> On Sat, Aug 30, 2014 at 01:14:23AM +0200, Bjorn Andersson wrote:
>> From: Kumar Gala 
>>
>> Add driver for Qualcomm MSM Hardware Mutex block that exists on
>> newer Qualcomm SoCs.
>>
>> Cc: Jeffrey Hugo 
>> Cc: Eric Holmberg 
>> Cc: Courtney Cavin 
>> Signed-off-by: Kumar Gala 
>> [bjorn: added pm_runtime calls, from Courtney,
>>  added sfpb-mutex compatible,
>>  updated DT binding documentation formatting]
>> Signed-off-by: Bjorn Andersson 
>> ---
> [...]
>> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
>> index 3612cb5..2cd39e2 100644
>> --- a/drivers/hwspinlock/Kconfig
>> +++ b/drivers/hwspinlock/Kconfig
>> @@ -8,6 +8,17 @@ config HWSPINLOCK
>>  
>>  menu "Hardware Spinlock drivers"
>>  
>> +config HWSPINLOCK_MSM
>> +tristate "MSM Hardware Spinlock device"
>> +depends on ARCH_QCOM
> This should also depend on OF, as it won't compile or work without it.

Doesn't ARCH_QCOM imply OF? ARCH_MULTIPLATFORM has a select USE_OF.

>
>> +select HWSPINLOCK
>> +help
>> +  Say y here to support the MSM Hardware Mutex functionality, which
>> +  provides a synchronisation mechanism for the various processors on
>> +  the SoC.
>> +
>> +  If unsure, say N.
>> +
>>

Maybe MSM should be changed to qcom? Just a thought.

-- 
Qualcomm Innovation Center, Inc. is a member of 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/

[RFC PATCH v4] tpm_tis: verify interrupt during init

[Scot Doyle]

On Thu, 28 Aug 2014, Jason Gunthorpe wrote:

> On Thu, Aug 28, 2014 at 12:35:16AM +, Scot Doyle wrote:
>
>>> To move it means we have to understand why you are getting timeouts:
>>>
>>> [   33.247720] tpm_tis 00:08: tpm_transmit: tpm_send: error -62
>>> [   33.247731] tpm_tis 00:08: [Hardware Error]: TPM command timed out 
>>> during continue self test
>>>
>>> I had thought based on your other patch that these should not happen
>>> since the raw register is polled after the timer expires?
>>
>> It is polled after the timer expires in tpm_tis_send_data, but not in
>> tpm_tis_send, and the return value is used in tpm_tis_send...
>
> tpm_tis_send does:
>
> wait_for_tpm_stat
>   (chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
>tpm_calc_ordinal_duration(chip, ordinal),
>>vendor.read_queue, false)
>
> Which is:
>   rc = wait_event_interruptible_timeout(*queue,
>   wait_for_tpm_stat_cond(chip, mask, check_cancel,
>  ),
>
> And we know that wait_event_interruptible_timeout returns 1 if
> the condition is true when the timeout expires.
>
> So, all calls to wait_for_tpm_stat should succeed if the register has
> the requested bits set at the end of the timer - thus if interrupts
> are broken we should never see ETIME from wait_for_tpm_stat as the
> chip does actually complete its work. (and this is the correct,
> desired, behavior)
>
> Is this analysis wrong somehow?

Something (systemd-udevd?) is interrupting the selftest with a signal 
(current->pending.signal.sig[0] == 0x0100 == SIGKILL?) about 30 
seconds after module load begins. wait_for_tpm_stat sees that the return 
value from wait_event_interruptible_timeout is positive and returns 0. 
tpm_tis_send thinks everything is fine and continues. However, since a 
signal was received, but not cleared, then the next time 
wait_event_interruptible_timeout is used within wait_for_tpm_stat it 
returns with -ERESTARTSYS, and continues doing so until tpm_send_data 
returns -ETIME.

So I think that mystery is finally solved :-)

The attached patch results in the following output:
[1.536850] tpm_tis 00:08: 1.2 TPM (device-id 0xB, rev-id 16)
[7.650172] tpm_tis 00:08: [Firmware Bug]: TPM interrupt not working, 
polling instead

I tried calling tpm_get_timeouts only during the interrupt test, but again 
was timed out after 30 seconds. The interrupt wait in tis_send calls 
tpm_calc_ordinal_duration, which uses a default timeout of two minutes 
when chip->vendor.duration[duration_idx] hasn't been set. Thus the second 
call to tpm_get_timeouts in tpm_tis_init.

What do you think about the guard logic? My intent is to prevent a signal 
received after the test period from causing a fallback to polling mode. 
Plus, it seems good to preserve the current logic where practical.

Thanks so much for the help!

---
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 2c46734..92f4ab5 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -75,6 +75,11 @@ enum tis_defaults {
 #defineTPM_DID_VID(l)  (0x0F00 | ((l) << 12))
 #defineTPM_RID(l)  (0x0F04 | ((l) << 12))

+struct priv_data {
+   bool testing_int;
+   bool int_received;
+};
+
 static LIST_HEAD(tis_chips);
 static DEFINE_MUTEX(tis_lock);

@@ -338,6 +343,21 @@ out_err:
return rc;
 }

+static void disable_interrupts(struct tpm_chip *chip)
+{
+   u32 intmask;
+   intmask =
+   ioread32(chip->vendor.iobase +
+TPM_INT_ENABLE(chip->vendor.locality));
+   intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
+  TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
+   iowrite32(intmask,
+ chip->vendor.iobase +
+ TPM_INT_ENABLE(chip->vendor.locality));
+   free_irq(chip->vendor.irq, chip);
+   chip->vendor.irq = 0;
+}
+
 /*
  * If interrupts are used (signaled by an irq set in the vendor structure)
  * tpm.c can skip polling for the data to be available as the interrupt is
@@ -347,6 +367,7 @@ static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, 
size_t len)
 {
int rc;
u32 ordinal;
+   struct priv_data *priv = chip->vendor.priv;

rc = tpm_tis_send_data(chip, buf, len);
if (rc < 0)
@@ -366,6 +387,15 @@ static int tpm_tis_send(struct tpm_chip *chip, u8 *buf, 
size_t len)
goto out_err;
}
}
+   if (priv->testing_int) {
+   priv->testing_int = false;
+   msleep(1);
+   if (!priv->int_received) {
+   disable_interrupts(chip);
+   dev_err(chip->dev,
+   FW_BUG "TPM interrupt not working, polling 
instead\n");
+   }
+   }
return len;
 out_err:

Re: net_ns cleanup / RCU overhead

[Florian Westphal]

Eric W. Biederman  wrote:
> Julian Anastasov  writes:
> 
> > Hello,
> >
> > On Thu, 28 Aug 2014, Simon Kirby wrote:
> >
> >> I noticed that [kworker/u16:0]'s stack is often:
> >> 
> >> [] wait_rcu_gp+0x46/0x50
> >> [] synchronize_sched+0x2e/0x50
> >> [] nf_nat_net_exit+0x2c/0x50 [nf_nat]
> >
> > I guess the problem is in nf_nat_net_exit,
> > may be other nf exit handlers too. pernet-exit handlers
> > should avoid synchronize_rcu and rcu_barrier.
> > A RCU callback and rcu_barrier in module-exit is the way
> > to go. cleanup_net includes rcu_barrier, so pernet-exit
> > does not need such calls.
> 
> In principle I agree, however in this particular case it looks a bit
> tricky because a separate hash table to track nat state per network
> namespace.
> 
> At the same time all of the packets should be drained before
> we get to nf_nat_net_exit so it doesn't look the synchronize_rcu
> in nf_nat_exit is actually protecting anything.

Hmm, the problem is with the conntrack entries living in the netns being
destroyed.

I don't think they are guaranteed to be removed by the time
the nat netns exit function runs.

> Further calling a rcu delay function in net_exit methods largely
> destroys the batched cleanup of network namespaces, so it is very
> unpleasant.
> 
> Could someone who knows nf_nat_core.c better than I do look and
> see if we can just remove the synchronize_rcu in nf_nat_exit?

If I remember correctly its needed to ensure that
all conntracks with nat extensions that might still be referenced
on other cpu have finished (i.e., nf_conntrack_destroy() has been
called, which calls nf_nat_cleanup_conntrack() which deletes
the extension from the hash table).

As we remove the ct from that table ourselves EXCEPT in the
case where we cannot steal the timers' reference we should
be able to avoid that call virtually every time.

Perhaps this is worth a shot (not even compile tested):

diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 4e0b478..80cfe10 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -508,6 +508,7 @@ EXPORT_SYMBOL_GPL(nf_nat_packet);
 struct nf_nat_proto_clean {
u8  l3proto;
u8  l4proto;
+   boolneed_sync_rcu;
 };
 
 /* kill conntracks with affected NAT section */
@@ -528,23 +529,32 @@ static int nf_nat_proto_remove(struct nf_conn *i, void 
*data)
 
 static int nf_nat_proto_clean(struct nf_conn *ct, void *data)
 {
+   struct nf_nat_proto_clean *clean = data;
struct nf_conn_nat *nat = nfct_nat(ct);
 
-   if (nf_nat_proto_remove(ct, data))
-   return 1;
-
if (!nat || !nat->ct)
return 0;
 
-   /* This netns is being destroyed, and conntrack has nat null binding.
+   /* This netns is being destroyed, and conntrack has nat binding.
 * Remove it from bysource hash, as the table will be freed soon.
 *
-* Else, when the conntrack is destoyed, nf_nat_cleanup_conntrack()
+* Else, when the conntrack is destroyed, nf_nat_cleanup_conntrack()
 * will delete entry from already-freed table.
 */
-   if (!del_timer(>timeout))
+   if (!del_timer(>timeout)) {
+   /* We have nat binding, but destruction
+* might already be in progress.
+*
+* nat entry is removed only after last
+* nf_ct_put().
+*/
+   clean->need_sync_rcu = true;
return 1;
+   }
 
+   /* We stole refcount owned by timer;
+* conntrack cannot go away.
+*/
spin_lock_bh(_nat_lock);
hlist_del_rcu(>bysource);
ct->status &= ~IPS_NAT_DONE_MASK;
@@ -553,6 +563,9 @@ static int nf_nat_proto_clean(struct nf_conn *ct, void 
*data)
 
add_timer(>timeout);
 
+   if (nf_nat_proto_remove(ct, data))
+   return 1;
+
/* don't delete conntrack.  Although that would make things a lot
 * simpler, we'd end up flushing all conntracks on nat rmmod.
 */
@@ -830,7 +843,8 @@ static void __net_exit nf_nat_net_exit(struct net *net)
struct nf_nat_proto_clean clean = {};
 
nf_ct_iterate_cleanup(net, nf_nat_proto_clean, , 0, 0);
-   synchronize_rcu();
+   if (clean.need_sync_rcu)
+   synchronize_rcu();
nf_ct_free_hashtable(net->ct.nat_bysource, net->ct.nat_htable_size);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block

[Courtney Cavin]

On Sat, Aug 30, 2014 at 01:14:23AM +0200, Bjorn Andersson wrote:
> From: Kumar Gala 
> 
> Add driver for Qualcomm MSM Hardware Mutex block that exists on
> newer Qualcomm SoCs.
> 
> Cc: Jeffrey Hugo 
> Cc: Eric Holmberg 
> Cc: Courtney Cavin 
> Signed-off-by: Kumar Gala 
> [bjorn: added pm_runtime calls, from Courtney,
>   added sfpb-mutex compatible,
>   updated DT binding documentation formatting]
> Signed-off-by: Bjorn Andersson 
> ---
[...]
> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> index 3612cb5..2cd39e2 100644
> --- a/drivers/hwspinlock/Kconfig
> +++ b/drivers/hwspinlock/Kconfig
> @@ -8,6 +8,17 @@ config HWSPINLOCK
>  
>  menu "Hardware Spinlock drivers"
>  
> +config HWSPINLOCK_MSM
> + tristate "MSM Hardware Spinlock device"
> + depends on ARCH_QCOM

This should also depend on OF, as it won't compile or work without it.

> + select HWSPINLOCK
> + help
> +   Say y here to support the MSM Hardware Mutex functionality, which
> +   provides a synchronisation mechanism for the various processors on
> +   the SoC.
> +
> +   If unsure, say N.
> +
>  config HWSPINLOCK_OMAP
>   tristate "OMAP Hardware Spinlock device"
>   depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || 
> SOC_AM43XX
[...]
> +static const struct of_device_id msm_hwspinlock_of_match[] = {
> + { .compatible = "qcom,sfpb-mutex", .data = (void *)0x4 },
> + { .compatible = "qcom,tcsr-mutex", .data = (void *)0x80 },
> + { },
> +};

MODULE_DEVICE_TABLE(of, msm_hwspinlock_of_match); ?

[...]
> +static struct platform_driver msm_hwspinlock_driver = {
> + .probe  = msm_hwspinlock_probe,
> + .remove = msm_hwspinlock_remove,
> + .driver = {
> + .name   = "msm_hwspinlock",
> + .owner  = THIS_MODULE,

No need, as:

#define platform_driver_register(drv) \
__platform_driver_register(drv, THIS_MODULE)
extern int __platform_driver_register(struct platform_driver *,
struct module *);

> + .of_match_table = msm_hwspinlock_of_match,
> + },
> +};

Otherwise, looks fine.

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

Re: [PATCH 3/3] ARM: zynq: DT: Add Ethernet phys

[Jason Gunthorpe]

On Fri, Aug 29, 2014 at 11:23:57AM -0700, Florian Fainelli wrote:
> On 08/29/2014 10:31 AM, Jason Gunthorpe wrote:
> > On Fri, Aug 29, 2014 at 08:35:36AM -0700, Sören Brinkmann wrote:
> > 
> >> The compatible string is listed as optional property for PHYs. So, not
> >> having one is an option, I guess. But, I'd also prefer to at least keep
> >> the -c22 one, since I saw problems when I tried using -c45 (the Zed phy
> >> should support it...).
> > 
> > -c45 and -c22 use a completely different MDIO protocol, Zed doesn't
> > have a 10GE port, so it certainly doesn't use -c45.
> 
> Most recent 1GbE PHYs should also implement clause 45. It is a nice
> improvement if you are using lot of transactions, otherwise clause 45
> over clause 22 is suitable and supported by the PHY library (for EEE in
> particular).

Oh, that is interesting, I haven't actually seen one of those yet..

Hum. So that is messy, even if the Zed phy supports the C45 format,
the macb driver (and by my reading, the Zynq hardware) lacks the
capability to generate C45 frames.

It could be supported, but you'd have to use the GPIO bitbang MDIO
driver to talk to the phy.

So... that makes the compatible string for the phy even more
confusing. 'Describe The HW' says it should have both c22 and c45
listed - however we don't have software support in Linux to negotiate
c22 and c45 support between the phy bus driver and attached phy :(

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/

[PATCH v2] hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block

[Bjorn Andersson]

From: Kumar Gala 

Add driver for Qualcomm MSM Hardware Mutex block that exists on
newer Qualcomm SoCs.

Cc: Jeffrey Hugo 
Cc: Eric Holmberg 
Cc: Courtney Cavin 
Signed-off-by: Kumar Gala 
[bjorn: added pm_runtime calls, from Courtney,
added sfpb-mutex compatible,
updated DT binding documentation formatting]
Signed-off-by: Bjorn Andersson 
---

We need this driver to add support for the shared memory manager, so I'm
reviving Kumars patch from a year ago, with some additional sprinkles on top.

Changes since v1:
 - Added the pm_runtime calls needed to be able to boot a kernel with
   pm_runtime and this driver, patch from Courtney.
 - Added sfpb-mutex compatible, for re-use of the driver in family A platforms.
 - Updated formatting of DT binding documentation, while adding the extra
   compatible.
 - Dropped Stephen Boyds Reviewed-by due to these changes.

 .../devicetree/bindings/hwlock/msm-hwspinlock.txt  |  35 +
 drivers/hwspinlock/Kconfig |  11 ++
 drivers/hwspinlock/Makefile|   1 +
 drivers/hwspinlock/msm_hwspinlock.c| 155 +
 4 files changed, 202 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/msm-hwspinlock.txt
 create mode 100644 drivers/hwspinlock/msm_hwspinlock.c

diff --git a/Documentation/devicetree/bindings/hwlock/msm-hwspinlock.txt 
b/Documentation/devicetree/bindings/hwlock/msm-hwspinlock.txt
new file mode 100644
index 000..65d9ab0
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/msm-hwspinlock.txt
@@ -0,0 +1,35 @@
+Qualcomm MSM Hardware Mutex Block:
+
+The hardware block provides mutexes utilized between different processors
+on the SoC as part of the communication protocol used by these processors.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,sfpb-mutex",
+   "qcom,tcsr-mutex"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: base address and size of the mutex registers
+
+- reg-names:
+   Usage: required
+   Value type: 
+   Definition: must be "mutex-base"
+
+- qcom,num-locks:
+   Usage: required
+   Value type: 
+   Definition: the number of locks/mutex available in this block
+
+Example:
+
+   hwlock@fd484000 {
+   compatible = "qcom,tcsr-mutex";
+   reg = <0xfd484000 0x1000>;
+   reg-names = "mutex-base";
+   qcom,num-locks = <32>;
+   };
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 3612cb5..2cd39e2 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -8,6 +8,17 @@ config HWSPINLOCK
 
 menu "Hardware Spinlock drivers"
 
+config HWSPINLOCK_MSM
+   tristate "MSM Hardware Spinlock device"
+   depends on ARCH_QCOM
+   select HWSPINLOCK
+   help
+ Say y here to support the MSM Hardware Mutex functionality, which
+ provides a synchronisation mechanism for the various processors on
+ the SoC.
+
+ If unsure, say N.
+
 config HWSPINLOCK_OMAP
tristate "OMAP Hardware Spinlock device"
depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || 
SOC_AM43XX
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index 93eb64b..4074c56 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -3,5 +3,6 @@
 #
 
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock_core.o
+obj-$(CONFIG_HWSPINLOCK_MSM)   += msm_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_OMAP)  += omap_hwspinlock.o
 obj-$(CONFIG_HSEM_U8500)   += u8500_hsem.o
diff --git a/drivers/hwspinlock/msm_hwspinlock.c 
b/drivers/hwspinlock/msm_hwspinlock.c
new file mode 100644
index 000..9ddd020
--- /dev/null
+++ b/drivers/hwspinlock/msm_hwspinlock.c
@@ -0,0 +1,155 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hwspinlock_internal.h"
+
+#define SPINLOCK_ID_APPS_PROC  1
+#define BASE_ID0
+
+static int msm_hwspinlock_trylock(struct hwspinlock *lock)
+{
+   void __iomem *lock_addr = lock->priv;
+
+   writel_relaxed(SPINLOCK_ID_APPS_PROC, lock_addr);
+
+   return readl_relaxed(lock_addr) == SPINLOCK_ID_APPS_PROC;
+}
+
+static void msm_hwspinlock_unlock(struct 

Re: [PATCH RFC] rcu: assoc_array: Add critical section to avoid a bug

[Andreea Bernat]

On Fri, Aug 29, 2014 at 11:49:04PM +0100, David Howells wrote:
> Andreea Bernat  wrote:
> 
> > Looks good to me.
> 
> Can I put that down as a Reviewed-by?

Yes, it is OK.

Regards,
Andreea

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

Re: [Patch v4] x86, irq, PCI: Keep IRQ assignment for runtime power management

[Rafael J. Wysocki]

On Friday, August 29, 2014 04:42:34 PM Rafael J. Wysocki wrote:
> On Fri, Aug 29, 2014 at 11:26 AM, Jiang Liu  wrote:
> > Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
> > We need to keep IRQ assignment for PCI devices during runtime power
> > management, otherwise it may cause failure of device wakeups.
> >
> > Commit 3eec595235c17a7 "x86, irq, PCI: Keep IRQ assignment for PCI
> > devices during suspend/hibernation" has fixed the issue for suspend/
> > hibernation, we also need the same fix for runtime device sleep too.
> >
> > Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271
> > Reported-and-Tested-by: EmanueL Czirai 
> > Signed-off-by: Jiang Liu 
> > ---
> >  arch/x86/include/asm/io_apic.h |2 ++
> >  arch/x86/kernel/apic/io_apic.c |   12 
> >  arch/x86/pci/intel_mid_pci.c   |2 +-
> >  arch/x86/pci/irq.c |2 +-
> >  drivers/acpi/pci_irq.c |4 
> >  5 files changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> > index 0aeed5ca356e..478c490f3654 100644
> > --- a/arch/x86/include/asm/io_apic.h
> > +++ b/arch/x86/include/asm/io_apic.h
> > @@ -227,6 +227,8 @@ static inline void io_apic_modify(unsigned int apic, 
> > unsigned int reg, unsigned
> >
> >  extern void io_apic_eoi(unsigned int apic, unsigned int vector);
> >
> > +extern bool mp_should_keep_irq(struct device *dev);
> > +
> >  #else  /* !CONFIG_X86_IO_APIC */
> >
> >  #define io_apic_assign_pci_irqs 0
> > diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> > index 29290f554e79..1e9a921d9701 100644
> > --- a/arch/x86/kernel/apic/io_apic.c
> > +++ b/arch/x86/kernel/apic/io_apic.c
> > @@ -3946,6 +3946,18 @@ int mp_set_gsi_attr(u32 gsi, int trigger, int 
> > polarity, int node)
> > return ret;
> >  }
> >
> > +bool mp_should_keep_irq(struct device *dev)
> > +{
> > +   if (dev->power.is_prepared)
> > +   return true;
> > +#ifdef CONFIG_PM_RUNTIME
> > +   if (dev->power.runtime_status == RPM_SUSPENDING)
> > +   return true;
> > +#endif
> 
> No, you can't do that.  It is racy and incorrect.

Well, maybe not.

> Please give me some time for looking into this.

So I guess the intended check is "Am I running in a suspend callback"?

Rafael

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

Re: [PATCH v8 net-next 2/2] net: filter: split filter.h and expose eBPF to user space

[Alexei Starovoitov]

On Fri, Aug 29, 2014 at 3:24 PM, Daniel Borkmann  wrote:
>>
>> Also I really dislike 'ebpf' name in all lower case. If we make such
>> header
>> file name, we would need to rename all macros and function names
>> to EBPF_... which I find very ugly looking. I think all good abbreviations
>> are
>> three letters :)
>
>
> I don't think we would have to name defines that way, really, that would be
> terrible. We can keep them simply *as is*. Not sure though why bpf.h +
> ebpf.h
> would be that bad. ;) I haven't tried it out yet, but if we would indeed run
> into a name collision, above proposal would resolve that.

imo it's a consistency issue. If main uapi header is ebpf.h then
corresponding kernel internal header should be ebpf.h as well
and kernel/ebpf/ directory and so on.
That's why I insist on uapi/linux/bpf.h and no other name.
Note I didn't move any of the BPF_ALU64_REG, BPF_ALU32_IMM
macros from linux/filter.h. Without them my verifier testsuite
won't compile, so more lines would be added to bpf.h in the future.
At that time we can take 45 lines out of uapi/linux/filter.h and move
them into bpf_common.h. My request is let's not fight about it
right now. We didn't even cross the bridge yet and arguing
about beauty of user apps that come in 30 patches from now...

These two patches are about _intent_ of making eBPF usable
from userspace, so I can move along with llvm.
Also worth noting that llmv will not be including this uapi/linux/bpf.h
It has its own infra to generate instructions. Look at:
tools/bpf/llvm/lib/Target/BPF/BPFInstrInfo.td
it's a special 'table definition' language for describing bits and fields
of instructions.
So these two patches are mainly establishing _intent_ and bpf.h file
name. That's why I'm so paranoid about naming.

btw, I've spent last two days writing syscall manpage :(
What is the best way to present it for review?
If I just attach it raw, it's unreadable... I can include a link
to html page, but man2html produces ugly pages comparing
to what 'man' command shows. Any nice man converters
that generate stuff seen on man7.org ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RTNL: assertion failed at net/ipv6/addrconf.c (1699)

[Cong Wang]

On Fri, Aug 29, 2014 at 12:53 PM, Sabrina Dubroca  wrote:
> 2014-08-29, 11:14:48 -0700, Cong Wang wrote:
>> On Fri, Aug 29, 2014 at 8:26 AM, Tommi Rantala  wrote:
>> > [   77.297196] RTNL: assertion failed at net/ipv6/addrconf.c (1699)
>> > [   77.298080] CPU: 0 PID: 4842 Comm: trinity-main Not tainted 3.17.0-rc2+ 
>> > #30
>> > [   77.299039] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>> > [   77.299789]  88003d76a618 880026133c50 8238ba79
>> > 880037c84520
>> > [   77.300829]  880026133c90 820bd52b 
>> > 82d86c40
>> > [   77.301869]   f76fd1e1 8800382d8000
>> > 8800382d8220
>> > [   77.302906] Call Trace:
>> > [   77.303246]  [] dump_stack+0x4d/0x66
>> > [   77.303928]  [] addrconf_join_solict+0x4b/0xb0
>> > [   77.304731]  [] ipv6_dev_ac_inc+0x2bb/0x330
>> > [   77.305498]  [] ? ac6_seq_start+0x260/0x260
>> > [   77.306257]  [] ipv6_sock_ac_join+0x26e/0x360
>> > [   77.307046]  [] ? ipv6_sock_ac_join+0x99/0x360
>> > [   77.307798]  [] do_ipv6_setsockopt.isra.5+0xa70/0xf20
>>
>>
>> I think we should just use rtnl_lock() instead of rcu_read_lock() there,
>> it is not a hot path worth optimization.
>>
>> Please try the attached patch.
>
> note: it doesn't build as it is now, it needs:
>
> -EXPORT_SYMBOL(dev_get_by_flags_rcu);
> +EXPORT_SYMBOL(dev_get_by_flags);
>
>
> I just tried your patch with a basic test program (open
> socket/join/leave/close and open socket/join/close).
>
> I think you need to modify ipv6_sock_ac_close as well, or you can still
> trigger the assertion when closing the socket without leaving first.

You are absolutely right here.

Can I have your Signed-off-by and Tested-by before sending the patch
formally?

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 RFC] rcu: assoc_array: Add critical section to avoid a bug

[David Howells]

Andreea Bernat  wrote:

> Looks good to me.

Can I put that down as a Reviewed-by?

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

[GIT PULL] x86 fixes for v3.17-rc3

[H. Peter Anvin]

Hi Linus,

One patch to avoid assigning interrupts we don't actually have on
non-PC platforms, and two patches that addresses bugs in the new
IOAPIC assignment code.

The following changes since commit 7be141d0554921751db103b54e9f794956aa4f65:

  Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2014-08-24 16:17:41 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus

for you to fetch changes up to 9eabc99a635a77cbf0948ce17d3cbc2b51680d4a:

  x86, irq, PCI: Keep IRQ assignment for runtime power management (2014-08-29 
13:38:00 +0200)


Andy Shevchenko (1):
  x86: Fix non-PC platform kernel crash on boot due to NULL dereference

Jiang Liu (2):
  x86: irq: Fix bug in setting IOAPIC pin attributes
  x86, irq, PCI: Keep IRQ assignment for runtime power management

 arch/x86/include/asm/io_apic.h |  2 ++
 arch/x86/kernel/apic/io_apic.c | 27 ++-
 arch/x86/kernel/irqinit.c  |  2 +-
 arch/x86/kernel/time.c |  2 ++
 arch/x86/pci/intel_mid_pci.c   |  2 +-
 arch/x86/pci/irq.c |  2 +-
 drivers/acpi/pci_irq.c |  4 
 7 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 0aeed5c..478c490 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -227,6 +227,8 @@ static inline void io_apic_modify(unsigned int apic, 
unsigned int reg, unsigned
 
 extern void io_apic_eoi(unsigned int apic, unsigned int vector);
 
+extern bool mp_should_keep_irq(struct device *dev);
+
 #else  /* !CONFIG_X86_IO_APIC */
 
 #define io_apic_assign_pci_irqs 0
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 29290f5..337ce5a 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1070,6 +1070,11 @@ static int mp_map_pin_to_irq(u32 gsi, int idx, int 
ioapic, int pin,
}
 
if (flags & IOAPIC_MAP_ALLOC) {
+   /* special handling for legacy IRQs */
+   if (irq < nr_legacy_irqs() && info->count == 1 &&
+   mp_irqdomain_map(domain, irq, pin) != 0)
+   irq = -1;
+
if (irq > 0)
info->count++;
else if (info->count == 0)
@@ -3896,7 +3901,15 @@ int mp_irqdomain_map(struct irq_domain *domain, unsigned 
int virq,
info->polarity = 1;
}
info->node = NUMA_NO_NODE;
-   info->set = 1;
+
+   /*
+* setup_IO_APIC_irqs() programs all legacy IRQs with default
+* trigger and polarity attributes. Don't set the flag for that
+* case so the first legacy IRQ user could reprogram the pin
+* with real trigger and polarity attributes.
+*/
+   if (virq >= nr_legacy_irqs() || info->count)
+   info->set = 1;
}
set_io_apic_irq_attr(, ioapic, hwirq, info->trigger,
 info->polarity);
@@ -3946,6 +3959,18 @@ int mp_set_gsi_attr(u32 gsi, int trigger, int polarity, 
int node)
return ret;
 }
 
+bool mp_should_keep_irq(struct device *dev)
+{
+   if (dev->power.is_prepared)
+   return true;
+#ifdef CONFIG_PM_RUNTIME
+   if (dev->power.runtime_status == RPM_SUSPENDING)
+   return true;
+#endif
+
+   return false;
+}
+
 /* Enable IOAPIC early just for system timer */
 void __init pre_init_apic_IRQ0(void)
 {
diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c
index 1e6cff5..44f1ed4 100644
--- a/arch/x86/kernel/irqinit.c
+++ b/arch/x86/kernel/irqinit.c
@@ -203,7 +203,7 @@ void __init native_init_IRQ(void)
set_intr_gate(i, interrupt[i - FIRST_EXTERNAL_VECTOR]);
}
 
-   if (!acpi_ioapic && !of_ioapic)
+   if (!acpi_ioapic && !of_ioapic && nr_legacy_irqs())
setup_irq(2, );
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
index bf7ef5c..0fa2960 100644
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -68,6 +68,8 @@ static struct irqaction irq0  = {
 
 void __init setup_default_timer_irq(void)
 {
+   if (!nr_legacy_irqs())
+   return;
setup_irq(0, );
 }
 
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 3865116..b9958c3 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -229,7 +229,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (!dev->dev.power.is_prepared && dev->irq > 0)
+   if (!mp_should_keep_irq(>dev) && dev->irq > 0)
mp_unmap_irq(dev->irq);
 }
 
diff --git 

Re: [PATCH 0/2] x86: Speed up ioremap operations

[Greg KH]

On Fri, Aug 29, 2014 at 01:52:00PM -0700, Andrew Morton wrote:
> On Fri, 29 Aug 2014 13:44:31 -0700 Mike Travis  wrote:
> 
> > 
> > 
> > On 8/29/2014 1:16 PM, Andrew Morton wrote:
> > > On Fri, 29 Aug 2014 14:53:28 -0500 Mike Travis  wrote:
> > > 
> > >>
> > >> We have a large university system in the UK that is experiencing
> > >> very long delays modprobing the driver for a specific I/O device.
> > >> The delay is from 8-10 minutes per device and there are 31 devices
> > >> in the system.  This 4 to 5 hour delay in starting up those I/O
> > >> devices is very much a burden on the customer.
> > >>
> > >> There are two causes for requiring a restart/reload of the drivers.
> > >> First is periodic preventive maintenance (PM) and the second is if
> > >> any of the devices experience a fatal error.  Both of these trigger
> > >> this excessively long delay in bringing the system back up to full
> > >> capability.
> > >>
> > >> The problem was tracked down to a very slow IOREMAP operation and
> > >> the excessively long ioresource lookup to insure that the user is
> > >> not attempting to ioremap RAM.  These patches provide a speed up
> > >> to that function.
> > >>
> > > 
> > > Really would prefer to have some quantitative testing results in here,
> > > as that is the entire point of the patchset.  And it leaves the reader
> > > wondering "how much of this severe problem remains?".
> > 
> > Okay, I have some results from testing.  The modprobe time appears to
> > be affected quite a bit by previous activity on the ioresource list,
> > which I suspect is due to cache preloading.  While the overall
> > improvement is impacted by other overhead of starting the devices,
> > this drastically improves the modprobe time.
> > 
> > Also our system is considerably smaller so the percentages gained
> > will not be the same.  Best case improvement with the modprobe
> > on our 20 device smallish system was from 'real5m51.913s' to
> > 'real0m18.275s'.
> 
> Thanks, I slurped that into the changelog.
> 
> > > Also, the -stable backport is a big ask, isn't it?  It's arguably
> > > notabug and the affected number of machines is small.
> > > 
> > 
> > Ingo had suggested this.  We are definitely pushing it to our distro
> > suppliers for our customers.  Whether it's a big deal for smaller
> > systems is up in the air.  Note that the customer system has 31 devices
> > on an SSI that includes a large number of other IB and SAS devices
> > as well as a number of nodes which all which have discontiguous memory
> > segments.  I'm envisioning an ioresource list that numbers at least
> > several hundred entries.  While that's somewhat indicative of typical
> > UV systems it is generally not that common otherwise.
> > 
> > So I guess the -stable is merely a suggestion, not a request.
> 
> Cc Greg for his thoughts!

Sounds like a good thing for stable.

thanks,

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

Re: [PATCH v8 net-next 2/2] net: filter: split filter.h and expose eBPF to user space

[Daniel Borkmann]

On 08/29/2014 08:02 PM, Alexei Starovoitov wrote:

On Fri, Aug 29, 2014 at 10:39 AM, Daniel Borkmann  wrote:

On 08/27/2014 10:37 PM, Alexei Starovoitov wrote:


allow user space to generate eBPF programs

uapi/linux/bpf.h: eBPF instruction set definition

linux/filter.h: the rest


Very sorry for being late, but just a thought since we're touching user
space headers anyway ...

Wouldn't it be more consistent to have it organized as follows ...

  - uapi/linux/bpf.h: classic BPF instruction set parts only
  - uapi/linux/ebpf.h   : eBPF instruction set definition (which also
  includes uapi/linux/bpf.h though)
... and have ...

  - uapi/linux/filter.h : just include uapi/linux/bpf.h but rest is empty

That way, it would be more consistent ...

Old legacy application can stay with linux/filter.h; new applications
based on their needs can choose between linux/{e,}bpf.h and in the kernel,
we can just include linux/ebpf.h.

Right now, it seems, an eBPF user space program would need to include
2 header files in user space (linux/filter.h, linux/bpf.h) which I find
a bit confusing.


It's been bugging me as well, but I suspect having it the way you
described won't work. Mainly because we cannot do include 
inside uapi/*.h, so we would need to do include 
inside uapi/linux/filter.h, but that will cause serious include path
confusion. That was the reason I didn't simply do include 
inside uapi/linux/bpf.h

Also I really dislike 'ebpf' name in all lower case. If we make such header
file name, we would need to rename all macros and function names
to EBPF_... which I find very ugly looking. I think all good abbreviations are
three letters :)


I don't think we would have to name defines that way, really, that would be
terrible. We can keep them simply *as is*. Not sure though why bpf.h + ebpf.h
would be that bad. ;) I haven't tried it out yet, but if we would indeed run
into a name collision, above proposal would resolve that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rockchip-i2s: add power setting for I2S controller, also fix some bugs

[Jianqun]

changes:
* add snd_soc_dai_init_dma_data
* fix duplicated argument to "I2S_DMACR_TDE_DISABLE"
* set 1.8v or 3.3v power for I2S controller by GRF interface
* enable "hclk" always
* dma maxburst change to 16

Requested on RK3XXX I2S controllers, and tested ok on rk3288-pinky board.

Change-Id: If17b8022a38c2974f32bfb2dd4b8d16644ec57ac
Signed-off-by: Jianqun 
---
 sound/soc/rockchip/rockchip_i2s.c | 93 +++
 sound/soc/rockchip/rockchip_i2s.h | 13 +++---
 2 files changed, 63 insertions(+), 43 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index 8d8e4b5..e07bdbd 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -10,14 +10,15 @@
  * published by the Free Software Foundation.
  */
 
-#include 
+#include 
 #include 
+#include 
+#include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
+#include 
 
 #include "rockchip_i2s.h"
 
@@ -25,6 +26,7 @@
 
 struct rk_i2s_dev {
struct device *dev;
+   struct regmap *grf;
 
struct clk *hclk;
struct clk *mclk;
@@ -66,11 +68,6 @@ static int i2s_runtime_resume(struct device *dev)
return 0;
 }
 
-static inline struct rk_i2s_dev *to_info(struct snd_soc_dai *dai)
-{
-   return snd_soc_dai_get_drvdata(dai);
-}
-
 static void rockchip_snd_txctrl(struct rk_i2s_dev *i2s, int on)
 {
unsigned int val = 0;
@@ -79,7 +76,6 @@ static void rockchip_snd_txctrl(struct rk_i2s_dev *i2s, int 
on)
if (on) {
regmap_update_bits(i2s->regmap, I2S_DMACR,
   I2S_DMACR_TDE_ENABLE, I2S_DMACR_TDE_ENABLE);
-
regmap_update_bits(i2s->regmap, I2S_XFER,
   I2S_XFER_TXS_START | I2S_XFER_RXS_START,
   I2S_XFER_TXS_START | I2S_XFER_RXS_START);
@@ -159,19 +155,20 @@ static void rockchip_snd_rxctrl(struct rk_i2s_dev *i2s, 
int on)
}
 }
 
-static int rockchip_i2s_set_fmt(struct snd_soc_dai *cpu_dai,
+static int rockchip_i2s_set_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
 {
-   struct rk_i2s_dev *i2s = to_info(cpu_dai);
+   struct rk_i2s_dev *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int mask = 0, val = 0;
 
-   mask = I2S_CKR_MSS_SLAVE;
+   mask = I2S_CKR_MSS_MASK;
switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
-   val = I2S_CKR_MSS_SLAVE;
+   /* Set default source clock in Master mode */
+   val = I2S_CKR_MSS_MASTER;
break;
case SND_SOC_DAIFMT_CBM_CFM:
-   val = I2S_CKR_MSS_MASTER;
+   val = I2S_CKR_MSS_SLAVE;
break;
default:
return -EINVAL;
@@ -220,7 +217,7 @@ static int rockchip_i2s_hw_params(struct snd_pcm_substream 
*substream,
  struct snd_pcm_hw_params *params,
  struct snd_soc_dai *dai)
 {
-   struct rk_i2s_dev *i2s = to_info(dai);
+   struct rk_i2s_dev *i2s = snd_soc_dai_get_drvdata(dai);
unsigned int val = 0;
 
switch (params_format(params)) {
@@ -243,24 +240,13 @@ static int rockchip_i2s_hw_params(struct 
snd_pcm_substream *substream,
regmap_update_bits(i2s->regmap, I2S_TXCR, I2S_TXCR_VDW_MASK, val);
regmap_update_bits(i2s->regmap, I2S_RXCR, I2S_RXCR_VDW_MASK, val);
 
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   dai->playback_dma_data = >playback_dma_data;
-   regmap_update_bits(i2s->regmap, I2S_DMACR, I2S_DMACR_TDL_MASK,
-  I2S_DMACR_TDL(1) | I2S_DMACR_TDE_ENABLE);
-   } else {
-   dai->capture_dma_data = >capture_dma_data;
-   regmap_update_bits(i2s->regmap, I2S_DMACR, I2S_DMACR_RDL_MASK,
-  I2S_DMACR_RDL(1) | I2S_DMACR_RDE_ENABLE);
-   }
-
return 0;
 }
 
 static int rockchip_i2s_trigger(struct snd_pcm_substream *substream,
int cmd, struct snd_soc_dai *dai)
 {
-   struct rk_i2s_dev *i2s = to_info(dai);
-   int ret = 0;
+   struct rk_i2s_dev *i2s = snd_soc_dai_get_drvdata(dai);
 
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
@@ -280,17 +266,16 @@ static int rockchip_i2s_trigger(struct snd_pcm_substream 
*substream,
rockchip_snd_txctrl(i2s, 0);
break;
default:
-   ret = -EINVAL;
-   break;
+   return -EINVAL;
}
 
-   return ret;
+   return 0;
 }
 
-static int rockchip_i2s_set_sysclk(struct snd_soc_dai *cpu_dai, int clk_id,
+static int rockchip_i2s_set_sysclk(struct snd_soc_dai *dai, int clk_id,
   unsigned int freq, int dir)
 {
-   struct rk_i2s_dev *i2s = to_info(cpu_dai);
+   struct rk_i2s_dev *i2s = 

[PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Andrew Bresticker]

Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
the upcoming Danube board in .  Since Sead-3 is
different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
define its MIPS_GIC_IRQ_BASE in .

Signed-off-by: Andrew Bresticker 
---
 arch/mips/include/asm/mach-generic/irq.h | 6 ++
 arch/mips/include/asm/mach-sead3/irq.h   | 1 +
 arch/mips/include/asm/mips-boards/maltaint.h | 2 --
 arch/mips/include/asm/mips-boards/sead3int.h | 2 --
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/mips/include/asm/mach-generic/irq.h 
b/arch/mips/include/asm/mach-generic/irq.h
index 139cd20..c0fc62b 100644
--- a/arch/mips/include/asm/mach-generic/irq.h
+++ b/arch/mips/include/asm/mach-generic/irq.h
@@ -36,4 +36,10 @@
 
 #endif /* CONFIG_IRQ_CPU */
 
+#ifdef CONFIG_IRQ_GIC
+#ifndef MIPS_GIC_IRQ_BASE
+#define MIPS_GIC_IRQ_BASE (MIPS_CPU_IRQ_BASE + 8)
+#endif
+#endif /* CONFIG_IRQ_GIC */
+
 #endif /* __ASM_MACH_GENERIC_IRQ_H */
diff --git a/arch/mips/include/asm/mach-sead3/irq.h 
b/arch/mips/include/asm/mach-sead3/irq.h
index d8106f7..52c75d5 100644
--- a/arch/mips/include/asm/mach-sead3/irq.h
+++ b/arch/mips/include/asm/mach-sead3/irq.h
@@ -1,6 +1,7 @@
 #ifndef __ASM_MACH_MIPS_IRQ_H
 #define __ASM_MACH_MIPS_IRQ_H
 
+#define MIPS_GIC_IRQ_BASE 0
 #define GIC_NUM_INTRS (24 + NR_CPUS * 2)
 #define NR_IRQS 256
 
diff --git a/arch/mips/include/asm/mips-boards/maltaint.h 
b/arch/mips/include/asm/mips-boards/maltaint.h
index e330732..9d23343 100644
--- a/arch/mips/include/asm/mips-boards/maltaint.h
+++ b/arch/mips/include/asm/mips-boards/maltaint.h
@@ -10,8 +10,6 @@
 #ifndef _MIPS_MALTAINT_H
 #define _MIPS_MALTAINT_H
 
-#define MIPS_GIC_IRQ_BASE  (MIPS_CPU_IRQ_BASE + 8)
-
 /*
  * Interrupts 0..15 are used for Malta ISA compatible interrupts
  */
diff --git a/arch/mips/include/asm/mips-boards/sead3int.h 
b/arch/mips/include/asm/mips-boards/sead3int.h
index 6b17aaf..11ebec9 100644
--- a/arch/mips/include/asm/mips-boards/sead3int.h
+++ b/arch/mips/include/asm/mips-boards/sead3int.h
@@ -14,6 +14,4 @@
 #define GIC_BASE_ADDR  0x1b1c
 #define GIC_ADDRSPACE_SZ   (128 * 1024)
 
-#define MIPS_GIC_IRQ_BASE  (MIPS_CPU_IRQ_BASE + 0)
-
 #endif /* !(_MIPS_SEAD3INT_H) */
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/12] MIPS: GIC: Implement generic irq_ack/irq_eoi callbacks

[Andrew Bresticker]

Implement a default gic_irq_ack() and gic_finish_irq().  These are
suitable for handling IPIs on Malta and the upcoming Danube board.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/kernel/irq-gic.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 01fcc28..1764b01 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -242,6 +242,20 @@ static void gic_unmask_irq(struct irq_data *d)
GIC_SET_INTR_MASK(d->irq - gic_irq_base);
 }
 
+void __weak gic_irq_ack(struct irq_data *d)
+{
+   GIC_CLR_INTR_MASK(d->irq - gic_irq_base);
+
+   /* Clear edge detector */
+   if (gic_irq_flags[d->irq - gic_irq_base] & GIC_TRIG_EDGE)
+   GICWRITE(GIC_REG(SHARED, GIC_SH_WEDGE), d->irq - gic_irq_base);
+}
+
+void __weak gic_finish_irq(struct irq_data *d)
+{
+   GIC_SET_INTR_MASK(d->irq - gic_irq_base);
+}
+
 static int gic_set_type(struct irq_data *d, unsigned int type)
 {
unsigned int irq = d->irq - gic_irq_base;
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 02/12] MIPS: Set vint handler when mapping CPU interrupts

[Andrew Bresticker]

When mapping an interrupt in the CPU IRQ domain, set the vint handler
for that interrupt if the CPU uses vectored interrupt handling.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/kernel/irq_cpu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c
index 9cf8459..33a4385 100644
--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static inline void unmask_mips_irq(struct irq_data *d)
 {
@@ -146,6 +147,9 @@ static int mips_cpu_intc_map(struct irq_domain *d, unsigned 
int irq,
chip = _cpu_irq_controller;
}
 
+   if (cpu_has_vint)
+   set_vi_handler(hw, plat_irq_dispatch);
+
irq_set_chip_and_handler(irq, chip, handle_percpu_irq);
 
return 0;
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI: Add GPIO-signaled event emulator.

[Rafael J. Wysocki]

On Thursday, August 28, 2014 01:19:48 PM Tomasz Nowicki wrote:
> On 26.08.2014 00:39, Rafael J. Wysocki wrote:
> > On Thursday, August 21, 2014 04:39:46 PM Tomasz Nowicki wrote:
> >> Hi Mika,
> >>
> >> On 21.08.2014 12:45, Mika Westerberg wrote:
> >>> On Wed, Aug 20, 2014 at 04:58:20PM +0200, Tomasz Nowicki wrote:
> >
> > [cut]
> >
>  +
>  +static int gpio_evt_trigger(void *data, u64 val)
>  +{
>  +struct gpio_pin_data *pin_data = (struct gpio_pin_data *)data;
>  +int pin = pin_data->pin;
>  +
>  +if (ACPI_FAILURE(acpi_execute_simple_method(pin_data->handle, 
>  NULL,
>  +pin <= 255 ? 0 : 
>  pin)))
>  +pr_err(PREFIX "evaluating event method failed\n");
> >>>
> >>> acpi_execute_simple_method() passes one argument to the method. You
> >>> can't use it with _Lxx or _Exx which don't expect any arguments.
> >>> Otherwise you get this:
> >>>
> >>> [  122.258191] ACPI: \_SB_.GPO2._E12: Excess arguments - Caller passed 1, 
> >>> method requires 0 (20140724/nsarguments-263)
> >> Right, I will fix it.
> >
> > OK, so here's my concern.
> >
> > If AML does any kind of tracking of state in _Exx/_Lxx, you'll likely 
> > totally
> > confuse it by calling those things at random.
> >
> > I'm not sure I'm seeing a compelling reason to put this thing into the tree
> > for this reason.
> 
> Yes you are right, but this emulator is only for debugging/development 
> purposes and goes with clear statement "DANGER to use on production 
> kernel", like APEI error injection feature.
> 
> IMO, this emulator would help with:
> 1. testing and developing AML methods
> 2. working on ACPI subsystems that need GPIO-signaled events without 
> GPIO h/w

OK

And why does that belong to the kernel source tree and not to an ACPI/UEFI
test suite?

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/12] MIPS: Provide a generic plat_irq_dispatch

[Andrew Bresticker]

For platforms which boot with device-tree and use the MIPS CPU interrupt
controller binding, a generic plat_irq_dispatch() can be used since all
CPU interrupts should be mapped through the CPU IRQ domain.  Implement a
plat_irq_dispatch() which simply handles the highest pending interrupt.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/kernel/irq_cpu.c | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c
index e498f2b..9cf8459 100644
--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -116,6 +116,24 @@ void __init mips_cpu_irq_init(void)
 }
 
 #ifdef CONFIG_IRQ_DOMAIN
+static struct irq_domain *mips_intc_domain;
+
+asmlinkage void __weak plat_irq_dispatch(void)
+{
+   unsigned int pending = read_c0_cause() & read_c0_status() & ST0_IM;
+   unsigned int hw;
+   int irq;
+
+   if (!pending) {
+   spurious_interrupt();
+   return;
+   }
+
+   hw = fls(pending) - CAUSEB_IP - 1;
+   irq = irq_linear_revmap(mips_intc_domain, hw);
+   do_IRQ(irq);
+}
+
 static int mips_cpu_intc_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hw)
 {
@@ -141,15 +159,15 @@ static const struct irq_domain_ops 
mips_cpu_intc_irq_domain_ops = {
 int __init mips_cpu_intc_init(struct device_node *of_node,
  struct device_node *parent)
 {
-   struct irq_domain *domain;
-
/* Mask interrupts. */
clear_c0_status(ST0_IM);
clear_c0_cause(CAUSEF_IP);
 
-   domain = irq_domain_add_legacy(of_node, 8, MIPS_CPU_IRQ_BASE, 0,
-  _cpu_intc_irq_domain_ops, NULL);
-   if (!domain)
+   mips_intc_domain = irq_domain_add_legacy(of_node, 8,
+MIPS_CPU_IRQ_BASE, 0,
+_cpu_intc_irq_domain_ops,
+NULL);
+   if (!mips_intc_domain)
panic("Failed to add irqdomain for MIPS CPU");
 
return 0;
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/12] MIPS: GIC: Fix gic_set_affinity() return value

[Andrew Bresticker]

If the online CPU check in gic_set_affinity() fails, return a proper
errno value instead of -1.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/kernel/irq-gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 1764b01..4ee3ad8 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -319,7 +319,7 @@ static int gic_set_affinity(struct irq_data *d, const 
struct cpumask *cpumask,
 
cpumask_and(, cpumask, cpu_online_mask);
if (cpus_empty(tmp))
-   return -1;
+   return -EINVAL;
 
/* Assumption : cpumask refers to a single CPU */
spin_lock_irqsave(_lock, flags);
-- 
2.1.0.rc2.206.gedb03e5

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

mmotm 2014-08-29-15-15 uploaded

[akpm]

The mm-of-the-moment snapshot 2014-08-29-15-15 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (3.x
or 3.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/?p=linux-mmots.git;a=summary

and use of this tree is similar to
http://git.cmpxchg.org/?p=linux-mmotm.git, described above.


This mmotm tree contains the following patches against 3.17-rc2:
(patches marked "*" will be included in linux-next)

  origin.patch
  i-need-old-gcc.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
  maintainers-akpm-maintenance.patch
* checkpatch-relax-check-for-length-of-git-commit-ids.patch
* resource-fix-the-case-of-null-pointer-access.patch
* memblock-memhotplug-fix-wrong-type-in-memblock_find_in_range_node.patch
* mm-actually-clear-pmd_numa-before-invalidating.patch
* lib-turn-config_stacktrace-into-an-actual-option.patch
* zram-fix-incorrectly-stat-with-failed_reads.patch
* mm-zpool-use-prefixed-module-loading.patch
* hugetlb_cgroup-use-lockdep_assert_held-rather-than-spin_is_locked.patch
* x86mm-fix-pte_special-versus-pte_numa.patch
* kexec-create-a-new-config-option-config_kexec_file-for-new-syscall.patch
* kexec-remove-config_kexec-dependency-on-crypto.patch
* xattr-fix-check-for-simultaneous-glibc-header-inclusion.patch
* rtc-s5m-re-add-support-for-devices-without-irq-specified.patch
* x86-purgatory-use-approprate-m64-32-build-flag-for-arch-x86-purgatory.patch
* ocfs2-do-not-write-error-flag-to-user-structure-we-cannot-copy-from-to.patch
* ocfs2-o2net-dont-shutdown-connection-when-idle-timeout.patch
* ocfs2-o2net-set-tcp-user-timeout-to-max-value.patch
* ocfs2-quorum-add-a-log-for-node-not-fenced.patch
* tools-selftests-fixing-build-issue-with-make-kselftests-target.patch
* flush_icache_range-export-symbol-to-fix-build-errors.patch
* add-arm-description-to-documentation-kdump-kdumptxt.patch
* purgatory-add-clean-up-for-purgatory-directory.patch
* 
mem-hotplug-let-memblock-skip-the-hotpluggable-memory-regions-in-__next_mem_range.patch
* 
mem-hotplug-let-memblock-skip-the-hotpluggable-memory-regions-in-__next_mem_range-fix.patch
* fix-faulty-logic-in-the-case-of-recursive-printk.patch
* mm-slab_commonc-suppress-warning.patch
* mm-cma-adjust-address-limit-to-avoid-hitting-low-high-memory-boundary.patch
* arm-mm-dont-limit-default-cma-region-only-to-low-memory.patch
* eventpoll-fix-uninitialized-variable-in-epoll_ctl.patch
* sh-get_user_pages_fast-must-flush-cache-the-way.patch
* checkpatch-allow-commit-descriptions-on-separate-line-from-commit-id.patch
* 
x86mem-hotplug-pass-sync_global_pgds-a-correct-argument-in-remove_pagetable.patch
* x86mem-hotplug-modify-pgd-entry-when-removing-memory.patch
* x86-numa-setup_node_data-drop-dead-code-and-rename-function.patch
* mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable.patch
* 
mem-hotplug-fix-boot-failed-in-case-all-the-nodes-are-hotpluggable-checkpatch-fixes.patch
* mn10300-use-kbuild-logic-to-include-asm-generic-sectionsh.patch
* 

[PATCH 05/12] MIPS: GIC: Add device-tree support

[Andrew Bresticker]

Add device-tree support for the MIPS GIC.  With DT, no per-platform
static device interrupt mapping is supplied and instead all device
interrupts are specified through the DT.  The GIC-to-CPU interrupts
must also be specified in the DT.

Platforms using DT-based probing of the GIC need only supply the
GIC_NUM_INTRS and, if necessary, MIPS_GIC_IRQ_BASE values and
call of_irq_init() with an of_device_id table including the GIC.

Currenlty only legacy and vecotred interrupt modes are supported.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/include/asm/gic.h |  15 ++
 arch/mips/kernel/irq-gic.c  | 122 +++-
 2 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
index d7699cf..1146803 100644
--- a/arch/mips/include/asm/gic.h
+++ b/arch/mips/include/asm/gic.h
@@ -339,6 +339,10 @@ struct gic_shared_intr_map {
 #define GIC_CPU_INT3   3 /* .*/
 #define GIC_CPU_INT4   4 /* .*/
 #define GIC_CPU_INT5   5 /* Core Interrupt 7 */
+#define GIC_NUM_CPU_INT6
+
+/* Add 2 to convert GIC CPU pin to core interrupt */
+#define GIC_CPU_PIN_OFFSET 2
 
 /* Local GIC interrupts. */
 #define GIC_INT_TMR(GIC_CPU_INT5)
@@ -381,4 +385,15 @@ extern void gic_disable_interrupt(int irq_vec);
 extern void gic_irq_ack(struct irq_data *d);
 extern void gic_finish_irq(struct irq_data *d);
 extern void gic_platform_init(int irqs, struct irq_chip *irq_controller);
+
+#ifdef CONFIG_IRQ_DOMAIN
+extern int gic_of_init(struct device_node *node, struct device_node *parent);
+#else
+static inline int gic_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return 0;
+}
+#endif
+
 #endif /* _ASM_GICREGS_H */
diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 9e9d8b9..be8bea4 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -8,8 +8,10 @@
  */
 #include 
 #include 
+#include 
+#include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -243,7 +245,7 @@ static DEFINE_SPINLOCK(gic_lock);
 static int gic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
bool force)
 {
-   unsigned int irq = (d->irq - gic_irq_base);
+   unsigned int irq = d->irq - gic_irq_base;
cpumask_t   tmp = CPU_MASK_NONE;
unsigned long   flags;
int i;
@@ -400,3 +402,119 @@ void __init gic_init(unsigned long gic_base_addr,
 
gic_platform_init(numintrs, _irq_controller);
 }
+
+#ifdef CONFIG_IRQ_DOMAIN
+/* CPU core IRQs used by GIC */
+static int gic_cpu_pin[GIC_NUM_CPU_INT];
+static int num_gic_cpu_pins;
+
+/* Index of core IRQ used by a particular GIC IRQ */
+static int gic_irq_pin[GIC_NUM_INTRS];
+
+static inline int gic_irq_to_cpu_pin(unsigned int hwirq)
+{
+   return gic_cpu_pin[gic_irq_pin[hwirq]] - MIPS_CPU_IRQ_BASE -
+   GIC_CPU_PIN_OFFSET;
+}
+
+static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+   irq_set_chip_and_handler(irq, _irq_controller, handle_level_irq);
+
+   GICWRITE(GIC_REG_ADDR(SHARED, GIC_SH_MAP_TO_PIN(hw)),
+GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hw));
+   /* Map to VPE 0 by default */
+   GIC_SH_MAP_TO_VPE_SMASK(hw, 0);
+   set_bit(hw, pcpu_masks[0].pcpu_mask);
+
+   return 0;
+}
+
+static int gic_irq_domain_xlate(struct irq_domain *d, struct device_node 
*ctrlr,
+   const u32 *intspec, unsigned int intsize,
+   unsigned long *out_hwirq,
+   unsigned int *out_type)
+{
+   if (intsize != 2 && intsize != 3)
+   return -EINVAL;
+
+   if (intspec[0] >= GIC_NUM_INTRS)
+   return -EINVAL;
+   *out_hwirq = intspec[0];
+
+   *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+
+   if (intsize == 3) {
+   if (intspec[2] >= num_gic_cpu_pins)
+   return -EINVAL;
+   gic_irq_pin[intspec[0]] = intspec[2];
+   }
+
+   return 0;
+}
+
+static const struct irq_domain_ops gic_irq_domain_ops = {
+   .map = gic_irq_domain_map,
+   .xlate = gic_irq_domain_xlate,
+};
+
+static void gic_irq_dispatch(unsigned int irq, struct irq_desc *desc)
+{
+   struct irq_domain *domain = irq_get_handler_data(irq);
+   unsigned int hwirq;
+
+   while ((hwirq = gic_get_int()) != GIC_NUM_INTRS) {
+   irq = irq_linear_revmap(domain, hwirq);
+   generic_handle_irq(irq);
+   }
+}
+
+void __init __weak gic_platform_init(int irqs, struct irq_chip *irq_controller)
+{
+}
+
+int __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+   struct irq_domain *domain;
+   struct resource res;
+   int i;
+
+   if (cpu_has_veic) {

[PATCH 11/12] MIPS: GIC: Use local interrupts for timer

[Andrew Bresticker]

Instead of using GIC interrupt 0 for the timer (which was not even
handled correctly by the GIC irqchip code and could conflict with an
actual external interrupt), use the designated local interrupt for
the GIC timer.

Also, since the timer is a per-CPU interrupt, initialize it with
setup_percpu_irq() and enable it with enable_percpu_irq() instead
of using direct register writes.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/kernel/cevt-gic.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/mips/kernel/cevt-gic.c b/arch/mips/kernel/cevt-gic.c
index 6093716..cae72a4 100644
--- a/arch/mips/kernel/cevt-gic.c
+++ b/arch/mips/kernel/cevt-gic.c
@@ -68,7 +68,7 @@ int gic_clockevent_init(void)
if (!cpu_has_counter || !gic_frequency)
return -ENXIO;
 
-   irq = MIPS_GIC_IRQ_BASE;
+   irq = MIPS_GIC_LOCAL_IRQ_BASE + GIC_LOCAL_INTR_COMPARE;
 
cd = _cpu(gic_clockevent_device, cpu);
 
@@ -91,15 +91,13 @@ int gic_clockevent_init(void)
 
clockevents_register_device(cd);
 
-   GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_COMPARE_MAP), 0x8002);
-   GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_SMASK), GIC_VPE_SMASK_CMP_MSK);
+   if (!gic_timer_irq_installed) {
+   setup_percpu_irq(irq, _compare_irqaction);
+   irq_set_handler(irq, handle_percpu_irq);
+   gic_timer_irq_installed = 1;
+   }
 
-   if (gic_timer_irq_installed)
-   return 0;
+   enable_percpu_irq(irq, 0);
 
-   gic_timer_irq_installed = 1;
-
-   setup_irq(irq, _compare_irqaction);
-   irq_set_handler(irq, handle_percpu_irq);
return 0;
 }
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/12] MIPS: GIC: Implement irq_set_type callback

[Andrew Bresticker]

Implement an irq_set_type callback for the GIC which is used to set
the polarity and trigger type of GIC interrupts.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/include/asm/gic.h |  9 
 arch/mips/kernel/irq-gic.c  | 53 +
 2 files changed, 62 insertions(+)

diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
index 1146803..3853c15 100644
--- a/arch/mips/include/asm/gic.h
+++ b/arch/mips/include/asm/gic.h
@@ -23,6 +23,8 @@
 #define GIC_POL_NEG0
 #define GIC_TRIG_EDGE  1
 #define GIC_TRIG_LEVEL 0
+#define GIC_TRIG_DUAL_ENABLE   1
+#define GIC_TRIG_DUAL_DISABLE  0
 
 #define MSK(n) ((1 << (n)) - 1)
 #define REG32(addr)(*(volatile unsigned int *) (addr))
@@ -179,6 +181,13 @@
GIC_INTR_OFS(intr)), (1 << GIC_INTR_BIT(intr)), \
(trig) << GIC_INTR_BIT(intr))
 
+/* Dual edge triggering : Reset Value is always 0 */
+#define GIC_SH_SET_DUAL_OFS0x0200
+#define GIC_SET_DUAL(intr, dual) \
+   GICBIS(GIC_REG_ADDR(SHARED, GIC_SH_SET_DUAL_OFS + \
+   GIC_INTR_OFS(intr)), (1 << GIC_INTR_BIT(intr)), \
+   (dual) << GIC_INTR_BIT(intr))
+
 /* Mask manipulation */
 #define GIC_SH_SMASK_OFS   0x0380
 #define GIC_SET_INTR_MASK(intr) \
diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 42558eb..01fcc28 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -47,6 +47,8 @@ static struct gic_pcpu_mask pcpu_masks[NR_CPUS];
 static struct gic_pending_regs pending_regs[NR_CPUS];
 static struct gic_intrmask_regs intrmask_regs[NR_CPUS];
 
+static struct irq_chip gic_irq_controller;
+
 #if defined(CONFIG_CSRC_GIC) || defined(CONFIG_CEVT_GIC)
 cycle_t gic_read_count(void)
 {
@@ -240,6 +242,56 @@ static void gic_unmask_irq(struct irq_data *d)
GIC_SET_INTR_MASK(d->irq - gic_irq_base);
 }
 
+static int gic_set_type(struct irq_data *d, unsigned int type)
+{
+   unsigned int irq = d->irq - gic_irq_base;
+   bool is_edge;
+
+   switch (type & IRQ_TYPE_SENSE_MASK) {
+   case IRQ_TYPE_EDGE_FALLING:
+   GIC_SET_POLARITY(irq, GIC_POL_POS);
+   GIC_SET_TRIGGER(irq, GIC_TRIG_EDGE);
+   GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+   is_edge = true;
+   break;
+   case IRQ_TYPE_EDGE_RISING:
+   GIC_SET_POLARITY(irq, GIC_POL_NEG);
+   GIC_SET_TRIGGER(irq, GIC_TRIG_EDGE);
+   GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+   is_edge = true;
+   break;
+   case IRQ_TYPE_EDGE_BOTH:
+   /* polarity is irrelevant in this case */
+   GIC_SET_TRIGGER(irq, GIC_TRIG_EDGE);
+   GIC_SET_DUAL(irq, GIC_TRIG_DUAL_ENABLE);
+   is_edge = true;
+   break;
+   case IRQ_TYPE_LEVEL_LOW:
+   GIC_SET_POLARITY(irq, GIC_POL_NEG);
+   GIC_SET_TRIGGER(irq, GIC_TRIG_LEVEL);
+   GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+   is_edge = false;
+   break;
+   case IRQ_TYPE_LEVEL_HIGH:
+   default:
+   GIC_SET_POLARITY(irq, GIC_POL_POS);
+   GIC_SET_TRIGGER(irq, GIC_TRIG_LEVEL);
+   GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+   is_edge = false;
+   break;
+   }
+
+   if (is_edge) {
+   gic_irq_flags[irq] |= GIC_TRIG_EDGE;
+   __irq_set_handler_locked(d->irq, handle_edge_irq);
+   } else {
+   gic_irq_flags[irq] &= ~GIC_TRIG_EDGE;
+   __irq_set_handler_locked(d->irq, handle_level_irq);
+   }
+
+   return 0;
+}
+
 #ifdef CONFIG_SMP
 static DEFINE_SPINLOCK(gic_lock);
 
@@ -280,6 +332,7 @@ static struct irq_chip gic_irq_controller = {
.irq_mask_ack   =   gic_mask_irq,
.irq_unmask =   gic_unmask_irq,
.irq_eoi=   gic_finish_irq,
+   .irq_set_type   =   gic_set_type,
 #ifdef CONFIG_SMP
.irq_set_affinity   =   gic_set_affinity,
 #endif
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 10/12] MIPS: GIC: Support local interrupts

[Andrew Bresticker]

The MIPS GIC supports 7 local interrupts, 5 of which are just core
interrupts which can be re-routed through the GIC.  This patch adds
support for mapping and handling the remaining two: the GIC timer
and watchdog.  GIC interrupts from 0 to GIC_NUM_INTRS are still the
shared external interrupts while interrupts from GIC_NUM_INTRS to
GIC_NUM_INTRS + GIC_NUM_LOCAL_INTRS are local interrupts.

With device-tree based probing, the GIC local interrupts will be routed
to the first GIC-to-CPU pin.  For platforms using a static mapping, the
local interrupts can be initialized by extending the interrupt mapping
table passed to gic_init.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/include/asm/gic.h  |  12 ++
 arch/mips/include/asm/mach-generic/irq.h |   2 +
 arch/mips/kernel/irq-gic.c   | 183 +++
 3 files changed, 175 insertions(+), 22 deletions(-)

diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
index 3853c15..d5b2d84 100644
--- a/arch/mips/include/asm/gic.h
+++ b/arch/mips/include/asm/gic.h
@@ -217,6 +217,10 @@
 #define GIC_VPE_COMPARE_LO_OFS 0x00a0
 #define GIC_VPE_COMPARE_HI_OFS 0x00a4
 
+#define GIC_VPE_MAP_OFS0x0040
+#define GIC_VPE_MAP_TO_PIN(intr) \
+   (GIC_VPE_MAP_OFS + 4 * (intr))
+
 #define GIC_VPE_EIC_SHADOW_SET_BASE0x0100
 #define GIC_VPE_EIC_SS(intr) \
(GIC_VPE_EIC_SHADOW_SET_BASE + (4 * intr))
@@ -354,6 +358,11 @@ struct gic_shared_intr_map {
 #define GIC_CPU_PIN_OFFSET 2
 
 /* Local GIC interrupts. */
+#define GIC_LOCAL_INTR_WD  0 /* GIC watchdog timer */
+#define GIC_LOCAL_INTR_COMPARE 1 /* GIC count/compare timer */
+#define GIC_NUM_LOCAL_INTRS2
+
+/* Pin mapping for CPU interrupts routable through the GIC. */
 #define GIC_INT_TMR(GIC_CPU_INT5)
 #define GIC_INT_PERFCTR(GIC_CPU_INT5)
 
@@ -389,6 +398,9 @@ extern void gic_bind_eic_interrupt(int irq, int set);
 extern unsigned int gic_get_timer_pending(void);
 extern void gic_get_int_mask(unsigned long *dst, const unsigned long *src);
 extern unsigned int gic_get_int(void);
+extern void gic_get_local_int_mask(unsigned long *dst,
+  const unsigned long *src);
+extern unsigned int gic_get_local_int(void);
 extern void gic_enable_interrupt(int irq_vec);
 extern void gic_disable_interrupt(int irq_vec);
 extern void gic_irq_ack(struct irq_data *d);
diff --git a/arch/mips/include/asm/mach-generic/irq.h 
b/arch/mips/include/asm/mach-generic/irq.h
index c0fc62b..89bc185 100644
--- a/arch/mips/include/asm/mach-generic/irq.h
+++ b/arch/mips/include/asm/mach-generic/irq.h
@@ -40,6 +40,8 @@
 #ifndef MIPS_GIC_IRQ_BASE
 #define MIPS_GIC_IRQ_BASE (MIPS_CPU_IRQ_BASE + 8)
 #endif
+
+#define MIPS_GIC_LOCAL_IRQ_BASE (MIPS_GIC_IRQ_BASE + GIC_NUM_INTRS)
 #endif /* CONFIG_IRQ_GIC */
 
 #endif /* __ASM_MACH_GENERIC_IRQ_H */
diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 4ee3ad8..7f66d6e 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -49,6 +49,21 @@ static struct gic_intrmask_regs intrmask_regs[NR_CPUS];
 
 static struct irq_chip gic_irq_controller;
 
+static inline bool gic_is_local_irq(unsigned int hwirq)
+{
+   return hwirq >= GIC_NUM_INTRS;
+}
+
+static inline unsigned int gic_hw_to_local_irq(unsigned int hwirq)
+{
+   return hwirq - GIC_NUM_INTRS;
+}
+
+static inline unsigned int gic_local_to_hw_irq(unsigned int irq)
+{
+   return irq + GIC_NUM_INTRS;
+}
+
 #if defined(CONFIG_CSRC_GIC) || defined(CONFIG_CEVT_GIC)
 cycle_t gic_read_count(void)
 {
@@ -232,28 +247,77 @@ unsigned int gic_get_int(void)
return find_first_bit(interrupts, GIC_NUM_INTRS);
 }
 
+void gic_get_local_int_mask(unsigned long *dst, const unsigned long *src)
+{
+   unsigned long pending, intrmask;
+
+   GICREAD(GIC_REG(VPE_LOCAL, GIC_VPE_PEND), pending);
+   GICREAD(GIC_REG(VPE_LOCAL, GIC_VPE_MASK), intrmask);
+
+   bitmap_and(, , , GIC_NUM_LOCAL_INTRS);
+   bitmap_and(dst, src, , GIC_NUM_LOCAL_INTRS);
+}
+
+unsigned int gic_get_local_int(void)
+{
+   unsigned long interrupts;
+
+   bitmap_fill(, GIC_NUM_LOCAL_INTRS);
+   gic_get_local_int_mask(, );
+
+   return find_first_bit(, GIC_NUM_LOCAL_INTRS);
+}
+
 static void gic_mask_irq(struct irq_data *d)
 {
-   GIC_CLR_INTR_MASK(d->irq - gic_irq_base);
+   unsigned int irq = d->irq - gic_irq_base;
+
+   if (gic_is_local_irq(irq)) {
+   GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_RMASK),
+1 << GIC_INTR_BIT(gic_hw_to_local_irq(irq)));
+   } else {
+   GIC_CLR_INTR_MASK(irq);
+   }
 }
 
 static void gic_unmask_irq(struct irq_data *d)
 {
-   GIC_SET_INTR_MASK(d->irq - gic_irq_base);
+   unsigned int irq = d->irq - gic_irq_base;
+
+   if (gic_is_local_irq(irq)) {
+   GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_SMASK),
+1 << 

[PATCH 00/12] MIPS: GIC device-tree support

[Andrew Bresticker]

This series add support for mapping and routing GIC interrupts through
the device-tree, which will be used on the upcoming interAptiv-based
Danube SoC.

- Patches 1 and 2 provide improvements to the CPU interrupt controller
  when used with DT.
- Patches 3 through 7 add device-tree support for the GIC.
- Patches 8 and 9 are misc. GIC irqchip cleanups.
- Patches 10 through 12 cleanup/fix GIC local interrupt support.

Based on 3.17-rc2 and boot tested on Danube (+ out of tree patches) and
Malta.  Build tested for SEAD-3.  Paul Burton has also tested this series
with his WIP Malta DT support [0].

[0] https://github.com/paulburton/linux/commits/wip-malta-dt

Andrew Bresticker (12):
  MIPS: Provide a generic plat_irq_dispatch
  MIPS: Set vint handler when mapping CPU interrupts
  of: Add binding document for MIPS GIC
  MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h
  MIPS: GIC: Add device-tree support
  MIPS: GIC: Add generic IPI support when using DT
  MIPS: GIC: Implement irq_set_type callback
  MIPS: GIC: Implement generic irq_ack/irq_eoi callbacks
  MIPS: GIC: Fix gic_set_affinity() return value
  MIPS: GIC: Support local interrupts
  MIPS: GIC: Use local interrupts for timer
  MIPS: Malta: Map GIC local interrupts

 Documentation/devicetree/bindings/mips/gic.txt |  50 +++
 arch/mips/include/asm/gic.h|  36 ++
 arch/mips/include/asm/mach-generic/irq.h   |   8 +
 arch/mips/include/asm/mach-sead3/irq.h |   1 +
 arch/mips/include/asm/mips-boards/maltaint.h   |   2 -
 arch/mips/include/asm/mips-boards/sead3int.h   |   2 -
 arch/mips/kernel/cevt-gic.c|  16 +-
 arch/mips/kernel/irq-gic.c | 434 -
 arch/mips/kernel/irq_cpu.c |  32 +-
 arch/mips/mti-malta/malta-int.c|  44 ++-
 10 files changed, 585 insertions(+), 40 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/gic.txt

-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 12/12] MIPS: Malta: Map GIC local interrupts

[Andrew Bresticker]

Now that the GIC driver properly supports local interrupts, extend
the static interrupt mapping to include the GIC timer and watchdog
and fix up the GIC interrupt setup and handling so that the local
interrupts are properly handled.  Note that ipi_map is also renamed
to gic_irq_map since it is now also used to track mapping of non-IPI
interrupts to CPUs.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/mti-malta/malta-int.c | 44 +++--
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/mips/mti-malta/malta-int.c b/arch/mips/mti-malta/malta-int.c
index e4f43ba..16b1473 100644
--- a/arch/mips/mti-malta/malta-int.c
+++ b/arch/mips/mti-malta/malta-int.c
@@ -38,7 +38,7 @@
 #include 
 
 static unsigned long _msc01_biu_base;
-static unsigned int ipi_map[NR_CPUS];
+static unsigned int gic_irq_map[NR_CPUS];
 
 static DEFINE_RAW_SPINLOCK(mips_irq_lock);
 
@@ -129,8 +129,8 @@ static void malta_hw0_irqdispatch(void)
 
 static void malta_ipi_irqdispatch(void)
 {
-#ifdef CONFIG_MIPS_GIC_IPI
unsigned long irq;
+#ifdef CONFIG_MIPS_GIC_IPI
DECLARE_BITMAP(pending, GIC_NUM_INTRS);
 
gic_get_int_mask(pending, ipi_ints);
@@ -143,8 +143,12 @@ static void malta_ipi_irqdispatch(void)
irq = find_next_bit(pending, GIC_NUM_INTRS, irq + 1);
}
 #endif
-   if (gic_compare_int())
-   do_IRQ(MIPS_GIC_IRQ_BASE);
+   irq = gic_get_local_int();
+   while (irq < GIC_NUM_LOCAL_INTRS) {
+   do_IRQ(MIPS_GIC_LOCAL_IRQ_BASE + irq);
+
+   irq = gic_get_local_int();
+   }
 }
 
 static void corehi_irqdispatch(void)
@@ -288,7 +292,7 @@ asmlinkage void plat_irq_dispatch(void)
 
if (irq == MIPSCPU_INT_I8259A)
malta_hw0_irqdispatch();
-   else if (gic_present && ((1 << irq) & ipi_map[smp_processor_id()]))
+   else if (gic_present && ((1 << irq) & gic_irq_map[smp_processor_id()]))
malta_ipi_irqdispatch();
else
do_IRQ(MIPS_CPU_IRQ_BASE + irq);
@@ -408,7 +412,7 @@ static int msc_nr_eicirqs __initdata = 
ARRAY_SIZE(msc_eicirqmap);
 #define GIC_CPU_NMI GIC_MAP_TO_NMI_MSK
 #define X GIC_UNUSED
 
-static struct gic_intr_map gic_intr_map[GIC_NUM_INTRS] = {
+static struct gic_intr_map gic_intr_map[GIC_NUM_INTRS + GIC_NUM_LOCAL_INTRS] = 
{
{ X, X,X,   X,  0 },
{ X, X,X,   X,  0 },
{ X, X,X,   X,  0 },
@@ -425,7 +429,10 @@ static struct gic_intr_map gic_intr_map[GIC_NUM_INTRS] = {
{ 0, GIC_CPU_NMI,  GIC_POL_POS, GIC_TRIG_LEVEL, GIC_FLAG_TRANSPARENT },
{ 0, GIC_CPU_NMI,  GIC_POL_POS, GIC_TRIG_LEVEL, GIC_FLAG_TRANSPARENT },
{ X, X,X,   X,  0 },
-   /* The remainder of this table is initialised by fill_ipi_map */
+   /*
+* The remainder of this table is initialised by fill_ipi_map and
+* fill_local_irq_map
+*/
 };
 #undef X
 
@@ -438,7 +445,7 @@ static void __init fill_ipi_map1(int baseintr, int cpu, int 
cpupin)
gic_intr_map[intr].polarity = GIC_POL_POS;
gic_intr_map[intr].trigtype = GIC_TRIG_EDGE;
gic_intr_map[intr].flags = 0;
-   ipi_map[cpu] |= (1 << (cpupin + 2));
+   gic_irq_map[cpu] |= (1 << (cpupin + 2));
bitmap_set(ipi_ints, intr, 1);
 }
 
@@ -453,6 +460,22 @@ static void __init fill_ipi_map(void)
 }
 #endif
 
+static void __init fill_local_irq_map(void)
+{
+   int i;
+
+   for (i = 0; i < GIC_NUM_LOCAL_INTRS; i++) {
+   int intr = i + GIC_NUM_INTRS;
+
+   gic_intr_map[intr].cpunum = 0;
+   gic_intr_map[intr].pin = GIC_CPU_INT2;
+   gic_intr_map[intr].flags = 0;
+   }
+
+   for (i = 0; i < NR_CPUS; i++)
+   gic_irq_map[i] |= 1 << (GIC_CPU_INT2 + 2);
+}
+
 void __init arch_init_ipiirq(int irq, struct irqaction *action)
 {
setup_irq(irq, action);
@@ -533,6 +556,7 @@ void __init arch_init_irq(void)
gic_resched_int_base = gic_call_int_base - nr_cpu_ids;
fill_ipi_map();
 #endif
+   fill_local_irq_map();
gic_init(GIC_BASE_ADDR, GIC_ADDRSPACE_SZ, gic_intr_map,
ARRAY_SIZE(gic_intr_map), MIPS_GIC_IRQ_BASE);
if (!mips_cm_present()) {
@@ -542,8 +566,7 @@ void __init arch_init_irq(void)
(i | (0x1 << MSC01_SC_CFG_GICENA_SHF));
pr_debug("GIC Enabled\n");
}
-#if defined(CONFIG_MIPS_GIC_IPI)
-   /* set up ipi interrupts */
+   /* set up ipi and local interrupts */
if (cpu_has_vint) {
set_vi_handler(MIPSCPU_INT_IPI0, malta_ipi_irqdispatch);
set_vi_handler(MIPSCPU_INT_IPI1, malta_ipi_irqdispatch);
@@ -557,6 +580,7 @@ void __init arch_init_irq(void)

[PATCH 06/12] MIPS: GIC: Add generic IPI support when using DT

[Andrew Bresticker]

When DT-based probing is used for the GIC and the GIC is also used
for IPIs (i.e. MIPS_GIC_IPI=y), set up the last 2 * NR_CPUs GIC
interrupts as the reschedule and call IPIs.

Signed-off-by: Andrew Bresticker 
---
 arch/mips/kernel/irq-gic.c | 86 ++
 1 file changed, 86 insertions(+)

diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index be8bea4..42558eb 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -417,6 +418,89 @@ static inline int gic_irq_to_cpu_pin(unsigned int hwirq)
GIC_CPU_PIN_OFFSET;
 }
 
+#ifdef CONFIG_MIPS_GIC_IPI
+static int gic_resched_int_base;
+static int gic_call_int_base;
+
+unsigned int plat_ipi_resched_int_xlate(unsigned int cpu)
+{
+   return gic_resched_int_base + cpu;
+}
+
+unsigned int plat_ipi_call_int_xlate(unsigned int cpu)
+{
+   return gic_call_int_base + cpu;
+}
+
+static irqreturn_t ipi_resched_interrupt(int irq, void *dev_id)
+{
+   scheduler_ipi();
+
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t ipi_call_interrupt(int irq, void *dev_id)
+{
+   smp_call_function_interrupt();
+
+   return IRQ_HANDLED;
+}
+
+static struct irqaction irq_resched = {
+   .handler= ipi_resched_interrupt,
+   .flags  = IRQF_PERCPU,
+   .name   = "IPI resched"
+};
+
+static struct irqaction irq_call = {
+   .handler= ipi_call_interrupt,
+   .flags  = IRQF_PERCPU,
+   .name   = "IPI call"
+};
+
+static __init void gic_ipi_init_one(struct irq_domain *domain,
+   unsigned int hwirq, int cpu,
+   struct irqaction *action)
+{
+   int irq = irq_create_mapping(domain, hwirq);
+   int i;
+
+   GIC_SET_POLARITY(hwirq, GIC_POL_POS);
+   GIC_SET_TRIGGER(hwirq, GIC_TRIG_EDGE);
+   GIC_SH_MAP_TO_VPE_SMASK(hwirq, cpu);
+   GICWRITE(GIC_REG_ADDR(SHARED, GIC_SH_MAP_TO_PIN(hwirq)),
+GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hwirq));
+   GIC_CLR_INTR_MASK(hwirq);
+   gic_irq_flags[hwirq] |= GIC_TRIG_EDGE;
+
+   for (i = 0; i < ARRAY_SIZE(pcpu_masks); i++)
+   clear_bit(hwirq, pcpu_masks[i].pcpu_mask);
+   set_bit(hwirq, pcpu_masks[cpu].pcpu_mask);
+
+   irq_set_chip_and_handler(irq, _irq_controller, handle_percpu_irq);
+   setup_irq(irq, action);
+}
+
+static __init void gic_ipi_init(struct irq_domain *domain)
+{
+   int i;
+
+   /* Use last 2 * NR_CPUS interrupts as IPIs */
+   gic_resched_int_base = GIC_NUM_INTRS - nr_cpu_ids;
+   gic_call_int_base = gic_resched_int_base - nr_cpu_ids;
+
+   for (i = 0; i < nr_cpu_ids; i++) {
+   gic_ipi_init_one(domain, gic_call_int_base + i, i, _call);
+   gic_ipi_init_one(domain, gic_resched_int_base + i, i,
+_resched);
+   }
+}
+#else
+static inline void gic_ipi_init(struct irq_domain *domain)
+{
+}
+#endif
+
 static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
  irq_hw_number_t hw)
 {
@@ -515,6 +599,8 @@ int __init gic_of_init(struct device_node *node, struct 
device_node *parent)
irq_set_handler_data(gic_cpu_pin[i], domain);
}
 
+   gic_ipi_init(domain);
+
return 0;
 }
 #endif
-- 
2.1.0.rc2.206.gedb03e5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

The Global Interrupt Controller (GIC) present on certain MIPS systems
can be used to route external interrupts to individual VPEs and CPU
interrupt vectors.  It also supports a timer and software-generated
interrupts.

Signed-off-by: Andrew Bresticker 
---
 Documentation/devicetree/bindings/mips/gic.txt | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/gic.txt

diff --git a/Documentation/devicetree/bindings/mips/gic.txt 
b/Documentation/devicetree/bindings/mips/gic.txt
new file mode 100644
index 000..725f1ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/gic.txt
@@ -0,0 +1,50 @@
+MIPS Global Interrupt Controller (GIC)
+
+The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
+It also supports a timer and software-generated interrupts which can be
+used as IPIs.
+
+Required properties:
+- compatible : Should be "mti,global-interrupt-controller"
+- reg : Base address and length of the GIC registers.
+- interrupts : Core interrupts to which the GIC may route external interrupts.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt specifier.  Should be 3.
+  - The first cell is the GIC interrupt number.
+  - The second cell encodes the interrupt flags.
+See  for a list of valid
+flags.
+  - The optional third cell indicates which CPU interrupt vector the GIC
+interrupt should be routed to.  It is a 0-based index into the list of
+GIC-to-CPU interrupts specified in the "interrupts" property described
+above.  For example, a '2' in this cell will route the interrupt to the
+3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
+be routed to the 1st core interrupt.
+
+Example:
+
+   cpu_intc: interrupt-controller@0 {
+   compatible = "mti,cpu-interrupt-controller";
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+
+   gic: interrupt-controller@1bdc {
+   compatible = "mti,global-interrupt-controller";
+   reg = <0x1bdc 0x2>;
+
+   interrupt-controller;
+   #interrupt-cells = <3>;
+
+   interrupt-parent = <_intc>;
+   interrupts = <3>, <4>;
+   };
+
+   uart@18101400 {
+   ...
+   interrupt-parent = <>;
+   interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
+   ...
+   };
-- 
2.1.0.rc2.206.gedb03e5

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

[PATCH 0/2] rockchip-i2s: add power setting for I2S controller and fix some critical bugs

[Jianqun]

Add optional power setting for i2s controller found on rk3066, rk3168 and rk3288
processors from rockchip, should according to hardware design.

Default setting for I2S controller is powered by 3.3V, there needs this patch if
it's powered by 1.8V by hardware design.

Jianqun (2):
  rockchip-i2s: dt: add grf requested properties to set power of I2S controller
  rockchip-i2s: add power setting for I2S controller, also fix some bugs

 .../devicetree/bindings/sound/rockchip-i2s.txt |  6 +-
 sound/soc/rockchip/rockchip_i2s.c  | 93 +-
 sound/soc/rockchip/rockchip_i2s.h  | 13 +--
 3 files changed, 68 insertions(+), 44 deletions(-)

-- 
1.8.3.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 1/2] rockchip-i2s: dt: add grf requested properties to set power of I2S controller

[Jianqun]

Add "rockchip,grf" for driver to get physical address of GRF, and 
"rockchip,grf-io-vsel"
for driver to set voltage for I2S controller according to hardware request.

Requested by rk3xxx I2S controller and tested ok on rk3288-pinky board.

Change-Id: I2587d15c25e64c569857369326653d8a450bae19
Signed-off-by: Jianqun 
---
 Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt 
b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
index 6c55fcf..b995fe6 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
@@ -9,6 +9,8 @@ Required properties:
- "rockchip,rk3066-i2s": for rk3066
- "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188
- "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288
+- rockchip,grf: physical base address of GRF.
+- rockchip,grf-io-vsel: select this if I2S controller powerd by 1.8v.
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: should contain the I2S interrupt.
@@ -26,12 +28,14 @@ Example for rk3288 I2S controller:
 
 i2s@ff89 {
compatible = "rockchip,rk3288-i2s", "rockchip,rk3066-i2s";
+   rockchip,grf = <>;
+   rockchip,grf-io-vsel;
reg = <0xff89 0x1>;
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
dmas = < 0>, < 1>;
-   dma-names = "rx", "tx";
+   dma-names = "tx", "rx";
clock-names = "i2s_hclk", "i2s_clk";
clocks = < HCLK_I2S0>, < SCLK_I2S0>;
 };
-- 
1.8.3.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: [tip:x86/urgent] x86, irq, PCI: Keep IRQ assignment for runtime power management

[Rafael J. Wysocki]

On Saturday, August 30, 2014 12:09:17 AM Rafael J. Wysocki wrote:
> On Friday, August 29, 2014 04:40:14 AM tip-bot for Jiang Liu wrote:
> > Commit-ID:  9eabc99a635a77cbf0948ce17d3cbc2b51680d4a
> > Gitweb: 
> > http://git.kernel.org/tip/9eabc99a635a77cbf0948ce17d3cbc2b51680d4a
> > Author: Jiang Liu 
> > AuthorDate: Fri, 29 Aug 2014 17:26:23 +0800
> > Committer:  Thomas Gleixner 
> > CommitDate: Fri, 29 Aug 2014 13:38:00 +0200
> > 
> > x86, irq, PCI: Keep IRQ assignment for runtime power management
> > 
> > Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
> > We need to keep IRQ assignment for PCI devices during runtime power
> > management, otherwise it may cause failure of device wakeups.
> > 
> > Commit 3eec595235c17a7 "x86, irq, PCI: Keep IRQ assignment for PCI
> > devices during suspend/hibernation" has fixed the issue for suspend/
> > hibernation, we also need the same fix for runtime device sleep too.
> >
> > Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271
> > Reported-and-Tested-by: EmanueL Czirai 
> > Signed-off-by: Jiang Liu 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Tony Luck 
> > Cc: Joerg Roedel 
> > Cc: Greg Kroah-Hartman 
> > Cc: EmanueL Czirai 
> > Cc: Benjamin Herrenschmidt 
> > Cc: Rafael J. Wysocki 
> > Cc: Bjorn Helgaas 
> > Cc: Randy Dunlap 
> > Cc: Yinghai Lu 
> > Cc: Borislav Petkov 
> > Cc: Grant Likely 
> > Link: 
> > http://lkml.kernel.org/r/1409304383-18806-1-git-send-email-jiang@linux.intel.com
> > Signed-off-by: Thomas Gleixner 
> 
> This patch is incorrect, can you please drop it/revert it?

Well, I'm actually not sure that it is correct, but also it is not as
outright incorrect as I thought.

The problem is that dev->power.runtime_status generally cannot be relied
on outside of dev.power->lock, but if mp_should_keep_irq() is guaranteed
to be executed from a callback run by rpm_suspend() for dev, then the
value will be RPM_SUSPENDING.

I'm not quite sure that this always is the case, however.


> > ---
> >  arch/x86/include/asm/io_apic.h |  2 ++
> >  arch/x86/kernel/apic/io_apic.c | 12 
> >  arch/x86/pci/intel_mid_pci.c   |  2 +-
> >  arch/x86/pci/irq.c |  2 +-
> >  drivers/acpi/pci_irq.c |  4 
> >  5 files changed, 20 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> > index 0aeed5c..478c490 100644
> > --- a/arch/x86/include/asm/io_apic.h
> > +++ b/arch/x86/include/asm/io_apic.h
> > @@ -227,6 +227,8 @@ static inline void io_apic_modify(unsigned int apic, 
> > unsigned int reg, unsigned
> >  
> >  extern void io_apic_eoi(unsigned int apic, unsigned int vector);
> >  
> > +extern bool mp_should_keep_irq(struct device *dev);
> > +
> >  #else  /* !CONFIG_X86_IO_APIC */
> >  
> >  #define io_apic_assign_pci_irqs 0
> > diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> > index 40a4aa3..337ce5a 100644
> > --- a/arch/x86/kernel/apic/io_apic.c
> > +++ b/arch/x86/kernel/apic/io_apic.c
> > @@ -3959,6 +3959,18 @@ int mp_set_gsi_attr(u32 gsi, int trigger, int 
> > polarity, int node)
> > return ret;
> >  }
> >  
> > +bool mp_should_keep_irq(struct device *dev)
> > +{
> > +   if (dev->power.is_prepared)
> > +   return true;
> > +#ifdef CONFIG_PM_RUNTIME
> > +   if (dev->power.runtime_status == RPM_SUSPENDING)
> > +   return true;
> > +#endif
> > +
> > +   return false;
> > +}
> > +
> >  /* Enable IOAPIC early just for system timer */
> >  void __init pre_init_apic_IRQ0(void)
> >  {
> > diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
> > index 3865116..b9958c3 100644
> > --- a/arch/x86/pci/intel_mid_pci.c
> > +++ b/arch/x86/pci/intel_mid_pci.c
> > @@ -229,7 +229,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
> >  
> >  static void intel_mid_pci_irq_disable(struct pci_dev *dev)
> >  {
> > -   if (!dev->dev.power.is_prepared && dev->irq > 0)
> > +   if (!mp_should_keep_irq(>dev) && dev->irq > 0)
> > mp_unmap_irq(dev->irq);
> >  }
> >  
> > diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
> > index bc1a2c3..eb500c2 100644
> > --- a/arch/x86/pci/irq.c
> > +++ b/arch/x86/pci/irq.c
> > @@ -1256,7 +1256,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
> >  
> >  static void pirq_disable_irq(struct pci_dev *dev)
> >  {
> > -   if (io_apic_assign_pci_irqs && !dev->dev.power.is_prepared &&
> > +   if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
> > dev->irq) {
> > mp_unmap_irq(dev->irq);
> > dev->irq = 0;
> > diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> > index c96887d..6e6b80e 100644
> > --- a/drivers/acpi/pci_irq.c
> > +++ b/drivers/acpi/pci_irq.c
> > @@ -484,6 +484,10 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
> > /* Keep IOAPIC pin configuration when suspending */
> > if (dev->dev.power.is_prepared)
> > return;
> > +#ifdef CONFIG_PM_RUNTIME
> > +   if 

[PATCH v2 2/3] i2c: add support for Diolan DLN-2 USB-I2C adapter

[Octavian Purdila]

From: Laurentiu Palcu 

This patch adds support for the Diolan DLN-2 I2C master module. Due
to hardware limitations it does not support SMBUS quick commands.

Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 6.2.2 for the I2C
master module commands and responses.

[1] https://www.diolan.com/downloads/dln-api-manual.pdf

Signed-off-by: Laurentiu Palcu 
Signed-off-by: Octavian Purdila 
---
 drivers/i2c/busses/Kconfig|  10 ++
 drivers/i2c/busses/Makefile   |   1 +
 drivers/i2c/busses/i2c-dln2.c | 300 ++
 3 files changed, 311 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-dln2.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2ac87fa..4873161 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1021,4 +1021,14 @@ config SCx200_ACB
  This support is also available as a module.  If so, the module
  will be called scx200_acb.
 
+config I2C_DLN2
+   tristate "Diolan DLN-2 USB I2C adapter"
+   depends on USB && MFD_DLN2
+   help
+ If you say yes to this option, support will be included for Diolan
+ DLN2, a USB to I2C interface.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-dln2.
+
 endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 49bf07e..3118fea 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -100,5 +100,6 @@ obj-$(CONFIG_I2C_ELEKTOR)   += i2c-elektor.o
 obj-$(CONFIG_I2C_PCA_ISA)  += i2c-pca-isa.o
 obj-$(CONFIG_I2C_SIBYTE)   += i2c-sibyte.o
 obj-$(CONFIG_SCx200_ACB)   += scx200_acb.o
+obj-$(CONFIG_I2C_DLN2) += i2c-dln2.o
 
 ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
diff --git a/drivers/i2c/busses/i2c-dln2.c b/drivers/i2c/busses/i2c-dln2.c
new file mode 100644
index 000..cc1335a
--- /dev/null
+++ b/drivers/i2c/busses/i2c-dln2.c
@@ -0,0 +1,300 @@
+/*
+ * Driver for the Diolan DLN-2 USB-I2C adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ *  i2c-diolan-u2c.c
+ *  Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define DRIVER_NAME"dln2-i2c"
+
+#define DLN2_I2C_MODULE_ID 0x03
+#define DLN2_I2C_CMD(cmd)  DLN2_CMD(cmd, DLN2_I2C_MODULE_ID)
+
+/* I2C commands */
+#define DLN2_I2C_GET_PORT_COUNTDLN2_I2C_CMD(0x00)
+#define DLN2_I2C_ENABLEDLN2_I2C_CMD(0x01)
+#define DLN2_I2C_DISABLE   DLN2_I2C_CMD(0x02)
+#define DLN2_I2C_IS_ENABLEDDLN2_I2C_CMD(0x03)
+#define DLN2_I2C_SET_FREQUENCY DLN2_I2C_CMD(0x04)
+#define DLN2_I2C_GET_FREQUENCY DLN2_I2C_CMD(0x05)
+#define DLN2_I2C_WRITE DLN2_I2C_CMD(0x06)
+#define DLN2_I2C_READ  DLN2_I2C_CMD(0x07)
+#define DLN2_I2C_SCAN_DEVICES  DLN2_I2C_CMD(0x08)
+#define DLN2_I2C_PULLUP_ENABLE DLN2_I2C_CMD(0x09)
+#define DLN2_I2C_PULLUP_DISABLEDLN2_I2C_CMD(0x0A)
+#define DLN2_I2C_PULLUP_IS_ENABLED DLN2_I2C_CMD(0x0B)
+#define DLN2_I2C_TRANSFER  DLN2_I2C_CMD(0x0C)
+#define DLN2_I2C_SET_MAX_REPLY_COUNT   DLN2_I2C_CMD(0x0D)
+#define DLN2_I2C_GET_MAX_REPLY_COUNT   DLN2_I2C_CMD(0x0E)
+#define DLN2_I2C_GET_MIN_FREQUENCY DLN2_I2C_CMD(0x40)
+#define DLN2_I2C_GET_MAX_FREQUENCY DLN2_I2C_CMD(0x41)
+
+#define DLN2_I2C_FREQ_FAST 40
+#define DLN2_I2C_FREQ_STD  10
+
+#define DLN2_I2C_MAX_XFER_SIZE 256
+
+struct dln2_i2c {
+   struct platform_device *pdev;
+   struct i2c_adapter adapter;
+};
+
+static uint frequency = DLN2_I2C_FREQ_STD; /* I2C clock frequency in Hz */
+
+module_param(frequency, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(frequency, "I2C clock frequency in hertz");
+
+static int dln2_i2c_set_state(struct dln2_i2c *dln2, u8 state)
+{
+   int ret;
+   u8 port = 0;
+
+   ret = dln2_transfer(dln2->pdev,
+   state ? DLN2_I2C_ENABLE : DLN2_I2C_DISABLE,
+   , sizeof(port), NULL, NULL);
+
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+#define dln2_i2c_enable(dln2)  dln2_i2c_set_state(dln2, 1)
+#define dln2_i2c_disable(dln2) dln2_i2c_set_state(dln2, 0)
+
+static int dln2_i2c_set_frequency(struct dln2_i2c *dln2, u32 freq)
+{
+   int ret;
+   struct tx_data {
+   u8 port;
+   __le32 freq;
+   } __packed tx;
+
+   tx.port = 0;
+   tx.freq = cpu_to_le32(freq);
+
+   ret = dln2_transfer(dln2->pdev, DLN2_I2C_SET_FREQUENCY, , sizeof(tx),
+   

[PATCH v2 3/3] gpio: add support for the Diolan DLN-2 USB GPIO driver

[Octavian Purdila]

From: Daniel Baluta 

This patch adds GPIO and IRQ support for the Diolan DLN-2 GPIO module.

Information about the USB protocol interface can be found in the
Programmer's Reference Manual [1], see section 2.9 for the GPIO
module commands and responses.

[1] https://www.diolan.com/downloads/dln-api-manual.pdf

Signed-off-by: Daniel Baluta 
Signed-off-by: Octavian Purdila 
---
 drivers/gpio/Kconfig |  12 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-dln2.c | 506 +++
 3 files changed, 519 insertions(+)
 create mode 100644 drivers/gpio/gpio-dln2.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..6a9e352 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -897,4 +897,16 @@ config GPIO_VIPERBOARD
   River Tech's viperboard.h for detailed meaning
   of the module parameters.
 
+config GPIO_DLN2
+   tristate "Diolan DLN2 GPIO support"
+   depends on USB && MFD_DLN2
+   select GPIOLIB_IRQCHIP
+
+   help
+ Select this option to enable GPIO driver for the Diolan DLN2
+ board.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-dln2.
+
 endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 5d024e3..eaa97a0 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_GPIO_CRYSTAL_COVE)   += gpio-crystalcove.o
 obj-$(CONFIG_GPIO_DA9052)  += gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)  += gpio-da9055.o
 obj-$(CONFIG_GPIO_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DLN2)+= gpio-dln2.o
 obj-$(CONFIG_GPIO_DWAPB)   += gpio-dwapb.o
 obj-$(CONFIG_GPIO_EM)  += gpio-em.o
 obj-$(CONFIG_GPIO_EP93XX)  += gpio-ep93xx.o
diff --git a/drivers/gpio/gpio-dln2.c b/drivers/gpio/gpio-dln2.c
new file mode 100644
index 000..bb6cb1e
--- /dev/null
+++ b/drivers/gpio/gpio-dln2.c
@@ -0,0 +1,506 @@
+/*
+ * Driver for the Diolan DLN-2 USB-GPIO adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "dln2-gpio"
+
+#define DLN2_GPIO_ID   0x01
+
+#define DLN2_GPIO_GET_PORT_COUNT   DLN2_CMD(0x00, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_PIN_COUNTDLN2_CMD(0x01, DLN2_GPIO_ID)
+#define DLN2_GPIO_SET_DEBOUNCE DLN2_CMD(0x04, DLN2_GPIO_ID)
+#define DLN2_GPIO_GET_DEBOUNCE DLN2_CMD(0x05, DLN2_GPIO_ID)
+#define DLN2_GPIO_PORT_GET_VAL DLN2_CMD(0x06, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_VAL  DLN2_CMD(0x0B, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_OUT_VAL  DLN2_CMD(0x0C, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_OUT_VAL  DLN2_CMD(0x0D, DLN2_GPIO_ID)
+#define DLN2_GPIO_CONDITION_MET_EV DLN2_CMD(0x0F, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_ENABLE   DLN2_CMD(0x10, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_DISABLE  DLN2_CMD(0x11, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_DIRECTIONDLN2_CMD(0x13, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_DIRECTIONDLN2_CMD(0x14, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_SET_EVENT_CFGDLN2_CMD(0x1E, DLN2_GPIO_ID)
+#define DLN2_GPIO_PIN_GET_EVENT_CFGDLN2_CMD(0x1F, DLN2_GPIO_ID)
+
+#define DLN2_GPIO_EVENT_NONE   0
+#define DLN2_GPIO_EVENT_CHANGE 1
+#define DLN2_GPIO_EVENT_LVL_HIGH   2
+#define DLN2_GPIO_EVENT_LVL_LOW3
+#define DLN2_GPIO_EVENT_CHANGE_RISING  0x11
+#define DLN2_GPIO_EVENT_CHANGE_FALLING  0x21
+#define DLN2_GPIO_EVENT_MASK   0x0F
+
+#define DLN2_GPIO_MAX_PINS 32
+
+struct dln2_irq_work {
+   struct work_struct work;
+   struct dln2_gpio *dln2;
+   int pin, type;
+};
+
+struct dln2_gpio {
+   struct platform_device *pdev;
+   struct gpio_chip gpio;
+
+   DECLARE_BITMAP(irqs_masked, DLN2_GPIO_MAX_PINS);
+   DECLARE_BITMAP(irqs_enabled, DLN2_GPIO_MAX_PINS);
+   DECLARE_BITMAP(irqs_pending, DLN2_GPIO_MAX_PINS);
+   struct dln2_irq_work irq_work[DLN2_GPIO_MAX_PINS];
+};
+
+struct dln2_gpio_pin {
+   __le16 pin;
+} __packed;
+
+struct dln2_gpio_pin_val {
+   __le16 pin;
+   u8 value;
+} __packed;
+
+static int dln2_gpio_get_pin_count(struct platform_device *pdev)
+{
+   __le16 count;
+   int ret, len = sizeof(count);
+
+   ret = dln2_transfer(pdev, DLN2_GPIO_GET_PIN_COUNT, NULL, 0, ,
+   );
+   if (ret < 0)
+   return ret;
+
+   if (len < sizeof(count))
+   return -EPROTO;
+
+   return le16_to_cpu(count);
+}
+
+static int dln2_gpio_pin_cmd(struct dln2_gpio *dln2, int cmd, unsigned pin)
+{
+   

[PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices

[Octavian Purdila]

This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
Master Adapter DLN-2. Details about the device can be found here:

https://www.diolan.com/i2c/i2c_interface.html.

Information about the USB protocol can be found in the Programmer's
Reference Manual [1], see section 1.7.

Because the hardware has a single transmit endpoint and a single
receive endpoint the communication between the various DLN2 drivers
and the hardware will be muxed/demuxed by this driver.

Each DLN2 module will be identified by the handle field within the DLN2
message header. If a DLN2 module issues multiple commands in parallel
they will be identified by the echo counter field in the message header.

The DLN2 modules can use the dln2_transfer() function to issue a
command and wait for its response. They can also register a callback
that is going to be called when a specific event id is generated by
the device (e.g. GPIO interrupts). The device uses handle 0 for
sending events.

[1] https://www.diolan.com/downloads/dln-api-manual.pdf

Signed-off-by: Octavian Purdila 
---
 drivers/mfd/Kconfig  |   9 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/dln2.c   | 652 +++
 include/linux/mfd/dln2.h |  64 +
 4 files changed, 726 insertions(+)
 create mode 100644 drivers/mfd/dln2.c
 create mode 100644 include/linux/mfd/dln2.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..7bcf895 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -183,6 +183,15 @@ config MFD_DA9063
  Additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_DLN2
+   tristate "Diolan DLN2 support"
+   select MFD_CORE
+   depends on USB
+   help
+ This adds support for Diolan USB-I2C/SPI/GPIO Master Adapter DLN-2.
+ Additional drivers must be enabled in order to use the functionality
+ of the device.
+
 config MFD_MC13XXX
tristate
depends on (SPI_MASTER || I2C)
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..591988d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
 obj-$(CONFIG_MFD_AS3722)   += as3722.o
 obj-$(CONFIG_MFD_STW481X)  += stw481x.o
 obj-$(CONFIG_MFD_IPAQ_MICRO)   += ipaq-micro.o
+obj-$(CONFIG_MFD_DLN2) += dln2.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
diff --git a/drivers/mfd/dln2.c b/drivers/mfd/dln2.c
new file mode 100644
index 000..ccd44fe
--- /dev/null
+++ b/drivers/mfd/dln2.c
@@ -0,0 +1,652 @@
+/*
+ * Driver for the Diolan DLN-2 USB adapter
+ *
+ * Copyright (c) 2014 Intel Corporation
+ *
+ * Derived from:
+ *  i2c-diolan-u2c.c
+ *  Copyright (c) 2010-2011 Ericsson AB
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME"usb-dln2"
+
+struct dln2_header {
+   __le16 size;
+   __le16 id;
+   __le16 echo;
+   __le16 handle;
+} __packed;
+
+struct dln2_response {
+   struct dln2_header hdr;
+   __le16 result;
+} __packed;
+
+#define DLN2_GENERIC_MODULE_ID 0x00
+#define DLN2_GENERIC_CMD(cmd)  DLN2_CMD(cmd, DLN2_GENERIC_MODULE_ID)
+#define CMD_GET_DEVICE_VER DLN2_GENERIC_CMD(0x30)
+#define CMD_GET_DEVICE_SN  DLN2_GENERIC_CMD(0x31)
+
+#define DLN2_HW_ID 0x200
+#define DLN2_USB_TIMEOUT   200 /* in ms */
+#define DLN2_MAX_RX_SLOTS  16
+#define DLN2_MAX_MODULES   5
+#define DLN2_MAX_URBS  16
+
+#define DLN2_HANDLE_GPIO_EVENT 0
+#define DLN2_HANDLE_CTRL   1
+#define DLN2_HANDLE_GPIO   2
+#define DLN2_HANDLE_I2C3
+
+/* Receive context used between the receive demultiplexer and the
+ * transfer routine. While sending a request the transfer routine
+ * will look for a free receive context and use it to wait for a
+ * response and to receive the URB and thus the response data. */
+struct dln2_rx_context {
+   struct completion done;
+   struct urb *urb;
+   bool connected;
+};
+
+/* Receive contexts for a particular DLN2 module (i2c, gpio, etc.). We
+ * use the handle header field to indentify the module in
+ * dln2_dev.mod_rx_slots and then the echo header field to index the
+ * slots field and find the receive context for a particular
+ * request. */
+struct dln2_mod_rx_slots {
+   /* RX slots bitmap */
+   unsigned long bmap;
+
+   /* used to wait for a free RX slot */
+   wait_queue_head_t wq;
+
+   /* used to wait for an RX 

[PATCH v2 0/3] mfd: add support for Diolan DLN-2

[Octavian Purdila]

This patch series adds support for Diolan USB-I2C/GPIO Master Adapter DLN-2.
Details about device can be found here:

https://www.diolan.com/i2c/i2c_interface.html.

Changes since v1:

 * rewrite the drivers as an MFD

 * rewrite the irq part of the gpio driver to use GPIOLIB_IRQCHIP 

 * cleanup the I/O interface 

 * various fixes and cleanps: check received message sizes before
   parsing, error handling for usb_submit_urb, check URB status, use
   single bit manipulation functions instead of bitmap_*, move
   GFP_KERNEL URB submit away from under lock



Daniel Baluta (1):
  gpio: add support for the Diolan DLN-2 USB GPIO driver

Laurentiu Palcu (1):
  i2c: add support for Diolan DLN-2 USB-I2C adapter

Octavian Purdila (1):
  mfd: add support for Diolan DLN-2 devices

 drivers/gpio/Kconfig  |  12 +
 drivers/gpio/Makefile |   1 +
 drivers/gpio/gpio-dln2.c  | 506 
 drivers/i2c/busses/Kconfig|  10 +
 drivers/i2c/busses/Makefile   |   1 +
 drivers/i2c/busses/i2c-dln2.c | 300 +++
 drivers/mfd/Kconfig   |   9 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/dln2.c| 652 ++
 include/linux/mfd/dln2.h  |  64 +
 10 files changed, 1556 insertions(+)
 create mode 100644 drivers/gpio/gpio-dln2.c
 create mode 100644 drivers/i2c/busses/i2c-dln2.c
 create mode 100644 drivers/mfd/dln2.c
 create mode 100644 include/linux/mfd/dln2.h

-- 
1.9.1

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

Re: net_ns cleanup / RCU overhead

[Eric W. Biederman]

Julian Anastasov  writes:

>   Hello,
>
> On Thu, 28 Aug 2014, Simon Kirby wrote:
>
>> I noticed that [kworker/u16:0]'s stack is often:
>> 
>> [] wait_rcu_gp+0x46/0x50
>> [] synchronize_sched+0x2e/0x50
>> [] nf_nat_net_exit+0x2c/0x50 [nf_nat]
>
>   I guess the problem is in nf_nat_net_exit,
> may be other nf exit handlers too. pernet-exit handlers
> should avoid synchronize_rcu and rcu_barrier.
> A RCU callback and rcu_barrier in module-exit is the way
> to go. cleanup_net includes rcu_barrier, so pernet-exit
> does not need such calls.

In principle I agree, however in this particular case it looks a bit
tricky because a separate hash table to track nat state per network
namespace.

At the same time all of the packets should be drained before
we get to nf_nat_net_exit so it doesn't look the synchronize_rcu
in nf_nat_exit is actually protecting anything.

Further calling a rcu delay function in net_exit methods largely
destroys the batched cleanup of network namespaces, so it is very
unpleasant.

Could someone who knows nf_nat_core.c better than I do look and
see if we can just remove the synchronize_rcu in nf_nat_exit?

>> [] ops_exit_list.isra.4+0x39/0x60
>> [] cleanup_net+0xf0/0x1a0
>> [] process_one_work+0x157/0x440
>> [] worker_thread+0x63/0x520
>> [] kthread+0xd6/0xf0
>> [] ret_from_fork+0x7c/0xb0
>> [] 0x

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

Re: [PATCH resend v5 0/2] ARM: sunxi: RTC support for A31/A23

[Maxime Ripard]

Hi Alessandro,

On Tue, Aug 26, 2014 at 11:54:54AM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
> 
> Resending the sun6i RTC series, rebased onto 3.17-rc1.
> The DT/defconfig patches have been queued for 3.18, and therefore
> dropped from this series. Hope we can get the driver parts in as
> well.
> 
> The A31 has a new RTC block that is separate from the timer block.
> It has separate interrupts for each of the alarms, and a different
> format for the counter alarm. The driver has been tested on the
> A31 Hummingbird, and the A23 tablet I'm using to work on sun8i
> support.
> 
> Patch 1 adds the driver for the RTC.
> 
> Patch 2 is a minor cleanup. This makes rtc-sunxi depend on sun4i or
> sun7i, the 2 platforms the driver is actually used on.

I'm quite happy with these patches. Are you?

IIRC, you prefer that we merge these kind of patches by our tree, are
you still ok with that? I'd feel more comfortable having an Acked-by
from you on this.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [tip:x86/urgent] x86, irq, PCI: Keep IRQ assignment for runtime power management

[Rafael J. Wysocki]

On Friday, August 29, 2014 04:40:14 AM tip-bot for Jiang Liu wrote:
> Commit-ID:  9eabc99a635a77cbf0948ce17d3cbc2b51680d4a
> Gitweb: http://git.kernel.org/tip/9eabc99a635a77cbf0948ce17d3cbc2b51680d4a
> Author: Jiang Liu 
> AuthorDate: Fri, 29 Aug 2014 17:26:23 +0800
> Committer:  Thomas Gleixner 
> CommitDate: Fri, 29 Aug 2014 13:38:00 +0200
> 
> x86, irq, PCI: Keep IRQ assignment for runtime power management
> 
> Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
> We need to keep IRQ assignment for PCI devices during runtime power
> management, otherwise it may cause failure of device wakeups.
> 
> Commit 3eec595235c17a7 "x86, irq, PCI: Keep IRQ assignment for PCI
> devices during suspend/hibernation" has fixed the issue for suspend/
> hibernation, we also need the same fix for runtime device sleep too.
>
> Fix: https://bugzilla.kernel.org/show_bug.cgi?id=83271
> Reported-and-Tested-by: EmanueL Czirai 
> Signed-off-by: Jiang Liu 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Tony Luck 
> Cc: Joerg Roedel 
> Cc: Greg Kroah-Hartman 
> Cc: EmanueL Czirai 
> Cc: Benjamin Herrenschmidt 
> Cc: Rafael J. Wysocki 
> Cc: Bjorn Helgaas 
> Cc: Randy Dunlap 
> Cc: Yinghai Lu 
> Cc: Borislav Petkov 
> Cc: Grant Likely 
> Link: 
> http://lkml.kernel.org/r/1409304383-18806-1-git-send-email-jiang@linux.intel.com
> Signed-off-by: Thomas Gleixner 

This patch is incorrect, can you please drop it/revert it?

Rafael


> ---
>  arch/x86/include/asm/io_apic.h |  2 ++
>  arch/x86/kernel/apic/io_apic.c | 12 
>  arch/x86/pci/intel_mid_pci.c   |  2 +-
>  arch/x86/pci/irq.c |  2 +-
>  drivers/acpi/pci_irq.c |  4 
>  5 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
> index 0aeed5c..478c490 100644
> --- a/arch/x86/include/asm/io_apic.h
> +++ b/arch/x86/include/asm/io_apic.h
> @@ -227,6 +227,8 @@ static inline void io_apic_modify(unsigned int apic, 
> unsigned int reg, unsigned
>  
>  extern void io_apic_eoi(unsigned int apic, unsigned int vector);
>  
> +extern bool mp_should_keep_irq(struct device *dev);
> +
>  #else  /* !CONFIG_X86_IO_APIC */
>  
>  #define io_apic_assign_pci_irqs 0
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 40a4aa3..337ce5a 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -3959,6 +3959,18 @@ int mp_set_gsi_attr(u32 gsi, int trigger, int 
> polarity, int node)
>   return ret;
>  }
>  
> +bool mp_should_keep_irq(struct device *dev)
> +{
> + if (dev->power.is_prepared)
> + return true;
> +#ifdef   CONFIG_PM_RUNTIME
> + if (dev->power.runtime_status == RPM_SUSPENDING)
> + return true;
> +#endif
> +
> + return false;
> +}
> +
>  /* Enable IOAPIC early just for system timer */
>  void __init pre_init_apic_IRQ0(void)
>  {
> diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
> index 3865116..b9958c3 100644
> --- a/arch/x86/pci/intel_mid_pci.c
> +++ b/arch/x86/pci/intel_mid_pci.c
> @@ -229,7 +229,7 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
>  
>  static void intel_mid_pci_irq_disable(struct pci_dev *dev)
>  {
> - if (!dev->dev.power.is_prepared && dev->irq > 0)
> + if (!mp_should_keep_irq(>dev) && dev->irq > 0)
>   mp_unmap_irq(dev->irq);
>  }
>  
> diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
> index bc1a2c3..eb500c2 100644
> --- a/arch/x86/pci/irq.c
> +++ b/arch/x86/pci/irq.c
> @@ -1256,7 +1256,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
>  
>  static void pirq_disable_irq(struct pci_dev *dev)
>  {
> - if (io_apic_assign_pci_irqs && !dev->dev.power.is_prepared &&
> + if (io_apic_assign_pci_irqs && !mp_should_keep_irq(>dev) &&
>   dev->irq) {
>   mp_unmap_irq(dev->irq);
>   dev->irq = 0;
> diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
> index c96887d..6e6b80e 100644
> --- a/drivers/acpi/pci_irq.c
> +++ b/drivers/acpi/pci_irq.c
> @@ -484,6 +484,10 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
>   /* Keep IOAPIC pin configuration when suspending */
>   if (dev->dev.power.is_prepared)
>   return;
> +#ifdef   CONFIG_PM_RUNTIME
> + if (dev->dev.power.runtime_status == RPM_SUSPENDING)
> + return;
> +#endif
>  
>   entry = acpi_pci_irq_lookup(dev, pin);
>   if (!entry)

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

[Andrew Morton]

On Wed, 20 Aug 2014 19:05:09 +0400 Konstantin Khlebnikov 
 wrote:

> * move special branch for balloon migraion into migrate_pages
> * remove special mapping for balloon and its flag AS_BALLOON_MAP
> * embed struct balloon_dev_info into struct virtio_balloon
> * cleanup balloon_page_dequeue, kill balloon_page_free

Another testing failure.  Guys, allnoconfig is really fast.

> --- a/include/linux/balloon_compaction.h
> +++ b/include/linux/balloon_compaction.h
> @@ -54,58 +54,27 @@
>   * balloon driver as a page book-keeper for its registered balloon devices.
>   */
>  struct balloon_dev_info {
> - void *balloon_device;   /* balloon device descriptor */
> - struct address_space *mapping;  /* balloon special page->mapping */
>   unsigned long isolated_pages;   /* # of isolated pages for migration */
>   spinlock_t pages_lock;  /* Protection to pages list */
>   struct list_head pages; /* Pages enqueued & handled to Host */
> + int (* migrate_page)(struct balloon_dev_info *, struct page *newpage,
> + struct page *page, enum migrate_mode mode);
>  };

If CONFIG_MIGRATION=n this gets turned into "NULL" and chaos ensues.  I
think I'll just nuke that #define:

--- a/include/linux/migrate.h~include-linux-migrateh-remove-migratepage-define
+++ a/include/linux/migrate.h
@@ -82,9 +82,6 @@ static inline int migrate_huge_page_move
return -ENOSYS;
 }
 
-/* Possible settings for the migrate_page() method in address_operations */
-#define migrate_page NULL
-
 #endif /* CONFIG_MIGRATION */
 
 #ifdef CONFIG_NUMA_BALANCING
--- a/mm/swap_state.c~include-linux-migrateh-remove-migratepage-define
+++ a/mm/swap_state.c
@@ -28,7 +28,9 @@
 static const struct address_space_operations swap_aops = {
.writepage  = swap_writepage,
.set_page_dirty = swap_set_page_dirty,
+#ifdef CONFIG_MIGRATION
.migratepage= migrate_page,
+#endif
 };
 
 static struct backing_dev_info swap_backing_dev_info = {
--- a/mm/shmem.c~include-linux-migrateh-remove-migratepage-define
+++ a/mm/shmem.c
@@ -3075,7 +3075,9 @@ static const struct address_space_operat
.write_begin= shmem_write_begin,
.write_end  = shmem_write_end,
 #endif
+#ifdef CONFIG_MIGRATION
.migratepage= migrate_page,
+#endif
.error_remove_page = generic_error_remove_page,
 };
 

Our mixture of "migratepage" and "migrate_page" is maddening.

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

[Rafael Aquini]

On Fri, Aug 29, 2014 at 05:09:55PM -0400, Rafael Aquini wrote:
> On Fri, Aug 29, 2014 at 02:05:21PM -0700, Andrew Morton wrote:
> > On Wed, 20 Aug 2014 19:05:09 +0400 Konstantin Khlebnikov 
> >  wrote:
> > 
> > > * move special branch for balloon migraion into migrate_pages
> > > * remove special mapping for balloon and its flag AS_BALLOON_MAP
> > > * embed struct balloon_dev_info into struct virtio_balloon
> > > * cleanup balloon_page_dequeue, kill balloon_page_free
> > > 
> > 
> > grump.
> > 
> > diff -puN 
> > include/linux/balloon_compaction.h~mm-balloon_compaction-general-cleanup-fix
> >  include/linux/balloon_compaction.h
> > --- 
> > a/include/linux/balloon_compaction.h~mm-balloon_compaction-general-cleanup-fix
> > +++ a/include/linux/balloon_compaction.h
> > @@ -145,7 +145,7 @@ static inline void
> >  balloon_page_insert(struct balloon_dev_info *balloon, struct page *page)
> >  {
> > __SetPageBalloon(page);
> > -   list_add(>lru, head);
> > +   list_add(>lru, >pages);
> >  }
> >  
> >  static inline void balloon_page_delete(struct page *page, bool isolated)
> > 
> > 
> > This obviously wasn't tested with CONFIG_BALLOON_COMPACTION=n.  Please
> > complete the testing of this patchset and let us know the result?
> >
>

Btw, I'll do a mea culpa here. Although this build failure was addressed
by my extra-cleanup suggestion, I never made that statement clear at my
original message.

http://permalink.gmane.org/gmane.linux.kernel.mm/121788

Sorry,
-- Rafael
 
> That also reminds me why I suggested moving those as static inlines into 
> mm.h, 
> instead of getting them hidden in mm/balloon_compaction.c
> 
> Cheers,
> -- Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.10.y regression caused by: lockd: ensure we tear down any live sockets when socket creation fails during lockd_up

[Jeff Layton]

On Fri, 29 Aug 2014 16:25:33 -0400
"J. Bruce Fields"  wrote:

> On Mon, Jul 07, 2014 at 03:27:21PM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Jun 20, 2014 at 03:14:03PM +0400, Nikita Yushchenko wrote:
> > > With current 3.10.y, if kernel is booted with init=/bin/sh and then nfs 
> > > mount
> > > is attempted (without portmap or rpcbind running) using busybox mount, 
> > > following
> > > OOPS happen:
> > > 
> > > # mount -t nfs 10.30.130.21:/opt /mnt
> > > svc: failed to register lockdv1 RPC service (errno 111).
> > > lockd_up: makesock failed, error=-111
> > > Unable to handle kernel paging request for data at address 0x0030
> > > Faulting instruction address: 0xc055e65c
> > > Oops: Kernel access of bad area, sig: 11 [#1]
> > > MPC85xx CDS
> > > Modules linked in:
> > > CPU: 0 PID: 1338 Comm: mount Not tainted 3.10.44.cge #117
> > > task: cf29cea0 ti: cf35c000 task.ti: cf35c000
> > > NIP: c055e65c LR: c0566490 CTR: c055e648
> > > REGS: cf35dad0 TRAP: 0300   Not tainted  (3.10.44.cge)
> > > MSR: 00029000   CR: 22442488  XER: 2000
> > > DEAR: 0030, ESR: 
> > > 
> > > GPR00: c05606f4 cf35db80 cf29cea0 cf0ded80 cf0dedb8 0001 1dec3086 
> > >  
> > > GPR08:  c07b1640 0007 1dec3086 22442482 100b9758  
> > > 10090ae8 
> > > GPR16:  000186a5   100c3018 bfa46edc 100b 
> > > bfa46ef0 
> > > GPR24: cf386ae0 c07834f0  c0565f88 0001 cf0dedb8  
> > > cf0ded80 
> > > NIP [c055e65c] call_start+0x14/0x34
> > > LR [c0566490] __rpc_execute+0x70/0x250
> > > Call Trace:
> > > [cf35db80] [0080] 0x80 (unreliable)
> > > [cf35dbb0] [c05606f4] rpc_run_task+0x9c/0xc4
> > > [cf35dbc0] [c0560840] rpc_call_sync+0x50/0xb8
> > > [cf35dbf0] [c056ee90] rpcb_register_call+0x54/0x84
> > > [cf35dc10] [c056f24c] rpcb_register+0xf8/0x10c
> > > [cf35dc70] [c0569e18] svc_unregister.isra.23+0x100/0x108
> > > [cf35dc90] [c0569e38] svc_rpcb_cleanup+0x18/0x30
> > > [cf35dca0] [c0198c5c] lockd_up+0x1dc/0x2e0
> > > [cf35dcd0] [c0195348] nlmclnt_init+0x2c/0xc8
> > > [cf35dcf0] [c015bb5c] nfs_start_lockd+0x98/0xec
> > > [cf35dd20] [c015ce6c] nfs_create_server+0x1e8/0x3f4
> > > [cf35dd90] [c0171590] nfs3_create_server+0x10/0x44
> > > [cf35dda0] [c016528c] nfs_try_mount+0x158/0x1e4
> > > [cf35de20] [c01670d0] nfs_fs_mount+0x434/0x8c8
> > > [cf35de70] [c00cd3bc] mount_fs+0x20/0xbc
> > > [cf35de90] [c00e4f88] vfs_kern_mount+0x50/0x104
> > > [cf35dec0] [c00e6e0c] do_mount+0x1d0/0x8e0
> > > [cf35df10] [c00e75ac] SyS_mount+0x90/0xd0
> > > [cf35df40] [c000ccf4] ret_from_syscall+0x0/0x3c
> > > --- Exception: c01 at 0xff2acc4
> > > LR = 0x10048ab8
> > > Instruction dump:
> > > 3d20c056 3929e648 91230028 3861 4e800020 3860 4e800020 81230014 
> > > 8103000c 81490014 394a0001 91490014 <81280030> 81490018 394a0001 91490018 
> > > ---[ end trace 033b5b4715cb5452 ]---
> > > 
> > > 
> > > This does not happen if
> > > 
> > > commit 72a6e594497032bd911bd187a88fae4b4473abb3
> > > Author: Jeff Layton 
> > > Date:   Tue Mar 25 11:55:26 2014 -0700
> > > 
> > > lockd: ensure we tear down any live sockets when socket creation 
> > > fails during lockd_up
> > > 
> > > commit 679b033df48422191c4cac52b610d9980e019f9b upstream.
> > > 
> > > is reverted:
> > > 
> > > # mount -t nfs 10.30.130.21:/opt /mnt
> > > svc: failed to register lockdv1 RPC service (errno 111).
> > > lockd_up: makesock failed, error=-111
> > > mount: mounting 10.30.130.21:/opt on /mnt failed: Connection refused
> > > #
> > > 
> > > 
> > > Physical reason of the OOPS is that:
> > > 
> > > - addition of svc_shutdown_net() call to error path of make_socks() causes
> > > double call of svc_rpcb_cleanup():
> > >   - first call is from within svc_shutdown_net(), because 
> > > serv->sv_shutdown
> > > points to svc_rpcb_cleanup() at this time,
> > >   - immediately followed by second call from lockd_up_net()'s error path
> > > 
> > > - when second svc_rpcb_cleanup() is executed, then at
> > >   svc_unregister() -> __svc_unregister() -> rpcb_register() -> 
> > > rpcb_register_call()
> > > call path, rpcb_register_call() is called with clnt=NULL.
> > 
> > So, Jeff, what should I do here?  Drop this patch from 3.10?  Add
> > something else to fix it up?  Something else entirely?
> 
> Sorry this got ignored.  Adding more useful addressess
> 
> So looks like the new svc_shutdown_net made lockd_up_net's cleanup
> redundant, and just removing it might do the job?
> 
> --b.
> 
> diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
> index 673668a9eec1..685e953c5103 100644
> --- a/fs/lockd/svc.c
> +++ b/fs/lockd/svc.c
> @@ -253,13 +253,11 @@ static int lockd_up_net(struct svc_serv *serv, struct 
> net *net)
>  
>   error = make_socks(serv, net);
>   if (error < 0)
> - goto err_socks;
> + goto err_bind;
>   set_grace_period(net);
>   dprintk("lockd_up_net: per-net data created; net=%p\n", net);
>   return 0;
>  
> -err_socks:
> - svc_rpcb_cleanup(serv, 

[GIT PULL] ACPI and power management fixes for 3.17-rc3

[Rafael J. Wysocki]

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm+acpi-3.17-rc3

to receive more ACPI and power management fixes for v3.17-rc3 with
top-most commit 0b4f58b7cebd74ede19d13b81fb43a7eaeba10a3

 Merge branch 'pm-cpufreq'

on top of commit 52addcf9d6669fa439387610bc65c92fa0980cef

 Linux 3.17-rc2

These are ACPI regression fixes (fixed events handling, EC driver
and PNP enumeration), intel_pstate fix for excessive messages on
boot, spurious __init removal from the s5pv210 cpufreq driver and
new IDs for Intel Braswell.

Specifics:

 - Fix for an ACPI regression related to the handling of fixed events
   that caused netlink routines to be (incorrectly) run in interrupt
   context from Lan Tianyu.

 - Fix for an ACPI EC driver regression on Acer Aspire V5-573G that
   caused AC/battery plug/unplug and video brightness change
   notifications to be delayed on that machine from Lv Zheng.

 - Fix for an ACPI device enumeration regression that caused ACPI
   driver probe to fail for some devices where it succeeded before
   (Rafael J Wysocki).

 - intel_pstate driver fix to prevent it from printing an information
   message for every CPU in the system on every boot from Andi Kleen.

 - s5pv210 cpufreq driver fix to remove an __init annotation from
   a routine that in fact can be called at any time after init too
   from Mark Brown.

 - New Intel Braswell device IDs for the ACPI LPSS (Low-Power Subsystem)
   driver from Alan Cox.

 - New Intel Braswell CPU ID for intel_pstate from Mika Westerberg.

Thanks!


---

Alan Cox (1):
  ACPI / LPSS: Add ACPI IDs for Intel Braswell

Andi Kleen (1):
  intel_pstate: Turn per cpu printk into pr_debug

Lan Tianyu (1):
  ACPI: Run fixed event device notifications in process context

Lv Zheng (2):
  ACPI / EC: Add support to disallow QR_EC to be issued when
SCI_EVT isn't set
  ACPI / EC: Add support to disallow QR_EC to be issued before
completing previous QR_EC

Mark Brown (1):
  cpufreq: s5pv210: Remove spurious __init annotation

Mika Westerberg (1):
  cpufreq: intel_pstate: Add CPU ID for Braswell processor

Rafael J. Wysocki (1):
  ACPI / scan: Allow ACPI drivers to bind to PNP device objects

---

 drivers/acpi/acpi_lpss.c  | 17 +
 drivers/acpi/ec.c | 21 ++---
 drivers/acpi/scan.c   | 17 +++--
 drivers/cpufreq/intel_pstate.c|  3 ++-
 drivers/cpufreq/s5pv210-cpufreq.c |  2 +-
 5 files changed, 49 insertions(+), 11 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/

Re: [PATCH 7/7] mm/balloon_compaction: general cleanup

[Rafael Aquini]

On Fri, Aug 29, 2014 at 02:05:21PM -0700, Andrew Morton wrote:
> On Wed, 20 Aug 2014 19:05:09 +0400 Konstantin Khlebnikov 
>  wrote:
> 
> > * move special branch for balloon migraion into migrate_pages
> > * remove special mapping for balloon and its flag AS_BALLOON_MAP
> > * embed struct balloon_dev_info into struct virtio_balloon
> > * cleanup balloon_page_dequeue, kill balloon_page_free
> > 
> 
> grump.
> 
> diff -puN 
> include/linux/balloon_compaction.h~mm-balloon_compaction-general-cleanup-fix 
> include/linux/balloon_compaction.h
> --- 
> a/include/linux/balloon_compaction.h~mm-balloon_compaction-general-cleanup-fix
> +++ a/include/linux/balloon_compaction.h
> @@ -145,7 +145,7 @@ static inline void
>  balloon_page_insert(struct balloon_dev_info *balloon, struct page *page)
>  {
>   __SetPageBalloon(page);
> - list_add(>lru, head);
> + list_add(>lru, >pages);
>  }
>  
>  static inline void balloon_page_delete(struct page *page, bool isolated)
> 
> 
> This obviously wasn't tested with CONFIG_BALLOON_COMPACTION=n.  Please
> complete the testing of this patchset and let us know the result?
>

That also reminds me why I suggested moving those as static inlines into mm.h, 
instead of getting them hidden in mm/balloon_compaction.c

Cheers,
-- Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 7/7] mm/balloon_compaction: general cleanup

[Andrew Morton]

On Wed, 20 Aug 2014 19:05:09 +0400 Konstantin Khlebnikov 
 wrote:

> * move special branch for balloon migraion into migrate_pages
> * remove special mapping for balloon and its flag AS_BALLOON_MAP
> * embed struct balloon_dev_info into struct virtio_balloon
> * cleanup balloon_page_dequeue, kill balloon_page_free
> 

grump.

diff -puN 
include/linux/balloon_compaction.h~mm-balloon_compaction-general-cleanup-fix 
include/linux/balloon_compaction.h
--- 
a/include/linux/balloon_compaction.h~mm-balloon_compaction-general-cleanup-fix
+++ a/include/linux/balloon_compaction.h
@@ -145,7 +145,7 @@ static inline void
 balloon_page_insert(struct balloon_dev_info *balloon, struct page *page)
 {
__SetPageBalloon(page);
-   list_add(>lru, head);
+   list_add(>lru, >pages);
 }
 
 static inline void balloon_page_delete(struct page *page, bool isolated)


This obviously wasn't tested with CONFIG_BALLOON_COMPACTION=n.  Please
complete the testing of this patchset and let us know the result?

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: [RFC v1 2/2] usb: otg: Temporarily hold wakeupsource on charger

[Felipe Balbi]

On Thu, Aug 28, 2014 at 03:36:39PM +0530, Kiran Kumar Raparthy wrote:
> From: Todd Poynor 
> 
> usb: otg: Temporarily hold wakeupsource on charger connect and disconnect
> events
> 
> Allow other parts of the system to react to the charger connect/disconnect
> event without allowing the system to suspend before the other parts can 
> process
> the event. This wakeup_source times out after 2 seconds; if nobody else holds 
> a
> wakeup_source by that time then the device can sleep.
> 
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: Android Kernel Team 
> Cc: John Stultz 
> Signed-off-by: Todd Poynor 
> [kiran: Added context to commit message]
> Signed-off-by: Kiran Raparthy 
> ---
>  drivers/usb/phy/otg-wakeupsource.c | 10 +++---
>  include/linux/usb/otg.h|  2 ++
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/phy/otg-wakeupsource.c 
> b/drivers/usb/phy/otg-wakeupsource.c
> index 7c838d1..9f3c5c1 100644
> --- a/drivers/usb/phy/otg-wakeupsource.c
> +++ b/drivers/usb/phy/otg-wakeupsource.c
> @@ -34,8 +34,11 @@ struct otgws_lock {
>   struct wakeup_source wsource;
>  };
>  
> -/* VBUS present lock */
> -
> +/*
> + * VBUS present lock.  Also used as a timed lock on charger
> + * connect/disconnect and USB host disconnect, to allow the system
> + * to react to the change in power.
> + */
>  static struct otgws_lock vbus_lock;
>  
>  static void otgws_handle_event(unsigned long event)
> @@ -59,7 +62,8 @@ static void otgws_handle_event(unsigned long event)
>   case USB_EVENT_NONE:
>   case USB_EVENT_ID:
>   case USB_EVENT_CHARGER:
> - __pm_relax(_lock.wsource);
> + __pm_wakeup_event(_lock.wsource,
> + msecs_to_jiffies(TEMPORARY_HOLD_TIME));

indentation here is wrong. Also, I have gotten three patches from you
with very similar contents and subject. Please make sure to read
Documentation/SubmittingPatches, Documentation/CodingStyle and
Documentation/SubmitChecklist

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 0/2] x86: Speed up ioremap operations

[Andrew Morton]

On Fri, 29 Aug 2014 13:44:31 -0700 Mike Travis  wrote:

> 
> 
> On 8/29/2014 1:16 PM, Andrew Morton wrote:
> > On Fri, 29 Aug 2014 14:53:28 -0500 Mike Travis  wrote:
> > 
> >>
> >> We have a large university system in the UK that is experiencing
> >> very long delays modprobing the driver for a specific I/O device.
> >> The delay is from 8-10 minutes per device and there are 31 devices
> >> in the system.  This 4 to 5 hour delay in starting up those I/O
> >> devices is very much a burden on the customer.
> >>
> >> There are two causes for requiring a restart/reload of the drivers.
> >> First is periodic preventive maintenance (PM) and the second is if
> >> any of the devices experience a fatal error.  Both of these trigger
> >> this excessively long delay in bringing the system back up to full
> >> capability.
> >>
> >> The problem was tracked down to a very slow IOREMAP operation and
> >> the excessively long ioresource lookup to insure that the user is
> >> not attempting to ioremap RAM.  These patches provide a speed up
> >> to that function.
> >>
> > 
> > Really would prefer to have some quantitative testing results in here,
> > as that is the entire point of the patchset.  And it leaves the reader
> > wondering "how much of this severe problem remains?".
> 
> Okay, I have some results from testing.  The modprobe time appears to
> be affected quite a bit by previous activity on the ioresource list,
> which I suspect is due to cache preloading.  While the overall
> improvement is impacted by other overhead of starting the devices,
> this drastically improves the modprobe time.
> 
> Also our system is considerably smaller so the percentages gained
> will not be the same.  Best case improvement with the modprobe
> on our 20 device smallish system was from 'real5m51.913s' to
> 'real0m18.275s'.

Thanks, I slurped that into the changelog.

> > Also, the -stable backport is a big ask, isn't it?  It's arguably
> > notabug and the affected number of machines is small.
> > 
> 
> Ingo had suggested this.  We are definitely pushing it to our distro
> suppliers for our customers.  Whether it's a big deal for smaller
> systems is up in the air.  Note that the customer system has 31 devices
> on an SSI that includes a large number of other IB and SAS devices
> as well as a number of nodes which all which have discontiguous memory
> segments.  I'm envisioning an ioresource list that numbers at least
> several hundred entries.  While that's somewhat indicative of typical
> UV systems it is generally not that common otherwise.
> 
> So I guess the -stable is merely a suggestion, not a request.

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

Re: [PATCH resend] nosave: Consolidate __nosave_{begin,end} in

[Stephen Boyd]

On 08/29/14 13:22, Geert Uytterhoeven wrote:
> The different architectures used their own (and different) declarations:
>
> extern __visible const void __nosave_begin, __nosave_end;
> extern const void __nosave_begin, __nosave_end;
> extern long __nosave_begin, __nosave_end;
>
> Consolidate them using the first variant in .
>
> Signed-off-by: Geert Uytterhoeven 
> ---
> This has been sent before, as part of the series "[PATCH 00/17] 
> 
> related cleanups", almost one year ago (https://lkml.org/lkml/2013/11/12/510).
>
>  arch/mips/include/asm/suspend.h   | 7 ---
>  arch/mips/power/cpu.c | 2 +-
>  arch/powerpc/kernel/suspend.c | 4 +---
>  arch/s390/kernel/suspend.c| 6 +-
>  arch/sh/include/asm/sections.h| 1 -
>  arch/sparc/power/hibernate.c  | 4 +---
>  arch/unicore32/include/mach/pm.h  | 3 ---
>  arch/unicore32/kernel/hibernate.c | 1 +
>  arch/x86/power/hibernate_32.c | 4 +---
>  arch/x86/power/hibernate_64.c | 4 +---
>  include/asm-generic/sections.h| 4 
>  11 files changed, 11 insertions(+), 29 deletions(-)
>  delete mode 100644 arch/mips/include/asm/suspend.h
>

There's one in arch/arm/kernel/hibernate.c now. Can we update ARM too?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH] Staging: bcm: LeakyBucket: format kernel-docs

[Andrew Plummer]

Remove insignificant spaces before tabs in comments.

Signed-off-by: Andrew Plummer 
---
 drivers/staging/bcm/LeakyBucket.c | 81 ---
 1 file changed, 33 insertions(+), 48 deletions(-)

diff --git a/drivers/staging/bcm/LeakyBucket.c 
b/drivers/staging/bcm/LeakyBucket.c
index 8c4030d..d6b55f9 100644
--- a/drivers/staging/bcm/LeakyBucket.c
+++ b/drivers/staging/bcm/LeakyBucket.c
@@ -1,20 +1,16 @@
 /**
-*  LEAKYBUCKET.C
+*  LEAKYBUCKET.C
 *  This file contains the routines related to Leaky Bucket Algorithm.
 ***/
 #include "headers.h"
 
-/*
-* Function- UpdateTokenCount()
-*
-* Description - This function calculates the token count for each
-*  channel and updates the same in Adapter 
strucuture.
-*
-* Parameters  - Adapter: Pointer to the Adapter structure.
-*
-* Returns - None
-**/
-
+/**
+ * UpdateTokenCount() - Calculates the token count for each channel
+ * and updates the same in Adapter structure
+ * @Adapter:   Pointer to the Adapter structure.
+ *
+ * Return: None
+ */
 static VOID UpdateTokenCount(register struct bcm_mini_adapter *Adapter)
 {
ULONG liCurrentTime;
@@ -59,20 +55,16 @@ static VOID UpdateTokenCount(register struct 
bcm_mini_adapter *Adapter)
 }
 
 
-/*
-* Function- IsPacketAllowedForFlow()
-*
-* Description - This function checks whether the given packet from the
-*  specified queue can be allowed for transmission 
by
-*  checking the token count.
-*
-* Parameters  - Adapter  : Pointer to the Adpater structure.
-*- iQIndex   : The queue Identifier.
-*- ulPacketLength: Number of bytes to be 
transmitted.
-*
-* Returns - The number of bytes allowed for transmission.
-*
-***/
+/**
+ * IsPacketAllowedForFlow() - This function checks whether the given
+ * packet from the specified queue can be allowed for transmission by
+ * checking the token count.
+ * @Adapter:   Pointer to the Adpater structure.
+ * @iQIndex:   The queue Identifier.
+ * @ulPacketLength:Number of bytes to be transmitted.
+ *
+ * Returns: The number of bytes allowed for transmission.
+ */
 static ULONG GetSFTokenCount(struct bcm_mini_adapter *Adapter, struct 
bcm_packet_info *psSF)
 {
BCM_DEBUG_PRINT(Adapter, DBG_TYPE_TX, TOKEN_COUNTS, DBG_LVL_ALL,
@@ -256,18 +248,14 @@ static void send_control_packet(struct bcm_mini_adapter 
*ad,
}
 }
 
-/
-* Function- CheckAndSendPacketFromIndex()
-*
-* Description - This function dequeues the data/control packet from the
-*  specified queue for transmission.
-*
-* Parameters  - Adapter : Pointer to the driver control structure.
-*- iQIndex : The queue Identifier.
-*
-* Returns - None.
-*
-/
+/**
+ * CheckAndSendPacketFromIndex() - This function dequeues the
+ * data/control packet from the specified queue for transmission.
+ * @Adapter:   Pointer to the driver control structure.
+ * @iQIndex:   The queue Identifier.
+ *
+ * Returns: None.
+ */
 static VOID CheckAndSendPacketFromIndex(struct bcm_mini_adapter *Adapter,
struct bcm_packet_info *psSF)
 {
@@ -284,16 +272,13 @@ static VOID CheckAndSendPacketFromIndex(struct 
bcm_mini_adapter *Adapter,
 }
 
 
-/***
-* Function- transmit_packets()
-*
-* Description - This function transmits the packets from different
-*  queues, if free descriptors are available on 
target.
-*
-* Parameters  - Adapter:  Pointer to the Adapter structure.
-*
-* Returns - None.
-/
+/**
+ * transmit_packets() - This function transmits the packets from
+ * different queues, if free descriptors are available on target.
+ * @Adapter:   Pointer to the Adapter structure.
+ *
+ * Returns: None.
+ */
 VOID transmit_packets(struct bcm_mini_adapter *Adapter)
 {
UINT uiPrevTotalCount = 0;
-- 
1.9.1

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

Re: [RFC 1/2] USB: OTG: Hold wakeupsource when VBUS present

[Felipe Balbi]

Hi,

On Wed, Aug 27, 2014 at 02:58:30PM -0700, Todd Poynor wrote:
> On Fri, Aug 22, 2014 at 10:12 AM, Felipe Balbi  wrote:
> ...
> > you never explain why this is needed and you have also added some
> > information to commit log which shouldn't be here.
> 
> Android uses this to prevent suspend from interfering with USB
> peripheral traffic, notably adb.

ah, that's because Android freezes userspace right ?

> The wakeup source is held only when USB is connected and enumerated
> for a host session (I might be using wrong terminology here).  It may
> not be necessary on a platform that implements wakeup on incoming USB
> traffic, although it is likely adb and other protocols would need to
> hold wakeup sources at certain times.
> 
> ...
> >> +static struct otgws_lock vbus_lock;
> >
> > should be per-PHY
> 
> One of the reasons this was done as a separate driver and via
> notifiers was to keep the (original Android wakelock) logic out of the
> USB code.  If the general idea is something that finds favor with the
> USB and PM folks then perhaps adding a wakeup source per PHY in the
> PHY driver would be better.

it's best to do it per-PHY, but it doesn't have to be written into each
and every PHY driver, do it at the core and abstract that away from PHY
drivers.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH net v5 4/4] tg3: Fix tx_pending checks for tg3_tso_bug

[Benjamin Poirier]

In tg3_set_ringparam(), the tx_pending test to cover the cases where
tg3_tso_bug() is entered has two problems
1) the check is only done for certain hardware whereas the workaround
is now used more broadly. IOW, the check may not be performed when it
is needed.
2) the check is too optimistic.

For example, with a 5761 (SHORT_DMA_BUG), tg3_set_ringparam() skips over the
"tx_pending <= (MAX_SKB_FRAGS * 3)" check because TSO_BUG is false. Even if it
did do the check, with a full sized skb, frag_cnt_est = 135 but the check is
for <= MAX_SKB_FRAGS * 3 (= 17 * 3 = 51). So the check is insufficient. This
leads to the following situation: by setting, ex. tx_pending = 100, there can
be an skb that triggers tg3_tso_bug() and that is large enough to cause
tg3_tso_bug() to stop the queue even when it is empty. We then end up with a
netdev watchdog transmit timeout.

Given that 1) some of the conditions tested for in tg3_tx_frag_set() apply
regardless of the chipset flags and that 2) it is difficult to estimate ahead
of time the max possible number of frames that a large skb may be split into
by gso, we instead take the approach of adjusting dev->gso_max_segs according
to the requested tx_pending size.

This puts us in the exceptional situation that a single skb that triggers
tg3_tso_bug() may require the entire tx ring. Usually the tx queue is woken up
when at least a quarter of it is available (TG3_TX_WAKEUP_THRESH) but that
would be insufficient now. To avoid useless wakeups, the tx queue wake up
threshold is made dynamic. Likewise, usually the tx queue is stopped as soon
as an skb with max frags may overrun it. Since the skbs submitted from
tg3_tso_bug() use a controlled number of descriptors, the tx queue stop
threshold may be lowered.

Signed-off-by: Benjamin Poirier 
---

Changes v1->v2
* in tg3_set_ringparam(), reduce gso_max_segs further to budget 3 descriptors
  per gso seg instead of only 1 as in v1
* in tg3_tso_bug(), check that this estimation (3 desc/seg) holds, otherwise
  linearize some skbs as needed
* in tg3_start_xmit(), make the queue stop threshold a parameter, for the
  reason explained in the commit description

Changes v2->v3
* use tg3_maybe_stop_txq() instead of repeatedly open coding it
* add the requested tp->tx_dropped++ stat increase in tg3_tso_bug() if
  skb_linearize() fails and we must abort
* in the same code block, add an additional check to stop the queue with the
  default threshold. Otherwise, the netdev_err message at the start of
  __tg3_start_xmit() could be triggered when the next frame is transmitted.
  That is because the previous calls to __tg3_start_xmit() in tg3_tso_bug()
  may have been using a stop_thresh=segs_remaining that is < MAX_SKB_FRAGS +
  1.

Changes v3->v4
* in tg3_set_ringparam(), make sure that wakeup_thresh does not end up being
  >= tx_pending. Identified by Prashant.

Changes v4->v5
* in tg3_set_ringparam(), use TG3_TX_WAKEUP_THRESH() and tp->txq_cnt instead
  of tp->irq_max. Identified by Prashant.

I reproduced this bug using the same approach explained in patch 1.
The bug reproduces with tx_pending <= 135
---
 drivers/net/ethernet/broadcom/tg3.c | 69 +
 drivers/net/ethernet/broadcom/tg3.h |  1 +
 2 files changed, 56 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index f706a1e..43feb18 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -204,6 +204,10 @@ static inline void _tg3_flag_clear(enum TG3_FLAGS flag, 
unsigned long *bits)
 /* minimum number of free TX descriptors required to wake up TX process */
 #define TG3_TX_WAKEUP_THRESH(tnapi)max_t(u32, (tnapi)->tx_pending / 4, \
  MAX_SKB_FRAGS + 1)
+/* estimate a certain number of descriptors per gso segment */
+#define TG3_TX_DESC_PER_SEG(seg_nb)((seg_nb) * 3)
+#define TG3_TX_SEG_PER_DESC(desc_nb)   ((desc_nb) / 3)
+
 #define TG3_TX_BD_DMA_MAX_2K   2048
 #define TG3_TX_BD_DMA_MAX_4K   4096
 
@@ -6609,10 +6613,10 @@ static void tg3_tx(struct tg3_napi *tnapi)
smp_mb();
 
if (unlikely(netif_tx_queue_stopped(txq) &&
-(tg3_tx_avail(tnapi) > TG3_TX_WAKEUP_THRESH(tnapi {
+(tg3_tx_avail(tnapi) > tnapi->wakeup_thresh))) {
__netif_tx_lock(txq, smp_processor_id());
if (netif_tx_queue_stopped(txq) &&
-   (tg3_tx_avail(tnapi) > TG3_TX_WAKEUP_THRESH(tnapi)))
+   (tg3_tx_avail(tnapi) > tnapi->wakeup_thresh))
netif_tx_wake_queue(txq);
__netif_tx_unlock(txq);
}
@@ -7830,6 +7834,8 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi 
*tnapi,
 }
 
 static netdev_tx_t tg3_start_xmit(struct sk_buff *, struct net_device *);
+static netdev_tx_t __tg3_start_xmit(struct sk_buff *, struct net_device *,
+   

[PATCH net v5 3/4] tg3: Move tx queue stop logic to its own function

[Benjamin Poirier]

It is duplicated. Also, the first instance in tg3_start_xmit() is racy.
Consider:

tg3_start_xmit()
if budget <= ...
tg3_tx()
(free up the entire ring)
tx_cons =
smp_mb
if queue_stopped and tx_avail, NO
if !queue_stopped
stop queue
return NETDEV_TX_BUSY

... tx queue stopped forever

Signed-off-by: Benjamin Poirier 
---
Changes v2->v3
* new patch to avoid repeatedly open coding this block in the next patch.

Changes v3->v4
* added a comment to clarify the return value, as suggested
* replaced the BUG_ON with netdev_err(). No need to be so dramatic, this
  situation will trigger a netdev watchdog anyways.
---
 drivers/net/ethernet/broadcom/tg3.c | 75 -
 1 file changed, 40 insertions(+), 35 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 0cecd6d..f706a1e 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -7831,6 +7831,35 @@ static int tigon3_dma_hwbug_workaround(struct tg3_napi 
*tnapi,
 
 static netdev_tx_t tg3_start_xmit(struct sk_buff *, struct net_device *);
 
+/* Returns true if the queue has been stopped. Note that it may have been
+ * restarted since.
+ */
+static inline bool tg3_maybe_stop_txq(struct tg3_napi *tnapi,
+ struct netdev_queue *txq,
+ u32 stop_thresh, u32 wakeup_thresh)
+{
+   bool stopped = false;
+
+   if (unlikely(tg3_tx_avail(tnapi) <= stop_thresh)) {
+   if (!netif_tx_queue_stopped(txq)) {
+   stopped = true;
+   netif_tx_stop_queue(txq);
+   if (wakeup_thresh >= tnapi->tx_pending)
+   netdev_err(tnapi->tp->dev,
+  "BUG! wakeup_thresh too large (%u >= 
%u)\n",
+  wakeup_thresh, tnapi->tx_pending);
+   }
+   /* netif_tx_stop_queue() must be done before checking tx index
+* in tg3_tx_avail(), because in tg3_tx(), we update tx index
+* before checking for netif_tx_queue_stopped().
+*/
+   smp_mb();
+   if (tg3_tx_avail(tnapi) > wakeup_thresh)
+   netif_tx_wake_queue(txq);
+   }
+   return stopped;
+}
+
 /* Use GSO to workaround all TSO packets that meet HW bug conditions
  * indicated in tg3_tx_frag_set()
  */
@@ -7841,20 +7870,9 @@ static int tg3_tso_bug(struct tg3 *tp, struct tg3_napi 
*tnapi,
u32 frag_cnt_est = skb_shinfo(skb)->gso_segs * 3;
 
/* Estimate the number of fragments in the worst case */
-   if (unlikely(tg3_tx_avail(tnapi) <= frag_cnt_est)) {
-   netif_tx_stop_queue(txq);
-
-   /* netif_tx_stop_queue() must be done before checking
-* checking tx index in tg3_tx_avail() below, because in
-* tg3_tx(), we update tx index before checking for
-* netif_tx_queue_stopped().
-*/
-   smp_mb();
-   if (tg3_tx_avail(tnapi) <= frag_cnt_est)
-   return NETDEV_TX_BUSY;
-
-   netif_tx_wake_queue(txq);
-   }
+   tg3_maybe_stop_txq(tnapi, txq, frag_cnt_est, frag_cnt_est);
+   if (netif_tx_queue_stopped(txq))
+   return NETDEV_TX_BUSY;
 
segs = skb_gso_segment(skb, tp->dev->features &
~(NETIF_F_TSO | NETIF_F_TSO6));
@@ -7902,16 +7920,13 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, 
struct net_device *dev)
 * interrupt.  Furthermore, IRQ processing runs lockless so we have
 * no IRQ context deadlocks to worry about either.  Rejoice!
 */
-   if (unlikely(budget <= (skb_shinfo(skb)->nr_frags + 1))) {
-   if (!netif_tx_queue_stopped(txq)) {
-   netif_tx_stop_queue(txq);
-
-   /* This is a hard error, log it. */
-   netdev_err(dev,
-  "BUG! Tx Ring full when queue awake!\n");
-   }
-   return NETDEV_TX_BUSY;
+   if (tg3_maybe_stop_txq(tnapi, txq, skb_shinfo(skb)->nr_frags + 1,
+  TG3_TX_WAKEUP_THRESH(tnapi))) {
+   /* This is a hard error, log it. */
+   netdev_err(dev, "BUG! Tx Ring full when queue awake!\n");
}
+   if (netif_tx_queue_stopped(txq))
+   return NETDEV_TX_BUSY;
 
entry = tnapi->tx_prod;
base_flags = 0;
@@ -8087,18 +8102,8 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, 
struct net_device *dev)

[PATCH net v5 2/4] tg3: Fix tx_pending check for MAX_SKB_FRAGS

[Benjamin Poirier]

The rest of the driver assumes at least one free descriptor in the tx ring.
Therefore, since an skb with max frags takes up (MAX_SKB_FRAGS + 1)
descriptors, tx_pending must be > (MAX_SKB_FRAGS + 1).

Signed-off-by: Benjamin Poirier 
---

Changes v1->v2
Moved ahead in the series from 3/3 to 2/3, no functionnal change

I reproduced this bug using the same approach explained in patch 1.
The bug reproduces with tx_pending = 18
---
 drivers/net/ethernet/broadcom/tg3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index b11c0fd..0cecd6d 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -12319,7 +12319,7 @@ static int tg3_set_ringparam(struct net_device *dev, 
struct ethtool_ringparam *e
if ((ering->rx_pending > tp->rx_std_ring_mask) ||
(ering->rx_jumbo_pending > tp->rx_jmb_ring_mask) ||
(ering->tx_pending > TG3_TX_RING_SIZE - 1) ||
-   (ering->tx_pending <= MAX_SKB_FRAGS) ||
+   (ering->tx_pending <= MAX_SKB_FRAGS + 1) ||
(tg3_flag(tp, TSO_BUG) &&
 (ering->tx_pending <= (MAX_SKB_FRAGS * 3
return -EINVAL;
-- 
1.8.4.5

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

[PATCH net v5 1/4] tg3: Limit minimum tx queue wakeup threshold

[Benjamin Poirier]

tx_pending may be set by the user (via ethtool -G) to a low enough value that
TG3_TX_WAKEUP_THRESH becomes smaller than MAX_SKB_FRAGS + 1. This may cause
the tx queue to be waked when there are in fact not enough descriptors to
handle an skb with max frags. This in turn causes tg3_start_xmit() to return
NETDEV_TX_BUSY and print error messages. Fix the problem by putting a limit to
how low TG3_TX_WAKEUP_THRESH can go.

Signed-off-by: Benjamin Poirier 
---

I noticed the problem in a 3.0 kernel when setting `ethtool eth0 -G tx 50` and
running a netperf TCP_STREAM test. The console fills up with
[10597.596155] tg3 :06:00.0: eth0: BUG! Tx Ring full when queue awake!
The problem in tg3 remains in current kernels though it does not reproduce as
easily since "5640f76 net: use a per task frag allocator (v3.7-rc1)". I
reproduced on current kernels by using the fail_page_alloc fault injection
mechanism to force the creation of skbs with many order-0 frags. Note that the
following script may also trigger another bug (NETDEV WATCHDOG), which is
fixed in the next patch.

$ cat /tmp/doit.sh

F="/sys/kernel/debug/fail_page_alloc"

echo -1 > "$F/times"
echo 0 > "$F/verbose"
echo 0 > "$F/ignore-gfp-wait"
echo 1 > "$F/task-filter"
echo 100 > "$F/probability"

netperf -H 192.168.9.30 -l100 -t omni -- -d send &

n=$!

sleep 0.3
echo 1 > "/proc/$n/make-it-fail"
sleep 10

kill "$n"
---
 drivers/net/ethernet/broadcom/tg3.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/tg3.c 
b/drivers/net/ethernet/broadcom/tg3.c
index 3ac5d23..b11c0fd 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -202,7 +202,8 @@ static inline void _tg3_flag_clear(enum TG3_FLAGS flag, 
unsigned long *bits)
 #endif
 
 /* minimum number of free TX descriptors required to wake up TX process */
-#define TG3_TX_WAKEUP_THRESH(tnapi)((tnapi)->tx_pending / 4)
+#define TG3_TX_WAKEUP_THRESH(tnapi)max_t(u32, (tnapi)->tx_pending / 4, \
+ MAX_SKB_FRAGS + 1)
 #define TG3_TX_BD_DMA_MAX_2K   2048
 #define TG3_TX_BD_DMA_MAX_4K   4096
 
-- 
1.8.4.5

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

Re: [PATCH 0/2] x86: Speed up ioremap operations

[Mike Travis]

On 8/29/2014 1:16 PM, Andrew Morton wrote:
> On Fri, 29 Aug 2014 14:53:28 -0500 Mike Travis  wrote:
> 
>>
>> We have a large university system in the UK that is experiencing
>> very long delays modprobing the driver for a specific I/O device.
>> The delay is from 8-10 minutes per device and there are 31 devices
>> in the system.  This 4 to 5 hour delay in starting up those I/O
>> devices is very much a burden on the customer.
>>
>> There are two causes for requiring a restart/reload of the drivers.
>> First is periodic preventive maintenance (PM) and the second is if
>> any of the devices experience a fatal error.  Both of these trigger
>> this excessively long delay in bringing the system back up to full
>> capability.
>>
>> The problem was tracked down to a very slow IOREMAP operation and
>> the excessively long ioresource lookup to insure that the user is
>> not attempting to ioremap RAM.  These patches provide a speed up
>> to that function.
>>
> 
> Really would prefer to have some quantitative testing results in here,
> as that is the entire point of the patchset.  And it leaves the reader
> wondering "how much of this severe problem remains?".

Okay, I have some results from testing.  The modprobe time appears to
be affected quite a bit by previous activity on the ioresource list,
which I suspect is due to cache preloading.  While the overall
improvement is impacted by other overhead of starting the devices,
this drastically improves the modprobe time.

Also our system is considerably smaller so the percentages gained
will not be the same.  Best case improvement with the modprobe
on our 20 device smallish system was from 'real5m51.913s' to
'real0m18.275s'.

> Also, the -stable backport is a big ask, isn't it?  It's arguably
> notabug and the affected number of machines is small.
> 

Ingo had suggested this.  We are definitely pushing it to our distro
suppliers for our customers.  Whether it's a big deal for smaller
systems is up in the air.  Note that the customer system has 31 devices
on an SSI that includes a large number of other IB and SAS devices
as well as a number of nodes which all which have discontiguous memory
segments.  I'm envisioning an ioresource list that numbers at least
several hundred entries.  While that's somewhat indicative of typical
UV systems it is generally not that common otherwise.

So I guess the -stable is merely a suggestion, not a request.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/5] USB:gadget: Fix a warning while loading g_mass_storage

[Felipe Balbi]

Hi,

On Wed, Aug 27, 2014 at 10:58:49PM +0200, Michal Nazarewicz wrote:
> From: Yang Wei 
> 
> While loading g_mass_storage module, the following warning
> is triggered.
> 
> WARNING: at drivers/usb/gadget/composite.c:
> usb_composite_setup_continue: Unexpected call
> Modules linked in: fat vfat minix nls_cp437 nls_iso8859_1 g_mass_storage
> [<800179cc>] (unwind_backtrace+0x0/0x104) from [<80619608>] 
> (dump_stack+0x20/0x24)
> [<80619608>] (dump_stack+0x20/0x24) from [<80025100>] 
> (warn_slowpath_common+0x64/0x74)
> [<80025100>] (warn_slowpath_common+0x64/0x74) from [<800251cc>] 
> (warn_slowpath_fmt+0x40/0x48)
> [<800251cc>] (warn_slowpath_fmt+0x40/0x48) from [<7f047774>] 
> (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage])
> [<7f047774>] (usb_composite_setup_continue+0xb4/0xbc [g_mass_storage]) from 
> [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage])
> [<7f047ad4>] (handle_exception+0x358/0x3e4 [g_mass_storage]) from 
> [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage])
> [<7f048080>] (fsg_main_thread+0x520/0x157c [g_mass_storage]) from 
> [<8004bc90>] (kthread+0x98/0x9c)
> [<8004bc90>] (kthread+0x98/0x9c) from [<8000faec>] 
> (kernel_thread_exit+0x0/0x8)
> 
> The root cause is that the existing code fails to take into
> account the possibility that common->new_fsg can change while
> do_set_interface() is running, so the value of common->new_fsg
> that gets tested after do_set_interface returns needs to be
> the same as the value used by do_set_interface.
> 
> Signed-off-by: Yang Wei 
> Signed-off-by: Michal Nazarewicz 
> Acked-by: Alan Stern 

looks like this is the only fix in this thread. Please refrain from
sending new code and bugfixes on the same thread, specially not as the
last message in the thread.

I'll add this one to my testing/fixes

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/1] usb: gadget: Remove use of PWD in Makefiles

[Felipe Balbi]

On Thu, Aug 28, 2014 at 01:30:46AM -0400, Shea Levy wrote:
> Using PWD breaks out-of-tree builds in certain circumstances [1], and
> other kernel Makefiles use relative paths just fine.
> 
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=83251
> 
> Signed-off-by: Shea Levy 

There is already another version for this patch which is in my
testing/fixes branch

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/4] tile: Remove tile-specific _sinitdata and _einitdata

[Chris Metcalf]

On 8/29/2014 4:18 PM, Geert Uytterhoeven wrote:

Use standard __init_begin and __init_end instead.

Signed-off-by: Geert Uytterhoeven
Acked-by: Chris Metcalf
---
  arch/tile/include/asm/sections.h |  3 ---
  arch/tile/kernel/vmlinux.lds.S   |  2 --
  arch/tile/mm/init.c  | 10 +-
  3 files changed, 5 insertions(+), 10 deletions(-)


This is still in the tile tree; I missed the merge window for 3.17
since I was lazing around on the beach, but I'll push it to Linus
for 3.18.

--
Chris Metcalf, Tilera Corp.
http://www.tilera.com

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

Re: 3.10.y regression caused by: lockd: ensure we tear down any live sockets when socket creation fails during lockd_up

[J. Bruce Fields]

On Mon, Jul 07, 2014 at 03:27:21PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jun 20, 2014 at 03:14:03PM +0400, Nikita Yushchenko wrote:
> > With current 3.10.y, if kernel is booted with init=/bin/sh and then nfs 
> > mount
> > is attempted (without portmap or rpcbind running) using busybox mount, 
> > following
> > OOPS happen:
> > 
> > # mount -t nfs 10.30.130.21:/opt /mnt
> > svc: failed to register lockdv1 RPC service (errno 111).
> > lockd_up: makesock failed, error=-111
> > Unable to handle kernel paging request for data at address 0x0030
> > Faulting instruction address: 0xc055e65c
> > Oops: Kernel access of bad area, sig: 11 [#1]
> > MPC85xx CDS
> > Modules linked in:
> > CPU: 0 PID: 1338 Comm: mount Not tainted 3.10.44.cge #117
> > task: cf29cea0 ti: cf35c000 task.ti: cf35c000
> > NIP: c055e65c LR: c0566490 CTR: c055e648
> > REGS: cf35dad0 TRAP: 0300   Not tainted  (3.10.44.cge)
> > MSR: 00029000   CR: 22442488  XER: 2000
> > DEAR: 0030, ESR: 
> > 
> > GPR00: c05606f4 cf35db80 cf29cea0 cf0ded80 cf0dedb8 0001 1dec3086 
> >  
> > GPR08:  c07b1640 0007 1dec3086 22442482 100b9758  
> > 10090ae8 
> > GPR16:  000186a5   100c3018 bfa46edc 100b 
> > bfa46ef0 
> > GPR24: cf386ae0 c07834f0  c0565f88 0001 cf0dedb8  
> > cf0ded80 
> > NIP [c055e65c] call_start+0x14/0x34
> > LR [c0566490] __rpc_execute+0x70/0x250
> > Call Trace:
> > [cf35db80] [0080] 0x80 (unreliable)
> > [cf35dbb0] [c05606f4] rpc_run_task+0x9c/0xc4
> > [cf35dbc0] [c0560840] rpc_call_sync+0x50/0xb8
> > [cf35dbf0] [c056ee90] rpcb_register_call+0x54/0x84
> > [cf35dc10] [c056f24c] rpcb_register+0xf8/0x10c
> > [cf35dc70] [c0569e18] svc_unregister.isra.23+0x100/0x108
> > [cf35dc90] [c0569e38] svc_rpcb_cleanup+0x18/0x30
> > [cf35dca0] [c0198c5c] lockd_up+0x1dc/0x2e0
> > [cf35dcd0] [c0195348] nlmclnt_init+0x2c/0xc8
> > [cf35dcf0] [c015bb5c] nfs_start_lockd+0x98/0xec
> > [cf35dd20] [c015ce6c] nfs_create_server+0x1e8/0x3f4
> > [cf35dd90] [c0171590] nfs3_create_server+0x10/0x44
> > [cf35dda0] [c016528c] nfs_try_mount+0x158/0x1e4
> > [cf35de20] [c01670d0] nfs_fs_mount+0x434/0x8c8
> > [cf35de70] [c00cd3bc] mount_fs+0x20/0xbc
> > [cf35de90] [c00e4f88] vfs_kern_mount+0x50/0x104
> > [cf35dec0] [c00e6e0c] do_mount+0x1d0/0x8e0
> > [cf35df10] [c00e75ac] SyS_mount+0x90/0xd0
> > [cf35df40] [c000ccf4] ret_from_syscall+0x0/0x3c
> > --- Exception: c01 at 0xff2acc4
> > LR = 0x10048ab8
> > Instruction dump:
> > 3d20c056 3929e648 91230028 3861 4e800020 3860 4e800020 81230014 
> > 8103000c 81490014 394a0001 91490014 <81280030> 81490018 394a0001 91490018 
> > ---[ end trace 033b5b4715cb5452 ]---
> > 
> > 
> > This does not happen if
> > 
> > commit 72a6e594497032bd911bd187a88fae4b4473abb3
> > Author: Jeff Layton 
> > Date:   Tue Mar 25 11:55:26 2014 -0700
> > 
> > lockd: ensure we tear down any live sockets when socket creation fails 
> > during lockd_up
> > 
> > commit 679b033df48422191c4cac52b610d9980e019f9b upstream.
> > 
> > is reverted:
> > 
> > # mount -t nfs 10.30.130.21:/opt /mnt
> > svc: failed to register lockdv1 RPC service (errno 111).
> > lockd_up: makesock failed, error=-111
> > mount: mounting 10.30.130.21:/opt on /mnt failed: Connection refused
> > #
> > 
> > 
> > Physical reason of the OOPS is that:
> > 
> > - addition of svc_shutdown_net() call to error path of make_socks() causes
> > double call of svc_rpcb_cleanup():
> >   - first call is from within svc_shutdown_net(), because serv->sv_shutdown
> > points to svc_rpcb_cleanup() at this time,
> >   - immediately followed by second call from lockd_up_net()'s error path
> > 
> > - when second svc_rpcb_cleanup() is executed, then at
> >   svc_unregister() -> __svc_unregister() -> rpcb_register() -> 
> > rpcb_register_call()
> > call path, rpcb_register_call() is called with clnt=NULL.
> 
> So, Jeff, what should I do here?  Drop this patch from 3.10?  Add
> something else to fix it up?  Something else entirely?

Sorry this got ignored.  Adding more useful addressess

So looks like the new svc_shutdown_net made lockd_up_net's cleanup
redundant, and just removing it might do the job?

--b.

diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index 673668a9eec1..685e953c5103 100644
--- a/fs/lockd/svc.c
+++ b/fs/lockd/svc.c
@@ -253,13 +253,11 @@ static int lockd_up_net(struct svc_serv *serv, struct net 
*net)
 
error = make_socks(serv, net);
if (error < 0)
-   goto err_socks;
+   goto err_bind;
set_grace_period(net);
dprintk("lockd_up_net: per-net data created; net=%p\n", net);
return 0;
 
-err_socks:
-   svc_rpcb_cleanup(serv, net);
 err_bind:
ln->nlmsvc_users--;
return error;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  

[PATCH resend] nosave: Consolidate __nosave_{begin,end} in

[Geert Uytterhoeven]

The different architectures used their own (and different) declarations:

extern __visible const void __nosave_begin, __nosave_end;
extern const void __nosave_begin, __nosave_end;
extern long __nosave_begin, __nosave_end;

Consolidate them using the first variant in .

Signed-off-by: Geert Uytterhoeven 
---
This has been sent before, as part of the series "[PATCH 00/17] 
related cleanups", almost one year ago (https://lkml.org/lkml/2013/11/12/510).

 arch/mips/include/asm/suspend.h   | 7 ---
 arch/mips/power/cpu.c | 2 +-
 arch/powerpc/kernel/suspend.c | 4 +---
 arch/s390/kernel/suspend.c| 6 +-
 arch/sh/include/asm/sections.h| 1 -
 arch/sparc/power/hibernate.c  | 4 +---
 arch/unicore32/include/mach/pm.h  | 3 ---
 arch/unicore32/kernel/hibernate.c | 1 +
 arch/x86/power/hibernate_32.c | 4 +---
 arch/x86/power/hibernate_64.c | 4 +---
 include/asm-generic/sections.h| 4 
 11 files changed, 11 insertions(+), 29 deletions(-)
 delete mode 100644 arch/mips/include/asm/suspend.h

diff --git a/arch/mips/include/asm/suspend.h b/arch/mips/include/asm/suspend.h
deleted file mode 100644
index 3adac3b53d19..
--- a/arch/mips/include/asm/suspend.h
+++ /dev/null
@@ -1,7 +0,0 @@
-#ifndef __ASM_SUSPEND_H
-#define __ASM_SUSPEND_H
-
-/* References to section boundaries */
-extern const void __nosave_begin, __nosave_end;
-
-#endif /* __ASM_SUSPEND_H */
diff --git a/arch/mips/power/cpu.c b/arch/mips/power/cpu.c
index 521e5963df05..2129e67723ff 100644
--- a/arch/mips/power/cpu.c
+++ b/arch/mips/power/cpu.c
@@ -7,7 +7,7 @@
  * Author: Hu Hongbing 
  *Wu Zhangjin 
  */
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/powerpc/kernel/suspend.c b/arch/powerpc/kernel/suspend.c
index 0167d53da30c..a531154cc0f3 100644
--- a/arch/powerpc/kernel/suspend.c
+++ b/arch/powerpc/kernel/suspend.c
@@ -9,9 +9,7 @@
 
 #include 
 #include 
-
-/* References to section boundaries */
-extern const void __nosave_begin, __nosave_end;
+#include 
 
 /*
  * pfn_is_nosave - check if given pfn is in the 'nosave' section
diff --git a/arch/s390/kernel/suspend.c b/arch/s390/kernel/suspend.c
index a7a7537ce1e7..1c4c5accd220 100644
--- a/arch/s390/kernel/suspend.c
+++ b/arch/s390/kernel/suspend.c
@@ -13,14 +13,10 @@
 #include 
 #include 
 #include 
+#include 
 #include "entry.h"
 
 /*
- * References to section boundaries
- */
-extern const void __nosave_begin, __nosave_end;
-
-/*
  * The restore of the saved pages in an hibernation image will set
  * the change and referenced bits in the storage key for each page.
  * Overindication of the referenced bits after an hibernation cycle
diff --git a/arch/sh/include/asm/sections.h b/arch/sh/include/asm/sections.h
index 1b6199740e98..7a99e6af6372 100644
--- a/arch/sh/include/asm/sections.h
+++ b/arch/sh/include/asm/sections.h
@@ -3,7 +3,6 @@
 
 #include 
 
-extern long __nosave_begin, __nosave_end;
 extern long __machvec_start, __machvec_end;
 extern char __uncached_start, __uncached_end;
 extern char __start_eh_frame[], __stop_eh_frame[];
diff --git a/arch/sparc/power/hibernate.c b/arch/sparc/power/hibernate.c
index 42b0b8ce699a..17bd2e167e07 100644
--- a/arch/sparc/power/hibernate.c
+++ b/arch/sparc/power/hibernate.c
@@ -9,11 +9,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
-/* References to section boundaries */
-extern const void __nosave_begin, __nosave_end;
-
 struct saved_context saved_context;
 
 /*
diff --git a/arch/unicore32/include/mach/pm.h b/arch/unicore32/include/mach/pm.h
index 4dcd34ae194c..77b522694e74 100644
--- a/arch/unicore32/include/mach/pm.h
+++ b/arch/unicore32/include/mach/pm.h
@@ -36,8 +36,5 @@ extern int puv3_pm_enter(suspend_state_t state);
 /* Defined in hibernate_asm.S */
 extern int restore_image(pgd_t *resume_pg_dir, struct pbe *restore_pblist);
 
-/* References to section boundaries */
-extern const void __nosave_begin, __nosave_end;
-
 extern struct pbe *restore_pblist;
 #endif
diff --git a/arch/unicore32/kernel/hibernate.c 
b/arch/unicore32/kernel/hibernate.c
index d75ef8b6cb56..9969ec374abb 100644
--- a/arch/unicore32/kernel/hibernate.c
+++ b/arch/unicore32/kernel/hibernate.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "mach/pm.h"
diff --git a/arch/x86/power/hibernate_32.c b/arch/x86/power/hibernate_32.c
index 7d28c885d238..291226b952a9 100644
--- a/arch/x86/power/hibernate_32.c
+++ b/arch/x86/power/hibernate_32.c
@@ -13,13 +13,11 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Defined in hibernate_asm_32.S */
 extern int restore_image(void);
 
-/* References to section boundaries */
-extern const void __nosave_begin, __nosave_end;
-
 /* Pointer to the temporary resume page tables */
 pgd_t *resume_pg_dir;
 
diff --git a/arch/x86/power/hibernate_64.c b/arch/x86/power/hibernate_64.c
index 35e2bb6c0f37..009947d419a6 100644
--- a/arch/x86/power/hibernate_64.c
+++ b/arch/x86/power/hibernate_64.c
@@ -17,11 +17,9 @@
 #include 
 

[PATCH 0/4] More section-related cleanups

[Geert Uytterhoeven]

Hi Andrew,

Here's a resend of 4 more patches from the series "[PATCH 00/17]
 related cleanups" I sent almost one year ago
(https://lkml.org/lkml/2013/11/12/510).

3 of them received acks from their maintainers.

Thanks for applying!

Geert Uytterhoeven (4):
  frv: Remove unused declarations of __start___ex_table and
__stop___ex_table
  ia64: Remove duplicate declarations of __per_cpu_start[] and
__per_cpu_end[]
  tile: Remove tile-specific _sinitdata and _einitdata
  kernel/param: Consolidate __{start,stop}___param[] in


 arch/frv/mm/extable.c|  2 --
 arch/ia64/include/asm/sections.h |  2 +-
 arch/tile/include/asm/sections.h |  3 ---
 arch/tile/kernel/vmlinux.lds.S   |  2 --
 arch/tile/mm/init.c  | 10 +-
 include/linux/moduleparam.h  |  2 ++
 init/main.c  |  2 --
 kernel/params.c  |  7 +++
 8 files changed, 11 insertions(+), 19 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 2/4] ia64: Remove duplicate declarations of __per_cpu_start[] and __per_cpu_end[]

[Geert Uytterhoeven]

They're already provided by .

Signed-off-by: Geert Uytterhoeven 
---
 arch/ia64/include/asm/sections.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/ia64/include/asm/sections.h b/arch/ia64/include/asm/sections.h
index 1a873b36a4a1..2ab2003698ef 100644
--- a/arch/ia64/include/asm/sections.h
+++ b/arch/ia64/include/asm/sections.h
@@ -10,7 +10,7 @@
 #include 
 #include 
 
-extern char __per_cpu_start[], __per_cpu_end[], __phys_per_cpu_start[];
+extern char __phys_per_cpu_start[];
 #ifdef CONFIG_SMP
 extern char __cpu0_per_cpu[];
 #endif
-- 
1.9.1

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

[PATCH 1/4] frv: Remove unused declarations of __start___ex_table and __stop___ex_table

[Geert Uytterhoeven]

Signed-off-by: Geert Uytterhoeven 
Acked-by: David Howells 
---
 arch/frv/mm/extable.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/frv/mm/extable.c b/arch/frv/mm/extable.c
index 6aea124f574d..2fb9b3ab57b9 100644
--- a/arch/frv/mm/extable.c
+++ b/arch/frv/mm/extable.c
@@ -6,8 +6,6 @@
 #include 
 #include 
 
-extern const struct exception_table_entry __attribute__((aligned(8))) 
__start___ex_table[];
-extern const struct exception_table_entry __attribute__((aligned(8))) 
__stop___ex_table[];
 extern const void __memset_end, __memset_user_error_lr, 
__memset_user_error_handler;
 extern const void __memcpy_end, __memcpy_user_error_lr, 
__memcpy_user_error_handler;
 extern spinlock_t modlist_lock;
-- 
1.9.1

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