[PATCH] PCI: Add disabling pm async quirk for JMicron chips

d in commit e6b7e41cdd8c ("ata: Disabling the async PM for JMicron chip 363/361"), so here add one quirk to disable the JMicron chips' PM async feature. Cc: sta...@vger.kernel.org # 3.15+ Signed-off-by: Chuansheng Liu --- drivers/pci/quirks.c | 17 + 1 file change

[PATCH] PCI: Do not enable async suspend for JMicron chips

# 3.15+ Acked-by: Aaron Lu Signed-off-by: Chuansheng Liu --- drivers/pci/pci.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 625a4ac..53128f0 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2046,7 +2046,17

[PATCH] PCI: Do not enable async suspend for JMicron chips

suspend method for Jmicron chip. Cc: sta...@vger.kernel.org # 3.15+ Signed-off-by: Chuansheng Liu --- drivers/pci/pci.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 625a4ac..53128f0 100644 --- a/drivers/pci/pci.c

[PATCH V2] ata: Disabling the async PM for JMicron chips

ync method directly, to avoid further similar issues. Details in: https://bugzilla.kernel.org/show_bug.cgi?id=84861 Reported-and-tested-by: Barto Signed-off-by: Chuansheng Liu --- drivers/ata/ahci.c | 11 +-- drivers/ata/pata_jmicron.c | 11 +-- 2 files changed, 10 inserti

[PATCH] ata: Disabling the async PM for JMicron chips

avoid further similar issues. Details in: https://bugzilla.kernel.org/show_bug.cgi?id=84861 Reported-and-tested-by: Barto Signed-off-by: Chuansheng Liu --- drivers/ata/ahci.c |6 +++--- drivers/ata/pata_jmicron.c |6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff

[tip:sched/core] cpuidle: Use wake_up_all_idle_cpus() to wake up all idle cpus

Commit-ID: 2ed903c5485bad0eafdd3d59ff993598736e4f31 Gitweb: http://git.kernel.org/tip/2ed903c5485bad0eafdd3d59ff993598736e4f31 Author: Chuansheng Liu AuthorDate: Thu, 4 Sep 2014 15:17:55 +0800 Committer: Ingo Molnar CommitDate: Fri, 19 Sep 2014 12:35:16 +0200 cpuidle: Use

[tip:sched/core] smp: Add new wake_up_all_idle_cpus() function

Commit-ID: c6f4459fc3ba532e896cb678e29b45cb985f82bf Gitweb: http://git.kernel.org/tip/c6f4459fc3ba532e896cb678e29b45cb985f82bf Author: Chuansheng Liu AuthorDate: Thu, 4 Sep 2014 15:17:54 +0800 Committer: Ingo Molnar CommitDate: Fri, 19 Sep 2014 12:35:15 +0200 smp: Add new

[tip:sched/core] sched: Add new API wake_up_if_idle() to wake up the idle cpu

Commit-ID: f6be8af1c95de4a46e325e728900a70ceadb52cf Gitweb: http://git.kernel.org/tip/f6be8af1c95de4a46e325e728900a70ceadb52cf Author: Chuansheng Liu AuthorDate: Thu, 4 Sep 2014 15:17:53 +0800 Committer: Ingo Molnar CommitDate: Fri, 19 Sep 2014 12:35:14 +0200 sched: Add new API

[PATCH 3/3] cpuidle: Using the wake_up_all_idle_cpus() to wake up all idle cpus

Currently kick_all_cpus_sync() or smp_call_function() can not break the polling idle cpu immediately. Here using wake_up_all_idle_cpus() which can wake up the polling idle cpu quickly is much helpful for power. Signed-off-by: Chuansheng Liu --- drivers/cpuidle/cpuidle.c |9 ++--- 1

[PATCH 1/3] sched: Add new API wake_up_if_idle() to wake up the idle cpu

Implementing one new API wake_up_if_idle(), which is used to wake up the idle CPU. Suggested-by: Andy Lutomirski Signed-off-by: Chuansheng Liu --- include/linux/sched.h |1 + kernel/sched/core.c | 19 +++ 2 files changed, 20 insertions(+) diff --git a/include/linux

[PATCH 2/3] smp: Adding new function wake_up_all_idle_cpus()

wake_up_all_idle_cpus() to let all cpus out of idle based on function wake_up_if_idle(). Signed-off-by: Chuansheng Liu --- include/linux/smp.h |2 ++ kernel/smp.c| 22 ++ 2 files changed, 24 insertions(+) diff --git a/include/linux/smp.h b/include/linux/smp.h index 34347f2

