Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

On 05/17/2018 06:01 PM, Doug Anderson wrote: > On Thu, May 17, 2018 at 5:16 PM, David Collins > wrote: >> On 05/17/2018 02:22 PM, Doug Anderson wrote: >>> On Fri, May 11, 2018 at 7:28 PM, David Collins >>> wrote: +-

Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

On 05/17/2018 06:01 PM, Doug Anderson wrote: > On Thu, May 17, 2018 at 5:16 PM, David Collins > wrote: >> On 05/17/2018 02:22 PM, Doug Anderson wrote: >>> On Fri, May 11, 2018 at 7:28 PM, David Collins >>> wrote: +- qcom,regulator-initial-microvolt + Usage: optional; VRM

Re: [linux-sunxi] Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

On Freitag, 18. Mai 2018 09:14:36 CEST Maxime Ripard wrote: > On Mon, May 14, 2018 at 10:36:08PM +0200, Paul Kocialkowski wrote: > > > > + backlight: backlight { > > > > + compatible = "pwm-backlight"; > > > > + pwms = < 0 5 PWM_POLARITY_INVERTED>; > > > > +

Re: [linux-sunxi] Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

On Freitag, 18. Mai 2018 09:14:36 CEST Maxime Ripard wrote: > On Mon, May 14, 2018 at 10:36:08PM +0200, Paul Kocialkowski wrote: > > > > + backlight: backlight { > > > > + compatible = "pwm-backlight"; > > > > + pwms = < 0 5 PWM_POLARITY_INVERTED>; > > > > +

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 18, 2018 at 11:23:08PM +0300, Roman Kagan wrote: > On Fri, May 18, 2018 at 10:50:25AM -0700, Matthew Wilcox wrote: > > It'd be nice if you cc'd the person who wrote the code you're patching. > > You'd get a response a lot quicker than waiting until I happened to > > notice the email in

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 18, 2018 at 11:23:08PM +0300, Roman Kagan wrote: > On Fri, May 18, 2018 at 10:50:25AM -0700, Matthew Wilcox wrote: > > It'd be nice if you cc'd the person who wrote the code you're patching. > > You'd get a response a lot quicker than waiting until I happened to > > notice the email in

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 18, 2018 at 03:31:38PM -0700, Andrew Morton wrote: > On Fri, 18 May 2018 10:50:25 -0700 Matthew Wilcox wrote: > > If the radix tree underlying the IDR happens to be full and we attempt > > to remove an id which is larger than any id in the IDR, we will call > >

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, May 18, 2018 at 03:31:38PM -0700, Andrew Morton wrote: > On Fri, 18 May 2018 10:50:25 -0700 Matthew Wilcox wrote: > > If the radix tree underlying the IDR happens to be full and we attempt > > to remove an id which is larger than any id in the IDR, we will call > > __radix_tree_delete()

Geschäfts vorschlag

Geschäfts vorschlag Ich habe ein Geschäft von $ 65.400.000.00 Million (fünfundsechzig Millionen, vierhunderttausend US-Dollar), die er in unserer Bank hinterlegt hat und gerade lügt, nicht beansprucht zu teilen, sollten Sie interessiert sein. Sollten Sie interessiert sein, wenden Sie sich

Geschäfts vorschlag

Geschäfts vorschlag Ich habe ein Geschäft von $ 65.400.000.00 Million (fünfundsechzig Millionen, vierhunderttausend US-Dollar), die er in unserer Bank hinterlegt hat und gerade lügt, nicht beansprucht zu teilen, sollten Sie interessiert sein. Sollten Sie interessiert sein, wenden Sie sich

Re: [PATCH v2 1/4] seccomp: add a return code to trap to userspace

Hi Tycho, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc5] [cannot apply to next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2 1/4] seccomp: add a return code to trap to userspace

Hi Tycho, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc5] [cannot apply to next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] uprobes/x86: remove the wrong WARN_ON() in uprobe_init_insn()

