Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

[Viresh Kumar]

On 5 August 2014 11:59,   wrote:
> Looks like Srivatsa has gone off the grid too. I'm hoping at least one of
> you can do a review of my series. Come on guys, not everyone has to work
> on the same patch/issue. :-(

Srivatsa is currently going through some personal stuff. He is joining MIT
for his Masters/Phd and so would be moving to US soon :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 5/6] base: platform: name the device already during allocation

[Heikki Krogerus]

On Mon, Jul 14, 2014 at 07:55:43AM -0700, Greg Kroah-Hartman wrote:
> > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > > index 9e9227e..e856bc4 100644
> > > --- a/drivers/base/platform.c
> > > +++ b/drivers/base/platform.c
> > > @@ -177,11 +177,45 @@ struct platform_object {
> > >   */
> > >  void platform_device_put(struct platform_device *pdev)
> > >  {
> > > - if (pdev)
> > > - put_device(&pdev->dev);
> > > + if (!pdev)
> > > + return;
> > > +
> > > + if (pdev->id_auto) {
> > > + ida_simple_remove(&platform_devid_ida, pdev->id);
> > > + pdev->id = PLATFORM_DEVID_AUTO;
> > > + }
> > > +
> > > + put_device(&pdev->dev);
> > >  }
> > >  EXPORT_SYMBOL_GPL(platform_device_put);
> 
> Why would a single call to this function remove an id?  That seems
> really wrong, you should be able to call get and put on a device
> numerous times, only the "last" reference should cause the device to be
> cleaned up.
> 
> Shouldn't this be in the release function instead?

I'll fix this.

Thanks Greg.

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

[skannan]

Viresh Kumar wrote:
> On 5 August 2014 01:46, Saravana Kannan  wrote:
>> The problem is when between one thread trying to cat a governor's file
>> (say,
>> sampling_rate) vs the governor getting a POLICY_EXIT.
>
> I don't see two threads racing against each other here. Simply changing
> the governor from conservative->ondemand creates this.
>
> Or is it that the kernel is detecting two different orders of taking lock?
>
> But during governor change, isn't the sysfs lock taken first as we are
> storing a value to "scaling_governor"? So, isn't this a sysfs lock first
> in all cases?
>
> In short, I am still unclear about the *exact* problem here.
>
>> Could you please look at my policy free/remove patches? If you can do
>> that,
>> I can work on a fix for this. It might also be simpler to fix after my
>> patch
>> series (not sure, might be).
>
> I had an overall look of those on the day you posted them, but haven't
> commented yet as was going away..
>
> There is no way those can land in 3.17-rc1 atleast and so we still have
> some time to get them pushed..
>
> Anyway, they are my number two priority and the number one is this bug,
> which we have to fix in stable kernels as well. So, a dependency on your
> series wouldn't work..

Sigh... ok. I too will try to fix this one. I already have something in
mind for this.

Looks like Srivatsa has gone off the grid too. I'm hoping at least one of
you can do a review of my series. Come on guys, not everyone has to work
on the same patch/issue. :-(

-Saravana

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

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the char-misc tree got a conflict in
drivers/dma/Makefile between commit b45b262cefd5 ("dmaengine: add a
driver for AMBA AXI NBPF DMAC IP cores") from the slave-dma tree and
commit 95b4ecbf759a ("dma: MIC X100 DMA Driver") from the char-misc
tree.

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

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

diff --cc drivers/dma/Makefile
index f2b831a994cf,bd9e7fa928bd..
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@@ -47,5 -47,4 +47,6 @@@ obj-$(CONFIG_MOXART_DMA) += moxart-dma.
  obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
  obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
  obj-y += xilinx/
 +obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
 +obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
+ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o


signature.asc
Description: PGP signature

Re: [PATCH 1/2] dma: imx-sdma: use module_platform_driver for SDMA driver

[Vignesh Raman]

On Monday 04 August 2014 02:08 PM, Vinod Koul wrote:
> On Mon, Aug 04, 2014 at 02:11:01PM +0530, Vignesh Raman wrote:
>> On Thursday 31 July 2014 05:30 PM, Vinod Koul wrote:
>>> On Wed, Jul 30, 2014 at 06:41:14PM +0530, Vignesh Raman wrote:
 Currently there is no module_exit declared in SDMA driver, so that once
 sdma module is inserted, it's shown with permanent attribute by lsmod,
 and it can't be removed.
 Use module_platform_driver to register/unregister SDMA driver and modify
 SDMA's remove operation, to make SDMA driver possible to be removed.
>>> where is this bit below?
>>>
>> I'm not clear with your question. Are you asking about the unregister
>> SDMA driver function? It is done by dma_async_device_unregister.
> Driver already uses module_platform_driver, so I dont see what information
> the last two lines are trying to convey.
> 
> Patch needs to talk about what is done in current patch
> 
I missed some changes in Jiada's patch while merging to mainline kernel.
I will update and send the latest version.

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

[PATCH] drm/gma500: mdfld: Reuse video/mipi_display.h

[Thierry Reding]

From: Thierry Reding 

The GMA500 driver redefines many constants already found in the generic
header. Replace uses of the custom defines by the standard ones and get
rid of the duplicate defininitions.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c | 75 +++
 drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.h | 12 -
 2 files changed, 31 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
index 87885d8c06e8..6b43ae3ffd73 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c
@@ -25,6 +25,7 @@
  */
 
 #include 
+#include 
 
 #include "mdfld_dsi_output.h"
 #include "mdfld_dsi_pkg_sender.h"
@@ -32,20 +33,6 @@
 
 #define MDFLD_DSI_READ_MAX_COUNT   5000
 
-enum data_type {
-   DSI_DT_GENERIC_SHORT_WRITE_0= 0x03,
-   DSI_DT_GENERIC_SHORT_WRITE_1= 0x13,
-   DSI_DT_GENERIC_SHORT_WRITE_2= 0x23,
-   DSI_DT_GENERIC_READ_0   = 0x04,
-   DSI_DT_GENERIC_READ_1   = 0x14,
-   DSI_DT_GENERIC_READ_2   = 0x24,
-   DSI_DT_GENERIC_LONG_WRITE   = 0x29,
-   DSI_DT_DCS_SHORT_WRITE_0= 0x05,
-   DSI_DT_DCS_SHORT_WRITE_1= 0x15,
-   DSI_DT_DCS_READ = 0x06,
-   DSI_DT_DCS_LONG_WRITE   = 0x39,
-};
-
 enum {
MDFLD_DSI_PANEL_MODE_SLEEP = 0x1,
 };
@@ -321,9 +308,9 @@ static int send_pkg_prepare(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
u8 cmd;
 
switch (data_type) {
-   case DSI_DT_DCS_SHORT_WRITE_0:
-   case DSI_DT_DCS_SHORT_WRITE_1:
-   case DSI_DT_DCS_LONG_WRITE:
+   case MIPI_DSI_DCS_SHORT_WRITE:
+   case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+   case MIPI_DSI_DCS_LONG_WRITE:
cmd = *data;
break;
default:
@@ -334,12 +321,12 @@ static int send_pkg_prepare(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
sender->status = MDFLD_DSI_PKG_SENDER_BUSY;
 
/*wait for 120 milliseconds in case exit_sleep_mode just be sent*/
-   if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
+   if (unlikely(cmd == MIPI_DCS_ENTER_SLEEP_MODE)) {
/*TODO: replace it with msleep later*/
mdelay(120);
}
 
-   if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
+   if (unlikely(cmd == MIPI_DCS_EXIT_SLEEP_MODE)) {
/*TODO: replace it with msleep later*/
mdelay(120);
}
@@ -352,9 +339,9 @@ static int send_pkg_done(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
u8 cmd;
 
switch (data_type) {
-   case DSI_DT_DCS_SHORT_WRITE_0:
-   case DSI_DT_DCS_SHORT_WRITE_1:
-   case DSI_DT_DCS_LONG_WRITE:
+   case MIPI_DSI_DCS_SHORT_WRITE:
+   case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+   case MIPI_DSI_DCS_LONG_WRITE:
cmd = *data;
break;
default:
@@ -362,15 +349,15 @@ static int send_pkg_done(struct mdfld_dsi_pkg_sender 
*sender, u8 data_type,
}
 
/*update panel status*/
-   if (unlikely(cmd == DCS_ENTER_SLEEP_MODE)) {
+   if (unlikely(cmd == MIPI_DCS_ENTER_SLEEP_MODE)) {
sender->panel_mode |= MDFLD_DSI_PANEL_MODE_SLEEP;
/*TODO: replace it with msleep later*/
mdelay(120);
-   } else if (unlikely(cmd == DCS_EXIT_SLEEP_MODE)) {
+   } else if (unlikely(cmd == MIPI_DCS_EXIT_SLEEP_MODE)) {
sender->panel_mode &= ~MDFLD_DSI_PANEL_MODE_SLEEP;
/*TODO: replace it with msleep later*/
mdelay(120);
-   } else if (unlikely(cmd == DCS_SOFT_RESET)) {
+   } else if (unlikely(cmd == MIPI_DCS_SOFT_RESET)) {
/*TODO: replace it with msleep later*/
mdelay(5);
}
@@ -405,19 +392,19 @@ static int send_pkg(struct mdfld_dsi_pkg_sender *sender, 
u8 data_type,
}
 
switch (data_type) {
-   case DSI_DT_GENERIC_SHORT_WRITE_0:
-   case DSI_DT_GENERIC_SHORT_WRITE_1:
-   case DSI_DT_GENERIC_SHORT_WRITE_2:
-   case DSI_DT_GENERIC_READ_0:
-   case DSI_DT_GENERIC_READ_1:
-   case DSI_DT_GENERIC_READ_2:
-   case DSI_DT_DCS_SHORT_WRITE_0:
-   case DSI_DT_DCS_SHORT_WRITE_1:
-   case DSI_DT_DCS_READ:
+   case MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM:
+   case MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM:
+   case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
+   case MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM:
+   case MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM:
+   case MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM:
+   case MIPI_DSI_DCS_SHORT_WRITE:
+   case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+   case MIPI_DSI_DCS_READ:
ret = send_short_pkg(sender, data_type, data[0], data[1], hs);
break;
-   case DSI_DT_GENERIC_LONG_WRITE:
-   case DSI_DT_DCS_LONG_WRITE:
+   case

Re: [PATCH] cpufreq_opp.c: Fixed the __might_sleep by changing GFP_KERNEL to GFP_ATOMIC.

[Viresh Kumar]

On 5 August 2014 01:44, Anand Moon  wrote:
> Note: Generally, you should use GFP_ATOMIC in interrupt context
> or in process context where it is not allowed to sleep, and GFP_KERNEL 
> elsewhere.
>
> This changes fixes bellow bug on ARM imx6
>
> Signed-off-by: Anand Moon 

This should have come after the kernel dump.

> [7.331858]
> [7.69] ===
> [7.337633] [ INFO: suspicious RCU usage. ]
> [7.341834] 3.16.0-armv7-x2 #1 Not tainted
> [7.346506] ---
> [7.350709] include/linux/rcupdate.h:513 Illegal context switch in RCU 
> read-side critical section!
> [7.359735]
> [7.359735] other info that might help us debug this:
> [7.359735]
> [7.367932]
> [7.367932] rcu_scheduler_active = 1, debug_locks = 1
> [7.374477] 2 locks held by swapper/0/1:
> [7.378491]  #0:  (&dev->mutex){..}, at: [] 
> device_attach+0x28/0x9c
> [7.386212]  #1:  (rcu_read_lock){..}, at: [] 
> dev_pm_opp_init_cpufreq_table+0x0/0x23c
> [7.396284]
> [7.396284] stack backtrace:
> [7.400666] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-armv7-x2 #1
> [7.407668] [] (unwind_backtrace) from [] 
> (show_stack+0x20/0x24)
> [7.415473] [] (show_stack) from [] 
> (dump_stack+0x9c/0xbc)
> [7.422818] [] (dump_stack) from [] 
> (lockdep_rcu_suspicious+0xdc/0x110)
> [7.431298] [] (lockdep_rcu_suspicious) from [] 
> (__might_sleep+0x204/0x240)
> [7.440106] [] (__might_sleep) from [] 
> (__kmalloc+0x2a8/0x328)
> [7.447801] [] (__kmalloc) from [] 
> (dev_pm_opp_init_cpufreq_table+0xa4/0x23c)
> [7.456780] [] (dev_pm_opp_init_cpufreq_table) from [] 
> (imx6q_cpufreq_probe+0x160/0x750)
> [7.466734] [] (imx6q_cpufreq_probe) from [] 
> (platform_drv_probe+0x28/0x5c)
> [7.475456] [] (platform_drv_probe) from [] 
> (driver_probe_device+0x14c/0x39c)
> [7.484457] [] (driver_probe_device) from [] 
> (__device_attach+0x50/0x54)
> [7.492986] [] (__device_attach) from [] 
> (bus_for_each_drv+0x70/0xa4)
> [7.501291] [] (bus_for_each_drv) from [] 
> (device_attach+0x88/0x9c)
> [7.509388] [] (device_attach) from [] 
> (bus_probe_device+0x98/0xbc)
> [7.517600] [] (bus_probe_device) from [] 
> (device_add+0x4a8/0x5a0)
> [7.525679] [] (device_add) from [] 
> (platform_device_add+0xd4/0x26c)
> [7.533974] [] (platform_device_add) from [] 
> (platform_device_register+0x30/0x34)
> [7.543404] [] (platform_device_register) from [] 
> (imx6q_init_late+0x17c/0x18c)
> [7.552609] [] (imx6q_init_late) from [] 
> (init_machine_late+0x28/0x30)
> [7.560991] [] (init_machine_late) from [] 
> (do_one_initcall+0xec/0x224)
> [7.569538] [] (do_one_initcall) from [] 
> (kernel_init_freeable+0x208/0x2ac)
> [7.578448] [] (kernel_init_freeable) from [] 
> (kernel_init+0x1c/0xf8)
> [7.586764] [] (kernel_init) from [] 
> (ret_from_fork+0x14/0x20)
> ---
>  drivers/cpufreq/cpufreq_opp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
> index c0c6f4a..d5b5625 100644
> --- a/drivers/cpufreq/cpufreq_opp.c
> +++ b/drivers/cpufreq/cpufreq_opp.c
> @@ -60,7 +60,7 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
> goto out;
> }
>
> -   freq_table = kzalloc(sizeof(*freq_table) * (max_opps + 1), 
> GFP_KERNEL);
> +   freq_table = kzalloc(sizeof(*freq_table) * (max_opps + 1), 
> GFP_ATOMIC);
> if (!freq_table) {
> ret = -ENOMEM;
> goto out;

Please see this:

https://lkml.org/lkml/2014/7/16/815

@Rafael: Have you already applied patch from above link?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

[Viresh Kumar]

On 5 August 2014 01:46, Saravana Kannan  wrote:
> The problem is when between one thread trying to cat a governor's file (say,
> sampling_rate) vs the governor getting a POLICY_EXIT.

I don't see two threads racing against each other here. Simply changing
the governor from conservative->ondemand creates this.

Or is it that the kernel is detecting two different orders of taking lock?

But during governor change, isn't the sysfs lock taken first as we are
storing a value to "scaling_governor"? So, isn't this a sysfs lock first
in all cases?

In short, I am still unclear about the *exact* problem here.

> Could you please look at my policy free/remove patches? If you can do that,
> I can work on a fix for this. It might also be simpler to fix after my patch
> series (not sure, might be).

I had an overall look of those on the day you posted them, but haven't
commented yet as was going away..

There is no way those can land in 3.17-rc1 atleast and so we still have
some time to get them pushed..

Anyway, they are my number two priority and the number one is this bug,
which we have to fix in stable kernels as well. So, a dependency on your
series wouldn't work..

Let me see if I can get some solution to this problem first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/33] perf record: Allow the user to disable time stamps

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> From: Andi Kleen 
> 

This patch looks dangerous and misleading to me.

> Time stamps are always implicitely enabled for record currently.  The
> old --time/-T option is a nop.
> 
> Allow the user to disable timestamps by using --no-time
> 
> This can cause some minor misaccounting (by missing mmaps), but
> significantly lowers the size of perf.data

I'm not any big change in size:

 -rw--- 1 mingo mingo 384768 Aug  5 08:01 perf.data.timestamps
 -rw--- 1 mingo mingo 336952 Aug  5 08:00 perf.data.notimestamps

That's a ~14% reduction - it's certainly noticeable but not 
earth-shattering.

And what is called 'minor misaccounting' in the description is 
actually a potentially broken profile that people might rely on.

So the patch description misleads twice: by exaggerating the 
advantages and also by downplaying the disadvantages.

So either remove the --time option altogether, or fix its 
'misaccounting' so that the profile can be relied on.

Thanks,

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

Re: [PATCH v1] phy: extend APIs of the generic phy framework

[Kishon Vijay Abraham I]

Hi,

On Tuesday 05 August 2014 12:03 AM, yga...@codeaurora.org wrote:
>> Hi,
>>
>> On Thursday 31 July 2014 06:07 PM, Yaniv Gardi wrote:
>>> This change adds a few more APIs to the phy_ops structure:
>>> advertise_quirks - API for setting the phy quirks
>>
>> What are these phy quirks? An explanation on what you are are planning to
>> do
>> with these quirks might help.
> 
> A phy HW might have a specific behavior that should be exposed to the phy
> SW structure by calling this callback. This is the reason behind this
> callback. does it make more sense now ?

I'm more interested in the _specific_ behaviour you are talking about. Such
callbacks can be abused easily.
> 
> 
>>> suspend - API for the implementation of phy suspend sequence
>>> resume - API for the implementation of phy resume sequence
>>
>> Why not use the existing pm_runtime's suspend/resume callbacks?
>>
> Like we observed in our case, often there are need to be extra operations
> in the suspend/resume sequence. those specific operations include turning
> off/on specific clocks, disabling/enabling regulators etc. the specific
> implementation must give enough flexibility to add whatever needed to be
> done in suspend/resume sequences.

All these can be done in suspend and resume callbacks of pm_runtime.

Thanks
Kishon
> 
> 
> 
> 
>>>
>>> Change-Id: I44dd77f2603d20acb02ccb0cc0d20ade884f97c2
>> Remove this..
>>
>>> Signed-off-by: Yaniv Gardi 
>>> ---
>>>  Documentation/phy.txt   |  6 ++---
>>>  drivers/phy/phy-core.c  | 58
>>> +
>>>  include/linux/phy/phy.h | 33 
>>>  3 files changed, 94 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/Documentation/phy.txt b/Documentation/phy.txt
>>> index c6594af..f0dc28e 100644
>>> --- a/Documentation/phy.txt
>>> +++ b/Documentation/phy.txt
>>> @@ -63,9 +63,9 @@ struct phy *devm_phy_create(struct device *dev, struct
>>> device_node *node,
>>>  The PHY drivers can use one of the above 2 APIs to create the PHY by
>>> passing
>>>  the device pointer, phy ops and init_data.
>>>  phy_ops is a set of function pointers for performing PHY operations
>>> such as
>>> -init, exit, power_on and power_off. *init_data* is mandatory to get a
>>> reference
>>> -to the PHY in the case of non-dt boot. See section *Board File
>>> Initialization*
>>> -on how init_data should be used.
>>> +init, exit, power_on and power_off, , suspend, resume and
>>> advertise_quirks.
>>> +*init_data* is mandatory to get a reference to the PHY in the case of
>>> non-dt
>>> +boot. See section *Board File Initialization* on how init_data should
>>> be used.
>>>
>>>  Inorder to dereference the private data (in phy_ops), the phy provider
>>> driver
>>>  can use phy_set_drvdata() after creating the PHY and use
>>> phy_get_drvdata() in
>>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>>> index ff5eec5..77abaab 100644
>>> --- a/drivers/phy/phy-core.c
>>> +++ b/drivers/phy/phy-core.c
>>> @@ -293,6 +293,64 @@ int phy_power_off(struct phy *phy)
>>>  }
>>>  EXPORT_SYMBOL_GPL(phy_power_off);
>>>
>>> +int phy_suspend(struct phy *phy)
>>> +{
>>> +   int ret = 0;
>>> +
>>> +   if (!phy->ops->suspend)
>>> +   return -ENOTSUPP;
>>> +
>>> +   mutex_lock(&phy->mutex);
>>> +
>>> +   if (--phy->resume_count == 0) {
>>> +   ret =  phy->ops->suspend(phy);
>>> +   if (ret) {
>>> +   dev_err(&phy->dev, "phy suspend failed --> %d\n", ret);
>>> +   /* reverting the resume_count since suspend failed */
>>> +   phy->resume_count++;
>>> +   goto out;
>>> +   }
>>> +   }
>>> +out:
>>> +   mutex_unlock(&phy->mutex);
>>> +   return ret;
>>> +}
>>> +EXPORT_SYMBOL(phy_suspend);
>>> +
>>> +int phy_resume(struct phy *phy)
>>> +{
>>> +   int ret = 0;
>>> +
>>> +   if (!phy->ops->resume)
>>> +   return -ENOTSUPP;
>>> +
>>> +   mutex_lock(&phy->mutex);
>>> +
>>> +   if (phy->resume_count++ == 0) {
>>> +   ret =  phy->ops->resume(phy);
>>> +   if (ret) {
>>> +   dev_err(&phy->dev, "phy resume failed --> %d\n", ret);
>>> +   /* reverting the resume_count since resume failed */
>>> +   phy->resume_count--;
>>> +   goto out;
>>> +   }
>>> +   }
>>> +out:
>>> +   mutex_unlock(&phy->mutex);
>>> +   return ret;
>>> +}
>>> +EXPORT_SYMBOL(phy_resume);
>>> +
>>> +void phy_advertise_quirks(struct phy *phy)
>>> +{
>>> +   if (phy->ops->advertise_quirks) {
>>> +   mutex_lock(&phy->mutex);
>>> +   phy->ops->advertise_quirks(phy);
>>> +   mutex_unlock(&phy->mutex);
>>> +   }
>>> +}
>>> +EXPORT_SYMBOL(phy_advertise_quirks);
>>> +
>>>  /**
>>>   * _of_phy_get() - lookup and obtain a reference to a phy by phandle
>>>   * @np: device_node for which to get the phy
>>> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
>>> index 8cb6f81..5b96d65 100644
>>> --- a/include/linux/phy/phy.h
>>

Re: linux-next: build failures after merge of the drm tree

[YoungJun Cho]

Hi Stephen and Dave,

On 08/05/2014 12:09 PM, Stephen Rothwell wrote:

Hi Dave,

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

ERROR: "drm_sysfs_connector_remove" [drivers/gpu/drm/i2c/tda998x.ko] undefined!
ERROR: "drm_sysfs_connector_add" [drivers/gpu/drm/i2c/tda998x.ko] undefined!

Caused by commit c707c3619ca8 ("drm/i2c: tda998x: add component
support") interacting with commit 34ea3d386347 ("drm: add register and
unregister functions for connectors").  Maybe it should have been fixed
up in the merge commit 920f946428b7 ("Merge branch 'tda998x-devel' of
git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next")?

I reverted commit c707c3619ca8 for today.

But then the arm multi_v7_defconfig build produced these errors:

ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 2
make[2]: *** Waiting for unfinished jobs
ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [arch/arm/boot/dts/exynos5420-smdk5420.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

ERROR: Input tree has errors, aborting (use -f to force output)
ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

make[2]: *** [arch/arm/boot/dts/exynos5800-peach-pi.dtb] Error 2
ERROR: Input tree has errors, aborting (use -f to force output)

Caused by commit 5a8da524049c ("ARM: dts: exynos5420: add dsi node")
interacting with commit d51cad7df871 ("ARM: dts: remove display power
domain for exynos5420") from the arm-soc tree.



I missed the patch "ARM: dts: remove display power domain for 
exynos5420" in linux-samsung-soc mail thread.


In my test without power domain property, the exynos5420 dsi master 
driver works well.



I applied this merge fix patch:

From: Stephen Rothwell 
Date: Tue, 5 Aug 2014 13:03:01 +1000
Subject: [PATCH] ARM: dts: exynos5420: remove disp_pd

per comit d51cad7df871 ("ARM: dts: remove display power
domain for exynos5420").

Signed-off-by: Stephen Rothwell 
---
  arch/arm/boot/dts/exynos5420.dtsi | 1 -
  1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 95ec37dff3e8..bfe056d9148c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -525,7 +525,6 @@
compatible = "samsung,exynos5410-mipi-dsi";
reg = <0x1450 0x1>;
interrupts = <0 82 0>;
-   samsung,power-domain = <&disp_pd>;
phys = <&mipi_phy 1>;
phy-names = "dsim";
clocks = <&clock CLK_DSIM1>, <&clock CLK_SCLK_MIPI1>;



Tested-by: YoungJun Cho 

Thank you.
Best regards YJ


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] netlink: Convert netlink_lookup() to use RCU protected hash table

[David Miller]

From: Eric Dumazet 
Date: Tue, 05 Aug 2014 07:50:07 +0200

> [PATCH net-next] netlink: fix lockdep splats
> 
> With netlink_lookup() conversion to RCU, we need to use appropriate
> rcu dereference in netlink_seq_socket_idx() & netlink_seq_next()
> 
> Reported-by: Sasha Levin 
> Signed-off-by: Eric Dumazet 
> Fixes: e341694e3eb57fc ("netlink: Convert netlink_lookup() to use RCU 
> protected hash table")

Applied, thanks 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: pull request: wireless-next 2014-08-01

[David Miller]

From: Marcel Holtmann 
Date: Mon, 4 Aug 2014 22:39:47 -0700

> Hi Dave,
> 
> Please pull this last(?) batch of wireless change intended for the
> 3.17 stream...
 
 When I pull this I get tons of conflicts for:
 
 CONFLICT (content): Merge conflict in net/6lowpan/iphc.c
 
 I don't feel comfortable fixing these up, where are they coming
 from?
>>> 
>>> I was short on time yesterday, but now I checked up on this in detail. The 
>>> merge conflicts are actually simple to resolve. You can just rely on John's 
>>> tree to have the more recent net/6lowpan/ tree. I should have insisted on 
>>> merging net/6lowpan/ through bluetooth-next and wireless-next way earlier 
>>> to avoid conflicts.
>>> 
>>> In the future we will avoid this by ensuring that all goes via 
>>> bluetooth-next first. Sorry for this confusion. John mentioned these merge 
>>> conflicts in his footnote.
>>> 
>>> John, do you just want to resolve the merge conflicts and send Dave a new 
>>> pull request?
>> 
>> I'm happy to do that, if Dave wants.  But as you say, once the initial
>> shock of all those conflicts passes the resolution really is fairly
>> simple. :-)
> 
> do you want John to just do the merge conflict resolution? They are all 
> trivial.

I am going to try and do it myself, I just haven't gotten around to it.

Thanks for asking.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xhci: Merge and Update debugging for patches from 3.6 kernel tree

[Nick Krause]

On Tue, Aug 5, 2014 at 1:45 AM, Greg KH  wrote:
> On Tue, Aug 05, 2014 at 12:56:57AM -0400, Nicholas Krause wrote:
>> I am adding the fixes to the tree send for adding debugging to the kernel
>> tree from a patch sent in 2013 on the the 3.6 release. The patch adds
>> debugging over xhci capable debugging usb ports and needed to be updated
>> into the latest rc tree. The patch was first sent in this thread,
>> http://marc.info/?l=linux-usb&m=135948845511047.
>>
>> Signed-off-by: Nicholas Krause 
>
> If you send one more patch, I am going to have to ask vger.kernel.org to
> ban you from their servers.  You are actively bothering people and
> causing problems and wasting time.
>
> You have been told _numerous_ times to stop, yet you refuse to listen.
> You hold the record for getting kicked out of the Eudyptula challenge in
> a matter of hours, something no one else has ever had happen.  You
> ignore lots of very valid comments and suggestions, for no good reason.
> You flail about, making mistakes that are now starting to bother users,
> which is not acceptable at all.
>
> I will not respond to any more of your emails, and ask everyone else to
> now stop as well.
>
> good bye.
>
> *plonk*
>
> greg k-h

Greg,
You haven't even checked my patch, our you just going to assume it's wrong?
Regards Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] netlink: Convert netlink_lookup() to use RCU protected hash table

[Eric Dumazet]

On Mon, 2014-08-04 at 19:58 -0700, David Miller wrote:
> From: Sasha Levin 
> Date: Mon, 04 Aug 2014 22:10:19 -0400
> 
> > On 08/02/2014 05:47 AM, Thomas Graf wrote:
> >>  static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
> >> -  __acquires(nl_table_lock)
> >>  {
> >> -  read_lock(&nl_table_lock);
> >> +  rcu_read_lock();
> >>return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
> >>  }
> > 
> > I'm not sure how you expect this code to work. You're replacing a local lock
> > with a RCU critical section. Imagine you're doing spin_lock() and just going
> > back to userspace.
> > 
> > It's quite easy to trigger this issue:
> 
> I think he expected the end of the seq sequence to drop the RCU lock,
> via netlink_seq_stop().
> --

Yes, two places use rht_dereference() instead of rht_dereference_rcu()

[PATCH net-next] netlink: fix lockdep splats

With netlink_lookup() conversion to RCU, we need to use appropriate
rcu dereference in netlink_seq_socket_idx() & netlink_seq_next()

Reported-by: Sasha Levin 
Signed-off-by: Eric Dumazet 
Cc: 
Fixes: e341694e3eb57fc ("netlink: Convert netlink_lookup() to use RCU protected 
hash table")
---
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 0b89ca51a3af..479a344563d8 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -2899,7 +2899,7 @@ static struct sock *netlink_seq_socket_idx(struct 
seq_file *seq, loff_t pos)
 
for (i = 0; i < MAX_LINKS; i++) {
struct rhashtable *ht = &nl_table[i].hash;
-   const struct bucket_table *tbl = rht_dereference(ht->tbl, ht);
+   const struct bucket_table *tbl = rht_dereference_rcu(ht->tbl, 
ht);
 
for (j = 0; j < tbl->size; j++) {
rht_for_each_entry_rcu(nlk, tbl->buckets[j], node) {
@@ -2950,7 +2950,7 @@ static void *netlink_seq_next(struct seq_file *seq, void 
*v, loff_t *pos)
 
do {
struct rhashtable *ht = &nl_table[i].hash;
-   const struct bucket_table *tbl = rht_dereference(ht->tbl, ht);
+   const struct bucket_table *tbl = rht_dereference_rcu(ht->tbl, 
ht);
 
for (; j < tbl->size; j++) {
rht_for_each_entry_rcu(nlk, tbl->buckets[j], 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/

Re: [PATCH] xhci: Merge and Update debugging for patches from 3.6 kernel tree

[Greg KH]

On Tue, Aug 05, 2014 at 12:56:57AM -0400, Nicholas Krause wrote:
> I am adding the fixes to the tree send for adding debugging to the kernel
> tree from a patch sent in 2013 on the the 3.6 release. The patch adds
> debugging over xhci capable debugging usb ports and needed to be updated
> into the latest rc tree. The patch was first sent in this thread,
> http://marc.info/?l=linux-usb&m=135948845511047.
> 
> Signed-off-by: Nicholas Krause 

If you send one more patch, I am going to have to ask vger.kernel.org to
ban you from their servers.  You are actively bothering people and
causing problems and wasting time.

You have been told _numerous_ times to stop, yet you refuse to listen.
You hold the record for getting kicked out of the Eudyptula challenge in
a matter of hours, something no one else has ever had happen.  You
ignore lots of very valid comments and suggestions, for no good reason.
You flail about, making mistakes that are now starting to bother users,
which is not acceptable at all.

I will not respond to any more of your emails, and ask everyone else to
now stop as well.

good bye.

*plonk*

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] sched: Reduce contention in update_cfs_rq_blocked_load

[Yuyang Du]

On Tue, Aug 05, 2014 at 03:15:26AM +0800, Yuyang Du wrote:
> Hi Jason,
> 
> I am not sure whether you noticed my latest work: rewriting per entity load 
> average
> 
> http://article.gmane.org/gmane.linux.kernel/1760754
> http://article.gmane.org/gmane.linux.kernel/1760755
> http://article.gmane.org/gmane.linux.kernel/1760757
> http://article.gmane.org/gmane.linux.kernel/1760756
> 
> which simply does not track blocked load average at all.

Actually, it tracks blocked load, but along with runnable load, so no this extra
overhead.

> Are you interested in
> testing the patchset with the workload you have? The comparison can also help
> us understand the rewrite. Overall, per our tests, the overhead should be 
> less,
> and perf should be better.
> 
> 
> On Mon, Aug 04, 2014 at 01:28:38PM -0700, Jason Low wrote:
> > When running workloads on 2+ socket systems, based on perf profiles, the
> > update_cfs_rq_blocked_load function constantly shows up as taking up a
> > noticeable % of run time. This is especially apparent on an 8 socket
> > machine. For example, when running the AIM7 custom workload, we see:
> > 
> >4.18%reaim  [kernel.kallsyms][k] 
> > update_cfs_rq_blocked_load
> > 
> > Much of the contention is in __update_cfs_rq_tg_load_contrib when we
> > update the tg load contribution stats.  However, it turns out that in many
> > cases, they don't need to be updated and "tg_contrib" is 0.
> > 
> > This patch adds a check in __update_cfs_rq_tg_load_contrib to skip updating
> > tg load contribution stats when nothing needs to be updated. This reduces 
> > the
> > cacheline contention that would be unnecessary. In the above case, with the
> > patch, perf reports the total time spent in this function went down by more
> > than a factor of 3x:
> > 
> >1.18%reaim  [kernel.kallsyms][k] 
> > update_cfs_rq_blocked_load
> > 
> > Signed-off-by: Jason Low 
> > ---
> >  kernel/sched/fair.c |3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index bfa3c86..8d4cc72 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -2377,6 +2377,9 @@ static inline void 
> > __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
> > tg_contrib = cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg;
> > tg_contrib -= cfs_rq->tg_load_contrib;
> >  
> > +   if (!tg_contrib)
> > +   return;
> > +
> > if (force_update || abs(tg_contrib) > cfs_rq->tg_load_contrib / 8) {
> > atomic_long_add(tg_contrib, &tg->load_avg);
> > cfs_rq->tg_load_contrib += tg_contrib;
> > -- 
> > 1.7.1
> > 
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kbuild: trivial - fix the help doc of CONFIG_CC_OPTIMIZE_FOR_SIZE

[Masahiro Yamada]

Other than GCC, we have another choice, Clang for building the kernel
these days.  It seems better to say "compiler" rather than "gcc".

Signed-off-by: Masahiro Yamada 
---
 init/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 41066e4..7bc7c05 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1259,8 +1259,8 @@ endif
 config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size"
help
- Enabling this option will pass "-Os" instead of "-O2" to gcc
- resulting in a smaller kernel.
+ Enabling this option will pass "-Os" instead of "-O2" to
+ your compiler resulting in a smaller kernel.
 
  If unsure, say N.
 
-- 
1.9.1

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

Re: [PATCH] brcmfmac: prevent watchdog from interfering with scanning and connecting

[Fu, Zhonghui]

On 2014/8/5 4:12, Arend van Spriel wrote:
> On 08/04/14 18:52, Russell King - ARM Linux wrote:
>> On Tue, Aug 05, 2014 at 12:36:49AM +0800, Fu, Zhonghui wrote:
>>> Hi, Arend
>>>
>>> I investigated this issue, and its root cause is still that sdio
>>> controller can't receive interrupts from WiFi chip on sdio bus when
>>> sdio controller is in runtime suspend status. I am running 3.16-rc5
>>> linux kernel on ASUS T100TA tablet, and using sdhci-acpi driver.
>>
>> That's the root cause.  I fixed this with the Freescale i.MX SD driver
>> which is now able to report pending SDIO interrupts while runtime PM
>> suspended.
>>
>> Other host drivers probably need fixing too, or having runtime PM
>> disabled on them - if you can't receive SDIO interrupts while runtime
>> PM suspended, then entering runtime PM while you have a SDIO device
>> attached is a bug.
>>
>> This is something for the MMC people to deal with rather than Arend.
>
> Occasionally, the itch is there to fix mmc code, but this looks a bit tricky. 
> The fun starts in sdio.c:mmc_attach_sdio():
>
> /*
>  * Enable runtime PM only if supported by host+card+board
>  */
> if (host->caps & MMC_CAP_POWER_OFF_CARD) {
> /*
>  * Let runtime PM core know our card is active
>  */
> err = pm_runtime_set_active(&card->dev);
> if (err)
> goto remove;
>
> /*
>  * Enable runtime PM for this card
>  */
> pm_runtime_enable(&card->dev);
> }
>
> The comment above the if statement seems to be stating the right idea, but 
> the code only looks at the host controller capability flags.

Yes, this code section is not implemented as its comments.

Thanks,
Zhonghui

>
> Regards,
> Arend
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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 4/7] locking/rwsem: threshold limited spinning for active readers

[Davidlohr Bueso]

On Mon, 2014-08-04 at 22:30 -0700, Davidlohr Bueso wrote:
> On Mon, 2014-08-04 at 21:54 -0700, Davidlohr Bueso wrote:
> > >  #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
> > > +/*
> > > + * The owner field is set to RWSEM_READ_OWNED if the last owner(s) are
> > > + * readers. It is not reset until a writer takes over and set it to its
> > > + * task structure pointer or NULL when it frees the lock. So a value
> > > + * of RWSEM_READ_OWNED doesn't mean it currently has active readers.
> > > + */
> > > +#define RWSEM_READ_OWNED ((struct task_struct *)-1)
> > 
> > Looks rather weird...
> 
> Instead of populating owner when taking the reader lock, why not just
> leave it NULL. Then, we can differentiate between the owner being NULL
> either because it is taken by reader(s) or simply because it is not
> taken. So something like this:
> 
> static inline bool rwsem_owner_is_reader(struct rw_semaphore *sem)
> {
>   return !sem->owner && rwsem_is_locked(sem));
> }

Although we could race between both checks, specially when going into
slowpaths, too bad. Probably a read barrier before calling is_locked
too. Anyway, you see, things start getting funky.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pull request: wireless-next 2014-08-01

[Marcel Holtmann]

Hi Dave,

 Please pull this last(?) batch of wireless change intended for the
 3.17 stream...
>>> 
>>> When I pull this I get tons of conflicts for:
>>> 
>>> CONFLICT (content): Merge conflict in net/6lowpan/iphc.c
>>> 
>>> I don't feel comfortable fixing these up, where are they coming
>>> from?
>> 
>> I was short on time yesterday, but now I checked up on this in detail. The 
>> merge conflicts are actually simple to resolve. You can just rely on John's 
>> tree to have the more recent net/6lowpan/ tree. I should have insisted on 
>> merging net/6lowpan/ through bluetooth-next and wireless-next way earlier to 
>> avoid conflicts.
>> 
>> In the future we will avoid this by ensuring that all goes via 
>> bluetooth-next first. Sorry for this confusion. John mentioned these merge 
>> conflicts in his footnote.
>> 
>> John, do you just want to resolve the merge conflicts and send Dave a new 
>> pull request?
> 
> I'm happy to do that, if Dave wants.  But as you say, once the initial
> shock of all those conflicts passes the resolution really is fairly
> simple. :-)

do you want John to just do the merge conflict resolution? They are all trivial.

Regards

Marcel

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

[PATCH v1] MIPS: perf: Mark pmu interupt IRQF_NO_THREAD

[Wei.Yang]

From: Yang Wei 

In RT kernel, I ran into the following calltrace, so PMU interrupts cannot
be threaded

in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0
INFO: lockdep is turned off.
Call Trace:
[] dump_stack+0x1c/0x50
[] __might_sleep+0x13c/0x148
[] rt_spin_lock+0x3c/0xb0
[] __wake_up+0x3c/0x80
[] perf_event_wakeup+0x8c/0xf8
[] perf_pending_event+0x40/0x78
[] irq_work_run+0x74/0xc0
[] mipsxx_pmu_handle_shared_irq+0x110/0x228
[] mipsxx_pmu_handle_irq+0x14/0x30
[] handle_irq_event_percpu+0xbc/0x470
[] handle_percpu_irq+0x98/0xc8
[] generic_handle_irq+0x4c/0x68
[] do_IRQ+0x2c/0x48
[] plat_irq_dispatch+0x64/0xd0 


Signed-off-by: Yang Wei 
---
 arch/mips/kernel/perf_event_mipsxx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/kernel/perf_event_mipsxx.c 
b/arch/mips/kernel/perf_event_mipsxx.c
index 811084f..fd16763 100644
--- a/arch/mips/kernel/perf_event_mipsxx.c
+++ b/arch/mips/kernel/perf_event_mipsxx.c
@@ -550,7 +550,7 @@ static int mipspmu_get_irq(void)
if (mipspmu.irq >= 0) {
/* Request my own irq handler. */
err = request_irq(mipspmu.irq, mipsxx_pmu_handle_irq,
-   IRQF_PERCPU | IRQF_NOBALANCING,
+   IRQF_PERCPU | IRQF_NOBALANCING | IRQF_NO_THREAD,
"mips_perf_pmu", NULL);
if (err) {
pr_warning("Unable to request IRQ%d for MIPS "
-- 
1.7.9.5

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

Re: [PATCH] brcmfmac: prevent watchdog from interfering with scanning and connecting

[Fu, Zhonghui]

On 2014/8/5 0:52, Russell King - ARM Linux wrote:
> On Tue, Aug 05, 2014 at 12:36:49AM +0800, Fu, Zhonghui wrote:
>> Hi, Arend
>>
>> I investigated this issue, and its root cause is still that sdio
>> controller can't receive interrupts from WiFi chip on sdio bus when
>> sdio controller is in runtime suspend status. I am running 3.16-rc5
>> linux kernel on ASUS T100TA tablet, and using sdhci-acpi driver.
> That's the root cause.  I fixed this with the Freescale i.MX SD driver
> which is now able to report pending SDIO interrupts while runtime PM
> suspended.
>
> Other host drivers probably need fixing too, or having runtime PM
> disabled on them - if you can't receive SDIO interrupts while runtime
> PM suspended, then entering runtime PM while you have a SDIO device
> attached is a bug.
>
> This is something for the MMC people to deal with rather than Arend.
>
Yes, this should be sdhci-acpi bug, I will contact MMC people for this issue.


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

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 11:18 PM, Nick Krause  wrote:
> On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause  wrote:
>> On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
>>  wrote:
>>> On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
 On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
  wrote:
 >> From: Nick Krause [mailto:xerofo...@gmail.com]
>>>
>>> [snip]
>>>
 >> Paul ,
 >> My computer is rather old now as of Sandy Bridge days, so I probably
 >> can't test the patch
 >> on my own machine. However I will look at the code and see if I can
 >> forward port it
 >> against the usb git tree I have a current version of. In addition I
 >> would like the new xhci
 >> maintainers information in  order to send out a patch with the
 >> Maintainer for xhci updated.
 >
 > Sarah already told you who the new maintainer is, and then CCed him
 > on this thread. Hint: There is a file name 'MAINTAINERS' in the root
 > of the kernel tree, which tells you who the maintainers are for all of
 > the subsystems. Please read Documentation/SubmittingPatches, it has a
 > lot of information like this that you need to know.
 >
 > --
 > Paul
 >
 Thanks I will read this file and thanks for the information. I known
 where the file is I will
 add the information then.
>>>
>>> You may be looking at an older version of MAINTAINERS.  Mathias has only
>>> been marked as the maintainer since 3.15.  Which kernel version are you
>>> working on?
>>>
>>> Sarah Sharp
>>
> I am going to send out my work on the project you sent me I hope it's
> Ok if not feel free
> to tell me why. I did this against linus's tree but other then that it
> should work.
> Regards Nick

In addition,
I just sent it a few hours ago. Please let me known tomorrow if it's fine.
I am assuming based off my other work it's not.
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/7] locking/rwsem: threshold limited spinning for active readers

[Davidlohr Bueso]

On Mon, 2014-08-04 at 21:54 -0700, Davidlohr Bueso wrote:
> >  #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
> > +/*
> > + * The owner field is set to RWSEM_READ_OWNED if the last owner(s) are
> > + * readers. It is not reset until a writer takes over and set it to its
> > + * task structure pointer or NULL when it frees the lock. So a value
> > + * of RWSEM_READ_OWNED doesn't mean it currently has active readers.
> > + */
> > +#define RWSEM_READ_OWNED   ((struct task_struct *)-1)
> 
> Looks rather weird...

Instead of populating owner when taking the reader lock, why not just
leave it NULL. Then, we can differentiate between the owner being NULL
either because it is taken by reader(s) or simply because it is not
taken. So something like this:

static inline bool rwsem_owner_is_reader(struct rw_semaphore *sem)
{
return !sem->owner && rwsem_is_locked(sem));
}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Is lockref_get_not_zero() really correct in dget_parent()

[Al Viro]

On Mon, Aug 04, 2014 at 09:07:32PM -0700, Linus Torvalds wrote:

> So renaming it to "lockref_get_active()", and changing the "not zero"
> test to check for "positive" and change the rtype of "count" to be
> signed, all sound like good things to me.

Fine by me.  I can do that, unless somebody else beats me to that.

> But I don't actually think it's an active bug, it's just an "active
> horribly ugly and subtly working code". I guess in theory if you can
> get lots of CPU's triggering the race at the same time, the magic
> negative number could become zero and positive, but at that point I
> don't think we're really talking reality any more.
> 
> Can somebody pick holes in that? Does somebody want to send in the
> cleanup patch?

FWIW, dget_parent() has been a bloody annoyance - most of the callers used
to be racy and looking through the current set...  Take a look at e.g.
fs/btrfs/tree-log.c:check_parent_dirs_for_sync().  In the loop there we
do
if (!parent || !parent->d_inode || sb != parent->d_inode->i_sb)
break;

if (IS_ROOT(parent))
break;

parent = dget_parent(parent);
dput(old_parent);
old_parent = parent;
inode = parent->d_inode;
and it's so bogus it's not even funny.  What the hell is that code trying to
check?  And while we are at it, can we race with renames there?

>From my reading of that code, most of it ought to have been under
rcu_read_lock() and sod all that playing with refcounts.  Other
btrfs users are not much nicer (who says, for instance, that result of
check_parent_dirs_for_sync() will remain valid?)

ecryptfs lock_parent(): AFAICS, all callers could do ecryptfs_dentry_to_lower()
on dentry->d_parent instead of doing ecryptfs_dentry_to_lower(dentry) and
then doing dget_parent() - the covering layer dentries have ->d_parent
stabilized by ->i_mutex on said parents and we really, really don't want to
run into the case when tree topologies go out of sync.  I.e. we want to grab
->i_mutex on lower(parent), then check that it's equal to parent(lower) and,
if it's at all possible that some joker has played with rename(2) on underlying
layer mounted somewhere else, drop everything we'd taken and bugger off.

XFS xfs_filestream_get_parent() is clearly bogus -
parent = dget_parent(dentry);
if (!parent)
goto out_dput;
When does dget_parent() return NULL?

And that's just from a quick grep.  The point is, dget_parent() is not a nice
API - historically it's been abused more often than not and we keep playing
whack-a-mole with it.  Sigh...

Speaking of bogosities, apparently nobody has noticed that automagical
turning BSD process accounting off upon r/o remounts of the filesystem
hosting the log got broken several years ago.  Suppose we find an opened
log when remounting.  OK, it gets closed, which means filp_close(...).
Which means that actual closing that sucker will happen just before we
return to userland.  Return with -EBUSY, since the filesystem still has
a file opened for write when we get around to checking that...

I have kinda-sorta fixes for that (basically, restoring the situation we
used to have before delayed fput() and being damn careful about avoiding
deadlocks), but I would really love to just rip that idiocy out.  IOW,
just let it fail with -EBUSY in such cases, same as for any other write-opened
file on that fs.

That, BTW, is the most painful part of the acct series, so being able to
drop it would be very nice.  Comments?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: One bug of SDHCI driver

[Fu, Zhonghui]

Hi, Jaehoon

According to your comments, I created a new patch for this issue as follows:


Thanks,
Zhonghui


>From 6cee984e1d76ba0a3320430f8cf4318ab65fcf06 Mon Sep 17 00:00:00 2001
From: Fu Zhonghui 
Date: Tue, 5 Aug 2014 12:44:38 +0800
Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on sdio 
thread

781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
the use of our own custom threaded IRQ handler, but left in an
unconditional wake_up_process() on that handler at resume-time.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=80151

In addition, the check for MMC_CAP_SDIO_IRQ capability is added
before enable sdio IRQ.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Chris Ball 
Signed-off-by: Fu Zhonghui 
---
 drivers/mmc/core/sdio.c |   14 --
 drivers/mmc/core/sdio_irq.c |4 ++--
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index e636d9e..e04a540 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -992,8 +992,18 @@ static int mmc_sdio_resume(struct mmc_host *host)
}
}
 
-   if (!err && host->sdio_irqs)
-   wake_up_process(host->sdio_irq_thread);
+   if (!err && host->sdio_irqs) {
+   if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD)) {
+   wake_up_process(host->sdio_irq_thread);
+   } else if (host->caps & MMC_CAP_SDIO_IRQ) {
+   mmc_release_host(host);
+   mmc_host_clk_hold(host);
+   host->ops->enable_sdio_irq(host, 1);
+   mmc_host_clk_release(host);
+   mmc_claim_host(host);
+   }
+   }
+
mmc_release_host(host);
 
host->pm_flags &= ~MMC_PM_KEEP_POWER;
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 5cc13c8..696eca4 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -208,7 +208,7 @@ static int sdio_card_irq_get(struct mmc_card *card)
host->sdio_irqs--;
return err;
}
-   } else {
+   } else if (host->caps & MMC_CAP_SDIO_IRQ) {
mmc_host_clk_hold(host);
host->ops->enable_sdio_irq(host, 1);
mmc_host_clk_release(host);
@@ -229,7 +229,7 @@ static int sdio_card_irq_put(struct mmc_card *card)
if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHREAD)) {
atomic_set(&host->sdio_irq_thread_abort, 1);
kthread_stop(host->sdio_irq_thread);
-   } else {
+   } else if (host->caps & MMC_CAP_SDIO_IRQ) {
mmc_host_clk_hold(host);
host->ops->enable_sdio_irq(host, 0);
mmc_host_clk_release(host);
-- 1.7.1






On 2014/7/30 11:40, Jaehoon Chung wrote:
> Hi, Zhonghui.
>
> On 07/30/2014 11:47 AM, Fu, Zhonghui wrote:
>> Hi,
>>
>> In the resume function, SDIO irq must be enabled, or the interrupts from 
>> devices on SDIO bus can't be acknowledged. I also uploaded this new patch to 
>> https://bugzilla.kernel.org/show_bug.cgi?id=80151.
>> Could you please help to review it?
>>
>>
>>
>>
>> Thanks,
>> Zhonghui
>>
>> On 2014/7/24 23:27, Fu, Zhonghui wrote:
>>> Hi,
>>>
>>> Any comments for this new patch?
>>>
>>> Thanks,
>>> Zhonghui
>>> On 2014/7/20 22:51, Fu, Zhonghui wrote:
 Hi,

 Chris' patch is not enough to fix this bug. I made a patch as follows and 
 verified it can work.  Could you please give out some comments about this 
 patch?


 Thanks,
 Zhonghui

 >From 72d6f5b56fa04290fd3a055ade1d89e7c8d4 Mon Sep 17 00:00:00 2001
 From: Fu Zhonghui 
 Date: Sun, 20 Jul 2014 22:29:53 +0800
 Subject: [PATCH] mmc: core: sdio: Fix unconditional wake_up_process() on 
 sdio thread

 781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
 bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
 the use of our own custom threaded IRQ handler, but left in an
 unconditional wake_up_process() on that handler at resume-time.

 Signed-off-by: Fu Zhonghui 
 ---
  drivers/mmc/core/sdio.c |   14 --
  1 files changed, 12 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
 index e636d9e..8369e56 100644
 --- a/drivers/mmc/core/sdio.c
 +++ b/drivers/mmc/core/sdio.c
 @@ -992,8 +992,18 @@ static int mmc_sdio_resume(struct mmc_host *host)
}
}
  
 -  if (!err && host->sdio_irqs)
 -  wake_up_process(host->sdio_irq_thread);
 +  if (!err && host->sdio_irqs) {
 +  if (!(host->caps2 & MMC_CAP2_SDIO_IRQ_NOTHR

Re: Is lockref_get_not_zero() really correct in dget_parent()

[Steven Noonan]

On Mon, Aug 4, 2014 at 9:54 PM, Steven Noonan  wrote:
> On Mon, Aug 04, 2014 at 09:07:32PM -0700, Linus Torvalds wrote:
>> On Mon, Aug 4, 2014 at 8:17 PM, NeilBrown  wrote:
>> >
>> >  I've been looking at last year's change to dentry refcounting which sets 
>> > the
>> >  refcount to -128 (mark_dead()) when the dentry is gone.
>> >
>> >  As this is an "unsigned long" and there are several places where
>> >  d_lockref.count is compared e.g. "> 1", I start feeling uncomfortable, as
>> >  "-128" is greater than "1".
>>
>> Anybody who checks the lockref count without holding the lock is
>> pretty much buggy by definition. And if you hold the lock, you had
>> better not ever see a negative (== large positive) number, because
>> that would be all kinds of buggy too.
>>
>> So I don't *think* that people who compare with "> 1" kind of things
>> should be problematic. I wouldn't necessarily disagree with the notion
>> of making a lockref be a signed entity, though. It started out
>> unsigned, but it started out without that dead state too, so that
>> unsigned thing can be considered a historical artifact rather than any
>> real design decision.
>>
>> Anyway, I think my argument is that anybody who actually looks at
>> d_count() and might see that magic dead value is so fundamentally
>> broken in other ways that I wouldn't worry too much about *that* part.
>>
>> But your "lockref_get_not_zero()" thing is a different thing:
>>
>> >  That brings me to dget_parent().  It only has rcu_read_lock() protection, 
>> > and
>> >  yet uses lockref_get_not_zero().  This doesn't seem safe.
>>
>> Yes, agreed, it's ugly and wrong, and smells bad.
>>
>> But I think it happens to be safe (because the re-checking of d_parent
>> will fail if a rename and dput could have triggered it, and even the
>> extraneous "dput()" is actually safe, because it won't cause the value
>> to become zero, so nothing bad happens. But it *is* kind of subtle,
>> and I do agree that it's *needlessly* so.
>>
>> So it might be a good idea to get rid of the "not zero" version
>> entirely, and make the check be about being *active* (ie not zero, and
>> not dead).
>>
>> The only user of lockref_get_not_zero() is that dget_parent() thing,
>> so that should be easy.
>>
>> So renaming it to "lockref_get_active()", and changing the "not zero"
>> test to check for "positive" and change the rtype of "count" to be
>> signed, all sound like good things to me.
>>
>> But I don't actually think it's an active bug, it's just an "active
>> horribly ugly and subtly working code". I guess in theory if you can
>> get lots of CPU's triggering the race at the same time, the magic
>> negative number could become zero and positive, but at that point I
>> don't think we're really talking reality any more.
>>
>> Can somebody pick holes in that? Does somebody want to send in the
>> cleanup patch?
>
> How does this look?
>
>
> diff --git a/fs/dcache.c b/fs/dcache.c
> index e99c6f5..1e7dc31 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -479,7 +479,7 @@ static void __dentry_kill(struct dentry *dentry)
>  * dentry_iput drops the locks, at which point nobody (except
>  * transient RCU lookups) can reach this dentry.
>  */
> -   BUG_ON((int)dentry->d_lockref.count > 0);
> +   BUG_ON(dentry->d_lockref.count > 0);
> this_cpu_dec(nr_dentry);
> if (dentry->d_op && dentry->d_op->d_release)
> dentry->d_op->d_release(dentry);
> @@ -532,7 +532,7 @@ static inline struct dentry *lock_parent(struct dentry 
> *dentry)
> struct dentry *parent = dentry->d_parent;
> if (IS_ROOT(dentry))
> return NULL;
> -   if (unlikely((int)dentry->d_lockref.count < 0))
> +   if (unlikely(dentry->d_lockref.count < 0))
> return NULL;
> if (likely(spin_trylock(&parent->d_lock)))
> return parent;
> @@ -699,7 +699,7 @@ struct dentry *dget_parent(struct dentry *dentry)
>  */
> rcu_read_lock();
> ret = ACCESS_ONCE(dentry->d_parent);
> -   gotref = lockref_get_not_zero(&ret->d_lockref);
> +   gotref = lockref_get_active(&ret->d_lockref);
> rcu_read_unlock();
> if (likely(gotref)) {
> if (likely(ret == ACCESS_ONCE(dentry->d_parent)))
> @@ -848,7 +848,7 @@ static void shrink_dentry_list(struct list_head *list)
>  * We found an inuse dentry which was not removed from
>  * the LRU because of laziness during lookup. Do not free it.
>  */
> -   if ((int)dentry->d_lockref.count > 0) {
> +   if (dentry->d_lockref.count > 0) {
> spin_unlock(&dentry->d_lock);
> if (parent)
> spin_unlock(&parent->d_lock);
> diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
> index aec7f73..d492f0e 100644
> --- a/fs/gfs2/glock.c
> +++ b/fs/gfs2/glock.c
> @@ -1745,7 +1745,7 @@ void gfs2_dump_glock(st

Re: [PATCH 4/7] locking/rwsem: threshold limited spinning for active readers

[Davidlohr Bueso]

On Sun, 2014-08-03 at 22:36 -0400, Waiman Long wrote:
> Even thought only the writers can perform optimistic spinning, there
> is still a chance that readers may take the lock before a spinning
> writer can get it. In that case, the owner field will be NULL and the
> spinning writer can spin indefinitely until its time quantum expires
> when some lock owning readers are not running.

Right, now I understand where you were coming from in patch 3/7 ;)

> This patch tries to handle this special case by:
>  1) setting the owner field to a special value RWSEM_READ_OWNED
> to indicate that the current or last owner is a reader.
>  2) seting a threshold on how many times (currently 100) spinning will
 ^^setting
> be done with active readers before giving up as there is no easy
> way to determine if all of them are currently running.
> 
> By doing so, it tries to strike a balance between giving up too early
> and losing potential performance gain and wasting too many precious
> CPU cycles when some lock owning readers are not running.

That's exactly why these kind of magic things aren't a good thing, much
less in locking. And other alternatives are much more involved, creating
more overhead, which can make the whole thing pretty much useless.

Nor does the amount of times trying to spin strike me as the correct
metric to determine such things. Instead something y cycles or time
based.

[...]
>  #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
> +/*
> + * The owner field is set to RWSEM_READ_OWNED if the last owner(s) are
> + * readers. It is not reset until a writer takes over and set it to its
> + * task structure pointer or NULL when it frees the lock. So a value
> + * of RWSEM_READ_OWNED doesn't mean it currently has active readers.
> + */
> +#define RWSEM_READ_OWNED ((struct task_struct *)-1)

Looks rather weird...

>  #define __RWSEM_OPT_INIT(lockname) , .osq = OSQ_LOCK_UNLOCKED, .owner = NULL
>  #else
>  #define __RWSEM_OPT_INIT(lockname)
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 9f71a67..576d4cd 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -304,6 +304,11 @@ static inline bool rwsem_try_write_lock(long count, 
> struct rw_semaphore *sem)
>  
>  #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
>  /*
> + * Threshold for optimistic spinning on readers
> + */
> +#define RWSEM_READ_SPIN_THRESHOLD100

I dislike this for the same reasons they weren't welcomed in spinlocks.
We don't know how it can impact workloads that have not been tested.

[...]
>  static bool rwsem_optimistic_spin(struct rw_semaphore *sem)
>  {
>   struct task_struct *owner;
>   bool taken = false;
> + int  read_spincnt = 0;
>  
>   preempt_disable();
>  
> @@ -397,8 +409,12 @@ static bool rwsem_optimistic_spin(struct rw_semaphore 
> *sem)
>  
>   while (true) {
>   owner = ACCESS_ONCE(sem->owner);
> - if (owner && !rwsem_spin_on_owner(sem, owner))
> + if (owner == RWSEM_READ_OWNED) {
> + if (++read_spincnt > RWSEM_READ_SPIN_THRESHOLD)
> + break;

This is still a pretty fast-path and is going to affect writers, so we
really want to keep it un-clobbered.

Thanks,
Davidlohr

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Is lockref_get_not_zero() really correct in dget_parent()

[Steven Noonan]

On Mon, Aug 04, 2014 at 09:07:32PM -0700, Linus Torvalds wrote:
> On Mon, Aug 4, 2014 at 8:17 PM, NeilBrown  wrote:
> >
> >  I've been looking at last year's change to dentry refcounting which sets 
> > the
> >  refcount to -128 (mark_dead()) when the dentry is gone.
> >
> >  As this is an "unsigned long" and there are several places where
> >  d_lockref.count is compared e.g. "> 1", I start feeling uncomfortable, as
> >  "-128" is greater than "1".
> 
> Anybody who checks the lockref count without holding the lock is
> pretty much buggy by definition. And if you hold the lock, you had
> better not ever see a negative (== large positive) number, because
> that would be all kinds of buggy too.
> 
> So I don't *think* that people who compare with "> 1" kind of things
> should be problematic. I wouldn't necessarily disagree with the notion
> of making a lockref be a signed entity, though. It started out
> unsigned, but it started out without that dead state too, so that
> unsigned thing can be considered a historical artifact rather than any
> real design decision.
> 
> Anyway, I think my argument is that anybody who actually looks at
> d_count() and might see that magic dead value is so fundamentally
> broken in other ways that I wouldn't worry too much about *that* part.
> 
> But your "lockref_get_not_zero()" thing is a different thing:
> 
> >  That brings me to dget_parent().  It only has rcu_read_lock() protection, 
> > and
> >  yet uses lockref_get_not_zero().  This doesn't seem safe.
> 
> Yes, agreed, it's ugly and wrong, and smells bad.
> 
> But I think it happens to be safe (because the re-checking of d_parent
> will fail if a rename and dput could have triggered it, and even the
> extraneous "dput()" is actually safe, because it won't cause the value
> to become zero, so nothing bad happens. But it *is* kind of subtle,
> and I do agree that it's *needlessly* so.
> 
> So it might be a good idea to get rid of the "not zero" version
> entirely, and make the check be about being *active* (ie not zero, and
> not dead).
> 
> The only user of lockref_get_not_zero() is that dget_parent() thing,
> so that should be easy.
> 
> So renaming it to "lockref_get_active()", and changing the "not zero"
> test to check for "positive" and change the rtype of "count" to be
> signed, all sound like good things to me.
> 
> But I don't actually think it's an active bug, it's just an "active
> horribly ugly and subtly working code". I guess in theory if you can
> get lots of CPU's triggering the race at the same time, the magic
> negative number could become zero and positive, but at that point I
> don't think we're really talking reality any more.
> 
> Can somebody pick holes in that? Does somebody want to send in the
> cleanup patch?

How does this look?


diff --git a/fs/dcache.c b/fs/dcache.c
index e99c6f5..1e7dc31 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -479,7 +479,7 @@ static void __dentry_kill(struct dentry *dentry)
 * dentry_iput drops the locks, at which point nobody (except
 * transient RCU lookups) can reach this dentry.
 */
-   BUG_ON((int)dentry->d_lockref.count > 0);
+   BUG_ON(dentry->d_lockref.count > 0);
this_cpu_dec(nr_dentry);
if (dentry->d_op && dentry->d_op->d_release)
dentry->d_op->d_release(dentry);
@@ -532,7 +532,7 @@ static inline struct dentry *lock_parent(struct dentry 
*dentry)
struct dentry *parent = dentry->d_parent;
if (IS_ROOT(dentry))
return NULL;
-   if (unlikely((int)dentry->d_lockref.count < 0))
+   if (unlikely(dentry->d_lockref.count < 0))
return NULL;
if (likely(spin_trylock(&parent->d_lock)))
return parent;
@@ -699,7 +699,7 @@ struct dentry *dget_parent(struct dentry *dentry)
 */
rcu_read_lock();
ret = ACCESS_ONCE(dentry->d_parent);
-   gotref = lockref_get_not_zero(&ret->d_lockref);
+   gotref = lockref_get_active(&ret->d_lockref);
rcu_read_unlock();
if (likely(gotref)) {
if (likely(ret == ACCESS_ONCE(dentry->d_parent)))
@@ -848,7 +848,7 @@ static void shrink_dentry_list(struct list_head *list)
 * We found an inuse dentry which was not removed from
 * the LRU because of laziness during lookup. Do not free it.
 */
-   if ((int)dentry->d_lockref.count > 0) {
+   if (dentry->d_lockref.count > 0) {
spin_unlock(&dentry->d_lock);
if (parent)
spin_unlock(&parent->d_lock);
diff --git a/fs/gfs2/glock.c b/fs/gfs2/glock.c
index aec7f73..d492f0e 100644
--- a/fs/gfs2/glock.c
+++ b/fs/gfs2/glock.c
@@ -1745,7 +1745,7 @@ void gfs2_dump_glock(struct seq_file *seq, const struct 
gfs2_glock *gl)
  state2str(gl->gl_demote_state), dtime,
  atomic_read(&gl->gl_ail_count),
  atomic_read(&gl->gl_revok

Re: [PATCH 1/2] KVM: nVMX: Fix nested vmexit ack intr before load vmcs01

[Wanpeng Li]

Hi Davidlohr,
On Mon, Aug 04, 2014 at 12:56:36PM -0700, Davidlohr Bueso wrote:
>On Fri, 2014-08-01 at 16:12 +0800, Wanpeng Li wrote:
>> External interrupt will cause L1 vmexit w/ reason external interrupt when L2 
>> is 
>> running. Then L1 will pick up the interrupt through vmcs12 if L1 set the ack 
>> interrupt bit. Commit 77b0f5d (KVM: nVMX: Ack and write vector info to 
>> intr_info
>> if L1 asks us to)
>
>So being that 77b0f5d is in 3.15, we need it for -stable.
>
>>  get intr that belongs to L1 before load vmcs01 which is wrong, 
>> especially this lead to the obvious L1 ack APICv behavior weired since APICv 
>> is for L1 instead of L2. This patch fix it by ack intr after load vmcs01.
>> 
>> Signed-off-by: Wanpeng Li 
>
>It strikes me that this fixes Felipe's issue:
>http://paste.opensuse.org/view/raw/78752586
>

Could you verify if the latest version also fix your issue? Your Tested-by
to the latest version is appreciated.

Regards,
Wanpeng Li 

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

[PATCH v2 2/2] KVM: nVMX: fix acknowledge interrupt on exit when APICv is in use

[Wanpeng Li]

After commit 77b0f5d (KVM: nVMX: Ack and write vector info to intr_info
if L1 asks us to), "Acknowledge interrupt on exit" behavior can be
emulated. To do so, KVM will ask the APIC for the interrupt vector if
during a nested vmexit if VM_EXIT_ACK_INTR_ON_EXIT is set.  With APICv,
kvm_get_apic_interrupt would return -1 and give the following WARNING:

Call Trace:
 [] dump_stack+0x49/0x5e
 [] warn_slowpath_common+0x7c/0x96
 [] ? nested_vmx_vmexit+0xa4/0x233 [kvm_intel]
 [] warn_slowpath_null+0x15/0x17
 [] nested_vmx_vmexit+0xa4/0x233 [kvm_intel]
 [] ? nested_vmx_exit_handled+0x6a/0x39e [kvm_intel]
 [] ? kvm_apic_has_interrupt+0x80/0xd5 [kvm]
 [] vmx_check_nested_events+0xc3/0xd3 [kvm_intel]
 [] inject_pending_event+0xd0/0x16e [kvm]
 [] vcpu_enter_guest+0x319/0x704 [kvm]

If enabling APIC-v, all interrupts to L1 are delivered through APIC-v.
But when L2 is running, external interrupt will casue L1 vmexit with
reason external interrupt. Then L1 will pick up the interrupt through
vmcs12. when L1 ack the interrupt, since the APIC-v is enabled when
L1 is running, so APIC-v hardware still will do vEOI updating. The problem
is that the interrupt is delivered not through APIC-v hardware, this means
SVI/RVI/vPPR are not setting, but hardware required them when doing vEOI
updating. The solution is that, when L1 tried to pick up the interrupt
from vmcs12, then hypervisor will help to update the SVI/RVI/vPPR to make
sure the following vEOI updating and vPPR updating corrently.

Also, since interrupt is delivered through vmcs12, so APIC-v hardware will
not cleare vIRR and hypervisor need to clear it before L1 running.

Suggested-by: Paolo Bonzini 
Suggested-by: "Zhang, Yang Z" 
Tested-by: Liu, RongrongX 
Signed-off-by: Wanpeng Li 
---
v1 -> v2:
 * reusing kvm_get_apic_interrupt here (by modifying kvm_cpu_get_interrupt, 
   apic_set_isr and apic_clear_irr)

 arch/x86/kvm/irq.c   |  2 +-
 arch/x86/kvm/lapic.c | 52 +++-
 2 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index bd0da43..a1ec6a5 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -108,7 +108,7 @@ int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
 
vector = kvm_cpu_get_extint(v);
 
-   if (kvm_apic_vid_enabled(v->kvm) || vector != -1)
+   if (vector != -1)
return vector;  /* PIC */
 
return kvm_get_apic_interrupt(v);   /* APIC */
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 3855103..08e8a89 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -352,25 +352,46 @@ static inline int apic_find_highest_irr(struct kvm_lapic 
*apic)
 
 static inline void apic_clear_irr(int vec, struct kvm_lapic *apic)
 {
-   apic->irr_pending = false;
+   struct kvm_vcpu *vcpu;
+
+   vcpu = apic->vcpu;
+
apic_clear_vector(vec, apic->regs + APIC_IRR);
-   if (apic_search_irr(apic) != -1)
-   apic->irr_pending = true;
+   if (unlikely(kvm_apic_vid_enabled(vcpu->kvm)))
+   /* try to update RVI */
+   kvm_make_request(KVM_REQ_EVENT, vcpu);
+   else {
+   vec = apic_search_irr(apic);
+   apic->irr_pending = (vec != -1);
+   }
 }
 
 static inline void apic_set_isr(int vec, struct kvm_lapic *apic)
 {
-   /* Note that we never get here with APIC virtualization enabled.  */
+   struct kvm_vcpu *vcpu;
+
+   if (__apic_test_and_set_vector(vec, apic->regs + APIC_ISR))
+   return;
+
+   vcpu = apic->vcpu;
 
-   if (!__apic_test_and_set_vector(vec, apic->regs + APIC_ISR))
-   ++apic->isr_count;
-   BUG_ON(apic->isr_count > MAX_APIC_VECTOR);
/*
-* ISR (in service register) bit is set when injecting an interrupt.
-* The highest vector is injected. Thus the latest bit set matches
-* the highest bit in ISR.
+* With APIC virtualization enabled, all caching is disabled
+* because the processor can modify ISR under the hood.  Instead
+* just set SVI.
 */
-   apic->highest_isr_cache = vec;
+   if (unlikely(kvm_apic_vid_enabled(vcpu->kvm)))
+   kvm_x86_ops->hwapic_isr_update(vcpu->kvm, vec);
+   else {
+   ++apic->isr_count;
+   BUG_ON(apic->isr_count > MAX_APIC_VECTOR);
+   /*
+* ISR (in service register) bit is set when injecting an 
interrupt.
+* The highest vector is injected. Thus the latest bit set 
matches
+* the highest bit in ISR.
+*/
+   apic->highest_isr_cache = vec;
+   }
 }
 
 static inline int apic_find_highest_isr(struct kvm_lapic *apic)
@@ -1627,11 +1648,16 @@ int kvm_get_apic_interrupt(struct kvm_vcpu *vcpu)
int vector = kvm_apic_has_interrupt(vcpu);
struct kvm_lapic *apic = vcpu->arch.apic;
 
-   /* Note that we never get here with A

[PATCH v2 1/2] KVM: nVMX: Fix nested vmexit ack intr before load vmcs01

[Wanpeng Li]

External interrupt will cause L1 vmexit w/ reason external interrupt when L2 is 
running. Then L1 will pick up the interrupt through vmcs12 if L1 set the ack 
interrupt bit. Commit 77b0f5d (KVM: nVMX: Ack and write vector info to intr_info
if L1 asks us to) get intr that belongs to L1 before load vmcs01 which is 
wrong, 
especially this lead to the obvious L1 ack APICv behavior weired since APICv 
is for L1 instead of L2. This patch fix it by ack intr after load vmcs01.

Reviewed-by: Paolo Bonzini 
Tested-by: Liu, RongrongX 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e618f34..b8122b3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -8754,14 +8754,6 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
exit_reason,
prepare_vmcs12(vcpu, vmcs12, exit_reason, exit_intr_info,
   exit_qualification);
 
-   if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
-   && nested_exit_intr_ack_set(vcpu)) {
-   int irq = kvm_cpu_get_interrupt(vcpu);
-   WARN_ON(irq < 0);
-   vmcs12->vm_exit_intr_info = irq |
-   INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
-   }
-
trace_kvm_nested_vmexit_inject(vmcs12->vm_exit_reason,
   vmcs12->exit_qualification,
   vmcs12->idt_vectoring_info_field,
@@ -8771,6 +8763,14 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
exit_reason,
 
vmx_load_vmcs01(vcpu);
 
+   if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
+   && nested_exit_intr_ack_set(vcpu)) {
+   int irq = kvm_cpu_get_interrupt(vcpu);
+   WARN_ON(irq < 0);
+   vmcs12->vm_exit_intr_info = irq |
+   INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
+   }
+
vm_entry_controls_init(vmx, vmcs_read32(VM_ENTRY_CONTROLS));
vm_exit_controls_init(vmx, vmcs_read32(VM_EXIT_CONTROLS));
vmx_segment_cache_clear(vmx);
-- 
1.9.1

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

Re: [PATCH? v2] x86: reimplement ___preempt_schedule*() using THUNK helpers

[Mike Galbraith]

On Mon, 2014-08-04 at 19:36 +0200, Oleg Nesterov wrote:

> Seems to work at least on x86_64, but I do not know how to test, lets see
> what HPA thinks.

Seeing the words "preempt" and "test", blindly feeding it to -rt seemed
like a reasonable thing to do over morning java (la la la;)... it hasn't
spat it out yet.

-Mike

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

[GIT PULL] bcache changes for 3.17

[Kent Overstreet]

Hey Jens, here's the pull request for 3.17 - typically late, but lots of tasty
fixes in this one :)

The following changes since commit 4c834452aad01531db949414f94f817a86348d59:

  Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)

are available in the git repository at:

  http://evilpiepirate.org/git/linux-bcache.git for-jens

for you to fetch changes up to 0781c8748cf1ea2b0dcd966571103909528c4efa:

  bcache: Drop unneeded blk_sync_queue() calls (2014-08-04 15:23:04 -0700)


Jianjian Huo (1):
  bcache: add mutex lock for bch_is_open

Kent Overstreet (7):
  bcache: Fix a bug when detaching
  bcache: Fix a journal replay bug
  bcache: Make sure to pass GFP_WAIT to mempool_alloc()
  bcache: Allocate bounce buffers with GFP_NOWAIT
  bcache: Fix an infinite loop in journal replay
  bcache: Fix more early shutdown bugs
  bcache: Drop unneeded blk_sync_queue() calls

Slava Pestov (12):
  bcache allocator: send discards with correct size
  bcache: fix lockdep warnings on shutdown
  bcache: fix crash on shutdown in passthrough mode
  bcache: wait for buckets when allocating new btree root
  bcache: fix uninterruptible sleep in writeback thread
  bcache: fix typo in bch_bkey_equal_header
  bcache: bcache_write tracepoint was crashing
  bcache: fix crash in bcache_btree_node_alloc_fail tracepoint
  bcache: fix use-after-free in btree_gc_coalesce()
  bcache: fix crash with incomplete cache set
  bcache: fix memory corruption in init error path
  bcache: try to set b->parent properly

Surbhi Palande (2):
  bcache: Fix to remove the rcu_sched stalls.
  bcache: Correct printing of btree_gc_max_duration_ms

 drivers/md/bcache/alloc.c |  2 +-
 drivers/md/bcache/bcache.h|  4 +++
 drivers/md/bcache/bset.c  |  2 +-
 drivers/md/bcache/bset.h  |  2 +-
 drivers/md/bcache/btree.c | 50 ++---
 drivers/md/bcache/btree.h |  5 ++--
 drivers/md/bcache/extents.c   | 13 +++---
 drivers/md/bcache/extents.h   |  1 +
 drivers/md/bcache/journal.c   | 24 +++---
 drivers/md/bcache/request.c   |  3 ++-
 drivers/md/bcache/super.c | 57 ---
 drivers/md/bcache/util.h  |  4 +--
 drivers/md/bcache/writeback.c | 14 ---
 drivers/md/bcache/writeback.h |  3 ++-
 include/trace/events/bcache.h | 21 +---
 15 files changed, 131 insertions(+), 74 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: [GIT PULL] Staging driver patches for 3.17-rc1

[Greg KH]

On Tue, Aug 05, 2014 at 06:13:25AM +0200, Andreas Mohr wrote:
> > Lots of things in here, over 2000 patches, but the best part is this:
> >  1480 files changed, 39070 insertions(+), 254659 deletions(-)
> >
> > Thanks to the great work of Kristina Martšenko, 14 different staging
> > drivers have been removed from the tree as they were obsolete and no
> > one
> > was willing to work on cleaning them up.
> 
> -ENOPARSE.
> 
> Define "as they were obsolete and no one was willing to work on cleaning
> them up."?
> 
> *Either* they're obsolete (due to better alternatives available, in the
> standard case), in which case they indeed can be removed on the spot,
> *or* they are expected to become full-service drivers and thus need cleanup.
> Which is it?

No one was willing to do the work to get these drivers out of the
staging directory.  One had been broken for a number of kernel releases
with no one even noticing.

> In the case of keucr (a driver where I happen to own hardware,
> and where AFAIK this driver is required),
> I really don't see "nobody was willing to work on cleaning them up.",
> as git log tells.

Don't confuse "coding style cleanups done in a drive-by fashion" with
"willing to do the real work to get this driver merged out of the
staging tree."

> Admittedly there probably was no substantial rework,
> but it did have many janitorial changes, and some changes
> only 4 months ago even (a time frame which IMHO does not justify
> removing a driver wholesale, with the effect of certain users to not
> be able to use them then).
> 
> Oh well, yet another driver where it became more difficult rather than
> easier to make forward progress.

If you are willing to do the work, I will gladly revert the patch and
look forward to patches to fix the remaining changes.

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] drivers/isdn/hisax/Kconfig: Let HISAX_NETJET skip microblaze architecture

[Chen Gang]

On 08/05/2014 03:44 AM, Geert Uytterhoeven wrote:
> On Mon, Aug 4, 2014 at 9:23 PM, Jean Delvare  wrote:
>>> --- a/drivers/isdn/hisax/Kconfig
>>> +++ b/drivers/isdn/hisax/Kconfig
>>> @@ -237,7 +237,7 @@ config HISAX_MIC
>>>
>>>  config HISAX_NETJET
>>>   bool "NETjet card"
>>> - depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && 
>>> !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
>>> + depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && 
>>> !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE))
>>>   depends on VIRT_TO_BUS
>>>   help
>>> This enables HiSax support for the NetJet from Traverse
>>> @@ -249,7 +249,7 @@ config HISAX_NETJET
>>>
>>>  config HISAX_NETJET_U
>>>   bool "NETspider U card"
>>> - depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && 
>>> !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
>>> + depends on PCI && (BROKEN || !(PPC || PARISC || M68K || (MIPS && 
>>> !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN) || MICROBLAZE))
>>>   depends on VIRT_TO_BUS
>>>   help
>>> This enables HiSax support for the Netspider U interface ISDN card
>>
>> Fine with me, however the list is getting long. It would be better if
>> we could depend on a functional symbol rather than a negated list of
>> architectures. Would it make sense to have CONFIG_CPU_LITTLE_ENDIAN
>> defined on all little-endian architectures, so that driver can depend
>> on that if needed?
> 
> Yes, that idea pops up once in a while.
> 
> BTW, these days little endian PPC is also supported by Linux...
> 
>> Alternatively, it might make more sense to list the architectures where
>> these drivers are actually used in practice. I guess that's X86, maybe
>> ARM and IA64, and that's all?
> 
> || COMPILE_TEST 
> 

OK, thanks, what all of you said sounds reasonable to me.

Hello Geert:

Could you help send the related patch for it?


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: linux-next: build failures after merge of the drm tree

[Dave Airlie]

> Hi Dave,
> 
> After merging the drm tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: "drm_sysfs_connector_remove" [drivers/gpu/drm/i2c/tda998x.ko] 
> undefined!
> ERROR: "drm_sysfs_connector_add" [drivers/gpu/drm/i2c/tda998x.ko] undefined!
> 

I've fixed this, caught it myself a few mins after push,

The other I'm not sure about, I'll hope the exynos guys know what is going 
on.

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

Re: [GIT PULL] Staging driver patches for 3.17-rc1

[Andreas Mohr]

> Lots of things in here, over 2000 patches, but the best part is this:
>  1480 files changed, 39070 insertions(+), 254659 deletions(-)
>
> Thanks to the great work of Kristina Martšenko, 14 different staging
> drivers have been removed from the tree as they were obsolete and no
> one
> was willing to work on cleaning them up.

-ENOPARSE.

Define "as they were obsolete and no one was willing to work on cleaning
them up."?

*Either* they're obsolete (due to better alternatives available, in the
standard case), in which case they indeed can be removed on the spot,
*or* they are expected to become full-service drivers and thus need cleanup.
Which is it?

In the case of keucr (a driver where I happen to own hardware,
and where AFAIK this driver is required),
I really don't see "nobody was willing to work on cleaning them up.",
as git log tells. Admittedly there probably was no substantial rework,
but it did have many janitorial changes, and some changes
only 4 months ago even (a time frame which IMHO does not justify
removing a driver wholesale, with the effect of certain users to not be able to
use them then).

Oh well, yet another driver where it became more difficult rather than easier
to make forward progress.


But I guess that change was done very intentionally, likely to induce pain
in non-cooperative areas ;-P
(which may or may not be a good thing...)

Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] FS-Cache: Bug fixes for bugs that happen under vma pressure

[Milosz Tanski]

David, I was away for a few days I'll take a look at your comments and
respond appropriately within the next two days.

- M

On Tue, Jul 29, 2014 at 12:03 PM, David Howells  wrote:
> Did you mean to add Signed-off-by lines?
>
> David



-- 
Milosz Tanski
CTO
16 East 34th Street, 15th floor
New York, NY 10016

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

[PATCH] perf/x86: fix load latency/precise store data source issues

[Stephane Eranian]

This patch fixes some issues introduced by Andi's 'Revamp
PEBS' event selection patch (which is under review right now).

Most of the issues were related to the encoding of the
data source, for PEBS events in general and load/store
events on Haswell.

This patchd does:
 - the default of 0 in perf_sample_data_init() was wrong. 0 is not
  a valid value. So defined PERF_MEM_NA (not available)

 - On HSW, renamed your precise_store_hsw() to datala_hsw()
   because you are actually processing both loads and stores, except
   the load latency event which goes thru normal function

 - precise_store_data_hsw() was returning bogus data source for store
   events. dse.mem_lvl instead of dse.val

Signed-off-by: Stephane Eranian 
---
 arch/x86/kernel/cpu/perf_event_intel_ds.c | 23 ++-
 include/linux/perf_event.h|  9 -
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_ds.c 
b/arch/x86/kernel/cpu/perf_event_intel_ds.c
index a9b60f3..1aca254 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -108,14 +108,17 @@ static u64 precise_store_data(u64 status)
return val;
 }
 
-static u64 precise_store_data_hsw(struct perf_event *event, u64 status)
+static u64 precise_datala_hsw(struct perf_event *event, u64 status)
 {
union perf_mem_data_src dse;
u64 cfg = event->hw.config & INTEL_ARCH_EVENT_MASK;
 
-   dse.val = 0;
-   dse.mem_op = PERF_MEM_OP_NA;
-   dse.mem_lvl = PERF_MEM_LVL_NA;
+   dse.val = PERF_MEM_NA;
+
+   if (event->hw.flags & PERF_X86_EVENT_PEBS_ST_HSW)
+   dse.mem_op = PERF_MEM_OP_STORE;
+   else if (event->hw.flags & PERF_X86_EVENT_PEBS_LD_HSW)
+   dse.mem_op = PERF_MEM_OP_LOAD;
 
/*
 * L1 info only valid for following events:
@@ -126,7 +129,7 @@ static u64 precise_store_data_hsw(struct perf_event *event, 
u64 status)
 * MEM_UOPS_RETIRED.ALL_STORES
 */
if (cfg != 0x12d0 && cfg != 0x22d0 && cfg != 0x42d0 && cfg != 0x82d0)
-   return dse.mem_lvl;
+   return dse.val;
 
if (status & 1)
dse.mem_lvl = PERF_MEM_LVL_L1 | PERF_MEM_LVL_HIT;
@@ -861,16 +864,18 @@ static void __intel_pmu_pebs_event(struct perf_event 
*event,
 * data.data_src encodes the data source
 */
if (sample_type & PERF_SAMPLE_DATA_SRC) {
+   u64 val;
if (fll)
-   data.data_src.val = 
load_latency_data(pebs->dse);
+   val = load_latency_data(pebs->dse);
else if (event->hw.flags &
(PERF_X86_EVENT_PEBS_ST_HSW|
 PERF_X86_EVENT_PEBS_LD_HSW|
 PERF_X86_EVENT_PEBS_NA_HSW))
-   data.data_src.val =
-   precise_store_data_hsw(event, 
pebs->dse);
+   val = precise_datala_hsw(event, pebs->dse);
else
-   data.data_src.val = 
precise_store_data(pebs->dse);
+   val = precise_store_data(pebs->dse);
+
+   data.data_src.val = val;
}
}
 
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 707617a..8b206aa 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -604,6 +604,13 @@ struct perf_sample_data {
u64 txn;
 };
 
+/* default value for data source */
+#define PERF_MEM_NA (PERF_MEM_S(OP, NA)   |\
+   PERF_MEM_S(LVL, NA)   |\
+   PERF_MEM_S(SNOOP, NA) |\
+   PERF_MEM_S(LOCK, NA)  |\
+   PERF_MEM_S(TLB, NA))
+
 static inline void perf_sample_data_init(struct perf_sample_data *data,
 u64 addr, u64 period)
 {
@@ -616,7 +623,7 @@ static inline void perf_sample_data_init(struct 
perf_sample_data *data,
data->regs_user.regs = NULL;
data->stack_user_size = 0;
data->weight = 0;
-   data->data_src.val = 0;
+   data->data_src.val = PERF_MEM_NA;
data->txn = 0;
 }
 
-- 
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: Is lockref_get_not_zero() really correct in dget_parent()

[Linus Torvalds]

On Mon, Aug 4, 2014 at 8:17 PM, NeilBrown  wrote:
>
>  I've been looking at last year's change to dentry refcounting which sets the
>  refcount to -128 (mark_dead()) when the dentry is gone.
>
>  As this is an "unsigned long" and there are several places where
>  d_lockref.count is compared e.g. "> 1", I start feeling uncomfortable, as
>  "-128" is greater than "1".

Anybody who checks the lockref count without holding the lock is
pretty much buggy by definition. And if you hold the lock, you had
better not ever see a negative (== large positive) number, because
that would be all kinds of buggy too.

So I don't *think* that people who compare with "> 1" kind of things
should be problematic. I wouldn't necessarily disagree with the notion
of making a lockref be a signed entity, though. It started out
unsigned, but it started out without that dead state too, so that
unsigned thing can be considered a historical artifact rather than any
real design decision.

Anyway, I think my argument is that anybody who actually looks at
d_count() and might see that magic dead value is so fundamentally
broken in other ways that I wouldn't worry too much about *that* part.

But your "lockref_get_not_zero()" thing is a different thing:

>  That brings me to dget_parent().  It only has rcu_read_lock() protection, and
>  yet uses lockref_get_not_zero().  This doesn't seem safe.

Yes, agreed, it's ugly and wrong, and smells bad.

But I think it happens to be safe (because the re-checking of d_parent
will fail if a rename and dput could have triggered it, and even the
extraneous "dput()" is actually safe, because it won't cause the value
to become zero, so nothing bad happens. But it *is* kind of subtle,
and I do agree that it's *needlessly* so.

So it might be a good idea to get rid of the "not zero" version
entirely, and make the check be about being *active* (ie not zero, and
not dead).

The only user of lockref_get_not_zero() is that dget_parent() thing,
so that should be easy.

So renaming it to "lockref_get_active()", and changing the "not zero"
test to check for "positive" and change the rtype of "count" to be
signed, all sound like good things to me.

But I don't actually think it's an active bug, it's just an "active
horribly ugly and subtly working code". I guess in theory if you can
get lots of CPU's triggering the race at the same time, the magic
negative number could become zero and positive, but at that point I
don't think we're really talking reality any more.

Can somebody pick holes in that? Does somebody want to send in the
cleanup patch?

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

Re: [PATCH 8/8] msm: scm: Move the scm driver to drivers/soc/qcom

[Lina Iyer]

On Mon, 4 Aug 2014, Stephen Boyd wrote:

> Architectural changes in the ARM Linux kernel tree mandate
> the eventual removal of the mach-* directories. Move the
> scm driver to drivers/soc/qcom and the scm header to
> include/soc/qcom to support that removal.
> 
> Signed-off-by: Stephen Boyd 
> ---
>  arch/arm/mach-qcom/Kconfig | 3 ---
>  arch/arm/mach-qcom/Makefile| 4 +---
>  arch/arm/mach-qcom/scm-boot.c  | 2 +-

 diff --git a/arch/arm/mach-qcom/scm.h b/include/soc/qcom/scm.h
> similarity index 100%
> rename from arch/arm/mach-qcom/scm.h
> rename to include/soc/qcom/scm.h

Could we move scm-boot.c as well to drivers/soc/qcom and scm-boot.h to 
include/soc/qcom ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: is the kgdb tree still relevant?

[Stephen Rothwell]

Hi Jason,

I have noticed that the kgdb tree contains 10 commits the last of which
was committed on March 3, 2013.  Should I drop this tree form
linux-next?

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


signature.asc
Description: PGP signature

Re: [PATCH] KVM: MMU: Use hashtable for MMU page hash

[Xiao Guangrong]

On 08/05/2014 04:54 AM, Sasha Levin wrote:
> Use the kernel hashtable interface instead of the hlist interface.
> This allows us to eliminate some unneeded code and make the code
> simpler.

The side effect is that the hash function is changed, the current
way is:
gfn & ((1 << KVM_MMU_HASH_SHIFT) - 1);

Guest memory is always continuous and big region, i guess it's better
than the one you introduced.

Anyway, benchmark is needed and always welcome. :)

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

Re: [PATCH v3 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting

[Doug Anderson]

Kever,

On Mon, Aug 4, 2014 at 6:45 PM, Kever Yang  wrote:
> Doug,
>
>
> On 08/05/2014 12:34 AM, Doug Anderson wrote:
>>
>> Kever,
>>
>> On Mon, Aug 4, 2014 at 6:45 AM, Kever Yang 
>> wrote:
>>>
>>> According to the "dr_mode", the otg controller can work as
>>> device role during firmware period, and work as host role in
>>> the kernel, without use of usb_id pin. As the commit "usb: dwc3:
>>> set 'mode' based on selected Kconfig choices".
>>
>> I don't think you need to mention firmware / kernel here.  Just say
>> that on some boards we always want to use host mode and on other
>> boards we want to use gadget mode.  ...and that we don't necessarily
>> have the ID pin hooked up to make this automatic.
>
> OK, I'll change this message again, I just don't know how to describe
> to make everyone understand what I'm doing.
>
>>
>>
>>> Signed-off-by: Kever Yang 
>>
>> Normally I'd say that you should have added Paul's "Acked-by" since
>> you fixed his nit and he told you to include his Acked-by when his nit
>> was fixed, but...
>
> There are some more changes than Paul's suggestion, so I'm not sure
> if Paul need more review to give me the "Acked-by", I get it now.
>
>>
>>
>>> ---
>>>
>>> Changes in v3:
>>> - fix the odd spacing in dwc2_hsotg struct
>>> - From Jingoo's suggestion:
>>>  change the commit message
>>
>> You did more than just this.  You also added some (incorrect) Kconfig
>> things.  See below.
>>
>>
>>> Changes in v2:
>>> - put spaces around '+' operator
>>> - expand the comment for dr_mode
>>> - handle dr_mode is USB_DR_MODE_OTG
>>>
>>>   drivers/usb/dwc2/core.c | 18 ++
>>>   drivers/usb/dwc2/core.h |  5 +
>>>   drivers/usb/dwc2/platform.c | 12 
>>>   3 files changed, 35 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
>>> index 27d2c9b..738bec2 100644
>>> --- a/drivers/usb/dwc2/core.c
>>> +++ b/drivers/usb/dwc2/core.c
>>> @@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>>>   {
>>>  u32 greset;
>>>  int count = 0;
>>> +   u32 gusbcfg;
>>>
>>>  dev_vdbg(hsotg->dev, "%s()\n", __func__);
>>>
>>> @@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
>>>  }
>>>  } while (greset & GRSTCTL_CSFTRST);
>>>
>>> +   if (hsotg->dr_mode == USB_DR_MODE_HOST) {
>>> +   gusbcfg = readl(hsotg->regs + GUSBCFG);
>>> +   gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
>>> +   gusbcfg |= GUSBCFG_FORCEHOSTMODE;
>>> +   writel(gusbcfg, hsotg->regs + GUSBCFG);
>>> +   } else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
>>> +   gusbcfg = readl(hsotg->regs + GUSBCFG);
>>> +   gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
>>> +   gusbcfg |= GUSBCFG_FORCEDEVMODE;
>>> +   writel(gusbcfg, hsotg->regs + GUSBCFG);
>>> +   } else if (hsotg->dr_mode == USB_DR_MODE_OTG) {
>>> +   gusbcfg = readl(hsotg->regs + GUSBCFG);
>>> +   gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
>>> +   gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
>>> +   writel(gusbcfg, hsotg->regs + GUSBCFG);
>>> +   }
>>> +
>>>  /*
>>>   * NOTE: This long sleep is _very_ important, otherwise the core
>>> will
>>>   * not stay in host mode after a connector ID change!
>>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>>> index 1efd10c..52a4fd2 100644
>>> --- a/drivers/usb/dwc2/core.h
>>> +++ b/drivers/usb/dwc2/core.h
>>> @@ -501,6 +501,10 @@ struct dwc2_hw_params {
>>>*  a_peripheral and b_device=>b_host) this may not
>>> match
>>>*  the core, but allows the software to determine
>>>*  transitions
>>> + * @dr_mode:Requested mode of operation, one of following:
>>> + *  - USB_DR_MODE_PERIPHERAL
>>> + *  - USB_DR_MODE_HOST
>>> + *  - USB_DR_MODE_OTG
>>>* @queuing_high_bandwidth: True if multiple packets of a
>>> high-bandwidth
>>>*  transfer are in process of being queued
>>>* @srp_success:Stores status of SRP request in the case of a
>>> FS PHY
>>> @@ -592,6 +596,7 @@ struct dwc2_hsotg {
>>>  /** Params to actually use */
>>>  struct dwc2_core_params *core_params;
>>>  enum usb_otg_state op_state;
>>> +   enum usb_dr_mode dr_mode;
>>>
>>>  unsigned int queuing_high_bandwidth:1;
>>>  unsigned int srp_success:1;
>>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>>> index a10e7a3..4d2c738 100644
>>> --- a/drivers/usb/dwc2/platform.c
>>> +++ b/drivers/usb/dwc2/platform.c
>>> @@ -42,6 +42,8 @@
>>>   #include 
>>>   #include 
>>>
>>> +#include 
>>> +
>>>   #include "core.h"
>>>   #include "hcd.h"
>>>
>>> @@ -171,6 +173,16 @@ static int dwc2_driver_probe(struct platform_device
>>> *dev)
>>>  de

Re: [PATCH, RESEND] procfs: silence lockdep warning about read vs. exec seq_file

[Eric W. Biederman]

"Kirill A. Shutemov"  writes:

> From: "Kirill A. Shutemov" 
>
> Testcase:
>
>   cat /proc/self/maps >/dev/null
>   chmod +x /proc/self/net/packet
>   exec /proc/self/net/packet
>
> It triggers lockdep warning:

> I don't know why we allow "chmod +x" on some proc files, notably net-related.
> Is it a bug?

It looks like we simply did not remove the ability to make those files
executable when we realized executable proc files could be a problem.

I expect that part of proc could use an audit where someone figures out
what makes sense.  It does appear that chmod XXX /proc/generic_file
is explicitly supported.  So we would have to be delicate with any
changes in that area to avoid creating userspace regressions.

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] sched: Reduce contention in update_cfs_rq_blocked_load

[Yuyang Du]

Hi Jason,

I am not sure whether you noticed my latest work: rewriting per entity load 
average

http://article.gmane.org/gmane.linux.kernel/1760754
http://article.gmane.org/gmane.linux.kernel/1760755
http://article.gmane.org/gmane.linux.kernel/1760757
http://article.gmane.org/gmane.linux.kernel/1760756

which simply does not track blocked load average at all. Are you interested in
testing the patchset with the workload you have? The comparison can also help
us understand the rewrite. Overall, per our tests, the overhead should be less,
and perf should be better.

Thanks,
Yuyang

On Mon, Aug 04, 2014 at 01:28:38PM -0700, Jason Low wrote:
> When running workloads on 2+ socket systems, based on perf profiles, the
> update_cfs_rq_blocked_load function constantly shows up as taking up a
> noticeable % of run time. This is especially apparent on an 8 socket
> machine. For example, when running the AIM7 custom workload, we see:
> 
>4.18%reaim  [kernel.kallsyms][k] update_cfs_rq_blocked_load
> 
> Much of the contention is in __update_cfs_rq_tg_load_contrib when we
> update the tg load contribution stats.  However, it turns out that in many
> cases, they don't need to be updated and "tg_contrib" is 0.
> 
> This patch adds a check in __update_cfs_rq_tg_load_contrib to skip updating
> tg load contribution stats when nothing needs to be updated. This reduces the
> cacheline contention that would be unnecessary. In the above case, with the
> patch, perf reports the total time spent in this function went down by more
> than a factor of 3x:
> 
>1.18%reaim  [kernel.kallsyms][k] update_cfs_rq_blocked_load
> 
> Signed-off-by: Jason Low 
> ---
>  kernel/sched/fair.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index bfa3c86..8d4cc72 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2377,6 +2377,9 @@ static inline void 
> __update_cfs_rq_tg_load_contrib(struct cfs_rq *cfs_rq,
>   tg_contrib = cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg;
>   tg_contrib -= cfs_rq->tg_load_contrib;
>  
> + if (!tg_contrib)
> + return;
> +
>   if (force_update || abs(tg_contrib) > cfs_rq->tg_load_contrib / 8) {
>   atomic_long_add(tg_contrib, &tg->load_avg);
>   cfs_rq->tg_load_contrib += tg_contrib;
> -- 
> 1.7.1
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Is lockref_get_not_zero() really correct in dget_parent()

[NeilBrown]

Hi,
 I've been looking at last year's change to dentry refcounting which sets the
 refcount to -128 (mark_dead()) when the dentry is gone.

 As this is an "unsigned long" and there are several places where
 d_lockref.count is compared e.g. "> 1", I start feeling uncomfortable, as
 "-128" is greater than "1".

 Most of them look safe because there is locking in place and
 d_lockref.count will never be seen as "-128" unless you get the reference
 with only rcu_read_lock().

 That brings me to dget_parent().  It only has rcu_read_lock() protection, and
 yet uses lockref_get_not_zero().  This doesn't seem safe.

 Is there a reason that it is safe that I'm not seeing?  Or is the following
 needed?

Thanks,
NeilBrown

Signed-off-by: NeilBrown 

diff --git a/fs/dcache.c b/fs/dcache.c
index 06f65857a855..c48ce95a38f2 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -699,7 +699,7 @@ struct dentry *dget_parent(struct dentry *dentry)
 */
rcu_read_lock();
ret = ACCESS_ONCE(dentry->d_parent);
-   gotref = lockref_get_not_zero(&ret->d_lockref);
+   gotref = lockref_get_not_dead(&ret->d_lockref);
rcu_read_unlock();
if (likely(gotref)) {
if (likely(ret == ACCESS_ONCE(dentry->d_parent)))


signature.asc
Description: PGP signature

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause  wrote:
> On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
>  wrote:
>> On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
>>> On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
>>>  wrote:
>>> >> From: Nick Krause [mailto:xerofo...@gmail.com]
>>
>> [snip]
>>
>>> >> Paul ,
>>> >> My computer is rather old now as of Sandy Bridge days, so I probably
>>> >> can't test the patch
>>> >> on my own machine. However I will look at the code and see if I can
>>> >> forward port it
>>> >> against the usb git tree I have a current version of. In addition I
>>> >> would like the new xhci
>>> >> maintainers information in  order to send out a patch with the
>>> >> Maintainer for xhci updated.
>>> >
>>> > Sarah already told you who the new maintainer is, and then CCed him
>>> > on this thread. Hint: There is a file name 'MAINTAINERS' in the root
>>> > of the kernel tree, which tells you who the maintainers are for all of
>>> > the subsystems. Please read Documentation/SubmittingPatches, it has a
>>> > lot of information like this that you need to know.
>>> >
>>> > --
>>> > Paul
>>> >
>>> Thanks I will read this file and thanks for the information. I known
>>> where the file is I will
>>> add the information then.
>>
>> You may be looking at an older version of MAINTAINERS.  Mathias has only
>> been marked as the maintainer since 3.15.  Which kernel version are you
>> working on?
>>
>> Sarah Sharp
>
I am going to send out my work on the project you sent me I hope it's
Ok if not feel free
to tell me why. I did this against linus's tree but other then that it
should work.
Regards Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Random panic in load_balance() with 3.16-rc

[Steven Rostedt]

On Fri, 25 Jul 2014 11:29:06 -0700
Linus Torvalds  wrote:

> On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt  wrote:
> >
> > But wouldn't it be rather trivial to run a static analyzer on the final
> > vmlinux to make sure there are no red zones? I mean, you would only need
> > to read each function and check to make sure that the offset of rbp is
> > within the change of rsp, wouldn't you?
> >
> > Almost seems like an objdump -rd into a perl script could do this.
> 
> I'm sure it's possible, but it sounds potentially complicated. It's
> not like the function prologue is fixed, and gcc will create code
> (including conditional branches etc) before the whole frame setup if
> there are simple things that can be done purely with the
> callee-clobbered registers etc.
> 
> Some simple pattern to make sure that the "sub $frame-size,%rsp" comes
> before any accesses to (%rbp) (when frame pointers are enabled)
> *might* work, but it might also end up missing things.
> 
> You want to try?
> 

I tried :-)

Seems to stay clean with my x86_64 vmlinux build. I compiled the fair.s
file and tested it and it got this:

$ objump -dr fair.o | ./check-vmlinux.pl
ERROR: : depth=-40 offset=136 at 4210
3572:   48 c7 85 78 ff ff ffmovq   $0x0,-0x88(%rbp)
ERROR: : depth=8 offset=48 at 5734
4a79:   48 89 45 d0 mov%rax,-0x30(%rbp)
ERROR: : depth=8 offset=48 at 5743
4a9c:   48 8b 75 d0 mov-0x30(%rbp),%rsi

The sched_group_set_shares errors seem to be bogus as that is done
after %rbp has been popped. Looks to be code that was jumped to from
the main body. I could probably fix this by ignoring code after a pop
of %rbp. Or make it more complex and be a bit smarter about branches.

The script will read a file if passed by parameter, otherwise it reads
standard input.

e.g.

$ objump -dr fair.o | ./check-vmlinux.pl

or

$ objdump -dr fair.o > /tmp/fair.dump
$ ./check-vmlinux.pl /tmp/fair.dump

produce the same.

It's a little hacky, but I only spent a half hour at most on it.

-- Steve


check-vmlinux.pl
Description: Perl program

Re: [GIT PULL] hwmon updates for 3.17

[Guenter Roeck]

On 08/04/2014 08:14 PM, Stephen Rothwell wrote:

Hi Guenter,

On Mon, 4 Aug 2014 19:22:09 -0700 Guenter Roeck  wrote:


Hi Linus,

Please pull hwmon updates for Linux 3.17 from signed tag:

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


This branch was rewritten (but not rebased) to add 5 commits at its
start and 8 commits at its end since yesterday's linux-next.


Yes, the start because I missed to send a bunch of fixes to Linus last week 
because I was on vacation
and merged it all together, and the end because I missed to push out a bunch of 
patches for the same
reason. Everything did pass my test suite, though.

If that is a problem, let me know.

Guenter

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

[Bugfix 1/2] x86, irq, PCI: Keep IRQ assignment for PCI devices during suspend/hibernation

[Jiang Liu]

Now IOAPIC driver dynamically allocates IRQ numbers for IOAPIC pins.
We need to keep IRQ assignment for PCI devices during suspend/hibernation,
otherwise it may cause failure of suspend/hibernation due to:
1) Device driver calls pci_enable_device() to allocate an IRQ number
   and register interrupt handler on the returned IRQ.
2) Device driver's suspend callback calls pci_disable_device() and
   release assigned IRQ in turn.
3) Device driver's resume callback calls pci_enable_device() to
   allocate IRQ number again. A different IRQ number may be assigned
   by IOAPIC driver this time.
4) Now the hardware delivers interrupt to the new IRQ but interrupt
   handler is still registered against the old IRQ, so it breaks
   suspend/hibernation.

To fix this issue, we keep IRQ assignment during suspend/hibernation.
Flag pci_dev.dev.power.is_prepared is used to detect that
pci_disable_device() is called during suspend/hibernation.

Signed-off-by: Jiang Liu 
---
Hi Borislav,
Could you please help to review the patch again since I have
made changes against the previous version?
Regards!
Gerry
---
 arch/x86/pci/intel_mid_pci.c |2 +-
 arch/x86/pci/irq.c   |3 ++-
 drivers/acpi/pci_irq.c   |4 
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 09fece368592..3865116c51fb 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->irq > 0)
+   if (!dev->dev.power.is_prepared && dev->irq > 0)
mp_unmap_irq(dev->irq);
 }
 
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 748cfe8ab322..bc1a2c341891 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1256,7 +1256,8 @@ 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->irq) {
+   if (io_apic_assign_pci_irqs && !dev->dev.power.is_prepared &&
+   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 6ba463ceccc6..c96887d5289e 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -481,6 +481,10 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
if (!pin)
return;
 
+   /* Keep IOAPIC pin configuration when suspending */
+   if (dev->dev.power.is_prepared)
+   return;
+
entry = acpi_pci_irq_lookup(dev, pin);
if (!entry)
return;
-- 
1.7.10.4

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

[Bugfix 2/2] x86, irq: Keep balance of IOAPIC pin reference count

[Jiang Liu]

To keep balance of IOAPIC pin reference count, we need to protect
pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable()
from reentrance. There are two cases which will cause reentrance.

The first case is caused by suspend/hibernation. If pcibios_disable_irq
is called during suspending/hibernating, we don't release the assigned
IRQ number, otherwise it may break the suspend/hibernation. So late when
pcibios_enable_irq is called during resume, we shouldn't allocate IRQ
number again.

The second case is that function acpi_pci_irq_enable() may be called
twice for PCI devices present at boot time as below:
1) pci_acpi_init()
--> acpi_pci_irq_enable() if pci_routeirq is true
2) pci_enable_device()
--> pcibios_enable_device()
--> acpi_pci_irq_enable()
We can't kill kernel parameter pci_routeirq yet because it's still
needed for debugging purpose.

Flag irq_managed is introduced to track whether IRQ number is assigned
by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable()
and intel_mid_pci_irq_enable() from reentrance.

Signed-off-by: Jiang Liu 
---
 arch/x86/pci/intel_mid_pci.c |9 -
 arch/x86/pci/irq.c   |7 ++-
 drivers/acpi/pci_irq.c   |   11 +--
 include/linux/pci.h  |1 +
 4 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 3865116c51fb..661e948aba11 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -210,6 +210,9 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
 {
int polarity;
 
+   if (dev->irq_managed && dev->irq > 0)
+   return 0;
+
if (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_TANGIER)
polarity = 0; /* active high */
else
@@ -224,13 +227,17 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
if (mp_map_gsi_to_irq(dev->irq, IOAPIC_MAP_ALLOC) < 0)
return -EBUSY;
 
+   dev->irq_managed = 1;
+
return 0;
 }
 
 static void intel_mid_pci_irq_disable(struct pci_dev *dev)
 {
-   if (!dev->dev.power.is_prepared && dev->irq > 0)
+   if (!dev->dev.power.is_prepared && dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
+   dev->irq_managed = 0;
+   }
 }
 
 struct pci_ops intel_mid_pci_ops = {
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index bc1a2c341891..dd1369dbcc42 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1202,6 +1202,9 @@ static int pirq_enable_irq(struct pci_dev *dev)
int irq;
struct io_apic_irq_attr irq_attr;
 
+   if (dev->irq_managed && dev->irq > 0)
+   return 0;
+
irq = IO_APIC_get_PCI_irq_vector(dev->bus->number,
PCI_SLOT(dev->devfn),
pin - 1, &irq_attr);
@@ -1228,6 +1231,7 @@ static int pirq_enable_irq(struct pci_dev *dev)
}
dev = temp_dev;
if (irq >= 0) {
+   dev->irq_managed = 1;
dev->irq = irq;
dev_info(&dev->dev, "PCI->APIC IRQ transform: "
 "INT %c -> IRQ %d\n", 'A' + pin - 1, 
irq);
@@ -1257,8 +1261,9 @@ 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 &&
-   dev->irq) {
+   dev->irq_managed && dev->irq > 0) {
mp_unmap_irq(dev->irq);
dev->irq = 0;
+   dev->irq_managed = 0;
}
 }
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index c96887d5289e..4a89701dfe36 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -413,6 +413,9 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
 
+   if (dev->irq_managed && dev->irq > 0)
+   return 0;
+
entry = acpi_pci_irq_lookup(dev, pin);
if (!entry) {
/*
@@ -456,6 +459,7 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return rc;
}
dev->irq = rc;
+   dev->irq_managed = 1;
 
if (link)
snprintf(link_desc, sizeof(link_desc), " -> Link[%s]", link);
@@ -478,7 +482,7 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
u8 pin;
 
pin = dev->pin;
-   if (!pin)
+   if (!pin || !dev->irq_managed || dev->irq <= 0)
return;
 
/* Keep IOAPIC pin configuration when suspending */
@@ -502,6 +506,9 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
 */
 
dev_dbg(&dev->dev, "PCI INT %c disabled\n", pin_name(pin));
-   if (gsi >= 0 && dev->irq > 0)
+   if (

[Bugfix 0/2] Fix bugs caused by "use irqdomain to dynamically allocate IRQ for IOAPIC"

[Jiang Liu]

Two issues have been reported against patch set "use irqdomain to
dynamically allocate IRQ for IOAPIC" at https://lkml.org/lkml/2014/6/9/44.

This first one causes failure of suspend/hibernation, please refer to
https://lkml.org/lkml/2014/7/28/822 for more information. And we have
worked out a patch to fix it (https://lkml.org/lkml/2014/7/30/725) and
Borislav has tested it. But with more testing and analysis, I found the
provided patch still has some issues:
1) It may cause regression to Xen
2) Flag dev->dev.power.is_prepared has already been cleared when
   pcibios_enable_device() gets called, so it will cause IOAPIC pin
   reference count leak.

So I reworked the patch to fix above issues. The first patch fixes issue
1 by moving check of dev->dev.power.is_prepared pcibios_enable_irq, so
it won't affect Xen. The second patch fixes the IOAPIC pin reference
count leakage issue. It also solves the issue we have discussed at
http://www.spinics.net/lists/linux-pci/msg32902.html

Regards!
Gerry

Jiang Liu (2):
  x86, irq, PCI: Keep IRQ assignment for PCI devices during
suspend/hibernation
  x86, irq: Keep balance of IOAPIC pin reference count

 arch/x86/pci/intel_mid_pci.c |9 -
 arch/x86/pci/irq.c   |8 +++-
 drivers/acpi/pci_irq.c   |   15 +--
 include/linux/pci.h  |1 +
 4 files changed, 29 insertions(+), 4 deletions(-)

-- 
1.7.10.4

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

Re: [PATCH v2 18/18] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-5 4:48, Randy Dunlap wrote:
> On 08/04/14 08:28, Hanjun Guo wrote:
>> From: Graeme Gregory 
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
>>
>> Signed-off-by: Graeme Gregory 
>> Signed-off-by: Hanjun Guo 
>> ---
>>  Documentation/arm64/arm-acpi.txt |  215 
>> ++
>>  1 file changed, 215 insertions(+)
>>  create mode 100644 Documentation/arm64/arm-acpi.txt
>>
>> diff --git a/Documentation/arm64/arm-acpi.txt 
>> b/Documentation/arm64/arm-acpi.txt
>> new file mode 100644
>> index 000..a6e14a2
>> --- /dev/null
>> +++ b/Documentation/arm64/arm-acpi.txt
>> @@ -0,0 +1,215 @@
>> +ACPI on ARMv8 Servers
>> +-
>> +
> 
> ...
> 
>> +
>> +ACPI Detection
>> +--
>> +
>> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>> +or .of_node, or other information in the device structure. This is
>> +detailed further in the "Driver Recommendations" section.
>> +
>> +In non-driver code If the presence of ACPI needs to be detected at runtime,
>> +then check the value of acpi_disabled. If CONFIG_ACPI not being set,
> 
>   If CONFIG_ACPI is not set,

Good catch, We will update it.

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [Linaro-acpi] [PATCH v2 00/18] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

On 2014-8-5 1:30, Alexander Spyridakis wrote:
> On 4 August 2014 17:28, Hanjun Guo  > wrote:
>>
>> ACPI 5.1 has been released and now be freely available for
>> download [1]. It fixed some major gaps to run ACPI on ARM,
>> this patch just follow the ACPI 5.1 spec and prepare the
>> code to run ACPI on ARM64.
> 
> Hello,

Hi,

> 
> Is this work still reproducible on Foundation and/or ARMv8 FVP models, as
> described in the following wiki page?
> https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI

Yes, I think so. If you meet any problem , please let us know, and we will
update the wiki.

> 
> Should I assume that UEFI is mandatory (alternative being the aarch64
> bootwrapper), as described in Documentation/arm64/arm-acpi.txt?

Yes, UEFI is mandatory if you want to use ACPI.

> 
> Thanks in advance.

You are welcome :)

Thanks
Hanjun

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

Re: [PATCH] arch/sparc/math-emu/math_32.c: drop stray break operator

[David Miller]

From: Andrey Utkin 
Date: Mon,  4 Aug 2014 23:47:41 +0300

> This commit is a guesswork, but it seems to make sense to drop this
> break, as otherwise the following line is never executed and becomes
> dead code. And that following line actually saves the result of
> local calculation by the pointer given in function argument. So the
> proposed change makes sense if this code in the whole makes sense (but I
> am unable to analyze it in the whole).
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81641
> Reported-by: David Binderman 
> Signed-off-by: Andrey Utkin 

Yeah, not putting the condition code result into the register might
cause problems :-)

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

Re: [GIT PULL] hwmon updates for 3.17

[Stephen Rothwell]

Hi Guenter,

On Mon, 4 Aug 2014 19:22:09 -0700 Guenter Roeck  wrote:
>
> Hi Linus,
> 
> Please pull hwmon updates for Linux 3.17 from signed tag:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
> hwmon-for-linus

This branch was rewritten (but not rebased) to add 5 commits at its
start and 8 commits at its end since yesterday's linux-next.

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


signature.asc
Description: PGP signature

[GIT PULL] ext4 bug updates for 3.17

[Theodore Ts'o]

The following changes since commit 1795cd9b3a91d4b5473c97f491d63892442212ab:

  Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_linus

for you to fetch changes up to 86f0afd463215fc3e58020493482faa4ac3a4d69:

  ext4: fix ext4_discard_allocated_blocks() if we can't allocate the pa struct 
(2014-07-30 22:17:17 -0400)


Bug fixes and clean ups for the 3.17 merge window


Darrick J. Wong (1):
  ext4: check inline directory before converting

Dmitry Monakhov (3):
  ext4: add i_data_sem sanity check
  ext4: use correct depth value
  ext4: fix incorrect locking in move_extent_per_page

Lukas Czerner (1):
  ext4: fix punch hole on files with indirect mapping

Namjae Jeon (1):
  ext4: fix COLLAPSE RANGE test for bigalloc file systems

Theodore Ts'o (3):
  ext4: rearrange initialization to fix EXT4FS_DEBUG
  ext4: remove metadata reservation checks
  ext4: fix ext4_discard_allocated_blocks() if we can't allocate the pa 
struct

Xiaoguang Wang (1):
  ext4: fix wrong size computation in ext4_mb_normalize_request()

Zhang Zhen (1):
  ext4: remove readpage() check in ext4_mmap_file()

Zheng Liu (1):
  ext4: make ext4_has_inline_data() as a inline function

 fs/ext4/balloc.c  |   1 -
 fs/ext4/dir.c |  25 ++
 fs/ext4/ext4.h|  14 +++-
 fs/ext4/extents.c |  14 ++--
 fs/ext4/file.c|   4 -
 fs/ext4/indirect.c| 281 
+++--
 fs/ext4/inline.c  |  18 +++--
 fs/ext4/inode.c   | 130 ++
 fs/ext4/mballoc.c |  41 ++
 fs/ext4/migrate.c |   7 ++
 fs/ext4/move_extent.c |   3 +-
 fs/ext4/super.c   |  88 +
 12 files changed, 333 insertions(+), 293 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/

linux-next: build failures after merge of the drm tree

[Stephen Rothwell]

Hi Dave,

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

ERROR: "drm_sysfs_connector_remove" [drivers/gpu/drm/i2c/tda998x.ko] undefined!
ERROR: "drm_sysfs_connector_add" [drivers/gpu/drm/i2c/tda998x.ko] undefined!

Caused by commit c707c3619ca8 ("drm/i2c: tda998x: add component
support") interacting with commit 34ea3d386347 ("drm: add register and
unregister functions for connectors").  Maybe it should have been fixed
up in the merge commit 920f946428b7 ("Merge branch 'tda998x-devel' of
git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next")?

I reverted commit c707c3619ca8 for today.

But then the arm multi_v7_defconfig build produced these errors:

ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [arch/arm/boot/dts/exynos5420-arndale-octa.dtb] Error 2
make[2]: *** Waiting for unfinished jobs
ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

ERROR: Input tree has errors, aborting (use -f to force output)
make[2]: *** [arch/arm/boot/dts/exynos5420-smdk5420.dtb] Error 2
ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

ERROR: Input tree has errors, aborting (use -f to force output)
ERROR (phandle_references): Reference to non-existent node or label "disp_pd"

make[2]: *** [arch/arm/boot/dts/exynos5800-peach-pi.dtb] Error 2
ERROR: Input tree has errors, aborting (use -f to force output)

Caused by commit 5a8da524049c ("ARM: dts: exynos5420: add dsi node")
interacting with commit d51cad7df871 ("ARM: dts: remove display power
domain for exynos5420") from the arm-soc tree.

I applied this merge fix patch:

From: Stephen Rothwell 
Date: Tue, 5 Aug 2014 13:03:01 +1000
Subject: [PATCH] ARM: dts: exynos5420: remove disp_pd

per comit d51cad7df871 ("ARM: dts: remove display power
domain for exynos5420").

Signed-off-by: Stephen Rothwell 
---
 arch/arm/boot/dts/exynos5420.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 95ec37dff3e8..bfe056d9148c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -525,7 +525,6 @@
compatible = "samsung,exynos5410-mipi-dsi";
reg = <0x1450 0x1>;
interrupts = <0 82 0>;
-   samsung,power-domain = <&disp_pd>;
phys = <&mipi_phy 1>;
phy-names = "dsim";
clocks = <&clock CLK_DSIM1>, <&clock CLK_SCLK_MIPI1>;
-- 
2.0.1

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


signature.asc
Description: PGP signature

Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function

[Brian Norris]

On Tue, Aug 05, 2014 at 01:54:07AM +, bpqw wrote:
> From 0304e9618d8c3ef5360b611f881f1b1bed08be06 Mon Sep 17 00:00:00 2001
> From: White Ding 
> Date: Thu, 24 Jul 2014 00:10:45 +0800
> Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
> 
> Do nand reset before write protect check.
> 
> If we want to check the WP# low or high through STATUS READ and check bit 7,
> we must reset the device, other operation (eg.erase/program a locked block) 
> can
> also clear the bit 7 of status register.
> 
> As we know the status register can be refreshed, if we do some operation to 
> trigger it,
> for example if we do erase/program operation to one block that is locked, 
> then READ STATUS,
> the bit 7 of READ STATUS will be 0 indicate the device in write protect, then 
> if we do
> erase/program operation to another block that is unlocked, the bit 7 of READ 
> STATUS will
> be 1 indicate the device is not write protect.
> Suppose we checked the bit 7 of READ STATUS is 0 then judge the WP# is low 
> (write protect),
> but in this case the WP# maybe high if we do erase/program operation to a 
> locked block, 
> so we must reset the device if we want to check the WP# low or high through 
> STATUS READ and 
> check bit 7.
> 
> Signed-off-by: White Ding 

Thanks. Queued to l2-mtd.git/next.

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] netlink: Convert netlink_lookup() to use RCU protected hash table

[David Miller]

From: Sasha Levin 
Date: Mon, 04 Aug 2014 22:10:19 -0400

> On 08/02/2014 05:47 AM, Thomas Graf wrote:
>>  static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
>> -__acquires(nl_table_lock)
>>  {
>> -read_lock(&nl_table_lock);
>> +rcu_read_lock();
>>  return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
>>  }
> 
> I'm not sure how you expect this code to work. You're replacing a local lock
> with a RCU critical section. Imagine you're doing spin_lock() and just going
> back to userspace.
> 
> It's quite easy to trigger this issue:

I think he expected the end of the seq sequence to drop the RCU lock,
via netlink_seq_stop().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] softlockup: make detector be aware of task switch of processes hogging cpu

[Chai Wen]

On 08/04/2014 10:31 PM, Don Zickus wrote:

> On Mon, Aug 04, 2014 at 03:36:19PM +0800, chai wen wrote:
>>
>> For now, soft lockup detector warns once for each case of process softlockup.
>> But the thread 'watchdog/n' may can not always get cpu at the time slot 
>> between
>> the task switch of two processes hogging that cpu.
>> This case is a false negative of "warn only once for a process", as there 
>> may be
>> a different process that is going to hog the cpu. Is is better for detector 
>> to
>> be aware of it. 
> 
> I am not sure I fully understand the problem resolved.
> 
>>From the changelog I understood that two processes bouncing back and forth
> could hog the cpu and could create a 'false negative' (a situation not
> reported but should).


Hi Don

Thanks for your comment.
Perhaps 'task-switch' is wrong and is some misleading here, sorry for that.

Here I mean the very case that between a termination of an old cpu hogging
process and a starting getting cpu of a new process hogging cpu.
The case that two or more processes bouncing back and forth and the thread 
'watchdog/n'
getting no chance to run is rather difficult to be supposed. And I think this 
situation
does not exist.

When I am reading the code of warning once about a case, I think maybe it is
not so reliable by judging a "soft_watchdog_warn". And I tried a simple test to 
see
if it could handle the cased I mentioned above. Please see the comment and 
detail of
the test below.

> 
> But looking at the patch below I was a little confused on the
> __touch_watchdog addition.  See below:
> 
>>
>> Signed-off-by: chai wen 
>> ---
>>  kernel/watchdog.c |   18 --
>>  1 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/watchdog.c b/kernel/watchdog.c
>> index 4c2e11c..908050c 100644
>> --- a/kernel/watchdog.c
>> +++ b/kernel/watchdog.c
>> @@ -42,6 +42,7 @@ static DEFINE_PER_CPU(bool, softlockup_touch_sync);
>>  static DEFINE_PER_CPU(bool, soft_watchdog_warn);
>>  static DEFINE_PER_CPU(unsigned long, hrtimer_interrupts);
>>  static DEFINE_PER_CPU(unsigned long, soft_lockup_hrtimer_cnt);
>> +static DEFINE_PER_CPU(pid_t, softlockup_warn_pid_saved);
>>  #ifdef CONFIG_HARDLOCKUP_DETECTOR
>>  static DEFINE_PER_CPU(bool, hard_watchdog_warn);
>>  static DEFINE_PER_CPU(bool, watchdog_nmi_touch);
>> @@ -317,6 +318,8 @@ static enum hrtimer_restart watchdog_timer_fn(struct 
>> hrtimer *hrtimer)
>>   */
>>  duration = is_softlockup(touch_ts);
>>  if (unlikely(duration)) {
>> +pid_t pid = task_pid_nr(current);
>> +
>>  /*
>>   * If a virtual machine is stopped by the host it can look to
>>   * the watchdog like a soft lockup, check to see if the host
>> @@ -326,8 +329,18 @@ static enum hrtimer_restart watchdog_timer_fn(struct 
>> hrtimer *hrtimer)
>>  return HRTIMER_RESTART;
>>  
>>  /* only warn once */
>> -if (__this_cpu_read(soft_watchdog_warn) == true)
>> +if (__this_cpu_read(soft_watchdog_warn) == true) {
>> +/*
>> + * soft lockup detector should be aware of that there
>> + * may be a task-swicth of two different processes
>> + * hogging the cpu continously
>> + */
>> +if (__this_cpu_read(softlockup_warn_pid_saved) != pid) {
>> +__this_cpu_write(soft_watchdog_warn, false);
>> +__touch_watchdog();
>> +}
> 
> The above piece is what I am trying to understand.  Are you saying that
> when two different processes are hogging the cpu, undo the
> soft_watchdog_warn and allow the second pid to be reported?
> 


Yes, Indeed.

> Just trying to understand the problem and see if this is the right
> approach (because 3 or more processes could cause the same problem???).
> 


Only 2 processes is involved in this case as mentioned above, and it is a case 
about
a termination of an old process and a starting of a new process.

Here is my test about the case:

stuck.c:
#include 
#include 

int main(int argc, char **argv)
{
while(1);
exit(0);
}

# gcc -o stuck stuck.c
# ./stuck &
[1] 30309
# ./stuck &
[2] 30310
# taskset -pc 3 30309
pid 30309's current affinity list: 0-3
pid 30309's new affinity list: 3
# taskset -pc 3 30310
pid 30310's current affinity list: 0-3
pid 30310's new affinity list: 3

Then change the schedule policy of 30309 and 30310 to be SCHED_FIFO 
with the MAX_RT_PRIO-1 priority.
As the firstly changed to SCHED_FIFO process hogging cpu#3, and is 
reported after about ~20s.
After it is killed or terminated, the process 30310 is going out and 
keeping hogging the cpu continuously
But this process can not be always rep

[RFC PATCH 3/3] ftracetest: Add kprobe basic testcases

[Masami Hiramatsu]

Add basic testcases for kprobe dynamic events.
This also shows that the ftracetest accepts sub-directory
for new testcases.

Signed-off-by: Masami Hiramatsu 
---
 .../testing/ftrace/test.d/kprobe/add_and_remove.tc |   11 +++
 tools/testing/ftrace/test.d/kprobe/busy_check.tc   |   14 ++
 2 files changed, 25 insertions(+)
 create mode 100644 tools/testing/ftrace/test.d/kprobe/add_and_remove.tc
 create mode 100644 tools/testing/ftrace/test.d/kprobe/busy_check.tc

diff --git a/tools/testing/ftrace/test.d/kprobe/add_and_remove.tc 
b/tools/testing/ftrace/test.d/kprobe/add_and_remove.tc
new file mode 100644
index 000..8e02257
--- /dev/null
+++ b/tools/testing/ftrace/test.d/kprobe/add_and_remove.tc
@@ -0,0 +1,11 @@
+#!/bin/bash
+# description: Kprobe dynamic event - adding and removing
+
+[ -f kprobe_events ] || exit 1
+
+echo 0 > events/enable || exit 1
+echo > kprobe_events || exit 1
+echo p:myevent do_fork > kprobe_events || exit 1
+grep myevent kprobe_events || exit 1
+[ -d events/kprobes/myevent ] || exit 1
+echo > kprobe_events
diff --git a/tools/testing/ftrace/test.d/kprobe/busy_check.tc 
b/tools/testing/ftrace/test.d/kprobe/busy_check.tc
new file mode 100644
index 000..57a8a2c
--- /dev/null
+++ b/tools/testing/ftrace/test.d/kprobe/busy_check.tc
@@ -0,0 +1,14 @@
+#!/bin/bash
+# description: Kprobe dynamic event - busy event check
+
+[ -f kprobe_events ] || exit 1
+
+echo 0 > events/enable || exit 1
+echo > kprobe_events || exit 1
+echo p:myevent do_fork > kprobe_events || exit 1
+[ -d events/kprobes/myevent ] || exit 1
+echo 1 > events/kprobes/myevent/enable || exit 1
+echo > kprobe_events && exit 1 # this must fail
+echo 0 > events/kprobes/myevent/enable || exit 1
+echo > kprobe_events # this must succeed
+


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 2/3] ftracetest: Add ftrace basic testcases

[Masami Hiramatsu]

Add ftrace basic testcases. This just checks ftrace debugfs
interface works as it is designed.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/ftrace/test.d/basic1.tc |3 +++
 tools/testing/ftrace/test.d/basic2.tc |6 ++
 tools/testing/ftrace/test.d/basic3.tc |8 
 3 files changed, 17 insertions(+)
 create mode 100644 tools/testing/ftrace/test.d/basic1.tc
 create mode 100644 tools/testing/ftrace/test.d/basic2.tc
 create mode 100644 tools/testing/ftrace/test.d/basic3.tc

diff --git a/tools/testing/ftrace/test.d/basic1.tc 
b/tools/testing/ftrace/test.d/basic1.tc
new file mode 100644
index 000..275bd71
--- /dev/null
+++ b/tools/testing/ftrace/test.d/basic1.tc
@@ -0,0 +1,3 @@
+#!/bin/bash
+# description: Basic trace file check
+test -f README -a -f trace -a -f tracing_on -a -f trace_pipe
diff --git a/tools/testing/ftrace/test.d/basic2.tc 
b/tools/testing/ftrace/test.d/basic2.tc
new file mode 100644
index 000..5849922
--- /dev/null
+++ b/tools/testing/ftrace/test.d/basic2.tc
@@ -0,0 +1,6 @@
+#!/bin/bash
+# description: Basic test for tracers
+for t in `cat available_tracers`; do
+  echo $t > current_tracer || exit 1
+done
+echo nop > current_tracer
diff --git a/tools/testing/ftrace/test.d/basic3.tc 
b/tools/testing/ftrace/test.d/basic3.tc
new file mode 100644
index 000..0b9cb2c
--- /dev/null
+++ b/tools/testing/ftrace/test.d/basic3.tc
@@ -0,0 +1,8 @@
+#!/bin/bash
+# description: Basic trace clock test
+[ -f trace_clock ] || exit 1
+for c in `cat trace_clock | tr  -d \[\]`; do
+  echo $c > trace_clock || exit 1
+  grep '\['$c'\]' trace_clock || exit 1
+done
+echo local > trace_clock


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 1/3] ftracetest: Initial commit for ftracetest

[Masami Hiramatsu]

ftracetest is a collection of testcase shell-scripts for ftrace.
To avoid regressions of ftrace, these testcases check correct
ftrace behaviors. If someone would like to add any features on
ftrace, the patch series should have at least one testcase for
checking the new behavior.

Signed-off-by: Masami Hiramatsu 
---
 tools/testing/ftrace/README  |   38 ++
 tools/testing/ftrace/ftracetest  |  133 ++
 tools/testing/ftrace/test.d/template |4 +
 3 files changed, 175 insertions(+)
 create mode 100644 tools/testing/ftrace/README
 create mode 100755 tools/testing/ftrace/ftracetest
 create mode 100644 tools/testing/ftrace/test.d/template

diff --git a/tools/testing/ftrace/README b/tools/testing/ftrace/README
new file mode 100644
index 000..16de781
--- /dev/null
+++ b/tools/testing/ftrace/README
@@ -0,0 +1,38 @@
+Linux Ftrace Testcases
+
+This is a collection of testcases for ftrace tracing feature in the Linux
+kernel. Since ftrace exports interfaces via the debugfs, we just need
+shell scripts for testing. Feel free to add new test cases.
+
+Running the ftrace testcases
+
+
+At first, you need to be the root user to run this script.
+To run all testcases:
+
+  $ sudo ./ftracetest
+
+To run specific testcases:
+
+  # ./ftracetest test.d/basic3.tc
+
+Contributing new testcases
+==
+
+Copy test.d/template to your testcase (whose filename must has *.tc extension)
+and rewrite test description line.
+
+ * The working directory of the script is /tracing/.
+
+ * Take care about the side effect, because that is run with root privilege.
+
+ * Don't take too long. It's a kind of unit test.
+
+ * You can add a directory for your testcases under test.d/ if needed.
+
+TODO
+
+
+ * Fancy colored output :)
+
+ * Integrate with selftest?
diff --git a/tools/testing/ftrace/ftracetest b/tools/testing/ftrace/ftracetest
new file mode 100755
index 000..5a7c9f8
--- /dev/null
+++ b/tools/testing/ftrace/ftracetest
@@ -0,0 +1,133 @@
+#!/bin/bash
+# ftracetest - Ftrace test shell scripts
+# Written by Masami Hiramatsu 
+
+usage() { # errno [message]
+[ "$2" ] && echo $2
+echo "Usage: ftracetest [options] [testcase(s)]"
+echo " Options:"
+echo " -h|--help  Show help message"
+echo " -k|--keep  Keep passed test logs"
+echo " -d|--debug Debug mode (trace all shell commands)"
+exit $1
+}
+
+# Utilities
+absdir() { # file_path
+  (cd `dirname $1`; pwd)
+}
+
+errexit() { # message
+  echo "Error: $1" 1>&2
+  exit 1
+}
+
+# Ensuring user privilege
+if [ `id -u` -ne 0 ]; then
+  errexit "this must be run by root user"
+fi
+
+parse_opts() { # opts
+  OPT_TEST_CASES=
+  while [ "$1" ]; do
+case "$1" in
+--help|-h)
+  usage 0
+;;
+--keep|-k)
+  KEEP_LOG=1
+  shift 1
+;;
+--debug|-d)
+  DEBUG=1
+  shift 1
+;;
+*)
+  if [ -f "$1" ]; then
+OPT_TEST_CASES="$OPT_TEST_CASES `absdir $1`/`basename $1`"
+shift 1
+  else
+usage 1 "Invalid option ($1)"
+  fi
+;;
+esac
+  done
+  if [ "$OPT_TEST_CASES" ]; then
+TEST_CASES=$OPT_TEST_CASES
+  fi
+}
+
+# Parameters
+DEBUGFS_DIR=`grep debugfs /proc/mounts | cut -f2 -d' '`
+TRACING_DIR=$DEBUGFS_DIR/tracing
+TOP_DIR=`absdir $0`
+TEST_DIR=$TOP_DIR/test.d
+TEST_CASES=`find $TEST_DIR -name *.tc`
+LOG_DIR=$TOP_DIR/logs/`date +%Y%m%d-%H%M%S`/
+KEEP_LOG=0
+DEBUG=0
+# Parse command-line options
+parse_opts $*
+
+[ $DEBUG -ne 0 ] && set -x
+
+# Verify parameters
+if [ -z "$DEBUGFS_DIR" -o ! -d "$TRACING_DIR" ]; then
+  errexit "No ftrace directory found"
+fi
+
+# Preparing logs
+LOG_FILE=$LOG_DIR/ftracetest.log
+mkdir -p $LOG_DIR || errexit "Failed to make a log directory: $LOG_DIR"
+date > $LOG_FILE
+prlog() { # messages
+  echo $@ | tee -a $LOG_FILE
+}
+catlog() { #file
+  cat $1 | tee -a $LOG_FILE
+}
+
+# Testcase management
+PASSED_CASES=
+FAILED_CASES=
+CASENO=0
+testcase() { # testfile
+  CASENO=$((CASENO+1))
+  prlog -n "[$CASENO]"`grep "^#[ \t]*description:" $1 | cut -f2 -d:`
+}
+failed() {
+  prlog -e "\t[FAILED]"
+  FAILED_CASES="$FAILED_CASES $CASENO"
+}
+passed() {
+  prlog -e "\t[PASSED]"
+  PASSED_CASES="$PASSED_CASES $CASENO"
+}
+
+
+# Run one test case
+function run_test() { # testfile
+  local testname=`basename $1`
+  local testlog=`mktemp --tmpdir=$LOG_DIR ${testname}-XX.log`
+  testcase $1
+  echo "execute: "$1 > $testlog
+  (cd $TRACING_DIR; set -x ; source $t) >> $testlog 2>&1
+  ret=$?
+  if [ $ret -ne 0 ]; then
+failed
+catlog $testlog
+  else
+passed
+[ $KEEP_LOG -eq 0 ] && rm $testlog
+  fi
+}
+
+# Main loop
+for t in $TEST_CASES; do
+  run_test $t
+done
+prlog ""
+prlog "Passed: " `echo $PASSED_CASES | wc -w`
+prlog "Failed: " `echo $FAILED_CASES | wc -w`
+
+test -z "$FAILED_CASES" # if no error, return 0
diff --git a/tools/testing/ftrace/test.d/template 
b/tools/testing/ftrace/test.d/template
new file mode 100644
index 000..e855b65
---

[RFC PATCH 0/3] ftrace: Add a ftrace test collection

[Masami Hiramatsu]

Hi,

I'd like to introduce a collection of testcases for ftrace to
avoid regressions.

For a long time, we've tried to stabilize and extend ftrace
tracing infrastructure. This small test framework is a kind of
stabilizing work for ftrace. For the first step, this series
just introduces a few basic testcases. However, it is easy to
add additional tests. I'd like to ask you, ftrace developers,
to add tests for your features to ensure it will not be broken
by future works.

ftracetest is a tiny bash script so that anyone can easily
understand what it does. I think it is better to share and
discuss this tests before growing it.

 - Is it enough to support bash script? (of course you can
   invoke other commands from the script)
 - What's the good naming method of testcases?
 - Is any dependency check required?

BTW, I decided to put this under tools/testing/ftrace instead
of tools/testing/selftests/, because all tests requires root
privilege. It will be one of discussion points. Anyway,
it is easy to integrate this to the selftests.

Thank you,

---

Masami Hiramatsu (3):
  ftracetest: Initial commit for ftracetest
  ftracetest: Add ftrace basic testcases
  ftracetest: Add kprobe basic testcases


 tools/testing/ftrace/README|   38 ++
 tools/testing/ftrace/ftracetest|  133 
 tools/testing/ftrace/test.d/basic1.tc  |3 
 tools/testing/ftrace/test.d/basic2.tc  |6 +
 tools/testing/ftrace/test.d/basic3.tc  |8 +
 .../testing/ftrace/test.d/kprobe/add_and_remove.tc |   11 ++
 tools/testing/ftrace/test.d/kprobe/busy_check.tc   |   14 ++
 tools/testing/ftrace/test.d/template   |4 +
 8 files changed, 217 insertions(+)
 create mode 100644 tools/testing/ftrace/README
 create mode 100755 tools/testing/ftrace/ftracetest
 create mode 100644 tools/testing/ftrace/test.d/basic1.tc
 create mode 100644 tools/testing/ftrace/test.d/basic2.tc
 create mode 100644 tools/testing/ftrace/test.d/basic3.tc
 create mode 100644 tools/testing/ftrace/test.d/kprobe/add_and_remove.tc
 create mode 100644 tools/testing/ftrace/test.d/kprobe/busy_check.tc
 create mode 100644 tools/testing/ftrace/test.d/template

--

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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.16-rcX crashes on resume from Suspend-To-RAM

[Zhang Rui]

Hi, Markus,

On Mon, 2014-08-04 at 09:06 -0700, Markus Gutschke wrote:
> Thanks for checking in. And no, I have not heard from Zhang since my
> last e-mail. I suspect he is still working on finding a solution.

Yes, I was trying to find out what differences commit
b04c58b1ed26317bfb4b33d3a2d16377fc6acd0f brings, and why it breaks
suspend. But so far, I didn't make any progress. Thus I do need your
help to do more test.

>  But
> you are of course right, reverting the patch in the meantime might be
> a good idea. I would love to be able to suspend my laptop again. But I
> defer to Zhang for the final decision. As long as it gets fixed
> eventually, I can personally live with a few weeks of delay while
> things get worked out. And of course, as offered before, I'll run
> whatever tests Zhang asks me to do.
> 
Great. Thanks for your help, please
1. make sure your kernel is built with CONFIG_PM_DEBUG and
CONFIG_PM_TRACE_RTC set.
2. in b04c58b1ed26317bfb4b33d3a2d16377fc6acd0f kernel, try "echo devices
> /sys/power/pm_test && echo mem > /sys/power/states", and wait for 10
seconds and see if the system can be resumed automatically.
3. if the test fails, please try a normal suspend, and reboot the kernel
ASAP after the hang, better in one minute, and then attach the dmesg
output after boot. Hopefully, we can find out which driver breaks your
machine by the suspend/resume trace feature. 

thanks,
rui

> Markus
> 
> On Mon, Aug 4, 2014 at 7:16 AM, Pavel Machek  wrote:
> > On Sat 2014-07-26 08:52:34, Markus Gutschke wrote:
> >> Sorry for the delay. Remotely debugging kernels over a shared and
> >> flaky 1MBps terrestrial wireless connection is quite a new experience
> >> to me.
> >>
> >> In any case, I was able to collect all the data that you asked for. I
> >> then used "pm-suspend" to put the machine to sleep and asked a helper
> >> to physically press the power button to wake the computer back up. My
> >> helper told me that it crashed just as before, and they had to
> >> power-cycle the machine to bring it back to life.
> >>
> >> Please let me know, what other data I can get for you. And thank you
> >> very much for putting up with my slow turn-around. I should have much
> >> better response time again in about two to three weeks when I return
> >> to civilization.
> >
> > Was this solved, somehow?
> >
> > If not, can we revert the patch that causes it?
> > Pavel
> >
> > --
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) 
> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

[GIT PULL] hwmon updates for 3.17

[Guenter Roeck]

Hi Linus,

Please pull hwmon updates for Linux 3.17 from signed tag:

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

Thanks,
Guenter
--

The following changes since commit 64aa90f26c06e1cb2aacfb98a7d0eccfbd6c1a91:

  Linux 3.16-rc7 (2014-07-27 12:41:55 -0700)

are available in the git repository at:

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

for you to fetch changes up to fce9626cd93abaf1ef21b361f8a0fa493cc855b2:

  hwmon: (g762) Use of_property_read_u32 at appropriate place (2014-08-04 
11:35:40 -0700)


Notable changes:

Heiko Schocher provided a driver for TI TMP103.
Kamil Debski provided a driver for pwm-controlled fans.
Neelesh Gupta provided a driver for power, fan rpm, voltage and temperature
reporting on powerpc/powernv systems.
Scott Kanowitz provided a driver supporting Lattice's POWR1220 power manager IC.
Richard Zhu provided a pmbus front-end driver for TPS40422.
Frans Klaver added support for TMP112 to the lm75 driver.
Johannes Pointner added support for EPCOS B57330V2103 to the ntc_thermistor
driver.
Guenter Roeck added support for TMP441 and TMP442 to the tmp421 driver.
Axel Lin converted several drivers to the new hwmon API (36 of them, if I
counted correctly), and cleaned up many of the drivers along the way.

There are also a number of patches fixing bugs discovered while testing
Axel's changes.


Aravind Gopalakrishnan (1):
  hwmon: (fam15h_power) Remove needless pci dev id

Axel Lin (72):
  hwmon: (ads1015) Fix off-by-one for valid channel index checking
  hwmon: (amc6821) Fix possible race condition bug
  hwmon: (lm77) Prevent overflow problem when writing large limits
  hwmon: (twl4030-madc-hwmon) Convert to 
devm_hwmon_device_register_with_groups
  hwmon: (gpio-fan) Convert to devm_hwmon_device_register_with_groups
  hwmon: (atxp1) Convert to devm_hwmon_device_register_with_groups
  hwmon: (ads7828) Convert to devm_hwmon_device_register_with_groups
  hwmon: (wm831x) Convert to devm_hwmon_device_register_with_groups
  hwmon: (wm8350) Convert to devm_hwmon_device_register_with_groups
  hwmon: (fam15h_power) Convert to devm_hwmon_device_register_with_groups
  hwmon: (w83l786ng) Avoid forward declaration
  hwmon: (w83l786ng) Convert to devm_hwmon_device_register_with_groups
  hwmon: (tmp103) Add missing i2c_set_clientdata call in tmp103_probe
  hwmon: (hih6130) Convert to devm_hwmon_device_register_with_groups
  hwmon: (ad7414) Convert to devm_hwmon_device_register_with_groups
  hwmon: (ad7418) Avoid forward declaration
  hwmon: (ad7418) Convert to devm_hwmon_device_register_with_groups
  hwmon: (adm1029) Avoid forward declarations
  hwmon: (adm1029) Convert to devm_hwmon_device_register_with_groups
  hwmon: (amc6821) Avoid forward declaration
  hwmon: (amc6821) Convert to devm_hwmon_device_register_with_groups
  hwmon: (emc6w201) Convert to devm_hwmon_device_register_with_groups
  hwmon: (htu21) Convert to devm_hwmon_device_register_with_groups
  hwmon: Make regmap configs const
  hwmon: (lm93) Convert to devm_hwmon_device_register_with_groups
  hwmon: (gl518sm) Avoid forward declaration
  hwmon: (gl518sm) Convert to devm_hwmon_device_register_with_groups
  hwmon: (gl520sm) Avoid forward declaration
  hwmon: (gl520sm) Convert to devm_hwmon_device_register_with_groups
  hwmon: (adm1021) Avoid forward declaration
  hwmon: (adm1025) Avoid forward declaration
  hwmon: (adm1025) Convert to devm_hwmon_device_register_with_groups
  hwmon: (adm1026) Avoid forward declaration
  hwmon: (adm1026) Convert to devm_hwmon_device_register_with_groups
  hwmon: (adm1031) Avoid forward declaration
  hwmon: (adm1031) Convert to devm_hwmon_device_register_with_groups
  hwmon: (adm9240) Avoid forward declaration
  hwmon: (smm665) Convert to devm_hwmon_device_register_with_groups
  hwmon: (lineage-pem) Convert to devm_hwmon_device_register_with_groups
  hwmon: (adm9240) Convert to devm_hwmon_device_register_with_groups
  hwmon: (g760a) Avoid forward declaration
  hwmon: (g760a) Convert to devm_hwmon_device_register_with_groups
  hwmon: (sht21) Convert to devm_hwmon_device_register_with_groups
  hwmon: (max16065) Use PTR_ERR_OR_ZERO
  hwmon: (ds620) Convert to devm_hwmon_device_register_with_groups
  hwmon: (asc7621) Make map tables const
  hwmon: (adt7462) Avoid forward declaration
  hwmon: (adt7462) Convert to devm_hwmon_device_register_with_groups
  hwmon: (adt7470) Avoid forward declaration
  hwmon: (adt7470) Convert to devm_hwmon_device_register_with_groups
  hwmon: (thmc50) Avoid forward declaration
  hwmon: (thmc50) Convert to devm_hwmon_device

Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device

[Yijing Wang]

On 2014/8/4 22:45, Arnd Bergmann wrote:
> On Monday 04 August 2014, Yijing Wang wrote:
>> I have another question is some drivers will request more than one
>> MSI/MSI-X IRQ, and the driver will use them to process different things.
>> Eg. network driver generally uses one of them to process trivial network 
>> thins,
>> and others to transmit/receive data.
>>
>> So, in this case, it seems to driver need to touch the IRQ numbers.
>>
>> wr-linux:~ # cat /proc/interrupts
>> CPU0   CPU1   CPU2   CPU17  CPU18  
>> CPU19  CPU20  CPU21  CPU22  CPU23
>>  ..
>>  100:  0  0  0   0  0  0 
>>  0  0  0  0  IR-PCI-MSI-edge  eth0
>>  101:  2  0  0   0  0  0 
>>  302830488  0  0  0  IR-PCI-MSI-edge  eth0-TxRx-0
>>  102:110  0  0   0  0  360675897 
>>  0  0  0  0  IR-PCI-MSI-edge  eth0-TxRx-1
>>  103:109  0  0   0  0  0 
>>  0  0  0  0  IR-PCI-MSI-edge  eth0-TxRx-2
>>  104:107  0  0 9678933  0  0 
>>  0  0  0  0  IR-PCI-MSI-edge  eth0-TxRx-3
>>  105:107  0  0   0  357838258  0 
>>  0  0  0  0  IR-PCI-MSI-edge  eth0-TxRx-4
>>  106:115  0  0   0  0  0 
>>  0  0  0  0  IR-PCI-MSI-edge  eth0-TxRx-5
>>  107:114  0  0   0  0  0 
>>  0  337866096  0  0  IR-PCI-MSI-edge  eth0-TxRx-6
>>  108:  373801199  0  0   0  0  0 
>>  0  0  0  0  IR-PCI-MSI-edge  eth0-TxRx-7
>>
> 
> I think in this example, you just need to request eight interrupts, and pass a
> different data pointer each time, pointing to the napi_struct of each of the
> NIC queues. The driver has no need to deal with the IRQ number at all,
> and I would be surprised if it cared today.

Yes, you are right, this is not a stumbling block. :)

