Re: linux-next: Signed-off-by missing for commit in the s390 tree

On Wed, 27 Sep 2017 09:27:34 +1000 Stephen Rothwell wrote: > Commit > > fc9abdb8a661 ("samples/kprobes: Add s390 case in kprobe example module") > > is missing a Signed-off-by from its committer. Fixed, thanks! -- blue skies, Martin. "Reality continues to ruin

Re: linux-next: Signed-off-by missing for commit in the s390 tree

On Wed, 27 Sep 2017 09:27:34 +1000 Stephen Rothwell wrote: > Commit > > fc9abdb8a661 ("samples/kprobes: Add s390 case in kprobe example module") > > is missing a Signed-off-by from its committer. Fixed, thanks! -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.

Re: [PATCH] HID: hid-multitouch: support fine-grain orientation reporting

Hi Wei-Ning, On Tue, Sep 26, 2017 at 8:03 PM, Wei-Ning Huang wrote: > > The current hid-multitouch driver only allow the report of two > orientations, vertical and horizontal. We use the Azimuth orientation > usage 0x5b under the Digitizer usage page to report orientation

Re: [PATCH] HID: hid-multitouch: support fine-grain orientation reporting

Hi Wei-Ning, On Tue, Sep 26, 2017 at 8:03 PM, Wei-Ning Huang wrote: > > The current hid-multitouch driver only allow the report of two > orientations, vertical and horizontal. We use the Azimuth orientation > usage 0x5b under the Digitizer usage page to report orientation directly > from the hid

Re: [RFC] a question about mlockall() and mprotect()

On 2017/9/26 19:00, Michal Hocko wrote: > On Tue 26-09-17 11:45:16, Vlastimil Babka wrote: >> On 09/26/2017 11:22 AM, Xishi Qiu wrote: >>> On 2017/9/26 17:13, Xishi Qiu wrote: > This is still very fuzzy. What are you actually trying to achieve? I don't expect page fault any more

Re: [RFC] a question about mlockall() and mprotect()

On 2017/9/26 19:00, Michal Hocko wrote: > On Tue 26-09-17 11:45:16, Vlastimil Babka wrote: >> On 09/26/2017 11:22 AM, Xishi Qiu wrote: >>> On 2017/9/26 17:13, Xishi Qiu wrote: > This is still very fuzzy. What are you actually trying to achieve? I don't expect page fault any more

[PATCH v2 2/4] mmc: sdhci-msm: Fix HW issue with power IRQ handling during reset

From: Sahitya Tummala There is a rare scenario in HW, where the first clear pulse could be lost when the actual reset and clear/read of status register are happening at the same time. Fix this by retrying upto 10 times to ensure the status register gets cleared.

[PATCH v2 2/4] mmc: sdhci-msm: Fix HW issue with power IRQ handling during reset

From: Sahitya Tummala There is a rare scenario in HW, where the first clear pulse could be lost when the actual reset and clear/read of status register are happening at the same time. Fix this by retrying upto 10 times to ensure the status register gets cleared. Otherwise, this will lead to a

[PATCH v2 4/4] mmc: sdhci-msm: Add sdhci msm register write APIs which wait for pwr irq

Register writes which change voltage of IO lines or turn the IO bus on/off require controller to be ready before progressing further. When the controller is ready, it will generate a power irq which needs to be handled. The thread which initiated the register write should wait for power irq to

[PATCH v2 3/4] mmc: Kconfig: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

Enable CONFIG_MMC_SDHCI_IO_ACCESSORS so that SDHC controller specific register read and write APIs, if registered, can be used. Signed-off-by: Vijay Viswanath --- drivers/mmc/host/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/Kconfig

[PATCH v2 1/4] mmc: sdhci-msm: fix issue with power irq

From: Subhash Jadavani SDCC controller reset (SW_RST) during probe may trigger power irq if previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we enable the power irq interrupt in GIC (by registering the interrupt handler), we need to ensure that any

[PATCH v2 4/4] mmc: sdhci-msm: Add sdhci msm register write APIs which wait for pwr irq

Register writes which change voltage of IO lines or turn the IO bus on/off require controller to be ready before progressing further. When the controller is ready, it will generate a power irq which needs to be handled. The thread which initiated the register write should wait for power irq to

[PATCH v2 3/4] mmc: Kconfig: Enable CONFIG_MMC_SDHCI_IO_ACCESSORS

