Re: [PATCH] acpi, numa, ia64: Parse all entries of SRAT memory affinity table

On Thu, Nov 16, 2017 at 12:16 AM, Luck, Tony wrote: >> This check is already added in x86 and extending same to ia64. > > Looks OK. > > Acked-by: Tony Luck thanks Tony. ACPI Maintainers, any comments on this patch? i can send rebasing to 4.15-rc1?

Re: [PATCH] acpi, numa, ia64: Parse all entries of SRAT memory affinity table

On Thu, Nov 16, 2017 at 12:16 AM, Luck, Tony wrote: >> This check is already added in x86 and extending same to ia64. > > Looks OK. > > Acked-by: Tony Luck thanks Tony. ACPI Maintainers, any comments on this patch? i can send rebasing to 4.15-rc1? thanks Ganapat

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Mon, 20 Nov 2017 11:30:40 -0500 joe.ko...@concurrent-rt.com wrote: > Hi Steve, > A quick perusal of 4.11.12-rt16 shows that it has an > entirely new version of migrate_disable which to me appears > correct. > > In that new implementation, migrate_enable() recalculates > p->nr_cpus_allowed

Re: [PATCH] 4.4.86-rt99: fix sync breakage between nr_cpus_allowed and cpus_allowed

On Mon, 20 Nov 2017 11:30:40 -0500 joe.ko...@concurrent-rt.com wrote: > Hi Steve, > A quick perusal of 4.11.12-rt16 shows that it has an > entirely new version of migrate_disable which to me appears > correct. > > In that new implementation, migrate_enable() recalculates > p->nr_cpus_allowed

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

On Mon, 20 Nov 2017, Guenter Roeck wrote: > On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 > > > start_off=536000 region=c0536000 > > > > If

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

On Mon, 20 Nov 2017, Guenter Roeck wrote: > On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 > > > start_off=536000 region=c0536000 > > > > If

Re: [PATCH v3] tracing: Allocate mask_str buffer dynamically

On Mon, 20 Nov 2017 21:33:23 +0800 "Du, Changbin" wrote: > Hi Steven, > Have you picked up this patch or need more polish? Thanks. > Neither. You sent this while I was traveling, and it was missed. I'll look at it tomorrow. Thanks, -- Steve

Re: [PATCH v3] tracing: Allocate mask_str buffer dynamically

On Mon, 20 Nov 2017 21:33:23 +0800 "Du, Changbin" wrote: > Hi Steven, > Have you picked up this patch or need more polish? Thanks. > Neither. You sent this while I was traveling, and it was missed. I'll look at it tomorrow. Thanks, -- Steve

Re: [PATCH 0/13] scsi: arcmsr: add some driver options and support new adapter ARC-1884

On Mon, 2017-11-20 at 22:03 -0500, Martin K. Petersen wrote: > Ching, > > > The following patches apply to Martin's 4.15/scsi-queue. > > Applied to 4.16/scsi-queue. Thank you! > Hi Martin, Thank you for response. These patches can apply to 4.16/scsi-queue is very good. It will be very

Re: [PATCH 0/13] scsi: arcmsr: add some driver options and support new adapter ARC-1884

On Mon, 2017-11-20 at 22:03 -0500, Martin K. Petersen wrote: > Ching, > > > The following patches apply to Martin's 4.15/scsi-queue. > > Applied to 4.16/scsi-queue. Thank you! > Hi Martin, Thank you for response. These patches can apply to 4.16/scsi-queue is very good. It will be very

[PATCH] arm64: kaslr: Fix kaslr end boundary of virt addr

