[PATCH v2 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

[PATCH v2 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

[PATCH v2 3/5] Documentation: dt: iio: document stm32 exti trigger

Add dt documentation for st,stm32-exti-trigger. EXTi gpio signal can be routed internally as trigger source for various IPs (e.g. for ADC or DAC conversions). Signed-off-by: Fabrice Gasnier --- .../bindings/iio/trigger/st,stm32-exti-trigger.txt | 17

[PATCH v2 3/5] Documentation: dt: iio: document stm32 exti trigger

Add dt documentation for st,stm32-exti-trigger. EXTi gpio signal can be routed internally as trigger source for various IPs (e.g. for ADC or DAC conversions). Signed-off-by: Fabrice Gasnier --- .../bindings/iio/trigger/st,stm32-exti-trigger.txt | 17 + 1 file changed, 17

[PATCH v2 4/5] iio: trigger: add support for STM32 EXTI triggers

EXTi[0..15] gpio signal can be routed internally as trigger source for ADC or DAC conversions. Configure them as interrupts to configure trigger path in HW. Note: interrupt handler isn't required here, and corresponding interrupt can be kept masked at exti controller level. Signed-off-by:

[PATCH v2 0/5] Add EXTI GPIO trigger support to STM32 ADC

STM32 ADC, can use GPIOs configured as EXTI line (external interrupt) as trigger source for conversions. This patchset is based on latest IIO testing branch, and adds support for EXTi GPIO triggers in IIO. It also adds a dt option to configure default trigger polarity in STM32 ADC driver. ---

[PATCH v2 4/5] iio: trigger: add support for STM32 EXTI triggers

EXTi[0..15] gpio signal can be routed internally as trigger source for ADC or DAC conversions. Configure them as interrupts to configure trigger path in HW. Note: interrupt handler isn't required here, and corresponding interrupt can be kept masked at exti controller level. Signed-off-by:

[PATCH v2 0/5] Add EXTI GPIO trigger support to STM32 ADC

STM32 ADC, can use GPIOs configured as EXTI line (external interrupt) as trigger source for conversions. This patchset is based on latest IIO testing branch, and adds support for EXTi GPIO triggers in IIO. It also adds a dt option to configure default trigger polarity in STM32 ADC driver. ---

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

On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > Now lets admit one drawback: s390 and powerpc with > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion > on cputime accounting path. But this should be leveraged by the recent > changes which delay the

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

On Mon, Jan 30, 2017 at 05:46:43AM +0100, Frederic Weisbecker wrote: > Now lets admit one drawback: s390 and powerpc with > CONFIG_VIRT_CPU_ACCOUNTING_NATIVE have new cputime_t to nsecs conversion > on cputime accounting path. But this should be leveraged by the recent > changes which delay the

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

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 > > > be provided from platform data. One which encompasses the

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

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 > > > be provided from platform data. One which encompasses the

Re: [PATCH v6 5/5] arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards

Hi Chris, On lun., janv. 30 2017, Chris Packham wrote: > These boards are Marvell's evaluation boards for the 98DX4251 and > 98DX3336 SoCs. > > Signed-off-by: Chris Packham Applied on mvebu/dt Thanks, Gregory > --- >

Re: [PATCH v6 5/5] arm: mvebu: Add device tree for db-dxbc2 and db-xc3-24g4xg boards

Hi Chris, On lun., janv. 30 2017, Chris Packham wrote: > These boards are Marvell's evaluation boards for the 98DX4251 and > 98DX3336 SoCs. > > Signed-off-by: Chris Packham Applied on mvebu/dt Thanks, Gregory > --- > > Notes: > Changes in v5: > - update license text > - use

[PATCH] net: thunderx: avoid dereferencing xcv when NULL

This fixes the following smatch and coccinelle warnings: drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119 xcv_setup_link() error: we previously assumed 'xcv' could be null (see line 118) [smatch] drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119:16-20: ERROR: xcv is NULL but

[PATCH] net: thunderx: avoid dereferencing xcv when NULL

This fixes the following smatch and coccinelle warnings: drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119 xcv_setup_link() error: we previously assumed 'xcv' could be null (see line 118) [smatch] drivers/net/ethernet/cavium/thunder/thunder_xcv.c:119:16-20: ERROR: xcv is NULL but

Re: [PATCH v6 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs

Hi Chris, On lun., janv. 30 2017, Chris Packham wrote: > The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs > with integrated CPUs. They are similar to the Armada XP SoCs but have > different I/O interfaces. > > Signed-off-by: Chris

Re: [PATCH v6 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs

Hi Chris, On lun., janv. 30 2017, Chris Packham wrote: > The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs > with integrated CPUs. They are similar to the Armada XP SoCs but have > different I/O interfaces. > > Signed-off-by: Chris Packham > Acked-by: Rob Herring

[PATCH 0/5] Add EXTI GPIO trigger support to STM32 ADC

STM32 ADC, can use GPIOs configured as EXTI line (external interrupt) as trigger source for conversions. This patchset is based on latest IIO testing branch, and adds support for EXTi GPIO triggers in IIO. It also adds a dt option to configure default trigger polarity in STM32 ADC driver. Fabrice

[PATCH 0/5] Add EXTI GPIO trigger support to STM32 ADC

STM32 ADC, can use GPIOs configured as EXTI line (external interrupt) as trigger source for conversions. This patchset is based on latest IIO testing branch, and adds support for EXTi GPIO triggers in IIO. It also adds a dt option to configure default trigger polarity in STM32 ADC driver. Fabrice

Re: [PATCH v6 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

Hi Chris, On lun., janv. 30 2017, Chris Packham wrote: > Compared to the armada-xp the 98DX3336 uses different registers to set > the boot address for the secondary CPU so a new enable-method is needed. > This will only work if the machine definition

Re: [PATCH v6 2/5] arm: mvebu: support for SMP on 98DX3336 SoC

Hi Chris, On lun., janv. 30 2017, Chris Packham wrote: > Compared to the armada-xp the 98DX3336 uses different registers to set > the boot address for the secondary CPU so a new enable-method is needed. > This will only work if the machine definition doesn't define an overall > smp_ops

Re: [PATCH v5 5/8] clocksource/drivers/rockchip_timer: split bc_timer into rk_timer and rk_clock_event_device

On Mon, Jan 30, 2017 at 04:55:33PM +0300, Alexander Kochetkov wrote: > > > 30 янв. 2017 г., в 16:12, Daniel Lezcano > > написал(а): > > > > I don't get the point of these changes. The patch does not explain why they > > are > > needed. > > I’d like to extract timer

Re: [PATCH v5 5/8] clocksource/drivers/rockchip_timer: split bc_timer into rk_timer and rk_clock_event_device

On Mon, Jan 30, 2017 at 04:55:33PM +0300, Alexander Kochetkov wrote: > > > 30 янв. 2017 г., в 16:12, Daniel Lezcano > > написал(а): > > > > I don't get the point of these changes. The patch does not explain why they > > are > > needed. > > I’d like to extract timer API from current

[PATCH 07/15] phy: Add support for Qualcomm's USB HS phy

From: Stephen Boyd The high-speed phy on qcom SoCs is controlled via the ULPI viewport. Cc: Kishon Vijay Abraham I Cc: Acked-by: Rob Herring Signed-off-by: Stephen Boyd

[PATCH 07/15] phy: Add support for Qualcomm's USB HS phy

From: Stephen Boyd The high-speed phy on qcom SoCs is controlled via the ULPI viewport. Cc: Kishon Vijay Abraham I Cc: Acked-by: Rob Herring Signed-off-by: Stephen Boyd Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/qcom,usb-hs-phy.txt| 84 ++

[PATCH 06/15] phy: Add support for Qualcomm's USB HSIC phy

From: Stephen Boyd The HSIC USB controller on qcom SoCs has an integrated all digital phy controlled via the ULPI viewport. Cc: Kishon Vijay Abraham I Acked-by: Rob Herring Cc: Signed-off-by: Stephen Boyd

[PATCH 06/15] phy: Add support for Qualcomm's USB HSIC phy

From: Stephen Boyd The HSIC USB controller on qcom SoCs has an integrated all digital phy controlled via the ULPI viewport. Cc: Kishon Vijay Abraham I Acked-by: Rob Herring Cc: Signed-off-by: Stephen Boyd Signed-off-by: Kishon Vijay Abraham I ---

[PATCH 06/14] phy: Add support for Qualcomm's USB HS phy

From: Stephen Boyd The high-speed phy on qcom SoCs is controlled via the ULPI viewport. Cc: Kishon Vijay Abraham I Cc: Acked-by: Rob Herring Signed-off-by: Stephen Boyd

[PATCH 06/14] phy: Add support for Qualcomm's USB HS phy

From: Stephen Boyd The high-speed phy on qcom SoCs is controlled via the ULPI viewport. Cc: Kishon Vijay Abraham I Cc: Acked-by: Rob Herring Signed-off-by: Stephen Boyd Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/qcom,usb-hs-phy.txt| 84 ++

[PATCH 09/15] phy: qcom-ufs: Correct usage of regulator_get()

From: Bjorn Andersson When regulator_get() tries to resolve a regulator supply but fail to find a matching property in DeviceTree it returns a dummy regulator, if a matching supply is specified but unavailable the regulator core will return an error. Based on this we

[PATCH 09/15] phy: qcom-ufs: Correct usage of regulator_get()

From: Bjorn Andersson When regulator_get() tries to resolve a regulator supply but fail to find a matching property in DeviceTree it returns a dummy regulator, if a matching supply is specified but unavailable the regulator core will return an error. Based on this we should not ignore errors

[PATCH 5/5] iio: adc: stm32: add exti11 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 5/5] iio: adc: stm32: add exti11 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 ---

GOOD NEWS

Dear Friend, I did not forgot your past effort and attempts to assist me, now i am happy to inform you that i have succeeded in getting those funds transferred with the help of a new partner from India. Now Contact my secretary, ask her for Seven Hundred And Fifty Thousand United States

GOOD NEWS

Dear Friend, I did not forgot your past effort and attempts to assist me, now i am happy to inform you that i have succeeded in getting those funds transferred with the help of a new partner from India. Now Contact my secretary, ask her for Seven Hundred And Fifty Thousand United States

Re: [PATCH 3/3] pinctrl: intel: Add Intel Gemini Lake pin controller support

On Fri, Jan 27, 2017 at 11:07 AM, Mika Westerberg wrote: > This driver adds pinctrl/GPIO support for Intel Gemini Lake SoC. The > GPIO controller is based on the next generation GPIO hardware but still > compatible with the one supported by the Intel core

Re: [PATCH 3/3] pinctrl: intel: Add Intel Gemini Lake pin controller support

On Fri, Jan 27, 2017 at 11:07 AM, Mika Westerberg wrote: > This driver adds pinctrl/GPIO support for Intel Gemini Lake SoC. The > GPIO controller is based on the next generation GPIO hardware but still > compatible with the one supported by the Intel core pinctrl/GPIO driver. > > This commit

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

On 01/30, Pavel Tikhomirov wrote: > > On 01/30/2017 03:51 PM, Oleg Nesterov wrote: > >>+ /* > >>+* Inherit has_child_subreaper flag under the same > >>+* tasklist_lock with adding child to the process tree > >>+* for

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

On 01/30, Pavel Tikhomirov wrote: > > On 01/30/2017 03:51 PM, Oleg Nesterov wrote: > >>+ /* > >>+* Inherit has_child_subreaper flag under the same > >>+* tasklist_lock with adding child to the process tree > >>+* for

Re: [PATCH v2 3/4] ARM: nommu: display vectors base

On Sun, Jan 22, 2017 at 08:52:12AM +0530, afzal mohammed wrote: > The exception base address is now dynamically estimated for no-MMU, > display it. As it is the case, now limit VECTORS_BASE usage to MMU > scenario. > > Signed-off-by: afzal mohammed As I wrote

Re: [PATCH v2 3/4] ARM: nommu: display vectors base

On Sun, Jan 22, 2017 at 08:52:12AM +0530, afzal mohammed wrote: > The exception base address is now dynamically estimated for no-MMU, > display it. As it is the case, now limit VECTORS_BASE usage to MMU > scenario. > > Signed-off-by: afzal mohammed As I wrote elsewhere... > diff --git

[PATCH 1/5] Documentation: dt: iio: document stm32 adc trigger polarity

STM32 ADC trigger polarity can be set to either rising, falling or both edges. Allow to configure it from dt. Signed-off-by: Fabrice Gasnier --- Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 1/5] Documentation: dt: iio: document stm32 adc trigger polarity

STM32 ADC trigger polarity can be set to either rising, falling or both edges. Allow to configure it from dt. Signed-off-by: Fabrice Gasnier --- Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git

Re: [PATCH 0/5] Add EXTI GPIO trigger support to STM32 ADC

Hi all, Please discard this series. I'll send a V2. Sorry for the noise. Best regards, Fabrice On 01/30/2017 02:57 PM, Fabrice Gasnier wrote: STM32 ADC, can use GPIOs configured as EXTI line (external interrupt) as trigger source for conversions. This patchset is based on latest IIO testing

Re: [PATCH 0/5] Add EXTI GPIO trigger support to STM32 ADC

Hi all, Please discard this series. I'll send a V2. Sorry for the noise. Best regards, Fabrice On 01/30/2017 02:57 PM, Fabrice Gasnier wrote: STM32 ADC, can use GPIOs configured as EXTI line (external interrupt) as trigger source for conversions. This patchset is based on latest IIO testing

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

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 configuration for per-pad hardware debouncer. > >

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

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 configuration for per-pad hardware debouncer. > > This patch adds support for that in

Re: [PATCH 14/14] ASoC: sunxi: simplify optional reset handling

On Mon, 2017-01-30 at 12:30 +, Mark Brown wrote: > On Mon, Jan 30, 2017 at 12:41:16PM +0100, Philipp Zabel wrote: > > As of commit bb475230b8e5 ("reset: make optional functions really > > optional"), the reset framework API calls use NULL pointers to describe > > optional, non-present reset

Re: [PATCH 14/14] ASoC: sunxi: simplify optional reset handling

On Mon, 2017-01-30 at 12:30 +, Mark Brown wrote: > On Mon, Jan 30, 2017 at 12:41:16PM +0100, Philipp Zabel wrote: > > As of commit bb475230b8e5 ("reset: make optional functions really > > optional"), the reset framework API calls use NULL pointers to describe > > optional, non-present reset

Re: [PATCH 2/3] pinctrl: intel: Add support for 1k additional pull-down

On Fri, Jan 27, 2017 at 11:07 AM, Mika Westerberg wrote: > The next generation Intel GPIO hardware supports additional 1k pull-down > per-pad. Add support for this to the Intel core pinctrl driver. > > Signed-off-by: Mika Westerberg

Re: [PATCH 2/3] pinctrl: intel: Add support for 1k additional pull-down

On Fri, Jan 27, 2017 at 11:07 AM, Mika Westerberg wrote: > The next generation Intel GPIO hardware supports additional 1k pull-down > per-pad. Add support for this to the Intel core pinctrl driver. > > Signed-off-by: Mika Westerberg > Reviewed-by: Andy Shevchenko Patch applied. And if you

Re: [PATCH REPOST 2/2] cgroup, perf_event: make perf_event controller work on cgroup2 hierarchy

Em Sun, Jan 29, 2017 at 02:35:20PM -0500, Tejun Heo escreveu: > perf_event is a utility controller whose primary role is identifying > cgroup membership to filter perf events; however, because it also > tracks some per-css state, it can't be replaced by pure cgroup > membership test. Mark the

Re: [PATCH REPOST 2/2] cgroup, perf_event: make perf_event controller work on cgroup2 hierarchy

Em Sun, Jan 29, 2017 at 02:35:20PM -0500, Tejun Heo escreveu: > perf_event is a utility controller whose primary role is identifying > cgroup membership to filter perf events; however, because it also > tracks some per-css state, it can't be replaced by pure cgroup > membership test. Mark the

[PATCH 4/5] iio: trigger: add support for STM32 EXTI triggers

EXTi[0..15] gpio signal can be routed internally as trigger source for ADC or DAC conversions. Configure them as interrupts to configure trigger path in HW. Note: interrupt handler isn't required here, and corresponding interrupt can be kept masked at exti controller level. Signed-off-by:

[PATCH 4/5] iio: trigger: add support for STM32 EXTI triggers

EXTi[0..15] gpio signal can be routed internally as trigger source for ADC or DAC conversions. Configure them as interrupts to configure trigger path in HW. Note: interrupt handler isn't required here, and corresponding interrupt can be kept masked at exti controller level. Signed-off-by:

Re: [PATCH 3/9] rhashtable: simplify a strange allocation pattern

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko alloc_bucket_locks allocation pattern is quite unusual. We are preferring vmalloc when CONFIG_NUMA is enabled. The rationale is that vmalloc will respect the memory policy of the current process and so the backing

Re: [PATCH 3/9] rhashtable: simplify a strange allocation pattern

On 01/30/2017 10:49 AM, Michal Hocko wrote: From: Michal Hocko alloc_bucket_locks allocation pattern is quite unusual. We are preferring vmalloc when CONFIG_NUMA is enabled. The rationale is that vmalloc will respect the memory policy of the current process and so the backing memory will get

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

Matt Fleming wrote: > > Matt argues, however, that boot_params->secure_boot should be propagated > > from > > the bootloader and if the bootloader wants to set it, then we should skip > > the > > check in efi_main() and go with the bootloader's opinion. This is

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

Matt Fleming wrote: > > Matt argues, however, that boot_params->secure_boot should be propagated > > from > > the bootloader and if the bootloader wants to set it, then we should skip > > the > > check in efi_main() and go with the bootloader's opinion. This is something > > we probably want

[PATCH] iio: stx104: Remove unneeded struct stx104_dev code

The stx104_dev structure was used to hold private data for use in the stx104_remove function. Now that the stx104_remove function is gone, the stx104_dev structure and relevant code is no longer needed. This patch removes the unnecessary code. Signed-off-by: William Breathitt Gray

[PATCH] iio: stx104: Remove unneeded struct stx104_dev code

The stx104_dev structure was used to hold private data for use in the stx104_remove function. Now that the stx104_remove function is gone, the stx104_dev structure and relevant code is no longer needed. This patch removes the unnecessary code. Signed-off-by: William Breathitt Gray ---

Re: [PATCH v3 03/37] treewide: Consolidate set_dma_ops() implementations

On Fri, Jan 20, 2017 at 01:04:03PM -0800, Bart Van Assche wrote: > Now that all set_dma_ops() implementations are identical (ignoring > BUG_ON() statements), remove the architecture specific definitions > and add a definition in . > > Signed-off-by: Bart Van Assche >

Re: task_is_descendant() cleanup

On 01/25, Kees Cook wrote: > > On Mon, Jan 23, 2017 at 4:52 AM, Oleg Nesterov wrote: > > On 01/23, Oleg Nesterov wrote: > >> > >> Btw task_is_descendant() looks wrong at first glance. > > > > No, I missed the 2nd ->group_leader dereference. Still this function looks > >

Re: [PATCH v3 03/37] treewide: Consolidate set_dma_ops() implementations

On Fri, Jan 20, 2017 at 01:04:03PM -0800, Bart Van Assche wrote: > Now that all set_dma_ops() implementations are identical (ignoring > BUG_ON() statements), remove the architecture specific definitions > and add a definition in . > > Signed-off-by: Bart Van Assche > Cc: Benjamin Herrenschmidt

Re: task_is_descendant() cleanup

On 01/25, Kees Cook wrote: > > On Mon, Jan 23, 2017 at 4:52 AM, Oleg Nesterov wrote: > > On 01/23, Oleg Nesterov wrote: > >> > >> Btw task_is_descendant() looks wrong at first glance. > > > > No, I missed the 2nd ->group_leader dereference. Still this function looks > > overcomplicated and the

Re: [PATCH v6 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

On Mon, Jan 30, 2017 at 12:20 AM, Chris Packham wrote: > From: Kalyan Kinthada > > This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs > from Marvell. > > Signed-off-by: Kalyan Kinthada

Re: [PATCH v6 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC

On Mon, Jan 30, 2017 at 12:20 AM, Chris Packham wrote: > From: Kalyan Kinthada > > This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs > from Marvell. > > Signed-off-by: Kalyan Kinthada > Signed-off-by: Chris Packham > Acked-by: Rob Herring > Acked-by: Sebastian Hesselbarth

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

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 - 64bit variables can be mangled. I do not see any protection > > (lock)

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

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 - 64bit variables can be mangled. I do not see any protection > > (lock)

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

On Mon, 30 Jan, at 12:10:29PM, David Howells wrote: > > Matt argues, however, that boot_params->secure_boot should be propagated from > the bootloader and if the bootloader wants to set it, then we should skip the > check in efi_main() and go with the bootloader's opinion. This is something > we

Re: What should the default lockdown mode be if the bootloader sentinel triggers sanitization?

On Mon, 30 Jan, at 12:10:29PM, David Howells wrote: > > Matt argues, however, that boot_params->secure_boot should be propagated from > the bootloader and if the bootloader wants to set it, then we should skip the > check in efi_main() and go with the bootloader's opinion. This is something > we

Re: [PATCH v5 5/8] clocksource/drivers/rockchip_timer: split bc_timer into rk_timer and rk_clock_event_device

> 30 янв. 2017 г., в 16:12, Daniel Lezcano > написал(а): > > I don't get the point of these changes. The patch does not explain why they > are > needed. I’d like to extract timer API from current implementation. And to make code more readable I’d like to introduce

Re: [PATCH v5 5/8] clocksource/drivers/rockchip_timer: split bc_timer into rk_timer and rk_clock_event_device

> 30 янв. 2017 г., в 16:12, Daniel Lezcano > написал(а): > > I don't get the point of these changes. The patch does not explain why they > are > needed. I’d like to extract timer API from current implementation. And to make code more readable I’d like to introduce 'struct rk_timer’ what can

Re: [PATCH v5 8/8] clocksource/drivers/rockchip_timer: implement clocksource timer

On Tue, Jan 24, 2017 at 03:16:43PM +0300, Alexander Kochetkov wrote: > The clock supplying the arm-global-timer on the rk3188 is coming from the > the cpu clock itself and thus changes its rate everytime cpufreq adjusts > the cpu frequency making this timer unsuitable as a stable clocksource > and

Re: [PATCH v5 8/8] clocksource/drivers/rockchip_timer: implement clocksource timer

On Tue, Jan 24, 2017 at 03:16:43PM +0300, Alexander Kochetkov wrote: > The clock supplying the arm-global-timer on the rk3188 is coming from the > the cpu clock itself and thus changes its rate everytime cpufreq adjusts > the cpu frequency making this timer unsuitable as a stable clocksource > and

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

Hi Jens/Omar, I used git.kernel.dk/linux-block branch - blk-mq-sched (commit 0efe27068ecf37ece2728a99b863763286049ab5) and confirm that issue reported in this thread is resolved. Now I am seeing MQ and SQ mode both are resulting in sequential IO pattern while IO is getting re-queued in block

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

Hi Jens/Omar, I used git.kernel.dk/linux-block branch - blk-mq-sched (commit 0efe27068ecf37ece2728a99b863763286049ab5) and confirm that issue reported in this thread is resolved. Now I am seeing MQ and SQ mode both are resulting in sequential IO pattern while IO is getting re-queued in block

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

On 01/30/2017 03:51 PM, Oleg Nesterov wrote: On 01/27, Pavel Tikhomirov wrote: --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1725,6 +1725,8 @@ struct task_struct { struct signal_struct *signal; struct sighand_struct *sighand; + struct list_head

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

On 01/30/2017 03:51 PM, Oleg Nesterov wrote: On 01/27, Pavel Tikhomirov wrote: --- a/include/linux/sched.h +++ b/include/linux/sched.h @@ -1725,6 +1725,8 @@ struct task_struct { struct signal_struct *signal; struct sighand_struct *sighand; + struct list_head

Re: [PATCH v15 2/5] tee: generic TEE subsystem

On Mon, Jan 30, 2017 at 09:02:49AM +, Benjamin GAIGNARD wrote: > > > On 01/28/2017 01:19 PM, Jens Wiklander wrote: [...] > > +/** > > + * tee_shm_alloc() - Allocate shared memory > > + * @ctx: Context that allocates the shared memory > > + * @size: Requested size of shared memory > > + *

Re: [PATCH v15 2/5] tee: generic TEE subsystem

On Mon, Jan 30, 2017 at 09:02:49AM +, Benjamin GAIGNARD wrote: > > > On 01/28/2017 01:19 PM, Jens Wiklander wrote: [...] > > +/** > > + * tee_shm_alloc() - Allocate shared memory > > + * @ctx: Context that allocates the shared memory > > + * @size: Requested size of shared memory > > + *

[tip:perf/core] perf/x86/amd/uncore: Update sysfs attributes for Family17h processors

Commit-ID: da6adaea2b7ef658c61a557c28508668eac29fe1 Gitweb: http://git.kernel.org/tip/da6adaea2b7ef658c61a557c28508668eac29fe1 Author: Janakarajan Natarajan AuthorDate: Mon, 16 Jan 2017 17:36:23 -0600 Committer: Ingo Molnar CommitDate:

[tip:perf/core] perf/x86/amd/uncore: Update sysfs attributes for Family17h processors

Commit-ID: da6adaea2b7ef658c61a557c28508668eac29fe1 Gitweb: http://git.kernel.org/tip/da6adaea2b7ef658c61a557c28508668eac29fe1 Author: Janakarajan Natarajan AuthorDate: Mon, 16 Jan 2017 17:36:23 -0600 Committer: Ingo Molnar CommitDate: Mon, 30 Jan 2017 12:01:18 +0100

[tip:perf/core] perf/x86/events: Add an AMD-specific Makefile

Commit-ID: 612f0c0b859ee99f800dc88ad470d938d90ad111 Gitweb: http://git.kernel.org/tip/612f0c0b859ee99f800dc88ad470d938d90ad111 Author: Borislav Petkov AuthorDate: Thu, 26 Jan 2017 09:08:19 +0100 Committer: Ingo Molnar CommitDate: Mon, 30 Jan 2017

[tip:perf/core] perf/x86/events: Add an AMD-specific Makefile

Commit-ID: 612f0c0b859ee99f800dc88ad470d938d90ad111 Gitweb: http://git.kernel.org/tip/612f0c0b859ee99f800dc88ad470d938d90ad111 Author: Borislav Petkov AuthorDate: Thu, 26 Jan 2017 09:08:19 +0100 Committer: Ingo Molnar CommitDate: Mon, 30 Jan 2017 12:01:19 +0100 perf/x86/events: Add an

[PATCH v3 2/3] Broadcom USB DRD Phy driver for Northstar2

This is driver for USB DRD Phy used in Broadcom's Northstar2 SoC. The phy can be configured to be in Device mode or Host mode based on the type of cable connected to the port. The driver registers to extcon framework to get appropriate connect events for Host/Device cables connect/disconnect

[PATCH v3 2/3] Broadcom USB DRD Phy driver for Northstar2

This is driver for USB DRD Phy used in Broadcom's Northstar2 SoC. The phy can be configured to be in Device mode or Host mode based on the type of cable connected to the port. The driver registers to extcon framework to get appropriate connect events for Host/Device cables connect/disconnect

[PATCH v3 0/3] Support for USB DRD Phy driver for NS2

Changes from v2: === Remove unnecessary checks for poweron as suggested in review. Changes from v1: === 1. Initialize file operations .owner field with THIS_MODULE. 2. Remove unnecessary gpio example in DT bindings documentation. This is previously acked by Rob Herring

[PATCH v3 0/3] Support for USB DRD Phy driver for NS2

Changes from v2: === Remove unnecessary checks for poweron as suggested in review. Changes from v1: === 1. Initialize file operations .owner field with THIS_MODULE. 2. Remove unnecessary gpio example in DT bindings documentation. This is previously acked by Rob Herring

[PATCH v3 3/3] DT nodes for Broadcom Northstar2 USB DRD Phy

This patch adds device tree nodes for USB Dual Role Device Phy for Broadcom's Northstar2 SoC. Signed-off-by: Raviteja Garimella --- arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git

[PATCH v3 3/3] DT nodes for Broadcom Northstar2 USB DRD Phy

This patch adds device tree nodes for USB Dual Role Device Phy for Broadcom's Northstar2 SoC. Signed-off-by: Raviteja Garimella --- arch/arm64/boot/dts/broadcom/ns2.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On Fri, Jan 27, 2017 at 01:07:35PM -0800, Kees Cook wrote: > On Fri, Jan 27, 2017 at 1:58 AM, Peter Zijlstra wrote: > > Nothing much, except lack of time. I spend the last several days hunting > > bugs, that trumps new features on my todo list. > > Totally understood. I was

Re: [RFC][PATCH 7/7] kref: Implement using refcount_t

On Fri, Jan 27, 2017 at 01:07:35PM -0800, Kees Cook wrote: > On Fri, Jan 27, 2017 at 1:58 AM, Peter Zijlstra wrote: > > Nothing much, except lack of time. I spend the last several days hunting > > bugs, that trumps new features on my todo list. > > Totally understood. I was just trying to see if

[PATCH v3 1/3] Add DT bindings documentation for NS2 USB DRD phy

This patch adds documentation for NS2 DRD Phy driver DT bindings Signed-off-by: Raviteja Garimella Acked-by: Rob Herring --- .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 30 ++ 1 file changed, 30 insertions(+)

[PATCH v3 1/3] Add DT bindings documentation for NS2 USB DRD phy

This patch adds documentation for NS2 DRD Phy driver DT bindings Signed-off-by: Raviteja Garimella Acked-by: Rob Herring --- .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 30 ++ 1 file changed, 30 insertions(+) create mode 100644

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Fri 2017-01-27 19:19:30, Borislav Petkov wrote: > + printk folk. > > On Fri, Jan 27, 2017 at 04:42:30PM +0100, Rabin Vincent wrote: > > proc_dostring() eats the '\n' and stops > > Not a problem, see diff below. > > Please do it this way instead because after a month no one will remember >

Re: [PATCH] printk: fix printk.devkmsg sysctl

On Fri 2017-01-27 19:19:30, Borislav Petkov wrote: > + printk folk. > > On Fri, Jan 27, 2017 at 04:42:30PM +0100, Rabin Vincent wrote: > > proc_dostring() eats the '\n' and stops > > Not a problem, see diff below. > > Please do it this way instead because after a month no one will remember >

Re: [PATCH v5 3/8] ARM: dts: rockchip: add timer entries to rk3188 SoC

On Mon, Jan 30, 2017 at 04:13:07PM +0300, Alexander Kochetkov wrote: > > > 30 янв. 2017 г., в 15:04, Daniel Lezcano > > написал(а): > > > > There is no case when the rockchip timer is used for the clockevent. > The is already timer entry for rk3228 in the DT. And it

Re: DRM Atomic property for color-space conversion

On Fri, Jan 27, 2017 at 05:23:24PM +, Brian Starkey wrote: > Hi, > > We're looking to enable the per-plane color management hardware in > Mali-DP with atomic properties, which has sparked some conversation > around how to handle YCbCr formats. > > As it stands today, it's assumed that a

<    10   11   12   13   14   15   16   17   18   19   >