Re: linux-next: manual merge of the mac80211-next tree with the mac80211 tree

Hi Stephen, > between commit: > > b71d856ab536 ("mac80211_hwsim: add workqueue to wait for deferred radio > deletion on mod unload") > > from the mac80211 tree and commit: > > c6509cc3b3e8 ("mac80211_hwsim: add hashtable with mac address keys for > faster lookup") > > from the

Re: linux-next: manual merge of the mac80211-next tree with the mac80211 tree

Hi Stephen, > between commit: > > b71d856ab536 ("mac80211_hwsim: add workqueue to wait for deferred radio > deletion on mod unload") > > from the mac80211 tree and commit: > > c6509cc3b3e8 ("mac80211_hwsim: add hashtable with mac address keys for > faster lookup") > > from the

[PATCH] MAINTAINERS: add the iommu list for swiotlb and xen-swiotlb

All other discussions related to the dma mapping interfaces are on the iommu list, so let's make it the official list for swiotlb and the second list for xen-swiotlb. Signed-off-by: Christoph Hellwig --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[PATCH] MAINTAINERS: add the iommu list for swiotlb and xen-swiotlb

All other discussions related to the dma mapping interfaces are on the iommu list, so let's make it the official list for swiotlb and the second list for xen-swiotlb. Signed-off-by: Christoph Hellwig --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: consolidate swiotlb dma_map implementations

I've pulled this into the dma-mapping for-next tree, including the missing free_pages noted. I'd be fine to rebase another day or two for additional reviews or important fixes.

Re: consolidate swiotlb dma_map implementations

I've pulled this into the dma-mapping for-next tree, including the missing free_pages noted. I'd be fine to rebase another day or two for additional reviews or important fixes.

Re: consolidate direct dma mapping V4

I've pulled this into the dma-mapping for-next branch so that we get a few days exposure before then end of the merge window. If there is anything important (e.g. the powerpc naming issue) please send incremental patches.

Re: consolidate direct dma mapping V4

I've pulled this into the dma-mapping for-next branch so that we get a few days exposure before then end of the merge window. If there is anything important (e.g. the powerpc naming issue) please send incremental patches.

Re: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting

