Re: [alsa-devel] [PATCH v4 03/15] soundwire: Add Master registration

On Sun, Dec 03, 2017 at 08:44:58PM -0600, Pierre-Louis Bossart wrote: > > >>>+/* SDW Enumeration Device Number */ > >>>+#define SDW_ENUM_DEV_NUM 0 > >> > >>add > >>SDW_GROUP12_DEV_NUM 12 > >>SDW_GROUP12_DEV_NUM 13 > > > >you mean SDW_GROUP13_DEV_NUM :D > > >

Re: [alsa-devel] [PATCH v4 03/15] soundwire: Add Master registration

On Sun, Dec 03, 2017 at 08:44:58PM -0600, Pierre-Louis Bossart wrote: > > >>>+/* SDW Enumeration Device Number */ > >>>+#define SDW_ENUM_DEV_NUM 0 > >> > >>add > >>SDW_GROUP12_DEV_NUM 12 > >>SDW_GROUP12_DEV_NUM 13 > > > >you mean SDW_GROUP13_DEV_NUM :D > > >

[PATCH v7 03/11] kexec_file: factor out crashdump elf header function from x86

prepare_elf_headers() can also be useful for other architectures, including arm64. So let it factored out. Signed-off-by: AKASHI Takahiro Cc: Dave Young Cc: Vivek Goyal Cc: Baoquan He ---

[PATCH v7 03/11] kexec_file: factor out crashdump elf header function from x86

prepare_elf_headers() can also be useful for other architectures, including arm64. So let it factored out. Signed-off-by: AKASHI Takahiro Cc: Dave Young Cc: Vivek Goyal Cc: Baoquan He --- arch/x86/kernel/crash.c | 324 include/linux/kexec.h

[PATCH v7 05/11] arm64: kexec_file: create purgatory

This is a basic purgatory, or a kind of glue code between the two kernels, for arm64. Since purgatory is assumed to be relocatable (not executable) object by kexec generic code, arch_kexec_apply_relocations_add() is required in general. Arm64's purgatory, however, is a simple asm and all the

[PATCH v7 05/11] arm64: kexec_file: create purgatory

This is a basic purgatory, or a kind of glue code between the two kernels, for arm64. Since purgatory is assumed to be relocatable (not executable) object by kexec generic code, arch_kexec_apply_relocations_add() is required in general. Arm64's purgatory, however, is a simple asm and all the

[PATCH v7 01/11] resource: add walk_system_ram_res_rev()

This function, being a variant of walk_system_ram_res() introduced in commit 8c86e70acead ("resource: provide new functions to walk through resources"), walks through a list of all the resources of System RAM in reversed order, i.e., from higher to lower. It will be used in kexec_file

[PATCH v7 06/11] arm64: kexec_file: load initrd, device-tree and purgatory segments

load_other_segments() sets up and adds all the memory segments necessary other than kernel, including initrd, device-tree blob and purgatory. Most of the code was borrowed from kexec-tools' counterpart. arch_kimage_kernel_post_load_cleanup() is meant to free arm64-specific data allocated for

[PATCH v7 01/11] resource: add walk_system_ram_res_rev()

This function, being a variant of walk_system_ram_res() introduced in commit 8c86e70acead ("resource: provide new functions to walk through resources"), walks through a list of all the resources of System RAM in reversed order, i.e., from higher to lower. It will be used in kexec_file

[PATCH v7 06/11] arm64: kexec_file: load initrd, device-tree and purgatory segments

load_other_segments() sets up and adds all the memory segments necessary other than kernel, including initrd, device-tree blob and purgatory. Most of the code was borrowed from kexec-tools' counterpart. arch_kimage_kernel_post_load_cleanup() is meant to free arm64-specific data allocated for

[PATCH v7 00/11] arm64: kexec: add kexec_file_load() support

This is the seventh round of implementing kexec_file_load() support on arm64.[1] Most of the code is based on kexec-tools (along with some kernel code from x86, which also came from kexec-tools). This patch series enables us to * load the kernel, Image, via kexec_file_load() system call, and

[PATCH v7 07/11] arm64: kexec_file: set up for crash dump adding elf core header