> 
>   Arnd
> 
> .
> 


-- 
Thanks!
Yijing

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

Re: [RFC][PATCH 4/7] inotify: Deal with nested sleeps

[Lai Jiangshan]

I don't think this one needs nested sleeps.

diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index cc423a3..1ca5888 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -233,15 +233,16 @@ static ssize_t inotify_read(struct file *file, char 
__user *buf,
group = file->private_data;
 
while (1) {
+   mutex_lock(&group->notification_mutex);
prepare_to_wait(&group->notification_waitq, &wait, 
TASK_INTERRUPTIBLE);
 
-   mutex_lock(&group->notification_mutex);
kevent = get_one_event(group, count);
mutex_unlock(&group->notification_mutex);
 
pr_debug("%s: group=%p kevent=%p\n", __func__, group, kevent);
 
if (kevent) {
+   __set_current_state(TASK_RUNNING);
ret = PTR_ERR(kevent);
if (IS_ERR(kevent))
break;



On 08/04/2014 06:30 PM, Peter Zijlstra wrote:
> inotify_read is a wait loop with sleeps in. Wait loops rely on
> task_struct::state and sleeps do too, since that's the only means of
> actually sleeping. Therefore the nested sleeps destroy the wait loop
> state and the wait loop breaks the sleep functions that assume
> TASK_RUNNING (mutex_lock).
> 
> Fix this by using the new woken_wake_function and wait_woken() stuff,
> which registers wakeups in wait and thereby allows shrinking the
> task_state::state changes to the actual sleep part.
> 
> Cc: Eric Paris 
> Cc: John McCutchan 
> Cc: Robert Love 
> Signed-off-by: Peter Zijlstra 
> ---
>  fs/notify/inotify/inotify_user.c |9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> --- a/fs/notify/inotify/inotify_user.c
> +++ b/fs/notify/inotify/inotify_user.c
> @@ -227,14 +227,13 @@ static ssize_t inotify_read(struct file
>   struct fsnotify_event *kevent;
>   char __user *start;
>   int ret;
> - DEFINE_WAIT(wait);
> + DEFINE_WAIT_FUNC(wait, woken_wake_function);
>  
>   start = buf;
>   group = file->private_data;
>  
> + add_wait_queue(&group->notification_waitq, &wait);
>   while (1) {
> - prepare_to_wait(&group->notification_waitq, &wait, 
> TASK_INTERRUPTIBLE);
> -
>   mutex_lock(&group->notification_mutex);
>   kevent = get_one_event(group, count);
>   mutex_unlock(&group->notification_mutex);
> @@ -264,10 +263,10 @@ static ssize_t inotify_read(struct file
>   if (start != buf)
>   break;
>  
> - schedule();
> + wait_woken(&wait, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
>   }
> + remove_wait_queue(&group->notification_waitq, &wait);
>  
> - finish_wait(&group->notification_waitq, &wait);
>   if (start != buf && ret != -EFAULT)
>   ret = buf - start;
>   return ret;
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@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: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device

[Yijing Wang]

>>> The method you describe here makes sense for PCI devices that are required 
>>> to support
>>> legacy interrupts and may or may not support MSI on a given system, but not 
>>> so much
>>> for platform devices for which we know exactly whether we want to use MSI
>>> or legacy interrupts.
>>>
>>> In particular if you have a device that can only do MSI, the entire 
>>> pci_enable_msi
>>> step is pointless: all we need to do is program the correct MSI target 
>>> address/message
>>> pair into the device and register the handler.
>>
>> Yes, I almost agree if we won't change the existing hundreds of drivers, what
>> I worried about is some drivers may want to know the IRQ numbers, and use 
>> the IRQ
>> number to process different things, as I mentioned in another reply.
>> But we can also provide the interface which integrate MSI configuration and 
>> request_irq(),
>> if most drivers don't care the IRQ number.
> 
> The driver would still have the option of getting the IRQ number for now: With
> the interface I imagine, you would get a 'struct msi_desc' pointer, from which
> you can look up the 'struct irq_desc' pointer (either embedded in msi_desc,
> or using a pointer from a member of msi_desc), and you can already get the
> interrupt number from the irq_desc.
> 
> My point was that a well-written driver already does not care about the 
> interrupt
> number: the only information a driver needs in the interrupt handler is a 
> pointer
> to its own context, which we already derive from the irq_desc.

Agree, I will try to introduce this similar interface in next version, thanks!

> 
> The main interface that currently requires the irq number is free_irq(), but
> I would argue that we can just add a wrapper that takes the msi_desc pointer
> as its first argument so the driver does not have to worry about it.
> 
> We can add additional wrappers like that as needed.

OK

 This is a huge change for device drivers, and some device drivers don't 
 know which msi_chip
 their MSI irq deliver to. I'm reworking the msi_chip, and try to use 
 msi_chip to eliminate
 all arch_msi_xxx() under every arch in kernel. And the important point is 
 how to create the
 binding for the MSI device to the target msi_chip.
>>>
>>> Which drivers are you thinking of? Again, I wouldn't expect to change any 
>>> PCI drivers,
>>> but only platform drivers that do native MSI, so we only have to change 
>>> drivers that
>>> do not support any MSI at all yet and that need to be changed anyway in 
>>> order to add
>>> support.
>>
>> I mean platform device drivers, because we can find the target msi_chip by 
>> some platform
>> interfaces(like the existing of_pci_find_msi_chip_by_node()). So we no need 
>> to explicitly
>> provide the msi_chip as the function argument.
> 
> Right, that works too. I was thinking we might need an interface that allows 
> us to
> pick a particular msi_chip if there are several alternatives (e.g. one in the 
> GIC
> and one in the PCI host), but you are right: we should normally be able to 
> hardwire
> that information in DT or elsewhere, and just need the 'struct device 
> pointer' which
> should probably be the first argument here.
> 
> As you pointed out, it's common to have multiple MSIs for a single device, so 
> we
> also need a context to pass around, so my suggestion would become something 
> like:
> 
> struct msi_desc *msi_request(struct device *dev, irq_handler_t handler,
>   unsigned long flags, const char *name, void *data);
> 
> It's possible that we have to add one or two more arguments here.

Good suggestion, thanks!

> 
>>> A degenerate case of this would be a system where a PCI device sends its 
>>> MSI into
>>> the host controller, that generates a legacy interrupt and that in turn 
>>> gets 
>>> sent to an irqchip which turns it back into an MSI for the GICv3. This 
>>> would of
>>> course be very inefficient, but I think we should be able to express this 
>>> with
>>> both the binding and the in-kernel framework just to be on the safe side.
>>
>> Yes, the best way to tell the kernel which msi_chip should deliver to is 
>> describe
>> the binding in DTS file. If a real degenerate case found, we can update the 
>> platform
>> interface which is responsible for getting the match msi_chip in future.
> 
> Ok.
> 
>   Arnd
> 
> .
> 


-- 
Thanks!
Yijing

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

Re: [PATCH net-next 2/3] netlink: Convert netlink_lookup() to use RCU protected hash table

[Sasha Levin]

On 08/02/2014 05:47 AM, Thomas Graf wrote:
>  static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
> - __acquires(nl_table_lock)
>  {
> - read_lock(&nl_table_lock);
> + rcu_read_lock();
>   return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
>  }

I'm not sure how you expect this code to work. You're replacing a local lock
with a RCU critical section. Imagine you're doing spin_lock() and just going
back to userspace.

It's quite easy to trigger this issue:

[  531.479773] ===
[  531.482951] [ INFO: suspicious RCU usage. ]
[  531.485512] 3.16.0-next-20140804-sasha-00029-gcb12d07 #995 Not tainted
[  531.489198] ---
[  531.491518] net/netlink/af_netlink.c:2953 suspicious 
rcu_dereference_protected() usage!
[  531.495781]
[  531.495781] other info that might help us debug this:
[  531.495781]
[  531.499094]
[  531.499094] rcu_scheduler_active = 1, debug_locks = 1
[  531.502685] 3 locks held by trinity-c490/9673:
[  531.505179] #0: (&f->f_pos_lock){+.+.+.}, at: __fdget_pos (fs/file.c:714)
[  531.510057] #1: (&p->lock){+.+.+.}, at: seq_lseek (fs/seq_file.c:322)
[  531.514819] #2: (rcu_read_lock){..}, at: netlink_seq_start 
(net/netlink/af_netlink.c:2923)
[  531.517956]
[  531.517956] stack backtrace:
[  531.519054] CPU: 7 PID: 9673 Comm: cat Not tainted 
3.16.0-next-20140804-sasha-00029-gcb12d07 #995
[  531.521526]   917b9e45 881efe493e20 
a55825a1
[  531.523616]  881efebeb000 881efe493e50 a21d3a75 
a81ce2c0
[  531.527426]  0002 8807cb581d90 880fa3da8000 
881efe493ea0
[  531.532068] Call Trace:
[  531.533595] dump_stack (lib/dump_stack.c:52)
[  531.536398] lockdep_rcu_suspicious (kernel/locking/lockdep.c:4259)
[  531.537934] netlink_seq_next (net/netlink/af_netlink.c:2953 (discriminator 
5))
[  531.539355] traverse (fs/seq_file.c:142)
[  531.541241] ? mutex_lock_nested (./arch/x86/include/asm/preempt.h:98 
kernel/locking/mutex.c:567 kernel/locking/mutex.c:584)
[  531.544797] seq_lseek (fs/seq_file.c:331 (discriminator 1))
[  531.547485] proc_reg_llseek (fs/proc/inode.c:197)
[  531.549904] SyS_lseek (fs/read_write.c:264 fs/read_write.c:289 
fs/read_write.c:280)
[  531.552190] tracesys (arch/x86/kernel/entry_64.S:541)

I'd suggest testing any RCU related patches with CONFIG_PROVE_RCU in the future.


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/

Re: [request for help] tty: serial: kgdb: fix msm_serial for kgdb

[Frank Rowand]

On 8/4/2014 6:33 PM, Stephen Boyd wrote:
> On 08/04/14 17:59, Frank Rowand wrote:
>> Stephen,
>>
>> I made some changes to drivers/tty/serial/msm_serial.c to allow kgdb
>> to work with the dragon board (which has a qcom,msm-uartdm-v1.4 serial
>> port).
>>
>> I will reply to this email with the patches.
>>
>> With these fixes, kgdb properly communicates with the dragon board, but
>> following the continue command, the serial driver does not get any stale
>> (UART_IMR_RXSTALE) interrupts until 48 characters have been read, which
>> triggers a high water interrupt.  After the high water interrupt has been
>> processed, the driver resumes properly getting stale interrupts.
>>
>> I am hoping you can help me figure out how to get the stale interrupt to
>> occur for the first character after gdb continues, instead of having to
>> first get a high water interrupt.
>>
>> Patch 2 adds a framework to fix up the state of the driver and/or hardware
>> after gdb continues.  Patch 3 is a series of experiments trying to fix
>> things up for msm_serial.  I don't have complete documentation and
>> understanding of the hardware, so some of the experiments might be less
>> than intelligent.
>>
>> Can you give me some suggestions of What should I be doing in the fix up
>> function?
> 
> Hmm... I've never gotten the serial console to come back after
> continuing because I only have one serial port and I use it for the
> console so switching it into kgdb makes me lose the console. How do you
> work around this? Use adb shell?

I use kdmx2 to share the host serial port between gdb for kgdb and minicom
for the console input and output.  I had to update kdmx2 to work in my
environment.  You can download it from:

   http://elinux.org/images/a/a7/Kdmx-2.00_v140730a.tar.gz

Whenever that link is updated, the new link can be found at:

   http://elinux.org/Kgdb

> 
> I think the big problem is
> 
> msm_write(port, UARTDM_DMEN_RX_SC_ENABLE, UARTDM_DMEN)
> 
> in msm_poll_init() which forces the uart into single character mode.

Yep, most of my fixes deal with the fact that in single character mode
echo fifo word only contains a single character of data.  All of that
works now.  So my only problem is not getting a stale interrupt until
after I've gotten a high water interrupt.

> That causes all sorts of problems but is required to make the get_char
> stuff work cleanly. I really wanted the msm_poll_get_char_dm_1p3() to
> work for the 1.4 version of the hardware but I guess they made the
> hardware different again for some unknown reason so it doesn't work. I
> never got around to figuring it out or talking to the hardware people.
> It took a while to develop the 1p3 version of the get_char code because
> of the "fifo" centric design.
> 
> Do you know if that 1p3 version of the code works for you on 1.3
> hardware? Just curious if that actually has the same bugs or not. I
> probably won't have much time to look at this anytime soon, but I'll try
> and send an email off to the hardware designers to figure out a way to
> avoid switching the mode.
> 

I don't have any 1.3 hardware on my desk.  I'll have to see if I can find
some when I get a chance.  I did try telling the driver that I was using
1.3 hardware even though it is 1.4; I had to make some changes to
msm_poll_get_char_dm_1p3() to make it kind of sort of work, but not well.
Instead of spending more time on that I just went back to making the single
character mode work.

-Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8] staging: iio: accel: sca3000_core.c: Add blank line between declarations and code

[Joe Perches]

On Mon, 2014-08-04 at 22:47 -0300, Murilo Opsfelder Araujo wrote:
> This patch adds missing blank line between declarations and code, and
> adjust code to fit 80-chars limit.
[]
> diff --git a/drivers/staging/iio/accel/sca3000_core.c 
> b/drivers/staging/iio/accel/sca3000_core.c
[]
> @@ -506,7 +506,8 @@ static int sca3000_read_raw(struct iio_dev *indio_dev,
>   mutex_unlock(&st->lock);
>   return ret;
>   }
> - *val = ((st->rx[0] & 0x3F) << 3) | ((st->rx[1] & 0xE0) 
> >> 5);
> + *val = ((st->rx[0] & 0x3F) << 3)
> + | ((st->rx[1] & 0xE0) >> 5);

Please don't strain to fit 80 columns.

If this is done, please strive to make it
quickly intelligible for humans.

I think this would be better as:

+   *val = ((st->rx[0] & 0x3F) << 3) |
+  ((st->rx[1] & 0xE0) >> 5);

so that the mask and shift are aligned.


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

[Minchan Kim]

On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
> Hello,
> 
> Not so long ago Timofey has reached both util-linux[1] and kernel[2]
> contributors with intention to make zram device management too.  I think
> the proposal is good, and there should be distribution independent tool
> like that.  Also such command fits fairly well to a scope of util-linux
> package.  But a tool is only as good as kernel support of it is.  This
> mail is a bit about both.
> 
> Existing proposal for zramctl[3], wrote by Timofey, does what I would
> call great starting point.  It can resize zram device, select algorithm,
> and set number of threads.  Unfortunately it cannot create or remove zram
> devices.
> 
> The zram devices are not created by any sort of equipment appearing in a
> bus so an method of creating new or removing existing devices will be
> needed.  When the zram module is loaded it should create
> /dev/zram-control device, that responds to ioctl() calls[4].  The calls
> could be similar with /dev/loop-control[5], that allow adding or removing
> specified device, and discover adding a free device.

Normally, dynamic management is good to have, I think but I didn't hear
strong requirement for that until now.
Why don't you change num_device param at module loading time?
I'd like to hear real scenario from whom are about to using that faeture
right now and what's the problem with num_device param.


> 
> This proposal would not affect the current initialization of the zram
> devices[6].  It would be an addition to manage zram devices after kernel
> module is loaded, of course each device separately and individually.  At
> the moment adding a device requires removing the existing devices[7],
> which can mean data loss, and at least unnecessary hassle when performing
> a device addition task.

If there is any holder of device, we shouldn't destroy the device.
It's doable.

> 
> But before getting too exited and asking for ioctl() allocation, or
> thinking too much about code, does an overall plan like this make sense? 
> Is there an alternative that would be better than /dev/zram-control +
> ioctl()'s?  Any other comments, better proposal, and so on?
> 
> Finally, Hats off to Timofey, you got the ball rolling getting the zram
> devices being dynamic someday in future.

I vote such standard tool to control each zram device's property but need
more thinking about dynamic device adding/removal.

> 
> [1] http://www.spinics.net/lists/util-linux-ng/index.html#09781
> [2] https://lkml.org/lkml/2014/7/17/272
> [3] http://www.spinics.net/lists/util-linux-ng/msg09900.html
> [4] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/ioctl-number.txt?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8
> [5] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8#n1757
> [6] such as: modprobe zram num_devices=4
> [7] requires 'rmmod zram' which is not possible if any zram device is busy
> 
> -- 
> Sami Kerola
> http://www.iki.fi/kerolasa/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: btrfs extents related oops.

[Dave Jones]

On Mon, Aug 04, 2014 at 09:28:45PM -0400, Dave Jones wrote:
 > Possibly related to some changes I've been making to my fuzz tester today
 > to operate on the same file from multiple threads.
 > This was on v3.16-829-g98959948a7ba, but probably exists on earlier trees too
 > given the lack of btrfs specific commits so far this merge window.

reproducer:

trinity -q -l off -c lseek -c write

(Things also go very, very bad if you then try to umount that
 partition - endless oopses, too mangled to parse).

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function

[bpqw]

>From 0304e9618d8c3ef5360b611f881f1b1bed08be06 Mon Sep 17 00:00:00 2001
From: White Ding 
Date: Thu, 24 Jul 2014 00:10:45 +0800
Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function

Do nand reset before write protect check.

If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.

As we know the status register can be refreshed, if we do some operation to 
trigger it,
for example if we do erase/program operation to one block that is locked, then 
READ STATUS,
the bit 7 of READ STATUS will be 0 indicate the device in write protect, then 
if we do
erase/program operation to another block that is unlocked, the bit 7 of READ 
STATUS will
be 1 indicate the device is not write protect.
Suppose we checked the bit 7 of READ STATUS is 0 then judge the WP# is low 
(write protect),
but in this case the WP# maybe high if we do erase/program operation to a 
locked block, 
so we must reset the device if we want to check the WP# low or high through 
STATUS READ and 
check bit 7.

Signed-off-by: White Ding 
---
 drivers/mtd/nand/nand_base.c |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 41167e9..22dd3aa 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t 
len)
 
chip->select_chip(mtd, chipnr);
 
+   /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+   chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug("%s: device is write protected!\n",
@@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t 
len)
 
chip->select_chip(mtd, chipnr);
 
+   /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+   chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug("%s: device is write protected!\n",
-- 
1.7.9.5

White

-Original Message-
From: Brian Norris [mailto:computersforpe...@gmail.com] 
Sent: Tuesday, August 05, 2014 6:48 AM
To: bpqw
Cc: dw...@infradead.org; b32...@freescale.com; 
artem.bityuts...@linux.intel.com; r...@debian.org; 
u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; 
linux-...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function

Hi,

On Mon, Jul 28, 2014 at 07:46:51AM +, bpqw wrote:
> >> Do nand reset before write protect check If we want to check the 
> >> WP# low or high through STATUS READ and check bit 7, we must reset 
> >> the device, other operation (eg.erase/program a locked block) can 
> >> also clear the bit 7 of status register.
> >This description doesn't really tell me why we need this patch.
> If we want to use the lock/unlock function, we must confirm the WP# is high, 
> if the WP# is low, the write protect is provided by WP#, we don't need 
> LOKC/UNLOCK function.
> So before we use the LOCK/UNLOCK function we must confirm the WP# is high.
> We can check the WP# is high or low through READ STATUS and check the bit 7, 
> but this only correct when we READ STATUS directly after RESET or Power On.
> If we don't add this patch, We can't check the WP# high or low just through 
> READ STATUS and check bit7. 
> 
> >First of all, where is the 'lock' sequence specified? I see the commit that 
> >introduced nand_lock() (without any users) which says Micron parts support 
> >it, but I don't see it documented in the datasheet:
> The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this 
> feature.
> 
> >  commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0
> >  Author: Vimal Singh 
> >  Date:   Mon Feb 8 15:50:49 2010 +0530
> 
> >  mtd: nand: add lock/unlock routines
> 
> >Now, supposing this is documented somewhere, are you seeing some kind 
> >of out-of-spec behavior? Is this a controller quirk you're seeing? 
> >Why should I need to reset the chip? I would presume that
> 
> >  chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
> 
> >would refresh the status properly. Is that not the case?
> chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, 
> but we must do some operation to trigger it.
> For example if we do rease/program operation to a block that is loc

[PATCH v2 0/8] staging: iio: accel: Multiple coding style fixes

[Murilo Opsfelder Araujo]

The following patches fix almost all warnings reported by
checkpatch.pl.

Changes from v1:
- Updated commit messages to better reflect changes.

Murilo Opsfelder Araujo (8):
  staging: iio: accel: adis16203_core.c: Add blank lines between
declarations and code
  staging: iio: accel: adis16201_core.c: Add blank line between
declarations and code
  staging: iio: accel: adis16204_core.c: Add blank line between
declarations and code
  staging: iio: accel: adis16209_core.c: Add blank line between
declarations and code
  staging: iio: accel: adis16240_core.c: Add blank line between
declarations and code
  staging: iio: accel: lis3l02dq_core.c: Add blank lines between
declarations and code
  staging: iio: accel: lis3l02dq_ring.c: Add blank line between
declarations and code
  staging: iio: accel: sca3000_core.c: Add blank line between
declarations and code

 drivers/staging/iio/accel/adis16201_core.c | 5 +++--
 drivers/staging/iio/accel/adis16203_core.c | 2 ++
 drivers/staging/iio/accel/adis16204_core.c | 1 +
 drivers/staging/iio/accel/adis16209_core.c | 1 +
 drivers/staging/iio/accel/adis16240_core.c | 1 +
 drivers/staging/iio/accel/lis3l02dq_core.c | 4 
 drivers/staging/iio/accel/lis3l02dq_ring.c | 1 +
 drivers/staging/iio/accel/sca3000_core.c   | 4 +++-
 8 files changed, 16 insertions(+), 3 deletions(-)

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

[PATCH v2 6/8] staging: iio: accel: lis3l02dq_core.c: Add blank lines between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank line between declarations and code,
satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/lis3l02dq_core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/iio/accel/lis3l02dq_core.c 
b/drivers/staging/iio/accel/lis3l02dq_core.c
index 898653c..f5e145c 100644
--- a/drivers/staging/iio/accel/lis3l02dq_core.c
+++ b/drivers/staging/iio/accel/lis3l02dq_core.c
@@ -212,6 +212,7 @@ static int lis3l02dq_write_thresh(struct iio_dev *indio_dev,
  int val, int val2)
 {
u16 value = val;
+
return lis3l02dq_spi_write_reg_s16(indio_dev,
   LIS3L02DQ_REG_THS_L_ADDR,
   value);
@@ -226,6 +227,7 @@ static int lis3l02dq_write_raw(struct iio_dev *indio_dev,
int ret = -EINVAL, reg;
u8 uval;
s8 sval;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
if (val > 255 || val < -256)
@@ -302,6 +304,7 @@ static ssize_t lis3l02dq_read_frequency(struct device *dev,
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
int ret, len = 0;
s8 t;
+
ret = lis3l02dq_spi_read_reg_8(indio_dev,
   LIS3L02DQ_REG_CTRL_1_ADDR,
   (u8 *)&t);
@@ -565,6 +568,7 @@ static int lis3l02dq_read_event_config(struct iio_dev 
*indio_dev,
u8 val;
int ret;
u8 mask = (1 << (chan->channel2*2 + (dir == IIO_EV_DIR_RISING)));
+
ret = lis3l02dq_spi_read_reg_8(indio_dev,
   LIS3L02DQ_REG_WAKE_UP_CFG_ADDR,
   &val);
-- 
2.1.0.rc1.204.gae8bc8d

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

[PATCH v2 5/8] staging: iio: accel: adis16240_core.c: Add blank line between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank line between declarations and code,
satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/adis16240_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/iio/accel/adis16240_core.c 
b/drivers/staging/iio/accel/adis16240_core.c
index 74ace2a..205d6d0 100644
--- a/drivers/staging/iio/accel/adis16240_core.c
+++ b/drivers/staging/iio/accel/adis16240_core.c
@@ -163,6 +163,7 @@ static int adis16240_write_raw(struct iio_dev *indio_dev,
int bits = 10;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
val16 = val & ((1 << bits) - 1);
-- 
2.1.0.rc1.204.gae8bc8d

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

[PATCH v6 1/7] kernel: Add support for kernel restart handler call chain

[Guenter Roeck]

Various drivers implement architecture and/or device specific means
to restart (reset) the system. Various mechanisms have been implemented
to support those schemes. The best known mechanism is arm_pm_restart,
which is a function pointer to be set either from platform specific code
or from drivers. Another mechanism is to use hardware watchdogs to issue
a reset; this mechanism is used if there is no other method available
to reset a board or system. Two examples are alim7101_wdt, which currently
uses the reboot notifier to trigger a reset, and moxart_wdt, which registers
the arm_pm_restart function.

The existing mechanisms have a number of drawbacks. Typically only one scheme
to restart the system is supported (at least if arm_pm_restart is used).
At least in theory there can be multiple means to restart the system, some of
which may be less desirable (for example one mechanism may only reset the CPU,
while another may reset the entire system). Using arm_pm_restart can also be
racy if the function pointer is set from a driver, as the driver may be in
the process of being unloaded when arm_pm_restart is called.
Using the reboot notifier is always racy, as it is unknown if and when
other functions using the reboot notifier have completed execution
by the time the watchdog fires.

Introduce a system restart handler call chain to solve the described problems.
This call chain is expected to be executed from the architecture specific
machine_restart() function. Drivers providing system restart functionality
(such as the watchdog drivers mentioned above) are expected to register
with this call chain. By using the priority field in the notifier block,
callers can control restart handler execution sequence and thus ensure that
the restart handler with the optimal restart capabilities for a given system
is called first.

Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: Use atomic notifier call chain
v5: Function renames:
register_restart_notifier -> register_restart_handler
unregister_restart_notifier -> unregister_restart_handler
kernel_restart_notify -> do_kernel_restart
v4: Document and suggest values for notifier priorities
v3: Add kernel_restart_notify wrapper function to execute notifier.
Improve documentation.
Move restart_notifier_list into kernel/reboot.c and make it static.
v2: No change.

 include/linux/reboot.h |  3 ++
 kernel/reboot.c| 81 ++
 2 files changed, 84 insertions(+)

diff --git a/include/linux/reboot.h b/include/linux/reboot.h
index 48bf152..67fc8fc 100644
--- a/include/linux/reboot.h
+++ b/include/linux/reboot.h
@@ -38,6 +38,9 @@ extern int reboot_force;
 extern int register_reboot_notifier(struct notifier_block *);
 extern int unregister_reboot_notifier(struct notifier_block *);
 
+extern int register_restart_handler(struct notifier_block *);
+extern int unregister_restart_handler(struct notifier_block *);
+extern void do_kernel_restart(char *cmd);
 
 /*
  * Architecture-specific implementations of sys_reboot commands.
diff --git a/kernel/reboot.c b/kernel/reboot.c
index a3a9e24..5925f5a 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -104,6 +104,87 @@ int unregister_reboot_notifier(struct notifier_block *nb)
 }
 EXPORT_SYMBOL(unregister_reboot_notifier);
 
+/*
+ * Notifier list for kernel code which wants to be called
+ * to restart the system.
+ */
+static ATOMIC_NOTIFIER_HEAD(restart_handler_list);
+
+/**
+ * register_restart_handler - Register function to be called to reset
+ *the system
+ * @nb: Info about handler function to be called
+ * @nb->priority:  Handler priority. Handlers should follow the
+ * following guidelines for setting priorities.
+ * 0:  Restart handler of last resort,
+ * with limited restart capabilities
+ * 128:Default restart handler; use if no other
+ * restart handler is expected to be available,
+ * and/or if restart functionality is
+ * sufficient to restart the entire system
+ * 255:Highest priority restart handler, will
+ * preempt all other restart handlers
+ *
+ * Registers a function with code to be called to restart the
+ * system.
+ *
+ * Registered functions will be called from machine_restart as last
+ * step of the restart sequence (if the architecture specific
+ * machine_restart function calls do_kernel_restart - see below
+ * for details).
+ * Registered functions are expected to restart the system immediately.
+ * If more than one function is registered, the restart handler priority
+ * selects which function will be called first.
+ *
+ * Restart handlers are expected to be registered from non-architecture

[PATCH v2 3/8] staging: iio: accel: adis16204_core.c: Add blank line between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank line between declarations and code,
satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/adis16204_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/iio/accel/adis16204_core.c 
b/drivers/staging/iio/accel/adis16204_core.c
index 19eaebc..4c8acbc 100644
--- a/drivers/staging/iio/accel/adis16204_core.c
+++ b/drivers/staging/iio/accel/adis16204_core.c
@@ -119,6 +119,7 @@ static int adis16204_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan->type) {
-- 
2.1.0.rc1.204.gae8bc8d

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

[PATCH v6 3/7] arm: Support restart through restart handler call chain

[Guenter Roeck]

The kernel core now supports a restart handler call chain for system
restart functions.

With this change, the arm_pm_restart callback is now optional, so check
if it is set before calling it. Only call the kernel restart handler
if arm_pm_restart is not set.

Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: No change.
v5: Renamed restart function to do_kernel_restart
v4: No change.
v3: Use wrapper function to execute notifier call chain.
v2: Only call notifier call chain if arm_pm_restart is not set.
Do not include linux/watchdog.h.

 arch/arm/kernel/process.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 81ef686..84ca0d5 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -230,7 +230,10 @@ void machine_restart(char *cmd)
local_irq_disable();
smp_send_stop();
 
-   arm_pm_restart(reboot_mode, cmd);
+   if (arm_pm_restart)
+   arm_pm_restart(reboot_mode, cmd);
+   else
+   do_kernel_restart(cmd);
 
/* Give a grace period for failure to restart of 1s */
mdelay(1000);
-- 
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 v6 4/7] power/restart: Call machine_restart instead of arm_pm_restart

[Guenter Roeck]

machine_restart is supported on non-ARM platforms, and and ultimately calls
arm_pm_restart, so dont call arm_pm_restart directly but use the more
generic function.

Cc: Russell King 
Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: No change.
v5: No change.
v4: No change.
v3: No change.
v2: Added patch.

 drivers/power/reset/restart-poweroff.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/reset/restart-poweroff.c 
b/drivers/power/reset/restart-poweroff.c
index 5758033..47f10eb 100644
--- a/drivers/power/reset/restart-poweroff.c
+++ b/drivers/power/reset/restart-poweroff.c
@@ -20,7 +20,8 @@
 
 static void restart_poweroff_do_poweroff(void)
 {
-   arm_pm_restart(REBOOT_HARD, NULL);
+   reboot_mode = REBOOT_HARD;
+   machine_restart(NULL);
 }
 
 static int restart_poweroff_probe(struct platform_device *pdev)
-- 
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 v6 7/7] arm/arm64: Unexport restart handlers

[Guenter Roeck]

Implementing a restart handler in a module don't make sense
as there would be no guarantee that the module is loaded when
a restart is needed. Unexport arm_pm_restart to ensure that
no one gets the idea to do it anyway.

Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: No change
v5: No change
v4: No change
v3: No change
v2: No change

 arch/arm/kernel/process.c   | 1 -
 arch/arm64/kernel/process.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 84ca0d5..27bdf11 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -125,7 +125,6 @@ void (*pm_power_off)(void);
 EXPORT_SYMBOL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd) = 
null_restart;
-EXPORT_SYMBOL_GPL(arm_pm_restart);
 
 /*
  * This is our default idle handler.
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 9591e60..f5fddff 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -92,7 +92,6 @@ void (*pm_power_off)(void);
 EXPORT_SYMBOL_GPL(pm_power_off);
 
 void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
-EXPORT_SYMBOL_GPL(arm_pm_restart);
 
 /*
  * This is our default idle handler.
-- 
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 v6 2/7] arm64: Support restart through restart handler call chain

[Guenter Roeck]

The kernel core now supports a restart handler call chain to restart
the system. Call it if arm_pm_restart is not set.

Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: No change.
v5: Renamed restart function to do_kernel_restart
v4: No change.
v3: Use wrapper function to execute notifier call chain.
v2: Only call notifier call chain if arm_pm_restart is not set.
Do not include linux/watchdog.h.

 arch/arm64/kernel/process.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 43b7c34..9591e60 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -174,6 +174,8 @@ void machine_restart(char *cmd)
/* Now call the architecture specific reboot code. */
if (arm_pm_restart)
arm_pm_restart(reboot_mode, cmd);
+   else
+   do_kernel_restart(cmd);
 
/*
 * Whoops - the architecture was unable to reboot.
-- 
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 v6 5/7] watchdog: moxart: Register restart handler with kernel restart handler

[Guenter Roeck]

The kernel now provides an API to trigger a system restart.
Register with it instead of setting arm_pm_restart.

Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: No change.
v5: Functions and variables renamed: *notifier -> *handler
v4: Set notifier priority to 128.
v3: Move struct notifier_block into struct moxart_wdt_dev.
Drop static variable previously needed to access struct moxart_wdt_dev
from notifier function; use container_of instead.
v2: No change.

 drivers/watchdog/moxart_wdt.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/watchdog/moxart_wdt.c b/drivers/watchdog/moxart_wdt.c
index 4aa3a8a..a64405b 100644
--- a/drivers/watchdog/moxart_wdt.c
+++ b/drivers/watchdog/moxart_wdt.c
@@ -15,12 +15,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-
 #define REG_COUNT  0x4
 #define REG_MODE   0x8
 #define REG_ENABLE 0xC
@@ -29,17 +29,22 @@ struct moxart_wdt_dev {
struct watchdog_device dev;
void __iomem *base;
unsigned int clock_frequency;
+   struct notifier_block restart_handler;
 };
 
-static struct moxart_wdt_dev *moxart_restart_ctx;
-
 static int heartbeat;
 
-static void moxart_wdt_restart(enum reboot_mode reboot_mode, const char *cmd)
+static int moxart_restart_handle(struct notifier_block *this,
+unsigned long mode, void *cmd)
 {
-   writel(1, moxart_restart_ctx->base + REG_COUNT);
-   writel(0x5ab9, moxart_restart_ctx->base + REG_MODE);
-   writel(0x03, moxart_restart_ctx->base + REG_ENABLE);
+   struct moxart_wdt_dev *moxart_wdt = container_of(this,
+struct moxart_wdt_dev,
+restart_handler);
+   writel(1, moxart_wdt->base + REG_COUNT);
+   writel(0x5ab9, moxart_wdt->base + REG_MODE);
+   writel(0x03, moxart_wdt->base + REG_ENABLE);
+
+   return NOTIFY_DONE;
 }
 
 static int moxart_wdt_stop(struct watchdog_device *wdt_dev)
@@ -136,8 +141,12 @@ static int moxart_wdt_probe(struct platform_device *pdev)
if (err)
return err;
 
-   moxart_restart_ctx = moxart_wdt;
-   arm_pm_restart = moxart_wdt_restart;
+   moxart_wdt->restart_handler.notifier_call = moxart_restart_handle;
+   moxart_wdt->restart_handler.priority = 128;
+   err = register_restart_handler(&moxart_wdt->restart_handler);
+   if (err)
+   dev_err(dev, "cannot register restart notifier (err=%d)\n",
+   err);
 
dev_dbg(dev, "Watchdog enabled (heartbeat=%d sec, nowayout=%d)\n",
moxart_wdt->dev.timeout, nowayout);
@@ -149,9 +158,8 @@ static int moxart_wdt_remove(struct platform_device *pdev)
 {
struct moxart_wdt_dev *moxart_wdt = platform_get_drvdata(pdev);
 
-   arm_pm_restart = NULL;
+   unregister_restart_handler(&moxart_wdt->restart_handler);
moxart_wdt_stop(&moxart_wdt->dev);
-   watchdog_unregister_device(&moxart_wdt->dev);
 
return 0;
 }
-- 
1.9.1

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

[PATCH v6 0/7] kernel: Add support for restart handler call chain

[Guenter Roeck]

Various drivers implement architecture and/or device specific means
to restart (reset) the system. Various mechanisms have been implemented
to support those schemes. The best known mechanism is arm_pm_restart,
which is a function pointer to be set either from platform specific code
or from drivers. Another mechanism is to use hardware watchdogs to issue
a reset; this mechanism is used if there is no other method available
to reset a board or system. Two examples are alim7101_wdt, which currently
uses the reboot notifier to trigger a reset, and moxart_wdt, which registers
the arm_pm_restart function. Several other restart drivers for arm, all
directly calling arm_pm_restart, are in the process of being integrated
into the kernel. All those drivers would benefit from the new API.

The existing mechanisms have a number of drawbacks. Typically only one scheme
to restart the system is supported (at least if arm_pm_restart is used).
At least in theory there can be multiple means to restart the system, some of
which may be less desirable (for example one mechanism may only reset the CPU,
while another may reset the entire system). Using arm_pm_restart can also be
racy if the function pointer is set from a driver, as the driver may be in
the process of being unloaded when arm_pm_restart is called.
Using the reboot notifier is always racy, as it is unknown if and when
other functions using the reboot notifier have completed execution
by the time the watchdog fires.

Introduce a system restart handler call chain to solve the described problems.
This call chain is expected to be executed from the architecture specific
machine_restart() function. Drivers providing system restart functionality
(such as the watchdog drivers mentioned above) are expected to register
with this call chain. By using the priority field in the notifier block,
callers can control restart handler execution sequence and thus ensure that
the restart handler with the optimal restart capabilities for a given system
is called first.

Since the first revision of this patchset, a number of separate patch
submissions have been made which either depend on it or could make use of it.

http://www.spinics.net/linux/lists/arm-kernel/msg344796.html
registers three notifiers.
https://lkml.org/lkml/2014/7/8/962
would benefit from it.

Patch 1 of this series implements the restart handler function. Patches 2 and 3
implement calling the restart handler chain from arm and arm64 restart code.

Patch 4 modifies the restart-poweroff driver to no longer call arm_pm_restart
directly but machine_restart. This is done to avoid calling arm_pm_restart
from more than one place. The change makes the driver architecture independent,
so it would be possible to drop the arm dependency from its Kconfig entry.

Patch 5 and 6 convert existing restart handlers in the watchdog subsystem
to use the restart handler. Patch 7 unexports arm_pm_restart to ensure
that no one gets the idea to implement a restart handler as module.

The entire patch series, including additional patches depending on it,
is available from
https://git.kernel.org/cgit/linux/kernel/git/groeck/linux-staging.git/
in branch 'restart-staging'.

On a side note, I realize that the timing for sending this series is less
than optimal, given that we have an open commit window. Letting it sit for
two weeks collecting dust isn't optimal either, so I figure it may as well
collect dust in public.

---
v6: Use atomic notifier call chain 
Rebased series to v3.16
v5: Rebased series to v3.16-rc5
Function renames:
register_restart_notifier -> register_restart_handler
unregister_restart_notifier -> unregister_restart_handler
kernel_restart_notify -> do_kernel_restart
v4: Document restart notifier priorities
Select 128 as default priority for newly introduced notifiers
Fix checkpatch warning (line too long) in moxart patch
v3: Drop RFC.
Add kernel_restart_notify wrapper function to execute notifier
Improve documentation.
Move restart_notifier_list into kernel/reboot.c and make it static.
v2: Add patch 4.
Only call blocking notifier call chain if arm_pm_restart was not set.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 6/7] watchdog: alim7101: Register restart handler with kernel restart handler

[Guenter Roeck]

The kernel core now provides an API to trigger a system restart.
Register with it to restart the system instead of misusing the
reboot notifier.

Signed-off-by: Guenter Roeck 
Acked-by: Catalin Marinas 
Acked-by: Heiko Stuebner 
---
v6: No change.
v5: Function and variable renames: *notifier -> *handler.
v4: Set restart notifier priority to 128.
v3: No change.
v2: No change.

 drivers/watchdog/alim7101_wdt.c | 42 +++--
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/drivers/watchdog/alim7101_wdt.c b/drivers/watchdog/alim7101_wdt.c
index 996b2f7..665e0e7 100644
--- a/drivers/watchdog/alim7101_wdt.c
+++ b/drivers/watchdog/alim7101_wdt.c
@@ -301,6 +301,28 @@ static struct miscdevice wdt_miscdev = {
.fops   =   &wdt_fops,
 };
 
+static int wdt_restart_handle(struct notifier_block *this, unsigned long mode,
+ void *cmd)
+{
+   /*
+* Cobalt devices have no way of rebooting themselves other
+* than getting the watchdog to pull reset, so we restart the
+* watchdog on reboot with no heartbeat.
+*/
+   wdt_change(WDT_ENABLE);
+
+   /* loop until the watchdog fires */
+   while (true)
+   ;
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block wdt_restart_handler = {
+   .notifier_call = wdt_restart_handle,
+   .priority = 128,
+};
+
 /*
  * Notifier for system down
  */
@@ -311,15 +333,6 @@ static int wdt_notify_sys(struct notifier_block *this,
if (code == SYS_DOWN || code == SYS_HALT)
wdt_turnoff();
 
-   if (code == SYS_RESTART) {
-   /*
-* Cobalt devices have no way of rebooting themselves other
-* than getting the watchdog to pull reset, so we restart the
-* watchdog on reboot with no heartbeat
-*/
-   wdt_change(WDT_ENABLE);
-   pr_info("Watchdog timer is now enabled with no heartbeat - 
should reboot in ~1 second\n");
-   }
return NOTIFY_DONE;
 }
 
@@ -338,6 +351,7 @@ static void __exit alim7101_wdt_unload(void)
/* Deregister */
misc_deregister(&wdt_miscdev);
unregister_reboot_notifier(&wdt_notifier);
+   unregister_restart_handler(&wdt_restart_handler);
pci_dev_put(alim7101_pmu);
 }
 
@@ -390,11 +404,17 @@ static int __init alim7101_wdt_init(void)
goto err_out;
}
 
+   rc = register_restart_handler(&wdt_restart_handler);
+   if (rc) {
+   pr_err("cannot register restart handler (err=%d)\n", rc);
+   goto err_out_reboot;
+   }
+
rc = misc_register(&wdt_miscdev);
if (rc) {
pr_err("cannot register miscdev on minor=%d (err=%d)\n",
   wdt_miscdev.minor, rc);
-   goto err_out_reboot;
+   goto err_out_restart;
}
 
if (nowayout)
@@ -404,6 +424,8 @@ static int __init alim7101_wdt_init(void)
timeout, nowayout);
return 0;
 
+err_out_restart:
+   unregister_restart_handler(&wdt_restart_handler);
 err_out_reboot:
unregister_reboot_notifier(&wdt_notifier);
 err_out:
-- 
1.9.1

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

[PATCH v2 4/8] staging: iio: accel: adis16209_core.c: Add blank line between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank line between declarations and code,
satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/adis16209_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/iio/accel/adis16209_core.c 
b/drivers/staging/iio/accel/adis16209_core.c
index 374dc6e..b2c7aed 100644
--- a/drivers/staging/iio/accel/adis16209_core.c
+++ b/drivers/staging/iio/accel/adis16209_core.c
@@ -44,6 +44,7 @@ static int adis16209_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan->type) {
-- 
2.1.0.rc1.204.gae8bc8d

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

[PATCH v2 2/8] staging: iio: accel: adis16201_core.c: Add blank line between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank line between declarations and code, and
also fixes lines starting by space, satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/adis16201_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/accel/adis16201_core.c 
b/drivers/staging/iio/accel/adis16201_core.c
index 50ba1fa..7eae5fd 100644
--- a/drivers/staging/iio/accel/adis16201_core.c
+++ b/drivers/staging/iio/accel/adis16201_core.c
@@ -111,6 +111,7 @@ static int adis16201_write_raw(struct iio_dev *indio_dev,
int bits;
s16 val16;
u8 addr;
+
switch (mask) {
case IIO_CHAN_INFO_CALIBBIAS:
switch (chan->type) {
@@ -131,8 +132,8 @@ static int adis16201_write_raw(struct iio_dev *indio_dev,
 }
 
 static const struct iio_chan_spec adis16201_channels[] = {
-  ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT, ADIS16201_SCAN_SUPPLY, 0, 12),
-  ADIS_TEMP_CHAN(ADIS16201_TEMP_OUT, ADIS16201_SCAN_TEMP, 0, 12),
+   ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT, ADIS16201_SCAN_SUPPLY, 0, 12),
+   ADIS_TEMP_CHAN(ADIS16201_TEMP_OUT, ADIS16201_SCAN_TEMP, 0, 12),
ADIS_ACCEL_CHAN(X, ADIS16201_XACCL_OUT, ADIS16201_SCAN_ACC_X,
BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14),
ADIS_ACCEL_CHAN(Y, ADIS16201_YACCL_OUT, ADIS16201_SCAN_ACC_Y,
-- 
2.1.0.rc1.204.gae8bc8d

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 8/8] staging: iio: accel: sca3000_core.c: Add blank line between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank line between declarations and code, and
ajust code to fit 80-chars limit.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/sca3000_core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/iio/accel/sca3000_core.c 
b/drivers/staging/iio/accel/sca3000_core.c
index ed30e32..1ff299f 100644
--- a/drivers/staging/iio/accel/sca3000_core.c
+++ b/drivers/staging/iio/accel/sca3000_core.c
@@ -506,7 +506,8 @@ static int sca3000_read_raw(struct iio_dev *indio_dev,
mutex_unlock(&st->lock);
return ret;
}
-   *val = ((st->rx[0] & 0x3F) << 3) | ((st->rx[1] & 0xE0) 
>> 5);
+   *val = ((st->rx[0] & 0x3F) << 3)
+   | ((st->rx[1] & 0xE0) >> 5);
}
mutex_unlock(&st->lock);
return IIO_VAL_INT;
@@ -713,6 +714,7 @@ static int sca3000_read_thresh(struct iio_dev *indio_dev,
int ret, i;
struct sca3000_state *st = iio_priv(indio_dev);
int num = chan->channel2;
+
mutex_lock(&st->lock);
ret = sca3000_read_ctrl_reg(st, sca3000_addresses[num][1]);
mutex_unlock(&st->lock);
-- 
2.1.0.rc1.204.gae8bc8d

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] zram: auto add new devices on demand

[Minchan Kim]

On Wed, Jul 30, 2014 at 10:58:31PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (07/29/14 12:00), Minchan Kim wrote:
> > Hello Timofey,
> > 
> > Sorry for late response and thanks for suggesting new feature.
> > 
> > First of all, I'd like to know your usecase.
> > 
> > I don't mean I am against this feature and I tend to agree it would
> > be good if we can make new device dynamically but until now, I don't
> > hear any requirement like that. So we need compelling usecase to
> > justify maintainance overhead.
> > 
> > On Mon, Jul 21, 2014 at 01:46:14PM +0300, Timofey Titovets wrote:
> > > From: Timofey Titovets 
> > > 
> > > This add supporting of auto allocate new zram devices on demand,
> > > like loop devices
> > > 
> > > This working by following rules:
> > >   - Pre create zram devices specified by num_device
> > >   - if all device already in use -> add new free device
> > > 
> > > From v1 -> v2:
> > > Delete useless variable 'ret', added documentation for explain new
> > > zram behavior
> > > 
> > > From v2 -> v3
> > > Delete logic to destroy not used devices, for avoid concurrency issues
> > > Code refactoring for made patch small and clean as possible
> > > Patch can pass the test:
> > > 
> > > #!/bin/sh
> > > modprobe zram
> > > while true; do
> > > echo 10485760 > /sys/block/zram0/disksize&
> > > echo 1 > /sys/block/zram0/reset&
> > > done
> > > 
> > > Can be pulled from:
> > > https://github.com/Nefelim4ag/linux.git
> > > 
> > > Tested on 3.15.5-2-ARCH, can be applied on any kernel version
> > > after this patch 'zram: add LZ4 compression support' - 
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=6e76668e415adf799839f0ab205142ad7002d260
> > > 
> > > ---
> > > 
> > > diff --git a/Documentation/blockdev/zram.txt
> > > b/Documentation/blockdev/zram.txt
> > > index 0595c3f..a090ac7 100644
> > > --- a/Documentation/blockdev/zram.txt
> > > +++ b/Documentation/blockdev/zram.txt
> > > @@ -21,6 +21,9 @@ Following shows a typical sequence of steps for
> > > using zram.
> > >   This creates 4 devices: /dev/zram{0,1,2,3}
> > >   (num_devices parameter is optional. Default: 1)
> > > 
> > > + If all device in use kernel will create new zram device
> > > + (between num_devices and 31)
> > > +
> > >  2) Set max number of compression streams
> > >   Compression backend may use up to max_comp_streams compression streams,
> > >   thus allowing up to max_comp_streams concurrent compression operations.
> > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > > index 089e72c..cc78779 100644
> > > --- a/drivers/block/zram/zram_drv.c
> > > +++ b/drivers/block/zram/zram_drv.c
> > > @@ -43,6 +43,8 @@ static const char *default_compressor = "lzo";
> > >  /* Module params (documentation at end) */
> > >  static unsigned int num_devices = 1;
> > > 
> > > +static inline int zram_add_dev(void);
> > > +
> > >  #define ZRAM_ATTR_RO(name)   
> > > \
> > >  static ssize_t zram_attr_##name##_show(struct device *d, \
> > >   struct device_attribute *attr, char *b) \
> > > @@ -168,6 +170,7 @@ static ssize_t comp_algorithm_store(struct device 
> > > *dev,
> > >   struct device_attribute *attr, const char *buf, size_t len)
> > >  {
> > >   struct zram *zram = dev_to_zram(dev);
> > > +
> > 
> > unnecessary change
> > 
> > >   down_write(&zram->init_lock);
> > >   if (init_done(zram)) {
> > >   up_write(&zram->init_lock);
> > > @@ -239,6 +242,7 @@ static struct zram_meta *zram_meta_alloc(u64 disksize)
> > >  {
> > >   size_t num_pages;
> > >   struct zram_meta *meta = kmalloc(sizeof(*meta), GFP_KERNEL);
> > > +
> > 
> > Ditto
> > 
> > >   if (!meta)
> > >   goto out;
> > > 
> > > @@ -374,6 +378,7 @@ static int zram_bvec_read(struct zram *zram,
> > > struct bio_vec *bvec,
> > >   struct page *page;
> > >   unsigned char *user_mem, *uncmem = NULL;
> > >   struct zram_meta *meta = zram->meta;
> > > +
> > 
> > Ditto
> > 
> > >   page = bvec->bv_page;
> > > 
> > >   read_lock(&meta->tb_lock);
> > > @@ -607,6 +612,7 @@ static void zram_reset_device(struct zram *zram,
> > > bool reset_capacity)
> > >   /* Free all pages that are still in this zram device */
> > >   for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
> > >   unsigned long handle = meta->table[index].handle;
> > > +
> > 
> > Ditto
> > 
> > >   if (!handle)
> > >   continue;
> > > 
> > > @@ -667,6 +673,7 @@ static ssize_t disksize_store(struct device *dev,
> > >   zram->disksize = disksize;
> > >   set_capacity(zram->disk, zram->disksize >> SECTOR_SHIFT);
> > >   revalidate_disk(zram->disk);
> > > + zram_add_dev();
> > 
> > Why do you add new device unconditionally?
> > Maybe we need new konb on sysfs or ioctl for adding new device?
> > Any thought, guys?
> 
> 
> speaking of the patch, frankly, I (almost) see no gain comparing to the
> e

[PATCH v2 7/8] staging: iio: accel: lis3l02dq_ring.c: Add blank line between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank line between declarations and code,
satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/lis3l02dq_ring.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/iio/accel/lis3l02dq_ring.c 
b/drivers/staging/iio/accel/lis3l02dq_ring.c
index bf33fde..1d934ee 100644
--- a/drivers/staging/iio/accel/lis3l02dq_ring.c
+++ b/drivers/staging/iio/accel/lis3l02dq_ring.c
@@ -19,6 +19,7 @@ static inline u16 combine_8_to_16(u8 lower, u8 upper)
 {
u16 _lower = lower;
u16 _upper = upper;
+
return _lower | (_upper << 8);
 }
 
-- 
2.1.0.rc1.204.gae8bc8d

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

[PATCH v2 1/8] staging: iio: accel: adis16203_core.c: Add blank lines between declarations and code

[Murilo Opsfelder Araujo]

This patch adds missing blank lines between declarations and code,
satisfying checkpatch.pl.

Signed-off-by: Murilo Opsfelder Araujo 
---
 drivers/staging/iio/accel/adis16203_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/iio/accel/adis16203_core.c 
b/drivers/staging/iio/accel/adis16203_core.c
index f472137..fbbe93f 100644
--- a/drivers/staging/iio/accel/adis16203_core.c
+++ b/drivers/staging/iio/accel/adis16203_core.c
@@ -37,6 +37,7 @@ static int adis16203_write_raw(struct iio_dev *indio_dev,
struct adis *st = iio_priv(indio_dev);
/* currently only one writable parameter which keeps this simple */
u8 addr = adis16203_addresses[chan->scan_index];
+
return adis_write_reg_16(st, addr, val & 0x3FFF);
 }
 
@@ -50,6 +51,7 @@ static int adis16203_read_raw(struct iio_dev *indio_dev,
int bits;
u8 addr;
s16 val16;
+
switch (mask) {
case IIO_CHAN_INFO_RAW:
return adis_single_conversion(indio_dev, chan,
-- 
2.1.0.rc1.204.gae8bc8d

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

Re: [PATCH v3 2/2] usb: dwc2: add 'mode' which based on Kconfig select or dts setting

[Kever Yang]

Doug,

On 08/05/2014 12:34 AM, Doug Anderson wrote:

Kever,

On Mon, Aug 4, 2014 at 6:45 AM, Kever Yang  wrote:

According to the "dr_mode", the otg controller can work as
device role during firmware period, and work as host role in
the kernel, without use of usb_id pin. As the commit "usb: dwc3:
set 'mode' based on selected Kconfig choices".

I don't think you need to mention firmware / kernel here.  Just say
that on some boards we always want to use host mode and on other
boards we want to use gadget mode.  ...and that we don't necessarily
have the ID pin hooked up to make this automatic.

OK, I'll change this message again, I just don't know how to describe
to make everyone understand what I'm doing.




Signed-off-by: Kever Yang 

Normally I'd say that you should have added Paul's "Acked-by" since
you fixed his nit and he told you to include his Acked-by when his nit
was fixed, but...

There are some more changes than Paul's suggestion, so I'm not sure
if Paul need more review to give me the "Acked-by", I get it now.




---

Changes in v3:
- fix the odd spacing in dwc2_hsotg struct
- From Jingoo's suggestion:
 change the commit message

You did more than just this.  You also added some (incorrect) Kconfig
things.  See below.



Changes in v2:
- put spaces around '+' operator
- expand the comment for dr_mode
- handle dr_mode is USB_DR_MODE_OTG

  drivers/usb/dwc2/core.c | 18 ++
  drivers/usb/dwc2/core.h |  5 +
  drivers/usb/dwc2/platform.c | 12 
  3 files changed, 35 insertions(+)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 27d2c9b..738bec2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -118,6 +118,7 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
  {
 u32 greset;
 int count = 0;
+   u32 gusbcfg;

 dev_vdbg(hsotg->dev, "%s()\n", __func__);

@@ -148,6 +149,23 @@ static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
 }
 } while (greset & GRSTCTL_CSFTRST);

+   if (hsotg->dr_mode == USB_DR_MODE_HOST) {
+   gusbcfg = readl(hsotg->regs + GUSBCFG);
+   gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
+   gusbcfg |= GUSBCFG_FORCEHOSTMODE;
+   writel(gusbcfg, hsotg->regs + GUSBCFG);
+   } else if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
+   gusbcfg = readl(hsotg->regs + GUSBCFG);
+   gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
+   gusbcfg |= GUSBCFG_FORCEDEVMODE;
+   writel(gusbcfg, hsotg->regs + GUSBCFG);
+   } else if (hsotg->dr_mode == USB_DR_MODE_OTG) {
+   gusbcfg = readl(hsotg->regs + GUSBCFG);
+   gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
+   gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
+   writel(gusbcfg, hsotg->regs + GUSBCFG);
+   }
+
 /*
  * NOTE: This long sleep is _very_ important, otherwise the core will
  * not stay in host mode after a connector ID change!
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..52a4fd2 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -501,6 +501,10 @@ struct dwc2_hw_params {
   *  a_peripheral and b_device=>b_host) this may not match
   *  the core, but allows the software to determine
   *  transitions
+ * @dr_mode:Requested mode of operation, one of following:
+ *  - USB_DR_MODE_PERIPHERAL
+ *  - USB_DR_MODE_HOST
+ *  - USB_DR_MODE_OTG
   * @queuing_high_bandwidth: True if multiple packets of a high-bandwidth
   *  transfer are in process of being queued
   * @srp_success:Stores status of SRP request in the case of a FS PHY
@@ -592,6 +596,7 @@ struct dwc2_hsotg {
 /** Params to actually use */
 struct dwc2_core_params *core_params;
 enum usb_otg_state op_state;
+   enum usb_dr_mode dr_mode;

 unsigned int queuing_high_bandwidth:1;
 unsigned int srp_success:1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index a10e7a3..4d2c738 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -42,6 +42,8 @@
  #include 
  #include 

+#include 
+
  #include "core.h"
  #include "hcd.h"

@@ -171,6 +173,16 @@ static int dwc2_driver_probe(struct platform_device *dev)
 dev_dbg(&dev->dev, "mapped PA %08lx to VA %p\n",
 (unsigned long)res->start, hsotg->regs);

+   hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
+
+   if (IS_ENABLED(CONFIG_USB_DWC2_HOST))
+   hsotg->dr_mode = USB_DR_MODE_HOST;
+   else if (IS_ENABLED(CONFIG_USB_DWC2_GADGET))
+   hsotg->dr_mode = USB_DR_MODE_PERIPHERAL;
+
+   if (hsotg->dr_mode == USB_DR_MODE_UNKNOWN)
+   hsotg->dr_mode = USB_DR_MODE_OTG;
+

Please remove this whole chunk.  Specifica

Re: [PATCH v2 2/4] pinctrl: qpnp: Qualcomm PMIC pin controller driver

[Stephen Boyd]

On 07/28/14 01:39, Ivan T. Ivanov wrote:
> I am working on proposal from Stephen Boyd to encode GPIO/MPP mode and 
> source select into combined function. Something like this one:
>
> #define PM8XXX_DIGITAL_IN 0
> #define PM8XXX_DIGITAL_OUT1
> #define PM8XXX_DIGITAL_IN_OUT 2
>
> ...
>
> /* mode and source select */
> #define PM8XXX_FUNCTION(m,s)  ((m) << 16 | (s))
>
> #define PM8921_GPIO1_14_KYPD_SNS  PM8XXX_FUNCTION(PM8XXX_DIGITAL_IN, 1)
> #define PM8921_GPIO9_14_KYPD_DRV  PM8XXX_FUNCTION(PM8XXX_DIGITAL_OUT, 1)
> #define PM8921_GPIO33_35_PWM  PM8XXX_FUNCTION(PM8XXX_DIGITAL_OUT, 3)
>
> ..
>
>

This isn't what I was suggesting at all. The function should be
something like KYPD, PWM and those should just be defined to be 1 or 3.
The mode should be some other property like input or output, and the
driver should or the two together and put it into the register.
Basically we shouldn't see any shifts or ors in the #defines, just
convenient numbers that correspond to the value of the field in the
register.

-- 
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 2/8] msm: scm: Get cacheline size from CTR

[Stephen Boyd]

Instead of hardcoding the cacheline size as 32, get the cacheline
size from the CTR register.

Signed-off-by: Stephen Boyd 
---
 arch/arm/mach-qcom/scm.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-qcom/scm.c b/arch/arm/mach-qcom/scm.c
index 820c72165e19..c08786ebf116 100644
--- a/arch/arm/mach-qcom/scm.c
+++ b/arch/arm/mach-qcom/scm.c
@@ -27,9 +27,6 @@
 
 #include "scm.h"
 
-/* Cache line size for msm8x60 */
-#define CACHELINESIZE 32
-
 #define SCM_ENOMEM -5
 #define SCM_EOPNOTSUPP -4
 #define SCM_EINVAL_ADDR-3
@@ -214,13 +211,18 @@ static int __scm_call(const struct scm_command *cmd)
 
 static void scm_inv_range(unsigned long start, unsigned long end)
 {
-   start = round_down(start, CACHELINESIZE);
-   end = round_up(end, CACHELINESIZE);
+   u32 cacheline_size, ctr;
+
+   asm volatile("mrc p15, 0, %0, c0, c0, 1" : "=r" (ctr));
+   cacheline_size = 4 << ((ctr >> 16) & 0xf);
+
+   start = round_down(start, cacheline_size);
+   end = round_up(end, cacheline_size);
outer_inv_range(start, end);
while (start < end) {
asm ("mcr p15, 0, %0, c7, c6, 1" : : "r" (start)
 : "memory");
-   start += CACHELINESIZE;
+   start += cacheline_size;
}
dsb();
isb();
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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