RE: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

> -Original Message- > From: Thomas Gleixner > Sent: Thursday, April 26, 2018 2:49 PM > To: KY Srinivasan > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; >

RE: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

> -Original Message- > From: Thomas Gleixner > Sent: Thursday, April 26, 2018 2:49 PM > To: KY Srinivasan > Cc: x...@kernel.org; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; > a...@canonical.com; jasow...@redhat.com;

Re: [PATCH v2] mm: huge_memory: Change return type to vm_fault_t

On Wed, Apr 25, 2018 at 12:39 PM, David Rientjes wrote: > On Wed, 25 Apr 2018, Souptick Joarder wrote: > >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT value rather than an errno. Once all

Re: [PATCH v2] mm: huge_memory: Change return type to vm_fault_t

On Wed, Apr 25, 2018 at 12:39 PM, David Rientjes wrote: > On Wed, 25 Apr 2018, Souptick Joarder wrote: > >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT value rather than an errno. Once all instances >> are

Re: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

Hi Srinivasan, I love your patch! Yet something to improve: [auto build test ERROR on v4.17-rc2] [also build test ERROR on next-20180426] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH 1/5] X86: Hyper-V: Enlighten APIC access

Hi Srinivasan, I love your patch! Yet something to improve: [auto build test ERROR on v4.17-rc2] [also build test ERROR on next-20180426] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

[git pull] drm fixes for v4.17-rc3

Hi Linus, Pretty run of the mill for this stage in the cycle. i915: - Black screen fixes - Display w/a fix - HDA codec interop fix sun4i: - tbsa711 tablet regression fix qxl: - Regression fixes due to changes in TTM virtio: - Fix wait event condition msm: - DSI display fixes amdgpu: - fix hang

[git pull] drm fixes for v4.17-rc3

Hi Linus, Pretty run of the mill for this stage in the cycle. i915: - Black screen fixes - Display w/a fix - HDA codec interop fix sun4i: - tbsa711 tablet regression fix qxl: - Regression fixes due to changes in TTM virtio: - Fix wait event condition msm: - DSI display fixes amdgpu: - fix hang

Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote: > In practice if you don't have a floppy device on x86, you don't need ZONE_DMA, I call BS on that, and you actually explain later why it it BS due to some drivers using it more explicitly. But even more importantly we have

Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote: > In practice if you don't have a floppy device on x86, you don't need ZONE_DMA, I call BS on that, and you actually explain later why it it BS due to some drivers using it more explicitly. But even more importantly we have

KASAN: use-after-free Read in process_preds

Hello, syzbot hit the following crash on bpf-next commit 5d1365940a68dd57b031b6e3c07d7d451cd69daf (Thu Apr 12 18:09:05 2018 +) Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=b6fc33dcecb65cd8ff80 Unfortunately,

KASAN: use-after-free Read in process_preds

Hello, syzbot hit the following crash on bpf-next commit 5d1365940a68dd57b031b6e3c07d7d451cd69daf (Thu Apr 12 18:09:05 2018 +) Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=b6fc33dcecb65cd8ff80 Unfortunately,

KASAN: slab-out-of-bounds Read in process_preds

Hello, syzbot hit the following crash on bpf-next commit af487c509d4b7f874fe1a33f9289d51b9adc (Wed Apr 25 07:56:11 2018 +) Merge branch 'bpf-optimize-neg-sums' syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=e47d942a98e75b4bd03e Unfortunately, I don't have any

KASAN: slab-out-of-bounds Read in process_preds

Hello, syzbot hit the following crash on bpf-next commit af487c509d4b7f874fe1a33f9289d51b9adc (Wed Apr 25 07:56:11 2018 +) Merge branch 'bpf-optimize-neg-sums' syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=e47d942a98e75b4bd03e Unfortunately, I don't have any

BUG: unable to handle kernel paging request in process_preds

Hello, syzbot hit the following crash on bpf-next commit 0c90f2243ec67eeacf9624ae52ab43c734fe0e93 (Wed Apr 18 02:46:34 2018 +) tools: bpftool: make it easier to feed hex bytes to bpftool syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=b76562b749bb67fca79f Unfortunately, I

BUG: unable to handle kernel paging request in process_preds