Enable CONFIG_MMC_SDHCI_IO_ACCESSORS so that SDHC controller specific register read and write APIs, if registered, can be used. Signed-off-by: Vijay Viswanath --- drivers/mmc/host/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig

[PATCH v2 1/4] mmc: sdhci-msm: fix issue with power irq

From: Subhash Jadavani SDCC controller reset (SW_RST) during probe may trigger power irq if previous status of PWRCTL was either BUS_ON or IO_HIGH_V. So before we enable the power irq interrupt in GIC (by registering the interrupt handler), we need to ensure that any pending power irq interrupt

[PATCH v2 0/4] mmc: sdhci-msm: Corrections to implementation of power irq

Register writes which change voltage of IO lines or turn the IO bus on/off require sdhc controller to be ready before progressing further. Once a register write which affects IO lines is done, the driver should wait for power irq from controller. Once the irq comes, the driver should acknowledge

[PATCH v2 0/4] mmc: sdhci-msm: Corrections to implementation of power irq

Register writes which change voltage of IO lines or turn the IO bus on/off require sdhc controller to be ready before progressing further. Once a register write which affects IO lines is done, the driver should wait for power irq from controller. Once the irq comes, the driver should acknowledge

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

Hi David, On Tuesday, 26 September 2017 21:53:21 PDT David Miller wrote: > From: Paul Burton > Date: Tue, 26 Sep 2017 21:30:56 -0700 > > > Nobody said that you are required to do anything, I suggested that > > it would be beneficial if you were to suggest a change to the

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

Hi David, On Tuesday, 26 September 2017 21:53:21 PDT David Miller wrote: > From: Paul Burton > Date: Tue, 26 Sep 2017 21:30:56 -0700 > > > Nobody said that you are required to do anything, I suggested that > > it would be beneficial if you were to suggest a change to the > > documented DMA API

Re: [PATCH v2 5/5] media: atmel-isc: Rework the format list

Hi Hans, Thank  you very much for your review. On 2017/9/25 21:24, Hans Verkuil wrote: Hi Wenyou, On 18/09/17 08:39, Wenyou Yang wrote: To improve the readability of code, split the format array into two, one for the format description, other for the register configuration. Meanwhile, add

Re: [PATCH v2 5/5] media: atmel-isc: Rework the format list

Hi Hans, Thank  you very much for your review. On 2017/9/25 21:24, Hans Verkuil wrote: Hi Wenyou, On 18/09/17 08:39, Wenyou Yang wrote: To improve the readability of code, split the format array into two, one for the format description, other for the register configuration. Meanwhile, add

[PATCH v2 2/2] pid: Remove pidhash

pidhash is no longer required as all the information can be looked up from idr tree. nr_hashed represented the number of pids that had been hashed. Since, nr_hashed and PIDNS_HASH_ADDING are no longer relevant, it has been renamed to pid_allocated and PIDNS_ADDING respectively. Signed-off-by:

[PATCH v2 2/2] pid: Remove pidhash

pidhash is no longer required as all the information can be looked up from idr tree. nr_hashed represented the number of pids that had been hashed. Since, nr_hashed and PIDNS_HASH_ADDING are no longer relevant, it has been renamed to pid_allocated and PIDNS_ADDING respectively. Signed-off-by:

[PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

This patch replaces the current bitmap implemetation for Process ID allocation. Functions that are no longer required, for example, free_pidmap(), alloc_pidmap(), etc. are removed. The rest of the functions are modified to use the IDR API. The change was made to make the PID allocation less

[PATCH v2 1/2] pid: Replace pid bitmap implementation with IDR API

This patch replaces the current bitmap implemetation for Process ID allocation. Functions that are no longer required, for example, free_pidmap(), alloc_pidmap(), etc. are removed. The rest of the functions are modified to use the IDR API. The change was made to make the PID allocation less

[PATCH v2 0/2] Replace PID bitmap allocation with IDR API

This patch series replaces kernel bitmap implementation of PID allocation with IDR API. These patches are written to simplify the kernel by replacing custom code with calls to generic code. The following are the stats for pid and pid_namespace object files before and after the replacement. There

[PATCH v2 0/2] Replace PID bitmap allocation with IDR API

This patch series replaces kernel bitmap implementation of PID allocation with IDR API. These patches are written to simplify the kernel by replacing custom code with calls to generic code. The following are the stats for pid and pid_namespace object files before and after the replacement. There

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote: > On Thu 21-09-17 09:33:10, Huang, Ying wrote: > > From: Huang Ying > > > > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA > > based swap readahead code inside #ifdef

Re: [PATCH] mm, swap: Make VMA based swap readahead configurable

On Tue, Sep 26, 2017 at 03:21:29PM +0200, Michal Hocko wrote: > On Thu 21-09-17 09:33:10, Huang, Ying wrote: > > From: Huang Ying > > > > This patch adds a new Kconfig option VMA_SWAP_READAHEAD and wraps VMA > > based swap readahead code inside #ifdef CONFIG_VMA_SWAP_READAHEAD/#endif. > > This

Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Sergey Senozhatsky writes: > On (09/22/17 16:48), Luck, Tony wrote: > [..] >> Tested patch series on ia64 successfully. >> >> Tested-by: Tony Luck > > thanks! > >> After this goes upstream, you should submit a patch to get rid of >> all

Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

Sergey Senozhatsky writes: > On (09/22/17 16:48), Luck, Tony wrote: > [..] >> Tested patch series on ia64 successfully. >> >> Tested-by: Tony Luck > > thanks! > >> After this goes upstream, you should submit a patch to get rid of >> all uses of %pF (70 instances in 35 files) and %pf (63 in 34)

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Paul Burton Date: Tue, 26 Sep 2017 21:30:56 -0700 > Nobody said that you are required to do anything, I suggested that > it would be beneficial if you were to suggest a change to the > documented DMA API such that it allows your usage where it currently > does not.

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Paul Burton Date: Tue, 26 Sep 2017 21:30:56 -0700 > Nobody said that you are required to do anything, I suggested that > it would be beneficial if you were to suggest a change to the > documented DMA API such that it allows your usage where it currently > does not. Documentation is often

Re: [PATCH v2 16/16] net: Add support for networking over Thunderbolt cable

From: Mika Westerberg Date: Mon, 25 Sep 2017 14:07:38 +0300 > +struct thunderbolt_ip_header { > + u32 route_hi; > + u32 route_lo; > + u32 length_sn; > + uuid_t uuid; > + uuid_t initiator_uuid; > + uuid_t target_uuid; > + u32 type; > +

Re: [PATCH v2 16/16] net: Add support for networking over Thunderbolt cable

From: Mika Westerberg Date: Mon, 25 Sep 2017 14:07:38 +0300 > +struct thunderbolt_ip_header { > + u32 route_hi; > + u32 route_lo; > + u32 length_sn; > + uuid_t uuid; > + uuid_t initiator_uuid; > + uuid_t target_uuid; > + u32 type; > + u32 command_id; > +}

Re: [PATCH v2 02/16] thunderbolt: Add support for XDomain properties

From: Mika Westerberg Date: Mon, 25 Sep 2017 14:07:24 +0300 > +struct tb_property_entry { > + u32 key_hi; > + u32 key_lo; > + u16 length; > + u8 reserved; > + u8 type; > + u32 value; > +} __packed; > + > +struct tb_property_rootdir_entry {

Re: [PATCH v2 02/16] thunderbolt: Add support for XDomain properties

From: Mika Westerberg Date: Mon, 25 Sep 2017 14:07:24 +0300 > +struct tb_property_entry { > + u32 key_hi; > + u32 key_lo; > + u16 length; > + u8 reserved; > + u8 type; > + u32 value; > +} __packed; > + > +struct tb_property_rootdir_entry { > + u32 magic; > + u32

Re: [PATCH v2 06/16] thunderbolt: Add support for XDomain discovery protocol

From: Mika Westerberg Date: Mon, 25 Sep 2017 14:07:28 +0300 > +struct icm_fr_event_xdomain_connected { > + struct icm_pkg_header hdr; > + u16 reserved; > + u16 link_info; > + uuid_t remote_uuid; > + uuid_t local_uuid; > + u32

Re: [PATCH v2 06/16] thunderbolt: Add support for XDomain discovery protocol

From: Mika Westerberg Date: Mon, 25 Sep 2017 14:07:28 +0300 > +struct icm_fr_event_xdomain_connected { > + struct icm_pkg_header hdr; > + u16 reserved; > + u16 link_info; > + uuid_t remote_uuid; > + uuid_t local_uuid; > + u32 local_route_hi; > + u32 local_route_lo; >

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

Hi David, On Tuesday, 26 September 2017 19:52:44 PDT David Miller wrote: > From: Paul Burton > Date: Tue, 26 Sep 2017 14:30:33 -0700 > > > I'd suggest that at a minimum if you're unwilling to obey the API as > > described in Documentation/DMA-API.txt then it would be

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

Hi David, On Tuesday, 26 September 2017 19:52:44 PDT David Miller wrote: > From: Paul Burton > Date: Tue, 26 Sep 2017 14:30:33 -0700 > > > I'd suggest that at a minimum if you're unwilling to obey the API as > > described in Documentation/DMA-API.txt then it would be beneficial > > if you could

Re: [PATCH v8 12/28] x86/insn-eval: Add utility functions to get segment selector

On Tue, 2017-09-26 at 12:43 +0200, Borislav Petkov wrote: > Hi, > > On Fri, Aug 18, 2017 at 05:27:53PM -0700, Ricardo Neri wrote: > > > > When computing a linear address and segmentation is used, we need > > to know > > the base address of the segment involved in the computation. In > > most of

Re: [PATCH v8 12/28] x86/insn-eval: Add utility functions to get segment selector

On Tue, 2017-09-26 at 12:43 +0200, Borislav Petkov wrote: > Hi, > > On Fri, Aug 18, 2017 at 05:27:53PM -0700, Ricardo Neri wrote: > > > > When computing a linear address and segmentation is used, we need > > to know > > the base address of the segment involved in the computation. In > > most of

Re: [PATCH net] net/ncsi: Don't assume last available channel exists

On Thu, 2017-09-21 at 18:11 -0700, David Miller wrote: > From: Samuel Mendoza-Jonas > Date: Fri, 22 Sep 2017 11:00:00 +1000 > > > If we haven't configured a channel yet (or are in the process of doing > > so) we won't have a hot_channel - does it make more sense to > > -

Re: [PATCH net] net/ncsi: Don't assume last available channel exists

On Thu, 2017-09-21 at 18:11 -0700, David Miller wrote: > From: Samuel Mendoza-Jonas > Date: Fri, 22 Sep 2017 11:00:00 +1000 > > > If we haven't configured a channel yet (or are in the process of doing > > so) we won't have a hot_channel - does it make more sense to > > - check against the

[PATCH v2] mm: update comments for struct page.mapping

From: Changbin Du The struct page.mapping can NULL or points to one object of type address_space, anon_vma or KSM private structure. Signed-off-by: Changbin Du --- v2: add back flag reference. --- include/linux/mm_types.h | 6 -- 1 file

[PATCH v2] mm: update comments for struct page.mapping

From: Changbin Du The struct page.mapping can NULL or points to one object of type address_space, anon_vma or KSM private structure. Signed-off-by: Changbin Du --- v2: add back flag reference. --- include/linux/mm_types.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

Re: [PATCH] mm: update comments for struct page.mapping

On Tue, Sep 26, 2017 at 04:30:27PM -0700, Andrew Morton wrote: > On Tue, 26 Sep 2017 15:14:17 +0800 changbin...@intel.com wrote: > > > From: Changbin Du > > > > The struct page.mapping can NULL or points to one object of type > > address_space, anon_vma or KSM private

Re: [PATCH] mm: update comments for struct page.mapping

On Tue, Sep 26, 2017 at 04:30:27PM -0700, Andrew Morton wrote: > On Tue, 26 Sep 2017 15:14:17 +0800 changbin...@intel.com wrote: > > > From: Changbin Du > > > > The struct page.mapping can NULL or points to one object of type > > address_space, anon_vma or KSM private structure. > > > > ... >

Re: [PATCH v2 03/13] drm/sun4i: tcon: Add support for demuxing TCON output on A31

On Tue, Sep 26, 2017 at 5:56 PM, Maxime Ripard wrote: > Hi, > > On Tue, Sep 26, 2017 at 06:59:09AM +, Chen-Yu Tsai wrote: >> On systems with 2 TCONs such as the A31, it is possible to demux the >> output of the TCONs to one encoder. >> >> Add support for this

Re: [PATCH v2 03/13] drm/sun4i: tcon: Add support for demuxing TCON output on A31

On Tue, Sep 26, 2017 at 5:56 PM, Maxime Ripard wrote: > Hi, > > On Tue, Sep 26, 2017 at 06:59:09AM +, Chen-Yu Tsai wrote: >> On systems with 2 TCONs such as the A31, it is possible to demux the >> output of the TCONs to one encoder. >> >> Add support for this for the A31. >> >> Signed-off-by:

Re: [PATCH] mmc:host:sdhci-pci: Addition of Arasan PCI controller with integrated phy.

On 2017/9/27 2:59, Atul Garg wrote: The Arasan controller is based on a FPGA platform and has integrated phy with specific phy registers used during the initialization and management of different modes. The phy and the controller are integrated and registers are very specific to Arasan. Arasan

Re: [PATCH] mmc:host:sdhci-pci: Addition of Arasan PCI controller with integrated phy.

On 2017/9/27 2:59, Atul Garg wrote: The Arasan controller is based on a FPGA platform and has integrated phy with specific phy registers used during the initialization and management of different modes. The phy and the controller are integrated and registers are very specific to Arasan. Arasan

[PATCH v3] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold

[PATCH v3] dma-debug: fix incorrect pfn calculation

From: Miles Chen dma-debug reports the following warning: [name:panic&]WARNING: CPU: 3 PID: 298 at kernel-4.4/lib/dma-debug.c:604 debug _dma_assert_idle+0x1a8/0x230() DMA-API: cpu touching an active dma mapped cacheline [cln=0x0882300] CPU: 3 PID: 298 Comm: vold Tainted: GW O

Re: [PATCH v2 02/13] clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision

On Tue, Sep 26, 2017 at 5:32 PM, Maxime Ripard wrote: > On Tue, Sep 26, 2017 at 06:59:08AM +, Chen-Yu Tsai wrote: >> The HDMI DDC clock found in the CCU is the parent of the actual DDC >> clock within the HDMI controller. That clock is also named "hdmi-ddc".

Re: [PATCH v2 02/13] clk: sunxi-ng: sun6i: Rename HDMI DDC clock to avoid name collision

On Tue, Sep 26, 2017 at 5:32 PM, Maxime Ripard wrote: > On Tue, Sep 26, 2017 at 06:59:08AM +, Chen-Yu Tsai wrote: >> The HDMI DDC clock found in the CCU is the parent of the actual DDC >> clock within the HDMI controller. That clock is also named "hdmi-ddc". >> >> Rename the one in the CCU to

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

Hi all, After merging the tip tree, today's linux-next build (x86_64 allnoconfig) produced this warning: kernel/printk/printk.c:1983:12: warning: 'printk_time' defined but not used [-Wunused-variable] static int printk_time; ^ Introduced by commit 310b454a8653 ("printk: Add

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

Hi all, After merging the tip tree, today's linux-next build (x86_64 allnoconfig) produced this warning: kernel/printk/printk.c:1983:12: warning: 'printk_time' defined but not used [-Wunused-variable] static int printk_time; ^ Introduced by commit 310b454a8653 ("printk: Add

Re: [v8 0/4] cgroup-aware OOM killer

I'm excited to see this being discussed again - it's been years since the last attempt. I've tried to stay out of the conversation, but I feel obligated say something and then go back to lurking. On Tue, Sep 26, 2017 at 10:26 AM, Johannes Weiner wrote: > On Tue, Sep 26, 2017

Re: [v8 0/4] cgroup-aware OOM killer

I'm excited to see this being discussed again - it's been years since the last attempt. I've tried to stay out of the conversation, but I feel obligated say something and then go back to lurking. On Tue, Sep 26, 2017 at 10:26 AM, Johannes Weiner wrote: > On Tue, Sep 26, 2017 at 03:30:40PM

[PATCH v5 1/4] ipv4: Namespaceify tcp_fastopen knob

Different namespace application might require enable TCP Fast Open feature independently of the host. This patch series continues making more of the TCP Fast Open related sysctl knobs be per net-namespace. Reported-by: Luca BRUNO Signed-off-by: Haishuang Yan

[PATCH v5 1/4] ipv4: Namespaceify tcp_fastopen knob

Different namespace application might require enable TCP Fast Open feature independently of the host. This patch series continues making more of the TCP Fast Open related sysctl knobs be per net-namespace. Reported-by: Luca BRUNO Signed-off-by: Haishuang Yan --- Changes since v5: * Splite

[PATCH v5 2/4] ipv4: Remove the 'publish' logic in tcp_fastopen_init_key_once

The 'publish' logic is not necessary after commit dfea2aa65424 ("tcp: Do not call tcp_fastopen_reset_cipher from interrupt context"), because in tcp_fastopen_cookie_gen，it wouldn't call tcp_fastopen_init_key_once. Signed-off-by: Haishuang Yan ---

[PATCH v5 2/4] ipv4: Remove the 'publish' logic in tcp_fastopen_init_key_once

The 'publish' logic is not necessary after commit dfea2aa65424 ("tcp: Do not call tcp_fastopen_reset_cipher from interrupt context"), because in tcp_fastopen_cookie_gen，it wouldn't call tcp_fastopen_init_key_once. Signed-off-by: Haishuang Yan --- include/net/tcp.h | 2 +-

[PATCH v5 4/4] ipv4: Namespaceify tcp_fastopen_blackhole_timeout knob

Different namespace application might require different time period in second to disable Fastopen on active TCP sockets. Tested: Simulate following similar situation that the server's data gets dropped after 3WHS. C syn-data ---> S C <--- syn/ack - S C ack > S S (accept &

[PATCH v5 3/4] ipv4: Namespaceify tcp_fastopen_key knob

Different namespace application might require different tcp_fastopen_key independently of the host. David Miller pointed out there is a leak without releasing the context of tcp_fastopen_key during netns teardown. So add the release action in exit_batch path. Tested: 1. Container namespace: #

[PATCH v5 4/4] ipv4: Namespaceify tcp_fastopen_blackhole_timeout knob

Different namespace application might require different time period in second to disable Fastopen on active TCP sockets. Tested: Simulate following similar situation that the server's data gets dropped after 3WHS. C syn-data ---> S C <--- syn/ack - S C ack > S S (accept &

[PATCH v5 3/4] ipv4: Namespaceify tcp_fastopen_key knob

Different namespace application might require different tcp_fastopen_key independently of the host. David Miller pointed out there is a leak without releasing the context of tcp_fastopen_key during netns teardown. So add the release action in exit_batch path. Tested: 1. Container namespace: #

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

Hi James, On Tue, 26 Sep 2017 14:09:47 +1000 Stephen Rothwell wrote: > > After merging the scsi-mkp tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/scsi/hisi_sas/hisi_sas_main.c: In function > 'hisi_sas_controller_reset': >

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

Hi James, On Tue, 26 Sep 2017 14:09:47 +1000 Stephen Rothwell wrote: > > After merging the scsi-mkp tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/scsi/hisi_sas/hisi_sas_main.c: In function > 'hisi_sas_controller_reset': >

Re: [PATCH v2 05/10] arm: dts: mt7623: update pio, usb and crypto nodes

On Tue, 2017-09-26 at 18:17 +0800, Yingjoe Chen wrote: > On Tue, 2017-09-26 at 10:02 +0800, Ryder Lee wrote: > > This patch updates pio, usb and crypto nodes to make them be consistent > > with the binding documents. > > > > Signed-off-by: Ryder Lee > > --- > >

Re: [PATCH v2 05/10] arm: dts: mt7623: update pio, usb and crypto nodes

On Tue, 2017-09-26 at 18:17 +0800, Yingjoe Chen wrote: > On Tue, 2017-09-26 at 10:02 +0800, Ryder Lee wrote: > > This patch updates pio, usb and crypto nodes to make them be consistent > > with the binding documents. > > > > Signed-off-by: Ryder Lee > > --- > > arch/arm/boot/dts/mt7623.dtsi |

Re: pull-request: wireless-drivers 2017-09-25

From: Kalle Valo Date: Mon, 25 Sep 2017 11:55:22 +0300 > here a pull request to net for 4.14, more info in the signed tag below. > Please let me know if there are any problems. Pulled, thanks Kalle.

Re: pull-request: wireless-drivers 2017-09-25

From: Kalle Valo Date: Mon, 25 Sep 2017 11:55:22 +0300 > here a pull request to net for 4.14, more info in the signed tag below. > Please let me know if there are any problems. Pulled, thanks Kalle.

Re: [PATCH net-next 0/5] net: dsa: use generic slave phydev

From: Vivien Didelot Date: Tue, 26 Sep 2017 17:15:30 -0400 > DSA currently stores a phy_device pointer in each slave private > structure. This requires to implement our own ethtool ksettings > accessors and such. > > This patchset removes the private

Re: [PATCH net-next 0/5] net: dsa: use generic slave phydev

From: Vivien Didelot Date: Tue, 26 Sep 2017 17:15:30 -0400 > DSA currently stores a phy_device pointer in each slave private > structure. This requires to implement our own ethtool ksettings > accessors and such. > > This patchset removes the private phy_device in favor of the one > provided in

[PATCH] Call xen_cleanhighmap() with 4MB aligned for page tables mapping

When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial mapping overlaps with kernel module virtual space. When mapping in this space is cleared by xen_cleanhighmap(), in certain case there could be an 2MB mapping left. This is due to XEN initialize 4MB aligned mapping but

[PATCH] Call xen_cleanhighmap() with 4MB aligned for page tables mapping

When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial mapping overlaps with kernel module virtual space. When mapping in this space is cleared by xen_cleanhighmap(), in certain case there could be an 2MB mapping left. This is due to XEN initialize 4MB aligned mapping but

[PATCH] HID: hid-multitouch: support fine-grain orientation reporting

The current hid-multitouch driver only allow the report of two orientations, vertical and horizontal. We use the Azimuth orientation usage 0x5b under the Digitizer usage page to report orientation directly from the hid device. A new quirk MT_QUIRK_REPORT_ORIENTATION is added so user can enable

[PATCH] HID: hid-multitouch: support fine-grain orientation reporting

The current hid-multitouch driver only allow the report of two orientations, vertical and horizontal. We use the Azimuth orientation usage 0x5b under the Digitizer usage page to report orientation directly from the hid device. A new quirk MT_QUIRK_REPORT_ORIENTATION is added so user can enable

Re: [PATCH] net/ipv4: Update sk_for_each_entry_offset_rcu macro to utilize rcu methods hlist_next_rcu. This fixes the warnings thrown by sparse regarding net/ipv4/udp.c on line 1974.

From: Tim Hansen Date: Tue, 26 Sep 2017 20:54:05 -0400 > Signed-off-by: Tim Hansen This is a poor patch submission on many levels. But the main problem, is that there is no use of sk_for_each_entry_offset_rcu() in any of my networking kernel

Re: [PATCH] net/ipv4: Update sk_for_each_entry_offset_rcu macro to utilize rcu methods hlist_next_rcu. This fixes the warnings thrown by sparse regarding net/ipv4/udp.c on line 1974.

From: Tim Hansen Date: Tue, 26 Sep 2017 20:54:05 -0400 > Signed-off-by: Tim Hansen This is a poor patch submission on many levels. But the main problem, is that there is no use of sk_for_each_entry_offset_rcu() in any of my networking kernel trees. Referencing code by line number never

Re: [PATCH for-next 05/20] RDMA/hns: Add command queue support for hip08 RoCE driver

On 2017/9/27 0:18, Doug Ledford wrote: On 9/26/2017 9:13 AM, Wei Hu (Xavier) wrote: On 2017/9/26 1:36, Doug Ledford wrote: On Mon, 2017-09-25 at 20:18 +0300, Leon Romanovsky wrote: On Mon, Sep 25, 2017 at 01:06:53PM -0400, Doug Ledford wrote: On Wed, 2017-08-30 at 17:23 +0800, Wei Hu

Re: [PATCH for-next 05/20] RDMA/hns: Add command queue support for hip08 RoCE driver

On 2017/9/27 0:18, Doug Ledford wrote: On 9/26/2017 9:13 AM, Wei Hu (Xavier) wrote: On 2017/9/26 1:36, Doug Ledford wrote: On Mon, 2017-09-25 at 20:18 +0300, Leon Romanovsky wrote: On Mon, Sep 25, 2017 at 01:06:53PM -0400, Doug Ledford wrote: On Wed, 2017-08-30 at 17:23 +0800, Wei Hu

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Paul Burton Date: Tue, 26 Sep 2017 14:30:33 -0700 > I'd suggest that at a minimum if you're unwilling to obey the API as > described in Documentation/DMA-API.txt then it would be beneficial > if you could propose a change to it such that it works for you, and >

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

From: Paul Burton Date: Tue, 26 Sep 2017 14:30:33 -0700 > I'd suggest that at a minimum if you're unwilling to obey the API as > described in Documentation/DMA-API.txt then it would be beneficial > if you could propose a change to it such that it works for you, and > perhaps we can extend the

[PATCH v7 0/2] gpio: uniphier: UniPhier GPIO driver

This series adds UniPhier GPIO driver. The interrupt controller part is implemented by using hierarchy irqdomain. IMHO, the problem of the hierarchy irqdomain is that drivers must hard-code the fwspec of the interrupt parent. We will never know the DT binding of the parent unless we parse

[PATCH v7 0/2] gpio: uniphier: UniPhier GPIO driver

This series adds UniPhier GPIO driver. The interrupt controller part is implemented by using hierarchy irqdomain. IMHO, the problem of the hierarchy irqdomain is that drivers must hard-code the fwspec of the interrupt parent. We will never know the DT binding of the parent unless we parse

[PATCH v7 2/2] gpio: uniphier: add UniPhier GPIO controller driver

This GPIO controller is used on UniPhier SoC family. It also serves as an interrupt controller, but interrupt signals are just delivered to the parent irqchip without any latching or OR'ing. This type of hardware can be well described with hierarchy IRQ domain. One unfortunate thing for this

[PATCH v7 2/2] gpio: uniphier: add UniPhier GPIO controller driver

This GPIO controller is used on UniPhier SoC family. It also serves as an interrupt controller, but interrupt signals are just delivered to the parent irqchip without any latching or OR'ing. This type of hardware can be well described with hierarchy IRQ domain. One unfortunate thing for this

[PATCH v7 1/2] dt-bindings: gpio: uniphier: add UniPhier GPIO binding

This GPIO controller is used on UniPhier SoC family. The vendor specific property "socionext,interrupt-ranges" is for specifying interrupt mapping to the parent interrupt controller because the mapping is not contiguous. It works like "ranges", but transforms "interrupts" instead of "reg".

[PATCH v7 1/2] dt-bindings: gpio: uniphier: add UniPhier GPIO binding

This GPIO controller is used on UniPhier SoC family. The vendor specific property "socionext,interrupt-ranges" is for specifying interrupt mapping to the parent interrupt controller because the mapping is not contiguous. It works like "ranges", but transforms "interrupts" instead of "reg".

Re: [PATCH v5 1/3] irqdomain: export of_phandle_args_to_fwspec

2017-09-25 19:11 GMT+09:00 Thomas Gleixner : > On Thu, 21 Sep 2017, Linus Walleij wrote: > >> On Wed, Sep 13, 2017 at 10:56 AM, Masahiro Yamada >> wrote: >> >> > This helper will be useful for irqchip drivers that need to convert >> > DT binding

Re: [PATCH v5 1/3] irqdomain: export of_phandle_args_to_fwspec

2017-09-25 19:11 GMT+09:00 Thomas Gleixner : > On Thu, 21 Sep 2017, Linus Walleij wrote: > >> On Wed, Sep 13, 2017 at 10:56 AM, Masahiro Yamada >> wrote: >> >> > This helper will be useful for irqchip drivers that need to convert >> > DT binding into IRQ fwspec. >> > >> > Signed-off-by: Masahiro

[PATCH v6 2/2] gpio: uniphier: add UniPhier GPIO controller driver

This GPIO controller is used on UniPhier SoC family. It also serves as an interrupt controller, but interrupt signals are just delivered to the parent irqchip without any latching or OR'ing. This type of hardware can be well described with hierarchy IRQ domain. One unfortunate thing for this

[PATCH v6 0/2] gpio: uniphier: UniPhier GPIO driver

This series adds UniPhier GPIO driver. The interrupt controller part is implemented by using hierarchy irqdomain. IMHO, the problem of the hierarchy irqdomain is that drivers must hard-code the fwspec of the interrupt parent. We will never know the DT binding of the parent unless we parse

[PATCH v6 2/2] gpio: uniphier: add UniPhier GPIO controller driver

This GPIO controller is used on UniPhier SoC family. It also serves as an interrupt controller, but interrupt signals are just delivered to the parent irqchip without any latching or OR'ing. This type of hardware can be well described with hierarchy IRQ domain. One unfortunate thing for this

[PATCH v6 0/2] gpio: uniphier: UniPhier GPIO driver

This series adds UniPhier GPIO driver. The interrupt controller part is implemented by using hierarchy irqdomain. IMHO, the problem of the hierarchy irqdomain is that drivers must hard-code the fwspec of the interrupt parent. We will never know the DT binding of the parent unless we parse

[PATCH v6 1/2] dt-bindings: gpio: uniphier: add UniPhier GPIO binding

This GPIO controller is used on UniPhier SoC family. The vendor specific property "socionext,interrupt-ranges" is for specifying interrupt mapping to the parent interrupt controller because the mapping is not contiguous. It works like "ranges", but transforms "interrupts" instead of "reg".

[PATCH v6 1/2] dt-bindings: gpio: uniphier: add UniPhier GPIO binding

This GPIO controller is used on UniPhier SoC family. The vendor specific property "socionext,interrupt-ranges" is for specifying interrupt mapping to the parent interrupt controller because the mapping is not contiguous. It works like "ranges", but transforms "interrupts" instead of "reg".

  1   2   3   4   5   6   7   8   9   10   >