[PATCH 01/10] ASoC: au1x: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/au1x/dbdma2.c | 2 +- sound/soc/au1x/dma.c| 2 +-

[PATCH 01/10] ASoC: au1x: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/au1x/dbdma2.c | 2 +- sound/soc/au1x/dma.c| 2 +- 2 files changed, 2

[PATCH 04/10] ASoC: intel: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/intel/baytrail/sst-baytrail-pcm.c | 2 +- 1 file

[PATCH 05/10] ASoC: nuc900: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/nuc900/nuc900-pcm.c | 2 +- 1 file changed, 1

[PATCH 04/10] ASoC: intel: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/intel/baytrail/sst-baytrail-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 05/10] ASoC: nuc900: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/nuc900/nuc900-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 06/10] ASoC: omap: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/omap/omap-pcm.c | 2 +- 1 file changed, 1

[PATCH 06/10] ASoC: omap: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/omap/omap-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 02/10] ASoC: blackfin: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/blackfin/bf5xx-ac97-pcm.c | 2 +-

[PATCH 02/10] ASoC: blackfin: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/blackfin/bf5xx-ac97-pcm.c | 2 +- sound/soc/blackfin/bf5xx-i2s-pcm.c | 2 +- 2

[PATCH 03/10] ASoC: fsl: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/fsl/fsl_dma.c | 2 +- sound/soc/fsl/imx-pcm-fiq.c

[PATCH 08/10] ASoC: samsung: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/samsung/idma.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH 09/10] ASoC: sh: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/sh/dma-sh7760.c | 2 +- sound/soc/sh/fsi.c| 2

[PATCH 10/10] ASoC: txx9: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/txx9/txx9aclc.c | 2 +- 1 file changed, 1

[PATCH 03/10] ASoC: fsl: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/fsl/fsl_dma.c | 2 +- sound/soc/fsl/imx-pcm-fiq.c | 2 +-

[PATCH 08/10] ASoC: samsung: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/samsung/idma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 09/10] ASoC: sh: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/sh/dma-sh7760.c | 2 +- sound/soc/sh/fsi.c| 2 +-

[PATCH 10/10] ASoC: txx9: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/txx9/txx9aclc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 07/10] ASoC: pxa: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/pxa/mmp-pcm.c| 2 +- sound/soc/pxa/pxa2xx-pcm.c |

[PATCH 00/10] constify ASoC snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Arvind Yadav (10): [PATCH 01/10] ASoC: au1x: constify snd_pcm_ops structures [PATCH 02/10] ASoC: blackfin: constify

[PATCH 07/10] ASoC: pxa: constify snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- sound/soc/pxa/mmp-pcm.c| 2 +- sound/soc/pxa/pxa2xx-pcm.c | 2 +- 2 files changed, 2

[PATCH 00/10] constify ASoC snd_pcm_ops structures

snd_pcm_ops are not supposed to change at runtime. All functions working with snd_pcm_ops provided by work with const snd_pcm_ops. So mark the non-const structs as const. Arvind Yadav (10): [PATCH 01/10] ASoC: au1x: constify snd_pcm_ops structures [PATCH 02/10] ASoC: blackfin: constify