Hello, syzbot hit the following crash on bpf-next commit 0c90f2243ec67eeacf9624ae52ab43c734fe0e93 (Wed Apr 18 02:46:34 2018 +) tools: bpftool: make it easier to feed hex bytes to bpftool syzbot dashboard link: https://syzkaller.appspot.com/bug?extid=b76562b749bb67fca79f Unfortunately, I

[PATCH] NFS: Avoid quadratic search when freeing delegations.

If an NFS client has 10,000 delegations which are between 90 and 180 seconds old, and 10,000 which are between 180 and 270 seconds old, with none of them still in use, it is likely that the old ones are at the end of the list. The first 10,000 will not be marked to be returned, the last 10,000

[PATCH] NFS: Avoid quadratic search when freeing delegations.

If an NFS client has 10,000 delegations which are between 90 and 180 seconds old, and 10,000 which are between 180 and 270 seconds old, with none of them still in use, it is likely that the old ones are at the end of the list. The first 10,000 will not be marked to be returned, the last 10,000

[PATCH v3] net: qrtr: Expose tunneling endpoint to user space

This implements a misc character device named "qrtr-tun" for the purpose of allowing user space applications to implement endpoints in the qrtr network. This allows more advanced (and dynamic) testing of the qrtr code as well as opens up the ability of tunneling qrtr over a network or USB link.

[PATCH v3] net: qrtr: Expose tunneling endpoint to user space

This implements a misc character device named "qrtr-tun" for the purpose of allowing user space applications to implement endpoints in the qrtr network. This allows more advanced (and dynamic) testing of the qrtr code as well as opens up the ability of tunneling qrtr over a network or USB link.

[PATCH] ASoC: uniphier: remove boilerplate from lisence comment

This patch removes boilerplate of GPLv2, use only SPDX identifier as same as other recently ASoC DAI drivers. Signed-off-by: Katsuhiro Suzuki --- sound/soc/uniphier/aio-compress.c | 13 - sound/soc/uniphier/aio-core.c | 13 -

[PATCH] ASoC: uniphier: remove boilerplate from lisence comment

This patch removes boilerplate of GPLv2, use only SPDX identifier as same as other recently ASoC DAI drivers. Signed-off-by: Katsuhiro Suzuki --- sound/soc/uniphier/aio-compress.c | 13 - sound/soc/uniphier/aio-core.c | 13 - sound/soc/uniphier/aio-cpu.c | 13

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

