Re: [PATCH 12/21] i2c: imx: make use of i2c_8bit_addr_from_msg

On Mon, May 14, 2018 at 04:53:21PM +0200, Peter Rosin wrote: > Because it looks neater. > i2c_imx_dma_write and i2c_imx_write are always called with a > write in msgs->flags, and i2c_imx_read with a read. > > Signed-off-by: Peter Rosin Reviewed-by: Uwe Kleine-König

Re: [PATCH 12/21] i2c: imx: make use of i2c_8bit_addr_from_msg

On Mon, May 14, 2018 at 04:53:21PM +0200, Peter Rosin wrote: > Because it looks neater. > i2c_imx_dma_write and i2c_imx_write are always called with a > write in msgs->flags, and i2c_imx_read with a read. > > Signed-off-by: Peter Rosin Reviewed-by: Uwe Kleine-König Best regards Uwe --

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 11:23 AM, Deepa Dinamani wrote: > On Mon, May 14, 2018 at 10:53 AM, Kees Cook wrote: >> On Mon, May 14, 2018 at 10:25 AM, Deepa Dinamani >> wrote: >>> On Mon, May 14, 2018 at 9:30 AM, Kees Cook

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 11:23 AM, Deepa Dinamani wrote: > On Mon, May 14, 2018 at 10:53 AM, Kees Cook wrote: >> On Mon, May 14, 2018 at 10:25 AM, Deepa Dinamani >> wrote: >>> On Mon, May 14, 2018 at 9:30 AM, Kees Cook wrote: On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani wrote:

Re: [RFC PATCH 00/11] prctl: Modernise wiring for optional prctl() calls