[PATCH] ata: Disabling the async PM for JMicron chip 363/361

chip 363/361, we need forcedly to disable the async method. Bug detail: https://bugzilla.kernel.org/show_bug.cgi?id=81551 Reported-by: Jay Signed-off-by: Chuansheng Liu --- drivers/ata/ahci.c | 11 +++ drivers/ata/pata_jmicron.c | 11 +++ 2 files changed, 22

[PATCH 1/3] sched: Add new API wake_up_if_idle() to wake up the idle cpu

Implementing one new API wake_up_if_idle(), which is used to wake up the idle CPU. Suggested-by: Andy Lutomirski Signed-off-by: Chuansheng Liu --- include/linux/sched.h |1 + kernel/sched/core.c | 16 2 files changed, 17 insertions(+) diff --git a/include/linux

[PATCH 2/3] smp: Adding new function wake_up_all_cpus()

wake_up_all_cpus() to let all cpus out of idle based on function wake_up_if_idle(). Signed-off-by: Chuansheng Liu --- include/linux/smp.h |2 ++ kernel/smp.c| 22 ++ 2 files changed, 24 insertions(+) diff --git a/include/linux/smp.h b/include/linux/smp.h index 34347f2

[PATCH 3/3] cpuidle: Using the wake_up_all_cpus() to wake up all idle cpus

Currently kick_all_cpus_sync() or smp_call_function() can not break the polling idle cpu immediately. Here using wake_up_all_cpus() which can wake up the polling idle cpu quickly is much helpful for power. Signed-off-by: Chuansheng Liu --- drivers/cpuidle/cpuidle.c |9 ++--- 1 file

[PATCH 1/3] sched: Add new API wake_up_if_idle() to wake up the idle cpu

Implementing one new API wake_up_if_idle(), which is used to wake up the idle CPU. Suggested-by: Andy Lutomirski Signed-off-by: Chuansheng Liu --- include/linux/sched.h |1 + kernel/sched/core.c | 16 2 files changed, 17 insertions(+) diff --git a/include/linux

[PATCH 2/3] smp: re-implement the kick_all_cpus_sync() with wake_up_if_idle()

Currently using smp_call_function() just woke up the corresponding cpu, but can not break the polling idle loop. Here using the new sched API wake_up_if_idle() to implement it. Signed-off-by: Chuansheng Liu --- kernel/smp.c | 18 +++--- 1 file changed, 11 insertions(+), 7

[PATCH 3/3] cpuidle: Using the kick_all_cpus_sync() to wake up all cpus

Current latency notify callback has the same function with kick_all_cpus_sync(). Here use it directly to remove the redundant code. Signed-off-by: Chuansheng Liu --- drivers/cpuidle/cpuidle.c |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/cpuidle/cpuidle.c

[PATCH] cpuidle: Fix the CPU stuck at C0 for 2-3s after PM_QOS back to DEFAULT

reschedule bit has no harm for them too. With this fix, we saved about 30mV power in our android platform. Signed-off-by: Chuansheng Liu --- drivers/cpuidle/cpuidle.c |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpui

[PATCH v2] usb: gadget: return the right length in ffs_epfile_io()

ace rightly also. Acked-by: Michal Nazarewicz Reviewed-by: David Cohen Signed-off-by: Chuansheng Liu --- drivers/usb/gadget/f_fs.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c index 42f7a0e..780f877 100

[tip:irq/urgent] genirq: Remove racy waitqueue_active check

Commit-ID: c685689fd24d310343ac33942e9a54a974ae9c43 Gitweb: http://git.kernel.org/tip/c685689fd24d310343ac33942e9a54a974ae9c43 Author: Chuansheng Liu AuthorDate: Mon, 24 Feb 2014 11:29:50 +0800 Committer: Thomas Gleixner CommitDate: Thu, 27 Feb 2014 10:54:16 +0100 genirq: Remove racy

[PATCH] usb: gadget: return the right length in ffs_epfile_io()

ace rightly also. Signed-off-by: Chuansheng Liu --- drivers/usb/gadget/f_fs.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c index 2b43343..31ee7af 100644 --- a/drivers/usb/gadget/f_fs.c +++ b/drivers/usb/gadget/f_f

[PATCH] genirq: Fix the possible synchronize_irq() wait-forever

for CPU0 atomic_read() threads_active also. So we need one smp_mb() before waitqueue_active or something like that. Thomas shared one good option that removing waitqueue_active() judgement directly, it will make things to be simple and clear. Cc: Thomas Gleixner Cc: Xiaoming Wang Signed-off-by: Ch