load_crashdump_segments() creates and loads a memory segment of elf core header for crash dump. "linux,usable-memory-range" and "linux,elfcorehdr" will add to the 2nd kernel's device-tree blob. The logic of this cod is also from kexec-tools. Signed-off-by: AKASHI Takahiro

[PATCH v7 02/11] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc

arch_kexec_kernel_*() and arch_kimage_file_post_load_cleanup can now be duplicated among some architectures, so let's factor them out. Signed-off-by: AKASHI Takahiro Cc: Dave Young Cc: Vivek Goyal Cc: Baoquan He

[PATCH v7 07/11] arm64: kexec_file: set up for crash dump adding elf core header

load_crashdump_segments() creates and loads a memory segment of elf core header for crash dump. "linux,usable-memory-range" and "linux,elfcorehdr" will add to the 2nd kernel's device-tree blob. The logic of this cod is also from kexec-tools. Signed-off-by: AKASHI Takahiro Cc: Catalin Marinas

[PATCH v7 02/11] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc

arch_kexec_kernel_*() and arch_kimage_file_post_load_cleanup can now be duplicated among some architectures, so let's factor them out. Signed-off-by: AKASHI Takahiro Cc: Dave Young Cc: Vivek Goyal Cc: Baoquan He Cc: Michael Ellerman Cc: Thiago Jung Bauermann ---

[PATCH v7 00/11] arm64: kexec: add kexec_file_load() support

This is the seventh round of implementing kexec_file_load() support on arm64.[1] Most of the code is based on kexec-tools (along with some kernel code from x86, which also came from kexec-tools). This patch series enables us to * load the kernel, Image, via kexec_file_load() system call, and

Re: [alsa-devel] [PATCH v4 04/15] soundwire: Add MIPI DisCo property helpers