On Mon, May 14, 2018 at 10:14 AM, Dave Martin wrote: > [Reviewer note: this is a cross-arch series. To reduce spam, I have > tried not to Cc people on patches they aren't likely to care about. > The complete series can be found in the LKML or linux-arch archives.] > > The

Re: [RFC PATCH 00/11] prctl: Modernise wiring for optional prctl() calls

On Mon, May 14, 2018 at 10:14 AM, Dave Martin wrote: > [Reviewer note: this is a cross-arch series. To reduce spam, I have > tried not to Cc people on patches they aren't likely to care about. > The complete series can be found in the LKML or linux-arch archives.] > > The core framework for the

Re: [PATCH 07/21] i2c: efm32: make use of i2c_8bit_addr_from_msg

Hello Peter, On Mon, May 14, 2018 at 04:53:16PM +0200, Peter Rosin wrote: > Because it looks neater. > > Signed-off-by: Peter Rosin > --- > drivers/i2c/busses/i2c-efm32.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-efm32.c

Re: [PATCH 07/21] i2c: efm32: make use of i2c_8bit_addr_from_msg

Hello Peter, On Mon, May 14, 2018 at 04:53:16PM +0200, Peter Rosin wrote: > Because it looks neater. > > Signed-off-by: Peter Rosin > --- > drivers/i2c/busses/i2c-efm32.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-efm32.c

Re: [PATCH v4 17/22] iommu/intel-svm: report device page request

On Mon, 14 May 2018 06:56:11 + "Liu, Yi L" wrote: > Same comment with the one to patch 16, pci_get_bus_and_slot() is > deprecated, may update accordingly. yes, it has been updated in v5, could you review v5?

Re: [PATCH v4 17/22] iommu/intel-svm: report device page request

On Mon, 14 May 2018 06:56:11 + "Liu, Yi L" wrote: > Same comment with the one to patch 16, pci_get_bus_and_slot() is > deprecated, may update accordingly. yes, it has been updated in v5, could you review v5?

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 20:28, Boaz Harrosh wrote: > > On a call to mmap an mmap provider (like an FS) can put > this flag on vma->vm_flags. > > The VM_LOCAL_CPU flag tells the Kernel that the vma will be used > from a single-core only, and therefore invalidation (flush_tlb) of > PTE(s) need not be a wide

Re: [PATCH] mm: Add new vma flag VM_LOCAL_CPU

On 14/05/18 20:28, Boaz Harrosh wrote: > > On a call to mmap an mmap provider (like an FS) can put > this flag on vma->vm_flags. > > The VM_LOCAL_CPU flag tells the Kernel that the vma will be used > from a single-core only, and therefore invalidation (flush_tlb) of > PTE(s) need not be a wide

Re: [Xen-devel] [PATCH v2 1/2] xen/PVH: Set up GS segment for stack canary

On 05/14/2018 08:50 AM, Jan Beulich wrote: On 09.05.18 at 22:33, wrote: >> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen) >> mov %eax,%es >> mov %eax,%ss >> >> +/* Set base address in stack canary descriptor. */ >> +movl _pa(gdt_start),%eax >> +

Re: [Xen-devel] [PATCH v2 1/2] xen/PVH: Set up GS segment for stack canary

On 05/14/2018 08:50 AM, Jan Beulich wrote: On 09.05.18 at 22:33, wrote: >> @@ -64,6 +67,17 @@ ENTRY(pvh_start_xen) >> mov %eax,%es >> mov %eax,%ss >> >> +/* Set base address in stack canary descriptor. */ >> +movl _pa(gdt_start),%eax >> +movl $_pa(canary),%ecx >> +

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 10:53 AM, Kees Cook wrote: > On Mon, May 14, 2018 at 10:25 AM, Deepa Dinamani > wrote: >> On Mon, May 14, 2018 at 9:30 AM, Kees Cook wrote: >>> On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 10:53 AM, Kees Cook wrote: > On Mon, May 14, 2018 at 10:25 AM, Deepa Dinamani > wrote: >> On Mon, May 14, 2018 at 9:30 AM, Kees Cook wrote: >>> On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani >>> wrote: Kees mentioned that he wants to merge a patch to pstore that

Re: [PATCH v1 7/9] iommu/tegra: gart: Provide single domain and group for all devices

On 11/05/18 21:05, Dmitry Osipenko wrote: On 11.05.2018 15:32, Robin Murphy wrote: On 08/05/18 19:16, Dmitry Osipenko wrote: GART aperture is shared by all devices, hence there is a single IOMMU domain and group shared by these devices. Allocation of a group per device only wastes resources

Re: [PATCH v1 7/9] iommu/tegra: gart: Provide single domain and group for all devices

On 11/05/18 21:05, Dmitry Osipenko wrote: On 11.05.2018 15:32, Robin Murphy wrote: On 08/05/18 19:16, Dmitry Osipenko wrote: GART aperture is shared by all devices, hence there is a single IOMMU domain and group shared by these devices. Allocation of a group per device only wastes resources

Re: [PATCH 1/1] Drivers: hv: vmbus: enable VMBus protocol version 5.0

On Mon, 14 May 2018 18:14:15 + Dexuan Cui wrote: > > From: devel On Behalf Of > > Stephen Hemminger > > Sent: Sunday, May 13, 2018 10:24 > > > ... > > > @@ -372,6 +400,18 @@ int vmbus_post_msg(void *buffer, size_t

Re: [PATCH 1/1] Drivers: hv: vmbus: enable VMBus protocol version 5.0

On Mon, 14 May 2018 18:14:15 + Dexuan Cui wrote: > > From: devel On Behalf Of > > Stephen Hemminger > > Sent: Sunday, May 13, 2018 10:24 > > > ... > > > @@ -372,6 +400,18 @@ int vmbus_post_msg(void *buffer, size_t buflen, > > bool can_sleep) > > > ... > > > + hdr =

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

On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: > On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >> Hi all, >> >> After merging the rdma tree, today's linux-next build (x86_64 >> allmodconfig) produced this warning: >> >> drivers/infiniband/hw/cxgb4/restrack.c: In function

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

On 5/14/2018 1:03 PM, Jason Gunthorpe wrote: > On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: >> Hi all, >> >> After merging the rdma tree, today's linux-next build (x86_64 >> allmodconfig) produced this warning: >> >> drivers/infiniband/hw/cxgb4/restrack.c: In function

RE: [PATCH 1/1] Drivers: hv: vmbus: enable VMBus protocol version 5.0

> From: devel On Behalf Of > Stephen Hemminger > Sent: Sunday, May 13, 2018 10:24 > > ... > > @@ -372,6 +400,18 @@ int vmbus_post_msg(void *buffer, size_t buflen, > bool can_sleep) > > ... > > + hdr = (struct

RE: [PATCH 1/1] Drivers: hv: vmbus: enable VMBus protocol version 5.0

> From: devel On Behalf Of > Stephen Hemminger > Sent: Sunday, May 13, 2018 10:24 > > ... > > @@ -372,6 +400,18 @@ int vmbus_post_msg(void *buffer, size_t buflen, > bool can_sleep) > > ... > > + hdr = (struct vmbus_channel_message_header *)buffer; > > Hate to pick o the

Re: [PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)

On Mon, May 14, 2018 at 10:36 AM, Lukasz Majewski wrote: > Dear All, It is only Thierry that you need to ping. It goes thru his tree as I mentioned on another panel you sent. >> This commit adds support for AUO's 7.0" display. > > If I may gentle remind about this patch > >>

Re: [PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)

On Mon, May 14, 2018 at 10:36 AM, Lukasz Majewski wrote: > Dear All, It is only Thierry that you need to ping. It goes thru his tree as I mentioned on another panel you sent. >> This commit adds support for AUO's 7.0" display. > > If I may gentle remind about this patch > >> >>

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Mon, May 14, 2018 at 6:58 PM, Pavel Machek wrote: > Hi! > >> > config CAN_PEAK_PCIEFD >> > depends on PCI >> > tristate "PEAK-System PCAN-PCIe FD cards" >> > ---help--- >> > This driver adds support for the PEAK-System PCI Express FD >> >

Re: [ANNOUNCE] Kconfiglib menuconfig implementation

On Mon, May 14, 2018 at 6:58 PM, Pavel Machek wrote: > Hi! > >> > config CAN_PEAK_PCIEFD >> > depends on PCI >> > tristate "PEAK-System PCAN-PCIe FD cards" >> > ---help--- >> > This driver adds support for the PEAK-System PCI Express FD >> > CAN-FD

Re: [PATCH RFC 3/8] rcu: Add back the cpuend tracepoint

On Sun, May 13, 2018 at 08:15:36PM -0700, Joel Fernandes (Google) wrote: > Commit be4b8beed87d ("rcu: Move RCU's grace-period-change code to ->gp_seq") > removed the cpuend grace period trace point. This patch adds it back. > > Signed-off-by: Joel Fernandes (Google) Good

Re: [PATCH RFC 3/8] rcu: Add back the cpuend tracepoint

On Sun, May 13, 2018 at 08:15:36PM -0700, Joel Fernandes (Google) wrote: > Commit be4b8beed87d ("rcu: Move RCU's grace-period-change code to ->gp_seq") > removed the cpuend grace period trace point. This patch adds it back. > > Signed-off-by: Joel Fernandes (Google) Good catch!!! I queued this

Re: [PATCH 01/18] kernel: Use pr_fmt

On Thu, May 10, 2018 at 08:45:27AM -0700, Joe Perches wrote: > Sometime in the future, it would be useful to convert pr_fmt from a > default simple define to use a default prefix with KBUILD_MODNAME. > > There are files in kernel/ that use pr_, some with an embedded > prefix, that also do not

Re: [PATCH 01/18] kernel: Use pr_fmt

On Thu, May 10, 2018 at 08:45:27AM -0700, Joe Perches wrote: > Sometime in the future, it would be useful to convert pr_fmt from a > default simple define to use a default prefix with KBUILD_MODNAME. > > There are files in kernel/ that use pr_, some with an embedded > prefix, that also do not

Re: INFO: rcu detected stall in kfree_skbmem

On Mon, May 14, 2018 at 9:34 PM, Neil Horman wrote: > On Fri, May 11, 2018 at 12:00:38PM +0200, Dmitry Vyukov wrote: >> On Mon, Apr 30, 2018 at 8:09 PM, syzbot >> wrote: >> > Hello, >> > >> > syzbot found the following

Re: INFO: rcu detected stall in kfree_skbmem

On Mon, May 14, 2018 at 9:34 PM, Neil Horman wrote: > On Fri, May 11, 2018 at 12:00:38PM +0200, Dmitry Vyukov wrote: >> On Mon, Apr 30, 2018 at 8:09 PM, syzbot >> wrote: >> > Hello, >> > >> > syzbot found the following crash on: >> > >> > HEAD commit:5d1365940a68 Merge >> >

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

On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the rdma tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/infiniband/hw/cxgb4/restrack.c: In function 'fill_res_qp_entry': >

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wrote: > This panel is marketed as Banana Pi 7" LCD display. On the back is > a sticker denoting the model name S070WV20-CT16. > > This is a 7" 800x480 panel connected through a 24-bit RGB interface. > However the panel only does 262k

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

On Mon, May 07, 2018 at 09:44:54AM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the rdma tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/infiniband/hw/cxgb4/restrack.c: In function 'fill_res_qp_entry': >

Re: [PATCH 4/6] drm/panel: simple: Add support for Banana Pi 7" S070WV20-CT16 panel

On Thu, Apr 19, 2018 at 3:02 PM, Chen-Yu Tsai wrote: > This panel is marketed as Banana Pi 7" LCD display. On the back is > a sticker denoting the model name S070WV20-CT16. > > This is a 7" 800x480 panel connected through a 24-bit RGB interface. > However the panel only does 262k colors. > >

Re: [PATCH 00/14] Modify action API for implementing lockless actions

On 14/05/18 10:27 AM, Vlad Buslov wrote: Currently, all netlink protocol handlers for updating rules, actions and qdiscs are protected with single global rtnl lock which removes any possibility for parallelism. This patch set is a first step to remove rtnl lock dependency from TC rules update

Re: [PATCH 00/14] Modify action API for implementing lockless actions

On 14/05/18 10:27 AM, Vlad Buslov wrote: Currently, all netlink protocol handlers for updating rules, actions and qdiscs are protected with single global rtnl lock which removes any possibility for parallelism. This patch set is a first step to remove rtnl lock dependency from TC rules update

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

On 05/14/2018 09:20 AM, Oleksandr Shamray wrote: Hi, Just a bit more Kconfig fixing below. > --- > Documentation/ioctl/ioctl-number.txt |2 + > MAINTAINERS | 10 ++ > drivers/Kconfig |2 + > drivers/Makefile |1 + >

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

On 05/14/2018 09:20 AM, Oleksandr Shamray wrote: Hi, Just a bit more Kconfig fixing below. > --- > Documentation/ioctl/ioctl-number.txt |2 + > MAINTAINERS | 10 ++ > drivers/Kconfig |2 + > drivers/Makefile |1 + >

Re: possible deadlock in sk_diag_fill

On Sat, May 12, 2018 at 09:46:25AM +0200, Dmitry Vyukov wrote: > On Fri, May 11, 2018 at 8:33 PM, Andrei Vagin wrote: > > On Sat, May 05, 2018 at 10:59:02AM -0700, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit:c1c07416cdd4

Re: possible deadlock in sk_diag_fill

On Sat, May 12, 2018 at 09:46:25AM +0200, Dmitry Vyukov wrote: > On Fri, May 11, 2018 at 8:33 PM, Andrei Vagin wrote: > > On Sat, May 05, 2018 at 10:59:02AM -0700, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit:c1c07416cdd4 Merge tag

Re: [PATCH RFC 5/8] rcu: Use rcu_node as temporary variable in funnel locking loop

On Sun, May 13, 2018 at 08:15:38PM -0700, Joel Fernandes (Google) wrote: > The funnel locking loop in rcu_start_this_gp uses rcu_root as a > temporary variable while walking the combining tree. This causes a > tiresome exercise of a code reader reminding themselves that rcu_root > may not be root.

Re: [PATCH RFC 5/8] rcu: Use rcu_node as temporary variable in funnel locking loop

On Sun, May 13, 2018 at 08:15:38PM -0700, Joel Fernandes (Google) wrote: > The funnel locking loop in rcu_start_this_gp uses rcu_root as a > temporary variable while walking the combining tree. This causes a > tiresome exercise of a code reader reminding themselves that rcu_root > may not be root.

Re: [PATCH RFC 4/8] rcu: Get rid of old c variable from places in tree RCU

On Sun, May 13, 2018 at 08:15:37PM -0700, Joel Fernandes (Google) wrote: > The 'c' variable was used previously to store the grace period > that is being requested. However it is not very meaningful for > a code reader, this patch replaces it with gp_seq_start indicating that Good catch, but how

Re: [PATCH RFC 4/8] rcu: Get rid of old c variable from places in tree RCU

On Sun, May 13, 2018 at 08:15:37PM -0700, Joel Fernandes (Google) wrote: > The 'c' variable was used previously to store the grace period > that is being requested. However it is not very meaningful for > a code reader, this patch replaces it with gp_seq_start indicating that Good catch, but how

Re: [PATCH RFC 01/19] kallsyms: Simplify update_iter_mod()

Em Thu, May 10, 2018 at 05:02:18PM +, Hunter, Adrian escreveu: > > -Original Message- > > From: Jiri Olsa [mailto:jo...@redhat.com] > > Sent: Thursday, May 10, 2018 4:02 PM > > To: Hunter, Adrian > > Cc: Thomas Gleixner ; Arnaldo Carvalho

Re: [PATCH RFC 01/19] kallsyms: Simplify update_iter_mod()

Em Thu, May 10, 2018 at 05:02:18PM +, Hunter, Adrian escreveu: > > -Original Message- > > From: Jiri Olsa [mailto:jo...@redhat.com] > > Sent: Thursday, May 10, 2018 4:02 PM > > To: Hunter, Adrian > > Cc: Thomas Gleixner ; Arnaldo Carvalho de Melo > > ; Ingo Molnar ; Peter Zijlstra > >

Re: [PATCH v5 2/2] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

On Thu, May 10, 2018 at 3:03 PM, Boris Brezillon wrote: >> +#define GET_BIT(bit, val) (((val) >> (bit)) & 0x01) > > Not sure we need that macro, see below. +1. We have too many nice helpers for bit manipulations (for_each_set_bit() as an example). >

Re: [PATCH v5 2/2] mtd: rawnand: use bit-wise majority to recover the contents of ONFI parameter

On Thu, May 10, 2018 at 3:03 PM, Boris Brezillon wrote: >> +#define GET_BIT(bit, val) (((val) >> (bit)) & 0x01) > > Not sure we need that macro, see below. +1. We have too many nice helpers for bit manipulations (for_each_set_bit() as an example). > for (k = 0; k <

Re: use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

> On May 14, 2018, at 8:52 AM, Dan Williams wrote: > > > I think "happy" is a strong word when it comes to x86 machine check > handling. My interpretation is that he and Andy acquiesced that this > is about the best we can do with dax+mce as things stand today.

Re: use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

> On May 14, 2018, at 8:52 AM, Dan Williams wrote: > > > I think "happy" is a strong word when it comes to x86 machine check > handling. My interpretation is that he and Andy acquiesced that this > is about the best we can do with dax+mce as things stand today. Agreed. I think it’s

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 10:25 AM, Deepa Dinamani wrote: > On Mon, May 14, 2018 at 9:30 AM, Kees Cook wrote: >> On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani >> wrote: >>> Kees mentioned that he wants to merge a patch to

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 10:25 AM, Deepa Dinamani wrote: > On Mon, May 14, 2018 at 9:30 AM, Kees Cook wrote: >> On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani >> wrote: >>> Kees mentioned that he wants to merge a patch to pstore that changes >>> it to use timespec64 internally for 4.17: >>>

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On 05/14/2018 10:20 AM, Gary R Hook wrote: > Implement a skeleton framework for debugfs support in the > AMD IOMMU. > > Signed-off-by: Gary R Hook > --- > drivers/iommu/Makefile|5 + > drivers/iommu/amd_iommu_debugfs.c | 39 >

Re: [PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

On 05/14/2018 10:20 AM, Gary R Hook wrote: > Implement a skeleton framework for debugfs support in the > AMD IOMMU. > > Signed-off-by: Gary R Hook > --- > drivers/iommu/Makefile|5 + > drivers/iommu/amd_iommu_debugfs.c | 39 > + >

Re: [PATCH net-next v8 0/3] kernel: add support to collect hardware logs in crash recovery kernel

From: ebied...@xmission.com (Eric W. Biederman) Date: Mon, 14 May 2018 08:11:24 -0500 > David Miller writes: > >> I'm deferring this patch series. >> >> If we can't get a reasonable review from an interested party in 10+ >> days, that is not reasonable. >> >> Resubmit this

Re: [PATCH net-next v8 0/3] kernel: add support to collect hardware logs in crash recovery kernel

From: ebied...@xmission.com (Eric W. Biederman) Date: Mon, 14 May 2018 08:11:24 -0500 > David Miller writes: > >> I'm deferring this patch series. >> >> If we can't get a reasonable review from an interested party in 10+ >> days, that is not reasonable. >> >> Resubmit this once someone reviews

Re: [PATCH] thermal: qcom: tsens: Allow number of sensors to come from DT

On Mon 14 May 07:45 PDT 2018, Amit Kucheria wrote: > On Tue, May 8, 2018 at 2:53 AM, Bjorn Andersson > wrote: > > For platforms that has multiple copies of the TSENS hardware block it's > > necessary to be able to specify the number of sensors per block in > >

Re: [PATCH] thermal: qcom: tsens: Allow number of sensors to come from DT

On Mon 14 May 07:45 PDT 2018, Amit Kucheria wrote: > On Tue, May 8, 2018 at 2:53 AM, Bjorn Andersson > wrote: > > For platforms that has multiple copies of the TSENS hardware block it's > > necessary to be able to specify the number of sensors per block in > > DeviceTree. > > I assume you want

Re: [PATCH 4.4 49/72] media: usbtv: prevent double free in error case

On Fri, 2018-04-06 at 15:23 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Oliver Neukum > > commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream. [...] > ---

Re: [PATCH 4.4 49/72] media: usbtv: prevent double free in error case

On Fri, 2018-04-06 at 15:23 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Oliver Neukum > > commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream. [...] > ---

Re: media: uvcvideo: Support realtek's UVC 1.5 device

I'm really sorry, but this message was originally meant to be sent (and was already also sent) to linux-media. Please ignore here. 2018-05-14 19:28 GMT+02:00 Josef Šimánek : > > > The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1. > > Change it to 48 for

Re: media: uvcvideo: Support realtek's UVC 1.5 device

I'm really sorry, but this message was originally meant to be sent (and was already also sent) to linux-media. Please ignore here. 2018-05-14 19:28 GMT+02:00 Josef Šimánek : > > > The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1. > > Change it to 48 for UVC 1.5 device, > > and

Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi

First of all, do not remove mailing lists from Cc and people if you are not sure they do not need your stuff. On Mon, May 14, 2018 at 11:11 AM, Radu Pirea wrote: > On Sun, 2018-05-13 at 16:33 +0300, Andy Shevchenko wrote: >> On Fri, May 11, 2018 at 1:38 PM, Radu Pirea

Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi

First of all, do not remove mailing lists from Cc and people if you are not sure they do not need your stuff. On Mon, May 14, 2018 at 11:11 AM, Radu Pirea wrote: > On Sun, 2018-05-13 at 16:33 +0300, Andy Shevchenko wrote: >> On Fri, May 11, 2018 at 1:38 PM, Radu Pirea > > wrote: >> > +static

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

> Il giorno 14 mag 2018, alle ore 19:31, Jens Axboe ha > scritto: > > On 5/14/18 11:16 AM, Paolo Valente wrote: >> >> >>> Il giorno 10 mag 2018, alle ore 18:14, Bart Van Assche >>> ha scritto: >>> >>> On Fri, 2018-05-04 at 19:17 +0200, Paolo

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

> Il giorno 14 mag 2018, alle ore 19:31, Jens Axboe ha > scritto: > > On 5/14/18 11:16 AM, Paolo Valente wrote: >> >> >>> Il giorno 10 mag 2018, alle ore 18:14, Bart Van Assche >>> ha scritto: >>> >>> On Fri, 2018-05-04 at 19:17 +0200, Paolo Valente wrote: When invoked for an I/O

Re: [PATCH RFC 1/8] rcu: Add comment documenting how rcu_seq_snap works

On Sun, May 13, 2018 at 08:15:34PM -0700, Joel Fernandes (Google) wrote: > rcu_seq_snap may be tricky for someone looking at it for the first time. > Lets document how it works with an example to make it easier. > > Signed-off-by: Joel Fernandes (Google) > --- >

Re: [PATCH RFC 1/8] rcu: Add comment documenting how rcu_seq_snap works

On Sun, May 13, 2018 at 08:15:34PM -0700, Joel Fernandes (Google) wrote: > rcu_seq_snap may be tricky for someone looking at it for the first time. > Lets document how it works with an example to make it easier. > > Signed-off-by: Joel Fernandes (Google) > --- > kernel/rcu/rcu.h | 24

Re: [PATCH 0/7] psi: pressure stall information for CPU, memory, and IO

On 05/14/18 08:39, Christopher Lameter wrote: On Mon, 7 May 2018, Johannes Weiner wrote: What to make of this number? If CPU utilization is at 100% and CPU pressure is 0, it means the system is perfectly utilized, with one runnable thread per CPU and nobody waiting. At two or more runnable

Re: [PATCH 0/7] psi: pressure stall information for CPU, memory, and IO

On 05/14/18 08:39, Christopher Lameter wrote: On Mon, 7 May 2018, Johannes Weiner wrote: What to make of this number? If CPU utilization is at 100% and CPU pressure is 0, it means the system is perfectly utilized, with one runnable thread per CPU and nobody waiting. At two or more runnable

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

On 5/14/18 11:16 AM, Paolo Valente wrote: > > >> Il giorno 10 mag 2018, alle ore 18:14, Bart Van Assche >> ha scritto: >> >> On Fri, 2018-05-04 at 19:17 +0200, Paolo Valente wrote: >>> When invoked for an I/O request rq, [ ... ] >> >> Tested-by: Bart Van Assche

Re: [PATCH BUGFIX] block, bfq: postpone rq preparation to insert or merge

On 5/14/18 11:16 AM, Paolo Valente wrote: > > >> Il giorno 10 mag 2018, alle ore 18:14, Bart Van Assche >> ha scritto: >> >> On Fri, 2018-05-04 at 19:17 +0200, Paolo Valente wrote: >>> When invoked for an I/O request rq, [ ... ] >> >> Tested-by: Bart Van Assche >> >> >> > > Any decision for

RE: media: uvcvideo: Support realtek's UVC 1.5 device

> The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1. > Change it to 48 for UVC 1.5 device, > and the UVC 1.5 device can be recognized. > > More changes to the driver are needed for full UVC 1.5 compatibility. > However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have >

[PATCH] mm: Add new vma flag VM_LOCAL_CPU

On a call to mmap an mmap provider (like an FS) can put this flag on vma->vm_flags. The VM_LOCAL_CPU flag tells the Kernel that the vma will be used from a single-core only, and therefore invalidation (flush_tlb) of PTE(s) need not be a wide CPU scheduling. The motivation of this flag is the

RE: media: uvcvideo: Support realtek's UVC 1.5 device

> The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1. > Change it to 48 for UVC 1.5 device, > and the UVC 1.5 device can be recognized. > > More changes to the driver are needed for full UVC 1.5 compatibility. > However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have >

[PATCH] mm: Add new vma flag VM_LOCAL_CPU

On a call to mmap an mmap provider (like an FS) can put this flag on vma->vm_flags. The VM_LOCAL_CPU flag tells the Kernel that the vma will be used from a single-core only, and therefore invalidation (flush_tlb) of PTE(s) need not be a wide CPU scheduling. The motivation of this flag is the

Re: CONFIG_KCOV causing crash in svm_vcpu_run()

On Mon, May 14, 2018 at 07:14:41AM +0200, Dmitry Vyukov wrote: > On Mon, May 14, 2018 at 5:02 AM, Eric Biggers wrote: > > Sorry, messed up address for KVM mailing list. See message below. > > > > On Sun, May 13, 2018 at 08:00:07PM -0700, Eric Biggers wrote: > >> With

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 9:30 AM, Kees Cook wrote: > On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani > wrote: >> Kees mentioned that he wants to merge a patch to pstore that changes >> it to use timespec64 internally for 4.17: >>

Re: CONFIG_KCOV causing crash in svm_vcpu_run()

On Mon, May 14, 2018 at 07:14:41AM +0200, Dmitry Vyukov wrote: > On Mon, May 14, 2018 at 5:02 AM, Eric Biggers wrote: > > Sorry, messed up address for KVM mailing list. See message below. > > > > On Sun, May 13, 2018 at 08:00:07PM -0700, Eric Biggers wrote: > >> With CONFIG_KCOV=y and an AMD

Re: [PATCH 6/6] vfs: change inode times to use struct timespec64

On Mon, May 14, 2018 at 9:30 AM, Kees Cook wrote: > On Sun, May 13, 2018 at 9:05 PM, Deepa Dinamani > wrote: >> Kees mentioned that he wants to merge a patch to pstore that changes >> it to use timespec64 internally for 4.17: >> https://lkml.org/lkml/2018/5/13/3 > > I'm still working on a v2

[PATCH] KVM: fix spelling mistake: "cop_unsuable" -> "cop_unusable"

From: Colin Ian King Trivial fix to spelling mistake in debugfs_entries text Signed-off-by: Colin Ian King --- arch/mips/kvm/mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kvm/mips.c

[PATCH] KVM: fix spelling mistake: "cop_unsuable" -> "cop_unusable"

From: Colin Ian King Trivial fix to spelling mistake in debugfs_entries text Signed-off-by: Colin Ian King --- arch/mips/kvm/mips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 2549fdd27ee1..0f725e9cee8f 100644 ---

Re: serial: custom baud rate

On Thu, May 3, 2018 at 8:54 PM, Theodore Y. Ts'o wrote: > On Thu, May 03, 2018 at 06:09:13PM +0530, Muni Sekhar wrote: > See the setserial man page:t > > https://linux.die.net/man/8/setserial > > Not all serial devices support the spd_cust and divisor, however. In >

Re: serial: custom baud rate

On Thu, May 3, 2018 at 8:54 PM, Theodore Y. Ts'o wrote: > On Thu, May 03, 2018 at 06:09:13PM +0530, Muni Sekhar wrote: > See the setserial man page:t > > https://linux.die.net/man/8/setserial > > Not all serial devices support the spd_cust and divisor, however. In > general Oh, please,

[PATCH v7 1/2] iommu - Enable debugfs exposure of IOMMU driver internals

Provide base enablement for using debugfs to expose internal data of an IOMMU driver. When called, create the /sys/kernel/debug/iommu directory. Emit a strong warning at boot time to indicate that this feature is enabled. This function is called from iommu_init, and creates the initial DebugFS

[PATCH v7 1/2] iommu - Enable debugfs exposure of IOMMU driver internals

Provide base enablement for using debugfs to expose internal data of an IOMMU driver. When called, create the /sys/kernel/debug/iommu directory. Emit a strong warning at boot time to indicate that this feature is enabled. This function is called from iommu_init, and creates the initial DebugFS

[PATCH v7 0/2] Base enablement of IOMMU debugfs support

These patches create a top-level function, called at IOMMU initialization, to create a debugfs directory for the IOMMU. Under this directory drivers may create and populate-specific directories for their device internals. Patch 1: general IOMMU enablement Patch 2: basic AMD enablement to

[PATCH v7 0/2] Base enablement of IOMMU debugfs support

These patches create a top-level function, called at IOMMU initialization, to create a debugfs directory for the IOMMU. Under this directory drivers may create and populate-specific directories for their device internals. Patch 1: general IOMMU enablement Patch 2: basic AMD enablement to

[PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

Implement a skeleton framework for debugfs support in the AMD IOMMU. Signed-off-by: Gary R Hook --- drivers/iommu/Makefile|5 + drivers/iommu/amd_iommu_debugfs.c | 39 + drivers/iommu/amd_iommu_init.c|6 --

[PATCH v7 2/2] iommu/amd: Add basic debugfs infrastructure for AMD IOMMU

Implement a skeleton framework for debugfs support in the AMD IOMMU. Signed-off-by: Gary R Hook --- drivers/iommu/Makefile|5 + drivers/iommu/amd_iommu_debugfs.c | 39 + drivers/iommu/amd_iommu_init.c|6 --

Re: [PATCH RFC 2/8] rcu: Clarify usage of cond_resched for tasks-RCU

On Mon, May 14, 2018 at 10:54:54AM -0400, Steven Rostedt wrote: > On Sun, 13 May 2018 20:15:35 -0700 > "Joel Fernandes (Google)" wrote: > > > Recently we had a discussion about cond_resched unconditionally > > recording a voluntary context switch [1]. > > > > Lets add a

Re: [PATCH RFC 2/8] rcu: Clarify usage of cond_resched for tasks-RCU

On Mon, May 14, 2018 at 10:54:54AM -0400, Steven Rostedt wrote: > On Sun, 13 May 2018 20:15:35 -0700 > "Joel Fernandes (Google)" wrote: > > > Recently we had a discussion about cond_resched unconditionally > > recording a voluntary context switch [1]. > > > > Lets add a comment clarifying that

[PATCH v2] coresight: documentation: update sysfs section

- Align and show updated ls devices output from the TC2, based on current driver - Provide an example from an ETMv4 based system (Juno) - Reflect changes to the way the RAM write pointer is accessed since it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS management

[PATCH v2] coresight: documentation: update sysfs section

- Align and show updated ls devices output from the TC2, based on current driver - Provide an example from an ETMv4 based system (Juno) - Reflect changes to the way the RAM write pointer is accessed since it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS management

[RFC PATCH 02/11] arm64: Move arch-specific prctls out of core code

This patch moves the arm64-specific prctl call implementations out of core code and removes redundant boilerplate associated with them. No functional change. Signed-off-by: Dave Martin Cc: Catalin Marinas Cc: Will Deacon ---

[RFC PATCH 02/11] arm64: Move arch-specific prctls out of core code

This patch moves the arm64-specific prctl call implementations out of core code and removes redundant boilerplate associated with them. No functional change. Signed-off-by: Dave Martin Cc: Catalin Marinas Cc: Will Deacon --- arch/arm64/Kconfig | 1 +

<    6   7   8   9   10   11   12   13   14   15   >