On 01/16/2018 01:57 PM, jianchao.wang wrote: > Hi Max > > Thanks for your kindly comment. > > On 01/15/2018 09:36 PM, Max Gurtovoy wrote: >   case NVME_CTRL_RECONNECTING: >   switch (old_state) { >   case NVME_CTRL_LIVE: >   case NVME_CTRL_RESETTING:

Re: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting

On 01/16/2018 01:57 PM, jianchao.wang wrote: > Hi Max > > Thanks for your kindly comment. > > On 01/15/2018 09:36 PM, Max Gurtovoy wrote: >   case NVME_CTRL_RECONNECTING: >   switch (old_state) { >   case NVME_CTRL_LIVE: >   case NVME_CTRL_RESETTING:

what trees/branches to test on syzbot

Hello, Several people proposed that linux-next should not be tested on syzbot. While some people suggested that it needs to test as many trees as possible. I've initially included linux-next as it is a staging area before upstream tree, with the intention that patches are _tested_ there, is they

what trees/branches to test on syzbot

Hello, Several people proposed that linux-next should not be tested on syzbot. While some people suggested that it needs to test as many trees as possible. I've initially included linux-next as it is a staging area before upstream tree, with the intention that patches are _tested_ there, is they

Re: LKML admins (syzbot emails are not delivered)

On Tue, Jan 16, 2018 at 8:12 AM, Theodore Ts'o wrote: > On Mon, Jan 15, 2018 at 10:38:42AM -0600, Eric W. Biederman wrote: >> >> Sometimes the branches on linux-next are experimental crap. If someone >> adds an experimental memory allocator to linux-next before discovering >> it

Re: LKML admins (syzbot emails are not delivered)

On Tue, Jan 16, 2018 at 8:12 AM, Theodore Ts'o wrote: > On Mon, Jan 15, 2018 at 10:38:42AM -0600, Eric W. Biederman wrote: >> >> Sometimes the branches on linux-next are experimental crap. If someone >> adds an experimental memory allocator to linux-next before discovering >> it causes all kinds

[PATCH v3 1/3] trace-cmd: Make read_proc() to return int status via OUT arg

This patch changes both the implementation and the interface of read_proc() in trace-stack.c. First, it makes the function to read a string from the proc file and then parse it as an integer using strtol(). Then, it makes the function to return the integer read from the proc file using the int

[PATCH v3 1/3] trace-cmd: Make read_proc() to return int status via OUT arg

This patch changes both the implementation and the interface of read_proc() in trace-stack.c. First, it makes the function to read a string from the proc file and then parse it as an integer using strtol(). Then, it makes the function to return the integer read from the proc file using the int

[PATCH v3 2/3] trace-cmd: Remove the die() call from read_proc()

As trace-stack.c's read_proc() function is going to be used by trace-cmd stat, we don't want it to make the program die in case something went wrong. Therefore, this simple patch makes read_proc() to just return -1 in case the proc file was empty or read() failed with an error, instead of using

[PATCH v3 2/3] trace-cmd: Remove the die() call from read_proc()

As trace-stack.c's read_proc() function is going to be used by trace-cmd stat, we don't want it to make the program die in case something went wrong. Therefore, this simple patch makes read_proc() to just return -1 in case the proc file was empty or read() failed with an error, instead of using

[PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

If we execute 'perf stat --per-thread' with non-root account (even set kernel.perf_event_paranoid = -1 yet), it reports the error: jinyao@skl:~$ perf stat --per-thread Error: You may not have permission to collect system-wide stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid, which

[PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

If we execute 'perf stat --per-thread' with non-root account (even set kernel.perf_event_paranoid = -1 yet), it reports the error: jinyao@skl:~$ perf stat --per-thread Error: You may not have permission to collect system-wide stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid, which

[PATCH v3 0/3] Integrate stack tracer status in 'stat'

This short patch series makes trace-cmd stat aware of the stack tracer: now, when the stack tracker is ON, the command will report that. Vladislav Valtchev (VMware) (3): trace-cmd: Make read_proc() to return int status via OUT arg trace-cmd: Remove the die() call from read_proc() trace-cmd:

[PATCH v3 0/3] Integrate stack tracer status in 'stat'

This short patch series makes trace-cmd stat aware of the stack tracer: now, when the stack tracker is ON, the command will report that. Vladislav Valtchev (VMware) (3): trace-cmd: Make read_proc() to return int status via OUT arg trace-cmd: Remove the die() call from read_proc() trace-cmd:

[PATCH v3 3/3] trace-cmd: Making stat to report when the stack tracer is ON

trace-cmd stat is a handy way for users to see what tracing is currently going on, but currently it does not say anything about the stack tracing. This patch makes the command to show a message when the stack tracer is ON. Signed-off-by: Vladislav Valtchev (VMware)

[PATCH v3 3/3] trace-cmd: Making stat to report when the stack tracer is ON

trace-cmd stat is a handy way for users to see what tracing is currently going on, but currently it does not say anything about the stack tracing. This patch makes the command to show a message when the stack tracer is ON. Signed-off-by: Vladislav Valtchev (VMware) --- trace-cmd.h | 2 ++

Re: [PATCH] mm: memory: fixed a coding style issue

On Mon 15-01-18 19:17:12, Robert Donald Rickett wrote: > This is a patch to the memory.c file that fixes the > "ERROR: code indent should use tabs where possible" > found by the checkpatch.pl tool. Is this really worth it? The code is not any better readable and it just adds a churn to the

Re: [PATCH] mm: memory: fixed a coding style issue

On Mon 15-01-18 19:17:12, Robert Donald Rickett wrote: > This is a patch to the memory.c file that fixes the > "ERROR: code indent should use tabs where possible" > found by the checkpatch.pl tool. Is this really worth it? The code is not any better readable and it just adds a churn to the

[PATCH] mtd: onenand: omap2: print resource using %pR format string

The omap2 onenand driver is now available for compile-testing, which uncovers a warning in configurations that have a 64-bit resource_size_t: drivers/mtd/onenand/omap2.c: In function 'omap2_onenand_probe': drivers/mtd/onenand/omap2.c:536:54: error: format '%x' expects argument of type 'unsigned

[PATCH] mtd: onenand: omap2: print resource using %pR format string

The omap2 onenand driver is now available for compile-testing, which uncovers a warning in configurations that have a 64-bit resource_size_t: drivers/mtd/onenand/omap2.c: In function 'omap2_onenand_probe': drivers/mtd/onenand/omap2.c:536:54: error: format '%x' expects argument of type 'unsigned

Re: [PATCH 4.14 053/118] Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""

Le 16/01/2018 à 07:33, Steffen Klassert a écrit : > On Mon, Jan 15, 2018 at 11:56:12AM -0500, David Miller wrote: >> From: Steffen Klassert >> Date: Mon, 15 Jan 2018 14:23:29 +0100 >> >>> On Mon, Jan 15, 2018 at 01:34:40PM +0100, Greg Kroah-Hartman wrote:

Re: [PATCH 4.14 053/118] Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""

Le 16/01/2018 à 07:33, Steffen Klassert a écrit : > On Mon, Jan 15, 2018 at 11:56:12AM -0500, David Miller wrote: >> From: Steffen Klassert >> Date: Mon, 15 Jan 2018 14:23:29 +0100 >> >>> On Mon, Jan 15, 2018 at 01:34:40PM +0100, Greg Kroah-Hartman wrote: 4.14-stable review patch. If anyone

Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

On Thu, Jan 4, 2018 at 12:31 AM, Cong Wang wrote: > On Wed, Jan 3, 2018 at 12:55 PM, Ozgur wrote: >> >> >> 03.01.2018, 21:57, "Cong Wang" : >>> On Tue, Jan 2, 2018 at 3:58 PM, syzbot >>>

Re: KASAN: slab-out-of-bounds Write in tcp_v6_syn_recv_sock

On Thu, Jan 4, 2018 at 12:31 AM, Cong Wang wrote: > On Wed, Jan 3, 2018 at 12:55 PM, Ozgur wrote: >> >> >> 03.01.2018, 21:57, "Cong Wang" : >>> On Tue, Jan 2, 2018 at 3:58 PM, syzbot >>> wrote: Hello, syzkaller hit the following crash on

R: Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

- Eric Wheeler ha scritto: > On Sat, 13 Jan 2018, Paolo Bonzini wrote: > > > Just add the new MSR at the end of the array. > > I'm assuming you meant emulated_msrs[], correct? No, msrs_to_save. It's just above emulated_msrs. Paolo > > > -- > Eric Wheeler > >

R: Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

- Eric Wheeler ha scritto: > On Sat, 13 Jan 2018, Paolo Bonzini wrote: > > > Just add the new MSR at the end of the array. > > I'm assuming you meant emulated_msrs[], correct? No, msrs_to_save. It's just above emulated_msrs. Paolo > > > -- > Eric Wheeler > > > > > > > Paolo > >

Re: [PATCH 04/14] mmc: mmci: Add STM32 variant

On Mon, Jan 15, 2018 at 6:17 PM, Patrice CHOTARD wrote: >>> + { >>> + .id = 0x00880180, >>> + .mask = 0x00ff, >>> + .data = _stm32, >>> + }, >> >> Since ux500 was 480180 I wonder what variants 5,6,7 are...

Re: [PATCH 04/14] mmc: mmci: Add STM32 variant

On Mon, Jan 15, 2018 at 6:17 PM, Patrice CHOTARD wrote: >>> + { >>> + .id = 0x00880180, >>> + .mask = 0x00ff, >>> + .data = _stm32, >>> + }, >> >> Since ux500 was 480180 I wonder what variants 5,6,7 are... > > What is the rule to

Re: [PATCH] soc: xilinx: xlnx_vcu: Depends on HAS_IOMEM for xlnx_vcu

On 16.1.2018 07:34, Dhaval Shah wrote: > xlnx_vcu driver uses devm_ioremap_nocache, which is included > only when HAS_IOMEM is enabled. > > drivers/soc/xilinx/xlnx_vcu.o: In function `xvcu_probe': >xlnx_vcu.c:(.text+0x116): undefined reference to `devm_ioremap_nocache' >

Re: [PATCH] soc: xilinx: xlnx_vcu: Depends on HAS_IOMEM for xlnx_vcu

On 16.1.2018 07:34, Dhaval Shah wrote: > xlnx_vcu driver uses devm_ioremap_nocache, which is included > only when HAS_IOMEM is enabled. > > drivers/soc/xilinx/xlnx_vcu.o: In function `xvcu_probe': >xlnx_vcu.c:(.text+0x116): undefined reference to `devm_ioremap_nocache' >

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

Am 16.01.2018 um 06:55 schrieb Greg Kroah-Hartman: On Tue, Jan 16, 2018 at 04:50:39AM +0100, Sebastian Gottschall wrote: please revert that on 4.9 and 4.14 it breaks igmp routing. it can be reproduced with any iptv connection using igmp-proxy. reverting this patch fixes the issue. So Linus's

Re: [PATCH 4.9 27/75] net: igmp: Use correct source address on IGMPv3 reports

Am 16.01.2018 um 06:55 schrieb Greg Kroah-Hartman: On Tue, Jan 16, 2018 at 04:50:39AM +0100, Sebastian Gottschall wrote: please revert that on 4.9 and 4.14 it breaks igmp routing. it can be reproduced with any iptv connection using igmp-proxy. reverting this patch fixes the issue. So Linus's

[PATCH] powerpc/8xx: do not select CONFIG_PPC_LIB_RHEAP

Since commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE muram"), rheap is not used anymore. Signed-off-by: Christophe Leroy --- arch/powerpc/platforms/Kconfig.cputype | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/platforms/Kconfig.cputype

[PATCH] powerpc/8xx: do not select CONFIG_PPC_LIB_RHEAP

Since commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE muram"), rheap is not used anymore. Signed-off-by: Christophe Leroy --- arch/powerpc/platforms/Kconfig.cputype | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/platforms/Kconfig.cputype

Re: [PATCH] ARM: dts: nomadik: add interrupt-parent for clcd

On Mon, Jan 15, 2018 at 5:37 PM, Arnd Bergmann wrote: > The clcd device is lacking an interrupt-parent property, which makes > the interrupt unusable and shows up as a warning with the latest > dtc version: > > arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning

Re: [PATCH] ARM: dts: nomadik: add interrupt-parent for clcd

On Mon, Jan 15, 2018 at 5:37 PM, Arnd Bergmann wrote: > The clcd device is lacking an interrupt-parent property, which makes > the interrupt unusable and shows up as a warning with the latest > dtc version: > > arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning (interrupts_property): > Missing

[patch v17 1/4] drivers: jtag: Add JTAG core driver

Initial patch for JTAG driver JTAG class driver provide infrastructure to support hardware/software JTAG platform drivers. It provide user layer API interface for flashing and debugging external devices which equipped with JTAG interface using standard transactions. Driver exposes set of IOCTL to

[patch v17 1/4] drivers: jtag: Add JTAG core driver

Initial patch for JTAG driver JTAG class driver provide infrastructure to support hardware/software JTAG platform drivers. It provide user layer API interface for flashing and debugging external devices which equipped with JTAG interface using standard transactions. Driver exposes set of IOCTL to

[patch v17 4/4] Documentation: jtag: Add ABI documentation

Added document that describe the ABI for JTAG class drivrer Signed-off-by: Oleksandr Shamray Acked-by: Arnd Bergmann --- v16->v17 v15->v16 v14->v15 v13->v14 v12->v13 v11->v12 Tobias Klauser - rename

[patch v17 4/4] Documentation: jtag: Add ABI documentation

Added document that describe the ABI for JTAG class drivrer Signed-off-by: Oleksandr Shamray Acked-by: Arnd Bergmann --- v16->v17 v15->v16 v14->v15 v13->v14 v12->v13 v11->v12 Tobias Klauser - rename /Documentation/ABI/testing/jatg-dev -> jtag-dev - Typo: s/interfase/interface v10->v11 v9->v10

[patch v17 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller. Driver implements the following jtag ops: - freq_get; - freq_set; - status_get; - idle; - xfer; It has been tested on Mellanox system with BMC equipped with Aspeed 2520 SoC for programming CPLD devices. Signed-off-by:

[patch v17 3/4] Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver

It has been tested on Mellanox system with BMC equipped with Aspeed 2520 SoC for programming CPLD devices. Signed-off-by: Oleksandr Shamray Signed-off-by: Jiri Pirko Acked-by: Rob Herring --- v16->v17 v15->v16 Comments pointed by

[patch v17 0/4] JTAG driver introduction

When a need raise up to use JTAG interface for system's devices programming or CPU debugging, usually the user layer application implements jtag protocol by bit-bang or using a proprietary connection to vendor hardware. This method can be slow and not generic. We propose to implement general

Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression

NAK. Calling a discard and expecting zeroing is simply buggy. And double NAK for patches like this without a linux-block Cc.

[patch v17 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver

Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller. Driver implements the following jtag ops: - freq_get; - freq_set; - status_get; - idle; - xfer; It has been tested on Mellanox system with BMC equipped with Aspeed 2520 SoC for programming CPLD devices. Signed-off-by:

[patch v17 3/4] Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver

It has been tested on Mellanox system with BMC equipped with Aspeed 2520 SoC for programming CPLD devices. Signed-off-by: Oleksandr Shamray Signed-off-by: Jiri Pirko Acked-by: Rob Herring --- v16->v17 v15->v16 Comments pointed by Joel Stanley - change clocks = <_apb> to proper clocks = <

[patch v17 0/4] JTAG driver introduction

When a need raise up to use JTAG interface for system's devices programming or CPU debugging, usually the user layer application implements jtag protocol by bit-bang or using a proprietary connection to vendor hardware. This method can be slow and not generic. We propose to implement general

Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression

NAK. Calling a discard and expecting zeroing is simply buggy. And double NAK for patches like this without a linux-block Cc.

Re: [PATCH] x86/jailhouse: fix building without X86_X2APIC

On Tue, Jan 16, 2018 at 3:34 AM, Dou Liyang wrote: > At 01/16/2018 09:25 AM, Dou Liyang wrote: >>> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h >>> index 98722773391d..0317d635d9ba 100644 >>> --- a/arch/x86/include/asm/apic.h >>> +++

Re: [PATCH] x86/jailhouse: fix building without X86_X2APIC

On Tue, Jan 16, 2018 at 3:34 AM, Dou Liyang wrote: > At 01/16/2018 09:25 AM, Dou Liyang wrote: >>> diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h >>> index 98722773391d..0317d635d9ba 100644 >>> --- a/arch/x86/include/asm/apic.h >>> +++ b/arch/x86/include/asm/apic.h >>> @@

Re: Query: Crash is coming during /prod/PID/stat and do_exit of same task

On Tue, Jan 16, 2018 at 11:06:47AM +0530, Kohli, Gaurav wrote: > On 1/10/2018 10:50 AM, Alexey Dobriyan wrote: > > >> We are seeing crash in do_task_stat while accessing stack pointer, It > >> seems same task has already completed do_exit call. > >> So it seems a race between them: > > Please,

Re: Query: Crash is coming during /prod/PID/stat and do_exit of same task

On Tue, Jan 16, 2018 at 11:06:47AM +0530, Kohli, Gaurav wrote: > On 1/10/2018 10:50 AM, Alexey Dobriyan wrote: > > >> We are seeing crash in do_task_stat while accessing stack pointer, It > >> seems same task has already completed do_exit call. > >> So it seems a race between them: > > Please,

Re: LKML admins (syzbot emails are not delivered)

On Mon, Jan 15, 2018 at 10:38:42AM -0600, Eric W. Biederman wrote: > > Sometimes the branches on linux-next are experimental crap. If someone > adds an experimental memory allocator to linux-next before discovering > it causes all kinds of problems I don't want bug reports about my code > not

Re: LKML admins (syzbot emails are not delivered)

On Mon, Jan 15, 2018 at 10:38:42AM -0600, Eric W. Biederman wrote: > > Sometimes the branches on linux-next are experimental crap. If someone > adds an experimental memory allocator to linux-next before discovering > it causes all kinds of problems I don't want bug reports about my code > not

Re: [BUG 4.15-rc7] IRQ matrix management errors

This is all way over my head, but the part that obviously shows something's gone wrong: kworker/u674:3-1421 [028] d... 335.307051: irq_matrix_reserve_managed: bit=56 cpu=0 online=1 avl=86 alloc=116 managed=3 online_maps=112 global_avl=22084, global_rsvd=157, total_alloc=570

Re: [BUG 4.15-rc7] IRQ matrix management errors

This is all way over my head, but the part that obviously shows something's gone wrong: kworker/u674:3-1421 [028] d... 335.307051: irq_matrix_reserve_managed: bit=56 cpu=0 online=1 avl=86 alloc=116 managed=3 online_maps=112 global_avl=22084, global_rsvd=157, total_alloc=570

RE: [patch v16 1/4] drivers: jtag: Add JTAG core driver

Hi Julia > -Original Message- > From: Julia Cartwright [mailto:jul...@eso.teric.us] > Sent: 15 января 2018 г. 22:52 > To: Oleksandr Shamray > Cc: gre...@linuxfoundation.org; a...@arndb.de; linux- > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >

RE: [patch v16 1/4] drivers: jtag: Add JTAG core driver

Hi Julia > -Original Message- > From: Julia Cartwright [mailto:jul...@eso.teric.us] > Sent: 15 января 2018 г. 22:52 > To: Oleksandr Shamray > Cc: gre...@linuxfoundation.org; a...@arndb.de; linux- > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; >

Re: [PATCH] Remove structure passing and assignment to save stack and no coping structures.

Hi Karim, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15-rc8 next-20180115] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH] Remove structure passing and assignment to save stack and no coping structures.

Hi Karim, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.15-rc8 next-20180115] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

On 01/10/2018 02:02 AM, Brian Norris wrote: This takes care of 2 TODOs in this driver, by using the common DSI packet-marshalling code instead of our custom short/long write code. This both saves us some duplicated code and gets us free support for command types that weren't already part of

Re: [PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

On 01/10/2018 02:02 AM, Brian Norris wrote: This takes care of 2 TODOs in this driver, by using the common DSI packet-marshalling code instead of our custom short/long write code. This both saves us some duplicated code and gets us free support for command types that weren't already part of

Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()

On 01/10/2018 08:03 PM, Andrzej Hajda wrote: On 09.01.2018 21:32, Brian Norris wrote: We're filling the "remainder" word with little-endian data, then writing it out to IO registers with endian-correcting writel(). That probably won't work on big-endian systems. Let's mark the "remainder"

Re: [PATCH v2 2/2] drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()

On 01/10/2018 08:03 PM, Andrzej Hajda wrote: On 09.01.2018 21:32, Brian Norris wrote: We're filling the "remainder" word with little-endian data, then writing it out to IO registers with endian-correcting writel(). That probably won't work on big-endian systems. Let's mark the "remainder"

Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver

On 16/01/18 03:11, Tony Lindgren wrote: We can support the RSTCTRL reset registers on many TI SoCs with reset-simple. Cc: Dave Gerlach Cc: Mark Rutland Cc: Nishant Menon Cc: Philipp Zabel Cc: Rob Herring

Re: [PATCH] reset: ti-rstctrl: use the reset-simple driver

On 16/01/18 03:11, Tony Lindgren wrote: We can support the RSTCTRL reset registers on many TI SoCs with reset-simple. Cc: Dave Gerlach Cc: Mark Rutland Cc: Nishant Menon Cc: Philipp Zabel Cc: Rob Herring Cc: Suman Anna Cc: Tero Kristo Signed-off-by: Tony Lindgren --- That's all there

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On Saturday 13 January 2018 06:41 AM, David Lechner wrote: > On 01/12/2018 10:18 AM, Sekhar Nori wrote: >> On Friday 12 January 2018 08:55 PM, David Lechner wrote: PLL output on DA850 must never be below 300MHz or above 600MHz (see datasheet table "Allowed PLL Operating

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On Saturday 13 January 2018 06:41 AM, David Lechner wrote: > On 01/12/2018 10:18 AM, Sekhar Nori wrote: >> On Friday 12 January 2018 08:55 PM, David Lechner wrote: PLL output on DA850 must never be below 300MHz or above 600MHz (see datasheet table "Allowed PLL Operating

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi Roger, On 1/15/2018 9:10 PM, Roger Quadros wrote: > Hi Manu, [snip] >> I think it will be better to separate runtime_suspend and pm_suspend >> handling for >> host mode in dwc3. Powering offf/on PHYs and dwc3_core_exit/init across >> system >> suspend-resume should be ok but doing that for

Re: [RESEND PATCH 1/3] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

Hi Roger, On 1/15/2018 9:10 PM, Roger Quadros wrote: > Hi Manu, [snip] >> I think it will be better to separate runtime_suspend and pm_suspend >> handling for >> host mode in dwc3. Powering offf/on PHYs and dwc3_core_exit/init across >> system >> suspend-resume should be ok but doing that for

[PATCH] soc: xilinx: xlnx_vcu: Depends on HAS_IOMEM for xlnx_vcu

xlnx_vcu driver uses devm_ioremap_nocache, which is included only when HAS_IOMEM is enabled. drivers/soc/xilinx/xlnx_vcu.o: In function `xvcu_probe': xlnx_vcu.c:(.text+0x116): undefined reference to `devm_ioremap_nocache' xlnx_vcu.c:(.text+0x1ae): undefined reference to

[PATCH] soc: xilinx: xlnx_vcu: Depends on HAS_IOMEM for xlnx_vcu

xlnx_vcu driver uses devm_ioremap_nocache, which is included only when HAS_IOMEM is enabled. drivers/soc/xilinx/xlnx_vcu.o: In function `xvcu_probe': xlnx_vcu.c:(.text+0x116): undefined reference to `devm_ioremap_nocache' xlnx_vcu.c:(.text+0x1ae): undefined reference to

Re: [PATCH 4.14 053/118] Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""

On Mon, Jan 15, 2018 at 11:56:12AM -0500, David Miller wrote: > From: Steffen Klassert > Date: Mon, 15 Jan 2018 14:23:29 +0100 > > > On Mon, Jan 15, 2018 at 01:34:40PM +0100, Greg Kroah-Hartman wrote: > >> 4.14-stable review patch. If anyone has any objections,

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On Saturday 13 January 2018 07:43 AM, David Lechner wrote: > On 01/12/2018 03:21 AM, Sekhar Nori wrote: >> On Monday 08 January 2018 07:47 AM, David Lechner wrote: >>> +static unsigned long davinci_pll_clk_recalc(struct clk_hw *hw, >>> +    unsigned long parent_rate) >>> +{ >>>

Re: [PATCH 4.14 053/118] Revert "Revert "xfrm: Fix stack-out-of-bounds read in xfrm_state_find.""

On Mon, Jan 15, 2018 at 11:56:12AM -0500, David Miller wrote: > From: Steffen Klassert > Date: Mon, 15 Jan 2018 14:23:29 +0100 > > > On Mon, Jan 15, 2018 at 01:34:40PM +0100, Greg Kroah-Hartman wrote: > >> 4.14-stable review patch. If anyone has any objections, please let me > >> know. > >> >

Re: [PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

On Saturday 13 January 2018 07:43 AM, David Lechner wrote: > On 01/12/2018 03:21 AM, Sekhar Nori wrote: >> On Monday 08 January 2018 07:47 AM, David Lechner wrote: >>> +static unsigned long davinci_pll_clk_recalc(struct clk_hw *hw, >>> +    unsigned long parent_rate) >>> +{ >>>

Re: [PATCH] EDAC, mv64x60: Remove some code duplication

Le 15/01/2018 à 23:31, Michael Ellerman a écrit : Chris Packham writes: On 14/01/18 06:17, Christophe JAILLET wrote: Le 13/01/2018 à 15:22, Borislav Petkov a écrit : + Chris Packham who's been fixing some stuff in here too. On Sat, Jan 13, 2018 at

Re: [PATCH] EDAC, mv64x60: Remove some code duplication

Le 15/01/2018 à 23:31, Michael Ellerman a écrit : Chris Packham writes: On 14/01/18 06:17, Christophe JAILLET wrote: Le 13/01/2018 à 15:22, Borislav Petkov a écrit : + Chris Packham who's been fixing some stuff in here too. On Sat, Jan 13, 2018 at 08:28:21AM +0100, Christophe JAILLET wrote:

Re: [RFC PATCH] ubifs: Add zstd support

On 2018/1/12 18:45, Richard Weinberger wrote: Yufen Yu, Am Freitag, 12. Januar 2018, 10:24:21 CET schrieb Yufen Yu: Add zstd compression and decompression support to ubifs. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression,

Re: [RFC PATCH] ubifs: Add zstd support

On 2018/1/12 18:45, Richard Weinberger wrote: Yufen Yu, Am Freitag, 12. Januar 2018, 10:24:21 CET schrieb Yufen Yu: Add zstd compression and decompression support to ubifs. zstd at its fastest level compresses almost as well as zlib, while offering much faster compression and decompression,

Re: [PATCH net-next v5 2/4] phy: cp110-comphy: 2.5G SGMII mode

On Friday 12 January 2018 01:21 PM, Antoine Tenart wrote: > This patch allow the CP100 comphy to configure some lanes in the > 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the > same code path. > > Signed-off-by: Antoine Tenart

Re: [PATCH net-next v5 2/4] phy: cp110-comphy: 2.5G SGMII mode

On Friday 12 January 2018 01:21 PM, Antoine Tenart wrote: > This patch allow the CP100 comphy to configure some lanes in the > 2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the > same code path. > > Signed-off-by: Antoine Tenart Acked-by: Kishon Vijay Abraham I > --- >

Re: [PATCH net-next v5 1/4] phy: add 2.5G SGMII mode to the phy_mode enum

On Tuesday 16 January 2018 12:51 AM, David Miller wrote: > From: Antoine Tenart > Date: Fri, 12 Jan 2018 08:51:27 +0100 > >> This patch adds one more generic PHY mode to the phy_mode enum, to allow >> configuring generic PHYs to the 2.5G SGMII mode by using

Re: [PATCH net-next v5 1/4] phy: add 2.5G SGMII mode to the phy_mode enum

On Tuesday 16 January 2018 12:51 AM, David Miller wrote: > From: Antoine Tenart > Date: Fri, 12 Jan 2018 08:51:27 +0100 > >> This patch adds one more generic PHY mode to the phy_mode enum, to allow >> configuring generic PHYs to the 2.5G SGMII mode by using the set_mode >> callback. >> >>

Re: [PATCH] fw_cfg: don't use DMA mapping for fw_cfg device

On Mon, Jan 15, 2018 at 12:22:48PM +0100, Marc-Andre Lureau wrote: > Hi > > On Mon, Jan 15, 2018 at 9:55 AM, Peter Xu wrote: > > fw_cfg device does not need IOMMU protection, so use physical addresses > > always. That's how QEMU implements fw_cfg. Otherwise we'll see call >

Re: [PATCH] fw_cfg: don't use DMA mapping for fw_cfg device

On Mon, Jan 15, 2018 at 12:22:48PM +0100, Marc-Andre Lureau wrote: > Hi > > On Mon, Jan 15, 2018 at 9:55 AM, Peter Xu wrote: > > fw_cfg device does not need IOMMU protection, so use physical addresses > > always. That's how QEMU implements fw_cfg. Otherwise we'll see call > > traces during

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

Hi, On (01/15/18 12:50), Petr Mladek wrote: > On Mon 2018-01-15 11:17:43, Petr Mladek wrote: > > PS: Sergey, you have many good points. The printk-stuff is very > > complex and we could spend years discussing the perfect solution. > > BTW: One solution that comes to my mind is based on ideas >

[PATCH] selftests: Fix loss of test output in run_kselftests.sh

Commit fbcab13d2e25 ("selftests: silence test output by default") changed the run_tests logic as well as the logic to generate run_kselftests.sh to redirect test output away from the console. As discussed on the list and at kernel summit, this is not a desirable default as it means in order to

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

Hi, On (01/15/18 12:50), Petr Mladek wrote: > On Mon 2018-01-15 11:17:43, Petr Mladek wrote: > > PS: Sergey, you have many good points. The printk-stuff is very > > complex and we could spend years discussing the perfect solution. > > BTW: One solution that comes to my mind is based on ideas >

[PATCH] selftests: Fix loss of test output in run_kselftests.sh

Commit fbcab13d2e25 ("selftests: silence test output by default") changed the run_tests logic as well as the logic to generate run_kselftests.sh to redirect test output away from the console. As discussed on the list and at kernel summit, this is not a desirable default as it means in order to

Re: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting

Hi Max Thanks for your kindly comment. On 01/15/2018 09:36 PM, Max Gurtovoy wrote:   case NVME_CTRL_RECONNECTING:   switch (old_state) {   case NVME_CTRL_LIVE:   case NVME_CTRL_RESETTING: +    case NVME_CTRL_RESET_PREPARE: > > I forget to

Re: [Suspected-Phishing]Re: [PATCH V3 1/2] nvme: split resetting state into reset_prepate and resetting

Hi Max Thanks for your kindly comment. On 01/15/2018 09:36 PM, Max Gurtovoy wrote:   case NVME_CTRL_RECONNECTING:   switch (old_state) {   case NVME_CTRL_LIVE:   case NVME_CTRL_RESETTING: +    case NVME_CTRL_RESET_PREPARE: > > I forget to

  1   2   3   4   5   6   7   8   9   10   >