Re: [PATCH] dt-bindings: mtd: add new compatible strings for mtk nor controller

On Thu, Aug 03, 2017 at 10:16:42AM +0800, Guochun Mao wrote: > Hi Cyrille, > > On Wed, 2017-08-02 at 17:31 +0200, Cyrille Pitchen wrote: > > Hi Guochun, > > > > Le 02/08/2017 à 10:36, Boris Brezillon a écrit : > > > Hi Matthias, > > > > > > On Tue, 1 Aug 2017 14:33:22 +0200 > > > Matthias

Re: [PATCH] dt-bindings: mtd: add new compatible strings for mtk nor controller

On Thu, Aug 03, 2017 at 10:16:42AM +0800, Guochun Mao wrote: > Hi Cyrille, > > On Wed, 2017-08-02 at 17:31 +0200, Cyrille Pitchen wrote: > > Hi Guochun, > > > > Le 02/08/2017 à 10:36, Boris Brezillon a écrit : > > > Hi Matthias, > > > > > > On Tue, 1 Aug 2017 14:33:22 +0200 > > > Matthias

Re: [PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson wrote: > In some cases drivers referencing a reserved-memory region might want to > remap the entire region, but when defining the reserved-memory by "size" > the client driver has no means to know the associated base

Re: [PATCH v2 2/5] of: reserved_mem: Accessor for acquiring reserved_mem

On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson wrote: > In some cases drivers referencing a reserved-memory region might want to > remap the entire region, but when defining the reserved-memory by "size" > the client driver has no means to know the associated base address of > the reserved

Re: [PATCH v2 1/5] of/platform: Generalize /reserved-memory handling

On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson wrote: > By iterating over all /reserved-memory child nodes and match each one to > a list of compatibles that we want to treat specially, we can easily > extend the list of compatibles to handle - without having to

Re: [PATCH v2 1/5] of/platform: Generalize /reserved-memory handling

On Wed, Aug 2, 2017 at 9:57 PM, Bjorn Andersson wrote: > By iterating over all /reserved-memory child nodes and match each one to > a list of compatibles that we want to treat specially, we can easily > extend the list of compatibles to handle - without having to resort to >

Re: [PATCH 23/29] drm/tilcdc: switch to drm_*{get,put} helpers

 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 08/03/17 18:42, Daniel Vetter wrote: > On Thu, Aug 3, 2017 at 3:56 PM, Jyri Sarha wrote: >> >> On 08/03/17 14:58, Cihangir Akturk wrote: >>>

Re: [PATCH 23/29] drm/tilcdc: switch to drm_*{get,put} helpers

 Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 08/03/17 18:42, Daniel Vetter wrote: > On Thu, Aug 3, 2017 at 3:56 PM, Jyri Sarha wrote: >> >> On 08/03/17 14:58, Cihangir Akturk wrote: >>> drm_*_reference() and

Re: [PATCH net-next] net: dsa: Add support for 64-bit statistics

On 08/02/2017 04:49 PM, David Miller wrote: > From: Florian Fainelli > Date: Tue, 1 Aug 2017 15:00:36 -0700 > >> DSA slave network devices maintain a pair of bytes and packets counters >> for each directions, but these are not 64-bit capable. Re-use >> pcpu_sw_netstats

Re: [PATCH net-next] net: dsa: Add support for 64-bit statistics

On 08/02/2017 04:49 PM, David Miller wrote: > From: Florian Fainelli > Date: Tue, 1 Aug 2017 15:00:36 -0700 > >> DSA slave network devices maintain a pair of bytes and packets counters >> for each directions, but these are not 64-bit capable. Re-use >> pcpu_sw_netstats which contains exactly

Re: [lustre-devel] [PATCH] staging: lustre: fix minor typos in comments

> Fix minor typos in comments. Acked-by: James Simmons > Signed-off-by: NeilBrown > --- > drivers/staging/lustre/lustre/llite/namei.c | 2 +- > drivers/staging/lustre/lustre/mdc/mdc_locks.c | 4 ++-- > 2 files changed, 3 insertions(+), 3

Re: [lustre-devel] [PATCH] staging: lustre: fix minor typos in comments

> Fix minor typos in comments. Acked-by: James Simmons > Signed-off-by: NeilBrown > --- > drivers/staging/lustre/lustre/llite/namei.c | 2 +- > drivers/staging/lustre/lustre/mdc/mdc_locks.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git

Re: [PATCH] selftests: use $SHELL to exec selftests

On Thu, Aug 3, 2017 at 9:59 AM, Luis R. Rodriguez wrote: > Executing selftests is fragile as if someone forgot to set a secript > as executable the test will fail. Setting scripts as executable is > desirable to enable folks to execute tests as independent units, > however, we

Re: [PATCH] selftests: use $SHELL to exec selftests

On Thu, Aug 3, 2017 at 9:59 AM, Luis R. Rodriguez wrote: > Executing selftests is fragile as if someone forgot to set a secript > as executable the test will fail. Setting scripts as executable is > desirable to enable folks to execute tests as independent units, > however, we can avoid the

Re: [PATCH] staging: lustre: declare fiemap_for_stripe static

> Declare fiemap_for_stripe as static to fix sparse warnings: > > > warning: symbol 'fiemap_for_stripe' was not declared. Should it be > > static? Acked-by: James Simmons > Signed-off-by: David Wittman > --- >

Re: [PATCH] staging: lustre: declare fiemap_for_stripe static

> Declare fiemap_for_stripe as static to fix sparse warnings: > > > warning: symbol 'fiemap_for_stripe' was not declared. Should it be > > static? Acked-by: James Simmons > Signed-off-by: David Wittman > --- > drivers/staging/lustre/lustre/lov/lov_object.c | 10 +- > 1 file

Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone

On Wed, Aug 02, 2017 at 06:40:01PM +0200, Andrea Arcangeli wrote: > On Wed, Aug 02, 2017 at 06:22:49PM +0200, Michal Hocko wrote: > > ESRCH refers to "no such process". Strictly speaking userfaultfd code is > > about a mm which is gone but that is a mere detail. In fact the owner of > > Well this

Re: [PATCH] userfaultfd_zeropage: return -ENOSPC in case mm has gone

On Wed, Aug 02, 2017 at 06:40:01PM +0200, Andrea Arcangeli wrote: > On Wed, Aug 02, 2017 at 06:22:49PM +0200, Michal Hocko wrote: > > ESRCH refers to "no such process". Strictly speaking userfaultfd code is > > about a mm which is gone but that is a mere detail. In fact the owner of > > Well this

Re: [PATCH] staging: lustre: obd: make echo_lock_ops const

> Declare echo_lock_ops object of type cl_lock_operations as const as it > is only passed to the function cl_lock_slice_add. The corresponding > argument is of type const, so make the object const. > Acked-by: James Simmons > Signed-off-by: Bhumika Goyal

Re: [PATCH] staging: lustre: obd: make echo_lock_ops const

> Declare echo_lock_ops object of type cl_lock_operations as const as it > is only passed to the function cl_lock_slice_add. The corresponding > argument is of type const, so make the object const. > Acked-by: James Simmons > Signed-off-by: Bhumika Goyal > --- >

Re: [PATCH v3 0/5] ACPI: DMA ranges management

On 03/08/17 16:45, Nate Watterson wrote: > Hi Lorenzo, > > On 8/3/2017 8:32 AM, Lorenzo Pieralisi wrote: >> This patch series is v3 of a previous posting: >> >> v2->v3: >> - Fixed DMA masks computation >> - Fixed size computation overflow in acpi_dma_get_range() >> >> v1->v2: >>

Re: [PATCH v3 0/5] ACPI: DMA ranges management

On 03/08/17 16:45, Nate Watterson wrote: > Hi Lorenzo, > > On 8/3/2017 8:32 AM, Lorenzo Pieralisi wrote: >> This patch series is v3 of a previous posting: >> >> v2->v3: >> - Fixed DMA masks computation >> - Fixed size computation overflow in acpi_dma_get_range() >> >> v1->v2: >>

Re: [PATCH] arm64: avoid overflow in VA_START and PAGE_OFFSET

On 3 August 2017 at 18:11, Nick Desaulniers wrote: > The bitmask used to define these values produces overflow, as seen by > this compiler warning: > > arch/arm64/kernel/head.S:47:8: warning: > integer overflow in preprocessor expression > #elif (PAGE_OFFSET &

Re: [PATCH] arm64: avoid overflow in VA_START and PAGE_OFFSET

On 3 August 2017 at 18:11, Nick Desaulniers wrote: > The bitmask used to define these values produces overflow, as seen by > this compiler warning: > > arch/arm64/kernel/head.S:47:8: warning: > integer overflow in preprocessor expression > #elif (PAGE_OFFSET & 0x1f) != 0 >

Re: MikeeUSA -- Notice Bruce Perens has NO response (nor does Moglen). [Was: Re: GrSecurity]

On 2017-08-03 09:13, Xen wrote: In Game Genie vs. Nintendo a company created a cheating device that would alter the operation of an existing product. They won that case and were allowed to do it. Distributing patches to be applied to an existing software product would really be no different

Re: MikeeUSA -- Notice Bruce Perens has NO response (nor does Moglen). [Was: Re: GrSecurity]

On 2017-08-03 09:13, Xen wrote: In Game Genie vs. Nintendo a company created a cheating device that would alter the operation of an existing product. They won that case and were allowed to do it. Distributing patches to be applied to an existing software product would really be no different

Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys

On Wed, Aug 02, 2017 at 01:06:44PM -0700, Davidlohr Bueso wrote: > On Mon, 31 Jul 2017, Guillaume Knispel wrote: > >static int __init ipc_init(void) > >{ > >-sem_init(); > >-msg_init(); > >+int err_sem, err_msg; > >+ > >+err_sem = sem_init(); > >+WARN(err_sem, "ipc: sysV

Re: [PATCH] ipc: optimize semget/shmget/msgget for lots of keys

On Wed, Aug 02, 2017 at 01:06:44PM -0700, Davidlohr Bueso wrote: > On Mon, 31 Jul 2017, Guillaume Knispel wrote: > >static int __init ipc_init(void) > >{ > >-sem_init(); > >-msg_init(); > >+int err_sem, err_msg; > >+ > >+err_sem = sem_init(); > >+WARN(err_sem, "ipc: sysV

[PATCH] arm64: avoid overflow in VA_START and PAGE_OFFSET

The bitmask used to define these values produces overflow, as seen by this compiler warning: arch/arm64/kernel/head.S:47:8: warning: integer overflow in preprocessor expression #elif (PAGE_OFFSET & 0x1f) != 0 ^~~ arch/arm64/include/asm/memory.h:52:46: note:

[PATCH] arm64: avoid overflow in VA_START and PAGE_OFFSET

The bitmask used to define these values produces overflow, as seen by this compiler warning: arch/arm64/kernel/head.S:47:8: warning: integer overflow in preprocessor expression #elif (PAGE_OFFSET & 0x1f) != 0 ^~~ arch/arm64/include/asm/memory.h:52:46: note:

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko wrote: > On Thu, Aug 3, 2017 at 6:18 PM, David Lechner wrote: > >> The particular display I have is this one: >> http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/ >> >> It looks like it uses a

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

On Thu, Aug 3, 2017 at 8:09 PM, Andy Shevchenko wrote: > On Thu, Aug 3, 2017 at 6:18 PM, David Lechner wrote: > >> The particular display I have is this one: >> http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/ >> >> It looks like it uses a command/data scheme like the MIPI displays, but >>

[PATCH 0/5] constify hotplug pci_device_id

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Arvind Yadav (5): [PATCH 1/5] PCI: hotplug: shpchp: constify pci_device_id. [PATCH 2/5] PCI: hotplug: ibmphp:

[PATCH 0/5] constify hotplug pci_device_id

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Arvind Yadav (5): [PATCH 1/5] PCI: hotplug: shpchp: constify pci_device_id. [PATCH 2/5] PCI: hotplug: ibmphp:

[PATCH 2/5] PCI: hotplug: ibmphp: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/pci/hotplug/ibmphp_core.c | 2 +- 1 file changed,

[PATCH 2/5] PCI: hotplug: ibmphp: constify pci_device_id.

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

[PATCH 4/5] PCI: hotplug: cpcihp_zt5550: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/pci/hotplug/cpcihp_zt5550.c | 2 +- 1 file

[PATCH 4/5] PCI: hotplug: cpcihp_zt5550: constify pci_device_id.

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

[PATCH 5/5] PCI: hotplug: cpqphp: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/pci/hotplug/cpqphp_core.c | 2 +- 1 file changed,

[PATCH 5/5] PCI: hotplug: cpqphp: constify pci_device_id.

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

[PATCH 1/5] PCI: hotplug: shpchp: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/pci/hotplug/shpchp_core.c | 2 +- 1 file changed,

[PATCH 1/5] PCI: hotplug: shpchp: constify pci_device_id.

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

[PATCH 3/5] PCI: hotplug: bmphp_ebda: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Signed-off-by: Arvind Yadav --- drivers/pci/hotplug/ibmphp_ebda.c | 2 +- 1 file changed,

[PATCH 3/5] PCI: hotplug: bmphp_ebda: constify pci_device_id.

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

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

On Thu, Aug 3, 2017 at 6:18 PM, David Lechner wrote: > The particular display I have is this one: > http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/ > > It looks like it uses a command/data scheme like the MIPI displays, but > doesn't use any of the standard values for the

Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display

On Thu, Aug 3, 2017 at 6:18 PM, David Lechner wrote: > The particular display I have is this one: > http://wiki.seeed.cc/Grove-OLED_Display_1.12inch/ > > It looks like it uses a command/data scheme like the MIPI displays, but > doesn't use any of the standard values for the commands. The

Re: [PATCH v2 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

On Mon, Jul 24, 2017 at 06:05:20PM -0500, Franklin S Cooper Jr wrote: > Add information regarding fixed transceiver binding. This is especially > important for MCAN since the IP allows CAN FD mode to run significantly > faster than what most transceivers are capable of. > > Signed-off-by:

Re: [PATCH v2 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

On Mon, Jul 24, 2017 at 06:05:20PM -0500, Franklin S Cooper Jr wrote: > Add information regarding fixed transceiver binding. This is especially > important for MCAN since the IP allows CAN FD mode to run significantly > faster than what most transceivers are capable of. > > Signed-off-by:

Re: [PATCH 1/2] bitops: Avoid integer overflow warning in GENMASK_ULL

El Thu, Aug 03, 2017 at 04:24:56PM +0300 Yury Norov ha dit: > On Wed, Aug 02, 2017 at 03:51:58PM -0700, Matthias Kaehlcke wrote: > > GENMASK_ULL performs a left-shift of (~0ULL), which technically > > results in an integer overflow. clang raises a warning about > > this if the overflow occurs in

Re: [PATCH 1/2] bitops: Avoid integer overflow warning in GENMASK_ULL

El Thu, Aug 03, 2017 at 04:24:56PM +0300 Yury Norov ha dit: > On Wed, Aug 02, 2017 at 03:51:58PM -0700, Matthias Kaehlcke wrote: > > GENMASK_ULL performs a left-shift of (~0ULL), which technically > > results in an integer overflow. clang raises a warning about > > this if the overflow occurs in

Re: [PATCH v2 2/3] dt-bindings: iio: adc: stm32: add optional st,min-sample-time-nsecs

On Mon, Jul 24, 2017 at 06:10:39PM +0200, Fabrice Gasnier wrote: > STM32 ADC allows each channel to be sampled with a different sampling > time. There's an application note that deals with this: 'How to get > the best ADC accuracy in STM32...' It basically depends on analog input > signal

Re: [PATCH v2 2/3] dt-bindings: iio: adc: stm32: add optional st,min-sample-time-nsecs

On Mon, Jul 24, 2017 at 06:10:39PM +0200, Fabrice Gasnier wrote: > STM32 ADC allows each channel to be sampled with a different sampling > time. There's an application note that deals with this: 'How to get > the best ADC accuracy in STM32...' It basically depends on analog input > signal

[PATCH 2/2] test_sysctl: fix sysctl.sh by making it executable

We had just forogtten to do this. Without this the following test fails: $ sudo make -C tools/testing/selftests/sysctl/ run_tests make: Entering directory '/home/mcgrof/linux-next/tools/testing/selftests/sysctl' /bin/sh: ./sysctl.sh: Permission denied selftests: sysctl.sh [FAIL]

[PATCH 2/2] test_sysctl: fix sysctl.sh by making it executable

We had just forogtten to do this. Without this the following test fails: $ sudo make -C tools/testing/selftests/sysctl/ run_tests make: Entering directory '/home/mcgrof/linux-next/tools/testing/selftests/sysctl' /bin/sh: ./sysctl.sh: Permission denied selftests: sysctl.sh [FAIL]

[PATCH 1/2] test_kmod: fix kmod.sh by making it executable

We had just forgotten to do this. Without this if we run the following we get a permission denied: sudo make -C tools/testing/selftests/kmod/ run_tests make: Entering directory '/home/mcgrof/linux-next/tools/testing/selftests/kmod' /bin/sh: ./kmod.sh: Permission denied selftests: kmod.sh [FAIL]

[PATCH 1/2] test_kmod: fix kmod.sh by making it executable

We had just forgotten to do this. Without this if we run the following we get a permission denied: sudo make -C tools/testing/selftests/kmod/ run_tests make: Entering directory '/home/mcgrof/linux-next/tools/testing/selftests/kmod' /bin/sh: ./kmod.sh: Permission denied selftests: kmod.sh [FAIL]

Re: [PATCH v5 5/6] seccomp: Action to log before allowing

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing > the syscall. At the implementation level, this action is identical to > the existing SECCOMP_RET_ALLOW action. However, it can be very useful when

Re: [PATCH v5 5/6] seccomp: Action to log before allowing

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing > the syscall. At the implementation level, this action is identical to > the existing SECCOMP_RET_ALLOW action. However, it can be very useful when > initially developing

[PATCH] selftests: use $SHELL to exec selftests

Executing selftests is fragile as if someone forgot to set a secript as executable the test will fail. Setting scripts as executable is desirable to enable folks to execute tests as independent units, however, we can avoid the fragile errors of forgetting to set the script as executable by just

[PATCH] selftests: use $SHELL to exec selftests

Executing selftests is fragile as if someone forgot to set a secript as executable the test will fail. Setting scripts as executable is desirable to enable folks to execute tests as independent units, however, we can avoid the fragile errors of forgetting to set the script as executable by just

Re: [PATCH v5 6/6] seccomp: Selftest for detection of filter flag support

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Userspace needs to be able to reliably detect the support of a filter > flag. A good way of doing that is by attempting to enter filter mode, > with the flag bit(s) in question set, and a NULL pointer for the args >

Re: [PATCH v5 6/6] seccomp: Selftest for detection of filter flag support

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Userspace needs to be able to reliably detect the support of a filter > flag. A good way of doing that is by attempting to enter filter mode, > with the flag bit(s) in question set, and a NULL pointer for the args > parameter of seccomp(2).

Re: [PATCH] pinctrl: intel: Add Intel Denverton pin controller support

On Thu, Aug 3, 2017 at 7:36 PM, Mika Westerberg wrote: > This driver adds pinctrl/GPIO support for Intel Denverton SoC. The GPIO > controller is based on the same hardware design that is already used in > Intel Sunrisepoint so we leverage the core driver here. I

Re: [PATCH] pinctrl: intel: Add Intel Denverton pin controller support

On Thu, Aug 3, 2017 at 7:36 PM, Mika Westerberg wrote: > This driver adds pinctrl/GPIO support for Intel Denverton SoC. The GPIO > controller is based on the same hardware design that is already used in > Intel Sunrisepoint so we leverage the core driver here. I would like to double check a pin

Re: [RFC][PATCH v3]: documentation,atomic: Add new documents

On Thu, Aug 03, 2017 at 05:12:24PM +0100, Will Deacon wrote: > On Thu, Aug 03, 2017 at 07:55:14AM -0700, Paul E. McKenney wrote: > > On Thu, Aug 03, 2017 at 10:05:16PM +0800, Boqun Feng wrote: > > > Hi Will, > > > > > > On Wed, Aug 02, 2017 at 10:45:32AM +0100, Will Deacon wrote: > > > [...] > >

Re: [RFC][PATCH v3]: documentation,atomic: Add new documents

On Thu, Aug 03, 2017 at 05:12:24PM +0100, Will Deacon wrote: > On Thu, Aug 03, 2017 at 07:55:14AM -0700, Paul E. McKenney wrote: > > On Thu, Aug 03, 2017 at 10:05:16PM +0800, Boqun Feng wrote: > > > Hi Will, > > > > > > On Wed, Aug 02, 2017 at 10:45:32AM +0100, Will Deacon wrote: > > > [...] > >

Re: [PATCH v5 3/6] seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for > all actions except for SECCOMP_RET_ALLOW for the given filter. > > SECCOMP_RET_KILL actions are always logged, when "kill" is in the >

Re: [PATCH v5 3/6] seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for > all actions except for SECCOMP_RET_ALLOW for the given filter. > > SECCOMP_RET_KILL actions are always logged, when "kill" is in the > actions_logged sysctl, and

Re: [PATCH v5 4/6] seccomp: Operation for checking if an action is available

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Userspace code that needs to check if the kernel supports a given action > may not be able to use the /proc/sys/kernel/seccomp/actions_avail > sysctl. The process may be running in a sandbox and, therefore, > sufficient

Re: [PATCH v5 4/6] seccomp: Operation for checking if an action is available

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Userspace code that needs to check if the kernel supports a given action > may not be able to use the /proc/sys/kernel/seccomp/actions_avail > sysctl. The process may be running in a sandbox and, therefore, > sufficient filesystem access may

Re: [PATCH BUGFIX/IMPROVEMENT] block, bfq: improve and refactor throughput-boosting logic

On 08/03/2017 10:48 AM, Paolo Valente wrote: > When a queue associated with a process remains empty, there are cases > where throughput gets boosted if the device is idled to await the > arrival of a new I/O request for that queue. Currently, BFQ assumes > that one of these cases is when the

Re: [PATCH BUGFIX/IMPROVEMENT] block, bfq: improve and refactor throughput-boosting logic

On 08/03/2017 10:48 AM, Paolo Valente wrote: > When a queue associated with a process remains empty, there are cases > where throughput gets boosted if the device is idled to await the > arrival of a new I/O request for that queue. Currently, BFQ assumes > that one of these cases is when the

Re: [PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

On Mon, Jul 24, 2017 at 12:23:24AM +0100, Andre Przywara wrote: > The ARM SMC mailbox binding describes a firmware interface to trigger > actions in software layers running in the EL2 or EL3 exception levels. > The term "ARM" here relates to the SMC instruction as part of the ARM > instruction

Re: [PATCH v2 1/3] DT: mailbox: add binding doc for the ARM SMC mailbox

On Mon, Jul 24, 2017 at 12:23:24AM +0100, Andre Przywara wrote: > The ARM SMC mailbox binding describes a firmware interface to trigger > actions in software layers running in the EL2 or EL3 exception levels. > The term "ARM" here relates to the SMC instruction as part of the ARM > instruction

Re: [PATCH v2 1/4] dt-bindings: crypto: add ARTPEC crypto

On Mon, Jul 24, 2017 at 09:07:29AM +0200, Lars Persson wrote: > Document the device tree bindings for the ARTPEC crypto accelerator on > ARTPEC-6 and ARTPEC-7 SoCs. > > Signed-off-by: Lars Persson > --- > .../devicetree/bindings/crypto/artpec6-crypto.txt| 16 >

Re: [PATCH v2 1/4] dt-bindings: crypto: add ARTPEC crypto

On Mon, Jul 24, 2017 at 09:07:29AM +0200, Lars Persson wrote: > Document the device tree bindings for the ARTPEC crypto accelerator on > ARTPEC-6 and ARTPEC-7 SoCs. > > Signed-off-by: Lars Persson > --- > .../devicetree/bindings/crypto/artpec6-crypto.txt| 16 > > 1

[PATCH BUGFIX/IMPROVEMENT] block, bfq: improve and refactor throughput-boosting logic

When a queue associated with a process remains empty, there are cases where throughput gets boosted if the device is idled to await the arrival of a new I/O request for that queue. Currently, BFQ assumes that one of these cases is when the device has no internal queueing (regardless of the

[PATCH BUGFIX/IMPROVEMENT] block, bfq: improve and refactor throughput-boosting logic

When a queue associated with a process remains empty, there are cases where throughput gets boosted if the device is idled to await the arrival of a new I/O request for that queue. Currently, BFQ assumes that one of these cases is when the device has no internal queueing (regardless of the

[PATCH v6] serio: PS/2 gpio bit banging driver for serio bus

This driver provides PS/2 serio bus support by implementing bit banging with the GPIO API. The GPIO pins, data and clock, can be configured with a node in the device tree or by generic device properties (GDP). Writing to a device is supported as well, though it is possible timings can not be halt

[PATCH v6] serio: PS/2 gpio bit banging driver for serio bus

This driver provides PS/2 serio bus support by implementing bit banging with the GPIO API. The GPIO pins, data and clock, can be configured with a node in the device tree or by generic device properties (GDP). Writing to a device is supported as well, though it is possible timings can not be halt

Re: [PATCH v6 5/7] mm: make tlb_flush_pending global

Hi Minchan, [auto build test WARNING on linus/master] [also build test WARNING on v4.13-rc3] [cannot apply to next-20170803] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nadav-Amit/mm-migrate

Re: [PATCH v6 5/7] mm: make tlb_flush_pending global

Hi Minchan, [auto build test WARNING on linus/master] [also build test WARNING on v4.13-rc3] [cannot apply to next-20170803] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nadav-Amit/mm-migrate

Re: [PATCH v3 2/4] dt-bindings: can: fixed-transceiver: Add new CAN fixed transceiver bindings

On 08/03/2017 07:22 AM, Sergei Shtylyov wrote: > On 08/03/2017 12:48 PM, Franklin S Cooper Jr wrote: > Add documentation to describe usage of the new fixed transceiver binding. This new binding is applicable for any CAN device therefore it exists as its own document.

Re: [PATCH v3 2/4] dt-bindings: can: fixed-transceiver: Add new CAN fixed transceiver bindings

On 08/03/2017 07:22 AM, Sergei Shtylyov wrote: > On 08/03/2017 12:48 PM, Franklin S Cooper Jr wrote: > Add documentation to describe usage of the new fixed transceiver binding. This new binding is applicable for any CAN device therefore it exists as its own document.

Re: [PATCH v2] zram: Rework copy of compressor name in comp_algorithm_store()

Hi, On Thu, Aug 3, 2017 at 9:33 AM, Matthias Kaehlcke wrote: > comp_algorithm_store() passes the size of the source buffer to strlcpy() > instead of the destination buffer size. Make it explicit that the two > buffers have the same size and use strcpy() instead of strlcpy(). >

Re: [PATCH v2] zram: Rework copy of compressor name in comp_algorithm_store()

Hi, On Thu, Aug 3, 2017 at 9:33 AM, Matthias Kaehlcke wrote: > comp_algorithm_store() passes the size of the source buffer to strlcpy() > instead of the destination buffer size. Make it explicit that the two > buffers have the same size and use strcpy() instead of strlcpy(). > The latter can be

Re: [PATCH v5 1/6] seccomp: Sysctl to display available actions

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > This patch creates a read-only sysctl containing an ordered list of > seccomp actions that the kernel supports. The ordering, from left to > right, is the lowest action value (kill) to the highest action value > (allow).

Re: [PATCH v5 1/6] seccomp: Sysctl to display available actions

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > This patch creates a read-only sysctl containing an ordered list of > seccomp actions that the kernel supports. The ordering, from left to > right, is the lowest action value (kill) to the highest action value > (allow). Currently, a read of

[PATCH] pinctrl: intel: Add Intel Denverton pin controller support

This driver adds pinctrl/GPIO support for Intel Denverton SoC. The GPIO controller is based on the same hardware design that is already used in Intel Sunrisepoint so we leverage the core driver here. Signed-off-by: Mika Westerberg ---

[PATCH] pinctrl: intel: Add Intel Denverton pin controller support

This driver adds pinctrl/GPIO support for Intel Denverton SoC. The GPIO controller is based on the same hardware design that is already used in Intel Sunrisepoint so we leverage the core driver here. Signed-off-by: Mika Westerberg --- drivers/pinctrl/intel/Kconfig | 8 +

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

On 08/02/2017 10:01 PM, Hean Loong, Ong wrote: > From: Ong Hean Loong > Really needs a short commit description. > Signed-off-by: Ong Hean Loong > --- > V5: > *Fix Comments > > V4: > *Fix Comments > > V3: > *Changes to fixing

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

On 08/02/2017 10:01 PM, Hean Loong, Ong wrote: > From: Ong Hean Loong > Really needs a short commit description. > Signed-off-by: Ong Hean Loong > --- > V5: > *Fix Comments > > V4: > *Fix Comments > > V3: > *Changes to fixing drm_simple_pipe > *Used drm_fb_cma_get_gem_addr > > V2: >

[PATCH v2] zram: Rework copy of compressor name in comp_algorithm_store()

comp_algorithm_store() passes the size of the source buffer to strlcpy() instead of the destination buffer size. Make it explicit that the two buffers have the same size and use strcpy() instead of strlcpy(). The latter can be done safely since the function ensures that the string in the source

[PATCH v2] zram: Rework copy of compressor name in comp_algorithm_store()

comp_algorithm_store() passes the size of the source buffer to strlcpy() instead of the destination buffer size. Make it explicit that the two buffers have the same size and use strcpy() instead of strlcpy(). The latter can be done safely since the function ensures that the string in the source

Re: [PATCH v5 2/6] seccomp: Sysctl to configure actions that are allowed to be logged

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Adminstrators can write to this sysctl to set the seccomp actions that > are allowed to be logged. Any actions not found in this sysctl will not > be logged. > > For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and >

Re: [PATCH v5 2/6] seccomp: Sysctl to configure actions that are allowed to be logged

On Fri, Jul 28, 2017 at 1:55 PM, Tyler Hicks wrote: > Adminstrators can write to this sysctl to set the seccomp actions that > are allowed to be logged. Any actions not found in this sysctl will not > be logged. > > For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and > SECCOMP_RET_ERRNO

Re: [PATCH v3 1/5] dt-bindings: update the Allwinner GPADC device tree binding for H3

On Sun, Jul 23, 2017 at 10:13:50PM +0800, Icenowy Zheng wrote: > Allwinner H3 features a thermal sensor like the one in A33, but has its > register re-arranged, the clock divider moved to CCU (originally the > clock divider is in ADC) and added a pair of bus clock and reset. > > Update the

Re: [PATCH v3 1/5] dt-bindings: update the Allwinner GPADC device tree binding for H3

On Sun, Jul 23, 2017 at 10:13:50PM +0800, Icenowy Zheng wrote: > Allwinner H3 features a thermal sensor like the one in A33, but has its > register re-arranged, the clock divider moved to CCU (originally the > clock divider is in ADC) and added a pair of bus clock and reset. > > Update the

Re: [PATCH 01/10] dt-bindings: add binding for the SY8160A voltage regulator

On Sun, Jul 23, 2017 at 06:27:40PM +0800, Icenowy Zheng wrote: > From: Ondrej Jirman > > SY8106A is an I2C-controlled adjustable voltage regulator made by > Silergy Corp. > > Add its device tree binding. > > Signed-off-by: Ondrej Jirman > [Icenowy: Change

Re: [PATCH 01/10] dt-bindings: add binding for the SY8160A voltage regulator

On Sun, Jul 23, 2017 at 06:27:40PM +0800, Icenowy Zheng wrote: > From: Ondrej Jirman > > SY8106A is an I2C-controlled adjustable voltage regulator made by > Silergy Corp. > > Add its device tree binding. > > Signed-off-by: Ondrej Jirman > [Icenowy: Change commit message] > Signed-off-by:

<    4   5   6   7   8   9   10   11   12   13   >