Re: [PATCH 5/9] treewide: use kv[mz]alloc* rather than opencoded variants

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko There are many code paths opencoding kvmalloc. Let's use the helper instead. The main difference to kvmalloc is that those users are usually not considering all the aspects of the memory allocator. E.g. allocation

Re: [PATCH 5/9] treewide: use kv[mz]alloc* rather than opencoded variants

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko There are many code paths opencoding kvmalloc. Let's use the helper instead. The main difference to kvmalloc is that those users are usually not considering all the aspects of the memory allocator. E.g. allocation requests <= 32kB

Re: [PATCH] drm: mali-dp: add custom plane ->reset hook

On Mon, Jan 30, 2017 at 03:42:26PM +, Mihail Atanassov wrote: > The reset hook needs to allocate space for a > malidp_plane_state, which is larger than drm_plane_state. > Otherwise, the hook is identical to the default one. > > Signed-off-by: Mihail Atanassov

Re: [PATCH] drm: mali-dp: add custom plane ->reset hook

On Mon, Jan 30, 2017 at 03:42:26PM +, Mihail Atanassov wrote: > The reset hook needs to allocate space for a > malidp_plane_state, which is larger than drm_plane_state. > Otherwise, the hook is identical to the default one. > > Signed-off-by: Mihail Atanassov Acked-by: Liviu Dudau Thanks,

Re: Device or HBA level QD throttling creates randomness in sequetial workload

