es are intended.
Nice work. I didn't realize this simplification :)
Regards,
Hao Lee
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 11aa1415d8bd2920ce884356479eabbd64b1df2a
Gitweb:
https://git.kernel.org/tip/11aa1415d8bd2920ce884356479eabbd64b1df2a
Author:Hao Lee
AuthorDate:Sun, 03 Jan 2021 03:08:34
Committer
do_IRQ has been replaced by common_interrupt in
commit fa5e5c409213 ("x86/entry: Use idtentry for interrupts")
Remove its declaration.
Signed-off-by: Hao Lee
---
arch/x86/include/asm/irq.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/irq.h b/arch/x86/i
The string buf will be stripped in cgroup_procs_write_start() before it
is converted to int, so remove this unnecessary call to strstrip().
Signed-off-by: Hao Lee
---
kernel/cgroup/cgroup.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
Ping. Thanks.
On Tue, Sep 08, 2020 at 01:33:50PM +, Hao Lee wrote:
> The string buf will be stripped in cgroup_procs_write_start() before it
> is converted to int, so remove this unnecessary call to strstrip().
>
> Signed-off-by: Hao Lee
> ---
> kernel/cgroup/cgroup.
Hi, ping...
On Sat, Aug 29, 2020 at 10:03:16AM +, Hao Lee wrote:
> css_visible() is called in either cgroup_apply_control_enable()
> or cgroup_apply_control_disable().
> In cgroup_apply_control_enable(), we have checked ss_mask before calling
> css_visible(), so there is n
e checking of CONFIG_ARCH_HAS_PTE_SPECIAL to make the
behavior consistent for all architectures. If my understanding is right,
I can submit a patch to fix this. Thanks.
Regards,
Hao Lee
the latter as the former. So, I
think we'd better remove the checking of CONFIG_ARCH_HAS_PTE_SPECIAL to
make the behavior consistent for all architectures. If my understanding
is right, I can submit a patch to fix this. Thanks.
Regards,
Hao Lee
On Wed, Sep 09, 2020 at 07:54:44AM -0500, Eric W. Biederman wrote:
> Hao Lee writes:
>
> > On Tue, Sep 08, 2020 at 07:48:57PM +0100, Al Viro wrote:
> >> On Tue, Sep 08, 2020 at 01:06:56PM +, Hao Lee wrote:
> >> > ping
> >> >
> >> >
On Tue, Sep 08, 2020 at 07:48:57PM +0100, Al Viro wrote:
> On Tue, Sep 08, 2020 at 01:06:56PM +0000, Hao Lee wrote:
> > ping
> >
> > On Wed, Jul 29, 2020 at 03:21:28PM +, Hao Lee wrote:
> > > The dentry local variable is introduced in 'commit 84d17192d2afd (&q
ping
On Wed, Jul 29, 2020 at 03:21:28PM +, Hao Lee wrote:
> The dentry local variable is introduced in 'commit 84d17192d2afd ("get
> rid of full-hash scan on detaching vfsmounts")' to reduce the length of
> some long statements for example
> mutex_lock(>dentry-&g
Hello,
ping
On Sat, Aug 29, 2020 at 10:03:16AM +, Hao Lee wrote:
> css_visible() is called in either cgroup_apply_control_enable()
> or cgroup_apply_control_disable().
> In cgroup_apply_control_enable(), we have checked ss_mask before calling
> css_visible(), so there is n
The string buf will be stripped in cgroup_procs_write_start() before it
is converted to int, so remove this unnecessary call to strstrip().
Signed-off-by: Hao Lee
---
kernel/cgroup/cgroup.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
ent is not NULL, we have checked ss_mask in the
second condition, so there is no need to do the same thing again.
- If css->parent is NULL, dsct is root cgroup so the deleted if
statement is always false and there is no need to keep it.
Signed-off-by: Hao Lee
---
kernel/cgroup/cgroup.c | 2 --
Ping
On Wed, Jul 29, 2020 at 11:21 PM Hao Lee wrote:
>
> The dentry local variable is introduced in 'commit 84d17192d2afd ("get
> rid of full-hash scan on detaching vfsmounts")' to reduce the length of
> some long statements for example
> mutex_lock(>dentry->d_i
ame thing now, and its length is
acceptable. Furthermore, it seems not concise that assign path->dentry
to local variable dentry in the statement before goto. So, this function
would be more clear if we eliminate the local variable dentry.
The function logic is not changed.
Signed-off-by: Hao
These comments should be updated as memcg limit enforcement has been moved
from zones to nodes.
Signed-off-by: Hao Lee
---
include/linux/memcontrol.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index
The member in struct zonelist is _zonerefs instead of zones.
Signed-off-by: Hao Lee
---
include/linux/mmzone.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 3f38c30d2f13..6d44a49b3f29 100644
--- a/include/linux/mmzone.h
On Mon, 29 Apr 2019 at 22:31, Greg KH wrote:
> This causes build warnings when applied, I'm having to drop it now.
>
> Please be more careful, when submitting patches, always test-build them
> first.
I have found my mistake. Although I have built a kernel to test my
patch, I forget to turn on
The dev_dbg statement should print the value of uart.port.mapbase instead
of its address. Besides that, uart.port.irq and uart.port.iotype are all
unsigned types, so using %u is more appropriate.
Signed-off-by: Hao Lee
---
drivers/tty/serial/8250/8250_pnp.c | 4 ++--
1 file changed, 2
The dev_dbg statement should print the value of uart.port.mapbase instead
of its address. Besides that, uart.port.irq and uart.port.iotype are all
unsigned types, so using %u is more appropriate.
Signed-off-by: Hao Lee
---
drivers/tty/serial/8250/8250_pnp.c | 4 ++--
1 file changed, 2
On Sat, 27 Apr 2019 at 16:09, Greg KH wrote:
>
> On Sat, Apr 27, 2019 at 04:00:15PM +0800, Hao Lee wrote:
> > The variable type and the type field is inconsistent.
>
> In what way? Please be very specific when you resend this.
The main problem is the dev_dbg statement shou
The variable type and the type field is inconsistent.
Signed-off-by: Hao Lee
---
drivers/tty/serial/8250/8250_pnp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pnp.c
b/drivers/tty/serial/8250/8250_pnp.c
index 431e69a5a6a0..9dea11baf479
On Tue, Jun 20, 2017 at 3:05 AM, Rasmus Villemoes
<li...@rasmusvillemoes.dk> wrote:
> On Mon, Jun 19 2017, Vlastimil Babka <vba...@suse.cz> wrote:
>
>> On 06/19/2017 03:54 PM, Hao Lee wrote:
>>> The variable current_order decreases from MAX_ORDER-1 to order, s
On Tue, Jun 20, 2017 at 3:05 AM, Rasmus Villemoes
wrote:
> On Mon, Jun 19 2017, Vlastimil Babka wrote:
>
>> On 06/19/2017 03:54 PM, Hao Lee wrote:
>>> The variable current_order decreases from MAX_ORDER-1 to order, so the
>>> condition current_order <= MAX_ORDER
The variable current_order decreases from MAX_ORDER-1 to order, so the
condition current_order <= MAX_ORDER-1 is always true.
Signed-off-by: Hao Lee <haolee.sw...@gmail.com>
---
mm/page_alloc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/page_all
The variable current_order decreases from MAX_ORDER-1 to order, so the
condition current_order <= MAX_ORDER-1 is always true.
Signed-off-by: Hao Lee
---
mm/page_alloc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2302
Fix variable name error in comments. No code changes.
Signed-off-by: Hao Lee <haolee.sw...@gmail.com>
---
include/linux/gfp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index db373b9..ff3d651 100644
--- a/include/linux
Fix variable name error in comments. No code changes.
Signed-off-by: Hao Lee
---
include/linux/gfp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index db373b9..ff3d651 100644
--- a/include/linux/gfp.h
+++ b/include/linux
for some
platforms. Therefore, to have a better tolerance, the DW_IC_SDA_HOLD
value should be kept by sda_hold_time.
Signed-off-by: Zhuo-hao Lee <zhuo-hao@intel.com>
---
drivers/i2c/busses/i2c-designware-core.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff
for some
platforms. Therefore, to have a better tolerance, the DW_IC_SDA_HOLD
value should be kept by sda_hold_time.
Signed-off-by: Zhuo-hao Lee
---
drivers/i2c/busses/i2c-designware-core.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c
e HPET RTC emulation fires an interrupt every
16ms(=1/2^DEFAULT_RTC_SHIFT) up to the point where the alarm time is reached.
This program always hits this situation(https://lkml.org/lkml/2015/11/8/326),
if system wake up earlier than alarm time.
Cc: Thomas Gleixner
Cc: John Stultz
Signed-off-by: Zh
tronix.de>
Cc: John Stultz <john.stu...@linaro.org>
Signed-off-by: Zhuo-hao Lee <zhuo-hao@intel.com>
---
kernel/time/alarmtimer.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 7fbba63..e840ed8 100
sleep over time. However,
if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
timeout. To fix this problem, just adding alarmtimer_resume to cancel the
RTC timer.
Signed-off-by: Zhuo-hao Lee
---
k
sleep over time. However,
if the system wakeup early than RTC timeout, the RTC timer will not be cleared.
And this will cause the hpet_rtc_interrupt come unexpectedly until the RTC
timeout. To fix this problem, just adding alarmtimer_resume to cancel the
RTC timer.
Signed-off-by: Zhuo-hao Lee
---
k
ned-off-by: Zhuo-hao Lee <zhuo-hao@intel.com>
---
kernel/time/alarmtimer.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 7fbba63..37ffccd 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtime
ned-off-by: Zhuo-hao Lee <zhuo-hao@intel.com>
---
kernel/time/alarmtimer.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 7fbba63..e840ed8 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtime
37 matches
Mail list logo