Hi Sean, > This adds a driver for the MediaTek serial protocol based on H4 protocol, > which can enable the built-in Bluetooth device inside MT7622 SoC. > > Signed-off-by: Sean Wang > --- > > [... snip ...] > > + > + /* Start to build a WMT

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

Hi Sean, > This adds a driver for the MediaTek serial protocol based on H4 protocol, > which can enable the built-in Bluetooth device inside MT7622 SoC. > > Signed-off-by: Sean Wang > --- > > [... snip ...] > > + > + /* Start to build a WMT header and its actual

Re: [PATCH v6] fs: dax: Adding new return type vm_fault_t

> I noticed that we have the following status translation now in 4 places in 2 > files: > > if (err == -ENOMEM) > return VM_FAULT_OOM; > if (err < 0 && err != -EBUSY) > return VM_FAULT_SIGBUS; > return VM_FAULT_NOPAGE; > > > This happens in

Re: [PATCH v6] fs: dax: Adding new return type vm_fault_t

> I noticed that we have the following status translation now in 4 places in 2 > files: > > if (err == -ENOMEM) > return VM_FAULT_OOM; > if (err < 0 && err != -EBUSY) > return VM_FAULT_SIGBUS; > return VM_FAULT_NOPAGE; > > > This happens in

Re: [PULL 0/1] vfio-ccw: another bugfix

On Tue, 24 Apr 2018 13:26:55 +0200 Cornelia Huck wrote: > The following changes since commit 6cf09958f32b9667bb3ebadf74367c791112771b: > > s390: correct module section names for expoline code revert (2018-04-23 > 07:57:17 +0200) > > are available in the Git repository at:

Re: [PULL 0/1] vfio-ccw: another bugfix

On Tue, 24 Apr 2018 13:26:55 +0200 Cornelia Huck wrote: > The following changes since commit 6cf09958f32b9667bb3ebadf74367c791112771b: > > s390: correct module section names for expoline code revert (2018-04-23 > 07:57:17 +0200) > > are available in the Git repository at: > >

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

> The CRNG changes were needed because were erroneously saying that the > entropy pool was securely initialized before it really was. Saying > that CRNG should be able to init on its own is much like saying, "Ted > should be able to fly wherever he wants in his own personal Gulfstream > V." It

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

> The CRNG changes were needed because were erroneously saying that the > entropy pool was securely initialized before it really was. Saying > that CRNG should be able to init on its own is much like saying, "Ted > should be able to fly wherever he wants in his own personal Gulfstream > V." It

Re: [PATCH v2] nvme: change order of qid and cmdid in completion trace

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH v2] nvme: change order of qid and cmdid in completion trace

Looks good, Reviewed-by: Christoph Hellwig

Re: testing io.low limit for blk-throttle

> Il giorno 27 apr 2018, alle ore 05:27, Joseph Qi ha > scritto: > > Hi Paolo, > > On 18/4/27 01:27, Paolo Valente wrote: >> >> >>> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi ha >>> scritto: >>> >>> Hi Paolo, >>> >> >> Hi Joseph >>

Re: testing io.low limit for blk-throttle

> Il giorno 27 apr 2018, alle ore 05:27, Joseph Qi ha > scritto: > > Hi Paolo, > > On 18/4/27 01:27, Paolo Valente wrote: >> >> >>> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi ha >>> scritto: >>> >>> Hi Paolo, >>> >> >> Hi Joseph >> >>> ... >>> Could you run blktrace as well

Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable

On 2018-04-25 21:17, Laura Abbott wrote: On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote: From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when there is high ION page pool since ION page pool is

Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable

On 2018-04-25 21:17, Laura Abbott wrote: On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote: From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when there is high ION page pool since ION page pool is not considered

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Thu, 26 Apr 2018 22:48:24 -0400 Steven Rostedt wrote: > On Fri, 27 Apr 2018 11:39:51 +0900 > Masami Hiramatsu wrote: > > > On Thu, 26 Apr 2018 21:13:51 -0400 > > Steven Rostedt wrote: > > > > > On Thu, 26 Apr 2018 17:10:03

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Thu, 26 Apr 2018 22:48:24 -0400 Steven Rostedt wrote: > On Fri, 27 Apr 2018 11:39:51 +0900 > Masami Hiramatsu wrote: > > > On Thu, 26 Apr 2018 21:13:51 -0400 > > Steven Rostedt wrote: > > > > > On Thu, 26 Apr 2018 17:10:03 +0900 > > > Masami Hiramatsu wrote: > > > > > > > Replace %p

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote: > Request IRQ with IRQF_SHARED flag. This works since the interrupt > handler already checks if there is an actual IRQ pending and returns > IRQ_NONE otherwise. hmmm what are we trying to fix here? Is your device on a shared line or

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote: > Request IRQ with IRQF_SHARED flag. This works since the interrupt > handler already checks if there is an actual IRQ pending and returns > IRQ_NONE otherwise. hmmm what are we trying to fix here? Is your device on a shared line or

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

Quoting Jerome Brunet (2018-02-02 04:50:28) > On Thu, 2018-02-01 at 09:43 -0800, Stephen Boyd wrote: > > > > > Applied to clk-protect-rate, with the exception that I did not apply > > > > > "clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks > > > > > qcom clk code. > > > > > > >

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

Quoting Jerome Brunet (2018-02-02 04:50:28) > On Thu, 2018-02-01 at 09:43 -0800, Stephen Boyd wrote: > > > > > Applied to clk-protect-rate, with the exception that I did not apply > > > > > "clk: fix CLK_SET_RATE_GATE with clock rate protection" as it breaks > > > > > qcom clk code. > > > > > > >

Re: [PATCH v4 1/2] perf: uncore: Adding documentation for ThunderX2 pmu uncore driver

On Fri, Apr 27, 2018 at 2:25 AM, Randy Dunlap wrote: > Hi, > > Just a few typo corrections... > > On 04/25/2018 02:00 AM, Ganapatrao Kulkarni wrote: >> Documentation for the UNCORE PMUs on Cavium's ThunderX2 SoC. >> The SoC has PMU support in its L3 cache controller (L3C)

Re: [PATCH v4 1/2] perf: uncore: Adding documentation for ThunderX2 pmu uncore driver

On Fri, Apr 27, 2018 at 2:25 AM, Randy Dunlap wrote: > Hi, > > Just a few typo corrections... > > On 04/25/2018 02:00 AM, Ganapatrao Kulkarni wrote: >> Documentation for the UNCORE PMUs on Cavium's ThunderX2 SoC. >> The SoC has PMU support in its L3 cache controller (L3C) and in the >> DDR4

Re: [PATCH] arm64: dts: uniphier: stabilize ethernet of LD20 reference boar

2018-04-27 13:25 GMT+09:00 Masahiro Yamada : > Currently, the ethernet RGMII mode on the LD20 reference board is > unstable. > > The default drive-strength of ethernet TX pins is too strong because > there is no dumping resistor on the TX lines on the board. > >

Re: [PATCH] arm64: dts: uniphier: stabilize ethernet of LD20 reference boar

2018-04-27 13:25 GMT+09:00 Masahiro Yamada : > Currently, the ethernet RGMII mode on the LD20 reference board is > unstable. > > The default drive-strength of ethernet TX pins is too strong because > there is no dumping resistor on the TX lines on the board. > > Weaken the drive-strength to make

[PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on

In recent tests with IRQ on/off tracepoints, a large performance overhead ~10% is noticed when running hackbench. This is root caused to calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the tracepoint code. Following a long discussion on the list [1] about this, we concluded that srcu is

[PATCH RFC] tracepoint: Introduce tracepoint callbacks executing with preempt on

In recent tests with IRQ on/off tracepoints, a large performance overhead ~10% is noticed when running hackbench. This is root caused to calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the tracepoint code. Following a long discussion on the list [1] about this, we concluded that srcu is

[PATCH] arm64: dts: uniphier: stabilize ethernet of LD20 reference boar

Currently, the ethernet RGMII mode on the LD20 reference board is unstable. The default drive-strength of ethernet TX pins is too strong because there is no dumping resistor on the TX lines on the board. Weaken the drive-strength to make the ethernet more stable. Signed-off-by: Masahiro Yamada

[PATCH] arm64: dts: uniphier: stabilize ethernet of LD20 reference boar

Currently, the ethernet RGMII mode on the LD20 reference board is unstable. The default drive-strength of ethernet TX pins is too strong because there is no dumping resistor on the TX lines on the board. Weaken the drive-strength to make the ethernet more stable. Signed-off-by: Masahiro Yamada

Re: [RFC v3 0/5] virtio: support packed ring

On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote: > > > On 2018年04月25日 13:15, Tiwei Bie wrote: > > Hello everyone, > > > > This RFC implements packed ring support in virtio driver. > > > > Some simple functional tests have been done with Jason's > > packed ring implementation in

Re: [RFC v3 0/5] virtio: support packed ring

On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote: > > > On 2018年04月25日 13:15, Tiwei Bie wrote: > > Hello everyone, > > > > This RFC implements packed ring support in virtio driver. > > > > Some simple functional tests have been done with Jason's > > packed ring implementation in

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

On Thu, 2018-04-26 at 11:47 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>> This adds a driver for the MediaTek serial protocol based on H4 protocol, > >>> which can enable the built-in Bluetooth device inside MT7622 SoC. > >>> > >>> Signed-off-by: Sean Wang > >>> ---

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

On Thu, 2018-04-26 at 11:47 +0200, Marcel Holtmann wrote: > Hi Sean, > > >>> This adds a driver for the MediaTek serial protocol based on H4 protocol, > >>> which can enable the built-in Bluetooth device inside MT7622 SoC. > >>> > >>> Signed-off-by: Sean Wang > >>> --- [... snip ...] > >>> +

Re: random: GFP_KERNEL from irq context

On 4/26/18 3:03 PM, Theodore Y. Ts'o wrote: > On Thu, Apr 26, 2018 at 10:28:13AM -0600, Jens Axboe wrote: >> during boot. We end up doing the numa_crng_init() from interrupt context, >> which >> makes things unhappy since you do GFP_KERNEL | __GFP_NOFAIL allocations from >> there. > > I've

Re: random: GFP_KERNEL from irq context

On 4/26/18 3:03 PM, Theodore Y. Ts'o wrote: > On Thu, Apr 26, 2018 at 10:28:13AM -0600, Jens Axboe wrote: >> during boot. We end up doing the numa_crng_init() from interrupt context, >> which >> makes things unhappy since you do GFP_KERNEL | __GFP_NOFAIL allocations from >> there. > > I've

[PATCH] softirq: reorder trace_softirqs_on to prevent lockdep splat

I'm able to reproduce a lockdep splat when CONFIG_PROVE_LOCKING=y and CONFIG_PREEMPTIRQ_EVENTS=y. $ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable --- [ 26.112609] DEBUG_LOCKS_WARN_ON(current->softirqs_enabled) [ 26.112636] WARNING: CPU: 0 PID: 118 at

[PATCH] softirq: reorder trace_softirqs_on to prevent lockdep splat

I'm able to reproduce a lockdep splat when CONFIG_PROVE_LOCKING=y and CONFIG_PREEMPTIRQ_EVENTS=y. $ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable --- [ 26.112609] DEBUG_LOCKS_WARN_ON(current->softirqs_enabled) [ 26.112636] WARNING: CPU: 0 PID: 118 at

Re: [RFC v3 0/5] virtio: support packed ring

On 2018年04月25日 13:15, Tiwei Bie wrote: Hello everyone, This RFC implements packed ring support in virtio driver. Some simple functional tests have been done with Jason's packed ring implementation in vhost: https://lkml.org/lkml/2018/4/23/12 Both of ping and netperf worked as expected

Re: [RFC v3 0/5] virtio: support packed ring

On 2018年04月25日 13:15, Tiwei Bie wrote: Hello everyone, This RFC implements packed ring support in virtio driver. Some simple functional tests have been done with Jason's packed ring implementation in vhost: https://lkml.org/lkml/2018/4/23/12 Both of ping and netperf worked as expected

Re: [PATCH] net: phy: marvell: clear wol event before setting it

Hi Andrew/Jisheng, On 4/26/2018 6:10 PM, Andrew Lunn wrote: hmm, so you want a "stick" WOL feature, I dunno whether Linux kernel requires WOL should be "stick". I see two different cases: Suspend/resume: The WoL state in the kernel is probably kept across such a cycle. If so, you would expect

Re: [PATCH] net: phy: marvell: clear wol event before setting it

Hi Andrew/Jisheng, On 4/26/2018 6:10 PM, Andrew Lunn wrote: hmm, so you want a "stick" WOL feature, I dunno whether Linux kernel requires WOL should be "stick". I see two different cases: Suspend/resume: The WoL state in the kernel is probably kept across such a cycle. If so, you would expect

Re: testing io.low limit for blk-throttle

Hi Paolo, On 18/4/27 01:27, Paolo Valente wrote: > > >> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi ha >> scritto: >> >> Hi Paolo, >> > > Hi Joseph > >> ... >> Could you run blktrace as well when testing your case? There are several >> throtl traces to help

Re: testing io.low limit for blk-throttle

Hi Paolo, On 18/4/27 01:27, Paolo Valente wrote: > > >> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi ha >> scritto: >> >> Hi Paolo, >> > > Hi Joseph > >> ... >> Could you run blktrace as well when testing your case? There are several >> throtl traces to help analyze whether it is caused

Re: [PATCH] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998

On Thu, Apr 19, 2018 at 04:00:32PM -0700, Stephen Boyd wrote: > Add the compatibles and PMIC ids for the pm8005, pm8998, and pmi8998 > PMICS found on MSM8998 and SDM845 based platforms. > > Cc: > Signed-off-by: Stephen Boyd > --- >

Re: [PATCH] mfd: qcom-spmi-pmic: Add support for pm8005,pm8998,pmi8998

On Thu, Apr 19, 2018 at 04:00:32PM -0700, Stephen Boyd wrote: > Add the compatibles and PMIC ids for the pm8005, pm8998, and pmi8998 > PMICS found on MSM8998 and SDM845 based platforms. > > Cc: > Signed-off-by: Stephen Boyd > --- > Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 3

Re: [PATCH] reset: uniphier: add LD11/LD20 stream demux system reset control

2018-04-27 9:41 GMT+09:00 Katsuhiro Suzuki : > Add reset lines for MPEG2 transport stream I/O and demux system (HSC) > on UniPhier LD11/LD20 SoCs. > > Signed-off-by: Katsuhiro Suzuki > --- Acked-by: Masahiro Yamada

Re: [PATCH] reset: uniphier: add LD11/LD20 stream demux system reset control

2018-04-27 9:41 GMT+09:00 Katsuhiro Suzuki : > Add reset lines for MPEG2 transport stream I/O and demux system (HSC) > on UniPhier LD11/LD20 SoCs. > > Signed-off-by: Katsuhiro Suzuki > --- Acked-by: Masahiro Yamada -- Best Regards Masahiro Yamada

Re: [PATCH] clk: uniphier: add LD11/LD20 stream demux system clock

2018-04-27 9:40 GMT+09:00 Katsuhiro Suzuki : > Add clock for MPEG2 transport stream I/O and demux system (HSC) on > UniPhier LD11/LD20 SoCs. > > Signed-off-by: Katsuhiro Suzuki > --- Acked-by: Masahiro Yamada

Re: [PATCH] clk: uniphier: add LD11/LD20 stream demux system clock

2018-04-27 9:40 GMT+09:00 Katsuhiro Suzuki : > Add clock for MPEG2 transport stream I/O and demux system (HSC) on > UniPhier LD11/LD20 SoCs. > > Signed-off-by: Katsuhiro Suzuki > --- Acked-by: Masahiro Yamada -- Best Regards Masahiro Yamada

[PATCH 1/2] hwmon: (k10temp) Fix reading critical temperature register

The HTC (Hardware Temperature Control) register has moved for recent chips. Signed-off-by: Guenter Roeck --- Compile tested only. drivers/hwmon/k10temp.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-) diff --git

[PATCH 1/2] hwmon: (k10temp) Fix reading critical temperature register

The HTC (Hardware Temperature Control) register has moved for recent chips. Signed-off-by: Guenter Roeck --- Compile tested only. drivers/hwmon/k10temp.c | 37 + 1 file changed, 29 insertions(+), 8 deletions(-) diff --git a/drivers/hwmon/k10temp.c

[PATCH 2/2] hwmon: (k10temp) Display both Tctl and Tdie

On some AMD CPUs, there is a different between the die temperature (Tdie) and the reported temperature (Tctl). Tdie is the real measured temperature, and Tctl is used for fan control. Lets report both for affected CPUs. Signed-off-by: Guenter Roeck ---

[PATCH 2/2] hwmon: (k10temp) Display both Tctl and Tdie

On some AMD CPUs, there is a different between the die temperature (Tdie) and the reported temperature (Tctl). Tdie is the real measured temperature, and Tctl is used for fan control. Lets report both for affected CPUs. Signed-off-by: Guenter Roeck --- drivers/hwmon/k10temp.c | 55

Re: [PATCH v2 1/2] pinctrl: uniphier: add LD20 MPEG2-TS I/O pin-mux settings

2018-04-27 10:49 GMT+09:00 Katsuhiro Suzuki : > The MPEG2-TS input/output core both accepts serial TS and parallel TS. > > The serial TS interface uses following pins: > hscin0_s : HS0DOUT[0-3] > hscin1_s : HS0DOUT[4-7] > hscin2_s : HS1BCLKIN, HS1SYNCIN,

Re: [PATCH v2 1/2] pinctrl: uniphier: add LD20 MPEG2-TS I/O pin-mux settings

2018-04-27 10:49 GMT+09:00 Katsuhiro Suzuki : > The MPEG2-TS input/output core both accepts serial TS and parallel TS. > > The serial TS interface uses following pins: > hscin0_s : HS0DOUT[0-3] > hscin1_s : HS0DOUT[4-7] > hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0 > hscin3_s :

Re: [PATCH v2 2/2] pinctrl: uniphier: add LD11 MPEG2-TS I/O pin-mux settings

2018-04-27 10:49 GMT+09:00 Katsuhiro Suzuki : > The MPEG2-TS input/output core both accepts serial TS and parallel TS. > > The serial TS interface uses following pins: > hscin0_s : HS0DOUT[0-3] > hscin1_s : HS0DOUT[4-7] > hscin2_s : HS1BCLKIN, HS1SYNCIN,

Re: [PATCH v2 2/2] pinctrl: uniphier: add LD11 MPEG2-TS I/O pin-mux settings

2018-04-27 10:49 GMT+09:00 Katsuhiro Suzuki : > The MPEG2-TS input/output core both accepts serial TS and parallel TS. > > The serial TS interface uses following pins: > hscin0_s : HS0DOUT[0-3] > hscin1_s : HS0DOUT[4-7] > hscin2_s : HS1BCLKIN, HS1SYNCIN, HS1VALIN, HS1DIN0 > hscout0_s:

Re: [PATCH 2/2] net: stmmac: dwmac-meson: extend phy mode setting

Hi Jerome On 04/26/18 16:47, Jerome Brunet wrote: > On Thu, 2018-04-26 at 16:05 +, Yixun Lan wrote: >> In the Meson-AXG SoC, the phy mode setting of PRG_ETH0 in the glue layer >> is extended from bit[0] to bit[2:0]. >> There is no problem if we configure it to the RGMII 1000M PHY mode, >>

Re: [PATCH 2/2] net: stmmac: dwmac-meson: extend phy mode setting

Hi Jerome On 04/26/18 16:47, Jerome Brunet wrote: > On Thu, 2018-04-26 at 16:05 +, Yixun Lan wrote: >> In the Meson-AXG SoC, the phy mode setting of PRG_ETH0 in the glue layer >> is extended from bit[0] to bit[2:0]. >> There is no problem if we configure it to the RGMII 1000M PHY mode, >>

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

On Thu, Apr 26, 2018 at 09:28:39PM -0500, David Lechner wrote: > On 04/26/2018 12:31 PM, Rich Felker wrote: > >On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote: > >>From: Bartosz Golaszewski > >> > >>This is a follow to my series[1] the aim of which

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

On Thu, Apr 26, 2018 at 09:28:39PM -0500, David Lechner wrote: > On 04/26/2018 12:31 PM, Rich Felker wrote: > >On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote: > >>From: Bartosz Golaszewski > >> > >>This is a follow to my series[1] the aim of which was to introduce device >

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

On Thu, Apr 19, 2018 at 05:45:34PM +0200, Paul Kocialkowski wrote: > This adds a device-tree binding document that specifies the properties > used by the Sunxi-Cedurs VPU driver, as well as examples. > > Signed-off-by: Paul Kocialkowski > --- >

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

On Thu, Apr 19, 2018 at 05:45:34PM +0200, Paul Kocialkowski wrote: > This adds a device-tree binding document that specifies the properties > used by the Sunxi-Cedurs VPU driver, as well as examples. > > Signed-off-by: Paul Kocialkowski > --- > .../devicetree/bindings/media/sunxi-cedrus.txt

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

On Fri, Apr 20, 2018 at 09:22:20AM +0200, Paul Kocialkowski wrote: > Hi and thanks for the review, > > On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote: > > Hi Paul, Philipp, > > > > On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel > > wrote: > > > > > Hi Paul, > > >

Re: [PATCH v2 08/10] dt-bindings: media: Document bindings for the Sunxi-Cedrus VPU driver

On Fri, Apr 20, 2018 at 09:22:20AM +0200, Paul Kocialkowski wrote: > Hi and thanks for the review, > > On Fri, 2018-04-20 at 01:31 +, Tomasz Figa wrote: > > Hi Paul, Philipp, > > > > On Fri, Apr 20, 2018 at 1:04 AM Philipp Zabel > > wrote: > > > > > Hi Paul, > > > On Thu, 2018-04-19 at

Re: [PATCH 2/3] dt-bindings: rtc: update stm32-rtc documentation for stm32mp1 rtc

On Thu, Apr 19, 2018 at 03:34:04PM +0200, Amelie Delaunay wrote: > RTC embedded in stm32mp1 SoC is slightly different from stm32h7 one, it > doesn't require to disable backup domain write protection, and rtc_ck > parent clock assignment isn't allowed. > To sum up, stm32mp1 RTC requires 2 clocks,

Re: [PATCH 2/3] dt-bindings: rtc: update stm32-rtc documentation for stm32mp1 rtc

On Thu, Apr 19, 2018 at 03:34:04PM +0200, Amelie Delaunay wrote: > RTC embedded in stm32mp1 SoC is slightly different from stm32h7 one, it > doesn't require to disable backup domain write protection, and rtc_ck > parent clock assignment isn't allowed. > To sum up, stm32mp1 RTC requires 2 clocks,

Re: [PATCH 3/4] dt-bindings: rtc: update stm32-rtc documentation for st,syscfg property

On Thu, Apr 19, 2018 at 03:21:42PM +0200, Amelie Delaunay wrote: > RTC driver should not be aware of the PWR registers offset and bits > position. Furthermore, we can imagine that Disable Backup Protection (DBP) > relative register and bit mask could change depending on the SoC. So this > patch

Re: [PATCH 3/4] dt-bindings: rtc: update stm32-rtc documentation for st,syscfg property

On Thu, Apr 19, 2018 at 03:21:42PM +0200, Amelie Delaunay wrote: > RTC driver should not be aware of the PWR registers offset and bits > position. Furthermore, we can imagine that Disable Backup Protection (DBP) > relative register and bit mask could change depending on the SoC. So this > patch

[PATCH] crypto: tcrypt: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this allocates the return code buffers before starting jiffie timers, rather than using stack space for the array. Additionally cleans up some exit paths and make sure that the num_mb module_param() is used only once per execution to

[PATCH] crypto: tcrypt: Remove VLA usage

In the quest to remove all stack VLA usage from the kernel[1], this allocates the return code buffers before starting jiffie timers, rather than using stack space for the array. Additionally cleans up some exit paths and make sure that the num_mb module_param() is used only once per execution to

Re: [PATCH 2/2] Revert "f2fs: add ovp valid_blocks check for bg gc victim to fg_gc"

Hi Jaegeuk, Missed this patch, or any problem in it? Thanks, On 2018/4/26 17:05, Chao Yu wrote: > For extreme case: > 10 section, op = 10%, no_fggc_threshold = 90% > All section usage: 85% 85% 85% 85% 90% 90% 95% 95% 95% 95% > > During foreground GC, if we skip select dirty section whose usage

Re: [PATCH 2/2] Revert "f2fs: add ovp valid_blocks check for bg gc victim to fg_gc"

Hi Jaegeuk, Missed this patch, or any problem in it? Thanks, On 2018/4/26 17:05, Chao Yu wrote: > For extreme case: > 10 section, op = 10%, no_fggc_threshold = 90% > All section usage: 85% 85% 85% 85% 90% 90% 95% 95% 95% 95% > > During foreground GC, if we skip select dirty section whose usage

[PATCH v2] clk: aspeed: Support second reset register

The ast2500 has an additional reset register that contains resets not present in the ast2400. This enables support for this register, and adds the one reset line that is controlled by it. Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley --- v2: This

[PATCH v2] clk: aspeed: Support second reset register

The ast2500 has an additional reset register that contains resets not present in the ast2400. This enables support for this register, and adds the one reset line that is controlled by it. Reviewed-by: Andrew Jeffery Signed-off-by: Joel Stanley --- v2: This commit fixes a bug in

Re: [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

On 2018年04月26日 23:06, Michel Dänzer wrote: From: Michel Dänzer When it's set, TTM tries to allocate huge pages if possible. Do you mean original driver doesn't do this? From the code, driver always try huge pages if CONFIG_TRANSPARENT_HUGEPAGE is enabled. Regards,

Re: [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

On 2018年04月26日 23:06, Michel Dänzer wrote: From: Michel Dänzer When it's set, TTM tries to allocate huge pages if possible. Do you mean original driver doesn't do this? From the code, driver always try huge pages if CONFIG_TRANSPARENT_HUGEPAGE is enabled. Regards, David Zhou Drivers

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Fri, 27 Apr 2018 11:39:51 +0900 Masami Hiramatsu wrote: > On Thu, 26 Apr 2018 21:13:51 -0400 > Steven Rostedt wrote: > > > On Thu, 26 Apr 2018 17:10:03 +0900 > > Masami Hiramatsu wrote: > > > > > Replace %p with appropriate

Re: [PATCH -tip v2 4/7] kprobes: Replace %p with other pointer types

On Fri, 27 Apr 2018 11:39:51 +0900 Masami Hiramatsu wrote: > On Thu, 26 Apr 2018 21:13:51 -0400 > Steven Rostedt wrote: > > > On Thu, 26 Apr 2018 17:10:03 +0900 > > Masami Hiramatsu wrote: > > > > > Replace %p with appropriate pointer types (or just remove it) > > > - Use %pS if possible

  1   2   3   4   5   6   7   8   9   10   >