Re: [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst wrote: > On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote: >> /* Normal 64-bit system call target */ >> ENTRY(xen_syscall_target) >> - undo_xen_syscall >> - jmp entry_SYSCALL_64_after_swapgs >> +

Re: [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On Sun, Aug 13, 2017 at 7:44 PM, Brian Gerst wrote: > On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote: >> /* Normal 64-bit system call target */ >> ENTRY(xen_syscall_target) >> - undo_xen_syscall >> - jmp entry_SYSCALL_64_after_swapgs >> + popq %rcx >> + popq

[PATCH] misc: mic: constify virtio_config_ops structure

This virtio_config_ops structure is only stored in the config field of a virtio_device structure and this field is const, so the virtio_config_ops structure can also be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall ---

[PATCH] misc: mic: constify virtio_config_ops structure

This virtio_config_ops structure is only stored in the config field of a virtio_device structure and this field is const, so the virtio_config_ops structure can also be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall --- drivers/misc/mic/vop/vop_main.c |2 +- 1 file

Re: [PATCH 2/9] Implement containers as kernel objects

On 2017-05-22 17:22, David Howells wrote: > A container is then a kernel object that contains the following things: > > (1) Namespaces. > > (2) A root directory. > > (3) A set of processes, including one designated as the 'init' process. > > A container is created and attached to a file

Re: [PATCH 2/9] Implement containers as kernel objects

On 2017-05-22 17:22, David Howells wrote: > A container is then a kernel object that contains the following things: > > (1) Namespaces. > > (2) A root directory. > > (3) A set of processes, including one designated as the 'init' process. > > A container is created and attached to a file

Re: [PATCH 3/3] IPI: Avoid to use 2 cache lines for one call_single_data

Hi, Peter, "Huang, Ying" writes: > Peter Zijlstra writes: > >> On Sat, Aug 05, 2017 at 08:47:02AM +0800, Huang, Ying wrote: >>> Yes. That looks good. So you will prepare the final patch? Or you >>> hope me to do that? >> >> I was hoping you'd do

Re: [PATCH 3/3] IPI: Avoid to use 2 cache lines for one call_single_data

Hi, Peter, "Huang, Ying" writes: > Peter Zijlstra writes: > >> On Sat, Aug 05, 2017 at 08:47:02AM +0800, Huang, Ying wrote: >>> Yes. That looks good. So you will prepare the final patch? Or you >>> hope me to do that? >> >> I was hoping you'd do it ;-) > > Thanks! Here is the updated patch

Re: [PATCH] soc: imx: gpcv2: fix regulator deferred probe

On Sun, Aug 13, 2017 at 10:12:13PM -0700, Stefan Agner wrote: > Hi Shawn, > > On 2017-08-04 20:13, Shawn Guo wrote: > > On Wed, Aug 02, 2017 at 12:51:29PM -0700, Stefan Agner wrote: > >> If a regulator requests a deferred probe, the power domain gets > >> initialized twice. This leads to a list

Re: [PATCH] soc: imx: gpcv2: fix regulator deferred probe

On Sun, Aug 13, 2017 at 10:12:13PM -0700, Stefan Agner wrote: > Hi Shawn, > > On 2017-08-04 20:13, Shawn Guo wrote: > > On Wed, Aug 02, 2017 at 12:51:29PM -0700, Stefan Agner wrote: > >> If a regulator requests a deferred probe, the power domain gets > >> initialized twice. This leads to a list

[PATCH] swap: choose swap device according to numa node

If the system has more than one swap device and swap device has the node information, we can make use of this information to decide which swap device to use in get_swap_pages() to get better performance. The current code uses a priority based list, swap_avail_list, to decide which swap device to

[PATCH] swap: choose swap device according to numa node

If the system has more than one swap device and swap device has the node information, we can make use of this information to decide which swap device to use in get_swap_pages() to get better performance. The current code uses a priority based list, swap_avail_list, to decide which swap device to

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On Mon, Aug 14, 2017 at 05:07:19AM +, Nadav Amit wrote: < snip > > Minchan, as for the solution you proposed, it seems to open again a race, > since the “pending” indication is removed before the actual TLB flush is > performed. Oops, you're right!

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On Mon, Aug 14, 2017 at 05:07:19AM +, Nadav Amit wrote: < snip > > Minchan, as for the solution you proposed, it seems to open again a race, > since the “pending” indication is removed before the actual TLB flush is > performed. Oops, you're right!

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

Vivek, On 8/11/2017 12:42 PM, Vivek Gautam wrote: On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen wrote: Vivek, Can you kindly review this patch series (for UFS controller changes) and consider giving your Ack so that Kishon can pull in the series through

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

Vivek, On 8/11/2017 12:42 PM, Vivek Gautam wrote: On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen wrote: Vivek, Can you kindly review this patch series (for UFS controller changes) and consider giving your Ack so that Kishon can pull in the series through phy tree. SCSI piece looks

Re: [PATCH] soc: imx: gpcv2: fix regulator deferred probe

Hi Shawn, On 2017-08-04 20:13, Shawn Guo wrote: > On Wed, Aug 02, 2017 at 12:51:29PM -0700, Stefan Agner wrote: >> If a regulator requests a deferred probe, the power domain gets >> initialized twice. This leads to a list double add (without >> list debugging the kernel hangs due to the double

Re: [PATCH] soc: imx: gpcv2: fix regulator deferred probe

Hi Shawn, On 2017-08-04 20:13, Shawn Guo wrote: > On Wed, Aug 02, 2017 at 12:51:29PM -0700, Stefan Agner wrote: >> If a regulator requests a deferred probe, the power domain gets >> initialized twice. This leads to a list double add (without >> list debugging the kernel hangs due to the double

Re: linux-next: manual merge of the akpm-current tree with the tip tree

Minchan Kim wrote: > On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote: >> On Sun, Aug 13, 2017 at 06:06:32AM +, Nadav Amit wrote: however mm_tlb_flush_nested() is a mystery, it appears to care about anything inside the range. For now rely on it

Re: linux-next: manual merge of the akpm-current tree with the tip tree

Minchan Kim wrote: > On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote: >> On Sun, Aug 13, 2017 at 06:06:32AM +, Nadav Amit wrote: however mm_tlb_flush_nested() is a mystery, it appears to care about anything inside the range. For now rely on it doing at least _a_ PTL

Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500

Florian, On Thu, Jun 29, 2017 at 5:04 PM, Vivek Unune wrote: > Florian, > >>> I have managed to use DSA driver and was able detect both internal and >>> external switches. However, I only get packets flowing only through the >>> internal switch. I have used the ip &

Re: [PATCH] ARM: dts: BCM5301X: Add support for Linksys EA9500

Florian, On Thu, Jun 29, 2017 at 5:04 PM, Vivek Unune wrote: > Florian, > >>> I have managed to use DSA driver and was able detect both internal and >>> external switches. However, I only get packets flowing only through the >>> internal switch. I have used the ip & bridge commands to setup the

Re: [v3 1/2] sched/clock: interface to allow timestamps early in boot

Hi Pavel, At 08/12/2017 02:50 AM, Pavel Tatashin wrote: In Linux printk() can output timestamps next to every line. This is very useful for tracking regressions, and finding places that can be optimized. However, the timestamps are available only later in boot. On smaller machines it is

Re: [v3 1/2] sched/clock: interface to allow timestamps early in boot

Hi Pavel, At 08/12/2017 02:50 AM, Pavel Tatashin wrote: In Linux printk() can output timestamps next to every line. This is very useful for tracking regressions, and finding places that can be optimized. However, the timestamps are available only later in boot. On smaller machines it is

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-08-11 02:36, Richard Guy Briggs wrote: > On 2017-06-28 15:03, Paul Moore wrote: > > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > > On 2017-05-30 17:21, Paul Moore wrote: > > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs > > >>

Re: [PATCH ALT4 V2 1/2] audit: show fstype:pathname for entries with anonymous parents

On 2017-08-11 02:36, Richard Guy Briggs wrote: > On 2017-06-28 15:03, Paul Moore wrote: > > On Tue, Jun 27, 2017 at 5:11 PM, Richard Guy Briggs wrote: > > > On 2017-05-30 17:21, Paul Moore wrote: > > >> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs > > >> wrote: > > > > ... > > > > >> >

Re: [PATCH net-next v2 2/3] net/ncsi: Configure VLAN tag filter

On Mon, 2017-08-14 at 11:39 +0930, Joel Stanley wrote: > On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas > wrote: > > Make use of the ndo_vlan_rx_{add,kill}_vid callbacks to have the NCSI > > stack process new VLAN tags and configure the channel VLAN filter > >

Re: [PATCH net-next v2 2/3] net/ncsi: Configure VLAN tag filter

On Mon, 2017-08-14 at 11:39 +0930, Joel Stanley wrote: > On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas > wrote: > > Make use of the ndo_vlan_rx_{add,kill}_vid callbacks to have the NCSI > > stack process new VLAN tags and configure the channel VLAN filter > > appropriately. > > Several

Re: [PATCH 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

在 2017/8/11 23:38, Philipp Zabel 写道: On Wed, 2017-08-09 at 18:00 +0800, Sandy Huang wrote: This patch add Document for Rockchip Soc RK3288 LVDS, This based on the patches from Mark yao and Heiko Stuebner. Signed-off-by: Sandy Huang Signed-off-by: Mark yao

Re: [PATCH 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

在 2017/8/11 23:38, Philipp Zabel 写道: On Wed, 2017-08-09 at 18:00 +0800, Sandy Huang wrote: This patch add Document for Rockchip Soc RK3288 LVDS, This based on the patches from Mark yao and Heiko Stuebner. Signed-off-by: Sandy Huang Signed-off-by: Mark yao Signed-off-by: Heiko Stuebner

Re: [PATCH 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

在 2017/8/11 22:44, Sean Paul 写道: On Fri, Aug 11, 2017 at 10:15:16AM +0800, Sandy Huang wrote: 在 2017/8/11 2:05, Sean Paul 写道: On Thu, Aug 10, 2017 at 05:35:52PM +0800, Sandy Huang wrote: Hi Sean Paul, Thanks for your review. 在 2017/8/10 3:58, Sean Paul 写道: On Wed, Aug 09, 2017 at

Re: [PATCH 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

在 2017/8/11 22:44, Sean Paul 写道: On Fri, Aug 11, 2017 at 10:15:16AM +0800, Sandy Huang wrote: 在 2017/8/11 2:05, Sean Paul 写道: On Thu, Aug 10, 2017 at 05:35:52PM +0800, Sandy Huang wrote: Hi Sean Paul, Thanks for your review. 在 2017/8/10 3:58, Sean Paul 写道: On Wed, Aug 09, 2017 at

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

On Sat, Aug 12, 2017 at 4:30 AM, Wolfram Sang wrote: > >> That being said, I could implement this as a custom clock subclass, which >> would probably be cleaner that what I have done. > > Shall I wait for that one or do you want this patch to be included? > I don't mind, your

Re: [PATCH v2 1/1] i2c: aspeed: add proper support fo 24xx clock params

On Sat, Aug 12, 2017 at 4:30 AM, Wolfram Sang wrote: > >> That being said, I could implement this as a custom clock subclass, which >> would probably be cleaner that what I have done. > > Shall I wait for that one or do you want this patch to be included? > I don't mind, your call here... >

Re: [PATCH v1] i2c: aspeed: fixed potential null pointer dereference

On Sat, Aug 12, 2017 at 9:02 PM, Wolfram Sang wrote: > On Fri, Jul 28, 2017 at 06:00:12PM -0700, Brendan Higgins wrote: >> Before I skipped null checks when the master is in the STOP state; this >> fixes that. >> >> Signed-off-by: Brendan Higgins >

Re: [PATCH v1] i2c: aspeed: fixed potential null pointer dereference

On Sat, Aug 12, 2017 at 9:02 PM, Wolfram Sang wrote: > On Fri, Jul 28, 2017 at 06:00:12PM -0700, Brendan Higgins wrote: >> Before I skipped null checks when the master is in the STOP state; this >> fixes that. >> >> Signed-off-by: Brendan Higgins > > Is there a suitable "Fixes:" tag for this? >

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote: > On Sun, Aug 13, 2017 at 06:06:32AM +, Nadav Amit wrote: > > > however mm_tlb_flush_nested() is a mystery, it appears to care about > > > anything inside the range. For now rely on it doing at least _a_ PTL > > > lock instead of

Re: linux-next: manual merge of the akpm-current tree with the tip tree

On Sun, Aug 13, 2017 at 02:50:19PM +0200, Peter Zijlstra wrote: > On Sun, Aug 13, 2017 at 06:06:32AM +, Nadav Amit wrote: > > > however mm_tlb_flush_nested() is a mystery, it appears to care about > > > anything inside the range. For now rely on it doing at least _a_ PTL > > > lock instead of

Re: [PATCH 04/11] serial: sunsu: constify uart_ops structures

From: Julia Lawall Date: Sun, 13 Aug 2017 08:21:43 +0200 > These uart_ops structures are only stored in the ops field of a > uart_port structure and this fields is const, so the uart_ops > structures can also be const. > > Done with the help of Coccinelle. > >

Re: [PATCH 04/11] serial: sunsu: constify uart_ops structures

From: Julia Lawall Date: Sun, 13 Aug 2017 08:21:43 +0200 > These uart_ops structures are only stored in the ops field of a > uart_port structure and this fields is const, so the uart_ops > structures can also be const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall

Re: [PATCH 03/11] serial: sunsab: constify uart_ops structures

From: Julia Lawall Date: Sun, 13 Aug 2017 08:21:42 +0200 > These uart_ops structures are only stored in the ops field of a > uart_port structure and this fields is const, so the uart_ops > structures can also be const. > > Done with the help of Coccinelle. > >

Re: [PATCH 0/4] constify net platform_device_id

From: Arvind Yadav Date: Sun, 13 Aug 2017 16:41:44 +0530 > platform_device_id are not supposed to change at runtime. All functions > working with platform_device_id provided by > work with const platform_device_id. So mark the non-const structs as const. Series

Re: [PATCH 03/11] serial: sunsab: constify uart_ops structures

From: Julia Lawall Date: Sun, 13 Aug 2017 08:21:42 +0200 > These uart_ops structures are only stored in the ops field of a > uart_port structure and this fields is const, so the uart_ops > structures can also be const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall

Re: [PATCH 0/4] constify net platform_device_id

From: Arvind Yadav Date: Sun, 13 Aug 2017 16:41:44 +0530 > platform_device_id are not supposed to change at runtime. All functions > working with platform_device_id provided by > work with const platform_device_id. So mark the non-const structs as const. Series applied, thanks.

Re: [PATCH] tap: make struct tap_fops static

From: Colin King Date: Sat, 12 Aug 2017 22:52:31 +0100 > From: Colin Ian King > > The structure tap_fops is local to the source and does not need to > be in global scope, so make it static. > > Cleans up sparse warning: > symbol 'tap_fops'

Re: [PATCH] tap: make struct tap_fops static

From: Colin King Date: Sat, 12 Aug 2017 22:52:31 +0100 > From: Colin Ian King > > The structure tap_fops is local to the source and does not need to > be in global scope, so make it static. > > Cleans up sparse warning: > symbol 'tap_fops' was not declared. Should it be static? > >

Re: [PATCH] virtio-net: make array guest_offloads static

From: Colin King Date: Sat, 12 Aug 2017 22:45:53 +0100 > From: Colin Ian King > > The array guest_offloads is local to the source and does not need to > be in global scope, so make it static. Also tweak formatting. > > Cleans up sparse

Re: linux-next: manual merge of the akpm-current tree with the tip tree

Hi Peter, On Fri, Aug 11, 2017 at 04:04:50PM +0200, Peter Zijlstra wrote: > > Ok, so I have the below to still go on-top. > > Ideally someone would clarify the situation around > mm_tlb_flush_nested(), because ideally we'd remove the > smp_mb__after_atomic() and go back to relying on PTL alone.

Re: [PATCH] virtio-net: make array guest_offloads static

From: Colin King Date: Sat, 12 Aug 2017 22:45:53 +0100 > From: Colin Ian King > > The array guest_offloads is local to the source and does not need to > be in global scope, so make it static. Also tweak formatting. > > Cleans up sparse warnings: > symbol 'guest_offloads' was not declared.

Re: linux-next: manual merge of the akpm-current tree with the tip tree

Hi Peter, On Fri, Aug 11, 2017 at 04:04:50PM +0200, Peter Zijlstra wrote: > > Ok, so I have the below to still go on-top. > > Ideally someone would clarify the situation around > mm_tlb_flush_nested(), because ideally we'd remove the > smp_mb__after_atomic() and go back to relying on PTL alone.

Re: [PATCH net-next V2 0/3] XDP support for tap

From: Jason Wang Date: Fri, 11 Aug 2017 19:41:15 +0800 > Hi all: > > This series tries to implement XDP support for tap. Two path were > implemented: > > - fast path: small & non-gso packet, For performance reason we do it > at page level and use build_skb() to create

Re: [PATCH net-next V2 0/3] XDP support for tap

From: Jason Wang Date: Fri, 11 Aug 2017 19:41:15 +0800 > Hi all: > > This series tries to implement XDP support for tap. Two path were > implemented: > > - fast path: small & non-gso packet, For performance reason we do it > at page level and use build_skb() to create skb if necessary. > -

Re: [PATCH v3 0/7] Add rk3328 pwm support

Hi Boris && thierry, Do you have any other suggestion for the patches? 在 2017/8/8 23:38, David Wu 写道: There are two features of rk3328 pwm module. - PWM APB and function clocks are different. - Add pwm atomic hardware update David Wu (7): pwm: rockchip: Add APB and function both clocks

Re: [PATCH v3 0/7] Add rk3328 pwm support

Hi Boris && thierry, Do you have any other suggestion for the patches? 在 2017/8/8 23:38, David Wu 写道: There are two features of rk3328 pwm module. - PWM APB and function clocks are different. - Add pwm atomic hardware update David Wu (7): pwm: rockchip: Add APB and function both clocks

Re: [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote: > Xen's raw SYSCALL entries are much less weird than native. Rather > than fudging them to look like native entries, use the Xen-provided > stack frame directly. > > This lets us eliminate entry_SYSCALL_64_after_swapgs and

Re: [PATCH v2] x86/xen/64: Rearrange the SYSCALL entries

On Mon, Aug 7, 2017 at 11:59 PM, Andy Lutomirski wrote: > Xen's raw SYSCALL entries are much less weird than native. Rather > than fudging them to look like native entries, use the Xen-provided > stack frame directly. > > This lets us eliminate entry_SYSCALL_64_after_swapgs and two uses of > the

Re: [PATCH 1/5] cramfs: direct memory access support

On Sat, 12 Aug 2017, Christoph Hellwig wrote: > Direct physical memory access in a file system is never safe. > Please make sure this goes through struct dax_operations. Well, after having a closer look, I don't think dax might be relevant here for a couple reasons: - cramfs is read-only. No

Re: [PATCH 1/5] cramfs: direct memory access support

On Sat, 12 Aug 2017, Christoph Hellwig wrote: > Direct physical memory access in a file system is never safe. > Please make sure this goes through struct dax_operations. Well, after having a closer look, I don't think dax might be relevant here for a couple reasons: - cramfs is read-only. No

Re: [PATCHv6 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

On Fri, 2017-08-11 at 08:21 -0700, Randy Dunlap wrote: > On 08/10/2017 11:49 PM, Hean-Loong, Ong wrote: > > > > diff --git a/drivers/gpu/drm/ivip/Kconfig > > b/drivers/gpu/drm/ivip/Kconfig > > new file mode 100644 > > index 000..398c9ab > > --- /dev/null > > +++ b/drivers/gpu/drm/ivip/Kconfig

Re: [PATCHv6 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite

On Fri, 2017-08-11 at 08:21 -0700, Randy Dunlap wrote: > On 08/10/2017 11:49 PM, Hean-Loong, Ong wrote: > > > > diff --git a/drivers/gpu/drm/ivip/Kconfig > > b/drivers/gpu/drm/ivip/Kconfig > > new file mode 100644 > > index 000..398c9ab > > --- /dev/null > > +++ b/drivers/gpu/drm/ivip/Kconfig

Re: [PATCH v4 4/5] squashfs: Add zstd support

On Sun, Aug 13, 2017 at 9:31 AM, Geert Uytterhoeven wrote: > On Fri, Aug 4, 2017 at 10:19 PM, Nick Terrell wrote: >> --- a/fs/squashfs/decompressor.c >> +++ b/fs/squashfs/decompressor.c >> @@ -65,6 +65,12 @@ static const struct squashfs_decompressor >>

Re: [PATCH v4 4/5] squashfs: Add zstd support

On Sun, Aug 13, 2017 at 9:31 AM, Geert Uytterhoeven wrote: > On Fri, Aug 4, 2017 at 10:19 PM, Nick Terrell wrote: >> --- a/fs/squashfs/decompressor.c >> +++ b/fs/squashfs/decompressor.c >> @@ -65,6 +65,12 @@ static const struct squashfs_decompressor >> squashfs_zlib_comp_ops = { >> }; >>

Re: [PATCH net-next v2 3/3] ftgmac100: Support NCSI VLAN filtering when available

On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas wrote: > Register the ndo_vlan_rx_{add,kill}_vid callbacks and set the > NETIF_F_HW_VLAN_CTAG_FILTER if NCSI is available. > This allows the VLAN core to notify the NCSI driver when changes occur > so that the remote

Re: [PATCH net-next v2 3/3] ftgmac100: Support NCSI VLAN filtering when available

On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas wrote: > Register the ndo_vlan_rx_{add,kill}_vid callbacks and set the > NETIF_F_HW_VLAN_CTAG_FILTER if NCSI is available. > This allows the VLAN core to notify the NCSI driver when changes occur > so that the remote NCSI channel can be

Re: [PATCH net-next v2 1/3] net/ncsi: Fix several packet definitions

On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas wrote: I asked Sam if these should be backported to stable and he said: > These are straight up bugs except... without my changes we never call > this code. As Ben says as time provides a lot of the current

Re: [PATCH net-next v2 1/3] net/ncsi: Fix several packet definitions

On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas wrote: I asked Sam if these should be backported to stable and he said: > These are straight up bugs except... without my changes we never call > this code. As Ben says as time provides a lot of the current definitions > need to be gone

Re: [PATCH net-next v2 2/3] net/ncsi: Configure VLAN tag filter

On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas wrote: > Make use of the ndo_vlan_rx_{add,kill}_vid callbacks to have the NCSI > stack process new VLAN tags and configure the channel VLAN filter > appropriately. > Several VLAN tags can be set and a "Set VLAN Filter"

Re: [PATCH net-next v2 2/3] net/ncsi: Configure VLAN tag filter

On Mon, Aug 14, 2017 at 10:59 AM, Samuel Mendoza-Jonas wrote: > Make use of the ndo_vlan_rx_{add,kill}_vid callbacks to have the NCSI > stack process new VLAN tags and configure the channel VLAN filter > appropriately. > Several VLAN tags can be set and a "Set VLAN Filter" packet must be sent >

linux-next: no release today

Hi all, There will be no linux-next release today (I am a bit under the weather). -- Cheers, Stephen Rothwell

linux-next: no release today

Hi all, There will be no linux-next release today (I am a bit under the weather). -- Cheers, Stephen Rothwell

Re: [PATCH v2 1/4] dt-bindings: hwmon: pmbus: Add Maxim MAX31785 documentation

On Thu, 2017-08-10 at 11:13 -0500, Rob Herring wrote: > On Wed, Aug 02, 2017 at 04:45:38PM +0930, Andrew Jeffery wrote: > > > > Signed-off-by: Andrew Jeffery > > --- > >  .../devicetree/bindings/hwmon/pmbus/max31785.txt   | 126 > > + > >  1 file changed, 126

Re: [PATCH v2 1/4] dt-bindings: hwmon: pmbus: Add Maxim MAX31785 documentation

On Thu, 2017-08-10 at 11:13 -0500, Rob Herring wrote: > On Wed, Aug 02, 2017 at 04:45:38PM +0930, Andrew Jeffery wrote: > > > > Signed-off-by: Andrew Jeffery > > --- > >  .../devicetree/bindings/hwmon/pmbus/max31785.txt   | 126 > > + > >  1 file changed, 126 insertions(+) > >

Re: [PATCH v3 10/13] ARM: dts: rockchip: add saradc support for rv1108

Hi Heiko: On 2017年08月13日 20:13, Heiko Stuebner wrote: Hi Andy, Am Freitag, 11. August 2017, 11:46:51 CEST schrieb Andy Yan: Add saradc device tree node for rv1108 soc Signed-off-by: Andy Yan + adc: adc@1038c000 { + compatible =

Re: [PATCH v3 10/13] ARM: dts: rockchip: add saradc support for rv1108

Hi Heiko: On 2017年08月13日 20:13, Heiko Stuebner wrote: Hi Andy, Am Freitag, 11. August 2017, 11:46:51 CEST schrieb Andy Yan: Add saradc device tree node for rv1108 soc Signed-off-by: Andy Yan + adc: adc@1038c000 { + compatible = "rockchip,rv1108-saradc",

Re: [PATCH v2 1/7] zram: set BDI_CAP_STABLE_WRITES once

On (08/11/17 14:17), Minchan Kim wrote: > [1] fixed weird thing(i.e., reset BDI_CAP_STABLE_WRITES flag > unconditionally whenever revalidat_disk is called) so zram doesn't > need to reset the flag any more whenever revalidating the bdev. > Instead, set the flag just once when the zram device is

Re: [PATCH v2 1/7] zram: set BDI_CAP_STABLE_WRITES once

On (08/11/17 14:17), Minchan Kim wrote: > [1] fixed weird thing(i.e., reset BDI_CAP_STABLE_WRITES flag > unconditionally whenever revalidat_disk is called) so zram doesn't > need to reset the flag any more whenever revalidating the bdev. > Instead, set the flag just once when the zram device is

Re: [PATCH v2 2/2] i2c: mediatek: Add i2c compatible for MediaTek MT7622

On Sat, 2017-08-12 at 16:44 +0200, Wolfram Sang wrote: > > +static const struct i2c_adapter_quirks mt7622_i2c_quirks = { > > + .max_num_msgs = 255, > > + .max_write_len = 65535, > > + .max_read_len = 65535, > > + .max_comb_1st_msg_len = 65535, > > + .max_comb_2nd_msg_len = 65535, > > +};

Re: [PATCH v2 2/2] i2c: mediatek: Add i2c compatible for MediaTek MT7622

On Sat, 2017-08-12 at 16:44 +0200, Wolfram Sang wrote: > > +static const struct i2c_adapter_quirks mt7622_i2c_quirks = { > > + .max_num_msgs = 255, > > + .max_write_len = 65535, > > + .max_read_len = 65535, > > + .max_comb_1st_msg_len = 65535, > > + .max_comb_2nd_msg_len = 65535, > > +};

  1   2   3   4   5   >