[tip:irq/core] genirq: Update the a comment typo

Commit-ID: b04c644e670f79417f1728e6be310cfd8e6a921b Gitweb: http://git.kernel.org/tip/b04c644e670f79417f1728e6be310cfd8e6a921b Author: Chuansheng Liu AuthorDate: Mon, 10 Feb 2014 16:13:57 +0800 Committer: Thomas Gleixner CommitDate: Wed, 19 Feb 2014 17:26:34 +0100 genirq: Update the a

[PATCH v4 5/5] PM / sleep: Asynchronous threads for suspend_late

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall suspend_late time significantly. This patch is for suspend_late phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 66 ++- 1

[PATCH v4 3/5] PM / sleep: Asynchronous threads for resume_early

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall resume_early time significantly. This patch is for resume_early phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 55 +-- 1

[PATCH v4 4/5] PM / sleep: Asynchronous threads for suspend_noirq

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall suspend_noirq time significantly. This patch is for suspend_noirq phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 68 +++ 1

[PATCH v4 1/5] PM / sleep: Two flags for async suspend_noirq and suspend_late

The patch is a helper adding two new flags for implementing async threads for suspend_noirq and suspend_late. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 24 ++-- include/linux/pm.h| 2 ++ 2 files changed, 24 insertions(+), 2 deletions(-) diff

[PATCH v4 2/5] PM / sleep: Asynchronous threads for resume_noirq

least. With the way of asynchronous threads, we just need wait d3_delay time once in parallel for each calling, which saves much time to resume quickly. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 66 +++ 1 file changed, 50 insertions

[PATCH v4 0/5] Enabling the asynchronous threads for other phases

Hello, This patch series are for enabling the asynchronous threads for the phases resume_noirq, resume_early, suspend_noirq and suspend_late. Just like commit 5af84b82701a and 97df8c12995, with async threads it will reduce the system suspending and resuming time significantly. With these patches

[PATCH v3 2/5] PM / sleep: Asynchronous threads for resume_noirq

least. With the way of asynchronous threads, we just need wait d3_delay time once in parallel for each calling, which saves much time to resume quickly. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 66 +++ 1 file changed, 50 insertions

[PATCH v3 5/5] PM / sleep: Asynchronous threads for suspend_late

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall suspend_late time significantly. This patch is for suspend_late phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 66 ++- 1

[PATCH v3 3/5] PM / sleep: Asynchronous threads for resume_early

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall resume_early time significantly. This patch is for resume_early phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 55 +-- 1

[PATCH v3 1/5] PM / sleep: Two flags for async suspend_noirq and suspend_late

The patch is a helper adding two new flags for implementing async threads for suspend_noirq and suspend_late. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 24 ++-- include/linux/pm.h| 2 ++ 2 files changed, 24 insertions(+), 2 deletions(-) diff

[PATCH v3 4/5] PM / sleep: Asynchronous threads for suspend_noirq

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall suspend_noirq time significantly. This patch is for suspend_noirq phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 68 +++ 1

[PATCH v3 0/5] Enabling the asynchronous threads for other phases

Hello, This patch series are for enabling the asynchronous threads for the phases resume_noirq, resume_early, suspend_noirq and suspend_late. Just like commit 5af84b82701a and 97df8c12995, with async threads it will reduce the system suspending and resuming time significantly. With these patches

[PATCH v2 5/5] PM / sleep: Asynchronous threads for suspend_late

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall suspend_late time significantly. This patch is for suspend_late phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 64 ++- 1

[PATCH v2 4/5] PM / sleep: Asynchronous threads for suspend_noirq

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall suspend_noirq time significantly. This patch is for suspend_noirq phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 68 +++ 1

[PATCH v2 3/5] PM / sleep: Asynchronous threads for resume_early

In analogy with commits 5af84b82701a and 97df8c12995, using asynchronous threads can improve the overall resume_early time significantly. This patch is for resume_early phase. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 55 +-- 1

[PATCH v2 2/5] PM / sleep: Asynchronous threads for resume_noirq

least. With the way of asynchronous threads, we just need wait d3_delay time once in parallel for each calling, which saves much time to resume quickly. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 66 +++ 1 file changed, 50 insertions

[PATCH v2 1/5] PM / sleep: Two flags for async suspend_noirq and suspend_late