On Fri, 18 May 2018 18:27:39 +0200 Oleg Nesterov wrote: > insn_get_length() has the side-effect of processing the entire instruction > but only if it was decoded successfully, otherwise insn_complete() can fail > and in this case we need to just return an error without warning.

Re: [PATCH] uprobes/x86: remove the wrong WARN_ON() in uprobe_init_insn()

On Fri, 18 May 2018 18:27:39 +0200 Oleg Nesterov wrote: > insn_get_length() has the side-effect of processing the entire instruction > but only if it was decoded successfully, otherwise insn_complete() can fail > and in this case we need to just return an error without warning. > This looks

[PATCH v1] gpu: host1x: Utilize IOMMU mapping for firewall-copied buffers

Map firewall-copied buffers into Host1x's IOVA space, otherwise Host1x CDMA can't access the command buffers and all submitted jobs fail if IOMMU and Host1x firewall are enabled in the kernels config. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 58

[PATCH v1] gpu: host1x: Utilize IOMMU mapping for firewall-copied buffers

Map firewall-copied buffers into Host1x's IOVA space, otherwise Host1x CDMA can't access the command buffers and all submitted jobs fail if IOMMU and Host1x firewall are enabled in the kernels config. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 58

mmotm 2018-05-18-16-44 uploaded

The mm-of-the-moment snapshot 2018-05-18-16-44 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: WARNING and PANIC in irq_matrix_free

2018-05-18 23:41 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: > What I did - was running x86 selftests and ssh'ing at the same moment. > Will try it again if it'll fire by any chance. No, I've tried a couple of times (after reboot as it's ONCE), but it looks hard to reproduce by hands without

mmotm 2018-05-18-16-44 uploaded

The mm-of-the-moment snapshot 2018-05-18-16-44 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: WARNING and PANIC in irq_matrix_free

2018-05-18 23:41 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: > What I did - was running x86 selftests and ssh'ing at the same moment. > Will try it again if it'll fire by any chance. No, I've tried a couple of times (after reboot as it's ONCE), but it looks hard to reproduce by hands without

[GIT PULL] platform-drivers-x86 for 4.17-3

Hi Linus, DELL_WMI had a lingering "select DELL_SMBIOS" leading to possible misconfiguration. This removes the last of the "select DELL_SMBIOS" lines in the Kconfig. Obviously this has been an unacceptable sequence of failures. I will be adding some contextual fuzz testing for this Kconfig to

[GIT PULL] platform-drivers-x86 for 4.17-3

Hi Linus, DELL_WMI had a lingering "select DELL_SMBIOS" leading to possible misconfiguration. This removes the last of the "select DELL_SMBIOS" lines in the Kconfig. Obviously this has been an unacceptable sequence of failures. I will be adding some contextual fuzz testing for this Kconfig to

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 0:16 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: > 2018-05-19 0:10 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: >> Sure. >> I'm on Intel actually: >> cpu family: 6 >> model: 142 >> model name: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz >> >> But I usually test

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 0:16 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: > 2018-05-19 0:10 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: >> Sure. >> I'm on Intel actually: >> cpu family: 6 >> model: 142 >> model name: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz >> >> But I usually test

general protection fault in smc_ioctl

Hello, syzbot found the following crash on: HEAD commit:1f7455c3912d tcp: tcp_rack_reo_wnd() can be static git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=171a133780 kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1 dashboard

general protection fault in smc_ioctl

Hello, syzbot found the following crash on: HEAD commit:1f7455c3912d tcp: tcp_rack_reo_wnd() can be static git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=171a133780 kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1 dashboard

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 10:56:18PM +, Trent Piepho wrote: > > I feel like "fix" might overstate the result a bit. > > This ends up taking a full second to make each UUID. Having gone to > great effort to make an iMX25 complete userspace startup in 250 ms, a > full second, per UUID, in early

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, May 18, 2018 at 10:56:18PM +, Trent Piepho wrote: > > I feel like "fix" might overstate the result a bit. > > This ends up taking a full second to make each UUID. Having gone to > great effort to make an iMX25 complete userspace startup in 250 ms, a > full second, per UUID, in early

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 0:10 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: > Sure. > I'm on Intel actually: > cpu family: 6 > model: 142 > model name: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz > > But I usually test kernels in VM. So, I use virt-manager as it's > easier to manage > multiple

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