On 12/3/17 10:52 AM, Vinod Koul wrote: On Fri, Dec 01, 2017 at 04:49:01PM -0600, Pierre-Louis Bossart wrote: +int sdw_master_read_prop(struct sdw_bus *bus) +{ + struct sdw_master_prop *prop = >prop; + struct fwnode_handle *link; + unsigned int count = 0; + char

Re: [alsa-devel] [PATCH v4 04/15] soundwire: Add MIPI DisCo property helpers

On 12/3/17 10:52 AM, Vinod Koul wrote: On Fri, Dec 01, 2017 at 04:49:01PM -0600, Pierre-Louis Bossart wrote: +int sdw_master_read_prop(struct sdw_bus *bus) +{ + struct sdw_master_prop *prop = >prop; + struct fwnode_handle *link; + unsigned int count = 0; + char

Re: UFS utilities

Hi, On 11/30/17, Bean Huo (beanhuo) wrote: > Hi, Greg > >>On Mon, Nov 27, 2017 at 11:25:47AM +, Bean Huo (beanhuo) wrote: >>> Hi, all >>> Is there someone knows if exists one utilis dedicated to UFS device, >>> rather >>than SCSI utils? >>> I have tried sg3-utils, but it

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Hi Heiko On 2017??12??02?? 05:58, Heiko Stuebner wrote: Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson: Hi, On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong wrote: Hi Doug Thank you for mentioning this patch. I think the focus of the discussion is: can

Re: UFS utilities

Hi, On 11/30/17, Bean Huo (beanhuo) wrote: > Hi, Greg > >>On Mon, Nov 27, 2017 at 11:25:47AM +, Bean Huo (beanhuo) wrote: >>> Hi, all >>> Is there someone knows if exists one utilis dedicated to UFS device, >>> rather >>than SCSI utils? >>> I have tried sg3-utils, but it is not convenient

Re: [PATCH 0/4] Move DP phy switch to PHY driver

Hi Heiko On 2017??12??02?? 05:58, Heiko Stuebner wrote: Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson: Hi, On Wed, Nov 29, 2017 at 6:27 PM, Chris Zhong wrote: Hi Doug Thank you for mentioning this patch. I think the focus of the discussion is: can we put the grf

Re: [alsa-devel] [PATCH v4 03/15] soundwire: Add Master registration

+/* SDW Enumeration Device Number */ +#define SDW_ENUM_DEV_NUM 0 add SDW_GROUP12_DEV_NUM 12 SDW_GROUP12_DEV_NUM 13 you mean SDW_GROUP13_DEV_NUM :D SDW_MASTER_DEV_NUM 14 /* not supported in these patches */ These dont help now as we dont

Re: [alsa-devel] [PATCH v4 03/15] soundwire: Add Master registration

+/* SDW Enumeration Device Number */ +#define SDW_ENUM_DEV_NUM 0 add SDW_GROUP12_DEV_NUM 12 SDW_GROUP12_DEV_NUM 13 you mean SDW_GROUP13_DEV_NUM :D SDW_MASTER_DEV_NUM 14 /* not supported in these patches */ These dont help now as we dont

Re: Difficulties for compilation without extra optimisation

On Sun, 3 Dec 2017 22:56:51 +0100 SF Markus Elfring wrote: > Can the software areas distinguished where such special handling matters? No idea. That's something you are going to have to figure out on your own. -- Steve

Re: Difficulties for compilation without extra optimisation

On Sun, 3 Dec 2017 22:56:51 +0100 SF Markus Elfring wrote: > Can the software areas distinguished where such special handling matters? No idea. That's something you are going to have to figure out on your own. -- Steve

Re: [GIT PULL] hash addresses printed with %p

On 12/03/17 at 06:33pm, Joe Perches wrote: > On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote: > > I think 0400 is good enough for this issue. > > > > Greg, would you like to agree add an extra macro like below? > [] > > -static struct map_attribute map_type_attr = __ATTR_RO(type); > > -static

Re: [GIT PULL] hash addresses printed with %p

On 12/03/17 at 06:33pm, Joe Perches wrote: > On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote: > > I think 0400 is good enough for this issue. > > > > Greg, would you like to agree add an extra macro like below? > [] > > -static struct map_attribute map_type_attr = __ATTR_RO(type); > > -static

Re: linux-next: Signed-off-by missing for commits in the drm tree

On 2017.12.04 10:57:35 +1100, Stephen Rothwell wrote: > Hi all, > > There is a series of commits > > 54cff6479fd8 - c1802534e5a6 > (not all in that range) > > that are missing a Signed-off-by from their committer. > They were originally committed by Zhi himself, but I had to rebase onto

Re: linux-next: Signed-off-by missing for commits in the drm tree

On 2017.12.04 10:57:35 +1100, Stephen Rothwell wrote: > Hi all, > > There is a series of commits > > 54cff6479fd8 - c1802534e5a6 > (not all in that range) > > that are missing a Signed-off-by from their committer. > They were originally committed by Zhi himself, but I had to rebase onto

Re: [GIT PULL] hash addresses printed with %p

On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote: > I think 0400 is good enough for this issue. > > Greg, would you like to agree add an extra macro like below? [] > -static struct map_attribute map_type_attr = __ATTR_RO(type); > -static struct map_attribute map_phys_addr_attr =

Re: [GIT PULL] hash addresses printed with %p

On Mon, 2017-12-04 at 10:02 +0800, Dave Young wrote: > I think 0400 is good enough for this issue. > > Greg, would you like to agree add an extra macro like below? [] > -static struct map_attribute map_type_attr = __ATTR_RO(type); > -static struct map_attribute map_phys_addr_attr =

Re: general protection fault in __lock_acquire (2)

On Sun, Dec 3, 2017 at 4:33 PM, syzbot wrote: > syzkaller has found reproducer for the following crash on > fb7516d42478ebc8e2f00efb76ef96f7b68fd8d3 > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master >

Re: general protection fault in __lock_acquire (2)

On Sun, Dec 3, 2017 at 4:33 PM, syzbot wrote: > syzkaller has found reproducer for the following crash on > fb7516d42478ebc8e2f00efb76ef96f7b68fd8d3 > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: [GIT PULL] revert ARM SCPI changes for v4.15-rc1

On Sat, Dec 02, 2017 at 05:04:35PM -0800, Olof Johansson wrote: > On Fri, Dec 01, 2017 at 11:53:05AM -0800, Kevin Hilman wrote: > > Arnd, Olof, > > > > These ARM SCPI changes caused SCPI regressions resulting in CPUfreq > > failures on most Amlogic SoCs (found by kernelci.org.) > > > >

Re: [GIT PULL] revert ARM SCPI changes for v4.15-rc1

On Sat, Dec 02, 2017 at 05:04:35PM -0800, Olof Johansson wrote: > On Fri, Dec 01, 2017 at 11:53:05AM -0800, Kevin Hilman wrote: > > Arnd, Olof, > > > > These ARM SCPI changes caused SCPI regressions resulting in CPUfreq > > failures on most Amlogic SoCs (found by kernelci.org.) > > > >

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

2017-11-14 13:12 GMT+08:00 Rik van Riel : > Currently, every time a VCPU is scheduled out, the host kernel will > first save the guest FPU/xstate context, then load the qemu userspace > FPU context, only to then immediately save the qemu userspace FPU > context back to memory.

Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

2017-11-14 13:12 GMT+08:00 Rik van Riel : > Currently, every time a VCPU is scheduled out, the host kernel will > first save the guest FPU/xstate context, then load the qemu userspace > FPU context, only to then immediately save the qemu userspace FPU > context back to memory. When scheduling in a

[PATCH v2] mmap.2: MAP_FIXED updated documentation

From: John Hubbard Previously, MAP_FIXED was "discouraged", due to portability issues with the fixed address. In fact, there are other, more serious issues. Also, in some limited cases, this option can be used safely. Expand the documentation to discuss both the hazards,

[PATCH v2] mmap.2: MAP_FIXED updated documentation

From: John Hubbard Previously, MAP_FIXED was "discouraged", due to portability issues with the fixed address. In fact, there are other, more serious issues. Also, in some limited cases, this option can be used safely. Expand the documentation to discuss both the hazards, and how to use it

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/most/video/video.c between commit: afc9a42b7464 ("the rest of drivers/*: annotate ->poll() instances") from the vfs tree and commit: 1b10a0316e2d ("staging: most: video: remove aim designators")

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/most/video/video.c between commit: afc9a42b7464 ("the rest of drivers/*: annotate ->poll() instances") from the vfs tree and commit: 1b10a0316e2d ("staging: most: video: remove aim designators")

Re: [GIT PULL] hash addresses printed with %p

On 12/02/17 at 10:22pm, Matt Fleming wrote: > (Cc'ing Dave since this is used for kexec on EFI) > > On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > > On 1 December 2017 at 09:48, Greg Kroah-Hartman > > wrote: > > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard

Re: [GIT PULL] hash addresses printed with %p

On 12/02/17 at 10:22pm, Matt Fleming wrote: > (Cc'ing Dave since this is used for kexec on EFI) > > On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote: > > On 1 December 2017 at 09:48, Greg Kroah-Hartman > > wrote: > > > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote: > > >> On

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/most/cdev/cdev.c between commit: afc9a42b7464 ("the rest of drivers/*: annotate ->poll() instances") from the vfs tree and commit: 1fd923f38610 ("staging: most: cdev: replace function prefix")

linux-next: manual merge of the staging tree with the vfs tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/staging/most/cdev/cdev.c between commit: afc9a42b7464 ("the rest of drivers/*: annotate ->poll() instances") from the vfs tree and commit: 1fd923f38610 ("staging: most: cdev: replace function prefix")

[PATCH] eeprom: at24: Change nvmem stride to 1

This changes the nvmem stride to 1. I am trying to use the nvram consumer apis to read a MAC address from an eeprom that has an offset that is not a multiple of 4, which causes an error currently. Signed-off-by: David Lechner --- drivers/misc/eeprom/at24.c | 2 +- 1 file

[PATCH] eeprom: at24: Change nvmem stride to 1

This changes the nvmem stride to 1. I am trying to use the nvram consumer apis to read a MAC address from an eeprom that has an offset that is not a multiple of 4, which causes an error currently. Signed-off-by: David Lechner --- drivers/misc/eeprom/at24.c | 2 +- 1 file changed, 1

Re: KAISER: kexec triggers a warning

On 12/01/17 at 04:27pm, Borislav Petkov wrote: > On Fri, Dec 01, 2017 at 11:18:51PM +0800, Baoquan He wrote: > > On 12/01/17 at 02:52pm, Juerg Haefliger wrote: > > > Loading a kexec kernel using today's linux-tip master with KAISER=y > > > triggers the following warning: > > > > I also noticed

Re: KAISER: kexec triggers a warning

On 12/01/17 at 04:27pm, Borislav Petkov wrote: > On Fri, Dec 01, 2017 at 11:18:51PM +0800, Baoquan He wrote: > > On 12/01/17 at 02:52pm, Juerg Haefliger wrote: > > > Loading a kexec kernel using today's linux-tip master with KAISER=y > > > triggers the following warning: > > > > I also noticed

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/iio/adc/meson_saradc.c between commit: d85eed9f5763 ("iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs") from the staging.current tree and commit: 930df4d853a8 ("iio: adc:

linux-next: manual merge of the staging tree with the staging.current tree

Hi Greg, Today's linux-next merge of the staging tree got a conflict in: drivers/iio/adc/meson_saradc.c between commit: d85eed9f5763 ("iio: adc: meson-saradc: initialize the bandgap correctly on older SoCs") from the staging.current tree and commit: 930df4d853a8 ("iio: adc:

Re: [PATCH 2/3, V2] kernel: Move groups_sort to the caller of set_groups.

On Thu, Nov 30 2017, Thiago Rafael Becker wrote: > The responsibility for calling groups_sort is now on the caller > of set_groups. > > Signed-off-by: Thiago Rafael Becker > --- > kernel/groups.c | 1 + > kernel/uid16.c| 1 + >

Re: [PATCH 2/3, V2] kernel: Move groups_sort to the caller of set_groups.

On Thu, Nov 30 2017, Thiago Rafael Becker wrote: > The responsibility for calling groups_sort is now on the caller > of set_groups. > > Signed-off-by: Thiago Rafael Becker > --- > kernel/groups.c | 1 + > kernel/uid16.c| 1 + > net/sunrpc/svcauth_unix.c | 7 +++ > 3

[PATCH V2 net-next 1/3] net: hns3: Refactor of the reset interrupt handling logic

The reset interrupt event shares common miscellaneous interrupt Vector 0. In the existing reset interrupt handling we disable the Vector 0 interrupt in misc interrupt handler and re-enable them later in context to common service task. This also means other event sources like mailbox would also be

[PATCH V2 net-next 3/3] net: hns3: Refactors the requested reset & pending reset handling code

In exisiting code, the way to detect if driver/client reset should be executed or if hardware should be be soft resetted was overly complex. Existing code use to read the interrupt status register from task context to figure out if the interrupt source event was reset and then use clear the

[PATCH V2 net-next 1/3] net: hns3: Refactor of the reset interrupt handling logic

The reset interrupt event shares common miscellaneous interrupt Vector 0. In the existing reset interrupt handling we disable the Vector 0 interrupt in misc interrupt handler and re-enable them later in context to common service task. This also means other event sources like mailbox would also be

[PATCH V2 net-next 3/3] net: hns3: Refactors the requested reset & pending reset handling code

In exisiting code, the way to detect if driver/client reset should be executed or if hardware should be be soft resetted was overly complex. Existing code use to read the interrupt status register from task context to figure out if the interrupt source event was reset and then use clear the

[PATCH V2 net-next 0/3] net: hns3: Refactors "reset" handling code in HCLGE layer of HNS3 driver

This patch refactors the code of the reset feature in HCLGE layer of HNS3 PF driver. Prime motivation to do this change is: 1. To reduce the time for which common miscellaneous Vector 0 interrupt is disabled because of the reset. Simplification of the common miscellaneous interrupt handler

[PATCH V2 net-next 0/3] net: hns3: Refactors "reset" handling code in HCLGE layer of HNS3 driver

This patch refactors the code of the reset feature in HCLGE layer of HNS3 PF driver. Prime motivation to do this change is: 1. To reduce the time for which common miscellaneous Vector 0 interrupt is disabled because of the reset. Simplification of the common miscellaneous interrupt handler

[PATCH V2 net-next 2/3] net: hns3: Add reset service task for handling reset requests

Existing common service task was being used to service the reset requests. This patch tries to make the handling of reset cleaner by separating task to handle the reset requests. This might in turn help in adapting similar handling approach for other interrupt events like mailbox, sharing vector 0

[PATCH V2 net-next 2/3] net: hns3: Add reset service task for handling reset requests

Existing common service task was being used to service the reset requests. This patch tries to make the handling of reset cleaner by separating task to handle the reset requests. This might in turn help in adapting similar handling approach for other interrupt events like mailbox, sharing vector 0

[bisected] x86 boot still broken on -rc2

Same thing on rc2, bisected down to: commit b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1 (refs/bisect/bad) Author: Prarit Bhargava Date: Tue Nov 14 07:42:57 2017 -0500 x86/smpboot: Fix __max_logical_packages estimate A system booted with a small number of cores

[bisected] x86 boot still broken on -rc2

Same thing on rc2, bisected down to: commit b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1 (refs/bisect/bad) Author: Prarit Bhargava Date: Tue Nov 14 07:42:57 2017 -0500 x86/smpboot: Fix __max_logical_packages estimate A system booted with a small number of cores enabled per package

Re: [PATCH] scsi: ufs: ufshcd: Enable no_write_same for scsi host

Hi Anderson, Could you please check about below thread? https://patchwork.kernel.org/patch/6357751/ Your patch is same as my old one. On 11/30/17, Bjorn Andersson wrote: > Occasionally the following error message can be seen in the logs of > Qualcomm devices using

Re: [PATCH] scsi: ufs: ufshcd: Enable no_write_same for scsi host

Hi Anderson, Could you please check about below thread? https://patchwork.kernel.org/patch/6357751/ Your patch is same as my old one. On 11/30/17, Bjorn Andersson wrote: > Occasionally the following error message can be seen in the logs of > Qualcomm devices using UFS: > > EXT4-fs (sda9):

RE: [PATCH v3 7/9] KVM: x86: Implement Intel Processor Trace MSRs read/write

> >>> + case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: { > >>> + u32 eax, ebx, ecx, edx; > >>> + > >>> + cpuid_count(0x14, 1, , , , ); > >> > >> Please cache the cpuid_count result, or do the cpuid_count after testing > >> vmx_pt_supported() (which

RE: [PATCH v3 7/9] KVM: x86: Implement Intel Processor Trace MSRs read/write

> >>> + case MSR_IA32_RTIT_ADDR0_A ... MSR_IA32_RTIT_ADDR3_B: { > >>> + u32 eax, ebx, ecx, edx; > >>> + > >>> + cpuid_count(0x14, 1, , , , ); > >> > >> Please cache the cpuid_count result, or do the cpuid_count after testing > >> vmx_pt_supported() (which

Re: [feature request] Linux should never break, it should rebuild/repair itself automatically

On 12/1/2017 2:25 PM, BILL ENGVALD wrote: > One of the flaws in *NIX software is that a simple command can lead to > a nightmare, so I would like the kernel devs to write code that > repairs Linux automatically. I would like it if Linux became > completely stable regardless of memory failures,

Re: [feature request] Linux should never break, it should rebuild/repair itself automatically

On 12/1/2017 2:25 PM, BILL ENGVALD wrote: > One of the flaws in *NIX software is that a simple command can lead to > a nightmare, so I would like the kernel devs to write code that > repairs Linux automatically. I would like it if Linux became > completely stable regardless of memory failures,

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Tue, Nov 07, 2017 at 07:23:27PM -0800, Richard Cochran wrote: > The application does join that group on the external (slave) > interface. I'll find out why the delay request mechanism isn't > working... Looking back, I now recall that the series lets the HW embed the time stamps into the

Re: [PATCH net-next RFC 0/9] net: dsa: PTP timestamping for mv88e6xxx

On Tue, Nov 07, 2017 at 07:23:27PM -0800, Richard Cochran wrote: > The application does join that group on the external (slave) > interface. I'll find out why the delay request mechanism isn't > working... Looking back, I now recall that the series lets the HW embed the time stamps into the

Re: [PATCH v2 35/35] dt-bindings: timer: Add andestech atcpit100 timer binding doc

2017-12-01 20:19 GMT+08:00 Linus Walleij : > On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu wrote: > >> From: Rick Chen >> >> Add a document to describe Andestech atcpit100 timer and >> binding information. >> >> Signed-off-by:

Re: [PATCH v2 35/35] dt-bindings: timer: Add andestech atcpit100 timer binding doc

2017-12-01 20:19 GMT+08:00 Linus Walleij : > On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu wrote: > >> From: Rick Chen >> >> Add a document to describe Andestech atcpit100 timer and >> binding information. >> >> Signed-off-by: Rick Chen >> Acked-by: Rob Herring >> Signed-off-by: Greentime Hu

Re: [PATCH] drm/panel: support Innolux P097PFG panel

Hi Emil, On Saturday, December 02, 2017 01:55 AM, Emil Velikov wrote: On 30 November 2017 at 06:13, Lin Huang wrote: Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it refactor Innolux P079ZCA panel driver, let it support multi panel, and add support P097PFG panel

Re: [PATCH] drm/panel: support Innolux P097PFG panel

Hi Emil, On Saturday, December 02, 2017 01:55 AM, Emil Velikov wrote: On 30 November 2017 at 06:13, Lin Huang wrote: Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it refactor Innolux P079ZCA panel driver, let it support multi panel, and add support P097PFG panel in this driver.

Re: [PATCH tip/core/rcu 15/21] keyring: Remove now-redundant smp_read_barrier_depends()

On Fri, 1 Dec 2017, Paul E. McKenney wrote: > Now that the associative-array library properly heads dependency chains, > the various smp_read_barrier_depends() calls in security/keys/keyring.c > are no longer needed. This commit therefore removes them. > > Signed-off-by: Paul E. McKenney

Re: [PATCH tip/core/rcu 15/21] keyring: Remove now-redundant smp_read_barrier_depends()

On Fri, 1 Dec 2017, Paul E. McKenney wrote: > Now that the associative-array library properly heads dependency chains, > the various smp_read_barrier_depends() calls in security/keys/keyring.c > are no longer needed. This commit therefore removes them. > > Signed-off-by: Paul E. McKenney > Cc:

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

On 4 December 2017 at 10:30, Stephen Rothwell wrote: > Hi all, > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > produced this warning: Oops, not sure how I missed it, force pushed drm-next with the merge fixed. Dave.

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

On 4 December 2017 at 10:30, Stephen Rothwell wrote: > Hi all, > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig) > produced this warning: Oops, not sure how I missed it, force pushed drm-next with the merge fixed. Dave.

[PATCH v3 4/4] input: serio: Replace timeval by timespec64

struct timeval is not y2038 safe. All references to timeval will be deleted from the kernel to make it y2038 safe. Replace its uses by y2038 safe struct timespec64. The timestamps changed here only keep track of delta times. These timestamps are also internal to kernel. Hence, monotonic times are

[PATCH v3 4/4] input: serio: Replace timeval by timespec64

struct timeval is not y2038 safe. All references to timeval will be deleted from the kernel to make it y2038 safe. Replace its uses by y2038 safe struct timespec64. The timestamps changed here only keep track of delta times. These timestamps are also internal to kernel. Hence, monotonic times are

[PATCH v3 3/4] input: Deprecate real timestamps beyond year 2106

struct timeval is not y2038 safe. All usage of timeval in the kernel will be replaced by y2038 safe structures. The change is also necessary as glibc is introducing support for 32 bit applications to use 64 bit time_t. Without this change, many applications would incorrectly interpret values in

[PATCH v3 2/4] input: evdev: Replace timeval with timespec64

struct timeval is not y2038 safe. All references to timeval in the kernel will be replaced by y2038 safe structures. Replace all references to timeval with y2038 safe struct timespec64 here. struct input_event will be changed in a different patch. Signed-off-by: Deepa Dinamani

[PATCH v3 3/4] input: Deprecate real timestamps beyond year 2106

struct timeval is not y2038 safe. All usage of timeval in the kernel will be replaced by y2038 safe structures. The change is also necessary as glibc is introducing support for 32 bit applications to use 64 bit time_t. Without this change, many applications would incorrectly interpret values in

[PATCH v3 2/4] input: evdev: Replace timeval with timespec64

struct timeval is not y2038 safe. All references to timeval in the kernel will be replaced by y2038 safe structures. Replace all references to timeval with y2038 safe struct timespec64 here. struct input_event will be changed in a different patch. Signed-off-by: Deepa Dinamani Reviewed-by:

[PATCH v3 0/4] Make input drivers y2038 safe

The series is aimed at making input events y2038 safe. It extends the lifetime of the realtime timestamps in the events to year 2106. The series is also a necessary update as glibc is set to provide 64 bit time_t support for 32 bit binaries. glibc plan is detailed at

[PATCH v3 1/4] uinput: Add ioctl for using monotonic/ boot times

struct timeval which is part of struct input_event to maintain the event times is not y2038 safe. Real time timestamps are also not ideal for input_event as this time can go backwards as noted in the patch a80b83b7b8 by John Stultz. Arnd Bergmann suggested deprecating real time and using

[PATCH v3 0/4] Make input drivers y2038 safe

The series is aimed at making input events y2038 safe. It extends the lifetime of the realtime timestamps in the events to year 2106. The series is also a necessary update as glibc is set to provide 64 bit time_t support for 32 bit binaries. glibc plan is detailed at

[PATCH v3 1/4] uinput: Add ioctl for using monotonic/ boot times

struct timeval which is part of struct input_event to maintain the event times is not y2038 safe. Real time timestamps are also not ideal for input_event as this time can go backwards as noted in the patch a80b83b7b8 by John Stultz. Arnd Bergmann suggested deprecating real time and using

Re: [PATCH v4 3/3] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

Hi Vlastimil, On 2017/12/1 23:18, Vlastimil Babka wrote: > On 12/01/2017 10:55 AM, Yisheng Xie wrote: >> As in manpage of migrate_pages, the errno should be set to EINVAL when >> none of the node IDs specified by new_nodes are on-line and allowed by the >> process's current cpuset context, or

Re: [PATCH v4 3/3] mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

Hi Vlastimil, On 2017/12/1 23:18, Vlastimil Babka wrote: > On 12/01/2017 10:55 AM, Yisheng Xie wrote: >> As in manpage of migrate_pages, the errno should be set to EINVAL when >> none of the node IDs specified by new_nodes are on-line and allowed by the >> process's current cpuset context, or

Re: possible deadlock in blk_trace_remove

On 12/03/2017 05:44 PM, Eric Biggers wrote: > On Sun, Dec 03, 2017 at 05:24:32PM -0700, Jens Axboe wrote: >> On 12/03/2017 01:24 PM, Eric Biggers wrote: >>> On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: Hello, syzkaller hit the following crash on

Re: possible deadlock in blk_trace_remove

On 12/03/2017 05:44 PM, Eric Biggers wrote: > On Sun, Dec 03, 2017 at 05:24:32PM -0700, Jens Axboe wrote: >> On 12/03/2017 01:24 PM, Eric Biggers wrote: >>> On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: Hello, syzkaller hit the following crash on

Re: possible deadlock in blk_trace_remove

On Sun, Dec 03, 2017 at 05:24:32PM -0700, Jens Axboe wrote: > On 12/03/2017 01:24 PM, Eric Biggers wrote: > > On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: > >> Hello, > >> > >> syzkaller hit the following crash on > >> d9e0e63d9a6f88440eb201e1491fcf730272c706 > >>

Re: possible deadlock in blk_trace_remove

On Sun, Dec 03, 2017 at 05:24:32PM -0700, Jens Axboe wrote: > On 12/03/2017 01:24 PM, Eric Biggers wrote: > > On Sun, Nov 19, 2017 at 02:36:01AM -0800, syzbot wrote: > >> Hello, > >> > >> syzkaller hit the following crash on > >> d9e0e63d9a6f88440eb201e1491fcf730272c706 > >>

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

Hi all, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/gpu/drm/i915/gvt/cmd_parser.c: In function 'perform_bb_shadow': drivers/gpu/drm/i915/gvt/cmd_parser.c:1647:8: warning: unused variable 'dst' [-Wunused-variable] void *dst = NULL;

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

Hi all, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/gpu/drm/i915/gvt/cmd_parser.c: In function 'perform_bb_shadow': drivers/gpu/drm/i915/gvt/cmd_parser.c:1647:8: warning: unused variable 'dst' [-Wunused-variable] void *dst = NULL;

[PATCH] asus-wireless: send an EV_SYN/SYN_REPORT between state changes

Sending the switch state change twice within the same frame is invalid evdev protocol and only works if the client handles keys immediately as well. Processing events immediately is incorrect, it forces a fake order of events that does not exist on the device. Recent versions of libinput changed

[PATCH] asus-wireless: send an EV_SYN/SYN_REPORT between state changes

Sending the switch state change twice within the same frame is invalid evdev protocol and only works if the client handles keys immediately as well. Processing events immediately is incorrect, it forces a fake order of events that does not exist on the device. Recent versions of libinput changed

<    1   2   3   4   5   6   7   >