On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: > - if (atomic_inc_return(>fw_outstanding) > > - instance->host->can_queue) { > - atomic_dec(>fw_outstanding); > - return SCSI_MLQUEUE_HOST_BUSY; > - } > + if (atomic_inc_return(>fw_outstanding) > safe_can_queue) {

Re: Device or HBA level QD throttling creates randomness in sequetial workload

On Mon, 2017-01-30 at 19:22 +0530, Kashyap Desai wrote: > - if (atomic_inc_return(>fw_outstanding) > > - instance->host->can_queue) { > - atomic_dec(>fw_outstanding); > - return SCSI_MLQUEUE_HOST_BUSY; > - } > + if (atomic_inc_return(>fw_outstanding) > safe_can_queue) {

Re: [PATCH 2/8] pinctrl: stm32: use gpio-ranges to declare bank range

Hi Linus, On 01/30/2017 04:19 PM, Linus Walleij wrote: On Fri, Jan 27, 2017 at 5:15 PM, Alexandre TORGUE wrote: Use device tree entries to declare gpio range. It will allow to use no contiguous gpio bank and holes inside a bank. Signed-off-by: Alexandre TORGUE

Re: [PATCH 2/8] pinctrl: stm32: use gpio-ranges to declare bank range

Hi Linus, On 01/30/2017 04:19 PM, Linus Walleij wrote: On Fri, Jan 27, 2017 at 5:15 PM, Alexandre TORGUE wrote: Use device tree entries to declare gpio range. It will allow to use no contiguous gpio bank and holes inside a bank. Signed-off-by: Alexandre TORGUE (...) +

Re: [PATCH 0/6 v3] kvmalloc

On Mon 30-01-17 17:15:08, Daniel Borkmann wrote: > On 01/30/2017 08:56 AM, Michal Hocko wrote: > > On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: > > > On 01/27/2017 11:05 AM, Michal Hocko wrote: > > > > On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: > > [...] > > > > > So to answer your

Re: [PATCH 0/6 v3] kvmalloc

On Mon 30-01-17 17:15:08, Daniel Borkmann wrote: > On 01/30/2017 08:56 AM, Michal Hocko wrote: > > On Fri 27-01-17 21:12:26, Daniel Borkmann wrote: > > > On 01/27/2017 11:05 AM, Michal Hocko wrote: > > > > On Thu 26-01-17 21:34:04, Daniel Borkmann wrote: > > [...] > > > > > So to answer your

[PATCH] PCI: ACPI: Fix ThunderX PEM initialization

This patch is to address PEM initialization issue which causes network issues. It is necessary to search for _HID:PNP0A08 while requesting PEM resources via ACPI instead of "THRX0002". Signed-off-by: Vadim Lomovtsev --- drivers/pci/host/pci-thunder-pem.c | 2

[PATCH] PCI: ACPI: Fix ThunderX PEM initialization

This patch is to address PEM initialization issue which causes network issues. It is necessary to search for _HID:PNP0A08 while requesting PEM resources via ACPI instead of "THRX0002". Signed-off-by: Vadim Lomovtsev --- drivers/pci/host/pci-thunder-pem.c | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Em Mon, 16 Jan 2017 21:13:58 +0100 Pavel Machek escreveu: > Hi! > > > On 16.01.2017 12:10, Sean Young wrote: > > > > > >Have you had a chance to test the ir-rx51 changes? > > > > > >Thanks > > >Sean > > > > > > > Still no, and afaik there are issues booting n900 with current

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

Em Mon, 16 Jan 2017 21:13:58 +0100 Pavel Machek escreveu: > Hi! > > > On 16.01.2017 12:10, Sean Young wrote: > > > > > >Have you had a chance to test the ir-rx51 changes? > > > > > >Thanks > > >Sean > > > > > > > Still no, and afaik there are issues booting n900 with current kernel. Will >

Re: [PATCH] PCI: Apply _HPX settings only to relevant devices

On Thu, Jan 12, 2017 at 02:32:04PM -0600, Bjorn Helgaas wrote: > Previously we didn't check the type of device before trying to apply Type 1 > (PCI-X) or Type 2 (PCIe) Setting Records from _HPX. > > We don't support PCI-X Setting Records, so this was harmless, but the > warning was useless. > >

Re: [PATCH] PCI: Apply _HPX settings only to relevant devices

On Thu, Jan 12, 2017 at 02:32:04PM -0600, Bjorn Helgaas wrote: > Previously we didn't check the type of device before trying to apply Type 1 > (PCI-X) or Type 2 (PCIe) Setting Records from _HPX. > > We don't support PCI-X Setting Records, so this was harmless, but the > warning was useless. > >

Re: [PATCH] video/mbx: use simple_open()

Hi, On Friday, January 20, 2017 10:27:05 PM Geliang Tang wrote: > Drop open_file_generic(), use simple_open() instead of it. > > Signed-off-by: Geliang Tang Thanks, patch queued for 4.11. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung

Re: [PATCH] video/mbx: use simple_open()

Hi, On Friday, January 20, 2017 10:27:05 PM Geliang Tang wrote: > Drop open_file_generic(), use simple_open() instead of it. > > Signed-off-by: Geliang Tang Thanks, patch queued for 4.11. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics > --- >

Re: [PATCH] gianfar: synchronize DMA API usage by free_skb_rx_queue w/ gfar_new_page

From: Arseny Solokha Date: Sun, 29 Jan 2017 19:52:20 +0700 > From: Arseny Solokha > > In spite of switching to paged allocation of Rx buffers, the driver still > called dma_unmap_single() in the Rx queues tear-down path. > > The DMA region unmapping

Re: [PATCH] gianfar: synchronize DMA API usage by free_skb_rx_queue w/ gfar_new_page

From: Arseny Solokha Date: Sun, 29 Jan 2017 19:52:20 +0700 > From: Arseny Solokha > > In spite of switching to paged allocation of Rx buffers, the driver still > called dma_unmap_single() in the Rx queues tear-down path. > > The DMA region unmapping code in free_skb_rx_queue() basically

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote: > On 1/27/2017 5:04 PM, James Bottomley wrote: > > > > Beware the nasty corner case: > > > > > > - Application asks for a session and gets 0200 > > > > > > - Time elapses and 0200 gets forcibly flushed > > > > > > - Later, app comes

Re: [tpmdd-devel] [RFC] tpm2-space: add handling for global session exhaustion

On Sun, 2017-01-29 at 19:52 -0500, Ken Goldman wrote: > On 1/27/2017 5:04 PM, James Bottomley wrote: > > > > Beware the nasty corner case: > > > > > > - Application asks for a session and gets 0200 > > > > > > - Time elapses and 0200 gets forcibly flushed > > > > > > - Later, app comes

Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states

Hi Lee, On Mon, 30 Jan 2017, Lee Jones wrote: > On Mon, 30 Jan 2017, Peter Griffin wrote: > > > Hi Lee, > > > > On Fri, 27 Jan 2017, Lee Jones wrote: > > > > > On Wed, 25 Jan 2017, Peter Griffin wrote: > > > > > > > Hi Lee, > > > > > > > > On Tue, 24 Jan 2017, Lee Jones wrote: > > > > > >

Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states

Hi Lee, On Mon, 30 Jan 2017, Lee Jones wrote: > On Mon, 30 Jan 2017, Peter Griffin wrote: > > > Hi Lee, > > > > On Fri, 27 Jan 2017, Lee Jones wrote: > > > > > On Wed, 25 Jan 2017, Peter Griffin wrote: > > > > > > > Hi Lee, > > > > > > > > On Tue, 24 Jan 2017, Lee Jones wrote: > > > > > >

Re: [PATCH V3 1/1] percpu-refcount: fix reference leak during percpu-atomic transition

Acked-by: Christoph Lameter

Re: [PATCH V3 1/1] percpu-refcount: fix reference leak during percpu-atomic transition

Acked-by: Christoph Lameter

Re: [PATCH] Pinctrl : berlin - Fix possible NULL derefrence.

On Fri, Jan 27, 2017 at 12:10 PM, Shailendra Verma wrote: > of_match_device could return NULL, and so can cause a NULL > pointer dereference later. > > Signed-off-by: Shailendra Verma Patch applied. Yours, Linus Walleij

Re: [PATCH] Pinctrl : berlin - Fix possible NULL derefrence.

On Fri, Jan 27, 2017 at 12:10 PM, Shailendra Verma wrote: > of_match_device could return NULL, and so can cause a NULL > pointer dereference later. > > Signed-off-by: Shailendra Verma Patch applied. Yours, Linus Walleij

Re: [PATCH v1] video : fbdev : stifb :- Handle return NULL error from ioremap_nocache.

Hi, On Wednesday, January 18, 2017 03:51:51 PM Arvind Yadav wrote: > Here, If ioremap_nocache will fail. It will return NULL. > Kernel can run into a NULL-pointer dereference. > This error check will avoid NULL pointer dereference. > > Signed-off-by: Arvind Yadav

Re: [PATCH v1] video : fbdev : stifb :- Handle return NULL error from ioremap_nocache.

Hi, On Wednesday, January 18, 2017 03:51:51 PM Arvind Yadav wrote: > Here, If ioremap_nocache will fail. It will return NULL. > Kernel can run into a NULL-pointer dereference. > This error check will avoid NULL pointer dereference. > > Signed-off-by: Arvind Yadav Thanks, I queued your patch

Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR

On Mon, Jan 30, 2017 at 02:04:46PM +0100, Thomas Gleixner wrote: > > The AMD-Manual from 12/16 does not mention that MSR. I do not have > > access to an AMD machine. But i can only assume that bigger machines > > also suffer from async TSCs and basically all fall back to HPET. > > Borislav? So

Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR

On Mon, Jan 30, 2017 at 02:04:46PM +0100, Thomas Gleixner wrote: > > The AMD-Manual from 12/16 does not mention that MSR. I do not have > > access to an AMD machine. But i can only assume that bigger machines > > also suffer from async TSCs and basically all fall back to HPET. > > Borislav? So

[PATCH] drm: mali-dp: add custom plane ->reset hook

The reset hook needs to allocate space for a malidp_plane_state, which is larger than drm_plane_state. Otherwise, the hook is identical to the default one. Signed-off-by: Mihail Atanassov --- drivers/gpu/drm/arm/malidp_planes.c | 23 ++- 1 file

[PATCH] drm: mali-dp: add custom plane ->reset hook

The reset hook needs to allocate space for a malidp_plane_state, which is larger than drm_plane_state. Otherwise, the hook is identical to the default one. Signed-off-by: Mihail Atanassov --- drivers/gpu/drm/arm/malidp_planes.c | 23 ++- 1 file changed, 22 insertions(+), 1

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

On Mon, Jan 30, 2017 at 03:56:49PM +0100, Frederic Weisbecker wrote: > On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote: > > On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > > > Now lets admit one drawback: s390 and powerpc with > > >

Re: [GIT PULL] cputime: Convert core use of cputime_t to nsecs

On Mon, Jan 30, 2017 at 03:56:49PM +0100, Frederic Weisbecker wrote: > On Mon, Jan 30, 2017 at 03:32:24PM +0100, Stanislaw Gruszka wrote: > > On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > > > Now lets admit one drawback: s390 and powerpc with > > >

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Sun, Jan 29, 2017 at 6:22 PM, Vlastimil Babka wrote: > On 29.1.2017 13:44, Dmitry Vyukov wrote: >> Hello, >> >> I've got the following deadlock report while running syzkaller fuzzer >> on f37208bc3c9c2f811460ef264909dfbc7f605a60: >> >> [ INFO: possible circular locking

Re: mm: deadlock between get_online_cpus/pcpu_alloc

On Sun, Jan 29, 2017 at 6:22 PM, Vlastimil Babka wrote: > On 29.1.2017 13:44, Dmitry Vyukov wrote: >> Hello, >> >> I've got the following deadlock report while running syzkaller fuzzer >> on f37208bc3c9c2f811460ef264909dfbc7f605a60: >> >> [ INFO: possible circular locking dependency detected ] >>

[PATCH 08/15] phy: qcom-ufs: Don't kfree devres resource

From: Bjorn Andersson Upon failing to acquire regulator supplies the qcom-ufs driver calls kfree() on the devm allocated memory used to store the name of the regulator, leading to devres corruption. Rather than switching to using the appropriate free function the

[PATCH 08/15] phy: qcom-ufs: Don't kfree devres resource

From: Bjorn Andersson Upon failing to acquire regulator supplies the qcom-ufs driver calls kfree() on the devm allocated memory used to store the name of the regulator, leading to devres corruption. Rather than switching to using the appropriate free function the patch acknowledge the fact that

Re: [PATCHv2] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Tue, Jan 24, 2017 at 11:24:51PM +, Abel Vesa wrote: > The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace > operation to specify if registers need to saved/restored by the ftrace > handler. > This is needed by kgraft and possibly other ftrace-based tools, and the ARM

Re: [PATCHv2] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

On Tue, Jan 24, 2017 at 11:24:51PM +, Abel Vesa wrote: > The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace > operation to specify if registers need to saved/restored by the ftrace > handler. > This is needed by kgraft and possibly other ftrace-based tools, and the ARM

[PATCH v2 5/5] iio: adc: stm32: add exti gpio trigger source

STM32F4 ADC can use exti11 (gpio) signal as trigger source for conversions. Signed-off-by: Fabrice Gasnier --- drivers/iio/adc/stm32-adc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index

[PATCH v2 5/5] iio: adc: stm32: add exti gpio trigger source

STM32F4 ADC can use exti11 (gpio) signal as trigger source for conversions. Signed-off-by: Fabrice Gasnier --- drivers/iio/adc/stm32-adc.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c index be0e457..0118c9c 100644 ---

Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer

On Thu, Jan 26, 2017 at 08:04:53PM -0500, Jintack Lim wrote: > Now that we have a separate structure for timer context, make functions > general so that they can work with any timer context, not just the > virtual timer context. This does not change the virtual timer > functionality. > >

Re: [RFC v2 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer

On Thu, Jan 26, 2017 at 08:04:53PM -0500, Jintack Lim wrote: > Now that we have a separate structure for timer context, make functions > general so that they can work with any timer context, not just the > virtual timer context. This does not change the virtual timer > functionality. > >

[PATCH v4 2/2] prctl: propagate has_child_subreaper flag to every descendant

If process forks some children when it has is_child_subreaper flag enabled they will inherit has_child_subreaper flag - first group, when is_child_subreaper is disabled forked children will not inherit it - second group. So child-subreaper does not reparent all his descendants when their parents

[PATCH v4 2/2] prctl: propagate has_child_subreaper flag to every descendant

If process forks some children when it has is_child_subreaper flag enabled they will inherit has_child_subreaper flag - first group, when is_child_subreaper is disabled forked children will not inherit it - second group. So child-subreaper does not reparent all his descendants when their parents

Re: [PATCH v4 1/2] mm/migration: make isolate_movable_page always defined

On Mon 30-01-17 22:59:52, Yisheng Xie wrote: > Hi， Michal， > Sorry for late reply. > > On 01/26/2017 05:18 PM, Michal Hocko wrote: > > On Wed 25-01-17 23:05:37, ys...@foxmail.com wrote: > >> From: Yisheng Xie > >> > >> Define isolate_movable_page as a static inline

Re: [PATCH v4 1/2] mm/migration: make isolate_movable_page always defined

On Mon 30-01-17 22:59:52, Yisheng Xie wrote: > Hi， Michal， > Sorry for late reply. > > On 01/26/2017 05:18 PM, Michal Hocko wrote: > > On Wed 25-01-17 23:05:37, ys...@foxmail.com wrote: > >> From: Yisheng Xie > >> > >> Define isolate_movable_page as a static inline function when > >>

Re: [PATCH v3 04/24] drm/rockchip: dw-mipi-dsi: fix command header writes

On Sun, Jan 29, 2017 at 01:24:24PM +, John Keeping wrote: > In a couple of places here we use "val" for the value that is about to > be written to a register but then reuse the same variable for the value > of a status register before we get around to writing it. Rename the > value to be

Re: [PATCH v3 04/24] drm/rockchip: dw-mipi-dsi: fix command header writes

On Sun, Jan 29, 2017 at 01:24:24PM +, John Keeping wrote: > In a couple of places here we use "val" for the value that is about to > be written to a register but then reuse the same variable for the value > of a status register before we get around to writing it. Rename the > value to be

[PATCH 0/2] gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper

Hello Linus, I send these 2 patches separately from the Atmel NAND driver rework since these are self-contained and do not have any external dependencies. Feel free to apply them in your tree if you are happy with this version and once other subsystem maintainers have acked patch 1. Thanks,

[PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

Rename devm_get_gpiod_from_child() into devm_fwnode_get_gpiod_from_child() to reflect the fact that this function is operating on a fwnode object. Signed-off-by: Boris Brezillon --- drivers/gpio/devres.c | 11 ++-

[PATCH 0/2] gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper

Hello Linus, I send these 2 patches separately from the Atmel NAND driver rework since these are self-contained and do not have any external dependencies. Feel free to apply them in your tree if you are happy with this version and once other subsystem maintainers have acked patch 1. Thanks,

[PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()

Rename devm_get_gpiod_from_child() into devm_fwnode_get_gpiod_from_child() to reflect the fact that this function is operating on a fwnode object. Signed-off-by: Boris Brezillon --- drivers/gpio/devres.c | 11 ++- drivers/input/keyboard/gpio_keys.c| 3 ++-

Re: [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote: > The PCI core will write to the bridge window config multiple times > while they are enabled. This can lead to mbus failures like: > > mvebu_mbus: cannot add window '4:e8', conflicts with another window > mvebu-pcie

Re: [PATCH v4 2/2] ceph: switch DIO code to use iov_iter_get_pages_alloc

On Fri, 2017-01-27 at 08:24 -0500, Jeff Layton wrote: > xfstest generic/095 triggers soft lockups in kcephfs. It uses fio to > drive some I/O via vmsplice ane splice. Ceph then ends up trying to > access an ITER_BVEC type iov_iter as a ITER_IOVEC one. That causes it to > pick up a wrong offset and

Re: [PATCH] PCI: mvebu: Handle changes to the bridge windows while enabled

On Mon, Dec 12, 2016 at 11:30:20AM -0700, Jason Gunthorpe wrote: > The PCI core will write to the bridge window config multiple times > while they are enabled. This can lead to mbus failures like: > > mvebu_mbus: cannot add window '4:e8', conflicts with another window > mvebu-pcie

Re: [PATCH v4 2/2] ceph: switch DIO code to use iov_iter_get_pages_alloc

On Fri, 2017-01-27 at 08:24 -0500, Jeff Layton wrote: > xfstest generic/095 triggers soft lockups in kcephfs. It uses fio to > drive some I/O via vmsplice ane splice. Ceph then ends up trying to > access an ITER_BVEC type iov_iter as a ITER_IOVEC one. That causes it to > pick up a wrong offset and

[PATCH 2/2] gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper

devm_fwnode_get_gpiod_from_child() currently allows GPIO users to request a GPIO that is defined in a child fwnode instead of directly in the device fwnode. Extend this API by adding the devm_fwnode_get_index_gpiod_from_child() helper which does the same except you can also specify an index in

[PATCH 2/2] gpio: Add the devm_fwnode_get_index_gpiod_from_child() helper

devm_fwnode_get_gpiod_from_child() currently allows GPIO users to request a GPIO that is defined in a child fwnode instead of directly in the device fwnode. Extend this API by adding the devm_fwnode_get_index_gpiod_from_child() helper which does the same except you can also specify an index in

Re: [PATCH v3 02/24] drm/rockchip: dw-mipi-dsi: pass mode in where needed

On Sun, Jan 29, 2017 at 01:24:22PM +, John Keeping wrote: > This shows that we only use the mode from the enable function and > prepares us to remove the "mode" field and the mode_set hook in the next > commit. > Reviewed-by: Sean Paul > Signed-off-by: John Keeping

Re: [PATCH v3 02/24] drm/rockchip: dw-mipi-dsi: pass mode in where needed

On Sun, Jan 29, 2017 at 01:24:22PM +, John Keeping wrote: > This shows that we only use the mode from the enable function and > prepares us to remove the "mode" field and the mode_set hook in the next > commit. > Reviewed-by: Sean Paul > Signed-off-by: John Keeping > Reviewed-by: Chris

Re: [PATCH v3 03/24] drm/rockchip: dw-mipi-dsi: remove mode_set hook

On Sun, Jan 29, 2017 at 01:24:23PM +, John Keeping wrote: > This is not needed since we can access the mode via the CRTC from the > enable hook. Also remove the "mode" field that is no longer used. > Reviewed-by: Sean Paul > Signed-off-by: John Keeping

Re: [PATCH v3 03/24] drm/rockchip: dw-mipi-dsi: remove mode_set hook

On Sun, Jan 29, 2017 at 01:24:23PM +, John Keeping wrote: > This is not needed since we can access the mode via the CRTC from the > enable hook. Also remove the "mode" field that is no longer used. > Reviewed-by: Sean Paul > Signed-off-by: John Keeping > Reviewed-by: Chris Zhong > --- >

Re: [PATCH 1/3] pinctrl: intel: Add support for hardware debouncer

On Mon, Jan 30, 2017 at 03:03:32PM +0100, Linus Walleij wrote: > On Fri, Jan 27, 2017 at 11:07 AM, Mika Westerberg > wrote: > > > The next generation Intel GPIO hardware has two additional registers > > PADCFG2 and PADCFG3. The latter is marked as reserved but

Re: [PATCH 1/3] pinctrl: intel: Add support for hardware debouncer

On Mon, Jan 30, 2017 at 03:03:32PM +0100, Linus Walleij wrote: > On Fri, Jan 27, 2017 at 11:07 AM, Mika Westerberg > wrote: > > > The next generation Intel GPIO hardware has two additional registers > > PADCFG2 and PADCFG3. The latter is marked as reserved but the former > > includes

Re: [PATCH 04/14] x86/fpu: Remove 'kbuf' parameter from the copy_xstate_to_user() APIs

On Mon, Jan 30, 2017 at 10:57:28AM +0100, Ingo Molnar wrote: > Would anyone object to using u32 in these prototypes? Well, would there be any disadvantage to forcing them to u32? Potentially by something else wanting to use those interfaces besides the regset thing and that something else doesn't

Re: [PATCH 04/14] x86/fpu: Remove 'kbuf' parameter from the copy_xstate_to_user() APIs

On Mon, Jan 30, 2017 at 10:57:28AM +0100, Ingo Molnar wrote: > Would anyone object to using u32 in these prototypes? Well, would there be any disadvantage to forcing them to u32? Potentially by something else wanting to use those interfaces besides the regset thing and that something else doesn't

Re: [PATCH 08/37] cputime: Convert task/group cputime to nsecs

On Mon, Jan 30, 2017 at 02:54:51PM +0100, Stanislaw Gruszka wrote: > On Sat, Jan 28, 2017 at 04:28:13PM +0100, Frederic Weisbecker wrote: > > On Sat, Jan 28, 2017 at 12:57:40PM +0100, Stanislaw Gruszka wrote: > > > On 32 bit architectures 64bit store/load is not atomic and if not > > > protected -

Re: [PATCH 08/37] cputime: Convert task/group cputime to nsecs

On Mon, Jan 30, 2017 at 02:54:51PM +0100, Stanislaw Gruszka wrote: > On Sat, Jan 28, 2017 at 04:28:13PM +0100, Frederic Weisbecker wrote: > > On Sat, Jan 28, 2017 at 12:57:40PM +0100, Stanislaw Gruszka wrote: > > > On 32 bit architectures 64bit store/load is not atomic and if not > > > protected -

Re: [PATCH 2/2] gpio: mcp23s08: add pinconf support

On Fri, Jan 27, 2017 at 3:47 PM, Sebastian Reichel wrote: > mcp23xxx device have configurable 100k pullup resistors. This adds > support for enabling them using pinctrl's pinconf interface. > > Signed-off-by: Sebastian Reichel That's the right approach! >

Re: [PATCH 2/2] gpio: mcp23s08: add pinconf support

On Fri, Jan 27, 2017 at 3:47 PM, Sebastian Reichel wrote: > mcp23xxx device have configurable 100k pullup resistors. This adds > support for enabling them using pinctrl's pinconf interface. > > Signed-off-by: Sebastian Reichel That's the right approach! > diff --git

Re: [PATCH RESEND 0/2] DEC frame buffer modular driver cleanups

Hi, On Thursday, January 12, 2017 12:54:57 PM Maciej W. Rozycki wrote: > Hi, > > This is a pair of small cleanups for `__init' annotation issues in PMAG-B > and PMAGB-B frame buffer drivers discovered in a modular build, which is a > seldom used, but supported configuration. > > Resending

Re: [PATCH RESEND 0/2] DEC frame buffer modular driver cleanups

Hi, On Thursday, January 12, 2017 12:54:57 PM Maciej W. Rozycki wrote: > Hi, > > This is a pair of small cleanups for `__init' annotation issues in PMAG-B > and PMAGB-B frame buffer drivers discovered in a modular build, which is a > seldom used, but supported configuration. > > Resending

Re: [PATCH v3 01/24] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

On Sun, Jan 29, 2017 at 01:24:21PM +, John Keeping wrote: > With atomic modesetting the hardware will be powered off when the > mode_set function is called. We should configure the hardware in the > enable function, which is the atomic version of "commit" so let's use > the enable hook rather

Re: [PATCH v3 01/24] drm/rockchip: dw-mipi-dsi: don't configure hardware in mode_set for MIPI

On Sun, Jan 29, 2017 at 01:24:21PM +, John Keeping wrote: > With atomic modesetting the hardware will be powered off when the > mode_set function is called. We should configure the hardware in the > enable function, which is the atomic version of "commit" so let's use > the enable hook rather

[PATCH 2/5] iio: adc: stm32: add dt option to set default trigger polarity

STM32 ADC trigger polarity can be set to either rising, falling or both edges. Add dt option to configure it. Note: default value may be overridden later via trigger_polarity sysfs attribute. Signed-off-by: Fabrice Gasnier --- drivers/iio/adc/stm32-adc.c | 7 +++ 1

Re: [PATCH v5 06/12] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality

Hi Ulf, On 2017/1/30 16:41, Ulf Hansson wrote: > [...] > + */ +static int xenon_child_node_of_parse(struct platform_device *pdev) +{ + struct device_node *np = pdev->dev.of_node; + struct sdhci_host *host = platform_get_drvdata(pdev); + struct

[PATCH 2/5] iio: adc: stm32: add dt option to set default trigger polarity

STM32 ADC trigger polarity can be set to either rising, falling or both edges. Add dt option to configure it. Note: default value may be overridden later via trigger_polarity sysfs attribute. Signed-off-by: Fabrice Gasnier --- drivers/iio/adc/stm32-adc.c | 7 +++ 1 file changed, 7

Re: [PATCH v5 06/12] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality

Hi Ulf, On 2017/1/30 16:41, Ulf Hansson wrote: > [...] > + */ +static int xenon_child_node_of_parse(struct platform_device *pdev) +{ + struct device_node *np = pdev->dev.of_node; + struct sdhci_host *host = platform_get_drvdata(pdev); + struct

Re: [PATCH v3 24/24] drm/rockchip: dw-mipi-dsi: support read commands

On Sun, Jan 29, 2017 at 01:24:44PM +, John Keeping wrote: > I haven't found any method for getting the length of a response, so this > just uses the requested rx_len > > Signed-off-by: John Keeping > --- > v3: > - Fix checkpatch warnings > Unchanged in v2 > >

Re: [PATCH v3 24/24] drm/rockchip: dw-mipi-dsi: support read commands

On Sun, Jan 29, 2017 at 01:24:44PM +, John Keeping wrote: > I haven't found any method for getting the length of a response, so this > just uses the requested rx_len > > Signed-off-by: John Keeping > --- > v3: > - Fix checkpatch warnings > Unchanged in v2 > >

Re: [PATCH] Pinctrl: mvebu - Fix possible NULL derefrence.

On Mon, Jan 30, 2017 at 9:24 AM, Thomas Petazzoni wrote: > On Mon, 30 Jan 2017 10:21:43 +0530, Shailendra Verma wrote: >> of_match_device could return NULL, and so can cause a NULL >> pointer dereference later. >> >> Signed-off-by: Shailendra Verma

Re: [PATCH] Pinctrl: mvebu - Fix possible NULL derefrence.

On Mon, Jan 30, 2017 at 9:24 AM, Thomas Petazzoni wrote: > On Mon, 30 Jan 2017 10:21:43 +0530, Shailendra Verma wrote: >> of_match_device could return NULL, and so can cause a NULL >> pointer dereference later. >> >> Signed-off-by: Shailendra Verma > > In practice, I don't see how

Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states

On Mon, 30 Jan 2017, Peter Griffin wrote: > Hi Lee, > > On Fri, 27 Jan 2017, Lee Jones wrote: > > > On Wed, 25 Jan 2017, Peter Griffin wrote: > > > > > Hi Lee, > > > > > > On Tue, 24 Jan 2017, Lee Jones wrote: > > > > > > > There are now 2 possible separate/different Pinctrl states which can

Re: [STLinux Kernel] [PATCH 3/8] serial: st-asc: Read in all Pinctrl states

On Mon, 30 Jan 2017, Peter Griffin wrote: > Hi Lee, > > On Fri, 27 Jan 2017, Lee Jones wrote: > > > On Wed, 25 Jan 2017, Peter Griffin wrote: > > > > > Hi Lee, > > > > > > On Tue, 24 Jan 2017, Lee Jones wrote: > > > > > > > There are now 2 possible separate/different Pinctrl states which can

Re: [PATCH v3 01/10] drivers: pinctrl: add driver for Allwinner H5 SoC

On Sun, Jan 29, 2017 at 3:33 AM, Icenowy Zheng wrote: > Based on the Allwinner H5 datasheet and the pinctrl driver of the > backward-compatible H3 this introduces the pin multiplex assignments for > the H5 SoC. > > H5 introduced some more pin functions (e.g. three more groups

Re: [PATCH v3 01/10] drivers: pinctrl: add driver for Allwinner H5 SoC

On Sun, Jan 29, 2017 at 3:33 AM, Icenowy Zheng wrote: > Based on the Allwinner H5 datasheet and the pinctrl driver of the > backward-compatible H3 this introduces the pin multiplex assignments for > the H5 SoC. > > H5 introduced some more pin functions (e.g. three more groups of TS > pins, and

Re: [PATCH v3 16/24] media: Add i.MX media core driver

On Mon, Jan 23, 2017 at 12:13:26PM +0100, Philipp Zabel wrote: > Hi Steve, > > On Sun, 2017-01-22 at 18:31 -0800, Steve Longerbeam wrote: > > Second, ignoring the above locking issue for a moment, > > v4l2_pipeline_pm_use() > > will call s_power on the sensor _first_, then the mipi csi-2

Re: [PATCH v3 16/24] media: Add i.MX media core driver

On Mon, Jan 23, 2017 at 12:13:26PM +0100, Philipp Zabel wrote: > Hi Steve, > > On Sun, 2017-01-22 at 18:31 -0800, Steve Longerbeam wrote: > > Second, ignoring the above locking issue for a moment, > > v4l2_pipeline_pm_use() > > will call s_power on the sensor _first_, then the mipi csi-2

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

On Mon, Jan 30, 2017 at 02:51:51PM +, Russell King - ARM Linux wrote: > Like it or not, it is _already_ exported to userspace, so it forms Well, I did try to stop it then too: b72e7464e4cf ("x86/uapi: Do not export as part of the user API headers") And yet this wankery trickled out to

Re: [PATCH v4 3/7] x86: put msr-index.h in uapi

On Mon, Jan 30, 2017 at 02:51:51PM +, Russell King - ARM Linux wrote: > Like it or not, it is _already_ exported to userspace, so it forms Well, I did try to stop it then too: b72e7464e4cf ("x86/uapi: Do not export as part of the user API headers") And yet this wankery trickled out to

[PATCH 1/2] introduce the walk_process_tree() helper

From: Oleg Nesterov Add the new helper to walk the process tree, the next patch adds a user. Note that it visits the group leaders only, proc_visitor can do for_each_thread itself or we can trivially extend walk_process_tree() to do this. Signed-off-by: Oleg Nesterov

[PATCH 1/2] introduce the walk_process_tree() helper

From: Oleg Nesterov Add the new helper to walk the process tree, the next patch adds a user. Note that it visits the group leaders only, proc_visitor can do for_each_thread itself or we can trivially extend walk_process_tree() to do this. Signed-off-by: Oleg Nesterov Signed-off-by: Pavel

[PATCH v3 2/2] prctl: propagate has_child_subreaper flag to every descendant

If process forks some children when it has is_child_subreaper flag enabled they will inherit has_child_subreaper flag - first group, when is_child_subreaper is disabled forked children will not inherit it - second group. So child-subreaper does not reparent all his descendants when their parents

[PATCH v3 2/2] prctl: propagate has_child_subreaper flag to every descendant

If process forks some children when it has is_child_subreaper flag enabled they will inherit has_child_subreaper flag - first group, when is_child_subreaper is disabled forked children will not inherit it - second group. So child-subreaper does not reparent all his descendants when their parents

[PATCH 1/2] introduce the walk_process_tree() helper

From: Oleg Nesterov Add the new helper to walk the process tree, the next patch adds a user. Note that it visits the group leaders only, proc_visitor can do for_each_thread itself or we can trivially extend walk_process_tree() to do this. Signed-off-by: Oleg Nesterov

[PATCH 1/2] introduce the walk_process_tree() helper

From: Oleg Nesterov Add the new helper to walk the process tree, the next patch adds a user. Note that it visits the group leaders only, proc_visitor can do for_each_thread itself or we can trivially extend walk_process_tree() to do this. Signed-off-by: Oleg Nesterov Signed-off-by: Pavel

<    8   9   10   11   12   13   14   15   16   17   >