The patch is a helper adding two new flags for implementing async threads for suspend_noirq and suspend_late. Signed-off-by: Chuansheng Liu --- drivers/base/power/main.c | 24 ++-- include/linux/pm.h| 2 ++ 2 files changed, 24 insertions(+), 2 deletions(-) diff

[PATCH v2 0/5] Enabling the asynchronous threads for other phases

Hello, This patch series are for enabling the asynchronous threads for the phases resume_noirq, resume_early, suspend_noirq and suspend_late. Just like commit 5af84b82701a and 97df8c12995, with async threads it will reduce the system suspending and resuming time significantly. With these patches

[PATCH 1/2] genirq: Fix the possible synchronize_irq() wait-forever

ver. Here put the increasing thread-active before setting bit RUNTHREAD, which can resolve such race. Signed-off-by: xiaoming wang Signed-off-by: Chuansheng Liu --- kernel/irq/handle.c | 21 - 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/kernel/irq/handle.

[PATCH 2/2] genirq: Fix one typo chasnge

Change the comment "chasnge" to "change". Signed-off-by: Chuansheng Liu --- kernel/irq/manage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 481a13c..4802295 100644 --- a/kernel/irq/manage.c +++ b

[PATCH V2] PM: Enable asynchronous threads for suspend/resume_noirq/late/early phases

Current code has implemented asynchronous threads for dpm_suspend() and dpm_resume(), which saved much time. As commit 5af84b82701a and 97df8c12995 said, the total time can be reduced significantly by running suspend and resume callbacks of device drivers in parallel with each other. For the sus

[PATCH] PM: Enable asynchronous noirq resume threads to save the resuming time