With kaslr and kasan enable both, I got the follow issue. [ 16.130523s]kasan: reg->base = 1, phys_end =1c000,start = 4000, end = ffc0 [ 16.142517s]___alloc_bootmem_nopanic:257 [ 16.148284s]__alloc_memory_core_early:63, addr = 197fc7fc0 [

[PATCH] arm64: kaslr: Fix kaslr end boundary of virt addr

With kaslr and kasan enable both, I got the follow issue. [ 16.130523s]kasan: reg->base = 1, phys_end =1c000,start = 4000, end = ffc0 [ 16.142517s]___alloc_bootmem_nopanic:257 [ 16.148284s]__alloc_memory_core_early:63, addr = 197fc7fc0 [

Re: [PATCH] platform/x86: Add Acer Wireless Radio Control driver

On Mon, Nov 20, 2017 at 8:24 PM, Andy Shevchenko wrote: > On Mon, Nov 20, 2017 at 8:31 AM, Chris Chiu wrote: >> On Fri, Nov 17, 2017 at 10:25 PM, Andy Shevchenko >> wrote: >>> On Thu, Nov 16, 2017 at 3:44 PM, Chris Chiu

Re: [PATCH] platform/x86: Add Acer Wireless Radio Control driver

On Mon, Nov 20, 2017 at 8:24 PM, Andy Shevchenko wrote: > On Mon, Nov 20, 2017 at 8:31 AM, Chris Chiu wrote: >> On Fri, Nov 17, 2017 at 10:25 PM, Andy Shevchenko >> wrote: >>> On Thu, Nov 16, 2017 at 3:44 PM, Chris Chiu wrote: > + +struct acer_wireless_data { + struct

Re: [PATCH] MIPS: Fix CPS SMP NS16550 UART defaults

On 11/20/2017 04:02 PM, James Hogan wrote: From: James Hogan The MIPS_CPS_NS16550_BASE and MIPS_CPS_NS16550_SHIFT options have no defaults for non-Malta platforms which select SYS_SUPPORTS_MIPS_CPS (i.e. the pistachio and generic platforms). This is problematic for automated

Re: [PATCH] MIPS: Fix CPS SMP NS16550 UART defaults

On 11/20/2017 04:02 PM, James Hogan wrote: From: James Hogan The MIPS_CPS_NS16550_BASE and MIPS_CPS_NS16550_SHIFT options have no defaults for non-Malta platforms which select SYS_SUPPORTS_MIPS_CPS (i.e. the pistachio and generic platforms). This is problematic for automated allyesconfig and

Re: [PATCH] cpufreq: mediatek: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

On 20-11-17, 13:32, Jesse Chan wrote: > This change resolves a new compile-time warning > when built as a loadable module: > > WARNING: modpost: missing MODULE_LICENSE() in > drivers/cpufreq/mediatek-cpufreq.o > see include/linux/module.h for more information > > This adds the license as "GPL

Re: [PATCH] cpufreq: mediatek: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE

On 20-11-17, 13:32, Jesse Chan wrote: > This change resolves a new compile-time warning > when built as a loadable module: > > WARNING: modpost: missing MODULE_LICENSE() in > drivers/cpufreq/mediatek-cpufreq.o > see include/linux/module.h for more information > > This adds the license as "GPL

Re: [PATCH] bfa: remove unused pointer 'port'

Colin, > The pointer 'port' is being assigned but it is never read, hence it is > redundant and can be removed. Cleans up clang warning: > > drivers/scsi/bfa/bfad_attr.c:505:2: warning: Value stored to 'port' > is never read Applied to 4.16/scsi-queue. Thanks, Colin! -- Martin K. Petersen

Re: [PATCH] bfa: remove unused pointer 'port'

Colin, > The pointer 'port' is being assigned but it is never read, hence it is > redundant and can be removed. Cleans up clang warning: > > drivers/scsi/bfa/bfad_attr.c:505:2: warning: Value stored to 'port' > is never read Applied to 4.16/scsi-queue. Thanks, Colin! -- Martin K. Petersen

Re: [PATCH] scsi: aacraid: remove unused variable managed_request_id

Colin, > Variable managed_request_id is being assigned but it is never read, > hence it is redundant and can be removed. Cleans up clang warning: Applied to 4.16/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: aacraid: remove unused variable managed_request_id

Colin, > Variable managed_request_id is being assigned but it is never read, > hence it is redundant and can be removed. Cleans up clang warning: Applied to 4.16/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper

On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote: > > Is there some specific scenario where you need to call > blk_schedule_flush_plug from rt_spin_lock_fastlock? Excellent question.  What's the difference between not getting IO started because you meet a mutex with an rt_mutex under

Re: [PATCH PREEMPT RT] rt-mutex: fix deadlock in device mapper

On Mon, 2017-11-20 at 16:33 -0500, Mikulas Patocka wrote: > > Is there some specific scenario where you need to call > blk_schedule_flush_plug from rt_spin_lock_fastlock? Excellent question.  What's the difference between not getting IO started because you meet a mutex with an rt_mutex under

Re: [PATCH 13/16] x86/entry/64: Create a percpu SYSCALL entry trampoline

On Mon, Nov 20, 2017 at 6:34 PM, Josh Poimboeuf wrote: > On Mon, Nov 20, 2017 at 09:07:44AM -0800, Andy Lutomirski wrote: >> + /* Save RDI, since we need a scratch register. */ >> + pushq %rdi >> + >> + /* >> + * x86 lacks a near absolute jump, and we can't

Re: [PATCH 13/16] x86/entry/64: Create a percpu SYSCALL entry trampoline

On Mon, Nov 20, 2017 at 6:34 PM, Josh Poimboeuf wrote: > On Mon, Nov 20, 2017 at 09:07:44AM -0800, Andy Lutomirski wrote: >> + /* Save RDI, since we need a scratch register. */ >> + pushq %rdi >> + >> + /* >> + * x86 lacks a near absolute jump, and we can't jump to the real >>

Re: Improving documentation of parent-ID field in /proc/PID/mountinfo

On Mon, Nov 20, 2017 at 10:07:29AM +0100, Michael Kerrisk (man-pages) wrote: > Hi Miklos, > > Sorry for the slow follow-up. > > On 14 November 2017 at 17:16, Miklos Szeredi wrote: > > On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages) > >

Re: Improving documentation of parent-ID field in /proc/PID/mountinfo

On Mon, Nov 20, 2017 at 10:07:29AM +0100, Michael Kerrisk (man-pages) wrote: > Hi Miklos, > > Sorry for the slow follow-up. > > On 14 November 2017 at 17:16, Miklos Szeredi wrote: > > On Tue, Nov 14, 2017 at 8:08 AM, Michael Kerrisk (man-pages) > > wrote: > >> Hi Miklos, Ram > >> > >> Thanks

Re: [PATCH] pinctrl: intel: Initialize GPIO properly when used through irqchip

On Mon, Nov 20, 2017 at 11:19 PM, Mika Westerberg wrote: > When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver > switches the pin to GPIO mode and makes sure interrupts are routed to > the GPIO hardware instead of IOAPIC. However, if the GPIO

Re: [PATCH] pinctrl: intel: Initialize GPIO properly when used through irqchip

On Mon, Nov 20, 2017 at 11:19 PM, Mika Westerberg wrote: > When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver > switches the pin to GPIO mode and makes sure interrupts are routed to > the GPIO hardware instead of IOAPIC. However, if the GPIO is used > directly through

Re: [PATCH] scsi: csiostor: remove unneeded DRIVER_LICENSE #define

Greg, > There is no need to #define the license of the driver, just put it in > the MODULE_LICENSE() line directly as a text string. > > This allows tools that check that the module license matches the source > code license to work properly, as there is no need to unwind the > unneeded

Re: [PATCH] scsi: csiostor: remove unneeded DRIVER_LICENSE #define

Greg, > There is no need to #define the license of the driver, just put it in > the MODULE_LICENSE() line directly as a text string. > > This allows tools that check that the module license matches the source > code license to work properly, as there is no need to unwind the > unneeded

Re: [PATCH 3/3] scsi: 3w-9xxx: rework lock timeouts

Arnd, > The TW_IOCTL_GET_LOCK ioctl uses do_gettimeofday() to check whether a > lock has expired. This can misbehave due to a concurrent > settimeofday() call, as it is based on 'real' time, and it will > overflow in y2038 on 32-bit architectures, producing unexpected > results when used across

Re: [PATCH 3/3] scsi: 3w-9xxx: rework lock timeouts

Arnd, > The TW_IOCTL_GET_LOCK ioctl uses do_gettimeofday() to check whether a > lock has expired. This can misbehave due to a concurrent > settimeofday() call, as it is based on 'real' time, and it will > overflow in y2038 on 32-bit architectures, producing unexpected > results when used across

Re: [PATCH 2/3] scsi: 3ware: use 64-bit times for FW time sync

Arnd, > The calculation of the number of seconds since Sunday 00:00:00 > overflows in 2106, meaning that we instead will return the seconds > since Wednesday 06:28:16 afterwards. > > Using 64-bit time stamps avoids this slight inconsistency, and the > deprecated do_gettimeofday(), replacing it

Re: [PATCH 2/3] scsi: 3ware: use 64-bit times for FW time sync

Arnd, > The calculation of the number of seconds since Sunday 00:00:00 > overflows in 2106, meaning that we instead will return the seconds > since Wednesday 06:28:16 afterwards. > > Using 64-bit time stamps avoids this slight inconsistency, and the > deprecated do_gettimeofday(), replacing it

[PATCH v3] x86/umip: Warn if UMIP-protected instructions are used

Print a rate-limited warning when a user space program attempts to execute any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR and SMSW). This is useful because, when CONFIG_X86_INTEL_UMIP is selected and supported by the hardware, user space programs that try to execute such

[PATCH v3] x86/umip: Warn if UMIP-protected instructions are used

Print a rate-limited warning when a user space program attempts to execute any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR and SMSW). This is useful because, when CONFIG_X86_INTEL_UMIP is selected and supported by the hardware, user space programs that try to execute such

Re: [PATCH 1/3] scsi: 3ware: fix 32-bit time calculations

Arnd, > twl_aen_queue_event/twa_aen_queue_event, we use do_gettimeofday() > to read the lower 32 bits of the current time in seconds, to pass > them to the TW_IOCTL_GET_NEXT_EVENT ioctl or the 3ware_aen_read > sysfs file. > > This will overflow on all architectures in year 2106, there is > not

Re: [PATCH 1/3] scsi: 3ware: fix 32-bit time calculations

Arnd, > twl_aen_queue_event/twa_aen_queue_event, we use do_gettimeofday() > to read the lower 32 bits of the current time in seconds, to pass > them to the TW_IOCTL_GET_NEXT_EVENT ioctl or the 3ware_aen_read > sysfs file. > > This will overflow on all architectures in year 2106, there is > not

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

On Mon, Nov 20, 2017 at 11:53:02PM +0100, Arnd Bergmann wrote: > .B EINVAL > +The > +.I clk_id > +specified is not supported on this system. We return EINVAL when the clockid is not valid. That can mean two things. Either the SYS-V style hard coded positive clockid is out of range, or the

Re: [PATCH 0/7] scsi: bfa: do_gettimeofday removal

Arnd, > The bfa driver is one of the main users of do_gettimeofday(), a > function that I'm trying to remove as part of the y2038 cleanup. > > The timestamps are all uses in slightly different ways, so this has > turned into a rather longish series for doing something that should be > simple. >

Re: [PATCH] [man-pages] adjtimex.2: document clock_adjtime

On Mon, Nov 20, 2017 at 11:53:02PM +0100, Arnd Bergmann wrote: > .B EINVAL > +The > +.I clk_id > +specified is not supported on this system. We return EINVAL when the clockid is not valid. That can mean two things. Either the SYS-V style hard coded positive clockid is out of range, or the

Re: [PATCH 0/7] scsi: bfa: do_gettimeofday removal

Arnd, > The bfa driver is one of the main users of do_gettimeofday(), a > function that I'm trying to remove as part of the y2038 cleanup. > > The timestamps are all uses in slightly different ways, so this has > turned into a rather longish series for doing something that should be > simple. >

Re: [PATCH 0/13] scsi: arcmsr: add some driver options and support new adapter ARC-1884

Ching, > The following patches apply to Martin's 4.15/scsi-queue. Applied to 4.16/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 0/13] scsi: arcmsr: add some driver options and support new adapter ARC-1884

Ching, > The following patches apply to Martin's 4.15/scsi-queue. Applied to 4.16/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 1/6] mmc: renesas_sdhc: remove eprobe jump label

2017-11-21 5:31 GMT+09:00 Wolfram Sang : > >> - ret = PTR_ERR(priv->clk); >> - dev_err(>dev, "cannot get clock: %d\n", ret); >> - goto eprobe; >> + dev_err(>dev, "cannot get clock\n"); >> + return PTR_ERR(priv->clk); >

Re: [PATCH 1/6] mmc: renesas_sdhc: remove eprobe jump label

2017-11-21 5:31 GMT+09:00 Wolfram Sang : > >> - ret = PTR_ERR(priv->clk); >> - dev_err(>dev, "cannot get clock: %d\n", ret); >> - goto eprobe; >> + dev_err(>dev, "cannot get clock\n"); >> + return PTR_ERR(priv->clk); > > Why dropping the

linux-next: Tree for Nov 21

Hi all, Please do not add any v4.16 material to your linux-next included trees until v4.15-rc1 has been released. Changes since 20171120: I have removed the following trees since they have not been updated in over a year: backlight-fixes berlin binfmt_misc

linux-next: Tree for Nov 21

Hi all, Please do not add any v4.16 material to your linux-next included trees until v4.15-rc1 has been released. Changes since 20171120: I have removed the following trees since they have not been updated in over a year: backlight-fixes berlin binfmt_misc

Re: [PATCH 13/16] x86/entry/64: Create a percpu SYSCALL entry trampoline

On Mon, Nov 20, 2017 at 09:07:44AM -0800, Andy Lutomirski wrote: > + /* Save RDI, since we need a scratch register. */ > + pushq %rdi > + > + /* > + * x86 lacks a near absolute jump, and we can't jump to the real > + * entry text with a relative jump, so we use a double

Re: [PATCH 13/16] x86/entry/64: Create a percpu SYSCALL entry trampoline

On Mon, Nov 20, 2017 at 09:07:44AM -0800, Andy Lutomirski wrote: > + /* Save RDI, since we need a scratch register. */ > + pushq %rdi > + > + /* > + * x86 lacks a near absolute jump, and we can't jump to the real > + * entry text with a relative jump, so we use a double

Re: [PATCH] scsi: ppa: mark expected switch fall-throughs

Gustavo A., > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. Applied to 4.16/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: ppa: mark expected switch fall-throughs

Gustavo A., > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. Applied to 4.16/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] fnic: use 64-bit timestamps

> struct timespec is deprecated since it overflows in 2038 on 32-bit > architectures, so we should use timespec64 consistently. > > I'm slightly adapting the format strings here, to make sure we print > the nanoseconds with the correct number of leading zeroes. Satish: Please review/test. Thank

Re: [PATCH] fnic: use 64-bit timestamps

> struct timespec is deprecated since it overflows in 2038 on 32-bit > architectures, so we should use timespec64 consistently. > > I'm slightly adapting the format strings here, to make sure we print > the nanoseconds with the correct number of leading zeroes. Satish: Please review/test. Thank

Re: [PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

On Mon, Nov 20, 2017 at 05:39:34PM -0800, Andy Lutomirski wrote: > On Mon, Nov 20, 2017 at 1:55 PM, Josh Poimboeuf wrote: > > On Mon, Nov 20, 2017 at 01:30:12PM -0800, Andy Lutomirski wrote: > >> On Mon, Nov 20, 2017 at 1:27 PM, Josh Poimboeuf > >>

Re: [PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

On Mon, Nov 20, 2017 at 05:39:34PM -0800, Andy Lutomirski wrote: > On Mon, Nov 20, 2017 at 1:55 PM, Josh Poimboeuf wrote: > > On Mon, Nov 20, 2017 at 01:30:12PM -0800, Andy Lutomirski wrote: > >> On Mon, Nov 20, 2017 at 1:27 PM, Josh Poimboeuf > >> wrote: > >> > On Mon, Nov 20, 2017 at

Re: [PATCH] scsi: bnx2i: bnx2i_hwi: use swap macro in bnx2i_send_iscsi_nopout

Gustavo A., > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. Applied to 4.16/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: bnx2i: bnx2i_hwi: use swap macro in bnx2i_send_iscsi_nopout

Gustavo A., > Make use of the swap macro and remove unnecessary variable tmp. > This makes the code easier to read and maintain. Applied to 4.16/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

On Sun, Nov 19, 2017 at 1:36 AM, LEROY Christophe wrote: > Meelis Roos a écrit : > >>> > > How early does it hang ? Any oops or trace ? >>> > >>> > Very early - instead oif kernel emssages, I see some repeated gibberish >>> > of some characteers, and the

Re: STRICT_KERNEL_RWX on PPC32 is broken on PowerMac G4

On Sun, Nov 19, 2017 at 1:36 AM, LEROY Christophe wrote: > Meelis Roos a écrit : > >>> > > How early does it hang ? Any oops or trace ? >>> > >>> > Very early - instead oif kernel emssages, I see some repeated gibberish >>> > of some characteers, and the background turns white. >>> > I am

[PATCH] mm: migrate: fix an incorrect call of prep_transhuge_page()

From: Zi Yan In [1], Andrea reported that during memory hotplug/hot remove prep_transhuge_page() is called incorrectly on non-THP pages for migration, when THP is on but THP migration is not enabled. This leads to a bad state of target pages for migration. This patch

[PATCH] mm: migrate: fix an incorrect call of prep_transhuge_page()

From: Zi Yan In [1], Andrea reported that during memory hotplug/hot remove prep_transhuge_page() is called incorrectly on non-THP pages for migration, when THP is on but THP migration is not enabled. This leads to a bad state of target pages for migration. This patch fixes it by only calling

[PATCH] x86/smpboot: set topology CPU mask before use.

From: Zhang Ning we detect topology CPU mask in tsc is used before it is set, it leads to longer bootup time. let's check the code. smpboot.c:smp_callin() ---> calibarate.c:calibrate_delay() ---> tsc.c: calibrate_delay_is_known() --->

[PATCH] x86/smpboot: set topology CPU mask before use.

From: Zhang Ning we detect topology CPU mask in tsc is used before it is set, it leads to longer bootup time. let's check the code. smpboot.c:smp_callin() ---> calibarate.c:calibrate_delay() ---> tsc.c: calibrate_delay_is_known() ---> topology_core_cpumask(): read

Re: [PATCH 3/3] autofs - fix AT_NO_AUTOMOUNT not being honored

On Wed, May 10 2017, Ian Kent wrote: > The fstatat(2) and statx() calls can pass the flag AT_NO_AUTOMOUNT > which is meant to clear the LOOKUP_AUTOMOUNT flag and prevent triggering > of an automount by the call. But this flag is unconditionally cleared > for all stat family system calls except

Re: [PATCH 3/3] autofs - fix AT_NO_AUTOMOUNT not being honored

On Wed, May 10 2017, Ian Kent wrote: > The fstatat(2) and statx() calls can pass the flag AT_NO_AUTOMOUNT > which is meant to clear the LOOKUP_AUTOMOUNT flag and prevent triggering > of an automount by the call. But this flag is unconditionally cleared > for all stat family system calls except

Re: [alsa-devel] [PATCH 2/2] ASoC: fsl_ssi: serialize AC'97 register access operations

On Mon, Nov 20, 2017 at 11:16:07PM +0100, Maciej S. Szmigiero wrote: > AC'97 register access operations (both read and write) on SSI use a one, > shared set of SSI registers for AC'97 register address and data. > This means that only one such access is possible at a time and so all these >

Re: [alsa-devel] [PATCH 2/2] ASoC: fsl_ssi: serialize AC'97 register access operations

On Mon, Nov 20, 2017 at 11:16:07PM +0100, Maciej S. Szmigiero wrote: > AC'97 register access operations (both read and write) on SSI use a one, > shared set of SSI registers for AC'97 register address and data. > This means that only one such access is possible at a time and so all these >

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote: >> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary >> wrote: >>> On Friday 17 November 2017 18:41:17 Ilia Mirkin

Re: Blank console but X11 works on MCP79 - old regression since 3.8

On Sat, Nov 18, 2017 at 12:23 AM, Ilia Mirkin wrote: > On Fri, Nov 17, 2017 at 2:37 PM, Ilia Mirkin wrote: >> On Fri, Nov 17, 2017 at 2:25 PM, Ondrej Zary >> wrote: >>> On Friday 17 November 2017 18:41:17 Ilia Mirkin wrote: On Fri, Nov 17, 2017 at 12:33 PM, Ondrej Zary wrote:

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > On Mon, Nov 20, 2017 at 03:21:32PM -0500, Nicolas Pitre wrote: > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > > > On Mon, Nov 20, 2017 at 01:18:38PM -0500, Nicolas Pitre

Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)

On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > On Mon, Nov 20, 2017 at 03:21:32PM -0500, Nicolas Pitre wrote: > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > > > On Mon, Nov 20, 2017 at 01:18:38PM -0500, Nicolas Pitre

Re: [PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

On Mon, Nov 20, 2017 at 1:55 PM, Josh Poimboeuf wrote: > On Mon, Nov 20, 2017 at 01:30:12PM -0800, Andy Lutomirski wrote: >> On Mon, Nov 20, 2017 at 1:27 PM, Josh Poimboeuf wrote: >> > On Mon, Nov 20, 2017 at 01:07:16PM -0800, Andy Lutomirski wrote: >>

Re: [PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack

On Mon, Nov 20, 2017 at 1:55 PM, Josh Poimboeuf wrote: > On Mon, Nov 20, 2017 at 01:30:12PM -0800, Andy Lutomirski wrote: >> On Mon, Nov 20, 2017 at 1:27 PM, Josh Poimboeuf wrote: >> > On Mon, Nov 20, 2017 at 01:07:16PM -0800, Andy Lutomirski wrote: >> >> >> but, more importantly, the OOPS

Re: [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

On Mon, Nov 20 2017 at 7:34pm -0500, NeilBrown wrote: > On Mon, Nov 20 2017, Mike Snitzer wrote: > > > On Sun, Jun 18, 2017 at 5:36 PM, NeilBrown wrote: > >> On Sun, Jun 18 2017, Jens Axboe wrote: > >> > >>> On Sun, Jun 18 2017, NeilBrown wrote: > This is

Re: [PATCH 00/13] block: assorted cleanup for bio splitting and cloning.

On Mon, Nov 20 2017 at 7:34pm -0500, NeilBrown wrote: > On Mon, Nov 20 2017, Mike Snitzer wrote: > > > On Sun, Jun 18, 2017 at 5:36 PM, NeilBrown wrote: > >> On Sun, Jun 18 2017, Jens Axboe wrote: > >> > >>> On Sun, Jun 18 2017, NeilBrown wrote: > This is a resend of my series of patches

Re: [PATCH 07/16] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

On Mon, Nov 20, 2017 at 3:37 PM, Thomas Gleixner wrote: > On Mon, 20 Nov 2017, Andy Lutomirski wrote: >> struct tss_struct { >> /* >> - * The hardware state: >> + * Space for the temporary SYSENTER stack. Used for the entry >> + * trampoline as well.

Re: [PATCH 07/16] x86/asm: Move SYSENTER_stack to the beginning of struct tss_struct

On Mon, Nov 20, 2017 at 3:37 PM, Thomas Gleixner wrote: > On Mon, 20 Nov 2017, Andy Lutomirski wrote: >> struct tss_struct { >> /* >> - * The hardware state: >> + * Space for the temporary SYSENTER stack. Used for the entry >> + * trampoline as well. Size it such that

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

On 20/11/2017 18:57, Mika Westerberg wrote: +Jarkko On Sun, Nov 19, 2017 at 04:35:51PM +, Jonathan Cameron wrote: On Thu, 2 Nov 2017 16:04:07 +0100 Wolfram Sang wrote: On Thu, Nov 02, 2017 at 02:35:50PM +, Jonathan Cameron wrote: On Fri, 27 Oct 2017 18:27:02

Re: [PATCH v4] iio : Add cm3218 smbus ara and acpi support

On 20/11/2017 18:57, Mika Westerberg wrote: +Jarkko On Sun, Nov 19, 2017 at 04:35:51PM +, Jonathan Cameron wrote: On Thu, 2 Nov 2017 16:04:07 +0100 Wolfram Sang wrote: On Thu, Nov 02, 2017 at 02:35:50PM +, Jonathan Cameron wrote: On Fri, 27 Oct 2017 18:27:02 +0200 Marc CAPDEVILLE

Re: [PATCH 04/16] x86/fixmap: Generalize the GDT fixmap mechanism

On Mon, Nov 20, 2017 at 2:01 PM, Thomas Gleixner wrote: > On Mon, 20 Nov 2017, Andy Lutomirski wrote: > > Just a few nits. > >> /* Provide the fixmap address of the remapped GDT */ >> static inline struct desc_struct *get_cpu_gdt_ro(int cpu) >> { >> - unsigned int idx =

Re: [PATCH 04/16] x86/fixmap: Generalize the GDT fixmap mechanism

On Mon, Nov 20, 2017 at 2:01 PM, Thomas Gleixner wrote: > On Mon, 20 Nov 2017, Andy Lutomirski wrote: > > Just a few nits. > >> /* Provide the fixmap address of the remapped GDT */ >> static inline struct desc_struct *get_cpu_gdt_ro(int cpu) >> { >> - unsigned int idx =

Re: [PATCH] ACPI / battery: add quirk for Asus GL502VSK and UX305LA

On Friday, September 22, 2017 10:27:44 AM CET Kai-Heng Feng wrote: > On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when > battery is full and AC is plugged. > > However rate_now is correct under this circumstance, hence we can use > "rate_now == 0" as a predicate to report

Re: [PATCH] ACPI / battery: add quirk for Asus GL502VSK and UX305LA

On Friday, September 22, 2017 10:27:44 AM CET Kai-Heng Feng wrote: > On Asus GL502VSK and UX305LA, ACPI incorrectly reports discharging when > battery is full and AC is plugged. > > However rate_now is correct under this circumstance, hence we can use > "rate_now == 0" as a predicate to report

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

On Tue, Nov 21, 2017 at 01:32:09AM +0100, Maciej S. Szmigiero wrote: > On 21.11.2017 01:00, Nicolin Chen wrote: > > On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote: > (..) > >> We need to make sure, however, that only proper channel slots are enabled > >> at playback start time

Re: [alsa-devel] [PATCH] ASoC: fsl_ssi: call _fsl_ssi_set_dai_fmt() just once in AC'97 mode

On Tue, Nov 21, 2017 at 01:32:09AM +0100, Maciej S. Szmigiero wrote: > On 21.11.2017 01:00, Nicolin Chen wrote: > > On Mon, Nov 20, 2017 at 11:13:45PM +0100, Maciej S. Szmigiero wrote: > (..) > >> We need to make sure, however, that only proper channel slots are enabled > >> at playback start time

Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo

On 11/20/2017 04:51 PM, Andrew Morton wrote: > On Wed, 15 Nov 2017 23:14:09 + Roman Gushchin wrote: > >> Currently we display some hugepage statistics (total, free, etc) >> in /proc/meminfo, but only for default hugepage size (e.g. 2Mb). >> >> If hugepages of different sizes are

Re: [PATCH v2] mm: show total hugetlb memory consumption in /proc/meminfo

On 11/20/2017 04:51 PM, Andrew Morton wrote: > On Wed, 15 Nov 2017 23:14:09 + Roman Gushchin wrote: > >> Currently we display some hugepage statistics (total, free, etc) >> in /proc/meminfo, but only for default hugepage size (e.g. 2Mb). >> >> If hugepages of different sizes are used (like

Re: [PATCH] devres: use MACRO instead of function for devm_ioremap_nocache

On 2017/11/20 17:32, Yisheng Xie wrote: > Default ioremap is ioremap_nocache, so devm_ioremap has the same function > with devm_ioremap_nocache, which may just be killed. However, there > are many places which use devm_ioremap_nocache instead of devm_ioremap. > > This patch is to use MACRO for

Re: [PATCH] devres: use MACRO instead of function for devm_ioremap_nocache

On 2017/11/20 17:32, Yisheng Xie wrote: > Default ioremap is ioremap_nocache, so devm_ioremap has the same function > with devm_ioremap_nocache, which may just be killed. However, there > are many places which use devm_ioremap_nocache instead of devm_ioremap. > > This patch is to use MACRO for

Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node

On Mon, Nov 20, 2017 at 01:28:01PM -0800, Palmer Dabbelt wrote: [...] > > > +++ b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt > > > > Nit: Other bindings use either a comma (as in the compatible string, > > "riscv,sbi.txt") or a dash (vendor-product.txt, "riscv-sbi.txt") in the > >

Re: [patches] Re: [PATCH] dt-bindings: Add a RISC-V SBI firmware node

On Mon, Nov 20, 2017 at 01:28:01PM -0800, Palmer Dabbelt wrote: [...] > > > +++ b/Documentation/devicetree/bindings/firmware/riscv.sbi.txt > > > > Nit: Other bindings use either a comma (as in the compatible string, > > "riscv,sbi.txt") or a dash (vendor-product.txt, "riscv-sbi.txt") in the > >

Re: [PATCH 2/3] x86/apic: Update the 'apic=' description of setting APIC driver

Hi Randy, At 11/21/2017 01:21 AM, Randy Dunlap wrote: On 11/20/2017 05:27 AM, Dou Liyang wrote: There are two consumers of apic=: the APIC debug level and the low level generic architecture code, but Linux just documented the first one. Append the second description. Signed-off-by: Dou

Re: [PATCH 2/3] x86/apic: Update the 'apic=' description of setting APIC driver

Hi Randy, At 11/21/2017 01:21 AM, Randy Dunlap wrote: On 11/20/2017 05:27 AM, Dou Liyang wrote: There are two consumers of apic=: the APIC debug level and the low level generic architecture code, but Linux just documented the first one. Append the second description. Signed-off-by: Dou

Re: [PATCH] mm, meminit: Serially initialise deferred memory if trace_buf_size is specified

On Fri, 17 Nov 2017 13:19:56 -0500 Pavel Tatashin wrote: > On Thu, Nov 16, 2017 at 5:06 AM, Mel Gorman > wrote: > > 4. Put a check into the page allocator slowpath that triggers serialised > >init if the system is booting and an

Re: [PATCH] mm, meminit: Serially initialise deferred memory if trace_buf_size is specified

On Fri, 17 Nov 2017 13:19:56 -0500 Pavel Tatashin wrote: > On Thu, Nov 16, 2017 at 5:06 AM, Mel Gorman > wrote: > > 4. Put a check into the page allocator slowpath that triggers serialised > >init if the system is booting and an allocation is about to fail. It > >would be such a cold

Re: [v2,12/18] kbuild: add support for clang LTO

On Mon, 20 Nov 2017 12:21:52 -0800 Sami Tolvanen wrote: > On Sat, Nov 18, 2017 at 01:21:39PM +1000, Nicholas Piggin wrote: > > Do you have any kind of numbers for this, out of curiosity? Binary > > size, performance, build time? > > I don't have performance numbers to

Re: [v2,12/18] kbuild: add support for clang LTO

On Mon, 20 Nov 2017 12:21:52 -0800 Sami Tolvanen wrote: > On Sat, Nov 18, 2017 at 01:21:39PM +1000, Nicholas Piggin wrote: > > Do you have any kind of numbers for this, out of curiosity? Binary > > size, performance, build time? > > I don't have performance numbers to share. Are there any

<    1   2   3   4   5   6   7   8   9   10   >