> -Original Message-
> From: Don Zickus [mailto:dzic...@redhat.com]
> Sent: Tuesday, November 27, 2012 4:09 AM
> To: Liu, Chuansheng
> Cc: a...@linux-foundation.org; mi...@kernel.org; r...@sisk.pl;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] watchdog: o
> It seems like a better approach would be to adjust the timer somehow when
> you change c-states. The whole point of the hard and softlockup is to
> detect if scheduled code is either deadlock or hogging the cpu for too long.
>
> If the cpu is in a deep sleep, then nothing is running, right? Wh
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Monday, February 04, 2013 11:16 AM
> To: Li, Fei
> Cc: Rafael J. Wysocki; a...@linux-foundation.org;
> linux-kernel@vger.kernel.org; linux...@vger.kernel.org; Liu, Chuansheng
> S
> >> -#define TIMEOUT(20 * HZ)
> >> +unsigned int __read_mostly sys_freeze_process_timeout_msecs =
> >> 2;
> >
> > 2 does not mean 20 seconds since we can select HZ other than
> 1000.
> > So (20 * HZ) is better than 2.
> >
> [Li, Fei]
> Are you sure
Hi,
Just found some comments as below:
In commit 0beefa208bb3a9e581a60125703
+ /*
+* The switch back from broadcast mode needs to be
+* called with interrupts disabled.
+*/
+local_irq_disable();
+clockeve
n order to keep the usage_count with correct
> > value and runtime power management to behave correctly, call
> > pm_runtime_put(_sync) in such case.
> >
> > Signed-off-by Liu Chuansheng
> > Signed-off-by: Li Fei
> > ---
> > drivers/usb/core/hub.c |3
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, March 01, 2013 8:51 AM
> To: Liu, Chuansheng
> Cc: Alan Stern; Li, Fei; gre...@linuxfoundation.org; Lan, Tianyu;
> sarah.a.sh...@linux.intel.com; linux-...@vger.kernel.org;
> linux-k
> -Original Message-
> From: Wu, Fengguang
> Sent: Wednesday, February 20, 2013 9:07 AM
> To: Andrew Morton
> Cc: Liu, Chuansheng; mi...@kernel.org; pet...@infradead.org;
> jbeul...@suse.com; paul...@linux.vnet.ibm.com; min...@mina86.org;
> srivatsa.b...@linux.vnet.
Hello Thomas,
Sorry to miss the V2 in the subject.
I have updated the comments in this new patch, could you consider to take it
into upstream?
Thanks.
Best Regards
Liu chuansheng
> -Original Message-
> From: Liu, Chuansheng
> Sent: Tuesday, March 12, 2013 5:58 P
ay, March 16, 2013 3:20 AM
> To: Liu, Chuansheng
> Cc: Li, Fei; r...@sisk.pl; a...@linux-foundation.org;
> linux-kernel@vger.kernel.org; ldewan...@nvidia.com
> Subject: Re: [PATCH] pm: print the name of failed suspend function for
> platform
> device
>
> On Mon, Mar
nks.
> -Original Message-
> From: Gross, Mark
> Sent: Monday, August 27, 2012 11:50 PM
> To: Liu, Chuansheng; 'linux-kernel@vger.kernel.org'
> (linux-kernel@vger.kernel.org)
> Cc: h...@linux.intel.com; a...@linux.intel.com; Pan, Jacob jun
> Subject: RE: [PATC
From: liu chuansheng
Subject: [PATCH] drm: Adding the option IRQ_ONESHOT to support irq oneshot
For some platforms, we want the irq is handled as one shot,
then even when we use the irq thread, with this option, the new
irq will come until the irq thread finished.
So we have the requirement for
From: liu chuansheng
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling
This patch is for introducing the irq thread support in drm_irq.
Why we need irq thread in drm_irq code?
In our GPU system, the gpu interrupt handler need some time even > 1ms to
finish,
in that case, the whole system will stay in irq disable status. One case is:
when audio is playing, it sometim
From: liu chuansheng
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the irq handler need >1ms to handle the irq action.
And it will delay the whole system irq handler.
This patch is adding the irq thread support, it will make the drm_irq
interface more flexi
> -Original Message-
> From: Oliver Neukum [mailto:oneu...@suse.de]
> Sent: Wednesday, October 31, 2012 5:03 PM
> To: Liu, Chuansheng
> Cc: john.stu...@linaro.org; t...@linutronix.de; gre...@linuxfoundation.org;
> linux-kernel@vger.kernel.org; Liu, Chuansheng
> Su
away and is never going to change, it's
completely pointless to have a lock in alarmtimer_get_rtcdev() at all.
So this patch remove the lock/unlock actions in alarmtimer_get_rtcdev().
Signed-off-by: liu chuansheng
---
kernel/time/alarmtimer.c | 21 +++--
1 files changed,
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Friday, November 02, 2012 6:56 AM
> To: Liu, Chuansheng
> Cc: john.stu...@linaro.org; gre...@linuxfoundation.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/3]
)
...
class_intf->add_dev()/alarmtimer_rtc_add_device
...
mutex_unlock(&parent->p->mutex);
But also the mutex parent->p->mutex has protected the add_dev()
callback.
So here removing the lock of rtcdev_lock.
Signed-o
> > + } else if (cpumask_test_cpu(cpu, data->affinity))
> > + cpumask_clear_cpu(cpu, data->affinity);
> >
>
> You meant to use 'affinity' (instead of data->affinity) in the above 2
> statements
> right? Note that we do chip->irq_set_affinity(data, affinity, true); furt
> Btw, on a slightly different note, I'm also rather surprised that the above
> code doesn't care about the return value of chip->irq_set_affinity() ..
> Shouldn't we warn if that fails?
It seems another case when irq_set_affinity is NULL whenever affinity is
changed or not before that,
For this
> Shouldn't we warn if that fails?
printk("Cannot set affinity for irq %i\n", irq);
This is the warning when set affinity failed.
> In that case, we would end up with an incorrect data->affinity right?
>
Moving the clean cpu mask code into if (chip->irq_set_affinity)?
Will resend the patch and will judge the chip->irq_set_affinity(data, affinity,
true)
return value.
> I know.. What I meant is, the code warns only if chip->irq_set_affinity
> is NULL and doesn't care if chip->irq_set_affinity was not NULL and
> the function failed to set the affinity (ie., when chip->irq_set_affinity()
> returns error). In other words, I meant to say that this is one more
> case
> Please hold on.. I'm not yet done reviewing, I might have more comments :-)
Sure, welcome, thanks again.
> A return value of 0 and 1 are acceptable. So this check isn't correct.
>
> Regards,
> Srivatsa S. Bhat
>
Which case value 1 is acceptable, could you share? Thanks.
> OMG, why did you drop the other hunk which cleared the cpu *before*
> invoking ->irq_set_affinity()? IMO, altering irq affinity
> -Original Message-
> From: Siddha, Suresh B
> Sent: Tuesday, October 30, 2012 4:24 AM
> To: Liu, Chuansheng
> Cc: mi...@redhat.com; h...@zytor.com; t...@linutronix.de;
> ying...@kernel.org; x...@kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH
> -Original Message-
> From: Peter Zijlstra [mailto:a.p.zijls...@chello.nl]
> Sent: Monday, October 29, 2012 5:06 PM
> To: Liu, Chuansheng
> Cc: t...@linutronix.de; mi...@kernel.org; linux-kernel@vger.kernel.org; Li,
> Fei;
> yanmin_zh...@linux.intel.com
> Subj
Hello Al and Eric,
Thanks your comments, please see the below comments.
> -Original Message-
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Monday, August 26, 2013 7:30 PM
> To: Liu, Chuansheng
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@
Thanks Al.
> -Original Message-
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Tuesday, August 27, 2013 8:43 AM
> To: Liu, Chuansheng
> Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Fi
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Wednesday, September 18, 2013 12:24 AM
> To: Liu, Chuansheng
> Cc: t...@kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ahci: Changing two module para
solve a real problem?
Yes, we already have the 0xCF9 rebooting function, why not support the
COLD/WARM reset both?
Thanks.
For safety and compatibility, we prepared the below patch, do you think is it
making sense?
From: liu chuansheng
Subject: [PATCH] X86, reboot: supporting COLD reset thr
> -Original Message-
> From: Robin Holt [mailto:robinmh...@linux.com]
> Sent: Monday, September 09, 2013 11:07 PM
> To: Liu, Chuansheng
> Cc: mi...@kernel.org; h...@sgi.com; h...@zytor.com;
> rmk+ker...@arm.linux.org.uk; r...@sgi.com; a...@linux-foundation.o
Hello Rafael,
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Wednesday, September 11, 2013 8:37 PM
> To: Liu, Chuansheng
> Cc: l...@kernel.org; linux-a...@vger.kernel.org; linux-kernel@vger.kernel.org;
> Li, Zhuangzhi; Li, Fei
> Subj
Hello Al,
> -Original Message-
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Tuesday, August 27, 2013 8:49 AM
> To: Liu, Chuansheng
> Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Fix th
> -Original Message-
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Saturday, August 31, 2013 2:48 PM
> To: Liu, Chuansheng
> Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Fix the rac
> -Original Message-
> From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> Sent: Saturday, August 31, 2013 3:36 PM
> To: Liu, Chuansheng
> Cc: Eric Dumazet; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Fix the rac
> This patch is corrupted and can not be applied at all. Please fix your email
> client and try again.
>
> greg k-h
I am very sorry to waste your time, resend it again.
From: liu chuansheng
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
Because the IRQF_DISABLED
> This possibly ought to be submitted in parallel with the code that uses it so
> that
> the whole proposal can be evaluated as one thing ?
>
> Alan
Patch is here, thanks.
From: liu chuansheng
Subject: [PATCH] drm_irq: Introducing the irq_thread support
For some GPUs, the i
> For a kms drm driver (and tbh, doing a non-kms driver today is not a great
> idea),
> there's no reason to use the drm_irq_install/_unistall helpers.
>
Can not understand well, I found many GPU drivers are using drm_irq helpers'
function, including ours:)
--
To unsubscribe from this list: sen
> Well, you cant use the pre_install/post_install hooks the drm_irq code
> provides,
> but yes, just do the request_irq in your driver code at the right time, with
> the
> right parameters. Much easier than adding code to a part of the drm core
> fraught with backwards-compat stuff no one really
> > From: liu chuansheng
> > Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
>
> Why is this in the patch?
>
> Please resend it in a format that I do not have to manually edit the patch.
>
> greg k-h
Thanks your teaching, resend again.
Because
Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.
so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();
Signed-off-by: liu
Hi all,
Could some one give help that removing the local_irq_enable() in function
panic()?
Currently I meet one case that when panic happening at irq disabling state with
spin_lock,
After panic() is called, due to local_irq_enable() is called, it causes some
interrupts come,
and cause more iss
> -Original Message-
> From: Liu, Chuansheng
> Sent: Friday, September 07, 2012 5:20 PM
> To: gre...@linuxfoundation.org
> Cc: linux-kernel@vger.kernel.org
> Subject: [PATCH RESEND] USB/host: Cleanup unneccessary irq disable code
>
> Because the IRQF_DISABLED a
> > Signed-off-by: liu chuansheng
> > Acked-by: Alan Stern
> > ---
> > drivers/usb/core/hcd.c | 15 ---
> > drivers/usb/host/ehci-ls1x.c |2 +-
> > drivers/usb/host/ohci-xls.c |2 +-
> > 3 files changed, 2 insertions(+), 1
One suggestion below, thanks.
> -Original Message-
> From: Siddha, Suresh B
> Sent: Thursday, September 27, 2012 6:46 AM
> To: Srivatsa S. Bhat
> Cc: Liu, Chuansheng; t...@linutronix.de; mi...@redhat.com; x...@kernel.org;
> linux-kernel@vger.kernel.org; yanmin_zh...@lin
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Friday, October 19, 2012 2:11 PM
> To: Liu, Chuansheng
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; Siddha, Suresh B;
> mathias.ny...@l
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> impossible !
>
> where is the irq_desc coming from. ?
Any other chip can call function irq_alloc_descs/irq_alloc_desc() to get
irq_desc,
and other chip can has their own chip da
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Tuesday, November 13, 2012 3:32 AM
> To: Martin Steigerwald
> Cc: Liu, Chuansheng; linux-kernel@vger.kernel.org; Ingo Molnar; Greg
> Kroah-Hartman
> Subject: Re: [REGRESSION] 3.7-rc3+g
> -Original Message-
> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
> Sent: Tuesday, November 13, 2012 1:27 AM
> To: Liu, Chuansheng
> Cc: linus.wall...@linaro.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
>
> -Original Message-
> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
> Sent: Tuesday, November 13, 2012 3:58 PM
> To: Liu, Chuansheng
> Cc: linus.wall...@linaro.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
>
> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Wednesday, November 07, 2012 6:40 PM
> To: Liu, Chuansheng
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] firmware loader: Fix the race FW_STATUS_DON
> -Original Message-
> From: Ming Lei [mailto:ming@canonical.com]
> Sent: Thursday, November 08, 2012 10:02 AM
> To: Liu, Chuansheng
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V2] firmware loader: Fix the race FW_STATUS_DON
> $./scripts/checkpatch.pl
> ERROR: space required before the open parenthesis '('
> #97: FILE: drivers/base/firmware_class.c:267:
> + if(!kref_put(&buf->ref, __fw_free_buf))
>
>
> > + spin_unlock(&fwc->lock);
> > }
> >
> > /* direct firmware loading support */
>
> After fixi
s been
> deprecated and in hardirq context the interrupt is disabled.
>
> so in usb/host code:
> Removing the usage of flag IRQF_DISABLED;
> Removing the calling local_irq save/restore actions in irq
> handler usb_hcd_irq();
>
> Signed-off-by: liu c
> -Original Message-
> From: Gustavo Padovan [mailto:gust...@padovan.org]
> Sent: Friday, January 04, 2013 6:03 AM
> To: Liu, Chuansheng
> Cc: mar...@holtmann.org; johan.hedb...@gmail.com;
> linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject:
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Wednesday, December 19, 2012 5:11 PM
> To: Liu, Chuansheng
> Cc: l...@ti.com; pe...@perex.cz; ti...@suse.de; alsa-de...@alsa-project.org;
> linux-kernel@vger.kernel.org
>
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Thursday, December 20, 2012 9:51 PM
> To: Liu, Chuansheng
> Cc: l...@ti.com; pe...@perex.cz; ti...@suse.de; alsa-de...@alsa-project.org;
> linux-kernel@vger.kernel.org
> Subj
Hi Thomas and Ingo,
Could you have a look for this patch? It fix the wrong unmask action.
Thanks.
> -Original Message-
> From: Liu, Chuansheng
> Sent: Thursday, November 15, 2012 12:53 AM
> To: mi...@redhat.com; t...@linutronix.de
> Cc: x...@kernel.org; linux-kernel@vger.
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Saturday, November 17, 2012 3:33 AM
> To: Liu, Chuansheng
> Cc: Chris Ball; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] mmc,sdio: Fix the panic due to
> -Original Message-
> From: Ohad Ben-Cohen [mailto:o...@wizery.com]
> Sent: Monday, November 19, 2012 3:47 PM
> To: Liu, Chuansheng
> Cc: Chris Ball; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] mmc,sdio: Fix the panic due to devname N
Hi Sasha,
> -Original Message-
> From: Sasha Levin [mailto:sasha.le...@oracle.com]
> Sent: Friday, April 19, 2013 5:06 AM
> To: Liu, Chuansheng; Andrew Morton
> Cc: Ingo Molnar; Thomas Gleixner; Peter Zijlstra; Wu, Fengguang;
> eag0...@gmail.com; Dave Jones; linux-kern
> -Original Message-
> From: Li, Fei
> Sent: Thursday, February 28, 2013 5:06 PM
> To: gre...@linuxfoundation.org; Lan, Tianyu; st...@rowland.harvard.edu;
> sarah.a.sh...@linux.intel.com
> Cc: r...@sisk.pl; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Friday, March 01, 2013 10:22 AM
> To: Liu, Chuansheng
> Cc: Li, Fei; gre...@linuxfoundation.org; Lan, Tianyu;
> st...@rowland.harvard.edu; sarah.a.sh...@linux.intel.com;
> linux-...@vger.ker
> -Original Message-
> From: Lai Jiangshan [mailto:eag0...@gmail.com]
> Sent: Wednesday, February 27, 2013 10:51 PM
> To: Liu, Chuansheng
> Cc: mi...@kernel.org; pet...@infradead.org; jbeul...@suse.com;
> paul...@linux.vnet.ibm.com; a...@linux-foundation.org;
&
Hi Mark,
> -Original Message-
> From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: Wednesday, April 10, 2013 8:30 PM
> To: Liu, Chuansheng
> Cc: sa...@linux.intel.com; linux-kernel@vger.kernel.org;
> patc...@opensource.wolfsonmicro.com
> Subject:
> -Original Message-
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Thursday, March 07, 2013 5:49 PM
> To: Liu, Chuansheng
> Cc: l...@kernel.org; Brown, Len; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH
> -Original Message-
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Saturday, March 09, 2013 11:00 AM
> To: Liu, Chuansheng
> Cc: l...@kernel.org; Brown, Len; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/3] int
Hi Greg,
I just noticed some other cases need the more log also.
https://lkml.org/lkml/2013/3/8/71
Could you consider the below patch, thanks?
Best Regards
Liu chuansheng
> -Original Message-
> From: Li, Fei
> Sent: Tuesday, February 05, 2013 1:13 PM
> To: gre...@linuxfound
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Tuesday, March 12, 2013 5:24 AM
> To: Liu, Chuansheng
> Cc: mi...@redhat.com; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 2/3] genirq: Do not consider the irqs with disabling and
From: liu chuansheng
Subject: [PATCH] x86_dump_trace: avoiding endless " " is printed
Found the case that endless " " printing in dump_trace,
and no real meaningful stack traces are output, so there should
be one rare case that possibly context->previous_esp = conte
ive locks if irq handler and irq thread use the
same spin lock.
> -Original Message-
> From: anish singh [mailto:anish198519851...@gmail.com]
> Sent: Tuesday, September 18, 2012 12:31 PM
> To: Liu, Chuansheng
> Subject: Re: [PATCH] genirq: Add the IRQS_ONESHOT support for edge
> Are you sure you have not returned from the irq_thread and how do you
> know that primary handler is called in between when your irq_thread is
> running?
I am sure because the spin recursive locks has been printed with call stack,
further more, with IRQS_ONESHOT, I have printed the value of
irq
> This comment might help.
> kernel/irq/manage.c
>
> } else if (new->handler == irq_default_primary_handler) {
>
> /*
> * The interrupt was requested with handler = NULL, so
> * we use the default primary handler for it. But it
> * does not have the oneshot
From: liu chuansheng
Subject: [PATCH] x86_dump_trace: avoiding endless " " is printed
Found the case that endless " " printing in dump_trace,
and no real meaningful stack traces are output, so there should
one rare case that possibly context->previous_esp = context or
ot
From: liu chuansheng
Subject: [PATCH] x86/fixup_irq: using the cpu_online_mask instead of
cpu_all_mask
When one CPU is going down, and this CPU is the last one in irq affinity,
current code is setting cpu_all_mask as the new affinity for that irq.
But for some system the firmware maybe send
> The endless " " is as below:
> ...
> [ 82.215244,0]
> [ 82.215399,0]
> [ 82.215554,0]
> [ 82.215710,0]
> [ 82.215865,0]
> [ 82.216022,0]
> [ 82.216178,0]
> [ 82.216333,0]
> [ 82.216488,0]
> [ 82.216643,0]
> [ 82.216798,0]
> [ 82.216953,0]
> ...
>
Sorry, I found the latest kernel code has some difference with my analysis.
I need more thoughts, then update this issue.
> -Original Message-
> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
> Sent: Monday, July 09, 2012 9:32 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@
Thanks Samuel and Linus' help.
> -Original Message-
> From: Samuel Ortiz [mailto:sa...@linux.intel.com]
> Sent: Tuesday, January 22, 2013 8:37 AM
> To: Liu, Chuansheng
> Cc: Peter Ujfalusi; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> torva...@lin
.p.zijls...@chello.nl; torva...@linux-foundation.org;
> a...@linux-foundation.org; t...@linutronix.de; Wu, Fengguang; Liu,
> Chuansheng
> Subject: [tip:core/locking] Revert "smp: Give WARN()ing if in_interrupt() when
> calling smp_call_function_many()/single()"
>
> Com
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Friday, October 12, 2012 8:32 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
> thread
>
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Friday, October 12, 2012 8:46 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
> thread
>
FLAG IRQS_ONESHOT does not work well for edge interrupt.
* IRQS_ONESHOT - irq is not unmasked in primary handler
Is it possible give some notification or remind? Thanks. I took some time
to know it:)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> To: Liu, Chuansheng
> Cc: linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
> thread
>
> On Fri, 12 Oct 2012, Liu, Chuansheng wrote:
> > > -Original Message-
> > > From: Thomas Gleixner [mailto:t.
> On SMP an interrupt which is raised after the ack() again before the
> handler finishes, can invoke another delivery on a different CPU,
> which then sees the IRQ_INPROGESS flag, masks it and flags it
> PENDING. When the primary handler on the first CPU returns, it sees
> the PENDING flag, unmask
> -Original Message-
> From: anish kumar [mailto:anish198519851...@gmail.com]
> Sent: Friday, October 12, 2012 11:25 PM
> To: Liu, Chuansheng
> Cc: Thomas Gleixner; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support
> -Original Message-
> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu
> Sent: Wednesday, October 17, 2012 10:03 AM
> To: Liu, Chuansheng
> Cc: t...@linutronix.de; mi...@redhat.com; Siddha, Suresh B;
> linux-kernel@vger.kernel.org
> -Original Message-
> From: Colin Cross [mailto:ccr...@android.com]
> Sent: Thursday, January 10, 2013 9:58 AM
> To: linux-kernel@vger.kernel.org
> Cc: Andrew Morton; Don Zickus; Ingo Molnar; Thomas Gleixner; Liu,
> Chuansheng; linux-arm-ker...@lists.infradead.org; Col
> -Original Message-
> From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of Colin
> Cross
> Sent: Friday, January 11, 2013 1:34 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@vger.kernel.org; Andrew Morton; Don Zickus; Ingo Molnar;
> Thomas Gl
> -Original Message-
> From: ccr...@google.com [mailto:ccr...@google.com] On Behalf Of Colin
> Cross
> Sent: Friday, January 11, 2013 2:18 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@vger.kernel.org; Andrew Morton; Don Zickus; Ingo Molnar;
> Thomas Gl
Hi maintainers,
Could you help to push this patch?
Every time syncing the latest code, always meet this build error.
Sorry to disturb.
> -Original Message-
> From: Peter Ujfalusi [mailto:peter.ujfal...@ti.com]
> Sent: Monday, December 31, 2012 6:04 PM
> To: Liu, Chuansh
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Monday, January 14, 2013 7:16 PM
> To: Liu, Chuansheng
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] genirq: Give warning when setup an already-setup
> non-shared irq
>
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Monday, January 14, 2013 11:30 PM
> To: Rafael J. Wysocki
> Cc: Liu, Chuansheng; linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] PM / Runtime: Fix the
Hi Gustavo,
> -Original Message-
> From: Gustavo Padovan [mailto:gust...@padovan.org]
> Sent: Thursday, January 10, 2013 4:35 AM
> To: Liu, Chuansheng
> Cc: mar...@holtmann.org; johan.hedb...@gmail.com;
> linux-blueto...@vger.kernel.org; linux-kernel@vger.kernel.org
>
> -Original Message-
> From: Bi, Chao
> Sent: Thursday, January 10, 2013 4:27 PM
> To: a...@linux.intel.com; gre...@linuxfoundation.org;
> a...@linux-foundation.org; pavan_sa...@ti.com
> Cc: Liu, Chuansheng; linux-kernel@vger.kernel.org
> Subject: [PATCH] ST_COR
Based on patch commit 401c636a0eeb ("kernel/hung_task.c:
show all hung tasks before panic"), we could get the
call stack of hung task.
However, if the console loglevel is not high, we still
can not get the useful information in practice, and
in most cases users don't set console loglevel to
high
> -Original Message-
> From: Sergey Senozhatsky [mailto:sergey.senozhatsky.w...@gmail.com]
> Sent: Monday, December 10, 2018 1:46 PM
> To: Liu, Chuansheng
> Cc: a...@linux-foundation.org; pmla...@suse.com;
> sergey.senozhat...@gmail.com; rost...@goodmis.org;
Based on patch commit 401c636a0eeb ("kernel/hung_task.c:
show all hung tasks before panic"), we could get the
call stack of hung task.
However, if the console loglevel is not high, we still
can not see the useful panic information in practice,
and in most cases users don't set console loglevel to
> -Original Message-
> From: Petr Mladek [mailto:pmla...@suse.com]
> Sent: Wednesday, December 12, 2018 6:18 PM
> To: Liu, Chuansheng
> Cc: Tetsuo Handa ; Sergey Senozhatsky
> ; a...@linux-foundation.org;
> sergey.senozhat...@gmail.com; rost...@goodmis.org; dvyu..
1 - 100 of 160 matches
Mail list logo