Currently, the dpm_resume_noirq() is done synchronously, and for PCI devices pci_pm_resume_noirq(): pci_pm_resume_noirq() pci_pm_default_resume_early() pci_power_up() pci_raw_set_power_state() Which set the device from D3hot to D0 mostly, for every device, there will be one 10ms(pci_pm_d3_d

[PATCH 3/3] dm snapshot: Calling destroy_work_on_stack() to pair with INIT_WORK_ONSTACK()

In case CONFIG_DEBUG_OBJECTS_WORK is defined, it is needed to call destroy_work_on_stack() which frees the debug object to pair with INIT_WORK_ONSTACK(). Signed-off-by: Liu, Chuansheng --- drivers/md/dm-snap-persistent.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/dm-snap-

[PATCH 1/3] workqueue: Calling destroy_work_on_stack() to pair with INIT_WORK_ONSTACK()

In case CONFIG_DEBUG_OBJECTS_WORK is defined, it is needed to call destroy_work_on_stack() which frees the debug object to pair with INIT_WORK_ONSTACK(). Signed-off-by: Liu, Chuansheng --- kernel/workqueue.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/workqueue.c b/kernel/wo

[PATCH 2/3] xfs: Calling destroy_work_on_stack() to pair with INIT_WORK_ONSTACK()

In case CONFIG_DEBUG_OBJECTS_WORK is defined, it is needed to call destroy_work_on_stack() which frees the debug object to pair with INIT_WORK_ONSTACK(). Signed-off-by: Liu, Chuansheng --- fs/xfs/xfs_bmap_util.c |1 + 1 file changed, 1 insertion(+) diff --git a/fs/xfs/xfs_bmap_util.c b/fs/

[tip:core/locking] mutexes: Give more informative mutex warning in the !lock->owner case

Commit-ID: 91f30a17024ff0d8345e11228af33ee938b13426 Gitweb: http://git.kernel.org/tip/91f30a17024ff0d8345e11228af33ee938b13426 Author: Chuansheng Liu AuthorDate: Wed, 4 Dec 2013 13:58:13 +0800 Committer: Ingo Molnar CommitDate: Tue, 17 Dec 2013 15:35:10 +0100 mutexes: Give more

tty: Removing the deprecated function tty_vhangup_locked()

The function tty_vhangup_locked() was deprecated, removed it from the tty.h also. Signed-off-by: Liu, Chuansheng --- include/linux/tty.h |1 - 1 file changed, 1 deletion(-) diff --git a/include/linux/tty.h b/include/linux/tty.h index 97d660e..a98c85f 100644 --- a/include/linux/tty.h +++ b/

TTY/n_gsm: Removing the wrong tty_unlock/lock() in gsm_dlci_release()

Commit 4d9b109060f690f5c835(tty: Prevent deadlock in n_gsm driver) tried to close all the virtual ports synchronously before closing the phycial ports, so the tty_vhangup() is used. But the tty_unlock/lock() is wrong: tty_release tty_ldisc_release tty_lock_pair(tty, o_tty) < == Here the tty i

[PATCH] locking: Giving mutex warning more precisely in case of !lock->owner

When enabling mutex debugging, in case the imbalanced mutex_unlock() is called, we still get the warning like below: [ 364.208284] DEBUG_LOCKS_WARN_ON(lock->owner != current) But in that case, it is due to imbalanced mutex_unlock calling, and the lock->owner is NULL. Here we can enhance the cas

[PATCH] devres: Freeing the drs after all release() are called

In release_nodes(), it will call dr->node.release() and kfree dr one by one. But sometimes the previous dr maybe be used by next .release(), such as: [50314.855534] [] ? synchronize_irq+0x3f/0xb0 [50314.861193] [] __free_irq+0x149/0x200 [50314.866367] [] free_irq+0x43/0xa0 [50314.871152] [] d

[PATCH] mmc: sdhci: Setting the host->mrq to NULL before executing tuning

In function sdhci_request(), it is possible to do the tuning execution like below: sdhci_request() { spin_lock_irqsave(&host->lock, flags); host->mrq = mrq; ... spin_unlock_irqrestore(&host->lock, flags); <=== Here it is possible one pending finish_tasklet get run

drm/i915: Avoid accessing the stolen address when it is unavailable

In our platform, we hit the the stolen region initialization failure case, such as below log: [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: [0x7b00] And it causes the dev_priv->mm.stolen_base is NULL, in this case, we should avoid accessing it any more. Here is

[SCSI] scsi_lib: avoid the "rejecting I/O to offline device" print storm

When handling the scsi_request_fn(), when the sd offline happened, sometimes we will hit the print storm as below: <3>[ 95.365837] sd 0:0:0:0: rejecting I/O to offline device <3>[ 95.368633] sd 0:0:0:0: rejecting I/O to offline device <3>[ 95.369881] sd 0:0:0:0: rejecting I/O to offline devi

sched/rt: Pick up the throttled rt tasks in case no other non-rt tasks

Meet the case that on CPU2, there are just two tasks to be run, one is one rt task A, another is idle task, but at this time, and the rt_rq is throttled. CPU1 CPU2 staying in idle task; waking up rt task A on target CPU 2;

[PATCH V2] ahci: Changing two module params with static and __read_mostly

Here module parameters ahci_em_messages and devslp_idle_timeout can be set as static and __read_mostly. Signed-off-by: Liu, Chuansheng --- drivers/ata/libahci.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index acfd

[PATCH] ahci: Changing two module params with static and __read_mostly

Here module parameters ahci_em_messages and devslp_idle_timeout can be set as static and __read_mostly. Signed-off-by: Liu, Chuansheng --- drivers/ata/libahci.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c index acfd0f

[PATCH] ACPI / osl: implement acpi_os_sleep() with msleep()

Currently the acpi_os_sleep() is using the schedule_timeout_interruptible(), which can be interrupted by signal, which causes the real sleep time is shorter. According to the ACPI spec: The Sleep term is used to implement long-term timing requirements. Execution is delayed for at least the requir

[tip:x86/reboot] reboot: Re-enable the function of variable reboot_default

Commit-ID: e635be963eb2e9883e8124b75dff0c2e29857a6e Gitweb: http://git.kernel.org/tip/e635be963eb2e9883e8124b75dff0c2e29857a6e Author: Chuansheng Liu AuthorDate: Mon, 9 Sep 2013 19:49:40 +0800 Committer: H. Peter Anvin CommitDate: Tue, 10 Sep 2013 08:48:40 -0700 reboot: Re-enable the

[PATCH] PCI/PM: Removing the function pci_pm_complete()

Commit(88d2613) removed the pm_runtime_put_sync() from pci_pm_complete() to PM core code device_complete(). Here the pci_pm_complete() is doing the same work which can be done in device_complete(), so we can remove it directly. Signed-off-by: liu chuansheng --- drivers/pci/pci-driver.c |9

[PATCH] reboot: re-enable the function of variable reboot_default

commit b3a5d02ee070c(reboot: move arch/x86 reboot= handling to generic kernel) did some cleanup for reboot= command line, but it made the reboot_default to be invalidated. The default value of variable reboot_default should be 1, and if command line reboot= is not set, system will use the default

[PATCH] Fix the race between the fget() and close()

When one thread is calling sys_ioctl(), and another thread is calling sys_close(), current code has protected most cases. But for the below case, it will cause issue: T1T2 T3 sys_close(oldfile)sys_open(newfile)

mfd, arizona: Fix the deadlock between interrupt handler and dpm_suspend

When system try to do the suspend: T1:suspend_thread T2: interrupt thread handler enter_state() arizona_irq_thread() suspend_devices_and_enter()regmap_read() __device_suspend() regm

[PATCH 2/3] genirq: Do not consider the irqs with IRQF_NO_SUSPEND in check_wakeup_irqs()

According to commit 9c6079aa1bf(genirq: Do not consider disabled wakeup irqs), we should not break the suspend when one interrupt has been disabled before suspending and is pending there. But there is another case missed: If an interrupt which is marked IRQF_NO_SUSPEND has been disabled before su

[PATCH 3/3] genirq: Give warning in case calling irq_set_irq_wake with _NO_SUSPEND flag

When one irq is setup with flag IRQF_NO_SUSPEND, it is pointless to call irq_set_irq_wake(). Because check_wakeup_irqs() is just checking the irq which has pending but is in IRQS_SUSPENDED state when do syscore_suspend(). Signed-off-by: liu chuansheng --- kernel/irq/manage.c |8 1

[PATCH 2/3] genirq: Do not consider the irqs with disabling and IRQF_NO_SUSPEND

According to commit 9c6079aa1bf(genirq: Do not consider disabled wakeup irqs), we should not break the suspend when one irq is pending but has been disabled before suspending. But there is another case missed, that one irq with flag IRQF_NO_SUSPEND, which has been disabled before suspending, and

[PATCH 1/3] x86, io_apic: Adding the flag IRQCHIP_SKIP_SET_WAKE

Currently for an ioapic chip irq, if we call irq_set_irq_wake() we will get the ENXIO returning error, but some drivers need the wake-up interrupts pending mechanism. Here adding the flag IRQCHIP_SKIP_SET_WAKE instead of emtpy callback. Signed-off-by: liu chuansheng --- arch/x86/kernel/apic/io

[PATCH 0/3] genirq: Do not consider the irqs with disabling and IRQF_NO_SUSPEND

Meet some issues when operating one ioapic chip irq which is set with _NO_SUSPEND flag and calling irq_set_irq_wake(). Written the below patches, thanks your time to review. [PATCH 1/3] x86, io_apic: Adding the flag IRQCHIP_SKIP_SET_WAKE [PATCH 2/3] genirq: Do not consider the irqs with disablin

[PATCH 2/3 V2] intel_idle: Removing the redundant calculating for dev->state_count

In function intel_idle_cpu_init() and intel_idle_cpuidle_driver_init(), they are having the same for(;;) loop to count the ->state_count. Although intel_idle_cpu_init() can be called at runtime CPU HOTPLUG case, but max_cstate can not be changed at runtime. So the dev->state_count should be == d

[PATCH 3/3] intel_idle: set the state_tables array as __initdata to save mem

Currently, in intel_idle.c, there are 5 state_tables array, every array size is sizeof(struct cpuidle_state) * CPUIDLE_STATE_MAX. As in intel_idle_cpuidle_driver_init(), we have copied the data into intel_idle_driver->state[], so do not need to keep state_tables[] there any more after system init

[PATCH 2/3] intel_idle: Removing the redundant calculating for dev->state_count

In function intel_idle_cpu_init() and intel_idle_cpuidle_driver_init(), they are having the same for(;;) loop. Here in intel_idle_cpu_init(), the dev->state_count can be assigned by drv->state_count directly. Signed-off-by: liu chuansheng --- drivers/idle/intel_idle.c | 30 ++

[PATCH 1/3] intel_idle: changing the continue to break in intel_idle_cpu_init()

According to commit e022e7eb9, the .enter == NULL is the last one in state_tables[]. So just like intel_idle_cpuidle_driver_init(), in case of .enter == NULL, breaking the for(;;) loop directly. Signed-off-by: liu chuansheng --- drivers/idle/intel_idle.c |2 +- 1 files changed, 1 insertion

[PATCH 0/3] intel_idle: set the state_tables array into __initdata to save mem

As Daniel suggested, I did some cleanup before setting the state_tables array into __initdata. Thanks your help to review them. [PATCH 1/3] intel_idle: changing the continue to break in intel_idle_cpu_init() [PATCH 2/3] intel_idle: Removing the redundant calculating for dev->state_count [PATCH 3/

[PATCH] intel_idle: set the state_tables array into __initdata to save mem

Currently, in intel_idle.c, there are 5 state_tables array, every array size is sizeof(struct cpuidle_state) * CPUIDLE_STATE_MAX. But after intel_idle_probe(), just only one array is useful. Here we can just define one static state_table, and initialize it in intel_idle_probe(), and set other da

[PATCH V2] smp: Give WARN()ing when calling smp_call_function_many()/single() in serving irq

Currently the functions smp_call_function_many()/single() will give a WARN()ing only in the case of irqs_disabled(), but that check is not enough to guarantee execution of the SMP cross-calls. In many other cases such as softirq handling/interrupt handling, the two APIs still can not be called, ju

[PATCH] smp: Give WARN()ing when calling smp_call_function_many()/single() in serving irq

Currently the functions smp_call_function_many()/single() will give a WARN()ing only in the case of irqs_disabled(), but that check is not enough to guarantee execution of the SMP cross-calls. In many other cases such as softirq handling/interrupt handling, the two APIs still can not be called, j

[tip:core/locking] smp: Give WARN()ing if in_interrupt() when calling smp_call_function_many()/single()

Commit-ID: b29f39c7c3e75a741a7da88244ec707f293ec04c Gitweb: http://git.kernel.org/tip/b29f39c7c3e75a741a7da88244ec707f293ec04c Author: Chuansheng Liu AuthorDate: Wed, 6 Feb 2013 23:18:21 +0800 Committer: Ingo Molnar CommitDate: Wed, 6 Feb 2013 12:00:30 +0100 smp: Give WARN()ing if

[PATCH] smp: give WARN in case of in_interrupt() when calling smp_call_function_many/single

Currently, in function smp_call_function_many/single, it will give WARN just in case of irqs_disabled(), but it is not enough. In many other cases such as softirq handling/interrupt handling, the two APIs still can not be called, just as the smp_call_function_many() comments said: * You must n

[PATCH] x86/io_apic: Do not unmask the masked-irq when migrating irq in ack_apic_level()

In ack_apic_level(), when there is pending affinity setting for current irq, ioapic_irqd_mask()/ioapic_irqd_unmask() will try to mask the irq and do the irq affinity setting. But at this time, it is possibility that the irq has been masked, in this case, we should not unmask it directly in ioapic

[PATCH] PM / Runtime: return the right value when deferred_resume is true in rpm_suspend()

For the case that in rpm_suspend() and deferred_resume is true, the rpm_resume() will be called, and if rpm_resume() return error, at this time, the device is still in SUSPENDED state. In this case it is still an suspend succeeding case, we should return non-error instead of EAGAIN. An example l

[PATCH] PM / Runtime: Fix the twice judgement in rpm_suspend/resume()

In function rpm_suspend/resume(), when going into the for(;;), the pre-condition judgement has been done, and the variable runtime_status are always protected by &power.lock, so it is not necessary to judge them again before unlock_irq &power.lock in for(;;). This patch clean them up. Signed-off

[PATCH] genirq: Give warning when setup an already-setup non-shared irq

Meet the case when the request_threaded_irq() with the same irq is called twice continually, get the below mismatch info: "IRQ handler type mismatch for IRQ 323" Here give a right warning that like below: "Trying to setup already-setup non-shared IRQ 323" Signed-off-by: liu chuansheng --- kern

[PATCH 2/2] ASoC: core: fix the memory leak in case of remove_aux_dev()

When probing aux_dev, initializing is as below: device_initialize() device_add() So when remove aux_dev, we need do as below: device_del() device_put() Otherwise, the rtd_release() will not be called. So here using device_unregister() to replace device_del(), like the action in soc_remove_link_d

[PATCH 1/2] ASoC: core: fix the memory leak in case of device_add() failure

After called device_initialize(), even device_add() returns error, we still need use the put_device() to release the reference to call rtd_release(), which will do the free() action. Signed-off-by: liu chuansheng --- sound/soc/soc-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(

[PATCH] Bluetooth: fix the oops due to conn->hcon == NULL in shutdown case

Meet one panic issue as below stack: <1>[11340.226404] BUG: unable to handle kernel NULL pointer dereference at 0008 <4>[11340.226619] EIP is at __sco_sock_close+0xe8/0x1a0 <4>[11340.226629] EAX: f063a740 EBX: ECX: f58f4544 EDX: <4>[11340.226640] ESI: dec83e00 EDI: 5f9a081f

[PATCH] mfd, TWL4030: TWL4030 need select REGMAP_I2C

This patch fix the below build error: drivers/built-in.o: In function `twl_probe': drivers/mfd/twl-core.c:1256: undefined reference to `devm_regmap_init_i2c' make: *** [vmlinux] Error 1 Signed-off-by: liu chuansheng --- drivers/mfd/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletion

[PATCH] ASoC: core: giving WARN when device starting from non-off bias with idle_bias_off

Just found some cases that some codec drivers set the bias to _STANDBY and set idle_bias_off to 1 during probing. It will cause unpaired runtime_get_sync/put() issue. Also as Mark suggested, there is no reason to start from _STANDBY bias with idle_bias_off == 1. So here giving one warning when de

[PATCH] mmc: sdio: Removing the unnecessary runtime_get/put in sdio_bus_remove()

The runtime_get_sync() is called during sdio_bus_probe(), then the device will be kept in active runtime state, so not neccessary to call runtime_get_sync/put_noidle() again in sdio_bus_remove(). Signed-off-by: liu chuansheng --- drivers/mmc/core/sdio_bus.c |8 1 files changed, 0 i

[PATCH] ASoC: dapm: Fix the unpaired runtime_get/put cases

Commit f1aac484f7(Take a pm_runtime reference on DAPM devices that are enabled) introduced runtime_get/put calling when devices are in off/non-off bias. It is based on: 1/ device from off to non-off bias is called thru dapm_pre_sequence_async; 2/ device from non-off to off bias is called thru dap

[PATCH] smpboot: calling smpboot_register_percpu_thread is unsafe during one CPU being down

When one CPU is going down, and smpboot_register_percpu_thread is called, there is the race issue below: T1(CPUA): T2(CPUB): _cpu_down()smpboot_register_percpu_thread() smpboot_park_threads() ... __s

[PATCH] watchdog: store the watchdog sample period as a variable

Currently getting the sample period is always thru complex calculation: get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5). But just like the watchdog_thresh, which is not changed often. So we can store the sample period as a variable, and set it as __read_mostly type. Signed-off-by: liu chuanshe

[PATCH V2] watchdog: optimizing the hrtimer interval for power saving

By default, the watchdog threshold is 10, it means every 4s every CPU will receive one hrtimer interrupt, for low power device, it will cause 4-5mV power impact when device is deep sleep. So here want to optimize it as below: 4s + 4s + 4s + 4s + 4s == > 1s + 9s + 9s ... Or 1s + 1s..+ 9s + 9s

[PATCH] watchdog: optimizing the hrtimer interval for power saving

By default, the watchdog threshold is 10, it means every 4s every CPU will receive one hrtimer interrupt, for low power device, it will cause 4-5mV power impact when device is deep sleep. So here want to optimize it as below: 4s + 4s + 4s + 4s + 4s == > 12s + 2s + 2s + 2s + 2s 3/5 1/10 1/10 1/1

[PATCH] watchdog: using u64 in get_sample_period()

In get_sample_period(), unsigned long is not enough: watchdog_thresh * 2 * (NSEC_PER_SEC / 5) case1: watchdog_thresh is 10 by default, the sample value will be: 0xEE6B 2800 case2: set watchdog_thresh is 20, the sample value will be: 0x1 DCD6 5000 >From case2, we need use u64 to express the samp

[PATCH] mmc,sdio: advancing the setting of dev name in mmc_sdio_init_card()

In below call trace: mmc_rescan -> mmc_rescan_try_freq() -> mmc_attach_sdio() -> mmc_sdio_init_card() ... pm_runtime_set_active() ... mmc_add_card() The dev name is set until in mmc_add_card(), but before that, it is possible the dev name is needed, for

[PATCH] mmc,sdio: Fix the panic due to devname NULL when calling pm_runtime_set_active()

Subject: [PATCH] mmc,sdio: Fix the panic due to devname NULL when calling pm_runtime_set_active() Meet one panic as the below: <1>[ 15.067350] BUG: unable to handle kernel NULL pointer dereference at (null) <1>[ 15.074455] IP: [] strlen+0x12/0x20 <4>[ 15.078803] *pde = <0>[ 15

[PATCH] x86/irq,io_apic: Fix wrong unmask_ioapic calling when the irq is masked

There is one typical case will cause this issue, that is: One io-apic interrupt with ONE_SHOT and threaded, when interrupt is coming: handle_fasteoi_irq() --> mask_irq(desc) ... desc->irq_data.chip->irq_eoi(&desc->irq_data)[ack_apic_level] --> ioapic_irqd_mask() ... ioa

  1   2   >