2018-05-19 0:10 GMT+01:00 Dmitry Safonov <0x7f454...@gmail.com>: > Sure. > I'm on Intel actually: > cpu family: 6 > model: 142 > model name: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz > > But I usually test kernels in VM. So, I use virt-manager as it's > easier to manage > multiple

Re: [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote: > On Sat, May 19, 2018 at 12:09 AM, Janusz Krzysztofik > > wrote: > > + gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy", GPIOD_IN); > > + if (!IS_ERR_OR_NULL(gpiod_rdy)) { > > So, is it optional or

Re: [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote: > On Sat, May 19, 2018 at 12:09 AM, Janusz Krzysztofik > > wrote: > > + gpiod_rdy = devm_gpiod_get_optional(>dev, "rdy", GPIOD_IN); > > + if (!IS_ERR_OR_NULL(gpiod_rdy)) { > > So, is it optional or not at the end? > If

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

Hi Andy, 2018-05-18 23:03 GMT+01:00 Andy Lutomirski : > On Thu, May 17, 2018 at 4:40 PM Dmitry Safonov wrote: >> Some selftests are failing, but the same way as before the patch >> (ITOW, it's not regression): >> [root@localhost self]# grep FAIL out >> [FAIL]

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

Hi Andy, 2018-05-18 23:03 GMT+01:00 Andy Lutomirski : > On Thu, May 17, 2018 at 4:40 PM Dmitry Safonov wrote: >> Some selftests are failing, but the same way as before the patch >> (ITOW, it's not regression): >> [root@localhost self]# grep FAIL out >> [FAIL] Reg 1 mismatch: requested 0x0; got

[GIT PULL] clk fixes for v4.17-rc5

From: Stephen Boyd The following changes since commit c964cfc612b59910593fa10ee1c2673db274c9c7: Merge tag 'meson-clk-fixes-4.17-1' of https://github.com/BayLibre/clk-meson into clk-fixes (2018-05-01 14:44:16 -0700) are available in the Git repository at:

[GIT PULL] clk fixes for v4.17-rc5

From: Stephen Boyd The following changes since commit c964cfc612b59910593fa10ee1c2673db274c9c7: Merge tag 'meson-clk-fixes-4.17-1' of https://github.com/BayLibre/clk-meson into clk-fixes (2018-05-01 14:44:16 -0700) are available in the Git repository at:

REGRESSION: HiKey eMMC corruption

The last few months have been busy and I've not been ontop of my upstream testing as well as I'd like, but today I did manage to chase down an issue I've been seeing since 4.17-rc1 on the HiKey board, which was causing emmc corruption and stopping the board from booting. Symptoms usually looked

REGRESSION: HiKey eMMC corruption

The last few months have been busy and I've not been ontop of my upstream testing as well as I'd like, but today I did manage to chase down an issue I've been seeing since 4.17-rc1 on the HiKey board, which was causing emmc corruption and stopping the board from booting. Symptoms usually looked

Re: [PATCH 1/2] lib: Add module to simulate atomic sections for testing {preempt,irqs}off tracers

On Sat, May 19, 2018 at 12:09:46AM +0300, Andy Shevchenko wrote: > On Fri, May 18, 2018 at 4:59 AM, Joel Fernandes wrote: > > From: "Joel Fernandes (Google)" > > > > In this patch we introduce a test module for simulating a long atomic > > section in

Re: [PATCH 1/2] lib: Add module to simulate atomic sections for testing {preempt,irqs}off tracers

On Sat, May 19, 2018 at 12:09:46AM +0300, Andy Shevchenko wrote: > On Fri, May 18, 2018 at 4:59 AM, Joel Fernandes wrote: > > From: "Joel Fernandes (Google)" > > > > In this patch we introduce a test module for simulating a long atomic > > section in the kernel which the preemptoff or irqsoff

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, 2018-05-17 at 22:32 -0400, Theodore Y. Ts'o wrote: > On Fri, May 18, 2018 at 01:27:03AM +, Trent Piepho wrote: > > I've hit this on an embedded system. mke2fs hangs trying to format a > > persistent writable filesystem, which is where the random seed to > > initialize the kernel

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, 2018-05-17 at 22:32 -0400, Theodore Y. Ts'o wrote: > On Fri, May 18, 2018 at 01:27:03AM +, Trent Piepho wrote: > > I've hit this on an embedded system. mke2fs hangs trying to format a > > persistent writable filesystem, which is where the random seed to > > initialize the kernel

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

Sedat, Thanks for the report. We have a fix ready in https://bugs.llvm.org/show_bug.cgi?id=37512. Can you report what version of clang you were using and if earlier versions of clang have this issue? Thanks, ~Nick

Re: Clang patch stacks for LTS kernels (v4.4 and v4.9) and status update

Sedat, Thanks for the report. We have a fix ready in https://bugs.llvm.org/show_bug.cgi?id=37512. Can you report what version of clang you were using and if earlier versions of clang have this issue? Thanks, ~Nick

[PATCH] MAINTAINERS: Change hugetlbfs maintainer and update files

The current hugetlbfs maintainer has not been active for more than a few years. I have been been active in this area for more than two years and plan to remain active in the foreseeable future. Also, update the hugetlbfs entry to include linux-mm mail list and additional hugetlbfs related files.

[PATCH] MAINTAINERS: Change hugetlbfs maintainer and update files

The current hugetlbfs maintainer has not been active for more than a few years. I have been been active in this area for more than two years and plan to remain active in the foreseeable future. Also, update the hugetlbfs entry to include linux-mm mail list and additional hugetlbfs related files.

[PATCH] soc: qcom: geni: Make version macros simpler

This macro doesn't work, because it hides a local variable inside of the macro to hold the version and that variable name is called 'ver' and 'version' sometimes. Let's change this to be more explicit. Introduce three macros for the major, minor, and step of the version, and require callers to

[PATCH] soc: qcom: geni: Make version macros simpler

This macro doesn't work, because it hides a local variable inside of the macro to hold the version and that variable name is called 'ver' and 'version' sometimes. Let's change this to be more explicit. Introduce three macros for the major, minor, and step of the version, and require callers to

Re: WARNING and PANIC in irq_matrix_free

Hi Thomas, Tariq, 2018-02-20 18:11 GMT+00:00 Thomas Gleixner : > On Tue, 20 Feb 2018, Tariq Toukan wrote: > >> Hi Thomas, >> >> We started seeing new issues in our net-device daily regression tests. >> They are related to patch [1] introduced in kernel 4.15-rc1. >> >> We

Re: [PATCH v3 1/6] x86/stacktrace: do not unwind after user regs

On Fri, May 18, 2018 at 08:55:47AM +0200, Ingo Molnar wrote: > > * Jiri Slaby wrote: > > > Josh pointed out, that there is no way a frame can be after user regs. > > So remove the last unwind and the check. > > > > Signed-off-by: Jiri Slaby > > Cc: Thomas

Re: [PATCH v3 1/6] x86/stacktrace: do not unwind after user regs

On Fri, May 18, 2018 at 08:55:47AM +0200, Ingo Molnar wrote: > > * Jiri Slaby wrote: > > > Josh pointed out, that there is no way a frame can be after user regs. > > So remove the last unwind and the check. > > > > Signed-off-by: Jiri Slaby > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > >

Re: WARNING and PANIC in irq_matrix_free

Hi Thomas, Tariq, 2018-02-20 18:11 GMT+00:00 Thomas Gleixner : > On Tue, 20 Feb 2018, Tariq Toukan wrote: > >> Hi Thomas, >> >> We started seeing new issues in our net-device daily regression tests. >> They are related to patch [1] introduced in kernel 4.15-rc1. >> >> We frequently see a warning

Re: [PATCH v4 3/4] tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf

On Mon Mar 26 18, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_get_tpm_pt() to use it. Signed-off-by: Jarkko Sakkinen Reviewed-by: Jerry Snitselaar ---

Re: [PATCH v4 3/4] tpm: migrate tpm2_get_tpm_pt() to use struct tpm_buf

On Mon Mar 26 18, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_get_tpm_pt() to use it. Signed-off-by: Jarkko Sakkinen Reviewed-by: Jerry Snitselaar --- drivers/char/tpm/tpm2-cmd.c | 63

Re: [PATCH v4 2/4] tpm: migrate tpm2_probe() to use struct tpm_buf

On Mon Mar 26 18, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_probe() to use it. Signed-off-by: Jarkko Sakkinen Acked-by: Jay Freyensee Reviewed-by: Jerry

Re: [PATCH v4 2/4] tpm: migrate tpm2_probe() to use struct tpm_buf

On Mon Mar 26 18, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_probe() to use it. Signed-off-by: Jarkko Sakkinen Acked-by: Jay Freyensee Reviewed-by: Jerry Snitselaar --- drivers/char/tpm/tpm2-cmd.c | 37

Re: [PATCH net-next v2 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST

Hi Florian, I love your patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-ethernet-ti-Allow-most-drivers-with-COMPILE_TEST/20180519-043005 config: sparc64-allyesconfig (attached as .config)

Re: [PATCH net-next v2 1/3] net: ethernet: ti: Allow most drivers with COMPILE_TEST

Hi Florian, I love your patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/net-ethernet-ti-Allow-most-drivers-with-COMPILE_TEST/20180519-043005 config: sparc64-allyesconfig (attached as .config)

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, 18 May 2018 10:50:25 -0700 Matthew Wilcox wrote: > If the radix tree underlying the IDR happens to be full and we attempt > to remove an id which is larger than any id in the IDR, we will call > __radix_tree_delete() with an uninitialised 'slot' pointer, at which >

Re: [PATCH] idr: fix invalid ptr dereference on item delete

On Fri, 18 May 2018 10:50:25 -0700 Matthew Wilcox wrote: > If the radix tree underlying the IDR happens to be full and we attempt > to remove an id which is larger than any id in the IDR, we will call > __radix_tree_delete() with an uninitialised 'slot' pointer, at which > point anything could

[PATCH] PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS

From: Bjorn Helgaas Host bridge drivers do not use the portdrv interfaces (struct pcie_device, struct pcie_port_service_driver, pcie_port_service_register(), etc), and they should not select CONFIG_PCIEPORTBUS. If users need the portdrv services, they can select

[PATCH] PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS

From: Bjorn Helgaas Host bridge drivers do not use the portdrv interfaces (struct pcie_device, struct pcie_port_service_driver, pcie_port_service_register(), etc), and they should not select CONFIG_PCIEPORTBUS. If users need the portdrv services, they can select CONFIG_PCIEPORTBUS just like all

Re: [PATCH v4 1/4] tpm: migrate tpm2_shutdown() to use struct tpm_buf

On Mon Mar 26 18, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_shutdown() to use it. In addition, removed the klog entry when tpm_transmit_cmd() fails because tpm_tansmit_cmd() already prints an error message.

Re: [PATCH v4 1/4] tpm: migrate tpm2_shutdown() to use struct tpm_buf

On Mon Mar 26 18, Jarkko Sakkinen wrote: In order to make struct tpm_buf the first class object for constructing TPM commands, migrate tpm2_shutdown() to use it. In addition, removed the klog entry when tpm_transmit_cmd() fails because tpm_tansmit_cmd() already prints an error message.

[PATCH v2] selftests: net: reuseport_bpf_numa: don't fail if no numa support

The reuseport_bpf_numa test case fails there's no numa support. The test shouldn't fail if there's no support it should be skipped. Fixes: 3c2c3c16aaf6 ("reuseport, bpf: add test case for bpf_get_numa_node_id") Signed-off-by: Anders Roxell ---

[PATCH v2] selftests: net: reuseport_bpf_numa: don't fail if no numa support

The reuseport_bpf_numa test case fails there's no numa support. The test shouldn't fail if there's no support it should be skipped. Fixes: 3c2c3c16aaf6 ("reuseport, bpf: add test case for bpf_get_numa_node_id") Signed-off-by: Anders Roxell --- tools/testing/selftests/net/reuseport_bpf_numa.c |

Re: [PATCH v2] usbip: vhci_sysfs: fix potential Spectre v1

On 05/18/2018 11:06 AM, Shuah Khan wrote: On 05/18/2018 07:47 AM, Greg Kroah-Hartman wrote: On Thu, May 17, 2018 at 03:16:28PM -0500, Gustavo A. R. Silva wrote: pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1

Re: [PATCH v2] usbip: vhci_sysfs: fix potential Spectre v1

On 05/18/2018 11:06 AM, Shuah Khan wrote: On 05/18/2018 07:47 AM, Greg Kroah-Hartman wrote: On Thu, May 17, 2018 at 03:16:28PM -0500, Gustavo A. R. Silva wrote: pdev_nr and rhport can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1

Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

On Thu, May 17, 2018 at 05:16:13PM -0700, David Collins wrote: > On 05/17/2018 02:22 PM, Doug Anderson wrote: > > On Fri, May 11, 2018 at 7:28 PM, David Collins > > wrote: > >> +- qcom,regulator-initial-microvolt > >> + Usage: optional; VRM regulators only >

Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings

On Thu, May 17, 2018 at 05:16:13PM -0700, David Collins wrote: > On 05/17/2018 02:22 PM, Doug Anderson wrote: > > On Fri, May 11, 2018 at 7:28 PM, David Collins > > wrote: > >> +- qcom,regulator-initial-microvolt > >> + Usage: optional; VRM regulators only > >> + Value type: >

Re: [PATCH v3 2/6] mfd: at91-usart: added mfd driver for usart

On Fri, May 11, 2018 at 01:38:18PM +0300, Radu Pirea wrote: > This mfd driver is just a wrapper over atmel_serial driver and > spi-at91-usart driver. Selection of one of the drivers is based on a > property from device tree. If the property is not specified, the default > driver is atmel_serial. >

Re: [PATCH v3 2/6] mfd: at91-usart: added mfd driver for usart

On Fri, May 11, 2018 at 01:38:18PM +0300, Radu Pirea wrote: > This mfd driver is just a wrapper over atmel_serial driver and > spi-at91-usart driver. Selection of one of the drivers is based on a > property from device tree. If the property is not specified, the default > driver is atmel_serial. >

Re: [Xen-devel][RFC 2/3] xen/grant-table: Extend API to work with DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/grant-table.c | 49 +++ >

Re: [Xen-devel][RFC 2/3] xen/grant-table: Extend API to work with DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/grant-table.c | 49 +++ > include/xen/grant_table.h | 7 ++ > 2 files changed, 56 insertions(+) > > diff

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/18/2018 05:08 PM, Dan Williams wrote: Oh I see now. Just to double check, then something like the following would be broken too, because is basically the same as the code above, and well, it doesn't make much sense to store the value returned by macro array_index_nospec into x,

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/18/2018 05:08 PM, Dan Williams wrote: Oh I see now. Just to double check, then something like the following would be broken too, because is basically the same as the code above, and well, it doesn't make much sense to store the value returned by macro array_index_nospec into x,

Re: [PATCH] kernel: sys: fix potential Spectre v1

On Fri, May 18, 2018 at 3:01 PM, Gustavo A. R. Silva wrote: > > > On 05/18/2018 04:45 PM, Dan Williams wrote: >> >> On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva >> wrote: >>> >>> >>> >>> On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote:

Re: [PATCH] kernel: sys: fix potential Spectre v1

On Fri, May 18, 2018 at 3:01 PM, Gustavo A. R. Silva wrote: > > > On 05/18/2018 04:45 PM, Dan Williams wrote: >> >> On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva >> wrote: >>> >>> >>> >>> On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote: >>> >>> >>> >> >> Oops, it

Re: [PATCH 2/2] pwm: stm32: initialize raw local variables

On Fri, May 18, 2018 at 05:24:04PM +0200, Fabrice Gasnier wrote: > This removes build warning when COMPILE_TEST=y and MFD_STM32_TIMERS=n > in drivers/pwm/pwm-stm32.c. In function 'stm32_pwm_capture' 'raw_prd' and > 'raw_dty' may be used uninitialized in this function > [-Wmaybe-uninitialized] > >

Re: [PATCH 2/2] pwm: stm32: initialize raw local variables

On Fri, May 18, 2018 at 05:24:04PM +0200, Fabrice Gasnier wrote: > This removes build warning when COMPILE_TEST=y and MFD_STM32_TIMERS=n > in drivers/pwm/pwm-stm32.c. In function 'stm32_pwm_capture' 'raw_prd' and > 'raw_dty' may be used uninitialized in this function > [-Wmaybe-uninitialized] > >

[PATCH 3/3] mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus

From: Corneliu Doban The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to properly reset the host controller (reset all) on initialization after exiting deep sleep. Signed-off-by: Corneliu Doban Signed-off-by: Scott Branden

[PATCH 3/3] mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus

From: Corneliu Doban The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to properly reset the host controller (reset all) on initialization after exiting deep sleep. Signed-off-by: Corneliu Doban Signed-off-by: Scott Branden Reviewed-by: Ray Jui Reviewed-by: Srinath Mannam ---

[PATCH 1/3] mmc: sdhci-iproc: remove hard coded mmc cap 1.8v

From: Srinath Mannam Remove hard coded mmc cap 1.8v from platform data as it is board specific. The 1.8v DDR mmc caps can be enabled using DTS property for those boards that support it. Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data")

[PATCH 1/3] mmc: sdhci-iproc: remove hard coded mmc cap 1.8v

From: Srinath Mannam Remove hard coded mmc cap 1.8v from platform data as it is board specific. The 1.8v DDR mmc caps can be enabled using DTS property for those boards that support it. Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data") Signed-off-by: Srinath Mannam

[PATCH 2/3] mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

From: Corneliu Doban When the host controller accepts only 32bit writes, the value of the 16bit TRANSFER_MODE register, that has the same 32bit address as the 16bit COMMAND register, needs to be saved and it will be written in a 32bit write together with the command

[PATCH 0/3] mmc: sdhci-iproc: UHS and 32bit access fixes

Collection of bug fixes for sdhci-iproc driver. - fix for 32bit writes for TRANSFER_MODE register by correcting shadow register logic - fix for deep sleep mode by adding SDHCI_QUIRK2_HOST_OFF_CARD_ON - remove hard coded mmc capability of 1.8V to allow boards to be supported that do support 1.8V.

[PATCH 2/3] mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

From: Corneliu Doban When the host controller accepts only 32bit writes, the value of the 16bit TRANSFER_MODE register, that has the same 32bit address as the 16bit COMMAND register, needs to be saved and it will be written in a 32bit write together with the command as this will trigger the host

[PATCH 0/3] mmc: sdhci-iproc: UHS and 32bit access fixes

Collection of bug fixes for sdhci-iproc driver. - fix for 32bit writes for TRANSFER_MODE register by correcting shadow register logic - fix for deep sleep mode by adding SDHCI_QUIRK2_HOST_OFF_CARD_ON - remove hard coded mmc capability of 1.8V to allow boards to be supported that do support 1.8V.

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

On Thu, May 17, 2018 at 4:40 PM Dmitry Safonov wrote: > Some selftests are failing, but the same way as before the patch > (ITOW, it's not regression): > [root@localhost self]# grep FAIL out > [FAIL] Reg 1 mismatch: requested 0x0; got 0x3 > [FAIL] Reg 15 mismatch: requested

Re: [PATCH] x86/mm: Drop TS_COMPAT on 64-bit exec() syscall

On Thu, May 17, 2018 at 4:40 PM Dmitry Safonov wrote: > Some selftests are failing, but the same way as before the patch > (ITOW, it's not regression): > [root@localhost self]# grep FAIL out > [FAIL] Reg 1 mismatch: requested 0x0; got 0x3 > [FAIL] Reg 15 mismatch: requested 0x8badf00d5aadc0de;

Re: [PATCH v2 07/11] cpufreq: tegra20: Remove unnecessary parentheses

On Fri, May 18, 2018 at 11:06:38PM +0300, Dmitry Osipenko wrote: > Remove unnecessary parentheses as suggested by the checkpatch script. > > Signed-off-by: Dmitry Osipenko > --- > drivers/cpufreq/tegra20-cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v2 07/11] cpufreq: tegra20: Remove unnecessary parentheses

On Fri, May 18, 2018 at 11:06:38PM +0300, Dmitry Osipenko wrote: > Remove unnecessary parentheses as suggested by the checkpatch script. > > Signed-off-by: Dmitry Osipenko > --- > drivers/cpufreq/tegra20-cpufreq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Thierry Reding

Re: [PATCH v2 1/4] mm: change type of free_contig_range(nr_pages) to unsigned long

On 05/18/2018 02:12 AM, Vlastimil Babka wrote: > On 05/04/2018 01:29 AM, Mike Kravetz wrote: >> free_contig_range() is currently defined as: >> void free_contig_range(unsigned long pfn, unsigned nr_pages); >> change to, >> void free_contig_range(unsigned long pfn, unsigned long nr_pages); >> >>

Re: [PATCH v2 1/4] mm: change type of free_contig_range(nr_pages) to unsigned long

On 05/18/2018 02:12 AM, Vlastimil Babka wrote: > On 05/04/2018 01:29 AM, Mike Kravetz wrote: >> free_contig_range() is currently defined as: >> void free_contig_range(unsigned long pfn, unsigned nr_pages); >> change to, >> void free_contig_range(unsigned long pfn, unsigned long nr_pages); >> >>

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/18/2018 04:45 PM, Dan Williams wrote: On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva wrote: On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote: Oops, it seems I sent the wrong patch. The function would look like this: #ifndef sanitize_index_nospec

Re: [PATCH] kernel: sys: fix potential Spectre v1

On 05/18/2018 04:45 PM, Dan Williams wrote: On Fri, May 18, 2018 at 2:27 PM, Gustavo A. R. Silva wrote: On 05/18/2018 03:44 PM, Gustavo A. R. Silva wrote: Oops, it seems I sent the wrong patch. The function would look like this: #ifndef sanitize_index_nospec inline bool

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko A commit message would be useful. > > Signed-off-by: Oleksandr Andrushchenko > > for (i = 0; i < nr_pages; i++) { > -

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko A commit message would be useful. > > Signed-off-by: Oleksandr Andrushchenko > > for (i = 0; i < nr_pages; i++) { > - page = alloc_page(gfp); > - if (page == NULL) { > -

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 01:35:08PM -0700, Vineet Gupta wrote: > On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: > >On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > >>I never understood the need for this direction. And if memory serves me > >>right, at that time I was seeing

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 01:35:08PM -0700, Vineet Gupta wrote: > On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: > >On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > >>I never understood the need for this direction. And if memory serves me > >>right, at that time I was seeing

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